AI coding tools are making your dependency problem much worse
Every time your AI coding assistant pulls in a package, it’s making a decision your security team hasn’t reviewed. Multiply that across an entire engineering org and you get dependency sprawl at a scale traditional governance processes were never built to handle.
Chainguard CISO Quincy Castro puts it plainly:
“Velocity has outpaced governance and controls. When you can generate code instantaneously, the traditional request, review, and approve cycle bottlenecks people.”
The review process was already broken
Castro argues AI hasn’t broken a functioning system. Across four CISO roles, he’s watched teams build to MVP first and only then bring in security for a sign-off at the end. That model was already unsustainable before agents entered the picture.
AI agents select dependencies based on relevance to a prompt, not on how well a package is maintained. Citizen developer programs compound the problem by putting software assembly in the hands of people without traditional engineering training.
Where attackers actually go
Popular packages attract more maintainers, more contributors, and more automated scrutiny, which makes them expensive targets. Attackers go after long-tail, less well-maintained projects instead, then find ways to drive developers toward them for maximum spread.
One recent operation mass-produced forks of legitimate projects, seeded malware into them, and scattered them widely enough that developers mistook a fork for the official repo. In March, attackers who seized the Trivy scanner’s GitHub Actions force-pushed 75 of 76 version tags to commits carrying an infostealer, then used the harvested secrets to publish malicious npm packages downstream.
The numbers that should concern you
Chainguard’s March 2026 State of Trusted Open Source report found that 96.2% of CVEs sit outside the top 20 container images. The June edition raised that to 97%. Enterprise hardening programs concentrate resources on the small set of images that account for the remaining sliver, while actual exposure lives in the long tail.
Transitive dependencies are the real blind spot
Pulling in a package means inheriting everything its authors depended on, and everything those dependencies depended on in turn. Visibility fades two or three layers down. Castro describes a real detection that fired for malware in a dependency that wasn’t in the container image or the bill of materials because it was a transitive dependency that only ran briefly during a build. No normal developer building that project would have had any indication they were at risk.
Why scanning won’t scale
Castro’s argument against purely reactive security is direct:
“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.”
Developer firewalls and build-breaking policies intercept the problem late, close to production, turning a sourcing failure into a queue of blocked pull requests. Engineers end up diagnosing why a scanner won’t let them push a PR instead of shipping product.
The alternative Castro describes is sourcing open-source components that arrive already rebuilt with provenance attestations, minimal attack surfaces, and continuous maintenance. The goal is keeping vulnerabilities from reaching the scanner in the first place, rather than catching them just before production.
Note: this article was presented by Chainguard.
I’m founder of BizStack at Cagri Sarigoz LLC and a passionate advocate for entrepreneurs.
With over 14 years in tech, marketing, and AI, including my role as Head of SEO at CitizenShipper and co-founder of TaleBot at Intale AI, I’m dedicated to sharing genuine, useful product insights and tips.
At BizStack, I aim to cut through the digital noise to provide clear, actionable advice.
And more than all else, I’m a father to a (always) little girl and a husband.
Contact me at [email protected] for assistance.
