An auditor usually picks a vulnerability from your population, then asks you to show the trail: when it was detected, who triaged it, what you decided, the change that fixed it, and proof it cleared. Gaps in any link become questions. Build the trail once, in a consistent format, and sampling gets easy.
The population comes first
Auditors do not choose from what you hand them. They ask for a complete list, often an export from your scanner or tracker over the audit period, then sample from it. If your export is partial, the sample is unreliable and you may be asked to rerun it. Know where the full list lives and how it is generated before the audit starts.
The trail, link by link
Take a made up example: a high severity advisory affects a library in one of your services.
- Detection. An alert fires. Evidence: the alert record with a date. GitHub documents that Dependabot alerts appear when a new vulnerability is added to its advisory database or when your dependency graph changes.
- Triage. Someone looks, judges impact and picks a priority. Evidence: a ticket with an owner and a comment on exposure.
- Decision. Fix now, schedule, or accept. Evidence: the ticket status and, for acceptance, an exception record.
- Change. A pull request upgrades the package. Evidence: the PR, its review and its checks.
- Release. The fix ships. Evidence: a deploy record or release tag.
- Verification. A rescan shows the alert closed. Evidence: scan result or alert closed timestamp.
Put the ticket number in the PR title and the PR link in the ticket. Then one click moves between them.
Where trails break
| Gap | What the auditor sees | Fix |
|---|---|---|
| No triage note | Alert closed with no human reasoning | Require a one line note |
| Fix PR with no link back | Cannot tie fix to alert | Template field for ticket id |
| Alert auto closed | Unclear if code changed | Record the version before and after |
| Fix after policy deadline | Exception | Open an exception when you miss, not afterwards |
| Dismissed as not used | Unsupported claim | Attach the reasoning or call graph evidence |
Prepare a sample packet before you are asked
Pick three recent closed vulnerabilities and assemble the trail yourself. If one takes an hour to reconstruct, your tooling or habits need work. This is a cheap dry run, and it tends to expose the missing link, usually the rescan.
A note on false alarms
Some alerts are real but not reachable in your code. That is a legitimate decision, but it has to be recorded with evidence, such as why the vulnerable function is not called. A bare "not affected" dismissal will get probed.
Try it yourself
Open the demo and see how reachability analysis trims a long alert list down to what matters. Notice which findings would deserve a full trail and which a short note.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard's dependency scanning, reachability analysis and compliance and evidence automation can keep the detection, decision and rescan records together. Free scan: https://gold.safeguard.sh/scan.
Quick check
Can I give the auditor a curated list of vulnerabilities?
Give the complete population for the period. The auditor selects the sample, not you.
What if the fix came after my policy deadline?
Record it as an exception with the reason and the date. Hiding it is worse than missing it.
Sources
Last reviewed: 19 October 2026.
