Survey data from more than 900 cybersecurity practitioners and leaders reveals the ways in which application security programs break down in practice. 

Key Findings 

• Real world incidents are being driven by known vulnerabilities and the patch gap. Among respondents that experienced a production incident, nearly half say it involved a vulnerability identified by the security team prior to release. Only 9% remediate high-severity flaws in production within 24 hours; 74% do so in one to seven days. 
• Longer patch cycles correlate with higher incident rates. Organizations were breached by a known vulnerability at a 97% rate when in the 4-to-7-day capability, but those patching within 24 hours were breached at a 77% rate. 
• Pre-production investment hasn’t closed the runtime security gap. In the past year, 92% of organizations prioritizing risk identification prior to deployment faced a known-vulnerability event. 91% of those who reported being “very confident” in the organization’s strategy for application security had a production incident evade pre-production controls. 
• Visibility into AI runtime behavior is lacking. A majority (70%) of organizations utilize AI-powered components in production; however, 82% are unable to see the AI’s runtime behavior in real time. 
• Runtime security is gaining more investment across organizations. In the next two years, 42% plan to invest more in runtime security. 

Security Leaders Weigh In 

Tim Mackey, Head of Software Supply Chain Risk Strategy at Black Duck:

Shifting cybersecurity left to developers has an implicit assumption — the developer understands, and has influence over, the deployment of their software. Any time software is shipped to a third party, even if that third party is within the same business, the probability of development assumptions getting passed along is low. This then implies that production deployment requirements don’t get fed back to the supplier, something that’s rarely going to happen if there are multiple distinct end users. Put another way, placing all the responsibility for cybersecurity decisions onto developers turns them into compliance, regulatory, red-team, and legal experts — but their rarely if ever any of those things.

In an AI-driven, post-Mythos, cybersecurity world, speed and illumination of weaknesses are key. Periodic maintenance outages are antiquated concepts, and any defensive measure that requires periodic scans is similarly antiquated. Defenders need to shift their attention away from individual patches and think about how their software is deployed and configured. AI can chain weaknesses in ways that would be the envy of cyber-attackers just a few years ago, and in so-doing discover new weaknesses. From the perspective of an AI enabled attacker, there is no distinction between components and vendors of a production system — it’s just a system to probe and explore. Despite this, the goal remains to apply a risk-based model to production software. All that’s changed is a need to consider the entire system and not just individual components.

Justin Fier, Senior Vice President, Offensive Security at Darktrace: 

AI runtime behavior is another way of describing visibility into the AI agents operating inside an organization: what they are doing, what they can access, and whether that behavior aligns with their intended purpose. The issue is simple: many organizations do not have enough visibility into the complex nature of their environments anymore. As AI agents become more embedded in business workflows, that visibility gap becomes harder to manage and more consequential from a security perspective.

The vulnerability finding is not surprising. Applying a patch is rarely simple, especially in environments that depend on legacy systems, industrial technology, or business-critical applications. Organizations are not necessarily delaying because they are negligent. They often need time to test patches because an untested update can break production, disrupt operations, or interrupt revenue. Security and business teams have always had to make that risk calculation: how much exposure can we tolerate while we validate a fix, versus how much operational risk do we create by moving too quickly?

There also needs to be more nuance in how we talk about disclosed vulnerabilities. A disclosed vulnerability does not automatically mean a working exploit exists. An exploit still has to be developed, tested, and operationalized. The risk increases when public disclosure gives attackers enough information to move quickly while defenders are still testing and deploying patches.

That raises important questions about responsible vulnerability disclosure. Historically, vendors were often given time to investigate and remediate vulnerabilities before public disclosure. If that norm erodes, and vulnerabilities are made public before organizations have a realistic chance to respond, the balance shifts further toward attackers.

Crystal Morin, Senior Cybersecurity Strategist at Sysdig:

The idea that organizations can patch every vulnerability within 24 hours sounds good on paper, but it ignores the reality of modern cloud environments. Security teams are overwhelmed by thousands of alerts, while only a small subset of vulnerabilities are actually reachable, running, and exploitable in production. 

But the pressure to patch quickly can also create its own risk. We saw this with the SolarWinds and XZ Utils incidents, when malicious code was pushed upstream by threat actors. Users updated and applied patches, inadvertently introducing a supply chain nightmare.

The organizations that consistently stay ahead aren’t the ones chasing down every CVE, patching immediately, or working on a “Patch Tuesday” cadence. Instead, they’re the ones using runtime insight to understand where real exposure exists and then prioritizing accordingly.

What makes the CSA findings notable is that the defender’s window is collapsing faster than most organizations can adapt. For instance, the Sysdig Threat Research Team (TRT) recently observed attackers exploiting a critical Langflow AI vulnerability just 20 hours after disclosure, before a public proof-of-concept was even available. In another case, attackers leveraged an AI-driven agent to move from initial access to exfiltration of an internal database in under an hour. Attackers are no longer waiting days or weeks to weaponize new vulnerabilities, and increasingly they’re using AI to accelerate every stage of the intrusion lifecycle.

At the same time, many organizations are rapidly deploying AI without fully understanding what those systems are doing once they’re running in production. The CSA report finding that 82% of organizations lack visibility into AI runtime behavior highlights a growing security blind spot at the worst possible time. AI applications often have access to sensitive data, self-authentication with APIs, and the ability to autonomously trigger downstream workflows, making them attractive targets and powerful pivot points for attackers. When security teams lack runtime visibility, they lose the ability to tell the difference between an AI model behaving normally and one that’s been manipulated or compromised. By the time they figure it out, the damage is already done and credentials are long gone. But on the bright side, Kubernetes has become the de facto operating system for AI, and runtime visibility for Kubernetes is an addressable challenge.

Ultimately, the future of vulnerability management isn’t actually patching everything faster. Security teams must instead understand what matters most, detect exploitation in real time, and reduce exposure before attackers can capitalize on it. As AI continues to compress the timeline from disclosure to exploitation, runtime visibility is becoming the deciding factor between organizations that can respond in minutes and those that open a ticket after a breach is discovered.

Ronald Lewis, Head of Cybersecurity Governance at Black Duck:

These results are no surprise. In security, outcomes follow incentives — not intentions. Organizations say they value “shift left,” but what actually gets rewarded is shipping on time, so risk acceptance becomes the mechanism that keeps delivery moving. That creates a false sense of security: we can point to tooling and findings, but known vulnerabilities are still making it to production. Until we reward rapid remediation and real risk reduction — not just detection — much of modern AppSec will remain theater.

The industry has created a system that looks mature on paper. Most companies have scanners, dashboards, and risk registers. But many of those controls optimize for reporting activity, not reducing exposure. 

There’s a similar dynamic within security teams. Finding issues is easy to measure, so we reward detection. But in practice, risk acceptance becomes the pressure valve that keeps delivery moving. Over time, that creates a normalization effect — where known vulnerabilities are routinely accepted, deferred, or reclassified as “manageable.”

We’re seeing the same dynamic play out with AI adoption. Organizations are rewarding speed to deployment, which puts direct pressure on security teams to approve AI solutions quickly. Those approvals are often based on deterministic evaluation models — treating AI like traditional automation — where outcomes are assumed to be predictable and governed by fixed rules. But AI doesn’t behave that way, and that mismatch is introducing risk under the illusion of control.

Saumitra Das, Vice President of Engineering at Qualys:

Due to the sheer volume of code being generated and the lack of people who reasonably understand it, we will need new architectures for dealing with the kind of issues discussed in this report.

1. We need to use AI models that are diverse in their training datasets to review the generated code
2. We need automation via, for example MCP, that can take any code being compiled and send it to vendor A for security reviews, understand the findings, and use vendor B to automate the patching of the issues found. Even if we find issues with large generated codebases we will need agentic workflows to fix them with minimal human intervention.
3. QA will need to evolve to better test various scenarios with AI-generated harnesses and test cases.
4. It’s harder to understand if the AI-generated code violates a license. A model could have learnt coding practices or libraries from a repository with license A and used that “knowledge” to generate code that now taints a user’s codebase with that license, without them realizing. We will need better guarantees from AI model providers on what code they have used to train their data. This is similar to how image generation models must avoid generating copyrighted characters.

Randolph Barr, Chief Information Security Officer at Cequence Security: 

AI coding tools are creating new vulnerabilities more quickly than conventional AppSec procedures can manage. Review fatigue, and a lack of human context, can result from AI's ability to make large-scale, often opaque, and occasionally dependent on untested interdependent changes. 

Security leaders must concentrate on the following in order to adapt:

• Automation-first validation using technologies such as SAST/SCA scans prior to merge.
• AI-assisted code review to ensure accuracy and speed. In order to detect problems that evade previous stages, compensating restrictions like runtime API protection and pre-commit hooks (Semgrep, Gitleaks) are used.

AI can complement human capabilities, rather than replace them, enabling developers to take on greater security responsibility under the supervision and automation of security teams.

In the end, trust needs to be regularly checked, particularly in a world where SaaS and APIs are used. To avoid cascade risks in the event that one link in the chain is compromised, organizations should prioritize vendor risk governance, secure integrations, and runtime API visibility.