Every SBOM programme hits the same wall around month four. The platform team has wired up emission, ingestion, and a vulnerability enrichment pipeline. The dashboard now shows 14,000 open findings across the product portfolio, of which roughly 600 are actually exploitable in production. Engineering rejects the queue, security loses credibility, and a programme that should accelerate decisions starts slowing them down. The wall is real, and almost every team underestimates how badly an SBOM without disciplined VEX behaves. Modern enterprise SBOMs, when scored against raw NVD data, produce noise ratios between 20:1 and 40:1. VEX is the mechanism that closes that gap. It is a structured way for the producer of a software artefact to publish a position on each vulnerability that affects a component in their SBOM: not affected, under investigation, affected with a fix available, or fixed. Done well, VEX cuts actionable backlogs by 70-90% within 60 days of rollout, raises programme defensibility, and makes the SBOM a decision-support tool rather than an alert firehose. This post lays out the operating model.
What VEX Actually Says
A VEX statement is a small, signed assertion. For each vulnerability that affects a component in an SBOM, the producer publishes one of four states using either CSAF 2.0 or CycloneDX VEX:
not_affected: the vulnerability is real but does not apply to this product, with a justification.under_investigation: the team is evaluating, with a target date.affected: the vulnerability applies, with optional remediation guidance.fixed: the vulnerability previously applied and a specified version remediates it.
The justification field is what makes VEX defensible. CSAF 2.0 defines a controlled vocabulary of justifications including component_not_present, vulnerable_code_not_present, vulnerable_code_not_in_execute_path, vulnerable_code_cannot_be_controlled_by_adversary, and inline_mitigations_already_exist. Auditors and customers will read these. A VEX feed that says not_affected with no justification is treated as suspect; one with a controlled-vocabulary justification and a signature is treated as evidence.
Where The Noise Actually Comes From
Before authoring VEX, understand the sources of noise. In our analysis of 2.4 million findings across 380 products through 2025, four categories accounted for 86% of the noise.
The largest, at 41%, was vulnerable_code_not_present: the SBOM lists a package, but the specific function or module containing the vulnerable code is not in the build. This is common in large libraries where vulnerabilities affect a single optional module.
The second, at 24%, was vulnerable_code_not_in_execute_path: the code is present but never reachable in this product's deployment. Reachability tools can confirm this for compiled languages with reasonable confidence.
The third, at 13%, was inline_mitigations_already_exist: the product wraps the vulnerable component with controls (input validation, network isolation, sandboxing) that neutralise the issue.
The fourth, at 8%, was component_not_present: the SBOM is wrong; the package is not actually shipped. This indicates an SBOM quality issue rather than a real exposure.
Targeted VEX authoring against these four categories typically eliminates 70-85% of finding volume in the first 60 days.
The Author-Once Pattern
The biggest mistake teams make is treating VEX as a per-product, per-release exercise. The same not_affected justification often applies to the same component across 30 products and 100 releases. Author once, at the component level, scoped to the configuration that justifies it, and apply automatically to every SBOM that matches.
A practical model uses three layers:
- Component-level VEX: applies wherever a given
purlappears with a given configuration assertion (for example "feature flag X is off"). - Product-level VEX: applies only to a specific product but across all releases unless overridden.
- Release-level VEX: pinned to one product version, used sparingly for one-off cases.
Aim for 75% of VEX volume at the component level, 20% at the product level, and 5% at the release level. Programmes that invert this distribution produce VEX volume that scales with releases and become unmaintainable around release 200.
CSAF 2.0 Or CycloneDX VEX
Both formats are credible in 2026. The pragmatic split: use CSAF 2.0 for inter-organisation VEX exchange (vendor-to-customer, ISAC-to-member) and CycloneDX VEX for intra-organisation use embedded inside SBOM documents.
CSAF 2.0 is the standard the FIRST community settled on, has the strongest tooling for cross-vendor exchange, and is the format most enterprise security platforms ingest natively. CycloneDX VEX is the right choice when you want VEX assertions to travel inline with the SBOM as a single signed artefact, particularly for customer-facing transparency feeds where the SBOM and VEX should not drift.
Many programmes emit both: CSAF for the published VEX feed, CycloneDX VEX inline in the customer-facing SBOM. This is more work but matches the dominant ingest patterns in 2026.
Signing And Provenance
Unsigned VEX statements are advisory at best and dangerous at worst. A vulnerability suppressed by an unsigned not_affected assertion looks identical to one suppressed by a forged one. Sign every VEX assertion using the same key chain that signs your SBOMs and AI-BOMs.
Two operational rules. The signer of a VEX statement should be the team that owns the assertion, not the team that publishes it. If the application security team asserts vulnerable_code_not_in_execute_path, that team should sign it; if procurement publishes it, the signature still belongs to AppSec. Second, VEX statements should carry timestamps and an explicit re-evaluation date. A not_affected assertion from 18 months ago is stale by definition.
Measuring The Programme
Three metrics tell you whether the VEX programme is working.
- Coverage ratio: the percentage of recurring findings (those appearing in three or more SBOMs) that have a published VEX position. Aim for 80% within 90 days.
- Suppression accuracy: the percentage of
not_affectedassertions that survive a quarterly sample re-validation. Aim for above 97%; below 95% indicates over-aggressive suppression and erodes trust in the feed. - Finding-to-action ratio: the percentage of remaining un-suppressed findings that result in an action within SLA. A healthy ratio is above 60%; below 30% indicates the noise has moved rather than been eliminated.
Programmes that publish these three metrics internally on a monthly cadence stay disciplined. Programmes that do not drift toward over-suppression, customer trust erosion, and eventual rollback.
How Safeguard Helps
Safeguard makes VEX a first-class operational surface. SBOM ingest pairs every component with the published VEX feed automatically, applying CSAF 2.0 and CycloneDX VEX assertions in the same query path that drives dashboards, policy gates, and customer transparency endpoints. AI-BOM extends VEX to model-level findings so guardrail-protected or sandboxed surfaces can be suppressed with the same vocabulary. Author-once VEX templates apply across products by purl and configuration assertion, and signed attestations preserve the chain from author to publisher. Coverage ratio, suppression accuracy, and finding-to-action metrics are surfaced as programme-level KPIs, so the team running the programme has the same view that auditors and customers will see when they review it.