Application security in 2026: Where the risk moved and what to measure

Application security is the set of practices that protect software from design through runtime. It is a set of best practices and process that eliminates the vulnerabilities in the code your teams write, the components they import, the APIs they expose, the configuration they deploy, and the behavior of the application once it is live.

The scope of this practice has widened considerably in recent years, yet most enterprise operating models are still playing catch up with it. Application security still tends to sit with a small central team and its effectiveness is measured on how many vulnerabilities it finds, while the surface it is responsible for has grown to include cloud configuration, third-party dependencies, machine identities, and now AI-generated code.

Added to that, if you look at 2026 breaches so far, a pattern is clear: Attackers noticed gaps in enterprise application security practices before most boards did.

Why application security became the leading breach vector

The 2026 Verizon Data Breach Investigations Report found that vulnerability exploitation accounted for 31% of initial access in breaches, up from 20% in 2025. It was the first time in the report's 19-year history that credential theft was displaced from the top position.

Still, two caveats are worth stating before we make any solid conclusions based on these numbers.

One, credential abuse fell to 13% as an initial access vector, but counted at any point in the breach chain it appears in 39% of breaches, which still makes it the most pervasive technique in the dataset. Two, part of this shift from credential abuse to application security exploitation is also methodological, since pretexting became a separately tracked vector this year. Identity has not stopped mattering.

Still, with the numbers, what is unambiguous is the direction attacks are increasingly taking: vulnerability exploitation.

Vulnerability exploitation has climbed steadily for three years, and attackers are choosing it because it works reliably. Unpatched, internet-facing code stays vulnerable long enough to be worth targeting. This in itself is a statement about defender capacity rather than attacker sophistication.

For enterprises with modern IT, the application security remediation math is the real problem

Here is the finding by the Verizon report that should make enterprise CISOs rethink their vulnerability mitigation strategy: Only 26% of vulnerabilities in CISA's Known Exploited Vulnerabilities catalog were fully remediated during 2025, down from 38% in the previous year, and median time to full resolution rose to 43 days from 32.

This means that the highest-confidence vulnerabilities currently live in enterprise IT and under active exploitation are being closed less often and more slowly than last year.

In this scenario, detection is not the bottleneck. In fact, a recent report by Veracode shows that it is the security debt that affects 82% of organizations, with critical security debt affecting 60%, and high-risk vulnerabilities rose 36% year over year, which is how large enterprises end up carrying backlogs in the thousands.

Any strategy that adds scanning coverage without adding remediation capacity makes the backlog larger and the reporting worse. That is the trap most application security programs are currently in.

The domains of application security, and where each one breaks

Application security is not a stand-alone practice in modern IT. It comprises of seven software practices, each with its own owner, tooling, and failure mode. This includes:

1. Source code analysis: This includes the traditional process of static analysis and code review, catching vulnerabilities and flaws in code before they ship to production. But this as a stand-alone security practice can fail when findings arrive after the merge, or in volumes developers learn to ignore. You can read more about source code analysis in our piece on software development life cycle security.

2. Dependencies and supply chains: Open-source components, container base images, and now model artifacts have become areas where organizations need to be much more vigilant because it is these areas they have less control over.

3. APIs: This is the interface layer of your applications and the fastest-growing attack surface in most enterprises. See how you can enable API security for authentication, authorization, and rate-limiting specifics.

4. Configuration and infrastructure: Vulnerabilities such as misconfigured storage, over-permissive IAM roles, and exposed management interfaces increase the risk vector of your applications. This is where cloud security posture management applies, and it accounts for a large share of real incidents despite involving no code defect at all.

5. Serverless and ephemeral compute:  Many enterprises now depend on short-lived functions that traditional agents cannot instrument. Our serverless security piece covers why the usual controls do not transfer.

6. Data access: This involves what the application can reach once it is running and whether that access is monitored is a critical aspect of application security. Database activity monitoring is the control here, and it is frequently the only thing standing between a compromised application and a reportable data breach.

7. Runtime and identity: It is critical to track application behavior in production before it inadvertently affects the end users. Best practices for this include machine identities and service-to-service authentication. This practice increasingly overlaps with insider threat detection, because a compromised service account and a malicious employee look similar in the telemetry.

With so many subdomains becoming a part of the equation, buying deeply into one domain while another sits uninstrumented becomes a critical investment mistake—because attackers do not respect the boundaries between these categories, and neither should your review.

What AI-generated code changed, and what it did not

The interesting finding from Veracode's 2026 GenAI Code Security Report is that while AI-generated code is boosting developer efficiency and reducing time to market, the generated code is increasingly exposing applications to security vulnerabilities.

Roughly 44% of AI code generation tasks introduced a risky vulnerability, and the average security pass rate across models was 56%, barely moving from 55% in the first edition. This means we are increasingly relying on AI-code-generation models while they are yet to become safer.

For a CIO, this creates a cascading business impact and not just a technical one. Think about it. If a CIO enables their team to run AI-generated code for faster time to market, then with continued use, the proportion of AI code in the product will increase, and if AI code is unreliable, then a constant proportion of generated code carries a flaw. When this generated code becomes a large share of everything shipped, then defect volume scales with adoption while review capacity stays flat.

So how should CIOs handle the AI code generation scenario? There are two practical options:

1. Treat AI-generated code as untrusted input subject to the same gate as any external contribution, which most organizations do not currently do.

2. Measure remediation throughput before expanding AI coding tools. This helps CIOs understand if the they can afford to enable AI-based code generation for their applications.

A security vulnerability closely similar to this is agentic systems deployed to run and maintain applications. An agent holding production credentials to your application is an application security problem regardless of how it is procured. Gartner® expects a substantial share of enterprise applications to integrate task-optimizing AI agents by the end of 2026. Our pieces on MCP servers and AI risk management cover the governance side.

New regulations are closing the optional window for ensuring application security

Application security is moving from a best practice to a legal obligation, which changes who is accountable when it fails.

For instance, recent regulations that have made application security a mandatory compliance requirement include:

• The European Union's (EU's) Cyber Resilience Act, Regulation 2024/2847, which entered into force in December 2024. Reporting obligations for actively exploited vulnerabilities begin on Sept. 11, 2026, with full application from Dec. 11, 2027. This regulation applies for any digital product sold into the EU, which makes application security a product requirement rather than an IT one for many organizations.

• NIS2, which already requires risk management measures covering security in acquisition, development, and maintenance.

• DORA, under which financial services firms face parallel expectations.

The common thread across all these three regulations is evidence. Each expects an organization to demonstrate a process for risk mitigation. This means the artifacts your program produces matter as much as the outcomes.

The application security metrics CXOs need to closely watch

Most application security reports lead with the number of vulnerabilities found. That number only helps in building a case for buying more scanners and says nothing about whether the actual risk went down.

Here are four metrics to evaluate your application's threat landscape:

• Remediation rate and trajectory: Ask what proportion of critical findings were closed this quarter, and is the backlog growing or shrinking? A shrinking backlog at a modest rate is a healthier signal than a large discovery number.

• Mean time to remediate, split by severity: Compare against Verizon's 43-day median for actively exploited vulnerabilities to see where you sit.

• Coverage across the seven domains above: Evaluate which are instrumented, which are not, and which are assumed to be covered by a tool that does not actually reach them.

• Exploitability-weighted exposure: Understand how many findings are on internet-facing assets with a known exploit, which is a far smaller and more actionable set than total open findings. Act on these first.

The strategic takeaway for CXOs

Application vulnerabilities are becoming the primarily entry point into your enterprise. With application security spanning across various subdomains, it is important CISOs remain vigilant of the vulnerabilities in their applications, how can they be exploited, what is being done to fix them, and how to avoid them.

Along with these, CISOs should also adopt three strong strategies this budget cycle:

• Fund remediation before detection: Additional scanning coverage on an unfixed backlog simply produces more reporting. So, with your current IT security tooling, if the vulnerability fix rate is below where it needs to be, spend there first.

• Stop reporting vulnerability counts upward: Replace them with remediation rate, trajectory, and exploitability-weighted exposure, and expect the first few reports to look worse before they start making actionable business sense.

• Assign ownership across engineering, not only security: A central team cannot clear a backlog it does not control. The organizations improving fastest have made remediation an engineering performance measure with real budget attached.

For help framing the spend, our IT budgeting white paper covers how to structure a case like this.

To stay in the know of what's new in IT operations, subscribe now to CXO Focus.