AI-assisted development is pulling more people and more packages into software pipelines, while attackers are increasingly targeting the machinery that builds and distributes code. Chainguard's practical warning is that scanning the finished code is not enough when build runners, dependencies and publishing credentials may already be exposed.
Watch Desk analysis
What happened
Chainguard CISO Quincy Castro says profit-motivated attackers are moving upstream into CI/CD pipelines, package registries and GitHub Actions. A compromised open-source component can reach many downstream organisations, while a poorly protected runner may hold registry credentials, signing keys, cloud tokens and other secrets worth considerably more than the code being inspected.
AI raises the stakes by making software creation easier to distribute beyond conventional engineering teams. Castro argues that citizen developers and coding agents may fetch packages from the open internet on individual laptops, leaving security teams without a reliable place to enforce controls. The account appears in a VentureBeat article sponsored by Chainguard, whose business includes rebuilding open-source packages and images with provenance.
What to do now
- Verify every artefact
Require cryptographic provenance and signatures rather than trusting a package name or publisher at face value. - Harden the build machinery
Protect runners, actions, registries and publishing credentials, not only the application code travelling through them. - Avoid mutable references
Do not let third-party actions silently change underneath a previously approved pipeline configuration. - Create a development chokepoint
Give AI-assisted builders a monitored environment instead of leaving experimental work scattered across unmanaged laptops. - Prefer prevention over clean-up
Block untrusted packages before installation, because stolen secrets may remain useful after the original compromise is removed.
Why it matters
Generating code has become cheap and wonderfully impatient. Trusting every dependency it summons has not. An AI coding tool can multiply the number of components entering an organisation while making traditional manual review even less capable of keeping pace.
The practical consequence is a shift from asking whether the final code looks safe to proving where every component came from, how it was built and what permissions touched it. That is useful guidance, although the claimed attack trend and proposed remedy come from a vendor selling precisely this sort of protection.
Our read
The commercial incentive is impossible to miss, but the architectural advice holds up: secure the factory, not just the boxes leaving it. Teams adopting coding agents should make trusted package sources, short-lived credentials, pinned dependencies and monitored build environments part of the default path. If the safe route is the awkward route, enthusiastic automation will eventually find a shortcut around it.
What to watch
- Whether organisations extend security monitoring to runners, registries and artefact repositories.
- Whether coding-agent platforms add provenance checks before installing suggested packages.
- Whether package ecosystems make signatures and immutable references easier to enforce.
- Whether independent incident data supports Chainguard's account of accelerating attacks.
Discussion spark: Which supply-chain control should coding-agent platforms enforce by default before they install or execute a dependency?
Sources and evidence
- Software supply chain attacks surge in 2026 – VentureBeat (15 September 2026, 14:30 UTC)
Watch Desk is operated by WittyWires as an independent cross-cutting AI news tracker. It does not speak for the organisations or people it covers.