Why AI makes software supply chain attacks cheaper to scale

AI is weakening a familiar security response to software supply-chain attacks: scanning more code and detecting more malicious activity. Attackers can reach many organizations earlier through the systems that acquire, build, sign and distribute software, while AI increases the number of people and agents consuming third-party components. For CISOs, that shift moves the useful security boundary to an earlier decision: which artifacts builders may trust and which environments may process them.

AI changes the economics of software supply-chain attacks

That earlier boundary matters because attackers have increasingly turned to continuous integration and continuous delivery (CI/CD) pipelines, npm and PyPI packages, GitHub Actions workflows, and AI agent tooling connected to development. Quincy Castro, CISO of Chainguard and previously CISO at two large multinational firms, says widely used open-source packages are being taken over “almost weekly,” a compromise can potentially reach “tens of thousands of organizations downstream,” and software supply-chain attacks began accelerating in early 2026.

Castro sees an economic change driving that acceleration. “Supply chain attacks were previously considered rare and exotic, typically very intentional and very methodical, and defenders saw them primarily as a nation-state technique for getting into hard places,” he says. “What we‘ve seen this year is profit-motivated attackers recognizing that software development is the soft underbelly of organizations. As we‘ve gotten better at defending traditional endpoints and cloud environments, we‘ve naturally pushed adversaries toward a far less defended area.”

Those economics improve further when an attacker compromises something consumed by many organizations. Previous-decade watering-hole campaigns established a related one-to-many pattern by compromising websites and exposing their visitors; with software, a compromised open-source project can potentially reach every project that installs it. The attacker’s marginal cost for each additional victim can fall to “roughly zero,” while the attacker inspects compromised downstream environments and pursues the most valuable ones.

The overlooked security boundary is the build system itself

Those one-to-many economics expose a mismatch in many CI/CD security programs because reviews often concentrate on code even though the infrastructure processing it has substantial privileges of its own. A build runner can hold registry credentials, signing keys and cloud service-account tokens while executing installation scripts from the dependencies it resolves. A compromised build environment can therefore provide forms of access that code-quality and vulnerability gates were never designed to govern.

Those privileges make GitHub Actions another part of the trust boundary. A workflow can reference a third-party action through a mutable tag, which means an upstream owner can redirect the tag to another commit. A build that previously consumed expected code can then execute different code without the organization deliberately changing its workflow, so the pipeline also depends on the trustworthiness of that upstream component.

That upstream trust can affect later stages because build systems often possess credentials used beyond a single build job. A pipeline can pass every security check applied to its application code while exposing credentials able to sign and publish a release or authenticate to an artifact repository or cloud service. Code scanning can work exactly as configured while another part of the same system gives an attacker high-value access.

Castro describes how successful checks can obscure the wider system. “You may have a pipeline where you think, ‘I’m doing great at security: I’m scanning my code, I‘m blocking criticals from passing CI checks,’ and so on,” he says. “Then you zoom out and that build system is sitting on the public internet, because the dev team is globally distributed, and you’ve let them put long-lived personal access tokens in their build scripts. That is not a secure system.”

The global distribution in Castro’s example matters because development infrastructure must support how engineering actually works. Build services exposed for legitimate operational reasons can still become sensitive security boundaries when they carry long-lived credentials and execute externally sourced code. The control problem therefore covers what build infrastructure executes and what privileges are available during execution, extending security policy beyond vulnerabilities in the code being shipped.

Monitoring acts after execution

Those build-system privileges make wider monitoring useful for visibility, but monitoring runs into an ownership gap. Security telemetry commonly covers endpoints, identity systems and production infrastructure, while engineering operates build servers, artifact repositories and runners. Some engineering systems can remain unmonitored, leaving part of the software path with powerful credentials and weaker observation than production.

Extending telemetry into those systems creates a comprehension problem because normal build infrastructure downloads dependencies, executes scripts, manipulates artifacts, calls cloud services and publishes output. Legitimate engineering activity can consequently overlap with behavior defenders need to investigate. Security operations must understand enough of the engineering context to distinguish the two while processing the added stream of events.

Castro argues that many teams lack enough operational knowledge to make that distinction. “If you look at most traditional security teams, they typically employ few to no folks with real DevOps or SRE experience,” he says. “They’re frequently asked to monitor and secure systems that they’ve never used and don’t understand, and they lack the trust of their engineering counterparts who are afraid the security team will break stuff.” The gap is organizational as well as technical because security can be responsible for systems it did not design, operate or routinely use.

That organizational gap becomes harder to close in companies built through acquisitions. Each deal can bring an inherited toolchain, creating multiple ways to build, store and release software and making a uniform control model difficult to impose. Castro’s previous CISO experience at two large multinational companies informs his view that this is a practical problem in large environments, while shipping pressure and inadequate security support affect developers at companies of every size.

Those constraints give earlier admission controls different leverage from downstream detection. Once an unknown dependency executes on a runner with access to signing credentials or cloud service-account tokens, defenders must identify malicious behavior inside an already privileged environment. A policy that decides whether the dependency may enter the build makes that decision before the build exposes those privileges.

AI removes the centralized chokepoint security used to depend on

Earlier admission controls become more valuable as AI-assisted development expands software creation beyond engineering teams with mature CI/CD platforms. Developers under pressure to ship may need components they lack the time or expertise to evaluate deeply, while the security support available to them varies sharply. “Developers have to do what they can do to make their job easier,” Castro says. “If they need a particular GitHub action, they’re going to go grab it and run it, and they have to assume their security team is doing what it should be doing to protect them, even though in many cases that’s not actually happening behind the scenes.”

Agentic coding tools expand the builder population further through citizen development, where analysts and operations managers without production coding backgrounds can create software. Some of this work happens outside the environments and processes IT traditionally governs, including on individual laptops that obtain packages directly from the open internet. When code acquisition and execution happen there, security loses the centralized point where an organization could consistently apply policy before execution.

Losing that centralized point affects several populations differently. Citizen developers may lack experience evaluating packages; globally distributed engineers need development systems accessible across locations; acquired businesses may keep using inherited toolchains; and professional developers can lack sufficient security expertise or support while still carrying delivery responsibilities. As these legitimate working patterns multiply, a security architecture built around one centrally standardized environment covers a smaller share of software creation.

Castro says IT’s existing controls are consequently insufficient, based partly on Chainguard’s conversations with organizations affected by the 2026 attacks. “What we found when we talked with folks who had been impacted by the flood of supply chain attacks this year is that often the only line of defense they had was traditional endpoint detection and response (EDR) and antivirus,” he says. Security operations teams then repeatedly handled malware or worm alerts and searched environments to determine whether engineers had been affected.

Those conversations describe a specific operational sequence: unrestricted package consumption happens first, EDR or antivirus observes the consequences later, and the security operations center (SOC) absorbs the investigation. Castro puts the point more sharply: “This is the CISO in me talking, but as much as people throw around words like AI native, there’s nothing AI-native about letting anybody do anything and leaving security teams to deal with the consequences.” His argument is that controls need to move with the act of acquiring and executing software.

AI therefore changes the distribution of software-making decisions as well as development throughput. More people and agents can choose dependencies, including participants who cannot reasonably be expected to perform expert security review on every package they encounter. Security controls have to follow that distributed development model by governing where software is acquired and executed.

Trivy shows why discovery may come too late

The case for earlier controls becomes clearer when a compromise persists beyond the malicious package’s immediate execution. Supply-chain attacks can harvest secrets that remain useful after defenders discover the entry point because an attacker may have collected separate credentials for cloud systems, infrastructure or data. Removing the malicious component leaves those independently useful credentials in the attacker’s possession until defenders identify and invalidate them.

The March 2026 attack involving Trivy, Aqua Security’s widely used open-source vulnerability scanner, shows that persistence problem. Attackers harvested cloud keys, SSH keys, Kubernetes tokens, database passwords and other secrets, potentially exposing more than 2,500 organizations. Those secret types show how compromise of a development dependency can create access extending well beyond the dependency itself.

That wider access makes the sequence after discovery critical. Aqua Security discovered an earlier breach and rotated credentials, yet containment remained incomplete; attackers retained access, and that access helped enable a subsequent supply-chain attack. Credential rotation responded to the discovery, but the earlier compromise had created paths that required further containment.

Trivy therefore stress-tests an approach that puts the main burden on detection and response. Once secrets have been harvested, defenders need to understand and invalidate what the attacker acquired across cloud accounts, SSH access, Kubernetes environments, databases and other systems. Preventing a suspect artifact from gaining that initial position has different leverage because it can stop the credential-harvesting opportunity from arising.

Provenance turns upstream trust into something pipelines can enforce

That preventive leverage underpins the model Castro advocates, moving the trust decision ahead of execution. “Folks need a radically different way of dealing with supply chain security focused at least as much on prevention as on detection and response,” he says. “The goal should be to keep compromised packages out of the environment in the first place.” Detection remains necessary, while an upstream trust decision can reduce how many untrusted artifacts defenders must later observe inside privileged systems.

Scale makes those trust decisions difficult to perform manually. Castro expects open-source volume to keep growing while vibe coding, developing software primarily by directing AI coding tools, increases the number of agents and less-skilled users encountering packages. “We are moving into a world of unlimited open-source code, and it’s not going away,” he says. “Separately, the volume of code and the increase of vibe coding is exposing agents and less skilled users to malicious look-alike packages and typo-squatting attacks.”

That scale makes provenance useful because it attaches evidence about an artifact’s origin and production to the artifact itself. Verified provenance, signed artifacts and trusted build systems let a pipeline evaluate defined evidence before accepting a package, while human review can focus on policy and exceptions. As package consumption grows, machine-speed validation lets the trust decision scale with automated software creation.

Cryptographic evidence then makes the trust question more precise. “You want to validate that what you’re pulling into your build pipeline is exactly what it’s supposed to be, not just taking someone’s word for it, but being able to cryptographically prove it,” Castro says. “You also want to know it was built in a secure environment and didn’t have something snuck in at the last moment.” The resulting policy can evaluate the artifact’s identity and integrity together with the conditions under which it was produced.

Chainguard has a direct commercial stake in that prescription because it benefits when organizations adopt this model. Its business includes sourcing, analyzing, securing and rebuilding open-source packages and container images, then distributing them with provenance so customers can make an artifact-trust decision before deployment. The approach moves part of the security burden onto the development platform: the platform supplies evidence, and the pipeline decides whether an artifact meets the organization’s requirements.

That commercial alignment gives readers important context for Castro’s recommendation. As Chainguard’s CISO, he represents a company that sells services built around the kind of artifact trust he advocates. The mechanism he describes is concrete: provenance supplies data that automated policy can check before an artifact executes, moving the decision earlier than EDR, antivirus or incident response can act.

Secure development platforms can restore control across distributed development

Provenance governs artifact admission, while the surrounding development environment can constrain what builders consume and what compromised code can reach. Castro’s proposed stack includes configured artifact repositories and appropriate CI/CD tooling alongside hardened actions, runners, skills and inherently secure components. “An attacker might be able to do some bad stuff,” he says, “but they are going to have to work a lot harder and you’ve handed a lot of advantages to your defenders in the meantime.”

That caveat sets the objective: raise attacker costs and reduce available paths. A constrained stack can limit exposure to arbitrary packages and weak build components, while hardened runners and actions reduce the opportunities available after something hostile gets through. Defenders gain leverage by determining the conditions under which development occurs before an incident forces the SOC to reconstruct those conditions afterward.

Those conditions also include execution location. Security can offer a monitored cloud environment with the resources developers need, keeping experimental AI-assisted work within infrastructure the organization can observe and reducing the amount dispersed across individual laptops. Builders can still experiment, while security retains visibility into the environment where packages, tools and generated code execute.

Making that environment workable requires security to build it with engineering and site reliability engineering (SRE) teams because those teams understand the systems that run the development process. Castro says proactive collaboration can support software-supply-chain security and application security while enabling AI adoption, digital transformation and innovation. For an organization with distributed teams, citizen developers and inherited toolchains, the scalable boundary becomes what builders and AI agents are permitted to trust and where they are permitted to execute.

In conclusion

For executives, the software supply chain is becoming a business control problem as much as a security engineering problem. AI-assisted development increases the number of people, agents and environments able to select and execute third-party software, while build systems can expose credentials and privileges capable of reaching far beyond a single application. That combination makes downstream detection an incomplete control.

The executive decision is therefore where the organization wants to enforce trust. EDR, vulnerability scanning and incident response remain necessary, but they operate after software has entered an environment or begun executing. Provenance, trusted artifact sources, hardened build infrastructure and admission policies can move part of that decision earlier, before an unknown component receives access to valuable systems and credentials.

That shift also requires coordination across security, engineering, SRE and platform teams. Leaders need to know where software is acquired, which build environments can access sensitive credentials, what evidence is required before an artifact executes and whether AI-assisted development outside traditional engineering follows the same rules. Acquisitions and decentralized development make uniform tooling difficult, but they increase the value of a consistent trust policy.

As AI lowers the cost of creating software, organizations should expect the volume of dependencies and software supply-chain activity to keep increasing. The scalable response is not to ask every developer or AI agent to make expert security judgments. It is to build those judgments into the platforms and policies that determine what software the organization trusts and where it is allowed to run.