SBOM

An SBOM, or software bill of materials, is a formal, machine-readable inventory of the components that make up a piece of software, including open-source libraries, their versions, suppliers, identifiers and dependency relationships. In application security it answers a deceptively simple question: what exactly is inside this application, and is any of it affected by a known vulnerability or license problem?

The idea mirrors the bill of materials used in manufacturing, where a parts list lets a carmaker trace a faulty component to every affected vehicle. In cybersecurity, an SBOM lets a software producer or customer find every product that contains a vulnerable library within minutes instead of weeks.

What an SBOM contains

An SBOM lists components and their relationships, not source code. Each entry identifies a package precisely enough to match it against vulnerability databases and license records. The widely used minimum elements, defined in the United States in 2021, set the baseline that most SBOM programs follow.

Mature SBOMs add cryptographic hashes of each component, license identifiers in SPDX notation and, for containers, the operating system packages of the base image. The Package URL (purl) has become the most practical identifier because it encodes the ecosystem, name and version in one string, such as pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1.

Depth and completeness determine how useful an SBOM is. A document that lists only the direct dependencies declared by developers may name twenty packages, while the full transitive tree of the same application can contain several hundred. Good SBOMs also state their own limits, for example by marking parts of the tree as unknown or incomplete rather than silently omitting them.

SBOM formats and standards

Two formats dominate SBOM practice, and most tools can produce and consume both. They differ mainly in origin and emphasis, while both support JSON and cover dependencies, licenses and hashes.

Regulation has made SBOMs a procurement and compliance requirement. United States Executive Order 14028 of 2021 pushed SBOMs into federal software purchasing, and the EU Cyber Resilience Act requires manufacturers of products with digital elements to draw up an SBOM as part of their technical documentation.

SBOM types across the software lifecycle

An SBOM describes software at a particular point in its lifecycle, and the point matters. A list generated from source manifests can differ substantially from what actually ships in a container image or runs in production.

For most producers, a build SBOM generated in the CI pipeline for every release is the best default, because it reflects the exact artifact customers receive and can be signed and stored alongside it.

SBOM compared with SCA, VEX and provenance

An SBOM is data, not a security control by itself. Its value appears when other processes use it, and several neighboring concepts are often confused with it.

VEX (Vulnerability Exploitability eXchange) is especially important in practice. An SBOM matched against vulnerability feeds produces many hits, and a VEX statement such as “not affected, vulnerable code not in execute path” lets customers focus on the findings that matter.

Building a useful SBOM program

• Generate SBOMs automatically in CI for every release, never by hand.
• Include transitive dependencies and operating system packages, since most vulnerable code arrives indirectly.
• Store SBOMs with version history in a platform that continuously matches them against new vulnerability data.
• Request SBOMs from suppliers in contracts and check them for completeness, not only presence.
• Pair SBOMs with VEX statements so customers can tell exploitable from merely present vulnerabilities.

Open-source generators such as Syft, Trivy and cdxgen produce SBOMs from source trees, container images and file systems, while platforms such as OWASP Dependency-Track ingest SBOMs and alert on new vulnerabilities as they are published. The decisive step is organizational: someone must own the alerts and decide on remediation.

Common weaknesses include vendored or copied code that no package manager knows about, statically linked libraries invisible to scanners, and stale SBOMs that describe last year’s build. The OWASP Top 10 has long included a category for vulnerable and outdated components, and an accurate SBOM is the foundation for addressing that risk, though it fixes nothing on its own.

The idea in brief

Modern applications are assembled from hundreds of ready-made parts written by other people. An SBOM is the ingredient label for software: a precise list of every part, which version it is and who made it.

When a problem is discovered in one ingredient, organizations with good labels can find every affected product immediately. Organizations without them have to open every box and look inside, which takes far longer while attackers are already busy.

A practical scenario

When the Log4Shell vulnerability in the Log4j logging library became public in December 2021, a hospital IT department had to determine which of its roughly 300 applications were affected. For in-house systems, the team already stored build SBOMs in a dependency tracking platform; a single search for log4j-core versions below 2.15.0 returned eleven affected services within minutes.

For vendor products without SBOMs, the team spent more than two weeks sending questionnaires and scanning servers. Afterward, the hospital added a contract clause requiring an SBOM and VEX statements with every software delivery, and the next major library vulnerability was triaged across all suppliers in two days.