Module schema

Expand description

OpenVEX 0.2.0 schema types.

Hand-rolled from the OpenVEX 0.2.0 spec (https://github.com/openvex/spec/blob/main/OPENVEX-SPEC.md) and cross-checked against the Go reference implementation (https://github.com/openvex/go-vex/tree/main/pkg/vex). The serde representation must match the spec verbatim; the vexctl merge step in our e2e suite is what catches drift.

Field-level notes:

@context / @id use serde renames because JSON-LD requires the literal @-prefixed keys.
Optional fields use Option<T> + skip_serializing_if = "Option::is_none" so the emitted JSON omits them rather than emitting null. Matches the Go implementation’s omitempty behavior.
version is the OpenVEX document revision counter (integer, starts at 1). NOT the schema version.
Vec<Statement> is always present (the spec allows it to be empty in principle, but our generator errors out before that state).
Product.identifiers / Product.hashes (and same on Subcomponent) use BTreeMap instead of HashMap for deterministic key ordering — easier diffing across runs.

Structs§

Document: Top-level OpenVEX document.
Product: A product the statement applies to. @id is a PURL or any URI; the subcomponent list pinpoints the vulnerable transitive dep.
Statement: One VEX statement — the unit of “I am asserting that vulnerability X has status S relative to product P”.
Subcomponent: A subcomponent of the product — i.e. the actual vulnerable dependency the patch covers.
Vulnerability: Vulnerability identifier. name is the primary ID (we use the GHSA), aliases holds the CVE list.

Justification: VEX justification enum — only required when status = not_affected. Spec lists five canonical values; we expose them all even though socket-patch only emits InlineMitigationsAlreadyExist today.
Status: VEX status. Spec defines exactly these four values.