A usable exemption record holds seven things: the finding identifier, the exact scope, the reason, an owner, an approver, the date it was granted and an expiry date. Without an expiry, an exemption becomes a permanent hole that nobody remembers opening.
The seven fields
| Field | Why it matters | Example |
|---|---|---|
| Finding ID | Ties the record to one advisory | An advisory or CVE identifier |
| Scope | Limits where it applies | One service, one package, one path |
| Reason | Lets a later reader judge it | "Parser not reachable, feature disabled" |
| Owner | Someone who will revisit it | A team or named person |
| Approver | Shows it was reviewed | Security lead |
| Granted on | Starts the clock | A date |
| Expires on | Forces a re-decision | A date |
What real tools support
Scanner formats already include some of these. One open source scanner's ignore file accepts an expiry on a line with a suffix, for example a CVE identifier followed by an exp date. Its experimental YAML format uses an expired_at field, and states that if it is not set the ignore is always valid. The YAML format can also limit an ignore to paths.
Another dependency scanner's config supports an ignore entry with an id, an optional ignoreUntil date and an optional reason, and says that ignoring an ID also ignores its aliases. Package overrides have optional effectiveUntil and reason fields too.
Notice the pattern: expiry and reason are optional in both. Optional means skipped. Make them mandatory with a check in your own pull request review.
A template
id: GHSA-xxxx-xxxx-xxxx
scope: services/billing, package example-lib
reason: vulnerable function is not called; feature flag off
owner: team-billing
approved_by: security-lead
granted: 2026-10-19
expires: 2027-01-19
Make the record enforceable
- Store exemptions in version control, next to the gate policy.
- Require review from the security team for changes to that file.
- Fail the build when an exemption is past its expiry date.
- Report the count of active exemptions each month.
- Close an exemption early when a fix ships.
Keep the scope narrow. Ignoring an ID across every project hides it where it may be reachable. Prefer a path or package specific entry.
Aliases and duplicates
The same flaw can have several identifiers. When your tool treats aliases as one, an exemption covers them all. When it does not, you may see the finding return under a different ID. Test this once, so you know which behaviour you have.
Try it yourself
Open the vulnerability management demo and follow a finding from detection to a decision. Think about what record you would want left behind.
Click through it at your own pace, or open it full screen.
Safeguard's policies and gates support documented exceptions, and its compliance and evidence automation helps keep the trail. The free scan is at gold.safeguard.sh/scan.
Quick check
How long should an exemption last?
Long enough to ship a fix, often 30 to 90 days. Pick a default and require a reason for anything longer.
Can a developer approve their own exemption?
Better not. A second person, ideally from security, should approve.
Sources
Last reviewed: 19 October 2026.
