Review every scanner once a year, and sooner after a trigger such as a major release, a maintainer change, a license change or a missed vulnerability. The review takes about half a day per tool and checks health, coverage, data freshness, permissions and whether it still earns its place.
Why a scheduled review
Scanners drift. Projects slow down, teams add languages, tokens accumulate permissions and nobody notices. A scheduled review catches drift while it is cheap to fix. It is also easy to defend: you can show an auditor that tools are reviewed on a calendar, not only when something breaks.
Trigger events that justify an early review
- The project archives its repository or changes its license.
- A security flaw is disclosed in the scanner itself.
- Your stack adds a new language or package manager.
- A vulnerability reaches production that the scanner should have found.
- The owner leaves the company.
The checklist
| Area | Question | Where to look |
|---|---|---|
| Health | Any release in the last six months? | Releases page |
| Governance | Is more than one person active? | Contributor history |
| Security | Is there a policy and a reporting channel? | SECURITY.md |
| Coverage | Does it cover every language we use? | Documentation, test repo |
| Data | Is advisory data fresh? | Freshness test |
| Permissions | Are token scopes still minimal? | CI and platform settings |
| Version | Are we pinned and within support? | Pipeline file |
| Noise | Has the false alarm rate changed? | Triage records |
| Ownership | Is there a named owner and backup? | Adoption record |
| Cost | How much time does it take? | Time log |
Each line should produce a note: fine, needs action, or consider replacing.
Score the outcome
Use three outcomes for each tool.
- Keep. No action beyond the calendar.
- Fix. A specific change with an owner and date.
- Replace. Start your exit plan. Our post on what to do if your scanner is archived lists the steps.
Include the whole stack
Review how the tools fit together, not just each one. Overlaps waste effort, while gaps hide risk. Draw a short matrix of ecosystems against tools and mark where each is covered. The post on a coverage matrix before retiring a scanner shows the format.
Keep the evidence
Save the filled checklist with the date and the reviewer. For compliance work this is a record that a control is monitored. Describe it as that and nothing more.
If the review keeps ending in fix and replace, it may be time to look at consolidation. Safeguard combines SBOM and dependency scanning, policies and gates, and compliance and evidence automation, and a free scan at https://gold.safeguard.sh/scan shows how it sees your repositories.
Quick check
Is once a year too slow?
For stable tools it is a fair baseline. Use trigger events to catch faster changes.
Who should run the review?
The tool owner prepares it and a second person from security or engineering reviews it.
Last reviewed: 19 October 2026.
