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/VULNERABILITY_EXPLORER_GUIDE.md`
|
|
- `docs/VEX_CONSENSUS_GUIDE.md`
|
|
- `docs/modules/vuln-explorer/architecture.md`
|