Black Duck published its 2026 Open Source Security and Risk Analysis in February, and the headline figure is one that should inform how every engineering team thinks about AI-assisted development: average open source vulnerabilities per codebase increased 107% in a single year. The report is based on an audit of 947 codebases across 17 industries, and the scale of the shift it documents is larger than anything in the report’s previous editions.

The numbers

• 87% of all audited codebases contained at least one open source vulnerability
• 78% contained high-risk vulnerabilities
• 44% contained critical-risk issues
• Open source components now appear in 98% of codebases, making inherited third-party risk effectively universal
• Open source component counts per codebase grew 30% year-over-year
• Files per codebase grew 74%
• 68% of codebases contained open source licence conflicts, the highest rate in the report’s history

The licence conflict figure is worth pausing on. Two thirds of audited codebases contain conflicting open source licences, up from 56% the prior year. This is not a theoretical problem. Licence conflicts can create legal exposure, block commercial distribution, and complicate acquisitions. The fact that the rate is at a historical high while teams are shipping more code faster is a predictable consequence of the same dynamic driving the vulnerability increase.

Why AI coding tools are driving this

AI coding assistants generate code quickly, and a significant portion of what they generate relies on open source libraries and packages. A developer using an AI tool to scaffold a new feature will often end up with a set of dependencies they did not explicitly choose, did not evaluate, and may not be fully aware of. The component count growth – 30% year-over-year – reflects this pattern directly.

The speed at which AI tools produce working code has outpaced the speed at which organisations have built governance around what those tools produce. Black Duck’s research found that 76% of surveyed organisations check AI-generated code for security risks. That figure sounds reasonable until you look at the rest of the data: only 54% evaluate AI-generated code for IP and licence risks, only 56% assess code quality, and only 24% perform comprehensive evaluations across all three dimensions.

The result is a significant gap between the confidence many organisations have in their AI coding workflows and the actual state of the code those workflows produce.

What this means for DevOps pipelines

The traditional mental model for open source security assumed that vulnerabilities entered a codebase at a relatively measured pace – through deliberate dependency updates, new library adoptions, or occasional transitive dependency changes. That model no longer applies. AI coding tools have made open source adoption continuous and often invisible, which means the vulnerability surface of a codebase can grow significantly between audits without any deliberate action by a developer.

A DevOps pipeline that scans for known vulnerabilities at the point of code commit or pull request is now the minimum baseline, not a security differentiator. Software composition analysis needs to run continuously, not periodically, because the dependency graph can change with every AI-assisted code generation step.

The licence compliance picture is equally important and often more neglected. Security teams have processes for tracking CVEs. Legal and compliance teams rarely have equivalent processes for tracking what open source licences are being introduced into production code through AI-assisted development.

Closing the governance gap

Black Duck’s data points to a straightforward set of changes that organisations need to make:

Software composition analysis in CI/CD. Every pull request that touches dependencies should trigger an SCA scan that identifies new vulnerabilities and licence changes before code is merged. Tools like Black Duck, Snyk, and Mend integrate directly into GitHub Actions, GitLab CI, and similar pipelines.

AI code review policy. The 76% security review figure suggests that many organisations have started to address this, but the gap in licence and quality checks means the policy is incomplete. A comprehensive AI code review standard covers security, licence, and quality evaluation, not just one of the three.

Dependency pinning and SBOM. Maintaining a software bill of materials – a full inventory of dependencies and their versions – enables teams to respond quickly when a new CVE affects a component they use. Without an SBOM, the response to something like the Log4Shell class of vulnerability becomes a manual search through repositories rather than a query against a known inventory.

Periodic codebase audits. The Black Duck report is itself a form of point-in-time audit. Organisations that have not reviewed the open source composition of their production codebases in the past year are likely to find the current state meaningfully different from what they remember.

If you want to assess where your organisation stands on open source governance and AI code risk – whether that means reviewing your current pipeline controls, evaluating SCA tooling options, or designing a policy for AI-generated code – contact Excello Digital. We help DevOps and security teams build the governance infrastructure to keep pace with the speed of AI-assisted development.