AI-Velocity Is Breaking Open-Source Security: 581 Mean Vulnerabilities Per Codebase, 65% of Firms Hit

The Number That Should Reorder Your Security Backlog

The single most important figure from Black Duck's 2026 Open Source Security and Risk Analysis (OSSRA) report is a count, not a percentage: the mean number of open-source vulnerabilities per codebase has more than doubled, rising 107% to an average of 581 vulnerabilities. This is not a detection artifact from better tooling. The increase correlates with codebase expansion—the average number of files per codebase increased by 74% and open-source components by 30%. The codebases physically got larger, and the vulnerabilities followed.

The OSSRA report audited 947 codebases across 17 industries, totaling 2,843 individual projects, between November 2024 and October 2025. This is production code, not self-reported survey data.

AI Velocity as a Driver — With Caveats

Black Duck cited AI coding assistants as a likely driver of unprecedented code volume growth between 2023 and 2025, and a contributing factor in the parallel vulnerability spike. The mechanism is straightforward: AI generates code faster than human review can track it. AI accelerates development pace and the rate at which new dependencies enter codebases. It also gravitates toward popular, well-established open-source libraries—which carry more documented vulnerabilities precisely because they see wider use and scrutiny.

The causality is plausible but not proven. The report establishes correlation, not a controlled experiment. What is unambiguous is the operational consequence: "There are no rules that AI-assisted growth has to follow. It adds code, dependencies, and architectural choices at a speed faster than standard review and fix processes can handle," said Randolph Barr, CISO at Cequence Security.

One specific mechanism warrants operational attention. 17% of open-source components enter codebases outside standard package managers—via copy-pasted snippets, direct vendor inclusions, or AI generation—making them invisible to traditional manifest-based scanning tools. If your SCA tool only reads package manifests, you are missing roughly one in six components.

65% Supply-Chain Attack Rate: Baseline, Not Outlier

65% of organizations surveyed in 2025 reported experiencing a software supply chain attack in the past year. At that rate, supply-chain compromise is a baseline operating condition. 66% of attacks deployed malicious packages created specifically to harm users through typosquatting and social engineering, while 34% were legitimate packages that had been hijacked.

The 65% figure is self-reported, which carries standard caveats around detection and definition. Organizations unaware of a supply-chain intrusion will under-report it. The actual rate is likely no lower.

The Transitive Dependency Problem

Component count alone does not explain exposure. Composition does. Black Duck found that 64% of open-source components in commercial codebases were transitive dependencies, and nearly half of high- and critical-risk vulnerabilities originated from them. A transitive dependency is a package your code does not import directly—it is a dependency of a dependency. Developers did not choose it. Security teams often cannot see it without specialized tooling.

"This probably signals the inability for development organizations to track massive numbers of dependencies and prioritize vulnerability remediation," said Mike McGuire, senior manager and OSSRA data advisor at Black Duck.

Maintenance Abandonment Underneath the Vulnerability Count

Vulnerability counts reveal a deeper condition: abandoned maintenance at scale. 93% of codebases contain components dormant for two or more years; 92% contain components four or more years out of date; only 7% of components in use are latest versions. When a zero-day surfaces in an unmaintained package, downstream organizations face three paths: fork it, refactor around it, or accept the exposure. Most teams lack the staffing or budget to execute the first two quickly.

License risk compounds in parallel. Two-thirds of audited commercial codebases harbor license conflicts—the highest rate in OSSRA history. The 12% year-over-year increase from 56% to 68% marks the largest single-year jump on record. One mechanism: "license laundering"—AI assistants generating code from copyleft sources without retaining original license information.

The Governance Gap Is Measurable

The 2026 OSSRA also measures organizational response. The adoption-to-governance gap is stark: 95% of organizations leverage AI tools for software development, yet only 24% implement comprehensive intellectual property, license, security, and quality evaluations for AI-generated code.

That 24% is your peer benchmark. If your engineering organization falls in the other 76%, you are accumulating security and legal debt with every AI-generated commit. Many companies are building legal debt that surfaces only during M&A due diligence or product launches.

Regulatory pressure will force resolution regardless of internal appetite. The OSSRA report examined how maintenance debt could impact compliance with the EU Cyber Resilience Act (CRA), effective September 2026. DORA is also in scope. Firms selling into EU markets without current SBOMs and documented vulnerability response processes will face compliance gaps within the year.

What To Watch

1. SCA tooling adoption, Q2-Q3 2026. The 581-vulnerability mean will drive procurement cycles. Watch whether SCA vendors (Snyk, Sonatype, Black Duck, JFrog) report accelerating enterprise deal flow and whether CI/CD-native scanning becomes a default RFP requirement.

2. AI coding assistant vendors and security integration. GitHub Copilot, Cursor, and comparable tools currently optimize for completion speed. Watch whether they begin surfacing CVE signals inline, at suggestion time, rather than deferring to downstream CI scanning. Inaction by year-end deepens the security debt OSSRA documents.

3. EU Cyber Resilience Act enforcement posture, September 2026. Organizations must continuously track open-source component status, maintain current software bills of material (SBOMs), and execute robust vulnerability response processes. Early enforcement actions will clarify what "adequate" SBOM coverage means in practice.

4. SBOM accuracy and AI model inventory. "Organizations must know exactly what is in their software, including open-source components, transitive dependencies, and embedded AI models. Accurate, continuously updated SBOMs and AI BOMs, along with automated vulnerability and license management, are baseline requirements," said Diana Kelley, CISO at Noma Security. The emerging requirement extends beyond open-source packages—to AI BOMs for embedded models. No vendor has solved this cleanly yet.

5. Your own dependency posture, now. Three diagnostic questions: Does your SCA tool scan beyond package manifests to catch copy-pasted and AI-generated components? Are CVE findings blocking deployments in CI/CD, or only generating reports? Can you produce a complete SBOM for your primary product in under 30 minutes? A no on any of these places you in the exposed cohort the OSSRA data describes.