Notifications
Clear all
Topic starter
18/08/2026 2:20 pm
TL;DR: VEX turns vulnerability data into a machine-readable determination of whether a known issue actually affects a product, helping teams suppress noise, document decisions, and prioritize remediation more consistently, according to FOSSA. The practical shift is from chasing every CVE to governing trust, traceability, and update discipline across SBOM-driven workflows.
NHIMG editorial — based on content published by FOSSA: Practical Guide to VEX in 2026
Questions worth separating out
Q: What breaks when VEX is missing from vulnerability management workflows?
A: Teams are forced to treat every disclosed CVE as equally actionable, which creates alert fatigue, wasted patch effort, and inconsistent risk decisions.
Q: Why do SBOMs need VEX to support real prioritisation?
A: An SBOM shows component inventory, not exploitability.
Q: What do security teams get wrong about not-affected statements?
A: They often assume a not-affected claim is self-validating.
Practitioner guidance
- Define a VEX publishing policy Specify when a determination should be published, who may approve it, which evidence is required, and how updates are versioned when facts change.
- Bind VEX to SBOM ingestion Land VEX statements in the same workflow as SBOM collection so vulnerability relevance is evaluated in the product context where the component actually ships.
- Set trust thresholds for not-affected claims Pre-decide which justification types are acceptable, which require maintainer evidence, and which will be rejected in high-assurance environments.
What's in the full article
FOSSA's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step VEX workflow design for producers and consumers across SBOM, CI/CD, and ticketing systems.
- Format selection guidance for CSAF, OpenVEX, CycloneDX, and SPDX based on audience and tooling maturity.
- Decision criteria for when not-affected claims are trustworthy enough for high-assurance environments.
- Examples of how to publish, update, and trace VEX statements as vulnerabilities move from investigation to remediation.
👉 Read FOSSA's analysis of practical VEX workflows for software producers and consumers →
VEX workflows for AppSec and product security teams?
Explore further
18/08/2026 3:12 pm
VEX is becoming the control plane for vulnerability relevance, not just vulnerability reporting. SBOMs answer what is present, but they do not answer whether a flaw is exploitable in the environment that matters. That distinction is now central to operational risk because teams cannot triage at scale without a decision layer. For practitioners, the lesson is to treat exploitability determinations as governed state, not ad hoc commentary.
A question worth separating out:
Q: Who should be accountable for VEX determinations in a software programme?
A: Accountability should sit with the team that owns product security decisions, but the workflow must include engineering, AppSec, and release governance. Every statement should be attributable to a named approver, time-stamped, and revisited when the product, patch state, or threat landscape changes. Without ownership, VEX becomes stale documentation instead of operational control.
👉 Read our full editorial: VEX is becoming the control layer for vulnerability prioritisation
