A build fails on SCA findings because the scan command returns a non-zero exit code when it finds vulnerabilities at or above a configured level. To fix a noisy gate, set the failure threshold deliberately, limit it to production scope, and add a documented exception path instead of switching the check off.
How the exit code works
The npm audit documentation is a clear example. The command exits with 0 if no vulnerabilities were found, and with a non-zero code if any vulnerability is found. It suggests using the audit level parameter in CI to specify the minimum level that will cause the command to fail. It also states that this option does not filter the report output, it simply changes the failure threshold.
That detail matters when reading logs. You will still see low findings printed in the output while the build passes, because only the threshold decides pass or fail.
Three settings that control a gate
| Setting | What it controls | Common choice |
|---|---|---|
| Threshold | Minimum level that fails the build | Start high, tighten later |
| Scope | Which dependencies count | Production only for blocking |
| Exceptions | Findings allowed to pass | Time limited, with owner |
A rollout that people tolerate
- Start in report mode. Run the scan and print results for a couple of weeks without failing builds. Record how many builds would have failed.
- Set the threshold to what you can clear. If the current backlog would block every build, fix or except the worst items first, then switch the gate on.
- Block on exploitation and reachability when your tool supports it. A gate that blocks on any high severity finding in an unused library teaches developers to bypass it.
- Limit blocking to production scope. The npm audit documentation shows omit options that remove development packages from the submitted payload, so the gate can focus on what ships.
- Tighten gradually. Move the threshold down one level at a time when the backlog is under control.
Exceptions that do not rot
Exceptions are fine when they are visible. Each should have a finding ID, a reason, an owner and an expiry date. When the date arrives, the build fails again and someone must decide. Without expiry, exceptions pile up until the gate means nothing.
Fixing a failing build today
- Read the output and find which finding crossed the threshold.
- Check whether a compatible fix exists. The npm documentation says the audit fix command applies remediations that do not require changing dependency ranges and needs a force option for the rest.
- If no fix exists, mitigate and add a dated exception.
- Do not lower the threshold in the same change as the fix. Keep policy and code changes separate so reviewers can follow each.
Try it yourself
Click through it at your own pace, or open it full screen. Try the pass and block cases and see what each message tells a developer.
Where Safeguard fits
Safeguard's policies, gates and guardrails let you set blocking conditions by signal, scope and exception, and keep an audit trail of overrides.
Quick check
Does a passing build mean there were no findings?
No. Findings below the threshold can still appear in the report while the build passes.
Should I disable the check when it blocks a release?
Use a time limited exception instead. Disabling it removes protection for every later change.
Sources
Last reviewed: 19 October 2026.
