Software development organizations did not suddenly become careless about security. They became optimized for something else: speed.
Over the past decade, application development has been pushed toward shorter release cycles, continuous delivery and an almost permanent backlog of requested features. Business units measure development organizations by how quickly applications reach customers, how rapidly defects are corrected, and how many projects can be delivered with a finite number of engineers. Security, meanwhile, is frequently measured by whether something bad happened.
That difference in incentives matters. When a development team has 400 items in its backlog and a product organization that promises customers a feature this quarter, another security review can easily look like friction rather than risk reduction. DevOps helped eliminate much of that friction by automating builds, testing, infrastructure provisioning and deployment. But it also normalized an environment in which software can move from a developer workstation into production extraordinarily quickly.
Open Source Speeds Development
Open source made that speed possible. Today, 98% of commercial codebases contain open source components, according to Black Duck's 2026 Open Source Security and Risk Analysis research (https://www.blackduck.com/resources/analyst-reports/open-source-security-risk-analysis.html). The average audited application contained 1,180 open source components, up 30% in a single year, as you can see in Figure 1. For practical purposes, modern application development is no longer principally the process of writing software. It is the process of assembling software from internal code, frameworks, packages, libraries, APIs, and enormous dependency trees.
That model produced extraordinary productivity, but it also created a security problem that development organizations have never completely solved.
A developer adding one npm, Maven, PyPI or NuGet package is rarely adding one piece of software. Dependencies bring other dependencies, which bring still more dependencies. Black Duck estimates that 64% of the open-source components in a typical codebase are transitive dependencies—software that the developer did not explicitly select at all (see Figure 2). The application may compile and the tests may pass, while dozens of additional components have quietly entered the software supply chain.
At the same time, the vulnerability workload has exploded. NIST reported in April 2026 that CVE submissions increased 263% between 2020 and 2025, and submissions in the first quarter of 2026 were already nearly one-third higher than during the same period in 2025. That growth does not necessarily mean software has become proportionally less secure; improved discovery, more CVE Numbering Authorities and better reporting contribute to the increase. But from the perspective of a development or security team, the operational consequence is the same: vastly more vulnerabilities must be evaluated, prioritized, and remediated.
The open source numbers are even more revealing. Black Duck found that the mean number of vulnerabilities in its audited codebases jumped from 280 to 581 in a single year, an increase of 107%, while the number of unique vulnerabilities per codebase increased 54%, as Figure 3 shows. The average codebase now contains more than 84,000 files, four times the level seen five years ago. Complexity is increasing at precisely the moment organizations are demanding even greater development velocity.
That was difficult enough when humans were choosing the dependencies.
Now agents are doing it.
Agents Compound the Issue of Dependencies
Agentic software development changes the dependency problem because an autonomous coding agent is not simply generating functions. Give an agent an objective such as “add PDF export,” “implement OAuth support,” or “build an analytics dashboard,” and it may determine that the fastest path is to import an existing package. It can modify package.json, requirements.txt, pom.xml or another manifest, execute the package manager, resolve dependency conflicts, modify the application, and run the tests without a developer individually approving every component it introduces.
From the agent's perspective, that is good engineering. Reusing a mature package is usually faster than implementing the functionality from scratch. The problem is that the agent's objective is generally functional: make the application work. The organization's security and compliance objectives may exist somewhere else entirely.
The critical architectural change is treating dependency selection as a security decision rather than merely a development decision.
A company may have rules requiring approved licenses, minimum package age, vulnerability thresholds, permitted repositories, SBOM generation, provenance checks, or human approval for certain dependencies. Those policies were often designed around a human development workflow in which somebody consciously decides to introduce a new component. Agentic development removes that assumption.
This becomes especially problematic when AI-generated recommendations are themselves unreliable. Sonatype's 2026 software supply chain research (https://www.sonatype.com/resources/ ) found open source consumption reached 9.8 trillion package downloads in 2025, up 67% year over year (see Figure 4). It also found that, in one analysis of 37,000 AI-generated dependency recommendations, GPT-5 hallucinated component versions 27.8% of the time and could recommend actual malicious packages when operating without current software supply chain intelligence.
The obvious response is not to stop using open source or prohibit development agents. Neither is economically realistic. Development organizations adopted open source because it dramatically shortened time to market, and they are adopting agents for exactly the same reason. The backlog has not disappeared simply because AI arrived; management will use AI to increase throughput expectations again.
Security Needs to Keep Pace
Security controls therefore have to move at the same speed as the development system. Software composition analysis, dependency policy, vulnerability intelligence, package provenance, license checks, and organizational compliance rules can no longer be processes performed after an agent has completed its work. They have to become enforceable controls inside the agentic workflow itself.
Agentic development is now putting that system on machine speed.
The critical architectural change is treating dependency selection as a security decision rather than merely a development decision. If an autonomous agent can select and execute third-party software, the organization needs to know what it selected, where it came from, what dependencies followed it into the build and whether the decision complied with policy before that software moves further through CI/CD.
Software development became lax about security because the business spent years rewarding velocity and penalizing delay. Open source amplified that velocity, while simultaneously creating dependency estates too large for humans to understand manually.
Agentic development is now putting that system on machine speed.
The problem is no longer that developers might occasionally bypass the security process to ship faster. It is that autonomous development networks can make thousands of those same decisions continuously, often without realizing there was a security process to bypass in the first place.
Ready
The Numbers Behind the Dependency Problem
Black Duck's 2026 Open Source Security and Risk Analysis found open source in 98% of commercial codebases, with an average of 1,180 open source components per application. Transitive dependencies account for 64% of those components, and the mean number of vulnerabilities per codebase jumped from 280 to 581 in a single year.
Sonatype counted 9.8 trillion package downloads in 2025, up 67% year over year, and NIST reported that CVE submissions increased 263% between 2020 and 2025.
Understood.
