VEX Documents: Validate Exploitability Claims

VEX expresses product status for a specific vulnerability

VEX document validation starts by reading the statement as a bounded claim: an issuer asserts a vulnerability status for an identified product at a point in time. VEX is designed to reduce false-positive remediation when a component appears in inventory but cannot be affected in the shipped product’s implementation or configuration.

CISA VEX minimum requirements describe core elements including document metadata, product, vulnerability, status, and—for a not-affected claim—a justification. The OASIS CSAF 2.0 VEX profile represents status with fields such as known_affected, known_not_affected, fixed, and under_investigation.

Status is not severity, exploitation probability, or local business risk. It also is not timeless. A supplier may learn new facts, a product configuration may change, or an earlier product identifier may have matched the wrong artifact. Preserve the original assertion, validation result, and later revisions independently.

Parse the statement without losing product relationships

Validate the format and schema first, then resolve product identifiers to the exact supplier, product, edition, version, architecture, build, package, and distribution channel. A syntactically valid VEX record that maps to the wrong product branch is operationally invalid.

This is an authored, abbreviated CSAF-style illustration—not a supplier advisory:

{
  "document": {"category": "csaf_vex", "tracking": {"id": "VEX-2026-041", "revision_history": []}},
  "vulnerabilities": [{
    "cve": "CVE-2026-0000",
    "product_status": {"known_not_affected": ["CSAFPID-0001"]},
    "threats": [{"category": "impact", "details": "Vulnerable code is not reachable."}]
  }]
}

Preserve issuer, document ID, initial release, current revision, status, product identifier, vulnerability identifier, justification, impact statement, action statement, references, signature or delivery provenance, and the hash of the retrieved document. Reject silent overwrites: revisions should remain diffable.

Validate identity, justification, evidence, and freshness

First establish provenance. Retrieve from an authenticated supplier channel or advisory distribution point, verify signatures where supported, and ensure the issuer is authorized to speak for the identified product. A copied JSON document in a ticket is not equivalent to a supplier publication.

Then test the justification. “Component not present” calls for artifact or SBOM inventory evidence. “Vulnerable code not reachable” requires build, configuration, call-path, or architecture evidence. “Inline mitigation already exists” requires confirmation that the mitigation is enabled and effective in the shipped and deployed product. Treat vague statements as unresolved, not automatically false or true.

Finally, check time. Compare the statement’s revision with the current supplier advisory, CVE record, affected-version range, fixed release, and your deployed artifact. The CVE lifecycle and records explains why identifiers and descriptions can change after initial publication.

Keep supplier status separate from local remediation state

Store the supplier’s status unchanged, then add a local assessment. Local fields should cover deployment presence, reachability, exposure, exploitation evidence, business consequence, compensating controls, remediation owner, deadline, and confidence. Do not rewrite known_not_affected to fixed, or treat a supplier’s fixed status as proof that the fixed build is deployed.

Use CVSS EPSS and KEV prioritization for questions VEX does not answer. A known-affected product may be low exposure locally, while a disputed not-affected claim may deserve urgent validation if exploitation is active and consequence is high.

Automation may suppress a finding only when product matching is exact, provenance is trusted, the status and justification meet policy, and the document is current. Time-box suppression and preserve the rule that made it. Human review is appropriate for ambiguous product trees, generic rationales, conflicting advisories, or high-consequence assets.

Operate VEX as a revisioned intelligence feed

Discover documents from supplier-advertised locations, validate schemas, verify provenance, retain hashes, compare revisions, resolve product identities, and publish ingestion health. Measure unmatched products, stale statements, unsupported statuses, missing justifications, conflicts, and suppressions approaching expiry.

A missing VEX statement means unknown, not affected. An under_investigation status requires an owner and next-check time. A revoked or superseded document must invalidate dependent automation. Keep an audit trail from raw supplier document through normalization, match decision, local assessment, and ticket action.

Test with authored fixtures that cover valid claims, wrong product versions, conflicting revisions, absent justifications, invalid signatures, and status changes. Clearly label those fixtures as simulations; do not present them as supplier intelligence.

Build one explainable VEX decision end to end

Next step: choose one current vulnerability in a product with an available VEX statement. Preserve the source document, map its product identifier to one deployed artifact, validate the justification, compare the latest advisory and CVE record, and document whether the local finding is remediated, monitored, accepted, or still under investigation.

Have a second analyst reproduce the result from the evidence record. If they cannot explain why a finding was suppressed without trusting a hidden automation rule, the VEX pipeline is not yet defensible. The durable outcome is faster triage with bounded claims, traceable product identity, expiring decisions, and visible uncertainty.