Data Fields

The purpose of these fields is to provide adequate identification of these components. This allows you to monitor them over the software supply chain and relate them to other useful data sources, such as vulnerability or license databases. Some examples of data fields are supplier name, component name, version of the component, other unique identifiers, dependency relationship, author of SBOM data, and timestamp.

Automation Support

Organizations that want to keep a close eye on SBOM component data will require it provided in a consistent and easy-to-understand style. This is addressed in the SBOM basic requirements section under “Automation Support”

Practices and Processes

Finally, the “Practices and Processes” section lays out six standards for how and when SBOMs should be updated and supplied. They are as follows:

• If the software component is upgraded with a new build or release, new SBOMs must be produced.
• Authors of SBOMs should include top-level components as well as their transitive dependencies.
• If the SBOM doesn’t offer a complete dependency tree, the SBOM author should explain whether this is because (a) the component has no more dependencies, or (b) the existence of dependencies is unknown and incomplete.
• SBOMs must be distributed and delivered in a “timely” manner, with “proper access rights and roles in place”.
• Companies that want to keep some components of an SBOM secret must specify access control parameters, which would contain specific rules and procedures for incorporating SBOM-related information into the user’s manual and tools. To put it simply: if there’s something that must be kept secret for the organization’s sake, then the process of keeping it secret is defined in this section. 
• Because the standards controlling SBOM generation are new, SBOM users are advised to forgive (unintentional) faults or omissions.