Record the advisory link, the version you ran, whether you were affected, what you did, who did it, and the dates of receipt and completion. Add the reasoning if you decided not to act. Seven fields in a ticket are enough for an auditor or a customer to follow.
Why bother
Fixing a dependency takes minutes. Proving later that you did, and when, takes much longer if nothing was written down. Customers and auditors ask questions such as "when did you learn of the issue and how quickly did you respond". A note made at the time answers it.
GitHub's documentation for Dependabot alerts says a dismissal comment goes on the alert timeline and can be used as justification during auditing and reporting. The same idea applies to any advisory you handle, whatever the source.
The seven fields
| Field | Example content |
|---|---|
| Source | Advisory ID and link, or announcement URL |
| Received | Date and time you first saw it, and through which channel |
| Exposure | Did you run an affected version, where, direct or transitive |
| Assessment | Reachable or not, internet facing or not, and how you know |
| Action | Upgraded to a named version, applied a workaround, replaced, accepted |
| Owner | Person or team responsible |
| Closed | Date of completion and the verification step |
A worked outline
A short entry might read: "Advisory linked above. Received 19 October via announce list. Library appears in two services at an affected version, one direct, one transitive. Both internet facing. Upgraded both to the patched release, deployed 20 October, verified by rescan. Owner platform team."
If the advisory did not apply, write that: "Library not present in any repository as of 19 October, checked against the SBOM inventory." That sentence is evidence too.
When you decide not to act
Add the reasoning and a review date. Examples: the feature is disabled, the vulnerable code is not called, or no fix exists and a workaround is in place. Name the approver. See our guide on acting when an advisory has no patch.
Where to store it
Put it where reviewers already look: the ticket system, the pull request that made the change, or the alert timeline. Avoid private chat threads that disappear. Make sure the note is linked from the ticket so a search by advisory ID finds it.
What to avoid
- Vague words like "handled" or "done".
- Claiming a version is safe without a source.
- Recording only the fix and not the exposure check.
- Skipping the received time. It is the start of your response clock.
A word on compliance language
Evidence of response helps with frameworks that ask about vulnerability management, but a note does not by itself show a control is effective. Keep your claims to what the record shows.
Where Safeguard fits
Safeguard's compliance and evidence automation collects scan results, SBOM data and remediation activity so you do not have to rebuild the story by hand. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Follow a finding from discovery to resolution and note which fields are captured along the way.
Quick check
Do I need to record advisories that did not affect me?
A one line note that you checked and found no exposure is cheap and answers later questions.
Where should the record live?
In a system reviewers can search, such as the ticket or alert timeline, linked by advisory ID.
Sources
Last reviewed: 19 October 2026.
