Fail closed for code that can reach production unreviewed, fail open for low risk repos, and write the choice down before you sign. A scanner outage should never silently turn into a green check. Decide the behaviour per repository tier, then ask the vendor what it promises when its service is unavailable.
Definitions
Fail closed means a merge is blocked when the security check cannot run. Fail open means the merge proceeds without a result. Neither is free. Closed stops developers during an outage. Open leaves a window where unscanned code ships.
The quiet failure to watch for
The dangerous case is not a deliberate fail open. It is a check that reports success because it never ran. GitHub's documentation states that a skipped job reports its status as success and will not block a pull request, even when the job is a required check. Its protected branch page lists successful, skipped and neutral as the statuses that satisfy a required check. If your scanner step is skipped because an API call timed out and the job is conditional, the branch rule may treat that as a pass.
So test it. Break the scanner on purpose in a sandbox repo and see what the merge button does.
A simple decision table
| Repo tier | Examples | Outage behaviour | Why |
|---|---|---|---|
| High | Payments, auth, infrastructure code | Fail closed, with a named break glass approver | Unscanned changes are the risk you bought the tool to remove |
| Medium | Internal services | Fail closed for a short window, then manual review | Keeps work moving without losing the record |
| Low | Docs, prototypes | Fail open, rescan afterwards | Cost of blocking exceeds the risk |
Steps to set it up
- Tier your repositories, even roughly. Three tiers is enough.
- For each tier, decide the outage rule and who can override it.
- Make the override leave a record: a labelled pull request or a ticket reference.
- Schedule a catch up scan for anything merged during an outage window.
- Rehearse once a quarter by disabling the scanner token in a test repo.
What to ask the vendor
Ask what status the integration reports when the service is unreachable, and whether you can choose it. Ask how outages are announced and whether a status history is public. Ask for the retry and timeout behaviour of the CI step, because a long timeout can stall every pipeline at once. Put your chosen behaviour into the pilot success criteria so you test it before purchase.
Try it yourself
Open the demo and look at how a gate decides between pass and block on a pull request. Then consider what would happen at that point if the scan result were missing.
Click through it at your own pace, or open it full screen.
Safeguard supports policies and gates on pull requests, and you can try a free scan at gold.safeguard.sh/scan.
Quick check
Does a skipped scan job count as passing in GitHub?
According to GitHub's documentation, a skipped job reports success and does not block a pull request, even when it is a required check. Test your own setup to confirm.
Is fail closed always safer?
It is safer for high risk code, but a blanket rule invites workarounds such as disabling the check. Tiering with a logged override tends to hold up better.
Sources
Last reviewed: 19 October 2026.
