Guide for how to create, implement, and manage an SBOM
A software bill of materials helps your org manage the software supply chain and identify vulnerabilities. Here's what your DevOps and DevSecOps teams need to know.
Oct 12, 2023 • 5 Minute Read
Software bill of materials (SBOM) are required for agencies and organizations that conduct business with the federal government. But they’re a good practice for any organization that wants to shore up their DevSecOps, secure their software, and reduce cybersecurity risks.
Table of contents
What is a software bill of materials?
A software bill of materials (or SBOM) lists all of the components used to create a software application, including each component’s name, supplier, version, and dependencies in the software supply chain.
Why do organizations need SBOMs?
A single piece of software can contain thousands of different custom, third-party, and open source components. SBOMs help organizations, particularly DevSecOps and DevOps teams, gain visibility into and keep track of the entire software supply chain and more easily manage and mitigate risks.
SBOM management for public sector organizations
SBOMs are a federal requirement for some organizations. In fact, President Biden issued an executive order that requires agencies doing business with the government to provide a software bill of materials.
SBOM management for private sector organizations
Even if your organization doesn’t do business with the federal government, creating an SBOM can be a good practice to get into. After all, SBOMs enhance software supply chain security, and government regulations tend to set the standard for public and private sector practices.
What to include in your SBOM
Before choosing an SBOM format, it can be helpful to take stock of your software supply chain. Your development team will be a good starting point, as they probably already have a list of software components they use. This may include:
Internal developed common code modules
Open source software (OSS), libraries, frameworks, or firmware
Third-party commercial off-the-shelf (COTS) software, libraries, frameworks, or firmware
At minimum, your SBOM should include the following for each component:
Author name
Supplier name
Component name
Version string
Component hash
Other unique identifiers
Relationships or dependencies between components
Timestamps
It’s also important to list known unknowns—any information or components you know are missing. You won’t have the time or inclination to list every dependency, but knowing what you need to gather will give you a baseline and help you determine the right SBOM format to use.
Types of SBOM standards or SBOM formats
SBOM formats provide a standard way to structure your SBOM so other tools (and customers and stakeholders you share it with) can easily understand the various software components you use. They also streamline the SBOM creation process.
The SBOM standard you use will depend on your needs. However, many organizations tend to use one of these two SBOM formats:
The third common format, the standard for software identification (SWID), is mostly used for licensing, not cybersecurity use, so we won’t cover it here.
OWASP CycloneDX
OWASP CycloneDX is a common SBOM standard used to reduce cybersecurity risks in the supply chain. It offers advanced capabilities designed specifically for creating and documenting SBOMs since it captures most details of software components, including metadata, dependencies, vulnerabilities, and annotations.
SPDX (Software Package Data Exchange)
SPDX (Software Package Data Exchange) is another common SBOM format. Originally created as a way to manage open-source software licenses, it’s become a standard for documenting and sharing provenance, license, security, and other SBOM-related information.
Best ways to automatically generate an SBOM
What makes automation so important when it comes to SBOM generation? Think about all the software components an organization uses. Whenever any component is updated, you need to create a new SBOM. This can make maintaining SBOMs manually a tedious, time-consuming process.
Automation is key to managing SBOMs efficiently and accurately. There are a few ways to automatically generate and update SBOMs. Using an SBOM format and machine-readable data will ensure tools can scan software and automatically create an SBOM for it.
The SwiftBOM tool can help with SBOM generation.
Getting started: Using and managing SBOMs
Even if your DevSecOps and DevOps teams don’t get SBOMs perfect at first, they should start creating and implementing them. Once your team creates an SBOM, they should comply with regulations and general best practices.
Create SBOM practices and processes
Beyond creating an SBOM and ensuring it contains the right data, you need practices and processes to integrate it into your workflows.
Frequency: You need to generate a new SBOM every time a component changes. What are your processes for this? How will you communicate with suppliers?
Depth: Your SBOM needs to contain essential information about each component. But as your organization matures, you may want to add even more detail.
Access control: Certain customers and users will need access to your organization’s SBOM. Specify access control terms, including who can access what information and/or make changes. You don’t need to make your SBOM public. But if you do, create guidelines with regulations and requirements.
Distribution: In addition to access controls and role permissions, you need a way to share SBOMs with key stakeholders. You might use source code or binary, human-readable files, or a website. You can choose more than one distribution method.
Acknowledge mistakes: Most organizations are still new to the process of generating SBOMs. Mistakes and inaccurate or incomplete information are likely to occur.
Determine who owns SBOM management
Once you create your SBOM, you’ll need people to maintain it and ensure it remains up to date. Your DevOps, DevSecOps, or development team is often the best to do this. They already work with and understand the code and software components your organization uses.
As they build new products, updating and maintaining the SBOM will become part of the software development lifecycle. They can also use software development tools to create SBOMs automatically.
Create a strategy for tracking known vulnerabilities
Organizations primarily use SBOMs to identify known vulnerabilities in the software supply chain. When you identify vulnerabilities, you need to assess their threat level and how you plan to proceed.
For example, you might identify a vulnerability in a component. If it doesn’t impact its dependencies or pose a risk to your organization, it wouldn’t be the best use of your time to remediate it.
In general, the Department of Commerce recommends tracking vulnerability data separately from SBOM data. Why? SBOM data reflects data for software components at a specific point in time, while vulnerability data constantly changes. Because of this, storing vulnerability data in your SBOM often isn’t the most accurate way to keep track of risks.
Improve your DevOps security posture with SBOM management
Between compliance requirements, emerging AI technologies, and growing application vulnerabilities, understanding your software supply chain is key to mitigating risks and defending your organization.
Learn more about SBOMs and DevSecOps:
