SBOM: being able to answer "do we use that?"

In December 2021, Log4Shell was published. What separated teams was not security skill but one very simple question: "do we use log4j anywhere?"

Teams that could answer in ten minutes had patched within a day. Teams that could not spent two weeks looking — grepping repos, asking teams, opening images. And during those two weeks they did not know whether they were being exploited.

An SBOM (Software Bill of Materials) is a list of every component in one specific artefact, with versions and provenance. It exists to answer exactly that question.

What separates an SBOM from a lockfile, and this is where they get conflated:

Answers | "What we declare we use" | "What this artefact contains" | Includes | One ecosystem's packages | OS packages, native libraries, the base image too | Attached to | A commit in source | A built artefact | Lives in | The repo | Beside the artefact in the registry |

The last row matters most and is most often got wrong: an SBOM belongs with the artefact, not in the repo. An SBOM in the repo answers "what this commit declares"; an SBOM beside the image in the registry answers "what is running in production" — and that is the question you need at 2am.

Two formats, and for most purposes which one you pick matters less than having one:

• CycloneDX — leaner, security-oriented, good VEX support. A reasonable default.
• SPDX — an ISO standard, strong on licensing, often required in government contracts.

And one companion artefact few teams produce: VEX (Vulnerability Exploitability eXchange) — a document saying "we have this CVE but it is not reachable, and here is why". It is how you record the conclusion from dependency-risk so the next scan does not ask again.