Continuous SBOM Monitoring and VEX: Answering the Question After Release

A build-time scan tells you what was known to be vulnerable on the day you shipped. The question that arrives later — a new advisory lands, and are we affected — is a different one, and answering it requires knowing what is in every artefact currently deployed, not what was in the one you scanned.

The gap between build-time and continuous

Scanning in the pipeline, as described under software composition analysis, catches vulnerabilities known at build time. It cannot catch vulnerabilities disclosed afterwards, and nothing about the artefact changes when they are.

So an application built clean six months ago may now contain three critical vulnerabilities, with no build, no commit and no alert. The only way to know is to hold the inventory of what was shipped and re-evaluate it as new advisories appear.

That is the function: a repository of SBOMs for every component and version in the estate, continuously matched against vulnerability data, generating notifications when something previously clean becomes affected.

The practical test is the one every organization failed during the last few large dependency incidents: how long does it take to list every deployed application containing a given library at a given version? With continuous SBOM monitoring it is a query. Without it, it is days of investigation while the exploitation window is open.

What makes the inventory usable

Three properties, and missing any one degrades it badly.

Per-version, per-deployment. Knowing that "the payments service uses this library" is not enough — you need to know which version is running in production right now, which may differ from the current build. That requires the SBOM to be published at build and associated with the deployment.

Complete, including transitive dependencies. The components that cause incidents are typically several levels down and appear in no manifest a human wrote.

Component identifiers that match advisory data. Package URLs identify library components far more precisely than the older naming scheme, for the matching reasons covered under CPE. Mismatched identifiers produce both silent misses and a queue of false positives.

VEX

The piece that makes the output workable, and the one most worth knowing because it is relatively new and increasingly required.

A Vulnerability Exploitability eXchange document is a machine-readable statement from a supplier about whether a specific vulnerability actually affects a specific product. The vulnerable component may be present and the vulnerable code path may be unreachable, in which case the honest answer is "not affected," and a VEX document says so with a reason.

The defined statuses are the exam-relevant part: not affected, with a justification such as the vulnerable code never being executed or not being present in the build; affected, with remediation advice; fixed, identifying the version containing the fix; and under investigation, which is a legitimate interim answer.

The value is enormous at scale. A large product may contain dozens of components with advisories that do not apply to how it uses them. Without VEX, every customer investigates each one independently and reaches the same conclusion the vendor already reached. With it, the assessment is published once and consumed automatically.

The caveat is that a VEX is an assertion by the supplier, not proof. "Not affected" from a vendor with a poor track record deserves the same scepticism as any other vendor claim, which is part of the assessment described under supply chain security.

Making the queue survivable

Continuous monitoring generates a continuous stream, and an unfiltered stream is ignored within a month.

Apply VEX first, which removes the items that do not apply. Then prioritise by exploitability rather than severity — probability data and known-exploited catalogs, as under EPSS — and by exposure, since an internet-facing service and an internal batch job with the same component carry different risk.

Route the remainder to the team that owns the component with a due date rather than to a central security queue, and track age rather than count. A rising median age of open findings is the indicator worth reporting, in the sense described under security metrics.

Regulatory pressure is pushing this from good practice toward requirement, with SBOM provision increasingly expected in procurement and in sector regulation, so the inventory is becoming something customers ask for rather than something you keep for yourself.

Exam angles

Know that build-time scanning cannot detect vulnerabilities disclosed after release, and that continuous SBOM monitoring of deployed artefacts is what answers "are we affected" quickly. Know the SBOM as the inventory and VEX as the supplier's machine-readable exploitability assertion, with statuses of not affected, affected, fixed and under investigation. Recognize package-level identifiers as necessary for accurate matching, and VEX plus exploitability data as what makes the finding queue workable.