Security evidence usually travels in five hops: a scanner produces a finding, a tracker records the decision, a fix or exception changes the state, a verification confirms it, and a retained record is sampled by an auditor. Each hop has an owner, and records most often break at the handoffs between teams.
The five hops
| Hop | What is produced | Typical owner | Common break |
|---|---|---|---|
| 1. Detect | Scan result with date, target and version | Platform runs it | Results expire with pipeline log retention |
| 2. Decide | Ticket with severity and chosen response | Product security | Decision made in chat, never written down |
| 3. Act | Fix pull request or approved exception | Service owner | Exception has no approver or expiry |
| 4. Verify | Rescan showing the issue gone | Product security | Fix merged, nobody rescans |
| 5. Retain | Stored, access controlled copy | Compliance | Evidence kept in personal folders |
Think of it as a relay. The record has to be handed over cleanly each time, with identifiers that link the pieces together.
Link the hops with one identifier
The cheapest improvement is a shared key. Put the ticket number in the pull request title, and the pull request link in the ticket. An auditor who samples one item can then follow the chain from detection to verification in minutes rather than asking three teams.
NIST SP 800-218 task RV.2.1 gives the example of using existing issue tracking software to record each vulnerability, and RV.2.2 includes updating records of risk responses and approved exceptions. PO.4.1 adds recording security check approvals, rejections and exception requests in the workflow and tracking system. Together they describe this same chain.
Who touches the record, and how
Not everyone should be able to edit it. SSDF PO.4.2 gives the example of permitting only authorized personnel to access gathered information and preventing alteration or deletion. A practical version: engineers can add to a ticket, product security can change its state, and nobody can delete history. Compliance gets read access.
Fixing the common breaks
- Retention. Check how long your pipeline keeps logs. If it is shorter than your audit period, export scan results to storage you control.
- Decisions in chat. Add one rule: if a decision is made in chat, the author pastes it into the ticket the same day.
- Exceptions. Require approver, reason and expiry as mandatory fields.
- Verification. Make the rescan a required closing step for the ticket.
- Storage. Pick one shared location and name it in the evidence register.
Try it yourself
Click through it at your own pace, or open it full screen. Follow one finding and note which hops leave a record you could show later.
How Safeguard relates
Safeguard covers dependency and SBOM scanning, reachability analysis, fix pull requests (off by default, every category on Manual) and compliance and evidence automation, so several hops can produce records in one place. A free scan shows the first hop on your own repository.
Quick check
Which hop do auditors care about most?
They sample across hops, but gaps between hops draw questions. Be ready to show a complete chain for any single finding they pick.
Do we need to keep every scan result?
Keep what covers your audit period and supports your decisions. Agree the retention rule with compliance rather than guessing.
Sources
- NIST SP 800-218, Secure Software Development Framework 1.1, tasks PO.4.1, PO.4.2, RV.2.1 and RV.2.2.
Last reviewed: 19 October 2026.
