SBOMs: Software Bill of Materials, Explained

Vendors have long used bills of materials (BOMs) to detail the pieces that make up their supply chain products.

Software bill of materials (SBOMs) work similarly. SBOM is a concept that's been around for some time, but is quickly being adopted more widely: companies are concerned about the security of their purchases, especially as applications become more expensive and sophisticated.

The application became more widely known in May 2021, when the Biden administration emphasized SBOMs in an executive order as a way organizations can boost their cybersecurity. Because of the order, the U.S. government now requires all their software suppliers to provide SBOMs for their products.

As it becomes more common and mandated for federal contracts, it's wise for companies to move toward using SBOMs to keep track of components. They’re quickly becoming an essential requirement for many businesses and industries.

What is a Software Bill of Materials?

The software bill of materials (SBOM) is a formal record, in the form of a list, of all software component parts and software dependencies used in application development and delivery. It details the various relationships. Similar to a bill of materials (BOM) for supply chain and manufacturing, it tracks most software packages' extensive third-party components, including:

• Libraries
• Frameworks
• Modules

Like checking the ingredients label when grocery shopping, the SBOM shows the "ingredients" within a given software product/service. This helps your organization to better assess and mitigate risk, by more fully understanding information like:  

• If a nested component may contains a new vulnerability.
• If a component manufacturer has (in-)adequate vulnerability management practices.

(Related reading: types of vulnerabilities & third party risk management.)

CISA's role in SBOM adoption

CISA, the Cybersecurity and Infrastructure Security Agency,  plays a critical role in molding SBOM adoption and best practices through action. CISA is dedicated to advancing community-led work on SBOMs, convening experts from a range of sectors and working collaboratively with the private sector through existing standards bodies.

SBOMs are a pointed effort by CISA for software transparency. CISA also notes that promoting the usage of SBOM can help enterprises to be more aware of risks associated with different components in their software supply chain.

The agency collaborates with international partners, industry leaders, and other government bodies to assist in SBOM implementation. This partnership guarantees uniform SBOM action across jurisdictions and sectors.

Imporantly, if you sell software to the U.S. Government, by 2025 you'll be required to supply SBOMs. 

(Related reading: the federal effort to automate SBOMs.)

Open source & SBOMs

Since a large portion of modern applications are built with open-source software, ensuring an accurate and up-to-date SBOM is imperative to knowing about what goes into the code you implement.

When working with open-source components, understanding license type is critical. It can be safer to choose those open-source licenses that are widely used, such as MIT and Apache (based on use case), rather than less well known or custom versions. Popular licenses are usually better understood, with less ambiguous terms and a more widespread acceptance within the community.

The risks of using open-source code or proprietary code depends on various factors:

• Although open source does provide transparency and an opportunity for community-driven enhancements, it also makes you, the open-source user, responsible to manage vulnerabilities.
• Using open-source libraries or packages (and even whole projects) may quicken development and cut expenses as benefits. This does depend on being managed properly and adhering to the licensing terms, so make sure you do your due diligence.

An SBOM is used to keep track of these components, which guarantees their proper use and mitigates legal risks and security vulnerabilities.

Required components for SBOMs

Since the federal government mandated SBOMs for all software they use, they created a document in coordination with the National Telecommunications and Information Administration (NTIA) outlining the minimum elements that must be included. NTIA’s minimum components are split into three categories:

• Data fields
• Automation support 
• Practices and processes

Data fields

The SBOM needs to include all the vital data about software components. This includes names of the component, supplier, software version, and any other identifiers. Also, it needs to detail any relationships between dependencies. This enables companies to accurately identify and manage all software components across the software supply chain.

(Read our full explainer on supply chain attacks.)

Automation support

The information in the SBOM is typically used both by multiple departments within an organization and by multiple organizations.

To ensure the documentation is easily used and shared, SBOMs must be machine-readable and capable of automatic generation. This allows organizations to track all the data in the SBOM continuously. NTIA recognizes three delivery formats for compliance:

• Software Package Data Exchange (SPDX) is the primary format for an SBOM inventory list and includes software components, licenses, security references, and copyrights. SPDX is commonly used in the open-source community and by companies across the globe. It's also recognized by the Linux Foundation.
• OWASP CycloneDX uses a lightweight SBOM standard to build a complete list of first- and third-party software components. It documents components such as applications, libraries, containers, files, firmware, operating systems, and frameworks.
• The standard for software identification (SWID) is an XML file created by the International Electrotechnical Commission (IEC) and International Organization for Standardization (ISO). The file contains a list of software components, as well as their patch statuses, installation bundles, and licenses.

Practices and processes

The last element relates to the mechanics of the SBOM. Practices and processes are the operational details that must be included in any contract that asks for them. The key requirements for the practices and processes section include:

Frequency. This should include how often your organization generates new SBOMs. NTIA recommends developing new SBOMs whenever you update a software component or release a new version. Also, you're expected to create a new SBOM if you find an error or learn a new detail about any component of your software that was not included in your initial documentation.

Depth. Your SBOM must include all top-level components and transitive dependencies to comply with NTIA standards. If you cannot include all transitive dependencies in your SBOM, the document must provide instructions on where your customer can find them. Also, you are required to specify why you cannot provide a complete dependency graph, such as because your component has no further dependencies.

Distribution. SBOMs need to be delivered quickly and easy to use. This requirement doesn’t specify how quickly SBOMs should be delivered, but they must be turned in quickly. Also, your SBOM needs to have access permission in place when delivered. Lastly, the requirement states that SBOMs can be either:

• Distributed with each product instance.
• Made available in an easily accessible manner, such as a website.

Access of control. If you have to limit access to your SBOM to specific customers or users, it should specify access control terms. You need to offer allowances for customers that want to integrate SBOM data into their security tools.

Accommodation of mistakes. While SBOMs improve software assurance and reduce software supply chain risk, they’re not perfect. Customers must be tolerant of occasional errors or unintentional omissions, while organizations must be diligent in fixing errors.

Benefits of using SBOMs

The primary advantages of SBOMs include:

Enhanced cybersecurity

As high-profile cyberattacks continue to grow, SBOMs are essential in helping organizations identify components and assess whether they need an update or patch. In the absence of an SBOM, it may be very difficult to determine which components might be vulnerable, as relatively complex software systems can have thousands or more dependencies.

All the features of a compliant SBOM work to provide enhanced cybersecurity. As modern attacks become more disruptive and expensive, organizations maintain integrity by using an SBOM to verify that all components and files it contains are the same ones that were intended.

With an SBOM, companies can find and eliminate vulnerabilities before production. Also, organizations with access to an SBOM can provide proactive vulnerability patching with deeper transparency.

Easier software development

Another benefit of an SBOM is that they save time and money for software engineers. With the list of versions and components in one convenient place, they save time and deliver secure software. Developers can reduce code bloat by finding a suitable component, leading to a more streamlined codebase.

Compliance

SBOMs also help improve licensing compliance by providing detailed information about the licenses associated with each software component and dependency. Organizations can then monitor the legal obligations of the components they use. It offers critical transparency and organization to manage software licenses, helping companies to better:

• Understand their legal obligation.
• Mitigate risks.
• Demonstrate compliance with licensing requirements.

(Related reading: compliance as a service & continuous compliance.)

Best practices for creating & managing SBOMs

Some of the best ways that you can create a compliant and effective SBO include:

Perform regular updates

After creating an SBOM, it’s your responsibility to ensure it remains updated as components change. Bug fixes, code updates, and new features must be tracked across teams and in real-time to ensure your SBOM doesn’t become outdated.

Confirm data integrity

Audit everything in your SBOM to ensure the integrity of the information, including version numbers and licenses.

Flag potential issues

Your SBOM should outline the current state of your application and how your customers can properly secure it. Issues you could discuss include:

• Copyleft licenses
• Known vulnerabilities
• Limitations or bugs in software components

Identify SBOM documents

Your software can have several SBOM documents, so it’s critical that you identify each of them.

For example, you may issue an updated SBOM to correct an error or publicize a new component. Clearly list the latest version so your customers have the most complete, accurate, and up-to-date information about your software.

Leverage SBOMs for the digital age

SBOMs are critical for modern organizations and offer multiple benefits for compliance, security, and monitoring each license agreement's components. Providing your customers with valuable component information will help them fix any potential cybersecurity issues before incurring damage.