SBOM Formats, Standards, Requirements, Examples & More
Today’s software is complex. Each modern software application typically includes a large number of open source and commercial components coming from a wide range of sources. According to the 2021 Open Source Security and Risk Analysis report, on average, 75% of codebases are made up of open source software. That’s where an SBOM, or software bill of materials, comes in.
For those new to this topic, be sure to learn the basics of SBOMs and their role in cybersecurity first. Put simply, however, an SBOM is a structured list of components, modules, and libraries that are included in a given piece of software. Think of them like a list of ingredients that evolves throughout the software development lifecycle as you add new code or components.
To ensure the security of the software you create, it is imperative that you maintain a comprehensive list of the components in each release of a software application in order to identify vulnerable and outdated code. You can also use an SBOM to monitor the security of each application post-deployment by identifying the potential impact of new security vulnerabilities on your user-facing applications.
Explore how Google leveraged 100M+ SBOMs to protect their software supply chain.
Are SBOMs Required?
No. SBOMs are not required. At least, not yet. There are some signs that it might become a requirement in the future.
The importance of the SBOM was emphasized in the 2021 U.S. Executive Order to Improve the Nation’s Cybersecurity. The Executive Order directs federal agencies to “publish minimum SBOM standards” and define criteria regarding “providing a purchaser a software bill of materials (SBOM) directly or publishing to a public website.” The Executive Order has had a ripple effect across the industry, as software suppliers that sell to U.S. federal government agencies need to provide SBOMs for the software they deliver. Over time, these standards will spread as companies in other industries begin to mirror the federal requirements in their own software procurement efforts.
We at Anchore believe that generating an SBOM is an important step toward defending against security incidents that use a software supply chain attack method, where an attacker infiltrates a software supplier ‘somewhere in the chain’ to either introduce or uncover an exploitable flaw, and then implements the attack against the end consumer of the software, who has deployed the compromised supplier software element in production.
Learn more about the Executive Order and its implications for FedRAMP →
What is an SBOM Standard?
To facilitate this widespread adoption of SBOMs, several SBOM standards have been developed to provide a unified structure for both generating SBOMs internally and sharing them upstream with end-users and customers. An SBOM standard is a schema designed to provide a common format for describing the composition of software in a structured way that is consumable by other tools, such as vulnerability scanners. CycloneDX and Software Product Data Exchange (SPDX) are the most commonly used standards.
Common SBOM Standards and Formats
CycloneDX
CycloneDX is a lightweight SBOM standard useful for application security contexts and supply chain component analysis. CycloneDX is an open source project that originated in the OWASP community and is guided by a Core Team that provides strategic direction and maintenance of the standard.
The full CycloneDX specification is available online at GitHub or the CycloneDX site.
SPDX
The Software Product Data Exchange (SPDX) is an international open standard (ISO/IEC 5962:2021) format for communicating the components, licenses, and copyrights associated with a software package. The SPDX standard is developed by a grassroots open source project hosted by the Linux Foundation. It draws representatives from vendors, foundations, and system integrators.
A tech team and legal team do the work behind the project. SPDX holds a scheduled monthly status call about their progress.
The full SPDX specification and archives are available on the SPDX site. There’s also an SPDX GitHub repo available.
SPDX vs CycloneDX
There are many opinions on which format – SPDX or CycloneDX – is the best format for specific use cases. Some years ago, there were arguments for using one format if your focus was open source dependencies, or the other if your focus was licensing.
Recently, we have seen the industry move away from specific focuses for SBOM and converge on SBOM formats containing complete and accurate dependency and license details. The two formats differ in how they are constructed, but the data contained within them is functionally the same for many SBOM use cases. For example, at Anchore we support both SPDX and CycloneDX because there is equally strong demand for the two formats.
SBOM Quality and Minimum Elements
There is a definition of the minimum elements that should be included in an SBOM. This document is long and is several years old now. The world of SBOMs has changed dramatically in recent years, and like any technology, the more use it gets, the more it changes to solve real problems.
Rather than speaking of minimum elements, the conversation can switch to SBOM quality, but without an adequate definition of quality. The SPDX and CycloneDX standards are working to ensure future versions of the standards define minimum expectations in a way that ensures every SBOM created has the data needed to be useful to the recipient.
If you are the recipient of an SBOM today, there isn’t an easy way to verify if the document contains the data you need to conduct analysis. By using an SBOM management solution it is possible to ingest the documents then view the results to understand if the data needed exists. If it does not, changes can be requested from the supplier of the SBOM to ensure the SBOM received is correct.
SBOM Examples to Help You Get Started
There are a number of ways to create an SBOM, everything from manually creating the document to running a scanner. The scanner route is much easier than trying to construct a properly formed SBOM by hand. A scanner also gives you the ability to output both SPDX and CycloneDX formats and conduct deep inspections of your software.
For this example, we will use the Syft SBOM scanner. Syft is very easy to use and can output both SPDX and CycloneDX formats. Once Syft is installed, it can be as easy as running
syft -o spdx-json docker.io/library/debian:latestThis will give us an SPDX format JSON SBOM. If we look at the top of the SBOM we can see what an SBOM looks like:
{
"spdxVersion": "SPDX-2.3",
"dataLicense": "CC0-1.0",
"SPDXID": "SPDXRef-DOCUMENT",
"name": "docker.io/library/debian",
"documentNamespace": "https://anchore.com/syft/image/docker.io/library/debian-5b03a9a6-85ff-4f5a-b618-04437c896322",
"creationInfo": {
"licenseListVersion": "3.22",
"creators": [
"Organization: Anchore, Inc",
"Tool: syft-0.93.0"
],
"created": "2023-10-20T15:04:46Z"
},This gives us the SBOM for the Debian container image. Syft can also be run against files or directories, it’s not just for containers.
There is a lot of additional information in the SBOM, but this example shows how easy it can be to generate an SBOM and what the output will look like. We published a blog post on using a number of free tools to generate SBOMs you can read titled How to Generate an SBOM with Free Open Source Tools.
Creating & Managing SBOMs
As SBOMs become increasingly common, more and more tools have sprung up promising to help organizations create their first. Because each use case is different, it’s critical to assess your options and identify the best SBOM solution for your needs before getting started.
With deep expertise in the world of SBOMs, Anchore offers a variety of tools – both open source and enterprise – to help with everything from SBOM generation to SBOM management, analysis and automation. After all, creating an SBOM is only the first step.
What’s next
As SBOMs rapidly gain acceptance, industry leaders have begun to develop approaches for creating, managing, and using SBOMs. While individual development or application teams may store SBOMs in a repository alongside their code artifacts, security teams must maintain a centralized repository of SBOMs across all applications and development teams.
When new vulnerabilities or security incidents arise, security teams and CISOs need the ability to quickly query the SBOMs of all of their software and instantly assess the impact instead of frantically scrambling to get individual assessments from each development team or having to waste valuable time finding and rescanning all of their applications from scratch. In addition, meeting regulatory requirements or compliance standards requires a centralized repository for reporting and other compliance activities.
Anchore Enterprise makes it easy for teams to manage SBOMs for increased security and quicker incident response. The platform provides a comprehensive set of SBOM management capabilities that enable teams to collect, store, analyze, automate, and use SBOMs across the application and software development lifecycles.
Over the course of just a few short years, we have seen the role of SBOMs transition from a “nice to have” to a “need to have” for both development and security teams who have been forced to recognize in a post-Solarwinds world that the software they build is part of a bigger chain that goes beyond the confines of their containers. The use of SBOMs will continue to expand and become the foundational element in securing and managing software supply chains.
