Black Duck’s 2026 Open Source Security and Risk Analysis (OSSRA), published February 25, 2026, found the mean number of open-source vulnerabilities per codebase reached 581 — a 107% year-over-year jump and the largest single-year increase in the report’s 11-year history1. The proximate cause: AI coding assistant adoption has expanded codebases faster than teams can audit them, while only 24% of organizations perform comprehensive reviews of AI-generated code1.
What the 2026 OSSRA Report Actually Found
The report analyzed 947 codebases across 17 industries1. The headline figures:
- 87% of audited codebases contained at least one vulnerability; 78% had high-risk vulnerabilities; 44% had critical-risk vulnerabilities2
- 98% of codebases contain open-source components, with component counts up 30% year-over-year1
- 68% of codebases had open-source license conflicts — up from 56% the prior year, the largest single-year jump in OSSRA history. One codebase contained 2,675 distinct license conflicts2
- 65% of organizations experienced an open-source supply chain attack in the past year: 66% involved malicious packages, and 34% involved compromised legitimate packages2
One methodological caveat: the 581-per-repo figure is a mean, not a median, and Black Duck does not publish the median. A small number of unusually large or legacy codebases could skew this number upward. The trend is real, but treat the headline figure as directional rather than a precise benchmark.
Black Duck was spun out of Synopsys in 2024 and sells software composition analysis (SCA) tooling. The implicit conclusion — that teams need better tooling — is self-serving and worth acknowledging when evaluating its recommendations.
The AI-Coding-Tools Connection
The mean number of files per codebase grew 74% year-over-year, which the report attributes directly to AI coding assistant adoption1. More files means more open-source components included (often automatically, through AI suggestions), expanding the attack surface vulnerability scanners must cover. Whether the 107% jump represents entirely new vulnerabilities or partly reflects improved detection of an expanded codebase is a question the report does not resolve.
The scale of adoption makes this structural, not incidental. According to the report, 85% of organizations use AI coding assistants. Of those that have explicitly prohibited them, 76% acknowledge their developers use them anyway1. Prohibition has not functioned as a control.
License Laundering: How AI Code Generation Strips Copyleft Metadata
The 68% license conflict rate points to a mechanism standard dependency scanning does not catch, often called “license laundering.”
When a developer pulls a snippet from a GPL-licensed project and asks an AI assistant to adapt it, the assistant may reproduce that code — verbatim or near-verbatim — without preserving the original license header3. The resulting file contains no package.json entry, no lockfile reference, and no NOTICE file. Manifest-only SCA tools have no visibility into it.
The OSSRA data supports the scale: 17% of open-source components in audited codebases entered outside traditional package managers — via copy-paste, direct file inclusion, or AI generation3.
Copyleft licenses like GPL and LGPL require that derivative works be released under the same terms. If AI-generated code in a proprietary product is later found to contain GPL-derived snippets, the exposure ranges from forced source disclosure to litigation.
The Governance Gap: Only 24% of Teams Run Full Reviews
The four dimensions of a complete AI code review, per the OSSRA report: security, licensing, intellectual property, and quality. Only 24% of organizations cover all four1.
The breakdown by dimension:
- 76% check for security risks
- 56% assess quality
- 54% evaluate IP and license risks
License review is the least common check — and the most directly linked to the record-high conflict rate. Security scanning has become normalized; license auditing of AI-generated code has not. Organizations already running comprehensive security scans are simply not extending those workflows to cover licensing and IP, despite relatively low incremental effort if SCA tooling is already in place.
Zombie Components: The Silent Risk Multiplier
Unmaintained dependencies compound vulnerability exposure over time. The 2026 OSSRA data:
- 93% of codebases contain at least one open-source component with no development activity in two or more years2
- 92% include components that are four or more years behind the current release2
- Only 7% of components across analyzed codebases are on the latest available version2
An abandoned component won’t receive patches. When a new CVE lands against it, the only remediation path is replacement — which takes longer than a version bump and is often deferred indefinitely. Rapid AI-accelerated dependency addition combined with near-zero version currency creates a compounding backlog.
Practitioner Audit Checklist: 6 Steps to Assess Your Own Repo
1. Run a snippet-level SCA scan, not just manifest analysis. Manifest-only tools miss the 17% of components entering outside package managers3. Tools that perform binary or snippet-level discovery are required to surface license laundering.
2. Triage vulnerabilities by severity, not by count. The 581 mean figure is not actionable as a single number. Filter to critical CVEs first (CVSS 9.0+), then high (7.0–8.9). The OSSRA data shows 44% of codebases have critical vulnerabilities2 — start there.
3. Flag components with no upstream commits in 24+ months. Most SCA tools expose last-commit dates. Components meeting the zombie threshold should be tagged for scheduled replacement and tracked on a roadmap.
4. Audit AI coding assistant output at merge time, not post-deployment. Gate AI-generated code at the pull request stage with automated license scanning. Retrofit auditing is significantly more expensive.
5. Check for copyleft license types specifically. GPL, LGPL, AGPL, MPL, and EUPL all carry viral or reciprocal requirements. A GPL conflict in proprietary code is not manageable the way an MIT or Apache 2.0 conflict typically is.
6. Run a supply chain integrity check on declared dependencies. 65% of organizations experienced a supply chain attack in the past year2. Verify package checksums and confirm registry provenance, particularly for dependencies added recently or via AI suggestion.
Tool Options: Snippet-Level SCA vs. Manifest-Only Scanning
| Tool | Approach | License | Snippet-Level Discovery |
|---|---|---|---|
| Black Duck SCA | Commercial | Proprietary | Yes |
| FOSSID | Commercial | Proprietary | Yes |
| Trivy | Open source | Apache 2.0 | No (manifest/lockfile) |
| Dependency-Track | Open source | Apache 2.0 | No (SBOM-based) |
| FOSSA (free tier) | Freemium | Proprietary | Partial |
Open-source tools like Trivy and Dependency-Track are well-suited to the 76% of organizations already running security-focused SCA — fast, CI-friendly, and reliable for declared dependencies. They do not address the license laundering problem, which requires file-content comparison against a known-code corpus.
For teams primarily concerned with compliance exposure from AI-generated code, snippet-level tools cover the gap. For teams primarily tracking CVEs against declared dependencies, open-source tooling remains effective and avoids vendor lock-in4.
FAQ
Does the 107% vulnerability increase mean the software industry is less secure, or just that more code is being written?
Probably both, and the report does not separate the two. A 74% increase in codebase file counts means there is more code to scan, and more code statistically contains more vulnerabilities. But the license conflict rate — a compliance metric, not a detection coverage metric — also rose sharply, from 56% to 68%2. That figure is less susceptible to the “more scanning equals more findings” interpretation.
Why doesn’t banning AI coding assistants solve this?
Because it doesn’t work in practice. Of organizations that explicitly prohibit AI assistants, 76% acknowledge their developers use them anyway1. Control frameworks that depend on prohibiting widely adopted tools produce shadow usage rather than compliance.
What’s the difference between a license conflict and a license vulnerability?
A license conflict is a legal compliance issue: two or more licenses impose incompatible terms (for example, GPL code embedded in a proprietary product without source disclosure). A vulnerability is a security defect in a component. They are tracked separately, require different remediation, and are both at record highs in the 2026 OSSRA data. Teams that conflate them typically under-resource license review.
Footnotes
-
Black Duck, “Black Duck Research Shows Open Source Vulnerabilities Have Doubled as AI Accelerates Code Creation,” February 25, 2026. https://news.blackduck.com/2026-02-25-Black-Duck-Research-Shows-Open-Source-Vulnerabilities-Have-Doubled-as-AI-Accelerates-Code-Creation ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8
-
Black Duck Blog, “2026 OSSRA Report: Open Source Vulnerabilities Double as AI Soars.” https://www.blackduck.com/blog/open-source-trends-ossra-report.html ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9
-
SD Times, “Report: Open source licensing conflicts hit an all-time high as organizations struggle to audit AI-generated code for IP risks.” https://sdtimes.com/ai/report-open-source-licensing-conflicts-hit-an-all-time-high-as-organizations-struggle-to-audit-ai-generated-code-for-ip-risks/ ↩ ↩2 ↩3
-
FOSSID, “How to Balance AI-Generated Code and Open Source License and Security Risks.” https://fossid.com/articles/how-to-balance-ai-generated-code-and-open-source-license-and-security-risks/ ↩