For most of the past two decades the assumption was simple: code is written inside your business, then moves outward to production, and the network edge is where you check everything that crosses. That model stopped describing how software is built some time ago.
Shipped software is now composed continuously from third-party code and infrastructure, none of which the old perimeter could see. This article argues the perimeter has relocated to the supply chain, and that the build pipeline and what flows through it is the asset under attack. See our software supply chain security in 2026 overview.
What is the software supply chain perimeter, and why is it now the attack surface?
The software supply chain perimeter is everything that can influence a shipped artefact: dependencies, registries, build runners, signing keys and CI configuration. The network perimeter assumed code was written then moved; the supply chain perimeter recognises code is composed from third parties continuously, so the boundary now runs through registries, runners and signing pipelines.
A supply chain attack works by compromising something you already trust, a library, a tool, an update server, and using that trust as the delivery mechanism. As Sysdig puts it, the payload doesn’t break in, it gets invited. The attack surface now includes everything the code depends on and everything that delivers it.
That is why the boundary is now a web of trust relationships. 87% of audited codebases carry at least one open-source vulnerability, averaging 581 per codebase. Adam Bullock frames the shift: production infrastructure is the destination, the supply chain is the journey, and attackers are now targeting the journey.
Why has the attacker’s target shifted from the package to the build pipeline?
The package is now a defended, well-understood target, while the build pipeline is softer and higher-leverage: one poisoned build reaches every downstream consumer of the artefact. Attackers moved upstream to where a single compromise multiplies across many projects.
CI/CD pipelines hold more privileged access than most engineers, running in a high-trust, low-visibility zone built for speed at the expense of scrutiny. Compromise one dependency or configuration and malicious code can propagate across every environment the pipeline deploys to.
ChainDrop made that concrete. The worm rode GitHub Actions OIDC trusted publishing, so poisoned packages carried valid provenance from a legitimate workflow identity. The pipeline itself became the delivery mechanism, and a single compromised maintainer, token or CI tag can produce downstream victims in the thousands.
Why are CI/CD credentials the primary target of open source attackers?
What those poisoned builds actually harvest is what makes the victim count so high: credentials. The credential is the actual payload, because npm tokens, GitHub PATs and OIDC identities grant ongoing access that outlasts any single package, so a harvested token becomes a path for lateral movement. Secrets then accumulate across runners, the instance metadata service, HashiCorp Vault, Kubernetes service accounts, and AWS Secrets Manager and SSM, each multiplying the blast radius.
Attackers chase CI/CD credentials because of the authority they carry: access to source code, build systems, registries such as npm and GitHub Packages, cloud infrastructure and production delivery. OIDC is the short-lived improvement over long-lived PATs, issuing each job a credential scoped to itself that expires within minutes.
Runner memory scraping reads a live build agent’s process memory, and stealers read memory, not logs, pulling OIDC tokens and runner secrets from the running process. Instance metadata is another path: attackers probe IMDSv1 and v2 for IAM role credentials, which is why IMDSv2’s session-token requirement is the SSRF-hardening answer. That is what you are up against. The full anatomy of how the ChainDrop worm spread across npm shows the same credential-first pattern. Here is how to scope your own exposure.
How do I assess whether our company is exposed to a supply chain compromise?
Assess exposure with three questions: what we consume, what can reach our build, and what our build can reach outward. Inventory codebases, CI configuration and developer machines for affected package versions, then consult ecosystem advisories. This scoping is a decision process.
Start with the artefacts that record your dependencies. Lockfiles and dependency manifests show what each codebase and CI job actually resolves, and an SBOM gives a consolidated inventory that answers “am I affected” fast. Include developer machines separately, because local installs drift from the repository and can hold tokens your business’s manifests never record.
There is a limit to what that inventory tells you. 633 malicious npm package versions passed Sigstore verification because the attacker held a valid signing certificate. So provenance is not the same as safety: a valid signature confirms the build came from a real workflow; it does not confirm the publisher was authorised. See the wider supply chain picture.
How do I tell whether we are only a victim or also a distributor in a worm incident?
Apply the Propagation-Node Test. A victim only consumes a compromised artefact; a distributor additionally republishes or propagates it through stolen publish tokens, automated pipelines, or worm behaviour. Token monitors and dead-man’s switches surface the credential use that reveals whether you are spreading the incident.
The distinction changes your obligations. Any compromised organisation with publishing privileges becomes a distribution node, so the first question is which one you are. A worm enumerates every package the compromised identity can publish, then pushes poisoned patch releases using stolen tokens.
Token monitors and dead-man’s switches are the observability that answers the question, because pipeline compromises are designed to be quiet. Watch for token use from infrastructure your team never provisioned and publishes that came from nowhere. A distributor also carries reporting duties a victim does not.
What questions should I ask to limit the blast radius of a compromised build environment?
Ask what a poisoned build step can reach, and how quickly new versions can enter it. The levers are a minimum release age (cooldowns), install-script gating, egress allowlisting by default-deny, private registry proxying, and credential rotation, where revoking comes before rotating.
Cooldowns delay adoption so ecosystem detection can catch a malicious version first. Most malicious packages are discovered and removed within days, and a seven-day cooldown would have prevented over 90% of recent attacks. The trade-off against velocity is real, so match the cooldown to how fast you genuinely need new versions.
Install-script gating removes the default execution of lifecycle scripts, the worm’s main entry point, and running CI with lifecycle scripts disabled neutralises the dropper class. Egress allowlisting contains what a poisoned step can reach outward; private registry proxying mediates what reaches the build in the first place. Rotation sequencing matters most of all: revoke before you rotate, and rotate the credential that reaches the most systems first.
The perimeter relocated to the supply chain, and what it now protects is the credentials that flow through the build. Scope what you consume and what your build can reach, establish whether you are spreading the incident, and shrink the blast radius.
Defence now lives at the composition layer. For the full programme, start with the new perimeter in 2026.
Frequently Asked Questions
Is the software supply chain perimeter just application security under a new name?
No. Application security protects the code you write and the application you ship, while the supply chain perimeter covers everything that can influence a shipped artefact: dependencies, registries, build runners, signing keys, and CI configuration. The overlap is real, but the supply chain is wider, because most of it is code you never authored and infrastructure you do not own.
Does signed provenance mean a dependency is safe to trust?
No. Provenance and signing prove where an artefact came from and that it has not been altered since, but they do not prove the code is safe or the publisher trustworthy. ChainDrop rode a legitimate, signed pipeline, which is exactly the point: a valid signature can confirm that a malicious build was produced by the real process.
If we run a private registry, are we still exposed to supply chain attacks?
Yes. A private registry mediates what reaches your build and gives you a place to enforce policy, but it is not a wall. If it mirrors or proxies upstream packages automatically, a poisoned version can still flow through, and any credentials or publish tokens attached to the registry remain a target. Treat it as a control point, not a guarantee.
Where can I check whether my codebase, CI, or developer machines use an affected package version?
Start with the artefacts that record your dependencies. Lockfiles and dependency manifests show what each codebase and CI job actually resolves, SBOMs give you a consolidated inventory if you generate them, and developer machines are worth scanning separately because local installs often drift from the repository. Cross-check any matches against the ecosystem’s published advisory before you act.
Do cooldowns on new releases actually stop attacks, or just slow teams down?
They help, and they do cost some velocity. A minimum release age delays adoption long enough for the ecosystem to notice and pull a malicious version, which is when most supply chain attacks are caught. The tradeoff is real for fast-moving projects, so the practical answer is to set a cooldown that matches how quickly you genuinely need new versions, rather than adopting every release on day one.
Which credential should we rotate first after a compromised build?
Rotate by blast radius, not convenience. The credential that reaches the most systems first, typically a cloud role or an OIDC identity with broad permissions, then publishing tokens such as npm tokens or GitHub PATs, then anything downstream those credentials could have touched. Revoke before you rotate, so the old secret cannot be used while the replacement is being issued.
Can a supply chain worm spread without publishing a new package version?
Yes, and this is the part teams miss. A worm can spread using stolen publish tokens to push a poisoned version of an existing package, or by executing inside CI pipelines and reusing the credentials they hold, without any new package appearing. That is why monitoring for unexpected token use matters as much as watching for new releases.
Is our organisation too small to be a worthwhile target?
No, and size is the wrong lens. Most supply chain attacks are opportunistic and automated, harvesting whatever credentials they find rather than choosing a victim. A small team with a publish token and cloud access is a useful stepping stone to the customers and partners downstream of it, so the relevant question is what your build can reach, not how big you are.
If we find a compromised dependency, is deleting it enough?
Almost never. Removing the package stops the immediate code path, but the payload was likely credentials, and those remain valid after the code is gone. Treat a confirmed compromise as a credential incident: scope what the build could reach, rotate anything the package might have harvested, and check whether your pipeline republished or propagated it.
What happens if the compromised build environment is a developer’s laptop rather than CI?
The same rules apply, with a smaller but still real blast radius. A laptop may hold long-lived tokens, SSH keys, cloud profiles, and package publish credentials, so a poisoned install script or dependency can harvest them just as a runner would. Include developer machines in your inventory, rotate credentials stored locally, and do not assume CI is the only place secrets live.
How would we notice a build pipeline compromise before customers do?
You probably will not, unless you build the observability for it. Pipeline compromises are designed to be quiet, so detection depends on watching for the credential use that has to happen: unexpected publishes, unfamiliar IP addresses or times, and token activity after a build has finished. Token monitors and dead-man’s switches surface exactly that signal, which is why they count as detection, not just response.
