Why AI coding tools require earlier dependency security controls

AI coding tools are making a familiar software-supply-chain problem impossible to ignore: dependency trust still depends heavily on controls that run after developers choose what to use. Assistants and agents can pull packages, libraries, and container images into a codebase faster than a security team can review them. Human review cannot fix that timing mismatch by running faster. The security decision has to move closer to the point where dependencies enter development.

AI is exposing a security model that was already too slow

That timing problem starts with a development model built around deliberate human selection. Older software-composition practices assumed a developer had selected a library, perhaps because they had used it before, and could explain the choice during review. Enterprise approval processes grew around that pace, with review cycles measured in days. Agentic development, where AI systems perform development tasks with greater autonomy, compresses or removes the pause in which those controls used to operate.

With less time available, manual approval becomes a bottleneck because instant code generation still feeds work into processes designed for slower development. “Velocity has outpaced governance and controls,” says Quincy Castro, CISO at software-supply-chain security company Chainguard. Chainguard sells technology intended to secure software supply chains, so it has a commercial stake in organizations moving toward stronger controls over dependency sourcing.

Castro connects that speed difference directly to how work reaches security teams. “When you can generate code instantaneously, the traditional request, review, and approve cycle bottlenecks people. Nobody will stand for a world where they get their work done very quickly and all of it stacks up against a legacy, manual, human-led process,” Castro says. Keeping the same approval point while increasing the volume that reaches it leaves security operating at yesterday’s development pace.

The mismatch accelerates a weakness Castro says he has seen across four CISO roles. Engineering teams have moved from an idea on a whiteboard to a minimum viable product before bringing in security for final approval. By then, they have already made the technology choices and assembled them into a working system. Security is left to validate a result after much of the consequential sourcing has happened.

Late review also hits a knowledge limit as the number of technology stacks grows. “The idea that a small security team can be a specialist in every tech stack of a Fortune 500 organization, and can say yes or no, this thing is safe to go out the door, is laughable,” Castro says. A small group making final decisions across a large enterprise must understand components selected by many teams across stacks that may have little in common.

That knowledge problem predates coding agents, which is why Castro sees AI as accelerating an existing weakness. “I‘m doubtful that most security teams have ever effectively reviewed and validated the software components developers use. That’s why the software supply chain became such a juicy target. If we were bad at it before, adding the speed and scale of agentic development on top only makes it worse,” Castro says. Existing gates already had to compensate for weak sourcing judgments; agentic development leaves those gates less time to do so.

Machine-speed dependency choice expands the attack surface

Once software can select dependencies during generation, finding relevant code and establishing its security quality become separate tasks. An agent can find a package that looks relevant to a prompt without establishing whether its project is actively maintained or its distribution path remains trustworthy. Legitimate components, malicious packages, typosquatted libraries, and compromised transitive dependencies can all arrive through the same automated dependency mechanisms, so functional fit alone does not establish trust.

Attackers can exploit that gap by targeting parts of open source that receive less attention. Popular projects tend to attract more maintainers, more contributors reviewing changes, and more automated scrutiny, raising the chance that malicious changes will be noticed. “Smuggling malware into the open, publicly viewable repo of a popular open-source project probably isn’t the path to success unless they’re extremely stealthy,” Castro says. Projects that draw less attention give attackers a different operating environment.

That difference can shape both compromise and distribution. “So they go after the less well-maintained projects, then find ways to drive developers toward those projects to get maximum spread for their operation,” Castro says. When agents and developers choose from a large universe of dependencies, an obscure package can satisfy a functional query while receiving substantially less external review than a well-known project.

One recent operation Castro points to shows how attackers can also exploit project identity. Attackers produced numerous forks of legitimate projects, inserted malware into those forks, and distributed them broadly enough for developers to mistake them for the official repositories. Such a mistake could introduce attacker capability directly into a continuous integration and continuous delivery (CI/CD) pipeline, the automated process that builds, tests, and prepares software for release.

Wide use still cannot eliminate compromise, as the Trivy attack demonstrates. In the March Trivy attack Castro cites, attackers who took control of the scanner’s GitHub Actions force-pushed 75 of its 76 version tags so they pointed to commits containing an infostealer. GitHub Actions automates repository workflows, so control over those references gave the malicious code a path into automated activity around a widely used security tool.

The Trivy compromise then spread risk beyond the original repository. The attackers harvested secrets and used them to publish malicious npm packages, carrying the operation from one part of the software ecosystem into another. Other techniques in the same threat landscape include typosquatting, where malicious packages use confusingly similar names; maintainer account takeover; poisoned distribution points; and dependency riding, where attackers exploit software’s inherited dependency relationships.

Those techniques become more consequential as automated selection creates more opportunities to encounter a candidate dependency. Anyone can publish open-source software, while its inclusion in an enterprise system can affect systems far beyond the function that first caused a package to be selected. Machine-speed selection repeats that trust decision across more dependencies with less deliberate review, making the distribution of risk across the ecosystem important.

The risk is concentrated in the long tail

That distribution is why a small list of approved components cannot cover the whole problem. Chainguard’s State of Trusted Open Source data measures common vulnerabilities and exposures (CVEs) across container images and reports a large concentration outside the 20 most popular images. Because Chainguard sells software-supply-chain security technology, the measurement comes from a company with a commercial interest in broader dependency-security controls.

Those figures run against how enterprise hardening effort is often allocated. Companies can put substantial resources into a relatively small collection of widely used images because they affect many workloads and give security teams a manageable target. Chainguard’s March 2026 data places 3.8% of CVEs inside that popular group, while the June edition reports 97% outside the top 20.

Castro interprets that distribution as an inversion of enterprise attention. “Risk concentration is inverted from where most enterprise attention goes,” Castro says. “Organizations pour a ton of resources into hardening a small set of well-known, widely used images, while the actual exposure lives in the long tail.” Chainguard supplies both the dataset and Castro’s interpretation, so the figures and conclusion are claims from a vendor whose business benefits from wider supply-chain security coverage.

The long tail matters more to development when AI can surface software that engineers would never have recalled from memory. A component can enter consideration simply because it matches a prompt, giving obscure dependencies another route into development workflows. As the accessible dependency population expands, governance concentrated on the most familiar components covers a smaller share of what teams and agents can select.

Popular-component standardization can still reduce risk wherever those components are deployed, and popularity can support stronger maintenance and scrutiny. Chainguard’s cited CVE distribution, however, places most of the measured vulnerability population elsewhere. Governance built around a small core therefore has to account for the much larger population beyond it.

That broader population also contains dependencies that applications may genuinely require. Real applications can depend on specialized software with few maintainers, while legacy systems may rely on components that cannot easily be upgraded or replaced. Those cases make the long tail an operational requirement as well as a security concern, while inherited dependencies make the population harder to see.

Some dependency risk disappears before the inventory sees it

The visibility problem grows because an application’s direct dependencies are only the first layer of code involved in creating software. A package can depend on other packages, which bring their own dependencies in turn. Castro says developers can lose practical visibility two or three levels into that chain even though the build process can still execute the inherited code.

Castro describes a detection where that difference initially made the malware appear inconsistent with the final artifact. “We‘ve had detections fire for a dependency with malware in it, and find it isn’t part of the container image, or not in the bill of materials,” he says. A software bill of materials (SBOM) is an inventory of components associated with software, but an inventory of the resulting artifact cannot by itself represent everything that ran temporarily while the artifact was being produced.

The investigation showed where the missing dependency had appeared. “Then we rewind the tape and see that it was a dependency of a transitive dependency that briefly ran during a build. Was it real? Yes. Would a normal person building this have any indication they were at risk? Absolutely not.” The malicious dependency had genuine execution exposure even though it did not survive into the resulting container image or appear in its bill of materials.

That case separates final-state visibility from build-time exposure because the two answer different security questions. An SBOM can provide useful information about components associated with an artifact, while temporary dependencies can cause harm before the artifact exists. A security process focused on what remains at the end can therefore miss code that participated in producing the software.

Covering that gap requires supply-chain systems that can control layers of inherited software. Castro says organizations can build such systems themselves with sufficient investment, but scale becomes difficult because producing trustworthy open-source packages requires more than checking each direct dependency in isolation. AI-driven dependency growth raises the workload on that infrastructure, while transient build behavior makes artifact inventories incomplete and pushes more findings toward downstream detection systems.

More scanning moves the bottleneck downstream

When more dependencies reach downstream detection, extra scanners can find more problems, but every detected issue creates work elsewhere in delivery. “Doing more of the same things that traditionally haven’t worked great, at much higher speed and scale, means you’ve failed before you started,” Castro says. His argument concerns the remediation capacity behind detection because finding another vulnerability helps only when the organization can decide what to do with it and enforce that decision.

Existing vulnerability-management practice already shows that capacity constraint. “Companies already struggle to patch severe vulnerabilities, let alone all the mediums and highs they regularly risk-accept. More scanning and more patching won’t hold up against a geometrically larger volume of agent-developed code,” Castro says. Existing risk acceptance for medium and high findings shows that organizations already triage results, so more generated code increases the amount they must classify, patch, or accept.

Enforcement tools can turn those unresolved findings into blocked engineering work. Developer firewalls and policies that break builds can stop a dependency after the sourcing choice has entered the development flow, leaving developers to investigate why a pull request cannot proceed. A security queue then becomes an engineering queue close to the point where the team expected to ship.

That transfer imposes a direct delivery cost. “Engineers end up dealing with a whole bunch of broken builds when what they want to do is ship products that people love, not diagnose why a scanner says they can’t push their PR,” Castro says. Scanning, patching, and build controls remain useful defenses, but increasing their workload while allowing the same volume of risky inputs preserves the mismatch between fast dependency selection and slower remediation.

Secure-by-default has to cover the long tail

Reducing that downstream workload requires changing the condition in which dependencies enter development. Castro advocates open-source components rebuilt with provenance attestations, records that show where and how an artifact was produced, together with reduced attack surfaces and continuous maintenance. Chainguard sells software-supply-chain security products aligned with this model, so the company benefits commercially if organizations adopt this kind of upstream approach.

With those controls applied earlier, provenance can inform selection, while continuous maintenance can cover changes after initial approval. Components and the systems supplying them are systematically secured before individual applications assemble them, reducing the number of problems that scanners and release gates must send back to developers or security teams for manual resolution. The approach shifts work from repeated application-level remediation toward the dependency supply process.

That supply process still has to cover irregular requirements across the long tail. “There’s always some weird edge case or exception. There’s always a system that can’t be properly updated, always an app that requires some weird thing maintained by one person,” Castro says. Such cases sit in the part of the ecosystem that receives less collective scrutiny and that Chainguard’s CVE figures identify as carrying most of the measured exposure.

The same coverage problem reaches beyond conventional engineering teams through citizen development, where employees outside software teams build applications for their own work. A finance analyst can vibe-code, meaning build software through AI-assisted prompting, in an AI-assisted integrated development environment without a site reliability engineering (SRE) team or application-security (AppSec) specialists reviewing the result. Specialist review is hardest to apply in that workflow because dependency selection can happen immediately while no dedicated security expert participates.

Broader access to software creation therefore makes dependency coverage the practical constraint on upstream governance. Enterprises will still encounter obscure packages, legacy systems, specialized components, and exceptions, so the sourcing system has to handle those cases as they appear. Castro puts the requirement this way: “The idea that we can drive everybody toward the most popular things is great to say and very hard to do in practice. To me that argues for shifting toward components and systems that are systematically secured by default, rather than letting people do whatever and then trying to solve it somewhere right before we push into production,” Castro says.

Key takeaways for decision-makers

• Move dependency controls upstream: AI coding tools select and introduce dependencies faster than manual security reviews can assess them. Security and platform teams can establish trust closer to sourcing so approval does not become a delivery bottleneck.
• Govern machine-speed dependency selection: Coding agents can surface obscure, compromised, or malicious packages based on functional fit. Engineering organizations need provenance and sourcing controls that evaluate trust before these components enter development workflows.
• Cover the software long tail: Chainguard reports that 97% of measured container-image CVEs in its June data fell outside the 20 most popular images. Dependency programs need coverage for specialized and less-maintained components alongside widely used software.
• Track build-time dependencies: Transitive dependencies can execute during builds and disappear before the final container image or SBOM is created. Platform and security teams need controls that observe and govern the build process as well as final artifacts.
• Reduce downstream remediation pressure: More scanning creates more findings for engineering and security teams to investigate, patch, accept, or block. Organizations can reduce that workload by improving dependency trust before components reach release gates.
• Make secure components the default: Provenance attestations, reduced attack surfaces, and continuous maintenance can shift security work toward the dependency supply process. Platform teams need this model to cover legacy systems, edge cases, and AI-assisted development outside traditional engineering teams.