Every piece of software is built on a thousand invisible foundations.
A Software Bill of Materials is a complete inventory of every component, library, and dependency that makes up a software system. Like an ingredient list for software, it reveals the invisible foundations beneath every application.
Modern software doesn't exist in isolation. A single application may depend on hundreds of packages, each with their own dependency trees. Every import statement is a trust decision. Every dependency is an attack surface.
The graph you see represents a typical mid-sized application. Each node is a package. Each edge is a dependency relationship. The deeper you go, the less visibility most teams have into what they're actually shipping.
On December 9, 2021, the world learned about CVE-2021-44228 -- a critical remote code execution vulnerability in Apache Log4j, a logging library embedded in millions of Java applications. Organizations scrambled to determine: Are we affected?
Without an SBOM, answering that question required manually auditing every application, every server, every container image. With an SBOM, it's a database query.
A vulnerability scan cross-references every component in your SBOM against known vulnerability databases -- the National Vulnerability Database (NVD), OSV, GitHub Advisory Database. Each component is classified:
1 {
2 "spdxVersion": "SPDX-2.3",
3 "dataLicense": "CC0-1.0",
4 "SPDXID": "SPDXRef-DOCUMENT",
5 "name": "sbom-application-v3.2.1",
6 "documentNamespace": "https://sbom.day/spdx/app-v3.2.1",
7 "packages": [
8 {
9 "SPDXID": "SPDXRef-Package-libcrypto",
10 "name": "libcrypto",
11 "versionInfo": "3.1.2",
12 "supplier": "Organization: OpenSSL Foundation",
13 "downloadLocation": "https://github.com/openssl/openssl",
14 "licenseConcluded": "Apache-2.0",
15 "checksumValue": "sha256:a3f2b8c91d...",
16 "externalRefs": [
17 {
18 "referenceType": "cpe23Type",
19 "referenceLocator": "cpe:2.3:a:openssl:openssl:3.1.2:*"
20 }
21 ]
22 },
23 {
24 "SPDXID": "SPDXRef-Package-zlib",
25 "name": "zlib",
26 "versionInfo": "1.2.13",
27 "licenseConcluded": "Zlib",
28 "checksumValue": "sha256:d7e4c10f..."
29 },
30 {
31 "SPDXID": "SPDXRef-Package-log4j",
32 "name": "log4j-core",
33 "versionInfo": "2.14.1",
34 "licenseConcluded": "Apache-2.0",
35 "vulnerabilities": [
36 "CVE-2021-44228",
37 "CVE-2021-45046"
38 ]
39 }
40 ]
41 }An SBOM is expressed in standardized formats: SPDX (ISO/IEC 5962:2021) and CycloneDX (OWASP standard). These machine-readable manifests enable automated analysis across entire software supply chains.
The regulatory landscape is shifting. The EU Cyber Resilience Act (CRA) mandates SBOMs for all products with digital elements sold in the European market. US Executive Order 14028 requires SBOMs for all software sold to the federal government. These are not recommendations -- they are legal requirements.
Every line in this manifest is a declaration of provenance. Every checksum is a seal of authenticity. Every license reference is a legal obligation. This is the future of software transparency.