What is an SBOM?
A software bill of materials (SBOM) lists what a piece of software is built from: every open-source and commercial component, its version, its supplier and how the components depend on each other. Most modern applications are largely assembled from third-party libraries, and each of those pulls in further libraries of its own, called transitive dependencies. An SBOM makes that hidden layer visible in a format tools can search, much as an ingredients label lets a shopper check a product for one allergen.
What an SBOM contains
A 2021 NTIA report, written in response to U.S. Executive Order 14028, set out minimum elements for an SBOM: supplier name, component name, version, other unique identifiers, dependency relationships, the author of the SBOM data and a timestamp. In practice, entries also carry identifiers such as a package URL (purl) or CPE name, file hashes and license information.
Two formats dominate. SPDX, from the Linux Foundation, is also published as the international standard ISO/IEC 5962. CycloneDX, an OWASP project, was designed with security use cases in mind. Both can be written in JSON. SBOMs are usually generated automatically at build time by software composition analysis or dependency scanning tools, so a new one comes with every release.
Example: answering the Log4Shell question
When Log4Shell (CVE-2021-44228) was disclosed in December 2021, organizations had to find every product containing Apache Log4j 2 versions 2.0-beta9 through 2.14.1, often buried several dependencies deep. An SBOM entry like this one answers the question with a search instead of weeks of emails to vendors:
{"type": "library", "group": "org.apache.logging.log4j", "name": "log4j-core", "version": "2.14.1", "purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1"}
Matching the SBOMs of every application against vulnerability feeds turns each newly published CVE into a list of affected products almost immediately.
How organizations use SBOMs
- Vulnerability response: match components against CVE data and the CISA Known Exploited Vulnerabilities catalog.
- Procurement and vendor risk: require suppliers to deliver an SBOM with each release, in the RFP and in the contract.
- Asset management: track which software, and which components inside it, the organization runs.
- License compliance: spot components whose licenses conflict with how a product is distributed.
A listed vulnerable component is not always exploitable, because the vulnerable function may never be called. Vendors can publish a VEX (Vulnerability Exploitability eXchange) statement saying whether a product is actually affected.
Limits of an SBOM
An SBOM is only as good as the tool and process that generated it, and one that is not regenerated with each release goes stale. It describes contents; it does not prove the code is safe, that it came from the vendor unaltered or that the build was clean. Code signing and signed build provenance answer those questions. Because an SBOM reveals exactly which components a product runs, vendors often share it with customers under agreement rather than publishing it.
SBOM on the CompTIA Security+ exam
SBOMs fit SY0-801 objective 4.2, asset management, where an SBOM is one of the security requirements written into a request for proposal and the purchase contract, and objective 4.6, where dependency scanning in an automated build pipeline produces one with each build. Wording such as quickly determine which applications include the vulnerable library or a list of every component in the vendor's product points to an SBOM. Distractors include an asset inventory or CMDB, which tracks systems rather than what is inside the software; SAST, which examines your own code; code signing, which proves who published the software; and an SLA, which sets service levels.