Presented by Chainguard


Attackers are increasingly moving upstream, targeting the systems that build and distribute code rather than the applications that emerge from them. CI/CD pipelines, package registries including npm and PyPI, GitHub Actions workflows, and the AI agent tooling are now connected to all of them, attracting the attention that production software used to. Adversaries take over widely used open-source packages almost weekly, and a single compromise can reach tens of thousands of organizations downstream.

Software supply chain attacks began accelerating in early 2026, says Quincy Castro, CISO at Chainguard.

"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," Castro 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."

Software supply chain attacks harken back to the watering hole campaigns of the previous decade, where attackers compromised websites in order to exploit unwary visitors. That “one to n” dynamic works to the advantage of attackers in supply chain attacks too, where compromising a single open-source project gives attackers a potential shot at compromising every project that installs it, dropping the marginal cost of each additional victim to roughly zero, while letting the operator choose which compromised environments to pursue.

CI/CD pipelines and build servers are undefended

Development pipelines run on delivery schedules, and security reviews concentrate on the code passing through, rather than the machinery moving it. A build runner holds registry credentials, signing keys, and cloud service account tokens, while executing install scripts from every dependency it resolves. It may also reference third-party actions by mutable tags that an upstream owner can repoint at any commit. That means a pipeline that clears every check it applies to the code can still be handing an attacker the credentials that sign and publish the release.

"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," Castro 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."

Detection and response teams compound the gap, because their telemetry covers endpoints, identity systems, and production infrastructure, while engineering runs the build servers, artifact repositories, and runners. These might not be monitored at all, or if they are, it’s frequently unclear to defenders what behavior is indicative of a real intrusion versus engineering work.

“If you look at most traditional security teams, they typically employ few to no folks with real DevOps or SRE experience," Castro adds. "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.”

Size makes standardization harder, particularly at businesses that have been growing through acquisitions and inheriting a new toolchain with every deal. Castro, who has previously held CISO roles at two large multinational firms, points out that developers in companies of every size are under constant pressure to ship quickly, and not all of them have the backup or expertise they need to do it securely.

"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."

AI coding agents and citizen developers widen the attack surface

Citizen developer programs let analysts and operations managers who have never written production code build with agentic coding tools, pushing software development beyond the environments and processes traditionally governed by IT.

Much of that work happens on laptops and involves pulling packages off the open internet, with no chokepoint to insert security controls. Existing security controls run by the IT team aren't enough anymore, Castro says.

“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 explains. "The security operations teams at these companies were being run ragged, responding to alerts that malware or a worm had installed itself, or they’d be constantly searching their environments to see if their engineers had been hit. 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.”

Supply chain security has to move ahead of incident response

The damage from a supply chain compromise can outlast the response. These attacks often harvest secrets from the environments they reach, giving attackers credentials they can use long after the initial compromise has been discovered.

In the March 2026 attack on Trivy, the widely used open-source vulnerability scanner, attackers harvested cloud keys, SSH keys, Kubernetes tokens, database passwords and more, potentially exposing more than 2,500 organizations. Aqua Security rotated credentials after discovering the earlier breach, but the containment was incomplete, leaving attackers with access that helped enable a subsequent supply chain attack.

"Folks need a radically different way of dealing with supply chain security focused at least as much on prevention as on detection and response," Castro says. "The goal should be to keep compromised packages out of the environment in the first place."

Provenance moves the decision upstream

"We are moving into a world of unlimited open-source code, and it's not going away," Castro 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."

To sort the safe from the unsafe at that volume requires evidence attached to the artifact. That turns verified provenance, signed artifacts, and trusted build systems into a control the pipeline enforces on its own, at machine speed.

"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," he 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 development environment becomes the security control

Chainguard builds its business on that premise, safely sourcing, analyzing, securing, and rebuilding open-source packages and container images and shipping them with provenance so customers settle the trust question upstream of deployment. That moves the burden onto the platform and sets a ceiling on how much damage can be done with the stack builders are handed.

"That means tools are configured with artifact repos, configured with the right CI/CD tooling, with hardened actions, hardened runners, hardened skills, and inherently secure components," Castro says. "An attacker might be able to do some bad stuff, 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 also applies to where the code runs. A security organization can provide a monitored cloud environment with the resources builders need, keeping experimental work inside a space the company can observe rather than on individual laptops outside its view, which is a boon to security leaders trying to maintain visibility as AI development expands.

"For those CISOs looking to differentiate themselves and be seen as empowering the business, building this out proactively in partnership with engineering and SRE is a way to help your business be proactive around software supply chain and app security," Castro says. "It's also how organizations can promote innovation, digital transformation, and the adoption of AI without sacrificing control over the software supply chain."


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.