Why vulnerability review needs evidence history

A scanner result is not the same as a review record. For readiness, teams need retained context showing what was found, who reviewed it, what decision was made, what remediation happened, and when.

Scanner exports show findings at a point in time. They often do not preserve product-version context, ownership, rationale, remediation state, and review history.

That missing context matters later when a team needs to explain whether a finding affected a release and how the decision changed.

Vulnerability handling is already spread across the tools teams use to ship software.

Across product releases, scattered evidence becomes stale or hard to reconstruct. A closed ticket may not show which product version was reviewed, which SBOM record informed the decision, or whether remediation updates were preserved.

Useful evidence follows the risk review, not just the first finding.

A review record should keep enough context to make decisions understandable after handoffs and releases.

Teams need concise rationale, not mystery statuses. These examples are decision context only and do not imply a formal VEX workflow.

A remediation trail should show ownership, state changes, blocked work, updates, and final decision context. This lets release and compliance reviewers see whether an item is merely detected, actively handled, or ready for a next decision.

From 11 September 2026, CRA reporting obligations for actively exploited vulnerabilities and severe incidents apply. This guide is not legal advice; teams should confirm reporting duties with counsel and official guidance.

CRA Ledger keeps vulnerability review, ownership, SLA pressure, remediation updates, and retained evidence connected to the product version.

A practical review pass should answer these questions without relying on one person remembering the ticket history.