DevSecOps Statistics 2026: The Numbers, With Their Populations
If you pulled a breach-cost figure from a DevSecOps round-up this year, check its edition. Spacelift's 2026 page dates its $4.88 million figure to 2024, and AppSecSanta's at-a-glance table leads with $4.44 million labelled IBM 2025. IBM's 2026 report puts the global average cost of a data breach at USD 4.99 million, up 12% and a record high. That is the number to use now.
The statistics below are the ones you can cite today. Each carries its population, period, source and evidence type. Most come from vendor telemetry or self-reported surveys, and the later sections say where that limits what you can claim.
Key DevSecOps statistics for 2026
Global average cost of a data breach: USD 4.99 million, up 12% and a record high, among 602 organizations breached between March 2025 and February 2026 (IBM, Cost of a Data Breach Report 2026). Evidence type: benchmark study of breached organizations.
One in four malicious breaches were AI-enabled, and those breaches averaged USD 6 million (IBM newsroom, 29 July 2026). Same study population.
Organizations reporting extensive use of AI and automation in security reported average breach costs USD 1.93 million lower than those using none (IBM, same report). An association in a benchmark study, not a measured saving.
82% of critical dependency vulnerabilities fall below critical once Datadog recomputes CVSS with runtime and exploit context, leaving 18% critical (Datadog State of DevSecOps). Population: applications instrumented by Datadog Code Security, data through January 2026. Modelled reclassification.
87% of organizations have at least one known exploitable vulnerability in deployed services, affecting 40% of services (Datadog, January 2026 extraction, same population).
10% of services run at least one end-of-life language or runtime: Go 23%, PHP 13%, Java 10% (Datadog, same population).
Only 4% of organizations using GitHub Actions pin the hash for all marketplace actions; 71% pin none (Datadog). A separate cohort: static-code findings through December 2025 plus CI Visibility data through January 2026.
32% of organizations have pulled a public Docker image within one day of its creation (Datadog product telemetry, its customer base).
Open source downloads reached 9.8 trillion in 2025 across Maven Central, PyPI, npm and NuGet, up 67% year over year (Sonatype, software infrastructure chapter; Sonatype press release, 28 January 2026). Downloads measure consumption, not users.
Sonatype's research corpus holds more than 1.233 million malicious open source packages, a cumulative count rather than the number published in 2025 (Sonatype press release).
82% of organizations carry security debt, which Veracode defines as flaws left unresolved for over a year after discovery, and which it describes as an 11% relative increase in one year (Veracode, 2026 State of Software Security, 24 February 2026).
74% of surveyed organizations said security concerns slowed or delayed application releases in the 12 months before fieldwork (Red Hat, state of cloud-native security, 2026 edition). Self-report from 600 respondents, fieldwork 25 August to 23 September 2025.
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.
The breach-cost number reset in 2026
IBM's 2026 edition puts the global average at USD 4.99 million, a 12% rise and the highest figure the series has reported. The sample is 602 organizations that suffered a breach between March 2025 and February 2026. So the figure describes breached organizations, not total breach spending and not the cost of running DevSecOps.
IBM's newsroom release adds a subgroup. One in four malicious breaches were AI-enabled, which IBM describes as "a 56% increase over last year". Those breaches averaged USD 6 million, roughly USD 1 million above the overall average. IBM does not define the base for the 56%, so you cannot tell whether it measures a change in share or in count. Quote it as IBM words it, and don't present it as growth in attack volume.
The USD 1.93 million gap is an association. Breached organizations reporting extensive AI and automation use in security reported lower average costs than those reporting none. The study is observational, so it shows what those organizations looked like, not what automation would save your team.
Severity scores are not risk scores
Datadog's recomputation model changes which vulnerabilities count as critical. Non-production services get confidentiality, integrity and availability impact set to low. Services without internet exposure get a network attack vector reset to local. Vulnerabilities with an EPSS score below 1% get attack complexity set to high. Scores are then recomputed under CVSS v3.1. Under that model, 18% of critical dependency vulnerabilities stay critical, so 82% fall below the threshold. The 82% is simply the complement of Datadog's own 18%.
This is a modelled reclassification inside one vendor's customer base. It is not a false-positive rate, and it says nothing about whether the remaining 18% are exploited.
A separate Datadog measurement has different denominators: 87% of organizations have at least one known exploitable vulnerability in deployed services, and those vulnerabilities sit in 40% of services. "Known exploitable" means a public exploit exists, not that the service was attacked. Datadog draws its exploit data from CISA KEV, NIST, ExploitDB and GitHub Advisories, extracted in January 2026.
Prevalence varies by language. Datadog reports known exploitable vulnerabilities in 59% of Java services and 47% of .NET services. The median count of high-or-critical SCA findings per affected application fell to 8 from 13.5 a year earlier. That moves opposite to the dependency-age finding below, so read the two side by side.
Dependencies age faster than teams deploy
Datadog's headline says dependencies run 278 days behind their latest major version. Its methodology defines the measure as the number of days since the latest update to the current major version of a library was released. The two wordings describe different things, and both appear on the page. This article uses the methodology wording. The measure covers versioned third-party libraries in applications instrumented by Datadog Code Security, measured in January 2026, and excludes public libraries. It describes that instrumented population, not all organizations and not all code.
The median rose from 215 days. Java was furthest out at 492 days and Ruby at 357. Services deployed less than once a month ran dependencies 295 days old on median, against 172 days for services deployed daily. Datadog's bands are at least 100 deployments in six months for daily, at least 26 for weekly, at least 6 for monthly, and fewer for less than monthly.
That gap is a correlation. Datadog calls deployment frequency "both a productivity metric and a meaningful security control", but the data can't show that deploying more often would fix a given service.
Old runtimes compound the problem. Where an organization runs an end-of-life version of a language, 50% of services in that language carry an exploitable vulnerability, against 37% where no end-of-life version is in use. Datadog attributes the high Go rate to a one-year support window, against four years for PHP.
The pipeline is where the numbers stop being opinions
Pinning is the clearest pipeline control in this data. Datadog finds that 4% of organizations using GitHub Actions pin every marketplace action to a hash, and 71% pin none. That cohort is not the SCA population. It combines static-code findings carrying the github-actions/unpinned-actions rule through December 2025 with CI Visibility data through January 2026, and covers only actions built on a standard template (run, post, build). Separately, 32% of organizations have pulled a public Docker image within a day of its creation.
Sonatype's registry data is the largest consumption figure here: 9.8 trillion downloads in 2025, up 67%. Its methodology says downloads are "treated as a consumption signal (what build systems actually pull), not as a proxy for unique users". Read every download figure in this genre with that sentence in mind.
The same release reports that Log4Shell still drew 42 million downloads in 2025, years after fixed Log4j versions existed. That shows remediation lag in consumption data rather than in a survey. It also reports that 86% of Maven Central traffic came from cloud service providers. That is a consumption mix, largely automated builds repeating pulls, not 86% of organizations.
Sonatype also tested an LLM on open source component selection. Across 37,000 recommendations for enterprise applications, GPT-5 hallucinated 27.8% of component versions, and without real-time intelligence it suggested real malware packages. This is one vendor's experiment on one model and one modelled upgrade task, with application scans sampled June to August 2025. It isn't an error rate for AI coding tools in general.
Security debt, and the claim it does not support
Veracode reports that 82% of organizations carry security debt, defined as flaws left unresolved more than a year after discovery, and that critical security debt affects 60%. It describes the first as an 11% increase and the second as a 20% increase from 2025. Both are relative changes in Veracode's framing. The blog gives neither the prior-year percentages nor the sample or measurement period.
The genre's usual next step is to say debt is "growing faster than it is being fixed." The evidence doesn't support that. A rising share of organizations holding year-old findings describes prevalence, not how fast findings are opened or closed. Veracode's blog gives no fix-throughput series, and no source behind this article publishes comparable opening and closure rates or a median remediation time. Treat the security-debt numbers as a count of organizations with old findings, and nothing more.
Delivery friction and where the data stops
Red Hat's 74% is the one practice figure here that comes from neither a security vendor's telemetry nor a mobile vendor. It is self-report. Respondents were 600 IT professionals at companies with 100 or more employees, surveyed online from 25 August to 23 September 2025 through expert networks and online panels, and responsible for applications, security, platforms or development. The edition is labelled 2026, but the figure describes late-2025 opinion about release delays. It is not a DevSecOps adoption rate, not a measured deployment delay, and it doesn't show that security tooling caused the delay.
Mobile is where the evidence is thinnest. NowSecure reports that authenticated scans surfaced 7.23 sensitive-data findings per scan on average, against 4.07 for unauthenticated scans, which it describes as 78% more (NowSecure, 25 February 2026). The population is about 105,000 mobile app assessments, roughly 5,000 authenticated and 100,000 unauthenticated, across Android and iOS, using the same 520-plus checks in both groups. The comparison is observational. Identical checks don't show that the same apps were tested both ways, that the groups were matched, or that findings were validated as true positives. NowSecure doesn't state the scan window, and 105,000 assessments are not 105,000 apps.
NowSecure's separate 2026 survey adds two figures. 68% of 485 senior mobile application security leaders said more than half their mobile application code consists of third-party SDKs and libraries, and 37% said their organization has not implemented AI behavioural monitoring as a security control (NowSecure press release, 29 June 2026). Respondents led mobile security at North American finance, healthcare, high-tech and retail organizations with 1,000 or more employees, surveyed by a research agency in April and May 2026, with a stated margin of error of ±4% at 95% confidence. That is a compensated panel of large enterprises, and the 68% is self-estimated, not measured code share. The release gives two different figures for formal AI governance policies, 99% and 74%, so none of its governance numbers appear here.
What's missing from the public record is a specific measurement. No source behind this article publishes a matched comparison of failure types between physical devices and emulators, or between authenticated and unauthenticated runs of the same apps, with its method and denominator. None measures which failures appear only on hardware, or how long a seeded regression takes to surface. Quash (our product) is a mobile-first testing platform and has no first-party data on this question either. It has designed three studies that would address it: failure causes across maintained open-source Android apps, the same suite on emulators versus physical devices, and time to surface for a seeded regression. None has been run, so no result exists to cite. For adjacent QA-side numbers, see Quash's State of QA Automation 2026 report.
Conclusion
Lead with IBM's USD 4.99 million, state the 602-organization base, and say it describes breached organizations. When you quote Datadog's 18% and 87% together, say they answer different questions: one about a severity model, the other about exploit availability. Quote Sonatype's downloads as consumption and Red Hat's or NowSecure's percentages as what respondents said. The claims you most want to make, about remediation speed and about what actually breaks in shipped apps, are the ones none of these sources measures, so don't borrow a number to fill that gap.
Methodology and how to cite these figures
IBM's Cost of a Data Breach Report 2026 is a benchmark study of 602 breached organizations, sponsored and analysed by IBM and conducted by the Ponemon Institute, covering breaches from March 2025 to February 2026. Datadog's State of DevSecOps is product telemetry from applications instrumented by Datadog Code Security and its CI Visibility product, extracted in January 2026 and updated in February 2026. Its population is Datadog's customers, not the market.
Sonatype's 2026 Software Supply Chain Report is registry telemetry. Its methodology states that downloads are not unique users, and the malicious-package figure is a cumulative research corpus. Veracode's 2026 State of Software Security is summarised in a blog that doesn't state sample or measurement period. Red Hat surveyed 600 respondents between 25 August and 23 September 2025. NowSecure's blog compares about 105,000 assessments in two groups, and its press release reports a survey of 485 leaders in April and May 2026.
When you cite a figure, keep its shape: metric, population, period, source and evidence type. Cite the publisher's own page, and quote its population and period in the same sentence. Competitor round-ups are useful for finding what to check, but their figures are their own claims.
Several sources could not support figures for this edition. Safeguard's 2026 DevSecOps maturity benchmark reports remediation and SBOM percentages, but its stated research period conflicts with its publication date. GitLab's developer survey and the OpenSSF cyber-resilience awareness report give sample sizes without usable adoption percentages. ENISA's SBOM adoption study offers a qualitative conclusion, that the CRA acts as an accelerator, and no extractable adoption rate. Black Duck's report page returned a not-found response, and the ACM literature review returned an access-denied response. As a result, no SBOM adoption rate and no remediation-time median appear here.
Continue reading
More articles from the Quash editorial desk.
