VEX Trust Model

Audience: policy authors and security engineers configuring how Stella Ops weighs VEX (Vulnerability Exploitability eXchange) evidence during release gating.

This guide explains how the Stella Ops Policy Engine consumes VEX evidence and issuer trust to produce deterministic, explainable verdicts. It focuses on policy posture — the trust signals and knobs you control — rather than API mechanics. For the underlying ingestion and correlation model, see the references at the end.

Inputs to Trust

Policy decisions about VEX rely on evidence produced by the VEX ingestion and correlation layers:

Raw observations and provenance (issuer, timestamps, signatures, content hashes)
Normalized tuples (status, justification, scope) emitted by VEX ingestion
Linksets that correlate multiple sources without merging them
Consensus view (when enabled) that summarizes the current effective status and conflicts
Issuer registry / directory that defines trust tiers and verification rules per tenant

See the VEX Consensus Guide for the conceptual model, and the Excititor and VEX Lens module dossiers for implementation details.

Principles

Provenance-first: VEX is stored and referenced as evidence; policy never “rewrites” upstream statements.
Conflicts are first-class: disagreements remain visible; policy chooses a posture for gating and explainability.
Deterministic evaluation: given the same evidence set and policy pack, evaluation must produce identical results (ordering, timestamps, digests).

Trust Signals Used by Policy

Typical signals include:

Issuer identity: stable provider IDs and (when present) cryptographic identity assertions.
Verification status: signature validity, certificate chain, transparency proof availability (offline-compatible).
Trust tier / weight: tenant-configured tiering (e.g., vendor/distro/internal) and weighting used for precedence.
Freshness / staleness: evidence age relative to time anchors; stale evidence can be down-weighted or gated.
Scope fit: whether the VEX statement’s scope matches the evaluated artifact/environment.

Policy Knobs (Posture)

Common policy knobs are expressed as rules rather than hard-coded behavior:

Require cryptographic verification for certain tiers (or for all not_affected gating).
Define how to treat conflicts (e.g., block on high-tier disagreement, or downgrade to under_investigation).
Set staleness budgets for offline snapshots and how they affect acceptance of not_affected.
Define which justifications are acceptable for suppressing a finding (and whether reachability evidence is required).

Simulation (What-if Analysis)

Policy simulation previews how changes to VEX trust settings or exception/waiver objects would affect outcomes before promotion: