Yes, SAST suppressions should expire or carry a review date. Code changes, dependencies change and the reason you gave last year may no longer hold. A quarterly sweep that renews, fixes or deletes each suppression keeps exceptions honest and keeps the finding count meaningful.
Why suppressions go stale
A suppression records a judgement made at one moment. Three things quietly invalidate it.
- The surrounding code changes. A value that was a constant becomes user input after a refactor.
- The scanner improves. A rule that raised a false alarm may now be precise, or the reverse.
- The owner leaves. Nobody remembers why the exception exists, so nobody dares remove it.
Without a date, the only trigger to revisit is luck.
Expire or review: which model
| Model | How it works | Good for | Watch out for |
|---|---|---|---|
| Hard expiry | Suppression stops working on a date and the finding returns | Teams with capacity to respond | Surprise build failures on expiry day |
| Soft review date | Suppression keeps working, a report lists overdue ones | Most teams starting out | Reports nobody reads |
| Review on change | Suppression is rechecked when the flagged file changes | Stable legacy code | Needs tooling support |
Many teams begin with soft review dates, then move to hard expiry for high severity rules only.
A quarterly review cycle in five steps
- Export every active suppression with its rule, location, reason, owner and date. If your scanner stores suppressions externally, the SARIF standard describes an "external" kind for exactly this: a persistent store outside the source. Suppressions written in code are "inSource".
- Filter to those past their review date, then sort by severity.
- For each one, ask the owner a single question: is the reason still true? Look at the code, not just the comment.
- Decide: renew with a new date and fresh evidence, fix the code and delete the suppression, or reject it and let the finding return.
- Record the outcome. SARIF models a status of accepted, under review or rejected, which is a handy vocabulary even if you track it in a spreadsheet.
Keep the meeting short. Fifteen minutes per team is usually enough if the export is prepared in advance.
Signals that the process is working
- The count of overdue suppressions trends toward zero.
- A visible share of reviewed suppressions are deleted rather than renewed, which means someone is actually looking.
- New suppressions arrive with reasons and dates, as described in how to write a suppression comment that survives review.
If every suppression is always renewed, the review is a ritual and not a control.
One factual note on Safeguard
Safeguard offers policies and gates that can be applied to pull requests, and compliance and evidence automation that can help keep review records. If you want a quick look at your own code, the free scan at gold.safeguard.sh/scan is a no-account place to start.
Quick check
Do suppressions need to be reviewed if the code never changes?
Less often, but still sometimes. The scanner, the dependencies and the way the code is used can change even when the file does not. A yearly check for stable code is a reasonable floor.
Who should own the review?
The team that owns the code, with security available for questions. Security alone cannot judge whether a local assumption still holds.
Sources
- SARIF 2.1.0 specification, OASIS, suppression kind and status definitions.
Last reviewed: 19 October 2026.
