VEX Consensus and Issuer Trust

This document consolidates the VEX concepts Stella Ops relies on: ingesting upstream VEX without rewriting it, correlating evidence across sources, and producing a deterministic, explainable “effective” status for a component-vulnerability pair. It is for operators, security managers, and auditors who need to understand how VEX evidence flows into a release verdict.

Scope

• VEX ingestion and provenance (what is stored and why)
• Correlation (linksets) versus consensus (effective status)
• Issuer trust and offline operation

This is not an API reference; module dossiers define concrete schemas and endpoints.

Vocabulary (Minimal)

• VEX statement: a claim about vulnerability status for a product/component (for example: affected, fixed, not_affected, under_investigation).
• Observation: an immutable record of a single upstream VEX document as received (including provenance and raw payload).
• Linkset: a deterministic correlation group that ties together statements that refer to the same (vulnerabilityId, productKey) across providers.
• Consensus decision (effective VEX): the platform’s deterministic result after policy rules evaluate available VEX/advisory/reachability evidence.

Observation Model (Link, Not Merge)

Stella Ops treats upstream VEX as append-only evidence.

An observation records:

• Provenance: tenant, provider/issuer identity, receive timestamps (UTC), signature status, and content hash.
• Raw payload: stored losslessly so auditors and operators can retrieve exactly what was ingested.
• Derived tuples: extracted (vulnerabilityId, productKey, status, justification?, version hints, references) used for correlation and UI presentation.

An observation is never mutated. If upstream publishes a revision, Stella Ops stores a new observation and records a supersedes relationship.

Linksets (Correlation Without Consensus)

Linksets exist to make multi-source evidence explainable without collapsing it:

• Group statements that likely refer to the same product-vulnerability pair.
• Preserve conflicts (status disagreements, justification divergence, version range clashes) as first-class facts.
• Provide stable IDs generated from canonical, sorted inputs (deterministic hashing).

Linksets do not invent consensus; they only align evidence so downstream layers (Policy/Console/Exports) can explain what is known and what disagrees.

Consensus (Effective Status)

The effective VEX status is computed by policy evaluation using:

• Correlated VEX evidence (observations + linksets)
• Advisory evidence (observations/linksets from Concelier)
• Optional reachability and other signals

Key properties:

• Deterministic: the same inputs yield the same output.
• Explainable: the decision includes an explanation trace and evidence references.
• Uncertainty-aware: when critical evidence is missing or conflicts are unresolved, the result can remain under_investigation instead of implying safety.

Aggregation-Only Guardrails (AOC)

To avoid hidden rewriting of upstream data, the platform enforces:

• Raw-first storage: upstream payloads are stored as received; normalized projections are derived but do not replace raw data.
• No merge of sources: each provider’s statements remain independently addressable.
• Provenance is mandatory: missing provenance or unverifiable signatures are surfaced as ingestion failures or warnings (policy-driven).
• Disabled verification is untrusted: when a bootstrap/local/offline site explicitly disables VEX signature verification, observations may be retained for audit continuity, but they must be labeled unverified and cannot satisfy strict allow gates.
• Idempotent writes: identical content hashes do not create duplicate observations.
• Deterministic outputs: stable ordering and canonical hashing for linksets and exports.

Issuer Directory and Trust

Issuer trust is a first-class input:

• Issuers are identified by stable provider IDs and, where applicable, cryptographic identity (certificate chain, key id, transparency proof).
• The issuer directory defines which issuers are trusted per tenant/environment and how they are weighted/accepted by policy.
• Offline sites carry required trust material (roots and allowlists) inside the Offline Kit so verification does not require network access.

Console Integration

The Console uses these concepts to keep VEX explainable:

• VEX views show provider provenance, signature/issuer status, and snapshot timestamps.
• Conflicts are displayed as conflicts (what disagrees and why), not silently resolved in the UI.
• The effective VEX status shown in triage views links back to underlying observations/linksets and the policy explanation.

See docs/UI_GUIDE.md for the operator workflow perspective.

Anchor-Aware Mode (v1.1)

Anchor-aware mode enforces cryptographic attestation requirements on VEX proofs used for allow decisions.

VexProofGate Options

Strict Anchor-Aware Preset

For production environments requiring maximum security:

var options = VexProofGateOptions.StrictAnchorAware;
// Enables: RequireVexAnchoring, RequireRekorVerification,
//          RequireSignedStatements, RequireProofForFixed
// Sets: MinimumConfidenceTier=high, MaxAllowedConflicts=0, MaxProofAgeHours=72

Metadata Keys

When passing VEX proof context through policy evaluation:

Failure Reasons

VEX Change Events

Excititor emits deterministic events when VEX statements change, enabling policy reanalysis.

Event Types

Conflict Detection

Conflicts are detected when multiple providers report different statuses for the same vulnerability-product pair:

Event Ordering

Events follow deterministic ordering:

1. Ordered by timestamp (ascending)
2. Conflict events after related statement events
3. Same-timestamp events sorted by provider ID

Integration with Policy

Subscribe to VEX events for automatic reanalysis:

subscriptions:
  - event: vex.statement.*
    action: reanalyze
    filter:
      trustScore: { $gte: 0.7 }

See Excititor Architecture for full event schemas.

Offline / Air-Gap Operation

• VEX observations/linksets are included in Offline Kit snapshots with content hashes and timestamps.
• Verification workflows (signatures, issuer trust) must work offline using bundled trust roots and manifests.
• The Console should surface snapshot identity and staleness budgets when operating offline.

Grey Queue and Unknown Mapping

When VEX correlation produces inconclusive results, observations are routed to the Grey Queue for monitoring or manual adjudication.

Mapping to OpenVEX Status

Uncertain observations preserve OpenVEX spec alignment:

VEX Conflict Types

The Grey Queue surfaces VEX-specific conflicts:

Deterministic Conflict Detection

Conflicts are detected via structured comparison:

1. Same vulnerability, same product, different status → VexStatusConflict
2. VEX not_affected + confirmed reachability → VexReachabilityContradiction
3. Multiple issuers, equal trust, opposite conclusions → TrustTie

Console Behavior for Grey Queue

When displaying Grey Queue items:

• Show the observation state badge (e.g., “Pending” or “Disputed”)
• Display all conflicting sources with provider identity
• Surface the reanalysis fingerprint for reproducibility
• List pending triggers awaiting data
• Provide action buttons for manual resolution

Offline Grey Queue

In offline/air-gap mode:

• Grey Queue state is included in Offline Kit snapshots
• Manual adjudications are recorded locally and synced on reconnection
• Staleness budgets apply to pending determinations
• Conflict detection works with cached issuer trust data

Related Docs

• docs/modules/excititor/architecture.md
• docs/modules/vex-lens/architecture.md
• docs/ARCHITECTURE_OVERVIEW.md
• docs/OFFLINE_KIT.md
• docs/modules/policy/determinization-api.md
• docs/UI_GUIDE.md