An SBOM (software bill of materials) is only as useful as it is accurate. There are a wide variety of potential SBOM use cases (security, open source license compliance, regulatory compliance, due diligence, etc), but all of them depend on the underlying SBOM data being correct, comprehensive, and up to date.  

There are many variables that ultimately affect SBOM quality. These include the tools you use to generate an SBOM, when and how you integrate those tools into the SDLC, the format of your SBOM document, the data fields you include in your SBOM, and more.

In this blog, we’ll discuss several important elements of a high-quality SBOM, starting with tooling and how to integrate it.

Tooling and Install Plan

Producing quality SBOMs at scale requires the right SBOM tools. It’s best to prioritize tools that offer comprehensive language coverage, support CycloneDX and SPDX, and provide numerous customization options.

Once you’ve selected an SBOM tool, the next question is when and how to integrate it into the software development lifecycle. I recommend after the final build for each service, but prior to deployment to represent a production environment — more specifically, within your continuous integration phase after you’ve successfully merged local environments with a development environment. At this point, you can build and run a FOSSA analysis (or an analysis with the tool of your choice) as a final step before deploying environments into any staging/production systems. 

Additionally, the final application install plan — which includes all microservices and components —  should be represented as one SBOM.

Another important consideration is how frequently you should generate a new SBOM. We recommend you create a new version each time you update or modify components (i.e. after every new build). 

It’s also critically important to ensure your SBOM tools provide language coverage for all open source dependencies in your install plan. Tooling will often report zero dependencies for unsupported languages. 

In addition to making sure your SBOM tooling has coverage for all the languages you use, ensure the output of the SBOM tooling properly aggregates polyglot applications. With free or open source tooling, it’s common that a user will need to manually aggregate individual SBOMs generated from language-specific tooling to represent a completed service or application.

SBOM Configuration and Data Fields

Although there are certain data fields that are part of every quality SBOM (package name, package version, package author, etc), there’s also a lot of room for customization. When deciding which data fields to include (and exclude) from your SBOM, it’s important to understand the needs of your SBOM consumers. This will make a big difference in determining whether a specific SBOM achieves its purpose.

Here are some considerations and recommendations for data fields to consider including depending on your primary use case(s).

License Compliance or Attribution Use Cases

Both CycloneDX and SPDX have a number of data fields that support open source license compliance use cases. Interestingly, SPDX License Identifiers — which are essentially standardized abbreviations for common open source licenses — form the foundation for license compliance use cases across both SPDX and CycloneDX. 

If you’re using the SPDX format, consider configuring your SBOM to include the Declared Licenses, Concluded License, and Copyright Text data fields. 

If you’re using CycloneDX, consider configuring your SBOM to include Licenses metadata, such as ID and URL.

You may also consider including full license text directly in your SBOM to help satisfy license notice requirements. You can do this in both SPDX (with the License Text field) or CycloneDX (with the Text field). Note that in CycloneDX, there’s an optional encoding for the license text; if you want to include human-readable full license text in a CycloneDX document, you will need to make some additional adjustments (e.g. escaping new lines or special characters).

Finally, it’s worth noting that both CycloneDX and SPDX support commercial licensing information. In CycloneDX, you can communicate commercial licensing information using the Licensor, Licensee, License Type, and Purchaser fields. In SPDX, you can communicate commercial license information by adding a custom license identifier (“LicenseRef”), then adding the full license text (or context/comments) in the “Extracted Text” field. (In cases where it wouldn’t be appropriate to include the full text of a commercial license in your SBOM, it’s relatively common practice to add context/comments in the SPDX “Extracted Text” field instead.)

Ultimately, for license compliance use cases, we recommend you configure your SBOM to include the license name for each component, and, if you intend for your SBOM to double as a public-facing attribution notice, consider including the copyright notice and full license text as well.

Security Use Cases

Security is a common SBOM use case. And, both CycloneDX and SPDX can be used to communicate a variety of security data, though the mechanism for doing so varies. 

This starts with VEX (Vulnerability Exploitability eXchange) data. VEX is used to communicate whether vulnerabilities are actually exploitable in a real-world context. Key VEX data fields include:

  • Vulnerability Identifier
  • Status
  • Status Justification
  • Mitigation 

In CycloneDX, you can either a) embed VEX data directly in the SBOM or b) link to an external VEX report (which is recommended to ensure the VEX data can be easily kept up to date). 

SPDX doesn’t have data fields that support directly embedding VEX data, but, like CycloneDX, it supports external references to VEX documents. 

Although VEX is an important part of communicating security-related information in an SBOM, there are other fields and references to keep in mind as well.

In CycloneDX, the “Vulnerabilities” element includes numerous security-related data fields, such as CWE, CVE, Vulnerability Score, Vulnerability Severity, and more. It’s also possible to link to external security advisories, vulnerability disclosure reports, and more. 

In SPDX, the primary way of communicating security information is through External References. You can link to VEX documents, CVE advisories, and more.

Whether using SPDX or CycloneDX, ensuring each package or component has a full dependencies (CycloneDX) or relationships (SPDX) graph will help locate the direct dependency remediation required to influence transitive dependencies. 

In addition, an associated unique identifier, such as a Package URL, is critical to validating the accuracy of vulnerabilities. For example: Is my organization using public registry versions of OSS packages or ones hosted internally? If internally hosted, are these mirrors or forked/modified versions my organization self-maintains? 

Ultimately, for security use cases, we recommend that you ensure each component has an accurate Package URL (PURL), a referenced or embedded VEX document, and up-to-date VEX status and accompanying justification.

Regulatory Compliance Use Cases

The Biden Administration’s 2021 cybersecurity executive order required organizations selling into the U.S. federal government to provide an SBOM along with each product. The requirement also outlined minimum elements that must be included in these SBOMs, which are as follows: 

  • Supplier Name
  • Component Name
  • Version of the Component
  • Other Unique Identifiers (e.g. PURL, CPE, SWID Tags)
  • Dependency Relationship            
  • Author of SBOM Data
  • Timestamp

It’s worth noting that these minimum elements are also applicable to the FDA’s new guidance around SBOMs to accompany premarket submissions. However, the FDA also has a few additional requirements, including communicating the level of support for maintaining the component and the component’s end-of-support date.

Automation vs. Human Contributions 

Although most of the data fields discussed in this section can be easily configured and automated in your SBOM tool — for example, it takes just a few seconds to add or remove data fields from your SBOM in FOSSA — there are a few that require some level of human intervention. 

Specifically, if you include VEX data in your SBOM, you will need to annotate it with status justification and mitigation information. Also, if you use SPDX and there are different values for the Concluded License (determined by the SPDX document creator) and Declared License (determined by the component author) fields, you’ll want to use the Comments on License field (7.16) to add context.

Additionally, SBOM tools often won’t easily support some of the less common data fields discussed in this section, so you may need to manually add them as well.

Hosting and Distributing High-Quality SBOMs

The work to ensure an accurate, quality SBOM doesn’t end once the document is first generated. It’s also vital to keep the SBOM up to date to reflect changes in your application. Additionally, it’s critical to distribute SBOMs in a way that your consumers can actually use them. 

We know this is not necessarily the highest priority for some organizations today, but we anticipate it becoming an increasingly important consideration as more SBOMS are demanded externally by software supply chain security-focused software consumers. 

An SBOM may become out of date as new vulnerabilities impact existing package versions, if the composition of your application changes (such as by introducing new components), or if an external mitigation is applied to an existing vulnerability, among many other reasons. We recommend the following to keep SBOMs up to date:

  • Generating new SBOMs, including updated VEX, per production deployment 
  • Daily VEX document creation to include new vulnerabilities and mitigation
  • Applicable access controls 

There are additional considerations for hosting and distributing SBOMs based on the type of software your organization is covering. Generally, these fall into either “Public” SBOMs or “Private” SBOMs. A public SBOM should be included in the root of any applicable public-facing version control software (VCS) or repositories enabling access for any potential software consumer. Public SBOMs should generally be reserved for open source applications or ubiquitous “freemium” models (for example, Slack). 

Private SBOMs should be included in the root of any applicable internally facing VCS or repositories enabling access by internal stakeholders such as security or compliance teams. Private SBOMs are generally reserved for internal security/compliance as well as commercial software used by government organizations (FDA, EO 14028) or risk-intolerant industries (healthcare, finance, industrial).

SBOM Quality: Additional Resources

I hope you found the guidance in this post helpful as you develop and/or refine your approach to generating SBOMs. If you did, here are some other resources you may find useful:

SBOM Examples, Explained (Blog): SBOMs can be complex, lengthy documents that describe multiple software components. To help demystify the content of an SBOM, we've created several examples, along with explanations for the data fields and sections in each.

Generating, Managing, and Importing SBOMs with FOSSA (On-demand webinar): See how you can use FOSSA’s platform to automate mission-critical parts of the SBOM lifecycle. 

How SBOMs Can Strengthen Security (Blog): Get a deep dive into how you can leverage SBOMs to strengthen software supply chain security.

Additionally, if you'd like more information about using FOSSA's tool to generate, manage, and import SBOMs, please reach out to our team.