npm supply-chain attacks expose why runtime secret injection matters

At a glance

What this is: This is an analysis of how malicious npm packages use install-time execution to harvest runtime credentials and expand a compromise into cloud access.

Why it matters: It matters because IAM, NHI, and platform teams must assume dependency compromise can expose standing secrets unless runtime credential delivery is tightly constrained.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.

👉 Read Riptides' analysis of npm supply-chain attacks and runtime secret injection

Context

npm supply-chain compromise is a software dependency attack in which trusted packages execute hostile code during install or build time. The governance problem is not just package provenance, but the fact that persistent secrets in CI, containers, and developer tooling can be harvested the moment untrusted code runs.

For IAM and NHI programmes, this is a workload identity problem as much as an application-security problem. Once secrets are available to any process in the execution path, a poisoned package can turn dependency trust into credential theft, cloud access, and later-stage persistence.

The article's core point is that static scanning can reduce known-package risk, but it does not remove the payoff from runtime secret exposure. That starting position is typical in modern engineering environments, where speed has been prioritised over credential containment.

Key questions

Q: How should security teams prevent a malicious npm package from stealing cloud credentials?

A: Security teams should assume install-time code can read whatever the environment exposes and remove persistent secrets from build and runtime contexts. The safest pattern is ephemeral credential delivery bound to workload identity, combined with least privilege in CI and container execution. If third-party code can run, it should not be able to discover reusable secrets.

Q: Why do supply-chain attacks become cloud breaches so quickly?

A: They become cloud breaches quickly because the initial compromise is often only the opening move. Once hostile code reaches environment variables, tokens, or kubeconfigs, it can reuse existing non-human identities to publish images, change workflows, or access infrastructure. The breach scales with the number of standing credentials still available at runtime.

Q: What breaks when secrets are stored in pods or build environments?

A: What breaks is the assumption that only trusted application code can see those secrets. Any code that executes in the same context, including a poisoned dependency, can scan and exfiltrate them. That creates a shared blast radius between the application and the attacker, which is why persistent secrets in execution contexts are so dangerous.

Q: Who is accountable when a compromised dependency exposes production secrets?

A: Accountability is shared across application, platform, and identity teams because the failure spans dependency control, secret exposure, and workload access governance. Security frameworks expect organisations to reduce attack surface, but the practical answer is to remove reusable secrets from places untrusted code can reach and to log every runtime credential handoff.

Technical breakdown

How malicious npm packages abuse install-time execution

npm packages can run lifecycle scripts such as preinstall and postinstall automatically during dependency installation. That matters because the malicious payload executes in the same CI or developer context as legitimate build tooling, inheriting the environment's available secrets and network reach. The attack does not need a browser exploit or a user click. It only needs a trusted dependency path and a place where credentials are still present in readable form. Obfuscation keeps the payload small and noisy checks are rare, so the code blends into normal build activity while it searches for useful tokens.

Practical implication: treat install-time execution as an identity boundary and block secrets from being readable in build contexts.

Runtime secret harvesting from CI, pods, and developer environments

Once code execution is achieved, attackers look for high-value NHI material: environment variables, .npmrc tokens, kubeconfigs, cached SDK credentials, and service account secrets. These are not just files, they are standing credentials that often outlive the process that uses them. In containerised and CI environments, that creates a broad blast radius because the same secret can be reused to publish images, modify workflows, or access cloud services. The article shows why the real payload is often the credential set, not the package itself.

Practical implication: remove persistent secrets from environments that can execute third-party code.

Why just-in-time secret injection changes the attack payoff

Just-in-time secret injection changes delivery from persistent exposure to ephemeral access. Credentials are provided only to the process that needs them, when it needs them, and can be tied to workload identity such as SPIFFE. That means a scraper running in the same pod does not automatically inherit the secret, even if the application itself is allowed to use it. The important architectural shift is that credential value becomes process-scoped and revocable, which sharply reduces the usefulness of a successful dependency compromise.

Practical implication: bind secrets to workload identity and make runtime delivery the default for high-value credentials.

Threat narrative

Attacker objective: The attacker wants durable cloud access by turning a routine dependency install into credential theft, persistence, and downstream data exfiltration.

1. Entry occurs when a malicious npm dependency or compromised maintainer account inserts code into the install or build lifecycle.
2. Credential harvesting follows when the payload scans environment variables, .npmrc tokens, kubeconfigs, and cached SDK credentials exposed to the process.
3. Impact occurs when stolen secrets are used to publish backdoored images, modify workflows, access cloud services, and move laterally through the environment.

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

Persistent runtime secrets are the real supply-chain failure, not package compromise alone. A poisoned npm package only becomes strategically valuable when it can reach environment variables, kubeconfigs, SDK tokens, or other standing credentials. That is a lifecycle and workload identity problem, not just a dependency hygiene problem. The implication is that supply-chain defence must be judged by what secrets remain reachable when untrusted code runs.

Runtime secret exposure creates an identity blast radius that static scanning cannot see. Dependency scanners can flag known bad packages, but they do not change the fact that a live process can read whatever secrets the platform exposes. That means the breach boundary is defined by runtime credential availability, not by package reputation. Practitioners should treat the gap between install-time trust and runtime privilege as the core control plane failure.

Ephemeral credential trust debt: modern pipelines accumulate risk when credentials stay valid and readable longer than the workload needs them. That debt is paid by the first hostile package, which can convert short code execution into long-lived cloud access. The implication is that identity programmes need to measure how much privilege is still discoverable at runtime, not just how often secrets are rotated.

Just-in-time injection reframes NHI governance from storage to delivery. Once credentials are delivered only to a verified workload identity at request time, the governance question changes from where the secret is stored to who can receive it in the moment. That does not eliminate compromise, but it sharply limits what a compromised dependency can steal. Practitioners should view this as a control on secret reachability, not as a replacement for source vetting.

Supply-chain attack patterns now sit squarely inside NHI governance. The article illustrates that package compromise, CI abuse, and cloud credential theft are one identity chain, not separate problems. OWASP-NHI and zero trust controls become relevant because the attacker is exploiting non-human access pathways end to end. Teams that still separate application security from identity governance will keep missing the operational handoff where secrets become usable.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• Our research also finds that the average estimated time to remediate a leaked secret is 27 days, which is far longer than the attacker dwell time associated with exposed credentials.
• For the broader identity control picture, Ultimate Guide to NHIs explains how lifecycle, rotation, and offboarding reduce the reach of exposed machine credentials.

What this signals

Ephemeral credential trust debt: teams should now measure how many secrets remain readable inside build and runtime paths after a package executes, not just how many secrets have been rotated. When the attack surface includes CI runners, pods, and developer workstations, the governance question becomes secret reachability at runtime. See also OWASP Non-Human Identity Top 10 for the control themes that matter most.

The practical shift is toward runtime containment, not better package optimism. With 75% of organisations expressing strong confidence in their secrets management capabilities while the average time to remediate a leaked secret is 27 days, the control gap is clearly operational rather than conceptual.

If you are maturing policy for workload identity, the next step is to align secret delivery with 52 NHI Breaches Analysis and the zero trust expectation that access should be continuously constrained rather than persistently available.

For practitioners

• Remove persistent secrets from build and runtime environments Stop placing long-lived API keys, cloud tokens, and database credentials in environment variables or pod files where third-party code can read them during install or execution.
• Bind credential delivery to workload identity Deliver high-value secrets only to a verified process or workload identity, and use ephemeral delivery so a scanner in the same pod cannot inherit the secret.
• Harden CI and publish paths Reduce runner privilege, restrict package publishing permissions, and monitor workflow changes so a compromised dependency cannot immediately pivot into registry or pipeline persistence.
• Treat runtime exfiltration as a detection priority Alert on outbound connections from build containers, unexpected telemetry domains, and secret-reading behaviour in places where code should only compile or install.

Key takeaways

• npm supply-chain attacks become serious when hostile code can read standing secrets, because credential exposure is what turns a package compromise into cloud access.
• The evidence in this pattern is clear: scanners can miss runtime behaviour, while attackers only need a short window to harvest reusable tokens and pivot into infrastructure.
• The control that changes the outcome is ephemeral, workload-bound secret delivery, because it removes the reusable payoff from compromised dependencies.

Key terms

• Just-in-time secret injection: A credential delivery pattern where secrets are supplied only when a verified workload needs them, instead of being stored persistently in files or environment variables. This reduces the value of runtime compromise because stolen code cannot automatically read reusable credentials.
• Standing credential: A reusable secret that remains available beyond the immediate action it supports, such as an API key, token, or service account secret stored in a pod or build environment. Standing credentials increase blast radius because any process with local read access can use them.
• Workload identity: The identity assigned to a process, service, or container so that access decisions can be tied to what is actually running rather than to a shared host or static secret. In practice, it is the control point used to scope secret delivery and limit credential reuse.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Riptides: Growing Threat of npm Supply Chain Attacks and the Runtime Fix That Stops It. Read the original.