How reliable are these statistics, given they come from vendors and industry reports?

Treat each figure as a well-lit sample rather than a census: every report measures the population it can see, which is usually the customers or scan data of whoever published it. That is why this page attributes every number to its named source (IBM, Verizon, Synopsys, Veracode, and the rest) so you can check the methodology yourself. The direction and rough magnitude are what matter, not the third decimal place.

Why do the reports cited here span several different years?

Because each figure is quoted from the specific edition that published it, rather than rounded up to look current. Some studies, like Stripe's Developer Coefficient and the CISQ cost estimate, have not been rerun annually, while reports like IBM's and Verizon's ship new editions every year. When you reuse a number, cite the edition it came from and check whether a newer one exists.

Do breach-cost averages like IBM's really apply to a small company?

Not directly. Averages from large-sample breach studies are pulled around by big incidents at big organizations, so a small team should not read the headline dollar figure as a personal forecast. The transferable lessons are directional: flaws are common, they take a long time to surface on their own, and later discovery costs more than earlier discovery.

What is the single most useful takeaway from these numbers for an engineering team?

That the baseline expectation for an unaudited codebase should be "there is something in here," not "we are probably fine." Veracode's scan data found roughly three-quarters of applications contained at least one security flaw, and the OWASP Top 10 shows the same handful of mistakes recurring for decades. Assume presence, then go looking.

How should we act on these statistics without overreacting?

Statistics describe populations; your codebase is a sample of one, and the only way to know which findings apply to you is to have someone read it. The cheap version of that is exactly what this site offers: a Webisoft engineer manually reviews your repository, free, and emails a prioritized written findings report within a few business days. Panic is not required, but neither is waiting for an incident to force the question.

Code Security and Quality: Key Statistics

Why a stats roundup

Arguments about code quality tend to run on vibes: one person feels the codebase is fine, another feels it is a time bomb, and the loudest voice wins. Numbers settle some of those arguments. This page collects the most useful public statistics on software security, code quality, technical debt, dependency risk, and AI-generated code, with every figure attributed to the named report that published it.

One caveat: industry reports measure the populations they can see, so treat each figure as a well-lit sample rather than a census. The direction and rough magnitude are what matter.

The headline numbers

Figure	Finding	Source
$4.88 million	Global average cost of a data breach	IBM Cost of a Data Breach Report, 2024
258 days	Average time to identify and contain a breach	IBM Cost of a Data Breach Report, 2024
68%	Share of breaches involving a human element	Verizon Data Breach Investigations Report, 2024
~180% growth	Year-over-year rise in breaches starting from vulnerability exploitation	Verizon DBIR, 2024
96%	Share of scanned commercial codebases containing open source	Synopsys OSSRA, 2024
84%	Share of those codebases with at least one known open source vulnerability	Synopsys OSSRA, 2024
$2.41 trillion	Estimated annual cost of poor software quality in the US	CISQ, 2022
~42%	Share of the developer week spent on maintenance, debt, and bad code	Stripe Developer Coefficient, 2018

The rest of this article unpacks these by theme.

What breaches actually cost

IBM’s Cost of a Data Breach Report 2024 put the global average cost of a breach at 4.88 million dollars, the highest figure in the report’s history and roughly a 10 percent jump over the prior year. The same report found breaches took an average of 258 days to identify and contain. That is most of a year during which the flaw sat in production doing damage.

Two findings from that report matter specifically for engineering teams. First, breaches that took longer to find cost substantially more. Second, organizations that made extensive use of security automation and AI in their defenses saved an average of about 2.2 million dollars per breach compared with those that used none. Tooling helps; the question is whether anyone is looking at what the tooling misses, which is the case for a manual review on top of scanners.

How attackers get in

The Verizon Data Breach Investigations Report 2024 found the human element involved in 68 percent of breaches: phishing, stolen credentials, plain error. But the sharpest movement in that edition was on the code side. Exploitation of vulnerabilities as the initial way into an organization grew by roughly 180 percent year over year, driven in large part by the mass exploitation of the MOVEit file transfer flaw. When one vulnerable dependency can compromise thousands of downstream organizations at once, the attack path runs through your codebase whether you wrote the flaw or imported it.

On what those flaws look like: the OWASP Top 10 2021 moved Broken Access Control into the number one position, based on testing data across hundreds of thousands of applications. Injection, the category that includes SQL injection, remained near the top decades after it was first documented. These are not exotic bugs. They are the same handful of mistakes, made repeatedly, in new codebases.

Veracode’s State of Software Security 2023 report, drawn from scans of hundreds of thousands of applications, found that roughly three-quarters of applications contained at least one security flaw. The baseline expectation for an unaudited codebase should therefore be “there is something in here,” not “we are probably fine.”

Open source and dependency risk

Modern applications are mostly other people’s code. The Synopsys Open Source Security and Risk Analysis (OSSRA) 2024 report, based on audits of over a thousand commercial codebases, found that 96 percent contained open source components, 84 percent contained at least one known open source vulnerability, and 74 percent contained high-risk vulnerabilities, a sharp rise from the prior year. The same report found that the large majority of codebases contained components that were significantly out of date or no longer receiving development at all.

The supply itself is also under attack. Sonatype’s State of the Software Supply Chain report 2023 logged more malicious open source packages in that single year than in all previous years it had tracked combined, reflecting a deliberate shift by attackers from finding vulnerabilities to planting them. Verizon’s DBIR 2024 echoed the downstream effect, reporting that breaches involving a third party rose sharply year over year.

The practical takeaway is that your dependency manifest is part of your attack surface and it decays on its own schedule, not yours. We cover what a reviewer actually checks in auditing third-party dependencies.

Technical debt and code quality

Security flaws get the headlines; quality problems get the payroll. The Consortium for Information and Software Quality (CISQ) estimated in its 2022 report that poor software quality cost the United States about 2.41 trillion dollars that year, with the accumulated principal of technical debt estimated at roughly 1.52 trillion dollars on top.

At the level of a single team, Stripe’s Developer Coefficient study (2018) found developers spending around 42 percent of their working week dealing with maintenance, technical debt, and bad code rather than building anything new. If you have ever wondered why a six-person team ships like a three-person team, that is the arithmetic. What debt is, how it compounds, and how an audit puts numbers on yours is covered in technical debt explained.

AI-generated code

Adoption is no longer the question. GitHub’s 2023 developer survey found 92 percent of US-based developers already using AI coding tools at work, and the Stack Overflow Developer Survey 2024 found 76 percent of respondents using or planning to use AI tools in their workflow. Notably, the same Stack Overflow survey found that well under half of developers expressed trust in the accuracy of those tools’ output.

The security evidence urges caution. A Stanford study (Perry et al., “Do Users Write More Insecure Code with AI Assistants?”, 2022) found that participants with access to an AI assistant produced less secure code on a majority of tasks than those without, and were simultaneously more confident that their code was secure. GitClear’s 2024 analysis of over a hundred million changed lines of code found code churn and copy-pasted code rising alongside assistant adoption, patterns historically associated with lower-quality codebases.

None of this makes AI-generated code unusable. It means it ships with a predictable class of problems that the person who prompted it is least likely to spot, the subject of hidden debt in AI-generated code.

What this means for a small team

Read together, the reports say something simple. Most codebases contain flaws; the ones that hurt take months to surface on their own; the dependency layer is actively hostile territory; and the fastest-growing way of producing code produces overconfident authors. None of that is a reason to panic. It is a reason to have someone who did not write the code read it before an incident forces the issue. If you are weighing that, our FAQ covers how the process works, what it covers, and what it costs (nothing).

Sources

IBM Cost of a Data Breach Report, 2024
Verizon Data Breach Investigations Report (DBIR), 2024
OWASP Top 10, 2021
Veracode State of Software Security, 2023
Synopsys Open Source Security and Risk Analysis (OSSRA), 2024
Sonatype State of the Software Supply Chain, 2023
CISQ, The Cost of Poor Software Quality in the US, 2022
Stripe, The Developer Coefficient, 2018
GitHub developer survey, 2023
Stack Overflow Developer Survey, 2024
Perry et al., Do Users Write More Insecure Code with AI Assistants?, Stanford University, 2022
GitClear, Coding on Copilot / AI code quality research, 2024

Get a free code audit

Statistics describe populations; your codebase is a sample of one. A Webisoft engineer will read it and send you a prioritized, written findings report, free, with no invoice afterwards. Get a free code audit and find out which of these numbers apply to you.