TL;DR
- Credential theft is becoming central to software supply chain attacks: Across the major 2025–2026 campaigns we analyzed, credential harvesting was the primary objective.
- Developer environments are valuable targets: Developer machines and CI/CD runners hold credentials for repositories, cloud infrastructure, package registries, and other systems.
- Automation gives attackers speed: A poisoned package can reach downstream environments through normal update and dependency workflows before defenders know it is compromised.
- Containment has to account for stolen access: Removing malicious code addresses the infection. Teams also need to understand which credentials were exposed, what they can reach, and whether they have been revoked.
A poisoned package may be where a software supply chain attack starts. The credentials it can reach determine what happens next.
Across the supply chain campaigns GitGuardian analyzed from 2025 through 2026, the initial access varied widely. Attackers compromised maintainer accounts, abused CI/CD workflows, rewrote GitHub Action tags, and poisoned trusted packages.
The objective was remarkably consistent: get credentials.
That changes how security teams need to think about software supply chain security. Protect against malicious code, yes, but also protect the access waiting for it once it executes.
Compromised software is a path to trusted access
Modern development environments need credentials to work. Developers authenticate to source code repositories, cloud environments, package registries, internal tools, and infrastructure. CI/CD pipelines need credentials to publish packages, deploy software, and interact with protected systems.
Attackers know where to look. Campaigns such as Shai-Hulud 2.0 and the Trivy compromise harvested GitHub tokens, package publishing credentials, SSH keys, cloud credentials, and other secrets that could provide access beyond the initially compromised package or machine.
That access can serve several purposes. A stolen credential might open another system, expose additional secrets, or give the attacker the publishing rights needed to push malicious software to another set of victims.
In other words, credential theft can become part of the propagation mechanism itself. The supply chain gives attackers distribution. Credentials give them somewhere to go next.
Developer machines and CI/CD runners concentrate access
There is a reason these campaigns keep landing on developer endpoints and build infrastructure. A production server usually holds credentials associated with the services it runs. A developer machine may contain credentials accumulated across repositories, cloud environments, CLIs, project directories, configuration files, and years of work.
CI/CD runners have their own concentration of access. A single pipeline may need permission to pull private code, publish artifacts, deploy applications, or communicate with production infrastructure.
The Shai-Hulud 2.0 dataset makes that concentration visible. GitGuardian analyzed 20,649 exfiltration repositories containing 33,185 unique secrets, with 3,760 confirmed valid at the time of analysis. For an attacker executing code in one of these environments, compromising the machine may only be the first step. The more important question is what that machine can authenticate to.
Automation makes the window painfully short
The same automation that keeps software current can move a compromised release quickly. When a poisoned Axios version appeared on npm, Dependabot opened its first pull request within five minutes. Across the attack window, 895 repositories were affected.
No developer has to deliberately download a malicious package for this model to work. Dependencies are installed during builds, bots propose updates, CI workflows fetch Actions automatically, etc. Coding agents can increasingly make package changes on a developer's behalf.
This is part of what makes modern supply chain incidents difficult to contain. By the time the malicious release is identified, execution may already have happened across developer machines and pipelines. And once credentials have been harvested, stopping the original package does not invalidate the access it collected.
The response question changes after execution
Traditional supply chain response naturally starts with the compromised artifact: Where was it installed? Which version ran? Which machines and pipelines were affected?
A credential-harvesting campaign adds another layer: Which identities were exposed, and what could they reach?
If malware accessed a cloud credential, GitHub token, SSH key, or package publishing credential, cleaning the affected machine does not close that access path. Responders have to establish the credential scope, identify ownership, prioritize the highest-risk access, and revoke or rotate it. That becomes much easier when the organization already knows where its secrets and non-human identities live. Waiting until the incident to build that map means reconstructing it while the response clock is already running.
See the full anatomy of a credential-harvesting supply chain attack
Our ebook, When the Supply Chain Becomes a Credential Attack, traces this shift across the major supply chain campaigns of 2025 and 2026.
It follows the attack chain from initial compromise through propagation, credential harvesting, exfiltration, and reuse, then breaks down the controls that can reduce both the chance of compromise and the access available afterward.
For security teams responsible for developer environments, CI/CD, secrets, or incident response, the bigger question is becoming clear: if trusted software turns hostile, what credentials are waiting within reach?
FAQ
What is a software supply chain attack?
A software supply chain attack compromises a component or process that organizations trust to build, distribute, or update software. Attackers may target packages, developer tools, CI/CD workflows, package maintainers, or other parts of the development ecosystem to reach downstream users.
Why do software supply chain attacks target credentials?
Credentials can extend an attacker's access beyond the initially compromised machine or package. Tokens, SSH keys, cloud credentials, and publishing credentials may provide access to repositories, infrastructure, additional secrets, or software distribution channels.
Why are developer machines targeted in supply chain attacks?
Developer machines often hold credentials for many different systems, including source code repositories, cloud services, package registries, and internal development tools. That concentration of access makes them valuable targets for credential-harvesting malware.
Why are CI/CD pipelines high-value targets?
CI/CD pipelines need significant permissions to build, publish, and deploy software. Depending on the workflow, a runner may have access to publishing credentials, source code, deployment credentials, or other secrets. If attacker-controlled code executes in that trusted context, those credentials may become accessible.
How should organizations respond to a credential-harvesting supply chain attack?
Teams need to contain the compromised execution environment and determine which credentials or identities may have been exposed. Response should include scoping affected access, reviewing evidence of credential use, and revoking or rotating exposed credentials based on their permissions and potential impact.
Guillaume Valadon
Mackenzie Jackson
