A waiver should always have an expiry date, and it should be short: tied to severity and exploitability, usually weeks rather than months. Name an owner, state the compensating control, and require a fresh review before any renewal. A waiver with no end date is a permanent exception.
What a waiver is
A waiver is a documented decision to release despite a failing gate. It is not a fix and it does not change the finding. It records that a named person accepted a named risk for a stated time. NIST SSDF practice RV.2.2 describes this as a risk-based decision on whether each vulnerability will be remediated or addressed by other means such as risk acceptance.
Choosing a length
There is no universal number. Choose lengths in your policy and apply them consistently. A reasonable pattern:
| Situation | Typical waiver length | Condition |
|---|---|---|
| Not reachable, no exploitation seen | Longer, reviewed at each release | Evidence of non-reachability |
| Reachable, mitigated | Short, until the fix lands | Mitigation tested |
| Known exploited | Shortest, often days | Executive approval and active mitigation |
The point is that a waiver should expire sooner as risk goes up. Whatever lengths you pick, shorter is easier to defend to an auditor than longer.
Fields every waiver needs
- Finding ID and affected component and version.
- Release and artifact digest it applies to.
- Reason: why it cannot be fixed now.
- Compensating control, if any.
- Owner and approver, who must be different people.
- Created date and expiry date.
- Trigger for early review, such as a fix becoming available or the finding appearing on the CISA KEV catalog.
Link waivers to VEX where it fits
If the reason is that the vulnerable code is not reachable, a VEX document can express that to downstream users. The OpenVEX spec says the document version must be incremented when any content changes, and statements carry timestamps. That gives you a built-in change history, which is useful when a waiver is renewed or revoked.
Enforce expiry automatically
The failure mode is quiet. The waiver lapses, nobody notices, and the finding keeps shipping. Have the gate treat an expired waiver as no waiver, so the next release fails and forces a decision. Also report open waivers monthly to whoever owns the risk register.
Review the waiver, not just the date
When an expiry arrives, resist renewing by default. Ask three questions: has a fix appeared, has the exploitation picture changed, and is the compensating control still in place and tested? A renewal should be a new decision with a new date, written by the owner, not a silent extension.
Quick check
Can the engineer who wrote the code approve the waiver?
They can propose it. Approval should come from someone else, ideally the owner of the risk.
Should waivers carry over to the next release?
Not automatically. Re-confirm that the reasoning still holds for the new artifact.
Sources
Safeguard supports policies and gates plus compliance and evidence automation, and a free scan is at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
