A gate should let a finding pass only while a matching, unexpired, approved exception exists, and it should log which exception it used. If the exception service is down or the match is unclear, the gate should fail closed and block, not guess.
What "matching" means
A gate sees a finding: advisory, package, version, repository. It asks whether an exception covers exactly that. Matching rules are where most mistakes live.
- Exact key. Advisory plus package plus version range plus asset.
- Status check. Approved and not expired, revoked or pending.
- Scope check. The branch or environment is within the exception's scope.
- Severity check. Severity has not risen since approval.
If any check fails, the finding counts as unexcepted and the normal gate rule applies.
Fail closed, not open
If the gate cannot reach the exception store, it cannot know what is approved. Failing open lets everything through during an outage, which is exactly when nobody is watching. Fail closed, show a clear error, and provide a break-glass route that records itself. See break glass workflow design.
What the gate should show
| Output | Why |
|---|---|
| Finding passed under exception ID | Traceability from build to decision |
| Days until expiry | Prompts renewal early |
| Findings blocked and why | Developers know the next step |
| Link to request or renew | Shortens the loop |
Surface "passes with exception, expires in 5 days" as a warning in the pull request, not a buried log line. It prevents surprise failures later.
Events worth recording
Log every gate decision that used an exception: build ID, finding, exception ID, timestamp. This is the join between your build history and your exception register, and it is the first thing an auditor will want to test. Compare with what should a security gate exemption record contain.
Separate checks for separate stages
A pull request gate can be lenient and informative. A release gate should be stricter. An exception for a feature branch should not automatically cover production. Scope it by environment, and test that scoping.
Edge cases to test
- Exception expires between PR check and merge
- A new advisory appears on an excepted package
- The version range in the exception is wider than intended
- Two exceptions overlap with different expiry dates
- The exception store returns an error
Write a test for each. They are cheap and they catch real policy bugs.
Avoid hidden state
Do not let developers satisfy a gate with a local ignore file that never reaches the register. Central records with expiry beat per-repo files that nobody reviews. For more, see where should vulnerability exceptions live.
Safeguard policies, gates and guardrails evaluate rules at pull request and release time, and its reachability analysis helps decide which findings deserve to block at all.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at what the gate reports on a blocked change and what a developer would need to do next.
Quick check
Should a gate warn before an exception expires?
Yes. A visible countdown in the pull request avoids a surprise failure.
What if the severity rises after approval?
Treat the exception as needing review. Approval was for the severity the approver saw.
Last reviewed: 19 October 2026.
