The short answer
DevSecOps fails when scanners are enabled at full sensitivity and developers are handed thousands of findings. The fix is to start with a high severity threshold and only the rules with low false-positive rates, use reachability analysis to filter dependency alerts, and tighten gradually as trust in the signal builds.
Key takeaways
- A gate developers route around is worse than no gate
- Reachability analysis removes most dependency-scanning noise
- Scan changed code, not the whole repository, on every build
- Start at critical-only and tighten over months, never the reverse
The failure mode is consistent. Security asks for scanning. Someone enables SAST, SCA, secret detection and container scanning at default sensitivity. The first run produces four thousand findings. Developers look at it once, conclude it is noise, and stop looking. Six months later the tooling is technically enabled and functionally ignored.
The signal-to-noise problem is the whole problem
Nobody disputes that scanning is useful. The question is whether the output changes behaviour, and that depends entirely on whether a developer opening a pull request believes the findings are worth reading.
Our rule: a developer should be able to read every finding on their pull request in under two minutes, and should expect that fixing them is worthwhile. If either stops being true, the gate is dead regardless of what the dashboard says.
Start narrow
Begin with critical severity only, and only the rule sets with a demonstrably low false-positive rate. For most languages that means a curated Semgrep configuration rather than everything the scanner ships with. You will miss things in month one. You will also have a team that reads the output, which is the prerequisite for catching anything at all.
Use reachability on dependencies
Software composition analysis is the worst offender for noise. A vulnerable transitive dependency that your code never calls is not an emergency, and treating it as one is how teams learn to ignore the ones that are.
Modern SCA tooling can determine whether the vulnerable function is reachable from your code. Filter on that, and dependency findings drop by something like 80% while the ones that remain are genuinely actionable.
Scan the diff, not the repository
Full-repository scans on every commit are slow and re-report the same historical findings forever. Scan changed files on pull requests for fast feedback, and run the full scan nightly on the main branch for the backlog. Developers get a two-minute build; security gets complete coverage.
Fail the build sparingly
Blocking merges is a strong tool that becomes useless once people learn to bypass it. We block on: new critical findings in changed code, hard-coded secrets, and container images with a critical vulnerability that has an available fix. Everything else is a comment, a ticket, or a nightly report.
Secrets need history, not just pre-commit
A pre-commit hook stops new secrets. It does nothing about the AWS key committed in 2021 that is still in git history and still valid. Scan the full history once, rotate everything you find, and treat a leaked credential as compromised regardless of whether the repository was ever public.
Policy-as-code for infrastructure
Terraform and Kubernetes manifests are where the most consequential misconfigurations live — a public storage bucket, a security group open to the world, a container running as root. These are far more deterministic than application findings, so the false-positive rate is low and you can be strict from the start. Checkov or OPA in the pipeline, blocking on high severity, is one of the highest-value gates available.
Generate an SBOM
A software bill of materials per build, retained. The value is not compliance; it is that when the next Log4Shell arrives, the question "are we affected, and where?" is a database query rather than a two-day fire drill across every team.
Tighten over time
Once developers trust the signal, lower the severity threshold. Add rule sets. Extend blocking. The order matters enormously: earning trust and then tightening works; starting strict and trying to recover trust afterwards, in our experience, does not.
