Security testing priorities are increasingly shaped by real exploitation, not only by theoretical severity. Verizon found exploitation of vulnerabilities rose 180% year over year as a critical-path action initiating a breach in its 2024 DBIR dataset. Mandiant’s 2024 investigations found exploits were the leading initial infection vector at 33%, while the global median dwell time was 11 days. These figures describe different populations and purposes, so they should be read as complementary signals rather than combined measurements.
Contents
- Threat-driven testing priorities
- Zero-day and exploitable vulnerability testing
- Remediation speed and exposure windows
- Software weakness patterns to test
- Vulnerability-scanning data quality
- Open-source supply-chain testing signals
Threat-driven testing priorities
Verizon’s 2024 Data Breach Investigations Report shows why security testing needs to reflect the ways incidents actually begin. Exploitation of vulnerabilities increased 180% year over year as the critical-path action initiating a breach in the 2024 DBIR dataset. Ransomware or other extortion techniques appeared in 32% of breaches: ransomware alone appeared in 23%, and pure extortion accounted for 9%.
The report also places people and process in the testing picture. The human element was present in 68% of breaches, while errors were present in 28%. Ransomware or extortion was among the top threats in 92% of industries covered by Verizon’s 2024 DBIR. Those percentages support testing that spans application behavior, identity controls, user-facing workflows, and operational recovery paths.
Mandiant’s M-Trends 2025 examined its 2024 targeted-attack investigations. Exploits were the most common initial infection vector at 33%, followed by stolen credentials at 16%. The global median dwell time was 11 days. For a security test, that combination makes detection timing and credential abuse important test conditions alongside the presence of a vulnerability.
Zero-day and exploitable vulnerability testing
Google Threat Intelligence Group’s 2025 zero-day review tracked 90 vulnerabilities disclosed in 2025 that were exploited as zero-days. GTIG tracked 100 exploited zero-days disclosed in 2023, its record high in the comparison, and 78 disclosed in 2024. Annual zero-day volume stayed within a 60–100 range during the four years preceding the 2025 review.
The GTIG figures are tracked zero-days, not a census of every vulnerability or every attack. They are useful for deciding where exposure testing should be resilient to incomplete advance notice. In the 2025 dataset, enterprise software and appliances accounted for 43 exploited zero-days, representing 48% of the total. Security and networking products accounted for about 21 of the enterprise-related zero-days, and edge devices accounted for 14.
End-user platforms and products accounted for 47 exploited zero-days in the same dataset. Operating-system vulnerabilities accounted for 39 exploited zero-days, or 44% of GTIG’s 2025 total. A test program can therefore use separate coverage views for enterprise infrastructure, edge devices, operating systems, and end-user products rather than treating “the application” as the only security boundary.
| GTIG measure | Period | Reported result |
|---|---|---|
| Exploited zero-days disclosed | 2023 | 100 |
| Exploited zero-days disclosed | 2024 | 78 |
| Exploited zero-days disclosed | 2025 | 90 |
| Enterprise technologies’ share | 2025 | 48% |
| Operating-system zero-days’ share | 2025 | 44% |
Remediation speed and exposure windows
Security testing is also a test of how quickly an organization can act after a defect becomes actionable. Verizon’s 2024 DBIR analysis found that 50% of critical CISA KEV vulnerabilities were remediated about 55 days after patches became available. About 8% remained open after one year. These are remediation observations for critical CISA KEV vulnerabilities, not a universal service-level target.
The same Verizon analysis found a sharp difference in observed scanning activity. The median time from publication to the first honeypot scan was 5 days for CISA KEV vulnerabilities, compared with 68 days for non-CISA-KEV vulnerabilities. A security test that measures only eventual patch completion can miss the exposure window between disclosure, exploitation attempts, detection, and remediation.
Sonatype’s 2026 State of the Software Supply Chain Report reported that the median time for the National Vulnerability Database to assign a score to open-source CVEs was 41 days in its 2025 analysis. Thirty-five percent of open-source CVEs took more than 90 days to receive a complete NVD record. Developers downloaded more than 42 million vulnerable Log4j versions in 2025; those versions represented 13% of all Log4j downloads worldwide.
These measurements point to two distinct checks: whether a team can identify and prioritize a vulnerability while public metadata is incomplete, and whether dependency controls prevent continued use of a known vulnerable version during the remediation period.
Software weakness patterns to test
MITRE’s 2025 CWE Top 25 key insights analyzed 28,336 total CWE mappings. Allowed mapping recommendations accounted for 22,438 mappings, or 79.19% of the total. Allowed-with-Review recommendations accounted for 4,363 mappings, or 15.40%, while discouraged mapping recommendations accounted for 1,535, or 5.42%. Base-level weaknesses represented 20,351 mappings, or 71.82%.
These mapping figures describe how CVE records were associated with software weaknesses; they are not breach rates. They can still guide test design by encouraging teams to validate the weakness categories most relevant to their own code, interfaces, and deployment patterns rather than relying on a single scanner score.
MITRE’s 2025 CWE Top 25 methodology covered 39,080 CVE records published between June 2024 and June 2025. Its scoped remapping dataset contained 9,468 records, equal to 24% of the full dataset, and included CVEs from 281 different CVE Numbering Authorities. MITRE received feedback on 2,459 of those scoped records, or 26% of the records requested for review. Feedback came from 170 CNAs, or 60% of the 281 contacted.
The review coverage matters when interpreting weakness classifications. A security test report should preserve the boundary of the classification source and avoid presenting a methodology sample as a complete inventory of all software weaknesses.
Vulnerability-scanning data quality
Sonatype’s 2025 analysis found that nearly 65% of the open-source CVEs it analyzed lacked an NVD-assigned CVSS score. Only about 600 open-source vulnerabilities in the analysis could be effectively triaged using available public CVE data. Sonatype rated 46% of the unscored open-source CVEs it reviewed as High or Critical. If enterprises relied on public CVE data, they could triage only 35% of vulnerabilities in 2025.
The volume and consistency of the underlying data also changed over time. Sonatype reported that the global CVE count doubled over the five years preceding its 2025 analysis, while the number of unscored CVEs increased 37-fold. Those are period-over-period observations in Sonatype’s analysis, not a forecast of future CVE volume.
Severity comparison produced additional uncertainty. In Sonatype’s 2025 open-source CVE sample, 4.4% of CVSS scores exactly matched its own scores. NVD and Sonatype severity categories aligned for 55.7% of the CVEs compared. NVD scores were higher than Sonatype’s for 61.3% and lower for 34.3%.
For testing teams, these findings support recording the evidence behind a prioritization decision: the affected package and version, the scoring source, the date of the score, and whether the issue has a remediation path. Scanner output should be treated as an input to testing and triage, not as a complete description of risk.
Open-source supply-chain testing signals
Sonatype’s 2026 report logged 1,233,219 open-source malware packages cumulatively since 2019. The registries covered in the report recorded 9.8 trillion downloads across Maven Central, PyPI, npm, and NuGet in the 2025 report coverage. Sonatype identified more than 454,600 new malicious packages during 2025. These totals cover the report’s stated registries and periods; they are not interchangeable with vulnerability counts.
The report also measured how often vulnerable components had a practical fix. About 95% of vulnerable Java component downloads analyzed by Sonatype had a fix already available. Only about 0.5% represented cases with no upstream remediation path. Sonatype found more than 81,000 package versions with known CVEs that were both end-of-life and unpatchable. Its HeroDevs analysis estimated that this number could reach 400,000 across all registries.
End-of-life components represented 5%–15% of components in enterprise dependency graphs in Sonatype’s analysis. Fourteen percent of Log4Shell-affected Log4j artifacts were end-of-life and generated more than 619 million downloads in 2025. The pattern is a testing signal for dependency inventories: a component can remain widely used even after its support and patching options have narrowed.
Finally, Sonatype reviewed 36,870 dependency-upgrade recommendations and found that 27.76% referenced nonexistent package versions. This result makes upgrade validation part of security testing. A pipeline should verify that a proposed version exists, resolves from the intended registry, passes compatibility checks, and actually removes the vulnerable dependency rather than merely recording a recommendation.