When a CI security scan errors or times out, treat it as a failed check, not a passed one, on branches that can reach production. On feature branches, allow a visible warning. Always separate no findings from could not scan, and record any override with a name and a reason.
Three outcomes, not two
Most pipelines only distinguish pass and fail. A scanner outage adds a third state: unknown. If your pipeline maps unknown to pass, you have built a fail-open gate, the pattern MITRE describes as CWE-636, where a failure drops the product to a less secure state.
If it maps unknown to fail, you have built a gate that stops all releases whenever a vendor has a bad afternoon. Neither default is right everywhere.
Decide by branch and risk
| Context | Scanner unavailable |
|---|---|
| Pull request to a feature branch | Warn, annotate the PR, retry later |
| Merge to main | Block until a scan completes or an approver overrides |
| Release or deploy to production | Block, with an emergency override path |
| Hotfix for an active incident | Allow override with a named approver and a follow-up scan within a set time |
The more directly a change can reach customers, the more the gate should fail closed. The method for choosing is in fail open or fail closed: how to decide for each system.
Reduce false outages first
Many scanner failures are not outages. Slow scans from huge repositories, rate limits and network flakiness cause most of them. Use sensible timeouts, retry once with backoff (not at every layer, see retry storms), cache results where safe, and scan incrementally.
Make overrides cheap but traceable
An override path nobody can use will be bypassed with a config change. Provide a documented one:
- A named approver, not the author of the change.
- A reason in the pipeline log.
- An expiry: the override covers this commit only.
- A follow-up scan that runs when the tool is back, with an alert if it finds something.
Record what ran
Keep the scan version, the time, and the scope in the build record. Later, an auditor or an incident responder can tell a clean result from a skipped one.
Where Safeguard fits
Safeguard supports policies and gates that you configure to block or allow based on findings, plus SBOM and dependency scanning. You choose the behaviour for each branch. You can also try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a gate decision is shown on a pull request, and ask what the gate would show if the scan never completed.
Quick check
Should a scanner timeout ever auto pass?
Only on low-risk branches, and only with a visible warning. On release paths, an unknown result should stop the line.
Who owns the override?
A security or platform owner, not the person pushing the change.
Sources
Last reviewed: 19 October 2026.
