Application Security Statistics Guide: Breach, Weakness, Dependency and Remediation Data

Application security teams are asked to justify budgets and priorities with numbers, yet most AppSec statistics in circulation are recycled from roundup pages with no traceable source. This page collects application security figures only from primary publishers: the Verizon 2026 Data Breach Investigations Report (DBIR), the OWASP Top 10:2025 dataset, CISA's Known Exploited Vulnerabilities (KEV) catalog, Black Duck's OSSRA 2026, Sonatype's 2026 State of the Software Supply Chain, Veracode's State of Software Security 2026, GitHub's Octoverse 2025 and GitGuardian's State of Secrets Sprawl 2026. Each figure names its publisher and period so you can quote it safely and refresh it when the next edition lands. It is for AppSec leads, CISOs and analysts building board papers, programme cases and metrics. For the wider picture see the Cybersecurity Statistics Guide.

Last reviewed: October 2026.

Key takeaways

• Exploited vulnerabilities lead breach entry. The Verizon 2026 DBIR finds exploitation of vulnerabilities was the initial access vector in 31% of breaches, ahead of credential abuse at 13%.
• Fixing is getting slower where it matters most. The same DBIR reports only 26% of critical KEV-listed vulnerabilities fully remediated in 2025, down from 38%, with the median time to full resolution up from 32 to 43 days.
• Broken access control is the most common weakness class. OWASP Top 10:2025 data from over 2.8 million applications keeps A01 Broken Access Control at number one, and GitHub's Octoverse 2025 reports it overtook injection as the top CodeQL alert.
• Dependencies carry most of the risk surface. Black Duck's OSSRA 2026 found open source in 98% of audited codebases and high-risk vulnerabilities in 78%; Sonatype identified more than 454,600 new malicious packages in 2025.
• Secrets in code keep growing. GitGuardian counted 28,649,024 new secrets in public GitHub commits in 2025, and found 32.2% of internal repositories contain at least one hardcoded secret.

Headline statistics

Breaches and how applications are attacked

The Verizon 2026 DBIR analysed more than 31,000 incidents, including more than 22,000 confirmed breaches, covering 1 November 2024 to 31 October 2025 (check the full report for country coverage). Three findings matter most for application teams:

• Exploitation overtook credentials: exploitation of vulnerabilities, at 31% of breaches, is now the most common initial access vector, with credential abuse falling to 13%. Internet-facing applications and the components inside them are therefore the front door.
• Web application attacks are a steady tenth: the Basic Web Application Attacks pattern accounts for about 10% of breaches in the 2026 pattern chart; check the full report before quoting it.
• Supply chain exposure is rising: third-party involvement reached 48% of breaches, which the DBIR describes as up 60% on the previous dataset.

The DBIR also links application risk to AI use: it reports that, in its data loss prevention dataset, source code was the most common data type submitted to unauthorised generative AI tools. See the Data Breach Statistics Guide for cost and sector figures.

Weakness prevalence: the OWASP Top 10:2025 dataset

OWASP built the 2025 list from data on over 2.8 million applications contributed by testing organisations, plus a community survey that promoted two categories. OWASP analysed 589 CWEs in the dataset (up from almost 400 in 2021 and about 30 in 2017) and mapped 248 CWEs into the ten categories. For exploit and impact scores it used around 175,000 CVE records mapped to CWEs in the NVD, covering 643 unique CWEs. Incidence rate means the share of tested applications with at least one instance of a mapped CWE, not the number of findings.

Note: OWASP's introduction and category pages give slightly different CWE counts for A03 and A05, so they are omitted here; all other values are from the OWASP category data tables.

• Supply chain is under-tested: A03 has the fewest occurrences but the highest average weighted exploit (8.17) and impact (5.23) scores, and only 27.47% average testing coverage. OWASP says it believes the low presence reflects testing difficulty. See the OWASP Top 10 A03 Guide.
• Injection has the most CVEs: 62,445 CVEs map to A05 CWEs, the largest of any category. See the OWASP Top 10 A05 Guide.
• Access control leads by occurrence: 1,839,701 applications had at least one A01 CWE. See the OWASP Top 10 A01 Guide.

GitHub's Octoverse 2025, covering September 2024 to August 2025, reports the same shift in its own telemetry: Broken Access Control overtook Injection as the most common CodeQL alert, though Injection still dominates JavaScript.

Which weaknesses get exploited: CISA KEV

The KEV catalog lists vulnerabilities CISA has evidence of being exploited. NHI Mgmt Group analysed the catalog at version 2026.10.21 (1,754 entries) by the CWE fields CISA records.

• Additions by year: 187 in 2023, 186 in 2024, 245 in 2025 and 270 in 2026 up to 21 October.
• Ransomware link: CISA marks 361 of the 1,754 entries as known to be used in ransomware campaigns.
• Reading the table: command injection, path traversal and deserialisation, classic web and API weaknesses, dominated 2025 additions alongside memory-safety flaws. The "n/a" cells were outside the top six for 2025.

See the Vulnerability and Exploitation Statistics Guide for CVE volumes and time-to-exploit data.

Open source dependencies and malicious packages

OSSRA 2026 audited 947 codebases comprising 2,843 projects between November 2024 and October 2025 from software audits, and Black Duck describes the results in terms of commercial codebases, so treat it as a view of audited commercial software rather than of all code. See the Supply Chain Attack Statistics Guide and the Open Source Security Guide.

Secrets in source code

• Volume: GitGuardian's State of Secrets Sprawl 2026 (5th edition) counted 28,649,024 new secrets in public GitHub commits in 2025.
• Persistence: of valid secrets detected in 2022, 64% were still valid four years later.
• Private is worse than public: 32.2% of internal repositories contained at least one secret, against 5.6% of public repositories, which GitGuardian summarises as internal repositories being six times more likely to hold hardcoded secrets.
• AI services: 1,275,105 secrets for AI services were exposed, with 81% year-on-year growth, and GitGuardian reports AI-assisted commits leak secrets at about twice the baseline rate.

Hardcoded credentials are non-human identities; see the Non-Human Identity and Secrets Statistics Guide and the Git Secret Scanning Guide.

Remediation and security debt

The DBIR and GitHub figures point in different directions because they measure different things: the DBIR tracks critical, exploited vulnerabilities across organisations' estates, while Octoverse averages fix times for alerts in GitHub repositories, where automated pull requests do much of the work. Veracode's 2026 landing page also headlines a 36% surge in high-risk vulnerabilities without publishing the base; quote it only with that caveat.

What the numbers mean for AppSec programmes

• Prioritise exploitable over numerous: with exploitation at 31% of breach entry and only 26% of critical KEV flaws fully fixed, a KEV-first remediation queue beats a CVSS-sorted backlog.
• Invest in access control testing: A01 tops both OWASP's data and GitHub's CodeQL alerts; authorisation checks need dedicated tests, not only scanner coverage.
• Treat dependencies as code you own: 92% of audited codebases carry components four or more years old; budget upgrade work, not just alerts.
• Block malicious packages before install: with hundreds of thousands of new malicious packages a year, almost all on npm, registry proxies, release-age gates and install-script controls matter more than post-install scanning.
• Scan private repositories first: internal repositories are where secrets concentrate.

Methodology notes and caveats

• Different denominators: DBIR percentages are shares of breaches; OWASP incidence is a share of tested applications; OSSRA is a share of audited codebases. Never compare them directly.
• Sample bias: OSSRA data comes from audited commercial codebases; OWASP data comes from organisations that test, which under-represents what is hard to test (A03, A09).
• Vendor reports: Veracode, Black Duck, Sonatype, GitHub and GitGuardian publish data from their own platforms. They are primary for their datasets but not neutral samples of all software.
• Our KEV analysis: counts are NHI Mgmt Group's own tally of CWE fields in catalog version 2026.10.21; entries can carry more than one CWE and some carry none.
• Refresh cycle: DBIR, OSSRA, Sonatype, Veracode, Octoverse and GitGuardian publish annually; KEV changes weekly. Check the edition year before quoting.

Common failure patterns

• Quoting roundup pages: statistics with no publisher, year or sample size cannot be defended in a board paper.
• Mixing editions: combining a 2024 figure with a 2026 trend line produces a false story.
• Treating incidence as frequency: 3.74% of applications having a Broken Access Control CWE does not mean 3.74% of findings are access control.
• Using averages as targets: a 26-day average fix time says nothing about your critical, internet-facing flaws; set targets by exploitability.
• Ignoring what the data cannot see: under-tested categories such as supply chain and logging look small in testing data and large in incidents.

Lessons from incidents

Two incidents in the NHI Mgmt Group breach database show what the aggregate numbers look like in practice:

• Malicious packages on npm: the Shai-Hulud npm Worm ran through a preinstall script and harvested GitHub, npm and cloud credentials from files, environment variables and metadata services. It is one campaign behind the kind of volume Sonatype reports, and its targets are the secrets GitGuardian keeps finding in repositories.
• Build tooling as a dependency: in the tj-actions/changed-files Compromise, a stolen bot token was used to repoint the action's version tags to a malicious commit, exposing CI/CD secrets. Testing data such as OWASP's under-represents this class (A03 average coverage 27.47%), yet the DBIR's 48% third-party involvement figure shows how often it reaches breaches.

The common thread is credentials: in both cases a non-human identity (a publishing token or bot token) turned a dependency into a delivery channel. Programmes that measure only vulnerability counts miss that path entirely, which is why secrets and dependency metrics belong in the same dashboard as scanner findings.

Using these figures in your programme

Practitioner checklist

• Quote every figure with publisher, report name and period, as in the tables above.
• Check for a newer edition before reusing a figure older than twelve months.
• Measure your own KEV remediation rate and median fix time, and compare with the DBIR benchmark.
• Track the share of applications tested for access control and supply chain weaknesses, not only finding counts.
• Report dependency age alongside vulnerability counts.
• Scan internal repositories for secrets and track how many remain valid.
• Keep denominators separate when presenting breach, application and codebase percentages.
• Refresh this evidence base each year when DBIR, OSSRA and OWASP data change.

Standards and references

• Verizon: 2026 Data Breach Investigations Report, Executive Summary
• OWASP: Top 10:2025
• CISA: Known Exploited Vulnerabilities Catalog
• Black Duck: Open Source Security and Risk Analysis 2026
• Sonatype: 2026 State of the Software Supply Chain, Open Source Malware
• Veracode: State of Software Security 2026
• GitHub: Octoverse 2025
• GitGuardian: State of Secrets Sprawl 2026

Related NHI Mgmt Group resources: Application Security Guide · Vulnerability and Exploitation Statistics Guide · Supply Chain Attack Statistics Guide · AI Security Statistics Guide