Open source code sits inside nearly every commercial application, and development teams continue to add new dependencies. Black Duck’s 2026 Open Source Security and Risk Analysis Report data shows that nearly all audited codebases contain open source components, with average component counts rising sharply over the past year.
That growth brings a parallel increase in exposure. Mean vulnerabilities per codebase climbed from 280 to 581 in one year, more than doubling. Median vulnerabilities also rose. The spread between mean and median points to a long tail of heavily burdened applications, including extreme outliers with tens of thousands of findings.
Top 10 most prevalent CVEs and BDSAs in 2025 (Source: Black Duck)
More components, more exposure
Median file counts increased by more than a third year over year, and the average codebase now contains tens of thousands of files. The number of components per application also climbed, expanding the dependency tree across direct and transitive packages.
Each component carries its own vulnerability history. Popular libraries that appear frequently in AI coding assistant suggestions tend to have long disclosure records. Disclosure volumes also rose after the Linux Kernel team became a CVE Numbering Authority in 2024, generating thousands of additional CVE assignments tied to kernel code.
High and critical risk findings remain widespread. Most codebases contain at least one high risk vulnerability, and nearly half contain at least one critical risk issue. Those rates dipped slightly from the prior year even as total vulnerability counts rose.
Supply chain attacks add another layer of risk. Sixty five percent of surveyed organizations experienced a software supply chain attack in the past year. Malicious packages continue to appear across major ecosystems, including cases in which attackers created new packages for harm and others in which they compromised established projects and pushed poisoned updates.
“Security leaders can interpret this divergence by looking to a few key areas within their security programs,” Tim Mackey, head of software supply chain risk strategy at Black Duck, told Help Net Security. “First, empowering developers to use AI coding assistants is critical for maintaining the velocity of innovation required for modern software development. However, it is one side of the coin. AI-powered development requires AI-powered security to keep pace.”
He pointed to the drop in high and critical vulnerabilities as evidence that teams are prioritizing the most serious issues.
“As AI reshapes software development, security teams will have to continue to adapt in turn. Security budgets and security guidelines should reflect this new reality. Leaders should continue to invest in tooling and education required to equip teams to manage the drastic increase in velocity, volume, and complexity of applications,” Mackey said.
Board level reporting also requires adjustment as vulnerability volumes rise.
“Board visibility into these issues will only increase,” Mackey said. “Risk reporting must be automated, continuous and be able to answer key questions about AppSec programs like: Are my total number of issues going down? Have critical issues been resolved? Can we produce a compliant SBOM on demand? Am I minimizing risk over time? Am I delivering ROI for my AppSec program? Focusing on visibility that demonstrates impact and proves compliance is critical and instantaneous.”
Large scale campaigns in the npm ecosystem demonstrated coordinated efforts to evade static inspection and deliver malicious payloads during installation. One self propagating campaign compromised hundreds of packages and exposed a large volume of credentials before it was contained.
License conflicts reach record levels
Legal exposure continues to climb alongside security risk. More than two thirds of audited codebases contain license conflicts, the highest level recorded in this data set. Average conflicts per codebase increased significantly, and one large application accumulated thousands of distinct conflicts.
Component growth drives much of that expansion. The average codebase now includes well over a thousand components, many of which enter as transitive dependencies that developers did not explicitly select. Each dependency introduces license terms that must align with every other component and with the organization’s distribution model.
Strong copyleft licenses remain present in commercial software, carrying obligations that can extend to derivative works. Permissive licenses dominate overall usage, yet weak and strong copyleft components still appear frequently enough to create compliance complexity.
More than half of organizations use AI-powered coding tools, and internal use often continues even where policies restrict it. A minority of organizations conduct comprehensive reviews of AI generated code for IP, license, security, and quality risks. Generated snippets can reflect patterns from restrictive licenses without embedded attribution or provenance data.
A portion of components carry no detectable license or use custom terms that require individual legal review. Under default copyright rules, use of code without an explicit license grant requires permission from the author.
Maintenance debt becomes a compliance issue
Outdated components appear in nearly every audited environment. More than nine in ten codebases contain components that are several years out of date or show no recent development activity. A large share of components run many versions behind current releases. Only a small fraction operate on the latest available version.
This maintenance debt intersects with regulatory obligations. The EU Cyber Resilience Act entered into effect in late 2024, with key reporting requirements taking effect in 2026 and broader enforcement following in 2027. Manufacturers must manage vulnerabilities throughout a product’s support period, which generally spans multiple years. They must also retain access to updates and maintain documentation over extended timeframes.
Mackey said managing obsolete third party code will present a direct challenge under the new framework.
“Managing obsolete third party code is going to be a challenge under CRA, but one that industry needs to step up and address,” he said. “One interesting thing about open-source software is that it does not operate like commercial software. It is not managed by a product manager and there is no support department to complain to. Anyone who believes that they can convince an open source maintainer to change something just by entering a GitHub issue does not understand how open source works.”
He described most projects as small teams focused on solving specific problems.
“Open source development is largely done by enthusiasts who care about solving a particular software problem,” Mackey said. “Occasionally that project goes mainstream and becomes something big like Kubernetes or Linux, but the vast majority is maintained by teams with fewer than five people. From a practical perspective, someone complaining about a feature or lack thereof needs to branch the code and implement their desired functionality. So long as there are developers on a project, it is not obsolete from a development standpoint, though that does require users to keep up to date.”
He added that the burden ultimately falls on the organization shipping the product.
“What the data shows is that when you start looking at dependencies, development teams make the decision once and are not monitoring for updates or investing in sustaining the code they depend upon,” Mackey said. “Software composition analysis tools have been around for well over a decade, meaning automated tools to identify obsolete open source libraries are readily available. The authors of the CRA recognize these tools exist, and they understand that when someone ships a software enabled product ownership of risks does not end when a box is on a truck. Users expect service lifespans to measure in years, and suppliers should provide security updates for the duration of that product lifespan, even if one of their suppliers ceases active development and becomes obsolete.”
The regulation mandates creation and maintenance of a software bill of materials that includes at least direct dependencies. Authorities may request SBOMs during audits or incident investigations, and the documentation must remain current across the product lifecycle.
Vulnerability reporting timelines under the act require notification after awareness of an exploitable issue, followed by confirmation and a final report after remediation becomes available.
Organizations deploy code to production frequently, often on a daily basis. Component update cycles tend to stretch across much longer intervals, creating a persistent gap between disclosure and remediation.
