Security leaders often talk about risk reduction. Developers talk about velocity. The tension between the two has defined AppSec for over a decade.
February 18, 2026
.png)
Security leaders often talk about risk reduction. Developers talk about velocity. The tension between the two has defined AppSec for over a decade.
But our new research shows something more concerning: reactive security models are quietly draining developer capacity.
In our new Application Security in Practice research report, we surveyed software developers and security professionals to understand how organizations are managing AppSec and software supply chain risk as regulatory pressure tightens and AI-driven development expands.
What we found is clear: most teams remain stuck in reactive security models that surface risk too late, fragment ownership, and create friction for developers.
Nearly half of respondents report spending five or more hours per week responding to security incidents. That’s not strategic security work. That’s interruption.
Reactive AppSec surfaces issues late — at release, during audit, or after production exposure. By then, context is lost. Code has evolved. Ownership is unclear. Fixes are slower and more expensive.
The result?
Security becomes a tax instead of an enabler.
Teams that assess security on every pull request report 40% fewer monthly vulnerabilities than those that check only at release.
That’s not a tooling story. It’s a workflow story.
When security lives inside developer workflows — inside pull requests, IDEs, and CI pipelines — remediation becomes part of development, not a separate event. We found that high-performing teams:
The hidden cost of reactive AppSec isn’t just risk. It’s lost engineering time. And in competitive markets, that time matters.
Understand the full picture.
Download the complete Application Security in Practice report for free to compare your AppSec program against industry data and see what high-performing teams are doing differently.
No older posts
No newer posts