Consuming VEX at scale: the intake side nobody talks about

We wrote last year about VEX as a producer — telling your customers which CVEs in your product actually matter. That is half the story, and honestly the easier half. The other direction is where the leverage is: you have suppliers too, and every "not affected" statement they publish is triage work you should not be repeating.

The math of ignored VEX

Take a typical mid-size inventory: hundreds of components from upstream vendors and open-source projects, thousands of CVE associations, and a security team that can deeply investigate a handful per week. Suppose your suppliers have already determined that a meaningful share of the findings in their components are not exploitable as shipped — the vulnerable function isn't called, the affected configuration isn't used, a mitigation is built in.

If that determination reaches you as a PDF attachment or a support-portal FAQ, it reaches you never. Your scanner re-flags the CVE, your analyst re-investigates it, and an engineer somewhere re-mutes it — per team, per quarter, forever. Machine-readable VEX exists precisely so that a supplier's exploitability analysis can flow into your triage queue and close findings the way the supplier already closed them.

What intake actually requires

Accepting a VEX document is easy. Making it trustworthy and durable takes more:

1. Provenance. A statement asserting "not affected" is an input to your risk decision, not a command. You need to know who issued it, for which product and version range, and when — and keep the statement attached to the finding it suppressed, so an auditor can trace why a critical CVE shows as resolved.
2. Version awareness. A VEX statement scoped to version 4.2 of a component must not silently suppress the same CVE in 5.0. Statements have to re-evaluate as your inventory moves — which means intake is a pipeline, not an import button.
3. Status transitions. Suppliers revise. "Under investigation" becomes "affected" more often than anyone likes; a good intake process treats a status change as an alertable event, because a downgraded assurance is precisely the thing you want to hear about immediately.
4. Disagreement handling. Sometimes your own analysis contradicts the supplier's. The record should hold both positions rather than letting the last writer win.

This is how VEX intake works in SBOMVault: statements attach to the affected components in your inventory, suppressions carry their provenance, and the affected findings move out of your active queue while remaining fully auditable — nothing is deleted, everything is explainable.

Ask your suppliers for it

The intake pipeline is only as useful as what flows into it, so the final step is contractual: when you request an SBOM from a supplier, request VEX alongside it, in a machine-readable format, updated when their analysis changes. Vendors increasingly have this on the shelf — the ones practicing what this industry preaches are already producing it for their other customers. All you have to do is stop accepting the PDF.