Record the tool, exact version, source and license, the named owner, what data it reads, the permissions it holds, how it gets updates, what it covers and a review date. One page, stored with your other security decisions, saves hours at every audit and every handover.
Why bother
Six months after adoption, nobody remembers why the scanner was chosen or what it can and cannot see. An auditor, a customer or a new hire asks, and the answer lives in someone's head. A written record turns that into a lookup.
It also helps you decide to retire the tool, since you can see what it was meant to do.
The record, field by field
| Field | What to write | Why |
|---|---|---|
| Tool and version | Name, exact version, pin location | Reproducibility |
| Source and license | Where it is downloaded from, license name | Legal review |
| Verification | How the download was verified | Supply chain evidence |
| Owner and backup | Named people | Accountability |
| Purpose | What risk it addresses | Scope |
| Coverage | Languages, ecosystems, repositories | Known blind spots |
| Data sources | Which advisory databases it reads | Accuracy questions |
| Permissions | Tokens and scopes it holds | Least privilege review |
| Updates | How and how often it updates | Staleness |
| Output | Where results go, who reads them | Triage ownership |
| Exit signs | Conditions that trigger review | Planned retirement |
| Review date | Next scheduled check | Prevents drift |
A template
Scanner: (name) (version) pinned in (file path)
Adopted: (date) Owner: (name) Backup: (name)
License: (name) Source: (url) Download verified by: (method)
Purpose: (one sentence)
Covers: (languages and ecosystems) Does not cover: (known gaps)
Data sources: (databases it reads) Refresh: (how often)
Permissions: (token scopes, read or write)
Results go to: (system) Triage owner: (team)
Review by: (date) Exit signs: (conditions)
Where to keep it
Keep it next to the decision records you already write. Our guide to security decision records explains a format. A file in the same repository as the pipeline configuration works well, because changes then appear in review.
Tie it to the audit trail
For compliance programs, a dated adoption record shows that a tool was chosen deliberately and is monitored. Be careful what you claim: the record shows a control exists and who owns it, not that the control is effective. Do not describe it as certification or attestation of anything.
Keep it alive
Update it whenever the version, permissions or owner changes. Add a calendar reminder for the review date. If you find the record has not been touched in a year, treat that as a finding.
If you later move to a platform, the record becomes your requirements list for migration. Safeguard's compliance and evidence automation can help keep records like this tied to your controls.
Quick check
Is this overkill for a small team?
Trim it to five lines: tool, version, owner, permissions, review date. Even that helps.
Who should approve the record?
The security owner and the engineering lead who runs the pipeline.
Last reviewed: 19 October 2026.
