stella-ops.org/git.stella-ops.org
1
0
Fork 0
Code Issues Pull Requests Actions 2 Releases Wiki Activity
Files
02772c7a270a8cf9449d9f482eeb8f79feb2d940
git.stella-ops.org/docs/policy/vex-trust-model.md
StellaOps Bot 7503c19b8f Add determinism tests for verdict artifact generation and update SHA256 sums script 
- Implemented comprehensive tests for verdict artifact generation to ensure deterministic outputs across various scenarios, including identical inputs, parallel execution, and change ordering.
- Created helper methods for generating sample verdict inputs and computing canonical hashes.
- Added tests to validate the stability of canonical hashes, proof spine ordering, and summary statistics.
- Introduced a new PowerShell script to update SHA256 sums for files, ensuring accurate hash generation and file integrity checks.
2025-12-24 02:17:34 +02:00

2.8 KiB
Raw Blame History

VEX Trust Model

This document explains how policy evaluation uses VEX evidence and issuer trust to produce deterministic, explainable outcomes. It focuses on policy posture rather than API details.

Inputs to Trust

Policy decisions about VEX rely on evidence produced by 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 docs/16_VEX_CONSENSUS_GUIDE.md for the conceptual model and docs/modules/excititor/architecture.md + docs/modules/vex-lens/architecture.md 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 is used to preview how changes in VEX trust settings or exception/waiver objects would affect outcomes before promotion. See:

  • docs/api/gateway/policy-exceptions.md (simulation contract)
  • docs/60_POLICY_TEMPLATES.md (policy packs and examples)

References

  • docs/16_VEX_CONSENSUS_GUIDE.md
  • docs/modules/excititor/architecture.md
  • docs/modules/vex-lens/architecture.md