Give every automated fix pull request a traceable chain: the finding it addresses, the person who approved it, the test results at merge time, and the deploy that shipped it. Put identifiers in the pull request, and the trail follows. No special tool is needed.
Why this is worth doing
When something breaks, the first question is what changed. When someone reviews your controls, the first question is how changes get approved. A fix bot generates many changes, so unlinked records pile up quickly. Linking at creation time is far cheaper than reconstructing later.
The chain
| Link | What to capture | Where it lives |
|---|---|---|
| Finding | Identifier, severity, source, date found | Vulnerability record |
| Proposal | Pull request number, bot identity, time opened | Repository |
| Review | Approver, time, comments | Repository |
| Checks | Names and results at merge | Repository and CI |
| Merge | Commit, time, branch | Repository |
| Deploy | Build, environment, time | Pipeline |
| Closure | Re-scan result, date | Vulnerability record |
Each row should hold the identifier of the row before it, so you can walk backwards from a production deploy to the finding.
How to make it automatic
- Template. Give the pull request description a fixed section: finding identifier, category, files touched, checks run.
- Labels. Tag every bot pull request with category and severity labels, so queries are simple.
- Branch names. Use a predictable prefix and include the finding identifier.
- Required fields. A required check can fail when the description lacks the finding link.
- Ticket sync. If you track work in a ticket system, link the ticket from the pull request and close the ticket on merge and re-scan, not on merge alone.
The related post on what a good fix PR description contains covers the template in depth.
What an approver should be able to see
A reviewer deciding quickly needs: the finding and why it matters, the change in plain words, which checks passed, whether the vulnerable code is reachable, and a rollback note. If any is missing, the approval is weaker than it looks.
Handling exceptions and reverts
Link reverts to the original and reopen the finding. Link accepted risk decisions the same way, with owner and expiry. A closed finding with no linked change and no linked exception is a gap a reviewer will find.
Retention
Decide how long to keep these records and where. Repository history persists, but ticket systems and CI logs often expire sooner. Export check results into the pull request or an evidence store at merge time if retention matters for you. Match the period to your own obligations, and ask your compliance lead what applies.
What to avoid saying
Do not claim the process satisfies a named standard unless your assessor has told you so. Describe what you do and show the records. That statement is true and checkable.
Safeguard offers autonomous remediation with fix PRs, off by default and Manual in every category, along with compliance and evidence automation that can help you collect records like these.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a change moves from finding to a gated decision.
Quick check
Is the pull request history enough as a change record?
Often it is the core, but add the finding link and deploy record so the chain runs from detection to production.
Should we close the ticket when the fix merges?
Better to close it after a re-scan confirms the finding is gone, since a merged fix can fail to remove it.
Last reviewed: 19 October 2026.
