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.
26 lines
1.0 KiB
Markdown
26 lines
1.0 KiB
Markdown
# VEX Integration with Vulnerability Explorer
|
|
|
|
The Vulnerability Explorer and triage surfaces treat VEX as first-class evidence: operator decisions should be explainable, replayable, and linked to provenance.
|
|
|
|
## Triage View Expectations
|
|
|
|
- Show effective VEX status alongside policy outcome and reachability/impact signals.
|
|
- Make conflicts visible and navigable (issuer list, trust tiers, verification state).
|
|
- Provide deep links from the triage view into VEX evidence (raw observations/linksets) and to policy explain traces.
|
|
|
|
## Filtering and Lanes
|
|
|
|
VEX evidence commonly affects:
|
|
|
|
- Default lane placement (e.g., `MUTED_VEX` vs `ACTIVE`)
|
|
- Whether a finding is actionable, needs exception, or can be shipped
|
|
- Staleness warnings for offline snapshots
|
|
|
|
The Explorer must remain “quiet by default, never silent”: VEX-based suppression should be reversible and auditable, not a destructive delete.
|
|
|
|
## References
|
|
|
|
- `docs/20_VULNERABILITY_EXPLORER_GUIDE.md`
|
|
- `docs/16_VEX_CONSENSUS_GUIDE.md`
|
|
- `docs/modules/vuln-explorer/architecture.md`
|