What Is an SBOM?
Software supply chains are rife with security risks of all types – from insecure open source components and malware lurking inside proprietary tools to risky configuration code and beyond. Fortunately, there’s one type of solution that can protect against all of these risks: A Software Bill of Materials, or SBOM. By providing comprehensive visibility into the components of a software supply chain, an SBOM plays a critical role in helping organizations get ahead of supply chain security challenges.
Keep reading for a breakdown of what an SBOM is, how it works, why it’s important, and how to generate an SBOM.
In this article:
- Software Bill of Materials: A definition
- Why are SBOMs needed?
- SBOM formats
- How is an SBOM created?
- Why are SBOMs important?
- SBOM examples
- AIBOMs vs. SBOMs
- How to generate an SBOM with Trivy
- SBOMs as the foundation for supply chain security
Software Bill of Materials: A definition
A Software Bill of Materials, or SBOM, is an inventory of all of the components that exist within a software resource, such as third-party libraries or modules. SBOMs can identify components that developers integrated directly into an application by importing them into its source code, as well as dependencies (which aren’t a direct part of an application but that are installed or run when the application is deployed).
In addition to identifying the third-party components associated with an application, SBOMs also typically record data such as which version of each component is in use, what the original source of the component is and which software licensing rules apply to the component.
Why are SBOMs needed?
We’ll say more below about specific compliance requirements and cybersecurity incidents that have made SBOMs important. But for now, suffice it to say that the main reason SBOMs are needed is that they provide a centralized source of visibility into the “ingredients” included in an application.
This is important because many modern applications include components sourced from third parties. Developers might use an open source library to help implement application functionality, for example, or they may install a plug-in developed by an external vendor. Threat actors could leverage any security issues associated with third-party components like these to exploit the application – so having visibility into which third-party software exists in an application is critical for detecting any potential security risks that affect the app.
SBOM formats
An SBOM could be as simple as a text file that lists the components within an application’s software supply chain. However, most SBOMs today use one of the following formal formats:
- SPDX.
- CycloneDX.
- Common Platform Enumeration (CPE).
Each of these formats provides a structured way of recording information about the components within a software supply chain. A comparison of the differences between SBOM formats is beyond the scope of this article, but at a high level, each of the formats works in the same basic way. The differences mostly have to do with variations in syntax and style.
How is an SBOM created?
We walk through an example of creating an SBOM later in this article, but for now, here’s a basic overview of how SBOMs are created.
There are three basic approaches to creating SBOMs:
- Manually listing the components of an application: This is not ideal. Not only does it take a lot of time, but there is also a high risk of overlooking certain components or forgetting to update an SBOM if a component is updated or added.
- Automatically generating an SBOM after building an application: You can do this using tools that scan the application and try to identify its components. This approach is efficient and delivers a relatively high degree of accuracy, but the big drawback is that you won’t know what’s in your software supply chain until your application is complete.
- Automatically generating an SBOM as part of the Software Delivery Lifecycle (SDLC): Using tools that automatically record components within a software supply chain as an application is under development provides maximum visibility from the start of the SDLC. This is the ideal way to create an SBOM, although it’s also the most complicated to implement because it requires integrating SBOM tools directly into your software delivery processes.
Why are SBOMs important?
We said above that SBOMs are important because they provide critical visibility into software supply chains. But to be a bit more specific, let’s discuss some of the key reasons why SBOMs have become so crucial in recent years.
One is the proliferation of zero-day vulnerabilities – meaning known software security flaws that have not yet been patched on affected systems. Zero-day vulnerabilities have been on the rise recently. Since many zero-day vulnerabilities originate within third-party components that developers borrow to write an application, developing an SBOM is critical for determining which vulnerabilities impact the software that your organization is running.
SBOMs also became more important in 2021, when the U.S. federal government issued an executive order requiring certain software vendors who do business with the government to produce SBOMs. Although this mandate, which was in part a response to the SolarWinds software supply chain incident disclosed in late 2020, doesn’t apply to companies that don’t sell to the federal government, it set a key precedent that has pushed organizations of all types to invest in SBOM generation as a standard security best practice.´
SBOM examples
As we mentioned above, most SBOMs use a specific format. You can find examples of SBOMs in different formats within the following public repositories:
(CPE SBOM examples are more challenging to find, but you can read more about the CPE format in this NIST publication.)
As a basic example of what SBOMs include, here’s an excerpt from an SPDX SBOM:
{
"SPDXID" : "SPDXRef-openssl",
"downloadLocation" : "NOASSERTION",
"filesAnalyzed" : false,
"homepage" : "https://www.openssl.org/source/",
"licenseConcluded" : "Apache-2.0",
"licenseDeclared" : "Apache-2.0",
"name" : "OpenSSL",
"versionInfo" : "3.0.4",
"externalRefs" : [ {
"referenceCategory" : "PACKAGE-MANAGER",
"referenceLocator" : "pkg:alpine/[email protected]",
"referenceType" : "purl"
}If you read through this code, you’ll see that it describes a specific software component – in this case, the OpenSSL open source library. It registers information such as the library’s name, home page, the version in use, and the package repository from which it originated. This information would be highly valuable in the event that a security vulnerability involving OpenSSL were announced because it would allow an organization to determine quickly whether their specific implementation was affected.
AIBOMs vs. SBOMs
SBOMs have helped give rise to the concept of the AI Bill of Materials, or AIBOM. An AIBOM records the resources used to develop and deploy an AI application or service. For instance, an AIBOM might list the data sources, AI model, parameters, and training procedures that a team relied on when developing an AI solution. Like the information provided by an SBOM, this data is critical for organizations that need to know whether security issues associated with third-party data sources, AI models, and so on affect any AI applications or services they use.
That said, AIBOMs should not be confused with SBOMs. Currently, AIBOMs remain a looser concept than SBOMs, with less consensus among AI developers regarding exactly which components to include in an AIBOM or how to structure an AIBOM. This may change as AIBOM tooling matures and gaining visibility into AI supply chains becomes more critical for businesses.
How to generate an SBOM with Trivy
As we mentioned, the best way to generate an SBOM is to use a tool that automatically identifies the components within an application. One such tool is Trivy, an open source SBOM tool that supports both the SPDX and CycloneDX formats.
Trivy is quite easy to use. You simply specify which software resource to scan, as well as which SBOM format to use and the name of an output file. For instance, to scan version 3.15 of the Alpine Linux container image and generate an SPDX SBOM, you’d run:
trivy image --format spdx-json --output result.json alpine:3.15
Within seconds, you’ll have an SBOM that looks like this:
"spdxVersion": "SPDX-2.3",
"dataLicense": "CC0-1.0",
"SPDXID": "SPDXRef-DOCUMENT",
"name": "alpine:3.15",
"documentNamespace": "http://aquasecurity.github.io/trivy/container_image/alpine:3.15-f867c1e8-e4f2-47bd-a4e8-23bf49484d01",
"creationInfo": {
"creators": [
"Organization: aquasecurity",
"Tool: trivy-0.49.1"
],
"created": "2024-04-17T13:49:47Z"
},
"packages": [
{
"name": "alpine",
"SPDXID": "SPDXRef-OperatingSystem-4a615561de851cdb",
"versionInfo": "3.15.11",
"downloadLocation": "NONE",
"filesAnalyzed": false,
"primaryPackagePurpose": "OPERATING-SYSTEM"
},
(The SBOM continues and includes about 500 lines in total; the above is just an excerpt.)
Similarly, to create an SBOM for Redis (an open source database and message broker), you could run:
trivy image --format spdx-json --output result.json redis
The output would include data like the following:
{
"name": "libblkid1",
"SPDXID": "SPDXRef-Package-665d25b5b11231c4",
"versionInfo": "2.38.1-5+deb12u1",
"supplier": "Organization: util-linux packagers \[email protected]\u003e",
"downloadLocation": "NONE",
"filesAnalyzed": false,
"sourceInfo": "built package from: util-linux 2.38.1-5+deb12u1",
"licenseConcluded": "GPL-2.0-only AND GPL-3.0-only AND public-domain AND BSD-4-Clause AND MIT AND BSD-3-Clause AND BSLA AND LGPL-2.0-only AND LGPL-2.1-only AND LGPL-3.0-only",
"licenseDeclared": "GPL-2.0-only AND GPL-3.0-only AND public-domain AND BSD-4-Clause AND MIT AND BSD-3-Clause AND BSLA AND LGPL-2.0-only AND LGPL-2.1-only AND LGPL-3.0-only",
"externalRefs": [
{
"referenceCategory": "PACKAGE-MANAGER",
"referenceType": "purl",
"referenceLocator": "pkg:deb/debian/[email protected]%2Bdeb12u1?arch=amd64\u0026distro=debian-12.5"
}
],
"attributionTexts": [
"PkgID: [email protected]+deb12u1",
"LayerDigest: sha256:13808c22b207b066ef43572e57e4fb8c6172e887dd9a918c089a174a19371b7a",
"LayerDiffID: sha256:1f00ff20147800878a4ebc9c283f79149a1dde5cc11d659c69d3a9c0bfeb7d4f"
],
"primaryPackagePurpose": "LIBRARY"
},
{
"name": "libbz2-1.0",
"SPDXID": "SPDXRef-Package-6cd283bb7535431e",
"versionInfo": "1.0.8-5+b1",
"supplier": "Organization: Anibal Monsalve Salazar \[email protected]\u003e",
"downloadLocation": "NONE",
"filesAnalyzed": false,
"sourceInfo": "built package from: bzip2 1.0.8-5",
"licenseConcluded": "BSD-variant AND GPL-2.0-only",
"licenseDeclared": "BSD-variant AND GPL-2.0-only",
"externalRefs": [
{Automated SBOM generation with Trivy
While Trivy can be used to create SBOMs on a one-off basis, you could also integrate Trivy into your SDLC and use it to generate SBOMs whenever a new software resource enters your development pipeline.
This approach not only maximizes efficiency by allowing your team to generate up-to-date SBOMs without any manual effort beyond initial setup of your SBOM tool. It also maximizes visibility and accuracy by ensuring that every change to your software supply chain will trigger a new SBOM, so you’ll always know which third-party components your applications are using.
SBOMs as the foundation for supply chain security
Securing software supply chains has always been important, but the growing prevalence of supply chain attacks makes it more critical than ever to maintain visibility into the components that make up software. SBOMs provide an easy and efficient way to achieve this visibility, which is why any organization that uses third-party software components in any way should be generating SBOMs.
