Why Traditional App Security Fails on the Patching Treadmill
▼ Summary
– Traditional app security relies on a reactive “find-and-fix” cycle and “defend-and-defer” patching, which are no longer sufficient for modern, fast-paced software development.
– The continuous integration/continuous deployment (CI/CD) model accelerates releases, creating a widening gap between code creation and security review, resulting in overwhelming vulnerability backlogs.
– A significant portion of vulnerabilities are exploited by attackers before developers are even aware of them, with 32.1% of known exploited vulnerabilities showing evidence of exploitation on the day the CVE was issued.
– AI-assisted coding increases the volume and speed of code production but does not guarantee security, as 56.4% of developers frequently encounter security issues in AI-generated code.
– To address these challenges, application security must shift earlier in the development process, moving toward code creation rather than remaining a downstream, reactive activity.
For all the effort poured into application security today, many teams find themselves running in place. The traditional find-and-fix cycle , where vulnerabilities are discovered after code ships, patched reactively, and then rediscovered in the next release , mirrors the exhausting, repetitive motion of a treadmill. You work hard, sweat, but never truly advance. The next day, you do it all over again.
This cycle is driven by continuous deployment and the sheer volume of modern code. Security teams and scanners generate endless reports, pulling developers away from innovation to re-learn, patch, and re-release old code. The problem compounds with each new dependency, API integration, or AI-assisted coding session. The result is a vulnerability backlog that grows faster than teams can realistically fix.
A common, but suboptimal, response is defend-and-defer. Instead of fixing deeply embedded flaws, organizations build protective walls around them , firewalls, runtime protections, monitoring, and segmentation. While these controls reduce immediate exposure, the underlying weak code remains untouched. This approach can become a permanent crutch, masking the root cause rather than resolving it.
The data underscores the urgency. According to Edgescan, web application fixes take an average of 75 days, and 45% of large-company vulnerabilities remain unpatched after a full year. Verizon’s 2025 Data Breach Incident Report found that 20% of breaches originated from code vulnerabilities , up 34% from the previous year. Worse, VulnCheck reports that 32.1% of known exploited vulnerabilities had evidence of exploitation before the CVE was even issued. Attackers are acting faster than defenders can respond.
Simply demanding faster patching isn’t the answer. Enterprise systems have dependencies, uptime requirements, regulatory constraints, and change-control boards that slow remediation. Developers face prioritization fatigue when every vulnerability is flagged as critical, making it impossible to focus. Even AI-driven scanning tools, like Anthropic Mythos or Claude Security, can flood teams with findings without addressing the underlying engineering practices that produce the same defect categories.
The real shift must happen earlier in the development lifecycle. Application security needs to move toward code creation itself. Instead of treating security as a downstream, reactive step, it should be embedded in design choices, coding practices, dependency selection, and deployment configurations. AI-assisted development has collapsed coding time but not testing time , and AI-generated code is not inherently secure. Snyk reports that 56.4% of developers frequently encounter security issues in AI-generated code, and 80% ignore or bypass organizational AI security policies.
While find-and-fix and defend-and-defer will never disappear entirely , unexpected behavior will always exist , they should become a second-tier safety net, not the primary strategy. The goal is to reduce the treadmill effect: less time spent running in place, and more time building secure, resilient software from the start.
(Source: ZDNet)
