When should a security finding break the build, and how do you handle false positives?
Short answer
Break the build only on high-confidence, high-severity, newly introduced findings; warn (don't block) on everything else so developers keep trust in the gate. Manage false positives with tuned rules, baselining of pre-existing issues, and documented, time-boxed, reviewed suppressions rather than disabling scanners. A gate that cries wolf gets ignored or bypassed, so signal quality is the whole game.
A security gate is only valuable if developers respect it. The hard part of DevSecOps isn't running scanners — it's deciding what should actually stop a release.
What should break the build
Reserve a hard fail for findings that are simultaneously:
- High severity — exploitable, real impact.
- High confidence — low false-positive rate for that rule.
- Newly introduced — added by this change, not inherited.
Everything else should warn rather than block: surfaced in the PR, tracked, but not stopping the pipeline. This keeps the gate's "stop" signal rare and meaningful.
The false-positive problem
This is the crux. A scanner that blocks builds on noise trains developers to distrust it — they'll rubber-stamp suppressions, demand it be turned off, or route around it. Signal quality determines whether security tooling survives contact with a real team. You manage noise by:
- Tuning rules to the codebase and language.
- Baselining pre-existing issues when you onboard scanning to a legacy repo, so day one isn't a wall of red for code nobody touched — then preventing new ones and burning the backlog down deliberately.
- Auditable suppressions — when a finding really is a false positive or accepted risk, record a documented, reviewed, time-boxed exception (with author and justification) instead of disabling the check. Silent
// noseceverywhere is the failure mode.
The feedback loop
Findings should land where developers already work — the pull request — with clear remediation guidance. Fast, accurate, in-context feedback is what makes shifting left actually stick.
What interviewers look for
They want the severity-plus-confidence-plus-new threshold, an honest reckoning with false-positive fatigue, and suppressions that stay auditable rather than becoming a quiet off-switch.
Likely follow-ups
- Why is baselining important when adding scanning to a legacy codebase?
- What happens to a gate's effectiveness when it has too many false positives?
- How do you make a suppression auditable rather than a silent bypass?