Decide by risk and by branch. Fail closed on release and production paths, where unscanned code is costly. Fail open on ordinary development branches with a visible warning and a later catch-up scan. Either way, make the outage state explicit and measurable, not a silent pass.
Define the terms
A required check is a status that must pass before a merge. Failing closed means that if the scanner cannot produce a result, the check fails and the merge is blocked. Failing open means a scanner error lets the merge proceed.
Neither is correct everywhere. The cost of a block is stalled work across every team. The cost of an open pass is code that skipped review.
Compare the options
| Option | Good for | Risk |
|---|---|---|
| Fail closed | Release branches, deploy pipelines, regulated paths | A scanner outage stops delivery |
| Fail open with warning | Feature branches, docs, low risk repos | Unscanned code merges |
| Fail open then catch up | Most development branches | Window of exposure until the catch-up scan runs |
| Manual override by named approvers | Emergencies | Needs audit trail and expiry |
A decision rule
- Classify paths: release or production, shared libraries, ordinary services, documentation.
- For release and production paths, fail closed, but provide a documented break-glass route with two approvers and an automatic ticket.
- For ordinary paths, fail open, label the pull request as unscanned, and queue a scan to run when the service returns.
- For all paths, distinguish a scanner error from a finding. An infrastructure error should say "scanner unavailable", not "vulnerabilities found".
- Run a catch-up scan on everything merged during the outage, and open issues for any new blocking findings.
Reduce how often the question arises
- Run the scanner with redundancy across zones, and keep the vulnerability database in a local mirror so an upstream outage does not stop scans.
- Set a timeout on the check so a hung scan resolves to an explicit result.
- Retry transient errors before declaring failure.
- Publish a status page and a channel for outages, so developers do not guess.
Keep the trail
Every fail-open pass should produce a record: the pull request, the commit, the reason, and the catch-up result. Auditors and security reviewers ask for these, and the data also tells you how often outages happen. If fail-open events are frequent, the platform needs reliability work, not a policy change.
Be careful with permanent bypass labels. A label that lets any author skip the check will become the default.
Compliance angle
Some frameworks expect that changes are reviewed and tested before release. Document your fail-open policy and the compensating control, the catch-up scan. Check with your auditor on how they view it rather than assuming.
Try it yourself
Click through it at your own pace, or open it full screen. See what the gate checks and what a blocked or passing pull request looks like.
Safeguard's policies and gates can be set per repository and branch, which supports different behaviour for release and development paths. You can try the free scan at https://gold.safeguard.sh/scan.
Quick check
Is it ever fine to fail open?
Yes, on low risk paths, if the pass is visible, recorded and followed by a catch-up scan.
What is break-glass?
A controlled emergency override with named approvers, a reason, an expiry and an automatic record.
Last reviewed: 19 October 2026.
