Somewhere in your organization's next incident report, a number is waiting to be written down. Globally, it averages $4.44 million per breach — and if your organization is based in the US, that figure more than doubles. None of that money goes toward anything productive. It's detection, containment, legal exposure, customer notification, and the slow bleed of lost business that follows a breach long after the incident itself is closed.
What rarely makes it into the board deck is where that cost actually originates: a line of code, written by a developer, that nobody caught before it shipped.
-
The Direct Cost Is Only the Opening Number
The headline breach figure is the easiest cost to point to, and also the least representative of the full picture. Vulnerability exploitation has become the second most common way attackers actually get in — up 34% year over year, overtaking several attack vectors that used to dominate the conversation. That's not a statement about attacker sophistication so much as it's a statement about supply: there's more exploitable code in production than there used to be, and attackers have simply followed the path of least resistance.
Detection speed compounds the number further. Breaches caught within 200 days run meaningfully cheaper than ones that drag past it — a gap of roughly a million dollars, driven almost entirely by how long a vulnerability sits undiscovered before someone notices it's being used against you.
-
The Cost That Never Shows Up as a Single Line Item
The more expensive number is the one nobody puts on a slide, because it never resolves into a single incident. It's security debt — the accumulating backlog of known, unresolved vulnerabilities sitting in production while teams prioritize shipping over fixing.
That debt is getting worse, not better. The average time to fix a security flaw has grown 47% since 2020, now sitting at 252 days — nearly a year of exposure between a vulnerability existing and someone actually closing it. Half of organizations are now carrying what researchers classify as critical security debt, and a majority of it didn't even originate with the team carrying it: it arrived through third-party code, dependencies, and vendors nobody directly reviewed.
Every unresolved vulnerability in that backlog is a bet — a wager that it won't be the one an attacker finds first. Organizations rarely lose that bet on any individual flaw. They lose it in aggregate, once enough of the backlog accumulates that the odds catch up.
-
The Human Factor Is the Real Multiplier
It's tempting to frame insecure code as a tooling problem — better scanners, better static analysis, better automated gates. Those help, but they're catching what a developer already missed. The human element is present in roughly 60% of breaches, and a meaningful share of that isn't malicious at all — it's a developer who didn't recognize a vulnerability class when it was sitting in front of them during a code review.
This is where most secure coding programs quietly fail: they train awareness (developers can define SQL injection) without verifying skill (developers can find one in a real codebase before it ships). The two aren't the same thing, and the gap between them is exactly where the security debt above comes from. A team that's confident in its secure coding posture because everyone passed an annual training video is, in practice, running on an unverified assumption.
-
Third-Party Code Multiplies the Exposure
None of this stays contained to your own developers. Third-party involvement now shows up in roughly half of all breaches, a sharp year-over-year jump, and remediation follow-through on flagged third-party issues is poor — most flagged gaps never get fully closed. Every vendor, contractor, and dependency your organization relies on inherits into your own risk surface, whether or not their developers were ever assessed for the same skill your own team is expected to have.
-
Turning the Cost Curve Around
The organizations pulling their breach costs down aren't doing it by writing bigger checks after an incident — they're doing it by catching the problem earlier, which is structurally cheaper at every stage than remediation after the fact. That starts with actually verifying secure coding skill rather than assuming it, the same way you'd verify any other technical capability before trusting it in production.
This is the gap Simulations Labs' Web Security category and broader assessment tooling are built to close — putting developers, candidates, and contractors alike into live, on-demand environments where finding and fixing a real vulnerability is the test, not a proxy for one. Analytics on common wrong attempts and solve rates per challenge turn individual assessments into an organizational signal — showing security leaders exactly where their aggregate exposure actually sits, before an attacker finds it for them.
If security debt has been accumulating quietly in your organization, the applicant assessment model that hiring teams already use for candidates works just as well turned inward, on the team you already have.
