Name the override path before you turn the gate on. A workable rule is that the author cannot approve their own override, a designated security reviewer or code owner can, a written reason is required, and the exception expires. Without that, developers will route around the gate or disable it.
Why overrides need design
A blocking check will sometimes be wrong. OWASP notes that static tools often produce false positives, so a finding that blocks a merge may not be a real flaw. If the only way past is disabling the check for everyone, the gate will not survive its first busy week.
An override is not a failure of the gate. It is a controlled exit that leaves a record.
Options compared
| Model | How it works | Risk |
|---|---|---|
| Author overrides alone | Anyone can click through | No independent check, easy to abuse |
| Any reviewer on the PR | A second person approves | Reviewer may not understand the finding |
| Code owner of the path | The owning team approves | Good context, may lack security view |
| Security reviewer | Central team approves | Strong, but can become a bottleneck |
| Two person rule for high severity | Owner plus security | Slower, suited to critical findings |
Many teams use a tiered mix: code owner for medium findings, security reviewer for high ones.
What every override should record
- The finding id, rule name and CWE.
- The reason, in a sentence a stranger could follow: false positive, accepted risk, or fix scheduled.
- Who approved, and when.
- An expiry or review date.
- A link to the follow up ticket if a fix is planned.
NIST's Secure Software Development Framework asks that discovered issues be recorded and triaged in the development team's workflow or issue tracker. An override record is part of that trail, and it is the kind of evidence an auditor or customer reviewer can read.
Decide which findings can be overridden at all
Not everything should be overridable by a reviewer. Consider a small set of rules that are hard blocks, for example a finding a security team has tagged as critical, where only a senior approver can proceed. Everything else uses the normal path.
Watch the override rate
Track how many overrides happen per month and by which rules. A rule that is overridden almost every time is probably noisy and should be tuned. A team that overrides far more than others may need help, or may be struggling with a legacy area.
Make the override easy but visible
If the process takes a week, people will not use it. A one click request that pings the approver, plus a visible label on the pull request, keeps friction low and transparency high. Report overrides in your regular security review.
A worked example: three overrides in one month
A team with a blocking gate on high severity findings records three override requests in a month. The details are illustrative.
Request one: the gate blocks a merge because of a possible injection pattern. The author explains that the value is an integer parsed earlier by the framework. The code owner reads the code, agrees it is a false positive and approves. The record states the reason and sets a review date three months out.
Request two: a finding on an old internal script. The author asks to override because the script is scheduled for retirement. A security reviewer approves with an expiry of the retirement date and a link to the retirement ticket.
Request three: a finding in the authentication module. The author asks to override because of a deadline. The security reviewer declines, since this is a hard block category. The author fixes it that day, with help from the reviewer.
Three requests, three different outcomes, all recorded. The monthly report shows one false positive, one temporary accepted risk and one fix. It also shows that the override process did not slow delivery by more than a few hours.
Designing the approval rules
| Finding class | Who can approve | Expiry |
|---|---|---|
| Low or medium, confirmed false positive | Code owner | Review in six months |
| High, false positive with evidence | Code owner plus security reviewer | Review in three months |
| High, accepted risk | Security reviewer and engineering lead | Short, tied to a fix date |
| Critical or hard block category | No override, fix required | Not applicable |
Adjust the classes to your own risk appetite. What matters is that the table exists, is short and is applied the same way each time.
Process details that make it work
- A request form with required fields. Reason, finding id and proposed expiry. A form prevents vague requests.
- A service level for approvers. For example, a response within one working day. Without it, the gate becomes a bottleneck.
- Automatic expiry reminders. When an override expires, the finding returns to the queue.
- Visible labels. A label on the pull request, such as "override approved," helps later reviewers.
- A monthly review. Look at counts, reasons and repeat requests.
Avoiding abuse
People will try the easy path if it exists. Watch for patterns: one author with many requests, one rule overridden almost every time, requests made late on Friday. None proves bad faith, but each is a conversation starter. Often the cause is a noisy rule or an unclear standard, and the fix is to tune the rule or clarify the standard.
Documentation for auditors
An override log is a useful artifact. NIST's Secure Software Development Framework asks that issues be recorded and triaged in the team's workflow. A log that shows who approved what, when and why demonstrates a working process. Keep it exportable and keep it for as long as your records policy requires.
What about emergencies
Define an emergency path in advance. For example, a production fix can merge with an override approved by an on call security reviewer, with a follow up review within two working days. Writing it down beforehand prevents improvisation under pressure, and it prevents the emergency path from becoming the routine one.
Try it yourself
Click through it at your own pace, or open it full screen. Look at what the pull request shows when a check fails and what the next step is.
Quick check
Should the PR author be able to override a blocking finding?
Not alone. An independent approver gives the gate meaning, and the author can still request the override.
Should overrides expire?
Yes. An expiry date forces a second look, so a temporary exception does not become permanent by default.
Should overrides be visible to the whole team?
Yes, at least at summary level. Visibility discourages misuse and helps people learn which findings are usually false alarms.
Safeguard offers policies, gates and guardrails for pull requests, and a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
