Allow exceptions one resource at a time, with a named owner, a written reason and an expiry date, recorded next to the code and approved in the pull request. Never disable a rule for a whole repository. An exception without an end date quietly becomes the standard.
Why exceptions need structure
Every rule set meets a case it should not apply to: a public website bucket, a test environment, a legacy system. If there is no sanctioned way to say so, people disable the check or stop looking at its results. Both are worse than a tracked exception.
What a good exception record holds
| Field | Why it matters |
|---|---|
| Rule and resource | Narrow scope, so only this resource is exempt |
| Owner | Someone who can answer questions later |
| Reason | The business or technical need, in a sentence |
| Compensating control | What reduces the risk instead |
| Expiry date | Forces a decision to renew or fix |
| Approver | Shows a second person agreed |
Where to keep it
Put the exception in the same repository and the same pull request as the code it covers, as a comment or annotation in the format your scanner reads, plus a short entry in a central register. Reviewers then see the exception when they see the risky setting, and the register gives you a count to report.
A process in five steps
- Request. The author adds the exception and the fields above in the pull request.
- Review. A security reviewer, not the author's own team lead, approves or rejects. Reject any whole repository or whole rule exemption.
- Record. The exception is added to the register with its expiry date.
- Expire. A scheduled job lists exceptions that are within 30 days of expiry and opens issues for owners.
- Renew or fix. Renewal needs a new approval, not an automatic extension.
Measures worth tracking
- Number of active exceptions, and how many are past expiry.
- Exceptions by rule, because a rule with many exceptions may be the wrong rule.
- Time from expiry to fix or renewal.
- Exceptions that cover production or data stores.
Warning signs
- Exceptions without owners.
- The same rule exempted across many unrelated resources.
- Expiry dates that are always extended.
- Suppression comments added in bulk by one person to clear a build.
If a rule keeps getting exempted, tune it, narrow it or retire it. Decide that on purpose rather than by accident. See also tuning or suppressing a noisy alert.
Quick check
Is it ever fine to disable a rule for the whole repository?
Rarely. If a rule does not fit a repository at all, change the rule set deliberately, with review, rather than switching it off.
How long should an exception last?
Short enough that someone has to look at it again. Many teams choose a few months, depending on risk.
Safeguard lets you set policies and gates that hold a pull request when a rule fails, and keeps evidence of each decision for audits. You can try a free dependency scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
