Guide for how to create, implement, and manage an 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.

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.

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.

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.

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.