Let developers request exceptions as a pull request that adds a dated entry to a file in the repository. Low risk entries merge with code owner review, higher risk ones need a security approver, and every entry expires automatically. The git history becomes the audit trail.
Why tickets fail
A separate ticket queue creates delay, and delay creates workarounds: disabled checks, renamed jobs, or a pasted || true. When the exception lives next to the code, developers use it because it is the fastest route, and security can see it.
What an exception entry contains
exceptions:
- id: GHSA-example-0001
package: example-lib
reason: Vulnerable function is not called; reachability shows no path
owner: team-payments
risk: low
expires: 2026-12-15
review_ticket: PLAT-1234
Required fields: what, why, who, how risky, and when it ends. An entry without an expiry date should fail validation in CI.
Risk tiers
| Tier | Example | Approver | Max duration |
|---|---|---|---|
| Low | Finding in unreachable code, no known exploit | Code owner | Set by policy, short |
| Medium | Fix exists but breaks a major upgrade | Code owner plus platform | Longer, with a plan |
| High | Critical finding in a reachable path | Security lead | Shortest, with a compensating control |
Pick the actual durations yourself, and write them in the policy. They differ by organization.
Steps to build it
- Define the file format and a schema.
- Add a CI step in the shared pipeline that validates entries and fails on expired ones.
- Add CODEOWNERS rules so high tier entries need security review.
- Send a reminder, for example a bot comment, a week before expiry.
- Report active exceptions by team and age every month.
Evidence over opinion
Ask for a reason that someone else can check. "Not exploitable" is weak. "No call path from our code to the vulnerable function, see analysis" is stronger. Reachability analysis and exploitability data make these requests quicker to approve or reject.
Audit angle
Auditors like a consistent process with records. A file in git with reviewer approvals, dates and automatic expiry shows that exceptions are controlled. Keep the policy that defines the tiers next to it. See also exceptions for an AI coding assistant policy for the same pattern in another area.
Try it yourself
Open the exploitability demo and check how a finding can be judged exploitable or not, the kind of evidence an exception request should carry.
Click through it at your own pace, or open it full screen.
Quick check
What happens when an exception expires?
The gate starts failing on that finding again. The team either fixes it or requests a renewal with fresh evidence.
Can the same person request and approve?
No. Require an approver who is not the author, and enforce it with CODEOWNERS and branch rules.
Safeguard supports policies, gates and reachability analysis, which give exception requests concrete evidence.
Last reviewed: 19 October 2026.
