The source of resistance
The most common complaint about DevSecOps is that it slows down development. Builds take longer. Merges get blocked by scanners that report false positives. Developers spend time configuring security tools instead of building features. The backlog of “security findings” grows faster than the team’s ability to address them.
This resistance is real and the frustration is legitimate. But the cause is usually implementation, not the concept.
Where implementations go wrong
Too many tools, too fast. Introducing SAST, DAST, SCA, container scanning and secret detection simultaneously creates an overwhelming wave of findings. Teams that go from zero security scanning to full coverage in one sprint face hundreds of alerts — most of which are noise.
Blocking without context. A scanner that blocks a merge with “HIGH severity vulnerability in transitive dependency X” without explaining the actual exploitability or providing remediation guidance creates friction without value. Developers learn to work around such blocks, not to engage with them.
No ownership model. Security findings land in a queue that nobody owns. The security team expects developers to fix them. Developers expect the security team to triage them. Both are right — and neither acts.
What works instead
Incremental adoption. Start with one tool that addresses the highest-risk category (typically secret scanning). Get it working, tune false positives, build trust. Then add the next layer. Each addition should be a deliberate decision with clear ownership.
Severity-based gating. Not every finding should block a merge. Critical vulnerabilities in direct dependencies with known exploits — yes. Low-severity findings in transitive dependencies five levels deep — track, don’t block. The distinction requires configuration and judgment.
Developer-centric tooling. Findings should appear where developers work — in the PR, in the IDE, not in a separate dashboard they never check. Remediation guidance should be specific: “upgrade library X from version Y to Z” rather than “vulnerability CVE-XXXX detected.”
The role of automation
Security gates that run in parallel with tests (not sequentially) add zero time to the developer workflow. A SAST scan that runs alongside unit tests finishes before the developer checks the PR status. The key is architecture — security as a parallel stream, not a sequential gate.
The organizations where DevSecOps works well are those where the security team’s job is to maintain the tools and tune the policies, while the development team’s workflow is minimally affected. This requires investment in tooling, not in process bureaucracy.
Read also: