Even though Software Bills of Materials (SBOMs) have been around for about a decade, they’ve recently gained a lot of buzz in the software industry.
This is due in part to Executive order 14028, which was released in May 2021 as a response to the SolarWinds software supply chain attack.
One of the key outcomes of Executive Order 14028 is the mandate that software companies wishing to sell to the US federal government must deliver a Software Bill of Materials (SBOM) for each product. Likewise, anyone selling to a company selling to the government must provide an SBOM. And again, anyone selling to a company selling to a company that sells to the US federal government must have an SBOM. You get the idea.
Suddenly everyone must have an SBOM.
This blog explores what an SBOM is, why they’re so important, and how to create one. Examples included!
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 Should You Use SBOMs?
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
First and foremost, if you want to sell to the US federal government – or sell to a company that sells to the US federal government – you must provide an SBOM as part of that transaction. The US federal government believes that requiring an SBOM 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 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.
Learn More About SBOMs
Though SBOMs have a wide range of use cases, they will be most helpful once they gain universal adoption. Currently, SBOM standards and requirements are still developing. Achieving full participation will take some time due to the large number of tools and standards that are now just emerging.
For a deeper dive into the baseline requirements for SBOMs as defined by the US federal government, check out “Making Sense of SBOMs: The Minimum Requirements.”
About Cycode
Want to learn more about how Cycode provides visibility, security, and integrity across all phases of the SDLC? Schedule a demo today!
