Presented by Chainguard
AI coding assistants are pulling open-source packages, libraries, and container images into enterprise codebases faster than security teams can review them, and the resulting dependency sprawl is widening the attack surface for software supply chain attacks. Malicious packages, typosquatted libraries, and compromised transitive dependencies all enter through the same automated pipeline.
Software composition once reflected deliberate human decisions, with an engineer choosing a library they had used before and could defend in review. The approval machinery that was built around that assumption runs on review cycles measured in days, which means enterprises are left with too wide a gap between how fast software arrives and how quickly and thoroughly it gets verified.
"Velocity has outpaced governance and controls," says Chainguard CISO Quincy Castro. "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."
That means two things have changed. Agents select dependencies based on their relevance to a prompt, which may have little to do with how well that dependency is maintained. At the same time, citizen developer programs put software assembly in the hands of people without traditional software engineering training, making technical validation more difficult.
Why security teams never fully vetted open-source dependencies
But AI hasn't broken a functioning review process, Castro says. Across four different CISO roles, he's watched engineering teams carry an idea from the whiteboard to MVP, and only then approach security for a sign-off at the very end; a process he says is unsustainable.
"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," he explains. "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."
Gates exist today because organizations already had to assume individual judgment could or would fail. But agentic development is erasing the pause in the development process where those gates traditionally kicked in.
Attackers are targeting long-tail open-source packages
Bad actors tend to go for more obscure projects, because popular ones attract the most maintainers, more contributors reviewing changes, and more automated scrutiny, which makes them expensive targets.
"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. "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 points to a recent attack operation that mass-produced forks of legitimate projects, seeded malware into them, and scattered them widely enough that developers would mistake a fork for the official repository and pull attacker capability into their CI/CD pipeline. But that doesn’t mean popular projects aren’t targets: In March, intruders who seized the Trivy scanner’s GitHub Actions force-pushed 75 of 76 version tags to commits carrying an infostealer. They then used the harvested secrets to publish malicious npm packages downstream.”
Attackers are also increasingly using typosquatting, maintainer account takeover, poisoned distribution points, and dependency riding. Castro says the trust those techniques exploit was never warranted, given that anyone can write and publish open-source code.
"You would never pick up a thumb drive in a parking lot and plug it into your laptop or pick up a sandwich sitting on a fence post," he says. "You're not thinking, free sandwich, let me eat that. You want to inspect it first and understand whether it's fresh, whether it's safe, why it's free."
96% of CVEs sit outside the top 20 container images
Chainguard's March 2026 State of Trusted Open Source report found that 96.2% of common vulnerabilities and exposures (CVEs) sit outside the top 20 container images, and the June edition raised that number to 97%. Enterprise hardening programs concentrate on the small set of images that account for the remaining sliver.
"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."
Transitive dependencies create supply chain blind spots
Pulling in a package means inheriting whatever its authors chose to depend on, and whatever those dependencies chose in turn. Visibility fades two or three layers down, making malicious code at that depth much harder to detect.
"We've had detectionsfire for a dependency with malware in it, and find it isn’t part of the container image, or not in the bill of materials," Castro says. "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."
Ensuring safe transitive dependencies is one of the issues DIYers run into when they try to build their own systems for securing the software supply chain. Teams can certainly do it with enough investment, but the difficulty of doing it at scale becomes apparent only once they start assembling the systems needed to produce safe, trustworthy open-source packages.
Vulnerability scanning can't scale with AI-generated code
"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. "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."
Developer firewalls and build-breaking policies inherit the same limitation. They intercept the problem late, close to the engineer and close to production, converting a sourcing failure into a queue of blocked pull requests.
"Engineersend up dealing with a whole bunch of broken builds when what they want to do is ship products that people love, not diagnosewhy a scanner says they can't push their PR," Castro says.
Secure-by-default open source and verified provenance
If scanning and patching break down at scale, the alternative is to keep vulnerabilities from reaching the scanner in the first place, by sourcing open-source components that arrive rebuilt with provenance attestations, minimal attack surfaces, and continuous maintenance behind them. The prevailing model is similar to a car whose only safety feature is its airbags: useful in the worst-case scenario, but no substitute for headlights, anti-lock brakes, and traction control. Verified, secure-by-default components are meant to be those preventive layers, shrinking the vulnerability load before any gate has to catch it. But no prevention model can depend on steering every team toward the best-supported packages. And a finance analyst who vibe-codes an internal tool in an AI-assisted IDE has no SRE team or application security staff checking their output.
"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. "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."
Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.