The Hidden Costs Of Ignoring Application Security

By Tony Bradley

Application security has become a strategic issue, not just a technical one. But if the 2025 State of Application Security report is any indication, many organizations still haven’t adjusted. Most teams are overwhelmed, underfunded and often making high-stakes trade-offs without clear risk visibility.

According to the survey, 62% of organizations knowingly ship insecure code. Nearly 80% of security leaders worry that a breach could cost them their job. And perhaps most concerning, over half still wait until the end of the development cycle to involve security—if at all.

This isn’t a tooling problem. It’s a systemic one. It’s a cultural gap. And it’s leaving organizations exposed at a time when application-layer flaws account for 43% of breaches.

AppSec as a Strategic Risk

Software runs the business. Which means vulnerable software puts the business at risk. But while most companies acknowledge that risk, few are resourced to deal with it. Nearly 90% of teams allocate just 11–20% of their security budgets to application security—even as the average breach cost in the U.S. climbs to $9.48 million.

Steve Kosten, director of application security at Cypress Data Defense, calls this a reflection of the industry’s roots. “AppSec is the younger brother of network security,” he told me. “Most security leaders came up through infrastructure. They don’t blink when developers deploy 20 times a day—but they’d lose it if the network team made changes that often.”

The result is predictable: heavy spending on firewalls and perimeter tools, while code-level security remains an afterthought.

Security as a Bottleneck—Still

Here’s the irony: security is supposed to enable innovation. But for many teams, it still shows up too late—and slows things down.

I know I’m dating myself–but when I was a security architect at EDS 20 years ago, one of my responsibilities was to conduct a final security review before an application was cleared for release. The problem? By the time I got involved, the app had already been built. Months of work had been poured into it. So when I found a serious vulnerability, I had two choices: wave it through and hope for the best, or be the bad guy who forced a delay and triggered a costly round of rework.

Neither choice felt good. But that was 2005. What’s astonishing is that in 2025, this is still how many organizations operate. The data backs it up—only 36% of respondents say they involve security during the planning phase. A full 57% wait until right before deployment.

Kosten agrees. “Despite what’s been preached for years, application security is still viewed as a last-minute task,” he says. “As long as organizations lack secure development lifecycles, security issues will continue to show up late and delay releases.”

We’ve had two decades of DevOps, threat modeling and “shift left” evangelism, yet security is still bolted on at the end. And it’s still perceived as a hurdle instead of a partner.

A Culture of Trade-Offs

It’s tempting to see that 62% figure—organizations admitting to knowingly releasing insecure code—as an indictment. But Kosten offers a more nuanced view. “The real issue isn’t whether code ships with vulnerabilities. It’s whether organizations understand the risk they’re accepting,” he says.

He describes three types of organizations: those unaware they’re vulnerable (true failure), those reacting to issues without risk context (survival mode) and those that make informed trade-offs based on thorough risk assessment (success). “True failure occurs when organizations operate without understanding their security posture or the risks they’re accepting.”

Drowning in False Positives

Another key challenge: noise. According to the report, 58% of teams say they’re overwhelmed by false positives from scanning tools. That figure likely undercounts the problem. “Too often, security teams hand off raw scanner output to developers without validation,” Kosten notes. “That leads to two bad outcomes: developers ignoring real issues they don’t understand, or wasting time fixing non-existent problems.”

To address the noise, he suggests tuning tools to the application’s context, prioritizing real risk and considering external support. “Managed service providers who do this every day are often better equipped to validate results quickly and accurately,” he says.

Still Struggling with the Basics

Despite broad awareness, foundational issues like the OWASP Top 10 remain unresolved for nearly half of organizations. That’s not necessarily due to negligence. As Kosten points out, OWASP categories have grown broader and more complex over time. “Fixing entire classes of vulnerabilities isn’t trivial—especially for under-resourced teams.”

He also points to the misplaced view of security as a compliance requirement rather than a design principle. “When security is bolted on at the end to satisfy audit checkboxes, the result isn’t secure software. It’s duct tape.”

The Case for External Support

The report reveals that 83% of security professionals are open to outsourcing at least part of their AppSec program. That’s not a sign of failure—it’s a recognition that modern development cycles demand support beyond what most internal teams can manage.

Managed AppSec providers bring not just capacity but specialization—experience with tools, languages and threat models that change constantly. Kosten sees their value in complementing internal teams: “Let external partners handle validation and scanning. That frees up your team to focus on secure design and developer engagement.”

Where We Go from Here

Application security isn’t getting easier. AI-generated code is already introducing new vulnerabilities, and attack tactics are evolving just as fast. Most organizations aren’t scaling security teams to match.

But the fix isn’t more tools. It’s better integration. Better visibility. And a cultural shift that frames AppSec as a business enabler, not a roadblock.