Software Quality Statistics (2026): 10 Numbers That Matter

A release can pass its pipeline, meet its deadline, and still leave you with a security review, a growing maintenance backlog, or a queue of pull requests waiting for attention. If you are making a case for better software quality, the useful numbers are the ones that tell those different stories apart.

The short answer: no single statistic measures software quality. The most useful 2026 evidence combines code-analysis benchmarks, controlled security tests, engineering-workflow data, practitioner surveys, and a dated economic model. Use the figure that fits your question—and keep its population and method attached.

Key software quality statistics

• 71% of code had a low degree of security controls in Software Improvement Group’s (SIG) 2026 enterprise-software benchmark. This is an observed result for SIG’s benchmark population, not a rate for all software.

• 86% of code fell below SIG’s recommended maintainability rating in that 2026 benchmark. This is SIG’s framework classification for its benchmark population, not a universal industry percentage.

• AI-generated code carried roughly twice the security-risk violations of human-written code in SIG’s 2026 code-analysis comparison. It is a comparative benchmark result, not a prediction for every model, repository, or generated snippet.

• Sonar analyzed 7.9 billion lines of code in 2025, from nearly 1 million developers, across seven named languages and against 5,300 quality and security rules, according to Sonar’s State of Code report. This is platform-observed code-analysis scope, not a defect rate.

• 45% of generated-code samples failed security tests in Veracode’s July 2025 evaluation of more than 100 large language models across Java, Python, C#, and JavaScript. This is a controlled security-test result for the tested tasks and criteria.

• 90% of nearly 5,000 technology professionals surveyed by DORA in 2025 said they used AI at work, while 30% reported little or no trust in AI-generated code. Google Cloud’s DORA report announcement presents these as survey responses on adoption and trust, not measured defect rates.

• 57% of QA tests were automated in Sembi’s 2026 Software Quality Pulse Report, a vendor-published survey of nearly 4,000 professionals. Automation share is a testing-practice measure, not a measure of risk coverage.

• 11% of respondents reached Katalon’s “optimized” QA-maturity stage in Katalon’s 2025 report, based on a survey of more than 1,500 QA professionals. “Optimized” is Katalon’s own category, defined using advanced automation or AI.

• AI pull requests waited 4.6 times longer than the manual-PR comparison group before review in LinearB’s 2026 benchmark of more than 8.1 million pull requests from more than 4,800 organizations. This is workflow behavior, not an escaped-defect count.

• CISQ estimated at least $2.41 trillion in U.S. poor-software-quality costs for 2022, including about $1.52 trillion in accumulated software technical debt, in its 2022 cost report. These are modeled economic estimates, not 2026 spending or a count of bugs.

Get the Mobile Testing Playbook Used by 800+ QA Teams

Discover 50+ battle-tested strategies to catch critical bugs before production and ship 5-star apps faster.

Email addressGet Instant Access

100% Free. No spam. Unsubscribe anytime.

What software quality statistics can—and cannot—tell you

These software quality statistics are valuable precisely because they are not interchangeable. SIG and Sonar inspect code through their own rules and scoring systems. Veracode tests generated code against defined security checks. DORA, Sembi, and Katalon report what respondents say they use or observe. LinearB measures pull-request workflow, while CISQ models economic cost.

A code-rule violation is not automatically a production incident, and a survey response about automation is not proof that every critical path is tested. That does not make the figures weak. It means you should match the evidence to the decision: code health, security verification, delivery flow, QA maturity, or financial framing.

Code quality and maintainability signals

SIG’s 2026 benchmark offers the clearest code-health warning in this source set: 71% of code had a low degree of security controls, while 86% fell below SIG’s recommended maintainability rating. SIG also reports that 1.9% of enterprise production code was AI-generated and that technical debt accounted for 21–40% of total IT spending in its benchmark framing. Those are SIG observations and estimates from its own enterprise-software population, rather than a census of every codebase.

Maintainability matters because it describes how difficult your code is to understand, change, and support over time. It should not be used as a substitute label for customer-facing reliability. A maintainability rating can identify future engineering friction before that friction becomes a visible incident.

Sonar supplies scale rather than a universal failure percentage. Its 2025 dataset covered 7.9 billion lines of code, nearly 1 million developers, seven languages, and 5,300 rules. That makes the report a useful view of code visible to Sonar’s platform; it does not make the dataset a random sample of all software written in 2025.

If you need to turn these findings into action, pair a maintainability measure with the test coverage metrics that show whether your highest-risk changes are actually exercised. Code analysis and test coverage answer complementary questions.

Security and AI-generated code

The generated-code security evidence is more specific than a broad claim that AI makes software worse. In Veracode’s July 2025 controlled evaluation, 45% of generated-code samples failed security tests. Within the tested samples, Java had a 72% failure rate, and cross-site-scripting defenses failed in 86% of relevant samples. Those results apply to the study’s more than 100 tested models, four languages, tasks, and security criteria—not every piece of AI-assisted production code.

DORA measures a different part of the same decision. Its 2025 survey found widespread AI use at work alongside a meaningful trust gap: 90% reported using AI, but 30% reported little or no trust in AI-generated code. For you, the practical implication is straightforward: faster code generation does not remove the need for review, testing, and security validation.

SIG’s comparative finding—roughly twice the security-risk violations in AI-generated code than in human-written code—adds a code-analysis signal to Veracode’s test result. Neither source establishes a universal production vulnerability rate. Together, they support a narrower and more useful conclusion: generated code needs verification that is proportionate to the risk of the change.

For a more focused view of adoption, risk, and testing practices around this topic, see Quash’s AI testing statistics and adoption data. That article covers the testing-specific question; this report keeps the wider software-quality lens.

Testing and quality-engineering maturity

Sembi’s 2026 survey reports that 57% of QA tests were automated among nearly 4,000 respondents. It also reports that about 26% of QA teams were mostly or fully integrated with DevOps, while about 22% released daily or more frequently. These are self-reported operational measures from a vendor-published survey, so they describe the surveyed population rather than an industry-wide automation baseline.

The distinction between automation and coverage matters. Automating 57% of tests does not show which user journeys, platforms, environments, or failure modes are covered. If you are deciding what to measure, start with the quality indicators that connect tests to outcomes, such as those in Quash’s guide to QA metrics for software teams.

Katalon’s 2025 survey places only 11% of respondents in its “optimized” stage. Because that stage is Katalon-defined and includes advanced automation or AI, it is best read as a maturity-model result—not as a claim that 89% of all QA organizations are failing.

The World Quality Report 2025–26 adds another survey perspective. It reports that 43% of organizations were experimenting with generative AI in quality assurance and 15% had scaled it enterprise-wide. The same report says 60% struggled with secure, scalable test data and 58% cited challenges adopting AI-powered tools. These are adoption and implementation-barrier responses, not software defect measurements.

Delivery and review signals

Workflow data can reveal where quality work is getting delayed, but it does not directly report what customers experience. LinearB’s 2026 benchmark found that AI pull requests waited 4.6 times longer than the manual comparison group before review, yet were reviewed twice as fast after pickup. It also reports AI-generated pull-request acceptance of 32.7%, compared with 84.4% for manual pull requests.

Those comparisons may point to review uncertainty, changes in PR shape, or workflow policy. They do not tell you how many defects reached production. Use them to investigate your review queue, then pair them with defect, incident, and validation data from your own delivery process.

DX’s July 2026 benchmark update reported a 16.9% improvement in systems-based defect ratio. DX says additional research is needed, so this is a vendor benchmark trend rather than evidence that AI—or any other single factor—caused the improvement.

CircleCI’s 2026 State of Software Delivery page says its analysis covered more than 28 million CI workflows and characterizes AI as exposing a delivery bottleneck. The report is sponsored by Thoughtworks. The workflow volume is useful context for delivery activity, but it is not a comparable defect-rate statistic.

The economic cost of poor software quality

CISQ’s figures remain useful for framing the size of the problem, with an important date attached. Its latest verified cost page models at least $2.41 trillion in U.S. poor-software-quality costs and about $1.52 trillion in accumulated technical debt for 2022. In a 2026 report, that makes the estimate four years old.

The numbers are not a bill you can apply to your organization, and they are not evidence that a given percentage of releases will fail. They are a national economic model. Use them when you need to explain why software quality deserves investment; use your own escaped defects, rework, incidents, and cycle times to decide where that investment goes.

What the public record still does not measure

No source in this set provides a universal software-quality score or a comparable cross-industry census of production defects reaching end users. The available evidence measures proxies: code-analysis findings, controlled security-test outcomes, survey responses, workflow behavior, and modeled costs.

There is also no Quash-specific mobile-app quality-outcome dataset for this report. Quash has not supplied telemetry, customer language, recurring bug patterns, or a completed experiment that would measure mobile production defects on a comparable basis. A useful future benchmark would need to state its app population, device conditions, defect definition, and observation period before it could be compared with these sources.

That gap is worth keeping visible. You should not treat a broad code benchmark as a measure of mobile release quality, or treat a PR-review metric as a measure of customer impact, simply because a universal measure is unavailable.

Methodology and source notes

This report prioritizes first-party benchmark pages, the original publisher’s survey summaries, a controlled vendor security evaluation, and CISQ’s own economic model. Each source represents its own population and method, so the figures should not be averaged into a single score.

Use a code-analysis statistic when you are discussing rule-based code health. Use Veracode’s experiment when the question is generated-code security under its tested conditions. Use DORA, Sembi, Katalon, or the World Quality Report for reported adoption and maturity. Use LinearB, DX, and CircleCI for engineering-system and workflow context. Use CISQ for dated U.S. cost framing.

The decision is not to find one number that settles software quality. It is to choose the statistic that exposes the quality risk you need to improve next.