Implementing an SBOM: Generation, VEX and Continuous Monitoring

This article is about putting SBOMs into practice — generating, storing and acting on them. For the exam-level overview of what an SBOM is and why it matters, see the companion article linked at the end.

Where to generate one

The generation point determines what the SBOM actually contains, and getting this wrong is the most common implementation mistake.

From source. Scanning the repository and its manifest files. Easy, and it reflects declared dependencies rather than what was actually built — transitive dependencies resolved at build time may differ.

At build time. Generated by the build system from what it genuinely pulled in. The most accurate for a compiled artefact, and the right default.

From the binary or container image. Analysing the finished artefact, including operating system packages in the base image. Catches everything that ships, including components no manifest mentions.

The practical answer for containerised software is both: a build-time SBOM for the application layer and an image scan for the base layer, because the base image usually contributes more components than the application does.

Generate on every build, not periodically. An SBOM that does not correspond to a specific released artefact cannot answer the question you will ask it.

The formats

SPDX — an ISO standard originating in the Linux Foundation, strong on licensing as well as security, widely accepted for compliance purposes.

CycloneDX — an OWASP project designed for security use cases, with good support for vulnerability data and for describing services and dependencies between them.

Both are machine-readable and broadly interconvertible. Choose based on what your consumers and tooling expect rather than on technical merit; many organisations produce both.

The minimum useful fields are supplier, component name, version, unique identifier such as a PURL or CPE, dependency relationships, the SBOM author and a timestamp.

Storage and distribution

An SBOM that nobody can find when a vulnerability is announced has failed at the only moment it mattered.

Store it alongside the artefact in the registry, tied to the exact version and digest. Sign it, so consumers can verify it corresponds to the artefact and has not been altered. Keep SBOMs for every version still deployed anywhere, not just the current one — the vulnerable version is usually the one still running in production somewhere.

Make them queryable. The operational requirement is to answer "which of our systems contain this component at this version" in minutes, across every product and deployment. That means a searchable index, not a folder of JSON files.

VEX

The piece that makes SBOMs usable rather than overwhelming.

A Vulnerability Exploitability eXchange document states whether a known vulnerability in a listed component actually affects the product. The status values are: not affected, affected, fixed, and under investigation.

The problem it solves is real. An SBOM lists a vulnerable library, so every customer raises a ticket — but the vulnerable function may never be called, or the affected code path may be unreachable in your configuration. Without VEX, the supplier answers the same question hundreds of times and customers chase findings that do not apply.

A "not affected" status must carry a justification: component not present in the execution path, vulnerable code not invoked, inline mitigation already exists, and so on. That justification is what makes it credible.

Consuming supplier SBOMs

The other half, and the one organisations neglect.

Ask for an SBOM in procurement, and specify the format and the delivery mechanism in the contract rather than as an aspiration. Require it per release, not once at purchase.

Ingest supplier SBOMs into the same index as your own, so a vulnerability search covers purchased software as well as software you wrote. Reconcile them against what you actually deployed. And treat a supplier unable to produce an SBOM as a risk indicator in its own right — it suggests they do not know what is in their product either.

Making it operational

The workflow that turns the inventory into a control: a vulnerability is published, you query the index for affected component versions, you identify every affected product and deployment, you check whether a VEX statement applies, you prioritise using exposure and exploitability rather than CVSS alone, and you remediate.

Automate the query step. If answering the first question takes a person a day, the SBOM programme will be abandoned after the second incident.

Limitations worth stating

An SBOM is an inventory, not an assessment — presence is not exploitability, which is what VEX addresses. It does not cover dynamically loaded components or things fetched at runtime. Accuracy depends entirely on the generation method. And it says nothing about the quality or maintenance status of what it lists.

What to remember

Generate at build time and from the image, on every build, tied to the artefact digest and signed. SPDX suits licensing and compliance, CycloneDX suits security tooling. Store them queryable, for every version still deployed. VEX states whether a listed vulnerability is actually exploitable and is what keeps SBOM output manageable. Demand SBOMs from suppliers contractually and index them alongside your own.

Related reading: SBOM explained · Supply chain security · Vulnerable software