Supply chain malware is turning developer secrets into the real target

At a glance

What this is: This is an analysis of three simultaneous supply chain attacks that targeted developer and pipeline secrets across npm, PyPI, and Docker Hub.

Why it matters: It matters because compromised packages can expose NHI credentials at the point where IAM controls are weakest: build systems, developer machines, and runtime configuration.

By the numbers:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read GitGuardian's analysis of the April 2026 supply chain attacks on secrets

Context

Supply chain attacks against packages and build tooling are no longer just a software integrity problem. They are an identity problem, because the attackers are now hunting for non-human identities such as API keys, cloud credentials, SSH keys, registry tokens, and environment variables wherever developers and pipelines handle them.

This article focuses on a familiar but still undercontrolled failure mode in NHI governance: secrets are spread across repositories, CI configurations, developer machines, and package install paths. When compromised code executes inside those environments, access often depends less on the malware itself than on how much standing credential material was already available to harvest.

Key questions

Q: How should security teams handle secrets in CI/CD and package-install environments?

A: They should assume package installation is an execution event and minimize what secrets are present at that moment. Use least-privilege credentials, short-lived tokens, isolated runners, and secret injection only when required. The goal is to make a malicious install see as little reusable access material as possible.

Q: Why do supply chain attacks so often turn into identity incidents?

A: Because attackers are not only changing code, they are harvesting the non-human identities that code runs beside. API keys, cloud credentials, SSH keys, and registry tokens give direct access to infrastructure and publishing systems, so a compromised package becomes an identity compromise with wider blast radius.

Q: What is the difference between secret detection and secret revocation?

A: Detection finds exposed credentials, while revocation makes them unusable. A team can know a secret is compromised and still remain at risk if the token, key, or certificate is still valid. In NHI governance, revocation is the control that turns exposure into a contained event instead of an active breach.

Q: When does a compromised developer package become a major security risk?

A: It becomes a major risk when the package can reach high-value credentials or publish permissions. If install-time code can read environment variables, cloud tokens, or registry keys, the attacker may gain access beyond the developer machine. The risk increases again when those secrets can be reused across multiple systems.

Technical breakdown

Why install-time execution is so effective in package ecosystems

npm and PyPI both allow package install hooks or setup logic that runs during installation. That is useful for legitimate automation, but it also gives malicious packages a reliable execution point inside developer contexts. Once code runs at install time, it can enumerate environment variables, read local credential stores, inspect configuration files, and reach cloud authentication material already present on the machine. In CI/CD runners, the blast radius expands because those environments often hold deployment tokens, signing credentials, or registry access. The technical risk is not only malicious code, but the trust boundary created when package installation is allowed to execute with access to high-value secrets.

Practical implication: Treat package installation as an execution event and restrict what secrets are available in that context.

How credential harvesting becomes ecosystem-wide propagation

Some supply chain malware does more than steal secrets. In the CanisterSprawl campaign, the malicious package reportedly searched for npm publish tokens, then used them to tamper with additional packages and publish infected versions. That creates a worm-like pattern: access to one token can become access to the wider package ecosystem. If a PyPI token is also found, the attacker can shift laterally across ecosystems rather than staying in one lane. This is why NHI governance must treat registry tokens as privileged credentials, not low-risk developer conveniences. A single exposed token can become both a theft path and a distribution path.

Practical implication: Place registry tokens under privileged credential controls and monitor for cross-ecosystem misuse.

Why exfiltration method matters less than credential location

The article highlights both encrypted and plain-text exfiltration, but the bigger lesson is that transport choices are secondary to the inventory problem. Whether malware compresses, encrypts, or sends a tarball directly to command and control, the outcome depends on what secrets were reachable in the first place. That is a governance issue because secrets often persist in places teams do not consistently audit, including environment variables, configuration files, and developer endpoints. A mature NHI program focuses on reducing secret residency, limiting exposure, and ensuring revocation happens fast enough to matter.

Practical implication: Reduce the number of places secrets can live and automate revocation when exposure is detected.

Threat narrative

Attacker objective: Steal reusable NHI secrets and turn a single compromised install into wider access across developer, cloud, and package ecosystems.

1. Entry via compromised package, official extension, or trojanized install path that executes inside a developer or CI/CD environment.
2. Escalation through local discovery of environment variables, cloud tokens, SSH keys, registry credentials, and publish permissions.
3. Impact through exfiltration of secrets and, in some cases, reuse of registry tokens to spread malicious packages to new victims.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Secrets in the software supply chain are now NHI assets, not just developer leftovers. The article shows attackers targeting the credentials that make software delivery work, including registry tokens, cloud keys, and SSH material. That reframes supply chain defense as identity governance across build and developer surfaces, not just package integrity checking. Practitioners should treat every exposed secret as a potential access path into production and adjacent ecosystems.

Ephemeral execution does not eliminate standing privilege if secrets remain reachable. Even short-lived package installs can access persistent credentials stored in environment variables, config files, and local tooling. The control failure is not duration alone, but residue: secrets left behind in places the attacker can read during that brief execution window. Teams should shift from assuming install-time trust to enforcing least-privilege secret exposure at the point of execution.

Identity blast radius is the right concept for modern supply chain risk. Once a malicious package runs, the real question is not only whether code was compromised, but how far the credential set could reach. A single token may expose package publishing, cloud resources, or downstream automation. The practical conclusion is simple: reduce blast radius by segmenting credentials, narrowing scope, and revoking aggressively when any exposure is suspected.

Automation without revocation is incomplete NHI governance. Detection tools can surface exposed secrets quickly, but the article reinforces that exposure is only the first step in the incident. If valid credentials remain usable after discovery, the adversary still has time to act. Security teams need workflows that connect detection, ownership, and revocation so exposed secrets do not remain active long enough to become incidents.

Package ecosystems are becoming credential collection systems for attackers. npm and PyPI are not just software distribution channels anymore. They are efficient environments for gathering reusable access material from developers, build runners, and downstream automation. That means practitioners should evaluate supply chain controls through an NHI lens, with token scope, secret placement, and revocation speed treated as core risk indicators.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks.
• For the control perspective, see Guide to the Secret Sprawl Challenge for how secret residency, exposure, and revocation fit together.

What this signals

Identity blast radius is the governance metric that matters here. When package malware can reach registry tokens, cloud credentials, and SSH keys in one execution path, the relevant question becomes how far a single secret can travel before it is revoked. Teams should measure credential scope, residency, and revocation speed together, not as separate hygiene tasks.

The broader programme implication is that NHI controls now need to live inside developer workflows, not around them. If credentials are available during install, test, or publish steps, then the build system itself becomes an NHI control plane. That is why IAM, PAM, and secret management teams need shared ownership of runner hardening, scoped tokens, and incident-driven rotation policies.

For practitioners

• Inventory secrets in package and build paths Map where API keys, cloud credentials, SSH keys, registry tokens, and environment variables are reachable during package install and CI/CD execution. Remove secrets from contexts that do not require them, and use short-lived credentials where possible. This reduces the chance that malicious postinstall logic can harvest usable access material.
• Restrict registry token privilege Treat npm and PyPI publish tokens as privileged secrets. Scope them narrowly, rotate them frequently, and segment publishing rights by package or team so one compromised token cannot spread malware across ecosystems. Pair this with approval gates for publishing and anomaly detection on version bumps.
• Automate revocation after exposure detection Connect secret scanning to revocation workflows so a newly exposed credential is disabled quickly rather than merely logged. Validate that cloud keys, SSH keys, and registry credentials are actually rotated and removed from downstream systems. Detection without revocation leaves the attacker with a usable window.
• Harden CI/CD runners and developer endpoints Limit persistent secrets on runners, isolate build jobs, and ensure endpoint controls cover the machines developers use to install packages and publish artifacts. The attacker target is often the environment around the package, not the package alone, so hardening that environment matters as much as scanning dependencies.

Key takeaways

• Supply chain malware is increasingly optimized to steal NHI secrets, not simply to break builds.
• A single exposed token can turn package installation into ecosystem-wide credential abuse.
• Teams need secret minimization, scoped credentials, and automated revocation to reduce blast radius.

Key terms

• Secret Sprawl: Secret sprawl is the uncontrolled distribution of credentials across repositories, CI systems, developer endpoints, logs, and collaboration tools. It matters because each additional location increases the chance of exposure, reuse, and delayed revocation. In NHI governance, sprawl is a lifecycle problem, not just a hygiene problem.
• Identity Blast Radius: Identity blast radius is the amount of damage an attacker can do after compromising one credential or non-human identity. It reflects scope, privilege, and how broadly a secret can be reused across systems. Smaller blast radius means tighter scoping, better segmentation, and faster revocation.
• Install-Time Execution: Install-time execution is code that runs automatically when a package is installed rather than when a user explicitly launches it. In supply chain attacks, that execution point is attractive because it runs inside trusted developer or CI environments where credentials may already be present.
• Credential Harvesting: Credential harvesting is the collection of usable secrets from a compromised environment, including API keys, cloud tokens, SSH keys, and registry credentials. It is the practical bridge between malicious code execution and account or infrastructure access, which is why secret placement matters so much.

What's in the full analysis

GitGuardian's full blog post covers the operational detail this post intentionally leaves for the source:

• The campaign-by-campaign breakdown of how the malicious packages behaved across npm, PyPI, and Docker Hub.
• The specific credential types harvested from developer machines, environment variables, and CI/CD pipelines.
• The technical indicators used to link the campaigns, including install-time hooks, propagation logic, and exfiltration patterns.
• The article's quantitative analysis of TeamPCP activity and the spread of the compromises across public targets.

👉 GitGuardian's full post covers the attack chains, credential targets, and ecosystem spread in detail.

Deepen your knowledge

Secrets sprawl and lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to reduce credential exposure across developer and CI/CD environments, it is a practical place to start.