SBOM and supply chain

What an SBOM actually is

A Software Bill of Materials is a formal, machine-readable inventory of every component in a piece of software — direct dependencies, transitive dependencies, and often the OS packages baked into your container image. The mental model is the ingredient label on food: not marketing copy, but the literal list of what’s inside, in a format a machine can parse and a regulator can audit. Two standards dominate in practice: SPDX (an ISO standard, ISO/IEC 5962) and CycloneDX (from OWASP, built security-first). Both express the same core facts — component name, version, and a unique identifier called a purl (package URL, e.g. pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1) — plus a cryptographic hash so you can prove the artifact wasn’t swapped.

The single property that makes an SBOM worth generating is that it captures the transitive graph, not just the top level. When you npm install express, you pull in dozens of packages you never named; a real application’s dependency tree routinely runs to several hundred or a thousand nodes. The vulnerabilities that hurt almost always live in that buried majority — Log4j was four levels deep — which is exactly where a human reading package.json cannot see them. An SBOM flattens that whole graph into a list you can query: “does any version of log4j-core appear anywhere in this build?” becomes a one-line lookup instead of a multi-day archaeology dig.

The non-obvious rule: an SBOM is generated at build time, per artifact, not written by hand. A hand-maintained dependency list is stale the moment someone bumps a lockfile, and stale is worse than nothing because it lies with confidence. The SBOM is an output of the build, pinned to a specific image digest, so it describes exactly the bytes you deployed — not what the README claims you deployed.

Why “are we affected?” is the whole point

An SBOM has no value sitting in a bucket. Its value is realized when a new vulnerability is published and you feed it into a scanner that matches each component’s purl against a CVE feed. This is the difference between inventory and detection: the inventory tells you what you have; the scan tells you which of it is now known to be dangerous. Because new CVEs are published every day against components you froze months ago, the match has to be continuous — a vulnerability that was clean at build time becomes critical the day its CVE drops, and your stored SBOM is what lets you reach back and find it without rebuilding or re-grepping anything.

This is also where prioritization enters, because a real scan against a thousand-node tree returns dozens of hits and you cannot patch them all this week. CVSS — the Common Vulnerability Scoring System — gives each CVE a 0–10 base score, a vendor-neutral severity that’s comparable across teams. But the base score is deliberately worst-case and context-free: it assumes the vulnerable code is reachable and the asset is exposed. The senior move is to layer CVSS’s environmental and temporal metrics — is this component actually on a reachable path? is the asset internet-facing? does an exploit exist in the wild? — on top of the base score. A 9.8 base CVE in a dev-only build tool you never ship is lower real risk than a 7.5 in your internet-facing auth service. The SBOM tells you where the component is, which is precisely the context that turns a raw score into a real priority.

The other half: provenance and trust

Knowing what you ship is only half the supply-chain problem. The other half is trusting that the component you pulled is the one its author actually published — and that question got urgent after attacks like SolarWinds (2020), where malicious code was injected into the build pipeline so the signed, official artifact itself was poisoned, and Codecov and the event-stream npm hijack, where a legitimate package was taken over and a malicious version pushed. In every case the dependency name and version looked correct. An SBOM would have told you that you were running that package; it would not have told you the package had been tampered with upstream. That gap is what provenance closes.

Provenance is verifiable, tamper-evident metadata answering where did this artifact come from, from which source commit, built by which pipeline? — cryptographically signed so it can’t be forged after the fact. SLSA (Supply-chain Levels for Software Artifacts, pronounced “salsa”) is the framework that grades how trustworthy that provenance is, in levels: roughly, L1 means provenance exists, L2 means it’s signed by the build service, and L3 means the build ran in a hardened, isolated environment that the producer can’t tamper with. The combined posture is the goal: an SBOM so you know your components, provenance so you trust they’re authentic, and a patch SLA — like the timelines NIST SP 800-40 prescribes — so a known-bad component gets remediated on a clock instead of whenever someone notices.