Software Bill of Materials (SBOM): An Overview
How can you defend against software supply chain security risks – meaning security problems that originate in third-party software resources that your business uses or depends on?
A key part of the answer is to generate a Software Bill of Materials, or SBOM. By systematically listing the components that exist within each application, as well as the dependencies that the application requires to run, SBOMs provide the crucial visibility that businesses need to detect and react to software supply chain security risks. In addition, SBOMs can in some cases help to address compliance requirements and provide assurances to customers and partners that your business takes supply chain security seriously.
Keep reading for an explanation of what an SBOM is, how SBOMs work, why they matter and how to generate an SBOM.
What is an SBOM?
A Software Bill of Materials, or SBOM, is a list of all of the components and dependencies (proprietary and open source) that an application uses. SBOMs also often include version details of each component and dependency, which is important because security problems often affect only specific versions of software.
SBOMs are typically formatted in a specific way, and they can usually be represented as XML or JSON files. That said, the exact nature of an SBOM varies depending on which SBOM standard – such as CycloneDX, SPDX or SWID – teams choose to record and structure SBOM information. But, despite minor differences, all SBOM formats focus on making it easy to determine at a glance what “goes into” each application that a business uses.
Why are SBOMs important?
SBOMs are the only way to systematically keep track systematically of an application’s components and dependencies. By extension, they provide the information necessary to determine whether any components or dependencies are subject to security risks.
SBOMs are also important because in some cases, they may be required by regulators or customers. For example, in 2021 the U.S. federal government announced plans to require SBOMs from vendors that do business with government agencies, as part of an effort to ensure that agencies have visibility into the software they depend on.
On top of this, even if SBOMs aren’t strictly required by your customers, partners or regulators, generating them is a great way to show that you take software supply chain security seriously. SBOMs give external stakeholders the peace of mind that comes with having visibility into software components and dependencies and the ability to determine whether third-party software places them at risk.
SBOMs vs. manual software component management
You could, of course, try to track components and dependencies manually by asking developers to list them upon request or attempting to track this information informally within documentation. However, the problems with this approach are that:
- It’s not systematic: It’s easy to forget to note an important dependency or component when you lack a systematic process for defining and formatting this information.
- It’s hard to share: Informal information about software components is difficult to share with regulators, auditors, partners and customers because they may not have access to the locations where you store the information. They may also be unsure how to interpret it.
SBOMs address both of these problems by providing a systematic, standardized way of defining what goes into each application that your business uses. When you make SBOM generation a standard part of your application delivery process, you minimize the risk of forgetting to note important software supply chain information. You also make the information easily shareable with any stakeholder who needs to access it.
SBOM Example
An SBOM is made up of a list of the various open source and proprietary components that exist within a piece of software. As noted above, the lists are typically structured using XML or JSON, which makes it possible to break the SBOM into different sections and define not just application components, but also metadata associated with them.
For example, here’s a simple SBOM file in JSON format that conforms with the CycloneDX SBOM standard:
{
"$schema": "http://cyclonedx.org/schema/bom-1.2a.schema.json",
"bomFormat": "CycloneDX",
"specVersion": "1.2",
"version": 1,
"metadata": {
"tools": [
{
"vendor": "cyclonedx",
"name": "cyclonedx-php-composer",
"version": "dev-master"
}
],
"component": {
"bom-ref": "pkg:composer/cyclonedx/cyclonedx-php-composer-demo@dev-master",
"type": "application",
"name": "cyclonedx-php-composer-demo",
"version": "dev-master",
"group": "cyclonedx",
"description": "demo of cyclonedx/cyclonedx-php-composer with a pinned version of laravel/framework",
"purl": "pkg:composer/cyclonedx/cyclonedx-php-composer-demo@dev-master"
}
},
"components": [
{
"bom-ref": "pkg:composer/asm89/stack-cors@1.3.0",
"type": "library",
"name": "stack-cors",
"version": "1.3.0",
"group": "asm89",
"description": "Cross-origin resource sharing library and stack middleware",
"licenses": [
{
"license": {
"id": "MIT"
}
}
],
"purl": "pkg:composer/asm89/stack-cors@1.3.0",
"externalReferences": [
{
"type": "distribution",
"url": "https://github.com/asm89/stack-cors.git",
"comment": "As detected by composer's `getSourceUrls()` (type=git & reference=b9c31def6a83f84b4d4a40d35996d375755f0e08)"
},
{
"type": "distribution",
"url": "https://api.github.com/repos/asm89/stack-cors/zipball/b9c31def6a83f84b4d4a40d35996d375755f0e08",
"comment": "As detected by composer's `getDistUrls()` (type=zip & reference=b9c31def6a83f84b4d4a40d35996d375755f0e08 & sha1=UNDEFINED)"
},
{
"type": "website",
"url": "https://github.com/asm89/stack-cors",
"comment": "As set via `homepage` in composer package definition."
},
{
"type": "issue-tracker",
"url": "https://github.com/asm89/stack-cors/issues",
"comment": "As set via `support.issues` in composer package definition."
},
{
"type": "distribution",
"url": "https://github.com/asm89/stack-cors/tree/1.3.0",
"comment": "As set via `support.source` in composer package definition."
}
]
},
]
}
The first main stanza of this SBOM defines metadata associated with the SBOM itself, such as the SBOM standard and formatting being used. Then, the SBOM includes a “components”: section, which is where the “meat” of the SBOM exists. The components section lists the specific packages that are included in the application in question, as well as related data such as package URLs, websites, licensing information and even the location of issue trackers.
Using this information, developers, IT engineers, security teams, DevOps teams and DevSecOps teams would be able to identify not just which dependencies and components exist within the software to which the SBOM applies, but also where those components came from and where they can find more information about them.
SBOM tools
You can read through an SBOM manually to find this information. Or, you can take advantage of various tools that help to parse and visualize SBOM files. Note, though, that most SBOM tools are designed to work only with a specific SBOM standard, so you’ll need to be sure you choose tools compatible with your SBOM’s standards and formatting. For example, if you want CycloneDX-compatible tools, you can find a list of open source and proprietary options on the CycloneDX website.
SBOM tools and how to generate an SBOM
The most efficient way to generate an SBOM is to take advantage of SBOM tools that automatically track the components and dependencies of each application, along with their versions, then report that information in a standardized SBOM format, such as CyloneDX, SPDX or SWID.
Using SBOM tools, you can make SBOM generation an automated part of your CI/CD process. SBOM tools can automatically scan every new application build or package to determine whether the application’s components have changed, ensuring that your SBOMs are kept continuously up-to-date.
For more tips on creating and working with SBOMs, check out our article on SBOM management best practices.
