No. A vulnerability scanner finds components with known vulnerabilities. VEX records an author's statement about whether a given vulnerability affects a given product. VEX has no discovery function and, by CISA's own description, may be incomplete. You need both, in a fixed order: scan first, then apply VEX.
What each one does
A scanner or SCA tool compares your components against vulnerability data and reports matches. It is broad and cheap, and it over-reports, because a version match does not prove that vulnerable code is used.
VEX indicates the status of a product or component with respect to a vulnerability. CISA describes a common use as saying the software is or is not affected. It says nothing about vulnerabilities nobody has written a statement for.
Where each fails alone
Scanner alone: large queues, many findings that are not exploitable, and no way to record why you ignored them in a form others can reuse.
VEX alone: no coverage of new CVEs until someone writes statements, and no way to check that the statements match what you actually run.
The combined workflow
- Generate or collect an SBOM for the product.
- Scan to produce findings.
- Apply VEX statements from the supplier, matching by identifier.
- Keep findings without a VEX answer in the normal queue.
- For findings you triage yourself, write your own statement or note, and record the reason.
Treat absence correctly
CISA says VEX does not imply a default status. So when a scanner reports a finding and no VEX statement mentions it, the finding is still open. Never read missing as safe.
A small example
A scanner reports ten findings in a product. The supplier's VEX file covers six: four not_affected, one fixed, one affected. After applying it, you close four, plan one upgrade, apply one action statement, and still triage the remaining four. The queue went from ten to six without losing any rigour, provided you checked the four not_affected claims.
What to look for in tooling
Tooling that ingests VEX should show the document, version and justification beside each suppressed finding, so a reviewer can undo a decision. Ask also whether it re-opens findings when a new document version changes a status.
Safeguard's SBOM and dependency scanning and reachability analysis address the scanner side of this, and a free scan is available at https://gold.safeguard.sh/scan.
Where the confusion comes from
VEX is often introduced with SBOMs, and both are described as ways to reduce noise. That makes people think VEX is a scanner feature. It is a data format. Scanners may read it, and some may produce it, but the format itself finds nothing.
A useful test is to ask what happens on day one with no existing statements. A scanner still produces a result. VEX produces nothing. That is the reason scanning stays first in any workflow.
Quick check
If my scanner shows nothing, do I still need VEX?
VEX would not add anything. It only annotates findings that exist.
Sources
Last reviewed: 19 October 2026.
