Today, organizations of all types are successfully generating SBOMs (software bill of materials) for a wide range of security, regulatory compliance, and business reasons. But we’ve seen businesses struggle when it comes to another part of the SBOM lifecycle: distributing them.

Of course, it’s easy enough for any organization that creates an SBOM to place the file in Google Drive or attach it to an email. It’s harder to share SBOMs in a way that will make the document actionable for the recipient.  

In many cases, SBOM consumers won’t get full value from SBOMs unless the file is created in the right format, with the right data fields, and with the right update frequency. And, given concerns around exposing sensitive intellectual property, it’s also critical that the SBOM be shared securely and to a limited audience.

Although we of course understand that the right approach to SBOM sharing may vary depending on your use case (e.g. there are different considerations when distributing SBOMs to a regulatory body and a private enterprise), this blog will review several best practices that generally apply.

Button to download FOSSA's SBOM Starter Kit

1. Understand Your SBOM Consumer’s Ingestion Requirements

The first part of effectively distributing SBOMs is making sure you generate them in a way that meets your consumer’s requirements. Advanced SBOM programs generally have tools in place that ingest third-party SBOMs and enable analysis — the desired result is for the SBOM consumer to analyze vulnerabilities and licenses in your SBOM like they would their own.

There are several specific areas where we recommend you get alignment with your SBOM consumer.

SBOM formats

  • Which SBOM specification should you use (CycloneDX, SPDX)?
  • What is the minimum acceptable version of said SBOM specification?

SBOM data fields

  • NTIA minimum elements
    • Supplier
    • Name
    • Version
    • Unique ID
    • Dependency relationships
    • Each SBOM element must have a component 
    • Author of SBOM
    • Timestamp
    • Unique identifiers
      • PURL
      • CPE
    • Vulnerability Disclosure Report (VDR) & Vulnerability Exploitability Exchange (VEX)

Required threshold(s) for analysis of SBOM metadata

  • Vulnerability risk tolerance 
  • License compatibility 
  • Package support status

2. Develop a Process to Share SBOMs After Updates Are Made

SBOMs are only useful if they are accurate. And, SBOMs aren’t accurate if they aren’t up-to-date. 

When building a continuous motion to share SBOM updates, an organization needs to consider the communication strategy for “static” and “dynamic” attributes of an SBOM. 

Static attributes are SBOM metadata that remain the same until a new build, commit, or application version. Examples of these attributes include SBOM generation metadata (tooling, author, format, version, etc.) and package metadata (package name, version, ecosystem, architecture, license(s), copyrights, etc.). 

Dynamic attributes are SBOM metadata that change in the absence of any new build, commit, or application version. Examples of these attributes include vulnerability metadata (new CVEs, VEX status and justification, support status, etc.)   

Distributing updated SBOMs generally involves two steps:

  1. Developing a mechanism to communicate static SBOM attributes
    1. An SBOM should be generated for every application build, commit, or application version.
    2. There are many distribution methods an organization may choose. These range from as simple as emailing an SBOM or including a cloud download URL to as complex as SaaS-hosted SBOMs with granular, role-based access controls.  
  2. Creating a process for sharing dynamic attributes as soon as they are updated,  including a notification system for the recipient. 
    1. An SBOM should either be redistributed, using the same means for static attributes, or appended with hosted solutions.
    2. Dynamic attributes offer the biggest challenge for manual distribution methods. We suggest you consider custom or commercial SBOM tooling with full support for the desired dynamic attributes.

3. Build in Security and Access Controls

Although some organizations are comfortable sharing their SBOMs publicly, others may not be, and understandably so. While we continue to be transparency and open source advocates, we understand some organizations have intellectual property or competitive concerns limiting their ability to share SBOMs publicly.

If you are in the latter category, we highly recommend you consider security and access control in your distribution process. Some features to consider when sharing SBOMs privately include:

  • Whether your SBOMs are hosted on a platform with standard security controls, including modern encryption in transit and at rest 
  • Role-based access controls to limit shared SBOMs to only the users or organizations you determine
  • Time-based access controls to limit how long an SBOM should remain accessible by your desired users or organizations

4. Share VEX Statements to Accompany Your SBOMs

SBOMs have a wealth of information about the software components and licenses in a given application. And, as mentioned, SBOM management tools can be used to analyze SBOMs and surface known vulnerabilities associated with open source dependencies.

But there’s one missing piece in making SBOMs truly actionable for vulnerability management: context on whether the vulnerabilities associated with open source are exploitable based on their specific usage. 

That’s where VEX (Vulnerability Exploitability eXchange) comes in. VEX is a set of formats that allows organizations to communicate whether a vulnerability is exploitable in its product context. 

For example, if your SBOM includes Package X, Version Y that’s associated with a CVE, your SBOM consumer might assume they’re impacted by that CVE. But, if you’ve already made an inline mitigation or if the code isn’t in the execute path, among other potential reasons, they won’t be. VEX helps you share that information in a standardized way with your SBOM consumers. 

Given VEX supports statuses for affected, not_affected, fixed, and under_investigation, an SBOM-focused organization is encouraged to categorize all vulnerabilities into one of the above statuses. 

While, in practice, this may be unrealistic to implement at scale, we highly encourage organizations to communicate affected and not_affected vulnerabilities at minimum. Doing so requires either embedding VEX statements directly in the SBOM or appending them as a standalone document. As mentioned earlier, since vulnerability detection and remediation are considered “dynamic” attributes of an SBOM, we’d advocate for you to leverage dynamic distribution strategies. 

SBOM Sharing: The Bottom Line

As private businesses, federal agencies, and regulatory bodies continue to prioritize software transparency, SBOM sharing will only increase as a focus. Although there’s no one-size-fits-all approach to distribution, we do recommend you consider security, your consumer’s data needs, and automation (among other factors) when deciding your distribution strategy.

A potential solution to make SBOM sharing easier for both producers and consumers is FOSSA's SBOM Portal. It allows producers to securely generate or upload their SBOM files while maintaining tight control over access to alleviate concerns over IP exposure. Consumers can then analyze the SBOMs they receive to surface vulnerabilities and licenses that may conflict with their policies.

Please get in touch with our team for more information about our SBOM Portal.

FOSSA Director of Content Andy Drukarev contributed to this article.