7503c19b8f
- 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.
54 lines
2.8 KiB
Markdown
54 lines
2.8 KiB
Markdown
# 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`
|