Vulnerability Exploitability eXchange

VEX is a structured way to communicate whether a product is affected by a reported vulnerability. It helps consumers distinguish scanner matches from assessed product status without discarding the original finding.

Indian Hill Labs statements follow the status and minimum-content model in CISA's Minimum Requirements for VEX. The serialized format and profile are identified in each release record.

Status model

VEX statements may communicate:

Status	Meaning
Affected	The product is affected and remediation or mitigation information may apply
Not affected	Evidence supports that the affected condition is not present or exploitable in the product
Fixed	The identified product version or artifact contains the applicable fix
Under investigation	Analysis is incomplete; no non-applicability conclusion should be inferred

Evidence and rationale

A not-affected conclusion should include a rationale such as vulnerable code not present, vulnerable code not in the execute path, vulnerable code cannot be controlled by an adversary, or an existing mitigation prevents exploitation. The rationale must be supported by analysis appropriate to the artifact.

At minimum, an Indian Hill Labs VEX record identifies the document and statement, product or artifact, vulnerability, status, status timestamp, and authoring identity. Not affected statements include a machine-readable justification and human-readable impact statement; affected statements include an action statement when remediation or mitigation is known.

VEX is scoped. A statement for one digest, version, architecture, or configuration may not apply to another. Material changes or new vulnerability information require reassessment.

Consumer use

Consumers should evaluate the VEX statement alongside the SBOM, scan results, product configuration, deployment context, and their own risk requirements. A VEX status does not grant authorization or transfer operational risk ownership.