Every blocking scan needs a documented way out: a waiver with a reason, a named approver, and an expiry date. The process should be lighter for a team of five and more formal at larger sizes, but the three fields stay the same.
Why you need a waiver process
Scanners are wrong sometimes, and sometimes a fix cannot ship today. Without a sanctioned exception path, developers choose their own: they disable the check, suppress findings in code, or merge with an administrator override. All three leave no record.
A waiver turns a quiet bypass into a visible decision.
The three required fields
- Reason. Why the finding does not apply or cannot be fixed now. "Not exploitable because the vulnerable function is never called" is a reason. "Deadline" is a weaker one but can be valid with a plan.
- Approver. A named person, not a team alias.
- Expiry. A date when the waiver lapses and the check applies again.
Leave out any of these and waivers become permanent, anonymous, and unexplained.
How it scales
| Team size | Who approves | Where recorded | Review |
|---|---|---|---|
| 1 to 10 | Tech lead or founder | A file in the repository | At each release |
| 10 to 100 | Service owner, with a security contact for high severity | A tracked list tied to the finding | Monthly |
| 100 and up | Tiered: owner for medium, security for critical | Central register with reporting | Monthly, plus aggregate trend review |
Keep waivers where reviewers can see them
A waiver stored in a developer's editor settings or a chat message is invisible. Put it in version control next to the code, or in the system that holds findings, so a reviewer can see it during the pull request.
Watch for patterns
Count waivers by rule. If one rule produces most of them, the rule is probably too noisy or too strict. Change the rule instead of approving the same waiver forty times. Also watch for repeated renewals of the same waiver, which usually mean a fix is stuck and needs an owner.
Do not forget the admin bypass
Branch protection can let administrators bypass required checks. GitHub's documentation lists a setting that prevents bypassing the protection settings. Decide whether administrators are bound. If they are not, make sure bypass use is logged and reviewed, since it is an exception too.
Steps
- Define the three required fields.
- Choose where waivers live.
- Name approvers by severity.
- Set a default expiry, such as 30 or 90 days, appropriate to your risk.
- Send reminders before expiry.
- Review waiver counts monthly.
Where Safeguard fits
Safeguard supports policies, gates, and compliance evidence automation, so approved exceptions and the checks they relate to can be kept as evidence. Try a scan first at https://gold.safeguard.sh/scan.
Quick check
Should waivers ever be permanent?
Rarely. An expiry forces a fresh decision. If a risk is truly accepted long term, record it as an accepted risk with periodic review.
Can developers suppress findings in code comments?
Only if the suppression is visible in review and tied to a reason. Silent inline suppressions are an invisible exception path.
Sources
Last reviewed: 19 October 2026.
