Because a reachability verdict is a statement about specific code at a specific time. Change a line, add a dependency or update the analyzer and the answer can change. Without the commit, tool version and date, the verdict cannot be reproduced, and an auditor cannot tell which version of your product it describes.
A verdict is a measurement
Think of it like a test result. "Tests passed" means little. "Tests passed on commit abc at 14:02 with runner version 3" is a measurement someone can repeat. The same discipline applies here.
A call path exists or does not exist in a particular program. The program is defined by the source, the build options and the resolved dependencies. All three can move between releases.
What can change the answer
- A code change that adds or removes a call to the vulnerable function.
- A dependency update that changes which version of a library is resolved.
- A build or configuration flag that includes or excludes a module.
- An analyzer update that models a framework better or worse.
- An advisory update that names a different affected function.
Any of these makes an old verdict stale without anyone touching the finding record.
The minimum record
| Field | Why it is there |
|---|---|
| Product and component | So the verdict is about the right thing |
| Commit or build identifier | Reproducibility |
| Build configuration | Different flags, different code |
| Tool name and version | The method matters |
| Analysis type | Static, dynamic or configuration based |
| Result | Path found, none found, or unknown |
| Timestamp | Evidence ages |
| Reviewer | Accountability |
CISA's minimum elements for VEX require timestamps expressed in common international standards, and include fields for when a statement was first issued and last updated. That structure is a useful model even if you do not publish VEX, because it separates "when we first said this" from "when we last confirmed it".
Handling a stale verdict
When a release ships, treat prior verdicts as unconfirmed until the analysis runs again on the new commit. If the result is unchanged, update the last confirmed date and leave the first issued date alone. If it changes, open the finding again and say why.
This is also the best answer to the auditor question "how do you know this is still true".
Where teams slip
- Recording the verdict in a chat message with no commit.
- Overwriting the old result so history is lost.
- Using the scan date as the release date.
- Letting a verdict from a branch stand for the release branch.
A simple rule helps: no verdict without a build identifier, no closure without a date. See when to re-run reachability analysis for triggers, and the same code can get different answers by build.
Quick check
Is the scan date enough?
It helps, but without the commit an auditor cannot tell which code the scan covered.
Should old verdicts be deleted when a new one is made?
No. Keep the history, mark the latest and link the earlier ones.
Safeguard's reachability analysis and evidence automation record the analyzed build and time with each result. You can try the free scan.
Sources
Last reviewed: 19 October 2026.
