An SBOM lists what you ship. A VEX says what actually affects you.

For every component that ends up in what you ship, an SBOM records a name, the version your lockfile actually resolved to, an identifier other tools agree on (a package URL, or purl), and the licence where one could be resolved. That is the whole idea. The value is in the fact that a second tool, written by someone else, can read it without a conversation.

It is worth generating for one practical reason. When an advisory lands on a Friday afternoon, the question is not academic: do we ship this component, at this version, anywhere. A current SBOM turns that into a lookup. Without one it is an afternoon of grepping lockfiles across repositories, and the answer tends to arrive after the decision had to be made. The second reason is that somebody asks. Procurement questionnaires, vendor security reviews and a growing number of regulations expect a machine-readable component list in a standard format, and expect it to match the artifact you actually shipped.

Two limits are worth knowing before you hand one to a reviewer. A dependency declared in a manifest format the scanner does not parse is absent from the document, and absence is reported as unread rather than as clean. And the dependency graph asserts only the edge it can prove, which is that the root application depends on every resolved component. The tree between components is left unstated rather than invented, because a graph that guesses at its edges is worse than one that omits them.

Somebody has to answer that question, and without a document the answer gets re-derived by every team that reads your SBOM. VEX (Vulnerability Exploitability eXchange) is the answer written down. Per product and vulnerability it carries one of three statements: affected, not_affected, or under_investigation. Vulkro emits it as OpenVEX 0.2.0 or as a CycloneDX analysis document, both from the same verdicts, so it lines up with whichever SBOM you handed over.

A hand-written VEX is a spreadsheet of judgements, and it starts ageing the moment someone refactors. The verdicts here come from the reachability pass the scanner already runs. A not_affected statement is emitted only where the forward closure from your entry points contains no call into the vulnerable symbol, and the document carries that reason: the justification is vulnerable_code_not_in_execute_path, and the impact statement names the package the claim was made about. An affected statement cites the call chain wherever the call graph could reconstruct one, and labels it as static call-graph reachability rather than as a confirmed exploit, because that is what it is.

The conservative half matters more than the confident half. Absence of a reachability signal maps to under_investigation, never to not_affected. Where the reachable and unreachable signals genuinely conflict, affected wins: an over-claimed not_affected forwarded to an auditor is the dangerous direction, while an over-claimed affected only prompts an upgrade.

vulkro compliance-pack writes a directory that maps findings onto the control identifiers of a framework: a manifest, a summary, a flat finding-to-control CSV, one JSON file per control, and a control-by-control HTML table for the deeper frameworks. vulkro cra-bundle runs that same pack and staples it into one zip alongside the CycloneDX and SPDX SBOMs, the OpenVEX document and a self-contained readiness one-pager.

Every file is generated locally and each control file cites the findings and endpoints it was built from, so a reviewer can follow a claim back to a file and a line rather than taking a summary on trust. What the bundle is not is stated on its own front page: readiness evidence, not a conformance attestation.