Link every finding to one ticket, every ticket to the pull request that fixes it, and every pull request to a review and a rescan result. An auditor can then follow one finding from discovery to verified closure without asking anyone to explain it.
The chain
- Finding: the scanner's record, with advisory id, component and detection date.
- Ticket: owner, priority, due date, status history.
- Pull request: the change, the reviewer, the passing checks.
- Merge and deploy: when it reached production.
- Rescan: proof that the finding is gone.
Each link needs a stable id that the next record stores.
How to wire it
| From | To | How |
|---|---|---|
| Finding | Ticket | Store the ticket key on the finding, and the finding id on the ticket |
| Ticket | Pull request | Put the ticket key in the branch name or title, and link the pull request on the ticket |
| Pull request | Review | Require review through branch protection so the approval is recorded |
| Pull request | Deploy | Record the commit or release identifier on the ticket at deploy time |
| Deploy | Rescan | Trigger a scan after deploy and attach the result to the ticket |
What auditors usually want to see
They sample items from a population and look for the whole chain on each one. For background on sampling, see how auditors sample evidence. A missing link, such as a fix with no review, is the kind of gap that becomes a finding of their own.
Common gaps
- Commits that fix a problem but reference no ticket.
- Tickets closed with no verification.
- Findings fixed by upgrading a different package that happens to remove the issue, with no note on why it vanished.
- Ticket history that shows only a shared bot account.
Automate the glue
A small piece of automation can post the pull request link on the ticket when the branch is pushed, set the status to In review, and move to Verified when the rescan passes. Keep a record of each automated step, as described in what audit trail security automation should keep.
Try it yourself
Open the demo and follow how a pull request is checked by a gate before merge. That gate result is one of the records in your chain.
Click through it at your own pace, or open it full screen.
Quick check
What is the simplest way to link a pull request to a ticket?
Put the ticket key in the branch name or pull request title, and make your tooling link them in both directions.
Why add a rescan to the chain?
It shows the finding is actually gone, which is stronger evidence than a merged change.
Safeguard supports compliance and evidence automation and fix pull requests (off by default, every category on Manual). Try a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
