Why Application Security Fails at the Handoff

Most organizations can find application flaws. Fewer can get them fixed. The gap sits in the handoffs: design to build, scanner to developer, developer to operations.

Veracode’s 2026 State of Software Security report, published 24 February 2026 and based on 1.6 million applications, shows the scale. It reports that 82% of organizations carry security debt, up 11% on the prior year, and that 60% of those carry critical debt. High-risk vulnerabilities rose 36% year on year. Of 141.3 million raw findings, only 11.3% posed real-world danger. Veracode is a security vendor and the figures describe the applications it analyzed, so treat them as one large dataset, not a census. The direction is still clear. Finding volume is not the bottleneck.

Exposure to attackers is real. Mandiant’s M-Trends 2026 found exploits were the top initial infection vector for the sixth year running, at 32% of intrusions. Verizon’s 2026 Data Breach Investigations Report puts vulnerability exploitation at 31% of breaches. Verizon’s data, as summarized by Help Net Security, also says only 26% of CISA Known Exploited Vulnerabilities were fully remediated across about 13,000 organizations, with a median of 43 days to patch. That figure covers vulnerabilities in general, not only application code. It still shows how slowly known problems close.

Seven handoffs where it breaks

The pattern below is our assessment. The OWASP Top 10:2025 categories cited are real, but OWASP does not rank handoffs. We use them to show which weaknesses tend to sit at each seam.

NIST’s Secure Software Development Framework, SP 800-218 version 1.1, is organized into four groups: prepare the organization, protect the software, produce well-secured software, and respond to vulnerabilities. Its structure makes the same point. Secure development spans the organization, and no single stage owns it.

What “handed off” should mean

A finding has been handed off only when four things are true.

1. It has a named owner. A team that still exists, and that owns the service.

2. It has a stated priority and the reason for it. Known exploitation, internet exposure and data sensitivity matter more than a severity score alone.

3. It has a due date. One set by exposure, not by whichever queue it landed in.

4. It has a closure test. Someone verifies the fix. Closing a ticket is not proof.

Here is a hypothetical. A scanner flags an injection flaw in an internal API. The ticket goes into a shared queue labeled “security”. The owning team is reorganized and nobody picks it up. Three months later, a new gateway exposes the API to partners. Each step was reasonable. The finding never had an owner, so nobody noticed the risk had changed.

What to change

• Run one backlog. Scanner findings, penetration test results, runtime incidents and dependency alerts go into the work queue developers already use.

• Prioritize before you hand off. Security owns triage. Developers should receive the fraction of findings that matter, with the reason.

• Tie ownership to a service catalog. Every application and every dependency class maps to a team. When teams reorganize, ownership is reassigned the same day.

• Set remediation targets by exposure. Internet-facing code with known exploitation gets the shortest clock.

• Measure the handoff, not the finding count. Track time from finding to verified fix, by team. A falling count with a rising age is a warning sign.

• Move the same logic upstream. CISA’s secure-by-design guidance argues that the security burden should not fall mainly on customers, and that suppliers should take ownership at executive level. Inside a company, the same logic applies to security teams and developers. If security hands over findings without owning the outcome, the burden lands on the team least equipped to carry it.

What this evidence does not show

Scanner findings depend on tool configuration, so raw counts are not comparable between organizations. The Veracode and Verizon figures describe different populations and should not be combined. And no cited source measures how much handoff failure alone contributes to unfixed flaws. That link is our reading of the evidence.

Trace twenty findings

Take your last twenty high-severity findings. For each, record who owns it, who set its priority and why, what the due date was, and how closure was verified. Every blank is a handoff that failed. The pattern across the blanks will show you which seam to fix first.

Sources

1. Veracode. 2026 State of Software Security Report (24 February 2026)

2. OWASP. OWASP Top 10:2025

3. NIST. Secure Software Development Framework (SSDF), SP 800-218

4. CISA. Secure by Design

5. Google Cloud / Mandiant. M-Trends 2026: Data, Insights, and Strategies From the Frontlines (23 March 2026)

6. Verizon. 2026 Data Breach Investigations Report

7. Help Net Security. Verizon DBIR: Vulnerability exploitation is the dominant initial access vector