SBOM Review: VEX, Quality Profiles and Delivery Checks

A supplier ships a release: a handful of container images, a Helm chart, plus SBOMs and an advisory document. Three questions stand between that package and sign-off. Does what arrived match what the bill of materials claims? Are the reported vulnerabilities actually reachable in the product? And is the SBOM formally good enough to hand to a market surveillance authority? This article walks through a review that answers all three in about twenty minutes instead of half a day of manual work.

Structure first, details second

A release SBOM is rarely a single document. The common shape is a cascade: a release-level document that points via ExternalDocumentRef to component SBOMs, which in turn reference container images. Open that in a text editor and you lose the thread after the second reference.

So the entry point is topology: how many documents hang together, which references dead-end, where does each component sit? In SBOM Lens the Map view answers this with a tree of documents rather than packages. Missing documents show up as placeholders, which in practice is the single most common finding: the supplier sent the release SBOM but forgot the component documents it references. How these cascades are built is covered in detail in SPDX cascades.

Next comes the Conflicts view. It collects packages that appear in more than one version across the cascade. Two versions of the same library in a release are not automatically a defect, but they are almost always worth a question: deliberate isolation, or a forgotten update?

VEX: when the CVE list overstates the case

A scanner reports forty vulnerabilities, the vendor says thirty of them are not exploitable. Who is right? That gap is what VEX addresses, the Vulnerability Exploitability eXchange. A VEX document is a vendor statement about one CVE in one product: affected, not affected, under investigation, fixed. For “not affected” it carries a justification, such as the vulnerable code path never being executed in the product.

Two formats have gained traction. OpenVEX is minimal and JSON-based, CSAF 2.0 is the far more comprehensive OASIS standard used, among others, by Germany’s BSI. SBOM Lens reads both and lays the statements over the component table as a dedicated column, matched by Package URL and CPE, the same identifiers the scanner uses.

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "statements": [{
    "vulnerability": { "name": "CVE-2026-1234" },
    "products": [{ "@id": "pkg:oci/billing@sha256:8a1f..." }],
    "status": "not_affected",
    "justification": "vulnerable_code_not_in_execute_path"
  }]
}

The practical gain lies in the adjacency. Instead of reading a CVE list and an advisory separately, each affected component carries the vendor statement and its justification right next to it. What remains are the cases with no statement at all, and those are exactly what belongs in the follow-up ticket to the supplier.

Measure quality instead of guessing it

An SBOM can exist formally and still be worthless. Without versions, suppliers or checksums, you can neither run a meaningful CVE match nor verify a delivery. Every review therefore needs a quality check, and that check should produce numbers rather than a traffic light based on gut feeling.

Two reference frames are established. The NTIA minimum elements define what an SBOM must contain at minimum: author, timestamp, namespace, components with version and supplier, plus the relationships between them. Germany’s BSI guideline TR-03183-2 goes further and is, in the German-speaking market, the yardstick teams use when preparing for the Cyber Resilience Act.

SBOM Lens checks a loaded document against a fixed set of spec rules covering SPDX 2.x, SPDX 3.0.x and CycloneDX 1.x, and shows coverage rates alongside: how many packages carry a version, a supplier, a checksum, a license. The output is plain numbers, not an invented score nobody can recompute. Teams with their own house rules supply a custom profile as a JSON file and measure every incoming SBOM against it. For why this stops being optional in 2027, see our piece on CRA SBOM requirements.

Delivery check: does the package match the list?

The third question is the one most often skipped: does the delivered archive actually contain what the SBOM says? SBOMs carry checksums per file or artifact. Comparing them is mechanical work, and yet it is rarely automated.

SBOM Lens takes the delivered files and holds them against the checksums in the document. Results fall into five buckets: match, mismatch, missing, unverifiable and extra. The last three are the interesting ones. Missing means the SBOM promises something that never arrived. Extra means a file shipped that nobody declared, which in a regulated environment warrants a serious question. Unverifiable means the SBOM carries no checksum for that artifact at all, a quality defect that often surfaces only here.

On the OCM side there is a counterpart for deliveries, described in OCM Lens. Both tools stay deliberately read-only: they show whether digests and signatures are present and consistent, but do not verify them cryptographically. That belongs in the CLI or the pipeline, where it is reproducible and automatable.

The workflow end to end

For an incoming release this order has proven itself. Load the cascade and check the topology first, so you know whether the package is complete at all. Then read the quality report, because an SBOM with thirty percent version coverage makes every later analysis meaningless. Only then walk the components with the VEX overlay and flag the ones without a vendor statement. Finally run the delivery check against the files that actually arrived.

For your own releases the Diff view joins in: compare two states, export added and removed packages plus version bumps as Markdown, and drop that into the release notes. It replaces the manual work nobody wants to do right before a release.

All of this runs in the browser without a file leaving the machine, and works offline as an installed web app. For teams, a self-hosted instance with a curated catalog is worth the setup: the entry point for any release is then one click away.

Conclusion

SBOM review is not reading, it is reconciling: structure against expectation, CVE list against vendor statement, delivery against checksum, document against minimum requirements. With the right tool that is a twenty-minute task rather than a project. SBOM Lens is freely available under Apache-2.0, and the fastest way in is the built-in example in the viewer. If you want this review step wired into your supplier process or your CI/CD, we help hands-on: Software Engineering at EverBright.

Frequently Asked Questions

What is VEX and why is it needed?

VEX stands for Vulnerability Exploitability eXchange and records the vendor statement about a CVE in a specific product: affected, not affected, under investigation or fixed. For “not affected” it adds a justification. This cuts noise from scanner reports considerably, because unreachable vulnerabilities drop out in a traceable way.

What is the difference between OpenVEX and CSAF?

OpenVEX is a lean JSON format focused on the exploitability statement itself and quick to wire into pipelines. CSAF 2.0 is the broader OASIS standard for machine-readable security advisories, used among others by Germany’s BSI. For everyday review work what matters most is that your tool reads both formats.

What does BSI TR-03183-2 require from an SBOM?

The technical guideline defines requirements for SBOM format and content, including mandatory fields per component such as name, version, supplier and unique identifiers. It goes beyond the NTIA minimum elements and serves, in the German-speaking market, as the practical yardstick for Cyber Resilience Act readiness.

How do I verify that a delivery matches its SBOM?

Through the checksums in the document. Every delivered file is held against its recorded hash, and results fall into match, mismatch, missing, unverifiable or extra. The most telling outcomes are undeclared extra files and artifacts without any checksum, both of which are typical follow-up questions for the supplier.