Software Bill of Materials (SBOM)

A Software Bill of Materials (SBOM) is a machine-readable list of every component, library and dependency that a piece of software is built from. Each entry comes with metadata about its origin, version and license. An SBOM works like the ingredients list on a food package: it shows exactly what is inside — including transitive dependencies, that is, components pulled in indirectly by another component. It is the core tool for managing risk in the software supply chain and for quickly finding vulnerable parts.

What does an SBOM contain?

The U.S. NTIA (National Telecommunications and Information Administration) described a set of minimum elements — the baseline fields every component in an SBOM should carry. They are:

• Supplier name — who created or identified the component.
• Component name — the name of the software unit.
• Version — points to the specific release, so a vulnerable build can be told apart from a patched one.
• Other unique identifiers — such as Package URL (purl), CPE or SWID tags. They let you map a component unambiguously to vulnerability databases.
• Dependency relationship — which component is included in which, i.e. the dependency tree.
• Author of SBOM data — who generated the document itself (not necessarily the same party as the component supplier).
• Timestamp — the date and time the record was created.

Beyond data fields, NTIA also sets out requirements for automation (generating and sharing the SBOM in a machine-readable format) and for practices and processes (how often to update, how deep to go in the dependency tree, how to handle known unknowns, access control and error handling). In practice an SBOM is often enriched with component checksums (hash) and references to known vulnerabilities (CVE).

What are the SBOM formats? (SPDX, CycloneDX, SWID)

SBOMs are written in standardized formats that a machine can read. Three are widely recognized (including by NTIA):

• SPDX (Software Package Data Exchange) — maintained by the Linux Foundation and standardized as ISO/IEC 5962:2021. It grew mainly out of license compliance and open-source auditing, and it can analyze files and even code snippets. It supports tag-value, JSON, YAML and RDF/XML.
• CycloneDX — maintained by OWASP, with a focus on security and vulnerability management. It has a compact, component-centric data model and built-in support for vulnerability information and VEX (more on it below). It supports JSON, XML and Protocol Buffers.
• SWID (Software Identification Tags) — the ISO/IEC 19770-2 standard, aimed at IT asset inventory and licensing. It works as a unique installation identifier, but on its own it does not show a full dependency tree. That is why security use cases rely mainly on SPDX and CycloneDX.

How is an SBOM generated?

Building an SBOM usually takes three steps and is automated inside the CI/CD pipeline (the automated process for building and shipping software):

1. Component discovery — a tool scans the source code, dependency manifests (e.g. package-lock.json, pom.xml, go.sum) or finished artifacts and container images to list the libraries and packages in use.
2. Metadata collection — gathering versions, licenses, identifiers, checksums and any vulnerability references.
3. Document generation — writing the data out in the chosen format (SPDX or CycloneDX).

SBOMs can be produced at different points: from source, at build time, from a finished binary (binary/analyzed) or at deployment. A build-time SBOM is often the most faithful, because it reflects the dependencies actually wired into the program. Common open-source tools include Syft and Trivy.

Why does an SBOM matter for supply-chain security?

Most applications today rely on open-source components and third-party libraries. These are often multi-level and not directly visible to the team. Without an inventory, an organization does not really know what it runs. And if it does not know, it cannot tell whether a newly disclosed vulnerability affects it.

• Log4Shell (CVE-2021-44228) — a critical vulnerability in the Apache Log4j library, disclosed in December 2021. The hard part was not its existence but figuring out where Log4j was used at all — often as a deeply buried transitive dependency. Companies with an up-to-date SBOM could point to affected systems almost at once, instead of searching everything by hand.
• SolarWinds (2020) — a supply-chain attack in which malicious code was injected into the build process of trusted software (Orion) and shipped through a legitimate update. The incident showed how important verifiable transparency into the origin and integrity of components really is.

In response to such threats, Executive Order 14028 (a U.S. presidential order from May 2021) directed software vendors selling to federal agencies to include an SBOM. NTIA and CISA (the U.S. cybersecurity agency) then produced guidance on minimum elements and formats. That is how the SBOM became a regulatory requirement and a due-diligence item in software procurement.

What is VEX and how does it complement an SBOM?

An SBOM says which components are present. It does not settle whether a given vulnerability can actually be exploited in that product. That gap is filled by VEX (Vulnerability Exploitability eXchange) — a companion document in which the vendor states a vulnerability’s status for its product: not affected, affected, fixed or under investigation.

VEX cuts down on needless alerts. Without it, matching an SBOM against a CVE database also flags components that are present but cannot be exploited in the given product. CycloneDX supports VEX natively; in the SPDX world it is handled through separate companion documents.

SBOMs in vulnerability management and monitoring

In day-to-day security work an SBOM is the source of truth for what is deployed. When a new CVE appears, the team matches component identifiers from the SBOMs of deployed systems and immediately sees what is exposed — without rescanning the whole environment from scratch. For SOC (security operations center) and incident-response teams, this shortens the time from disclosure to prioritization and remediation.

An SBOM complements network-side visibility well. Network telemetry (flows, traffic, fingerprinting) shows what is communicating and how, while the SBOM shows which components the running services are built from. Combining both layers makes it possible to tie active traffic more precisely to specific, potentially vulnerable software, and to spot differences between what was declared and what is actually running.

Limitations and challenges of SBOMs

• Freshness — an SBOM is a snapshot taken at build time. Without automation it quickly goes stale as code and versions change.
• Completeness — components loaded dynamically, statically compiled in, or deliberately obfuscated can be hard to detect. Hence known unknowns — gaps you know exist but cannot fully see into.
• Interoperability — differences between formats and tools make it harder to use SBOMs from many suppliers consistently.
• Scale and distribution — generating, storing, versioning and securely sharing SBOMs across many products needs a real process, not ad-hoc effort.

Learn more

• Zero-Day Exploit — SBOM helps identify affected components when a zero-day exploit targets vulnerable software.
• OWASP Top 10 — SBOM supports tracking dependencies that may contribute to OWASP Top 10 software risks.
• CMDB — A CMDB can complement SBOM data by mapping software components to managed assets.
• PCI-DSS — SBOM helps demonstrate software component visibility needed for PCI-DSS security control reviews.
• SaaS Security Posture Management (SSPM) — SSPM and SBOM both improve visibility into software and dependency risks in cloud services.