The National Telecommunications and Information Administration (NTIA), under the guidance of the US Department of Commerce, recently released a white paper outlining the minimum requirements for a Software Bill of Materials (SBOM). The Minimum Elements for a Software Bill of Materials (SBOM) describes the requirements that must be met for any company doing business with the US federal government.
This blog will explore the importance of SBOMs, how to create them, and the minimum requirements businesses need to meet.
Key Takeaways:
- SBOMs Are Critical for Security and Compliance: An SBOM provides transparency into the components and dependencies of your software, helping organizations identify vulnerabilities, ensure license compliance, and manage supply chain risks.
- SBOM Mandates Have a Broad Impact: While SBOMs are required for businesses selling software to the US federal government, this mandate is creating a trickle-down effect across industries, pushing more organizations to adopt SBOMs for improved transparency and security.
Tools Are Essential for Managing SBOMs and Vulnerabilities: SBOM generation and vulnerability management can be complex, but tools like ASPM platforms automate and streamline the process, ensuring continuous monitoring, compliance, and proactive risk management throughout the software development lifecycle.
What Is a Software Bill of Materials (SBOM)?
An SBOM is a formal record containing the details and supply chain relationships of the various components used in building a software application and is typically used by organizations to manage and track the components that make up their software applications. The goal? Improve software security and compliance.
These “components” include all open-source and third-party dependencies, including direct and transitive dependencies.
- Direct Dependencies: These are components that your software explicitly relies on. For example, if your application uses React.js for its front end, React.js is a direct dependency.
- Transitive Dependencies: These are dependencies of your dependencies. Continuing with the React.js example, if React.js relies on another library like loose-envify, then loose-envify becomes a transitive dependency of your application.
In the past, software development teams often worked in isolation, resulting in limited visibility into the components used in their application. With the rise of open-source software, the complexity of software systems has increased. This increased complexity makes it difficult for organizations to keep track of all the components used in their codebases. That’s where SBOMs come in, providing a single source of truth for all components that comprise an application.
Still confused? One of the most common analogies you hear is that SBOMs are like a list of ingredients for your software. Much like your favorite lemon ginger scone mix provides a list of everything it contains so you can make an assessment of whether it’s safe to consume, an SBOM provides a list of everything in a software application so you can make an assessment of whether it’s secure.
Why Is a Software Bill of Materials Important?
SBOMs help organizations better produce, choose, and operate software. They allow for greater transparency into both the solutions you produce and the solutions you use.
The following are some of the main use cases for SBOMs:
Selling to the US Federal Government
On May 12, 2021, the White House issued Executive Order (EO) 14028 on Improving the Nation’s Cybersecurity. The EO identified cyberattacks as a threat to national and economic security. One of the key outcomeoutcomes of Executive Order 14028 was the mandate that software companies wishing to sell to the US federal government must deliver an bill of materialsSBOM for each product sold.
The government believes that an SBOM federal requirement will lead to greater transparency and help curb the current rash of software supply chain attacks.
SBOMs for Supply Chain Security
SBOMs provide a comprehensive inventory of software components, enabling organizations to effectively manage supply chain security. By identifying vulnerabilities, tracking dependencies, ensuring license compliance, and tracing component provenance, SBOMs help organizations mitigate risks, respond to incidents promptly, and maintain a secure software ecosystem.
Open Source and Third-Party Security
An SBOM can be used to monitor software for known security vulnerabilities. By keeping track of all the components and dependencies used in your application, you can identify any vulnerabilities and take steps to address them. When new exploits like Log4J are disclosed, an SBOM allows you to quickly identify whether the vulnerability is in your codebase and needs to be remediated.
License Compliance
Open source is free as in “free speech” not free as in “free beer.” As such, open source components each operate under an open source license, which may or may not limit your ability to create and sell derivative work. SBOMs help identify which open source licenses are in your codebase. This data can be used to determine whether your licenses are compliant with your internal policies and help protect your intellectual property. SBOMs can also help you remain compliant with license obligations of all components used.
M&A Due Diligence
SBOMs are often used as part of the merger and acquisition due diligence process to provide visibility into the software and solutions that are being purchased. Using an SBOM gives insight into the security of the solution and can help protect intellectual property by identifying any restrictive open source licenses.
Open Source Component Management
One of the best practices to secure your software is to keep your dependencies up to date. Furthermore, with time, every component reaches the end of its useful life. SBOMs help you proactively identify components that have reached their end of life and need to be cycled out as well as help you find alternative solutions.
Compliance and Reporting Mandates
SBOMs can help organizations better support compliance and reporting requirements by providing a highly detailed asset inventory. SBOMs can be used to help monitor for security risks of deployed systems and to follow up on security alerts to demonstrate vigilance.
Learn more about achieving compliance in the software development lifecycle (SDLC).
Export/Import Controls
SBOM data can be used to build allowlists or denylists of open source and third-party components that are approved or disapproved within your organization.
How To Create an SBOM
Convinced you should adopt the use of SBOMs? Here’s a high-level overview of where to start.
Step 1: Select the Right SBOM Generation Tool
While you technically could manually create SBOMs or develop custom scripts, most organizations use automated tools. Importantly, you must choose one that fits your development environment and the specific stage of your software’s lifecycle.
Tools like Software Package Data Exchange (SPDX), CycloneDX, and OWASP Dependency-Track plugins integrate seamlessly with most CI/CD pipelines and automate the SBOM generation process. The result? SBOMs are always up to date, with automation minimizing the risk of human error.
Step 2: Include All Relevant Software Components
As we’ve said, your SBOM should comprehensively list all the software components used in your project. This includes open-source libraries, third-party commercial software, internal modules, and any other dependencies. For each component, record essential details such as the component name, version number, supplier, and license type.
For example, if you’re developing a web application, your SBOM might include frontend libraries like React.js, backend frameworks like Node.js, and databases like MongoDB, each with its version and licensing information.
Step 3: Integrate SBOM Creation into Your DevSecOps Workflow
For ongoing security and compliance, it’s important to integrate SBOM generation into your DevSecOps processes. The tools we mentioned above (SPDX, CycloneDX, and OWASP Dependency-Track plugins) were specifically designed to assist here.
Remember: ongoing SBOM maintenance is critical to ensure that it reflects the current state of the software.
Software Bill of Materials (SBOM) Example
Before we share an example, it’s important to note that SBOMs can vary significantly depending on the format used, with different formats tailored to meet specific needs and compliance requirements.
Common formats include SPDX and CycloneDX (among others), each offering unique features. Organizations must carefully consider their goals when choosing a format.
The eagle-eyed amongst you will have noticed we mentioned SPDX and CycloneDX above in the context of automation tools. To be clear: “formats” are the standardized templates or blueprints that define how SBOMs are structured and documented, while “automation tools” are the software solutions that help create and manage SBOMs according to these templates.
SPDX is ideal for detailed license management and legal compliance. CycloneDX, on the other hand, excels in security-focused environments where vulnerability management and dependency mapping are critical.
We’ve included both examples below, which provide a straightforward view of all the components, dependencies, associated licenses, etc., for the application we’ve aptly named “Cycode.”
SPDX Example
{
"SPDXID": "SPDXRef-DOCUMENT",
"spdxVersion": "SPDX-2.2",
"creationInfo": {
"created": "2024-08-31T00:00:00Z",
"creators": [
"Tool: YourSBOMTool-1.0"
],
"licenseListVersion": "3.9"
},
"dataLicense": "CC0-1.0",
"name": "Cycode",
"documentNamespace": "http://spdx.org/spdxdocs/Cycode-1.8.03",
"packages": [
{
"SPDXID": "SPDXRef-Package-React.js",
"name": "React.js",
"versionInfo": "17.0.2",
"supplier": "Organization: Facebook, Inc.",
"licenseDeclared": "MIT",
"downloadLocation": "NOASSERTION",
"filesAnalyzed": false,
"hasFiles": [],
"externalRefs": [],
"verificationCode": "NOASSERTION",
"comment": "No detailed license verification done yet",
"vulnerability": [
{
"id": "CVE-2021-12345",
"source": "NVD",
"severity": "High",
"description": "Vulnerability in React.js related to XSS attacks.",
"mitigation": "Upgrade to React.js 17.0.3"
}
]
},
{
"SPDXID": "SPDXRef-Package-Node.js",
"name": "Node.js",
"versionInfo": "14.17.6",
"supplier": "Organization: OpenJS Foundation",
"licenseDeclared": "MIT",
"downloadLocation": "NOASSERTION",
"filesAnalyzed": false
},
{
"SPDXID": "SPDXRef-Package-Express.js",
"name": "Express.js",
"versionInfo": "4.17.1",
"supplier": "Organization: OpenJS Foundation",
"licenseDeclared": "MIT",
"downloadLocation": "NOASSERTION",
"filesAnalyzed": false,
"dependencies": [
{
"SPDXID": "SPDXRef-Package-node-forge",
"relationship": "DEPENDS_ON"
}
],
"vulnerability": [
{
"id": "CVE-2020-7720",
"source": "NVD",
"severity": "Medium",
"description": "Prototype pollution vulnerability in Express.js.",
"mitigation": "Upgrade to Express.js 4.17.2"
}
]
},
{
"SPDXID": "SPDXRef-Package-MongoDB",
"name": "MongoDB",
"versionInfo": "4.4.10",
"supplier": "Organization: MongoDB, Inc.",
"licenseDeclared": "SSPL",
"downloadLocation": "NOASSERTION",
"filesAnalyzed": false,
"comment": "Specific license implications for commercial use not fully analyzed"
}
]
}
CycloneDX Example
{
"bomFormat": "CycloneDX",
"specVersion": "1.4",
"serialNumber": "urn:uuid:123e4567-e89b-12d3-a456-426614174000",
"version": 1,
"metadata": {
"timestamp": "2024-08-31T00:00:00Z",
"tools": [
{
"vendor": "YourCompany",
"name": "YourSBOMTool",
"version": "1.0"
}
],
"component": {
"type": "application",
"name": "Cycode",
"version": "1.8.03"
}
},
"components": [
{
"type": "library",
"name": "React.js",
"version": "17.0.2",
"publisher": "Facebook, Inc.",
"licenses": [
{
"license": {
"id": "MIT"
}
}
],
"properties": [
{
"name": "cyclonedx.knownUnknowns",
"value": "No detailed license verification done yet"
}
],
"vulnerabilities": [
{
"id": "CVE-2021-12345",
"source": {
"name": "NVD"
},
"ratings": [
{
"severity": "High"
}
],
"description": "Vulnerability in React.js related to XSS attacks.",
"recommendation": "Upgrade to React.js 17.0.3"
}
]
},
{
"type": "library",
"name": "Node.js",
"version": "14.17.6",
"publisher": "OpenJS Foundation",
"licenses": [
{
"license": {
"id": "MIT"
}
}
]
},
{
"type": "library",
"name": "Express.js",
"version": "4.17.1",
"publisher": "OpenJS Foundation",
"licenses": [
{
"license": {
"id": "MIT"
}
}
],
"dependencies": [
{
"ref": "pkg:npm/[email protected]"
}
],
"vulnerabilities": [
{
"id": "CVE-2020-7720",
"source": {
"name": "NVD"
},
"ratings": [
{
"severity": "Medium"
}
],
"description": "Prototype pollution vulnerability in Express.js.",
"recommendation": "Upgrade to Express.js 4.17.2"
}
]
},
{
"type": "library",
"name": "MongoDB",
"version": "4.4.10",
"publisher": "MongoDB, Inc.",
"licenses": [
{
"license": {
"id": "SSPL"
}
}
],
"properties": [
{
"name": "cyclonedx.knownUnknowns",
"value": "Specific license implications for commercial use not fully analyzed"
}
]
}
],
"dependencies": [
{
"ref": "pkg:npm/[email protected]",
"dependsOn": [
"pkg:npm/[email protected]"
]
},
{
"ref": "pkg:npm/[email protected]",
"dependsOn": [
"pkg:npm/[email protected]"
]
}
]
}
In practice, SBOMs can be more detailed and tailored depending on the complexity of the software and the specific needs of your organization.
What’s Included in a Software Bill of Materials?
As you can see above, an SBOM is more than just a list of software components; it’s a detailed inventory that provides critical insights into your software’s construction, helping you manage risks, ensure compliance, and maintain security.
Importantly, though, this is just one example.
Here’s a more detailed visual representation of how an SBOM is structured that might make it easier to understand how these elements fit together and where each piece of critical information is documented.
Now, let’s explore the role of each piece of information in more detail.
Core Components and Metadata
At its foundation, an SBOM lists each software component by name, along with its version, supplier, and license type. This information is essential for identifying the origins of your software components and understanding the legal and operational implications of using them.
- Component Name: This is the identifier for each software component, usually provided as the exact name used in the dependency management system. Example: “React.js”
- Version: The specific version of the component used in the software. This is critical for vulnerability management, as different versions may have different security implications (e.g., “17.0.2”).
- Supplier: The entity or organization that provides the component, such as an open-source project or a commercial vendor. Example: “Facebook, Inc.” for React.js
- License Information: The type of license under which the component is distributed. This is crucial for legal compliance. Example: “MIT License.”
These metadata elements typically appear in the main component list of the SBOM, as in the example above.
Dependencies and Relationships
Beyond listing individual components, an SBOM should map out the relationships between these components. This includes dependencies—both direct and transitive — and is essential for assessing the impact of vulnerabilities, managing risks, and ensuring compliance.
The SBOM maps these relationships by listing each component along with its direct dependencies. This can be represented in a hierarchical structure or a flat list with references indicating which components depend on others.
In SPDX, for example, dependencies are mapped using “Relationship” tags like “DEPENDS_ON” or “CONTAINS” which define how components are connected.
Security and Vulnerability Data
Another critical aspect of any SBOM is the inclusion of security-related information. This includes known vulnerabilities associated with each component and a summary of any security measures or patches that have been applied.
In some SBOM formats, there’s a specific section dedicated to vulnerabilities. This section lists known vulnerabilities associated with each component, often including details such as the vulnerability ID, severity, description, and references to patches or mitigation steps.
In other formats, relevant security information might be included in the metadata for each component, or within broader compliance sections.
In both SPDX and CycloneDX examples above, the data is embedded within the “vulnerability” array inside each component’s section. Additional vulnerability data like CVE ID, source, severity, description, and mitigation steps are also included in each.
Missing Data and Known Unknowns
An SBOM should also address any gaps in the data. These “known unknowns” are areas where further investigation is needed. For example, if a component lacks sufficient documentation or if the licensing terms are unclear, this should be noted in the SBOM.
These “known unknowns” can be documented directly within the component metadata, within dedicated sections, or via a link to external documents or databases.
In the SPD snippet, this information is documented using the “comment” field within the package component. In the CycloneDX snippet, this information is captured using custom “properties” fields.
Minimum SBOM Requirements
When defining the minimum SBOM requirements, the NTIA understood that record format was still rapidly evolving as a technology. Because of this, they adopted a highly flexible set of guidelines that allow for adaptation to the developing needs of the market.
The three main requirements of SBOMs, as detailed by the NTIA, are:
Data Fields
SBOM-required fields need to contain baseline data about each component. Information should be presented in a uniform structure to easily identify the elements that make up an application. The purpose of these fields is to track components across the software supply chain and map them to other useful sources, such as license or vulnerability databases.
While uniformity is a key requirement, these data fields must be flexible enough to adapt to future changes. The following are the minimum requirements for data fields in an NTIA SBOM:
Automation Support
To achieve the greatest transparency and usability, companies must generate machine-readable SBOMs that support automation and allow for scaling across the software ecosystem.
Furthermore, SBOMs should be generated in one of the following three formats:
- Software Package Data eXchange (SPDX): Created as an open standard by the Linux Foundation, this is now an ISO standard (ISO/IEC 5962:2021). SPDX reduces redundant work by providing common formats to share important data, thereby streamlining and improving compliance, security, and dependability. A wide range of open-source and commercial vendors support SBOMs using this format.
- CycloneDX: This a lightweight SBOM standard originated in the Open Web Application Security Project (OWASP) community. Designed from the start to be a BOM format and meet a variety of use cases, CycloneDX provides support for integrity verification of the components associated with the BOMs it is used for through hash values and cryptography.
- Software Identification (SWID) Tags: The project is supported by the National Institute of Standards and Technology (NIST), and the specification is defined by the ISO/IEC 19770-2:2015 standard. NIST is working to incorporate SWID tag data into the vulnerability dataset provided by the National Vulnerability Database (NVD). SWID is most often associated with component licensing.
Figure 1 shows what an SBOM might look like for the Lemon Ginger Scones we talked about earlier. In Figure 2, the image shows the SBOM relationship of one ingredient, sugar, in our scones.
Figure 1. SPDX SBOM for Lemon Ginger Scones
Figure 2. SPDX SBOM Package Detail for Sugar
Practices and Processes
The NTIA states that organizations need best practices and processes to identify how an SBOM is requested, created, and used within the software supply chain. In many cases, however, the NTIA does not define what that practice or process should be, but rather states that each organization needs to define it themselves.
To maintain strong ASPM, the following are the practices, processes, and SBOM standards should be followed:
| Required Practices and Processes | How They Work |
| Frequency | A new SBOM must be created whenever a software component is updated in a new build or release. Likewise, if you discover an error or omission in your SBOM, it must be corrected and updated. |
| Depth | SBOMs should identify all primary and transitive dependencies. According to NTIA, “At a minimum, all top-level dependencies must be listed with enough detail to seek out the transitive dependencies recursively.” |
| Known Unknowns | In some instances, the full dependency graph of a component is unknown. SBOMs should distinguish between whether a component has no further dependencies versus when information about dependencies is unknown or incomplete. |
| Distribution and Delivery | SBOMs should be made available in a timely fashion and must have appropriate access permissions and roles in place. Organizations must also make their existence and availability known, as well as how they are accessed. |
| Access Control | Organizations must decide whether to publish their SBOMs publicly or privately. If they decide to keep SBOMs private, the terms of access must be specified, usually in either the sales contract or license agreement. |
| Accommodation of Mistakes | Internal management of supply chain data is still evolving, and it is understood that mistakes will happen. Suppliers should offer updated data as they identify mistakes or omissions. Likewise, users should be tolerant of the occasional “incidental error.” |
Limitations of SBOM Compliance in the Software Supply Chain
Despite these guidelines, the NTIA is clear that these requirements are only a starting point. SBOMs still have limitations. More work must be done to expand transparency in the software supply chain and support visibility for securing software.
In fact, the NTIA acknowledges that several recent high-profile attacks in the supply chain did not target software components but the tools and systems used to manage the software development and build process. In these cases, SBOMs, as currently defined, would not provide effective coverage against a software supply chain attack.
This solution is not a panacea, and NTIA acknowledges that there are gaps in coverage. SBOMs alone do not address the multitude of challenges that developers face when it comes to software supply chain risk management. Instead, they should be considered one tool among many.
Stay Ahead of Emerging SBOM Standards with Cycode
As we’ve explored, staying compliant with emerging SBOM standards is crucial for ensuring transparency and security in your software supply chain. Cycode’s Complete ASPM platform offers robust SBOM capabilities to help you navigate these requirements effectively.
- Automated SBOM Generation: Easily create SBOMs in SPDX or CycloneDX formats with a single click, ensuring up-to-date and accurate inventories of your software components.
- Seamless CI/CD Integration: Integrate SBOM generation into your continuous integration and delivery pipelines, maintaining real-time visibility into your software components throughout the development lifecycle.
- Comprehensive Vulnerability Management: Leverage Cycode’s SBOM capabilities to identify and assess vulnerabilities within your software components, facilitating proactive risk mitigation strategies.
- Enhanced License Compliance: Gain insights into open-source licenses within your codebase, ensuring adherence to legal obligations and internal policies.
By integrating Cycode’s SBOM features into your development processes, you can achieve greater transparency, enhance security, and maintain compliance with evolving standards,
Want to learn more? Schedule a demo today.
