The U.S. government’s NTIA (National Telecommunications and Information Administration) July 2021 release of the “The Minimum Elements For a Software Bill of Materials (SBOM)” was a landmark event. The publication, which stemmed from the Biden Administration’s May 2021 Cybersecurity Executive Order, provided a common framework for an SBOM’s data fields, formats, practices, and processes.
Although the requirements only directly apply to federal government agencies and their suppliers, the publication has provided a roadmap for how public and private enterprises alike should think about SBOMs.
Now that several years have passed since its release, we thought it would be an interesting exercise to consider the next iteration: Given the significant progress we’ve seen in SBOM adoption since 2021, what are the right next steps to make SBOMs even more usable across the ecosystem?
This blog outlines our proposal for several additions and changes we feel would help accomplish that objective. We outline recommendations for:
- Two new required data fields
- Updates to two existing required data fields
- An update to the list of required SBOM formats
- Considerations for using SBOMs to support vulnerability management
Before diving into the specifics, we do want to acknowledge that every SBOM program operates differently and has different objectives. These recommendations are based on the best practices we’ve gathered from supporting numerous SBOM management customers, who, in general, are motivated by SBOM accuracy, usability (e.g. using SBOMs to inform risk-management activities, not just generating them), and scalability.
Whether you’re a participant in a regulatory body/standards group, leading SBOM management for a private enterprise, or anywhere in between, we hope you find this piece useful.
1. PURL (Package URL)
One of the required data fields in the current minimum required elements is “Other Unique Identifiers.” The intent of this data field is to help the SBOM consumer identify with confidence the software component being described in the bill of materials. (It also plays an important role in making SBOMs truly machine-readable.)
Although we wholeheartedly endorse including unique identifiers in an SBOM, we think the logical next step is getting a bit more prescriptive about the type of required unique identifier, specifically for open source software.
Today, we often see CPEs (Common Platform Enumerations) used as unique identifiers. Although CPEs are valuable in theory, they’re notoriously difficult to use in practice, primarily for two reasons:
- CPEs are not generated until a CVE exists on a product version
- Tooling will often invent a CPE to use as a unique identifier, but there’s no guarantee it will use the same nomenclature as a CPE that Mitre or the NVD create
- The individuals within MITRE/NVD creating the CVE entry may not use consistent nomenclature. As a result, CPEs are not consistently generated, which the screenshot below illustrates
The PURL spec is not plagued by these issues. PURL is a URL string with standardized components that can be used across programming languages and ecosystems.
(We recommend viewing the official spec for full details, but, just as an example, the PURL for Version 3.6.0 of the popular Python package Bokeh is: pkg:pip/bokeh@3.6.0. This describes static properties of the package, such as type, namespace, and version. The namespace in particular is important because Bokeh 3.6.0 hosted in PyPI, and your forked Bokeh 3.6.0 hosted in your internal artifact registry, are different packages, full stop.)
Our view is that requiring PURL as a unique identifier will significantly improve data quality and accuracy across the SBOM ecosystem and go a long way toward enabling the sort of software supply chain security and, more specifically, zero-day vulnerability response initiatives that SBOMs can make possible.
One point to note regarding a major limitation of PURL is the lack of closed source or commercial software support. The spec is defined in such a way as to support different “types,” which in theory could include commercial software in the future and is the direction we’ve consistently seen working groups push for.
2. Component Type
SBOMs can be used to describe any number of different components: applications, libraries, frameworks, files, snippets, containers, and more. And, given the rapidly growing number of use cases in the extended bill of materials (such as AI and build profiles), it’s becoming increasingly important to be able to differentiate.
Including component type in an SBOM provides critical context to help SBOM consumers (and SBOM management tools) make informed decisions. Consider, for example, the difference between an open source package and a file. An SBOM may intend to describe a dynamically linked file — but if the consumer thinks it refers to a full open source library, “data,” or a “cryptographic-asset,” it could create significant confusion when ingested with the inherent intent of being machine-readable.
3. Minimum Version of SPDX and CycloneDX
The existing required SBOM minimum elements mandate organizations to produce SBOMs in one of three machine-readable formats: SWID, CycloneDX, or SPDX. This guidance has made a significant, positive impact on accelerating the move to SBOM format standardization and machine-readability.
In our view, the next iteration of the SBOM format conversation involves two adjustments:
- Removing SWID as one of the allowed SBOM formats
- Establishing minimum acceptable versions of SPDX and CycloneDX
Our rationale for these recommendations is as follows:
Removing SWID
In truth, removing SWID from the list of approved SBOM formats is more of a formality than a substantive change. SWID is much more of a software descriptor (along the lines of PURL) than a full-stack SBOM format; we’ve never actually seen it used as a replacement for a CycloneDX or SPDX document. So although removing SWID from the list of approved formats wouldn’t impact the vast majority of existing SBOM programs, it would provide greater clarity for organizations just starting their SBOM journeys.
Establishing Minimum Acceptable Versions of SPDX and CycloneDX
CycloneDX and SPDX (in particular) have evolved significantly from their initial releases. More recent versions support a far greater number of use cases, data fields, and general utility.
Beyond benefiting from general improvements to each specification, however, there are very concrete reasons why we recommend using a specific set of versions for each spec.
- SPDX: 2.2 or later. Version 2.2 is when SPDX started to natively support PURL.
- CycloneDX: 1.2 or later. Version 1.2 is when CycloneDX started to natively support PURL.
4. Declared License
Although SBOMs have strong roots in open source license compliance use cases — that was a primary driver for the initial development of SPDX nearly 15 years ago — regulatory compliance and security mostly dominate the conversation today.
Our view is that open source license compliance still has an important role — and requiring declared license information for open source components would both provide a major boost to the open source ecosystem and improve SBOM utility.
First and foremost, open source licenses are what sustain open source software development. They give project developers and maintainers the essential ability to require usage attribution and ensure their code remains free and accessible. Without open source licenses — and adherence to open source licenses — there would be no thriving open source ecosystem. Elevating declared licenses to a required SBOM element would help emphasize the vital importance of license compliance.
The other important benefit of including license compliance data fields in an SBOM is that this unlocks the ability to use the actual SBOM as a compliance artifact. Most permissive open source licenses have only attribution requirements (e.g. credit the open source author and post a copy of the open source license), which an SBOM can easily satisfy. Although simply including the declared license as we recommend won’t be entirely sufficient to comply with most licenses, it may encourage more SBOM producers to consider utilizing the optional fields that would be. Our view is that the end result would be more SBOMs being created and distributed for a broader range of purposes, supporting big-picture software transparency objectives.
It’s also worth noting that the SBOM ecosystem is well-positioned to embrace software licensing data fields. Both SPDX and CycloneDX support the use case extremely well, and many modern SBOM management tools (like FOSSA) allow organizations to easily add software licensing fields to their SBOMs.
5. Dependency Relationships
SBOM practitioners might be surprised to see us include this in our list. After all, dependency relationships are currently an NTIA-required element. The distinction is that existing minimum elements focus only on the upstream relationship — e.g. describing the relationship where an upstream component X is included in software Y. In order to best ensure a full dependency graph is represented, our view is that dependency relationships should be represented bi-directionally.
Doing so is critically important to maintain the integrity of where transitive dependencies are introduced. To be clear, you can with high diligence represent a dependency graph with purely upstream relationships. In practice, we find users and tooling often miss dependency relationships when not forced to represent both directions. It is extremely common that the same transitive dependencies are used by multiple direct dependencies.
Take for example an application “App1” with a major vulnerability in transitive dependency D:
- Direct dependency A depends on B depends on C depends on D
- Direct dependency E depends on F depends on C depends on D
- Direct dependency H depends on I depends on D
An upstream-only dependency relationship must ensure it claims “D” is a dependency of “C,” “D” is a dependency of “G,” and “D” is a dependency of “I.” If the user or tooling generating the SBOM misses “D” is a dependency of “I,” you have now falsely made the assumption D is only a transitive dependency of C.
In our small example, it is unlikely this relationship will be missed, but when scaled to modern-day applications with thousands of dependencies, these critical relationships are often misrepresented.
To emphasize the importance of bidirectional dependency relationships is to serve as a redundancy control to ensure your dependency graph isn’t missing any nodes — thus ensuring your remediation efforts, in particular for transitive dependencies, are accurate.
SBOMs and Vulnerability Management
You may notice that none of the existing SBOM minimum elements (or our proposed additions and revisions) cover vulnerability-specific information. There are a few reasons for this, including the fact that vulnerability information tends to be dynamic, while core SBOM metadata is largely static. Consequently, some organizations prefer to decouple vulnerability assessments from the SBOM itself.
With that said, we do recommend organizations that produce SBOMs consider producing accompanying assessments to assist consumers with vulnerability management. In practice, this means starting with a list of all CVEs — including ones that you’ve confirmed impact your product, ones that you’ve confirmed don’t impact your product, and ones that might impact your product.
The reason why we recommend including CVEs (even false positives) is for the benefit of the SBOM consumer. If the consumer imports your SBOM into some sort of SBOM management tooling, their analysis will show all CVEs associated with your open source components. Declining to include not-affected CVEs is likely to create confusion.
At the same time, the SBOM manufacturer should certainly communicate exploitability information to help the consumer understand where risks are real and where they’re not. This is where VEX (Vulnerability Exploitability eXchange) and VDR (Vulnerability Disclosure Report) statements come into play. If and when possible, annotate CVEs with VEX statuses and justifications. Potential statuses are as follows:
- “affected”
- “not affected”
- “under investigation”
- “fixed” - i.e. patched
There are a variety of possible status justifications (which can differ depending on the specific VEX format you use). These include reasons like an inline mitigation has already been applied, the vulnerable code isn’t in the execute path, or the vulnerable code isn’t present. We recommend reviewing your preferred VEX format for a full list of potential justifications.
We’d also note that, to make VEX production scalable, it’s a good practice to integrate this process with your remediation workflow, including SCA tooling (if it supports automated VEX annotations) and ticketing systems (like JIRA).
More SBOM Management Resources
If you’ve found this blog post useful, we’d encourage you to consider checking out some of our other SBOM management content. Links are included below.
Alternatively, if your organization is looking for support automating SBOM management essentials (generation, ingestion, monitoring, analysis, or distribution), please feel free to reach out to our team for support and/or a product demo.
