Suppression files rot because adding a line is easy and removing one never feels urgent. Over time they hide real findings. Keep them honest by requiring a reason, an owner and an expiry date for every entry, and by reviewing the file on a schedule.
How rot happens
- A developer suppresses a false positive. The code changes, and the suppression now hides a true positive.
- A vulnerable dependency is accepted for a release. Nobody removes the entry after the fix ships.
- Wildcard rules are added to quiet one noisy path and match far more than intended.
- The person who understood the reason leaves.
Tools support suppression, not governance
Gitleaks lets you allowlist by commit, path, regex or stopword, add an inline allow comment, or list fingerprints in an ignore file. Dependency-Check accepts a suppression XML file. These are mechanisms. None of them enforces a reason or a review date for you, so add that in code review rules.
A simple standard for every exception
| Field | Example |
|---|---|
| What | Finding ID or fingerprint, not a wildcard |
| Why | One sentence a stranger could understand |
| Who | A named owner |
| Until | A date, at most a quarter away |
| Review | Who approved it |
Automate the boring parts
Write a small check that fails when an exception has no owner or has expired. Run it in CI. Send a monthly list of exceptions expiring in the next thirty days to their owners.
Review routine
Once a quarter, delete every exception you cannot justify in a sentence. Rerun the scan without suppressions and compare. Surprises are the point of the exercise.
Where this gets costly
At hundreds of repositories, files are scattered. A platform with central exception records and expiry can reduce the effort, but just if the workflow requires reasons and owners. Check that in a trial.
Safeguard covers this ground with SBOM and dependency scanning, reachability analysis, policies and gates, and compliance evidence automation. Autonomous fix PRs are off by default, with every category set to Manual. You can try a free scan at gold.safeguard.sh/scan.
A pull request template for exceptions
Add a template that asks the four questions every time someone edits a suppression file: what is suppressed, why, who owns it, and until when. Require a security reviewer on those files with a code owners rule. The friction is small, and it creates a reviewable history that also helps when an auditor asks how you decide to accept risk.
Quick check
Should exceptions ever be permanent?
Rarely. Set an expiry so each one is reconsidered, even if the answer is to renew it.
Is a wildcard suppression ever fine?
Use it sparingly and narrowly. A wildcard is the most common way real findings get hidden.
Sources
Last reviewed: 19 October 2026.
