Frustrations Shared By The Cyber Security Community
The FIVE Major Concerns Are:
- Security Is Seen as Slowing Delivery
- OWASP Top 10 Issues Keep Repeating
- Fixing Vulns Risks Breaking Production
- Too Many Findings, Not Enough Context
- Security Still Engages Too Late
1. Security Is Seen as Slowing Delivery
Few things strain relationships more than security being seen as the team that says “no.” When release deadlines loom, security reviews and testing are often viewed as friction rather than protection. Developers feel pressure to ship; product teams are measured on velocity; and security becomes the last gate before launch. That dynamic creates tension even when everyone wants the same outcome.
The problem isn’t that security is wrong—it’s that security is often introduced too late, without enough context, and without tooling that fits naturally into development workflows. Over time, this perception damages trust and turns AppSec into a negotiation rather than a partnership.
2. OWASP Top 10 Issues Keep Repeating
It’s frustrating to see the same vulnerabilities show up release after release. SQL injection, broken access control, insecure deserialization—none of these are new. Teams invest in scanners, training, and policies, yet the findings keep coming back.
The reality is that knowledge doesn’t always translate into consistent implementation, especially under delivery pressure. New developers join, frameworks change, and old lessons fade. Without guardrails baked directly into development pipelines, the OWASP Top 10 becomes a recurring reminder that awareness alone doesn’t equal prevention.
3. Fixing Vulns Risks Breaking Production
Legacy systems are where good security intentions go to die. These applications often power critical business processes, yet they’re built on outdated frameworks and fragile dependencies. Touching them feels risky, even when vulnerabilities are known. Teams hesitate to patch because a small change can trigger unexpected failures, outages, or regressions.
As a result, vulnerabilities are documented, accepted, and quietly deferred. Over time, technical debt becomes security debt. The longer these systems remain untouched, the harder remediation becomes—and the higher the eventual cost when something finally breaks.
4. Too Many Findings, Not Enough Context
Modern AppSec tools are incredibly good at finding issues—but not at explaining which ones truly matter. Security teams are often flooded with findings that lack context about exploitability, data sensitivity, or business impact. Developers see long lists of issues with similar severity ratings and struggle to decide what to fix first.
Without clear prioritization, critical risks can sit alongside low-impact bugs, competing for attention. This noise erodes trust in the tooling and slows remediation, turning what should be actionable insight into yet another backlog.
5. Security Still Engages Too Late
“Shift Left” still exists….but only in theory! Everyone agrees with the idea of shifting security left, yet in practice it often remains aspirational. Security is brought in after designs are finalized or code is already written, limiting how much influence it can realistically have. At that stage, recommendations are expensive, disruptive, or ignored.
True shift-left requires more than slogans—it requires early involvement, shared ownership, and security controls that align with how developers actually build software. Without that, security remains reactive, always trying to catch issues after the fact.
A Question Back to the Community
These application-layer frustrations point to a deeper issue. While traditional AppSec principles remain vital, they are often misaligned with the novel risks introduced by AI components—from insecure third-party model integrations and prompt injection vulnerabilities to data poisoning in training pipelines and unpredictable model behavior under attack. The gap between the speed of AI feature integration and the maturity of application security frameworks is widening. For development and security teams, this creates tangible risk in the software lifecycle.
So the question for practitioners is this: do these AI-aware application security challenges reflect your reality? Are these the critical issues—or should we be prioritizing others, such as securing AI-enhanced supply chains, managing sensitive data in training logs, or validating the integrity of AI-generated outputs and actions? As AI becomes a core layer within applications themselves, these discussions move from theory to necessity. They will define whether the next generation of software is resilient or inherently vulnerable.
In Summary
Application security frustrations rarely stem from a lack of care or effort. They arise when security, development, and product teams operate on different timelines and incentives. Repeated vulnerabilities, brittle legacy systems, noisy tooling, and late engagement all reinforce the perception that security slows things down.
Bridging that gap requires earlier collaboration, better context, and security practices that integrate seamlessly into delivery workflows—so protecting applications becomes part of how software is built, not an obstacle to shipping it.