TL;DR: npm supply-chain attacks exploit install-time trust to steal credentials from CI, developer, and Kubernetes environments, with malicious packages scanning for secrets in env vars, .npmrc files, kubeconfigs, and cached SDK tokens before exfiltrating them, according to Riptides. Persistent secrets, not the poisoned package itself, are what turn a supply-chain compromise into a full cloud breach.
At a glance
What this is: This is an analysis of npm supply-chain compromise patterns and the case for runtime secret injection as the control that deprives malicious packages of usable credentials.
Why it matters: IAM, PAM, and NHI teams need to treat runtime credential exposure as the decisive risk, because package scanning alone cannot stop secrets already present in build and runtime environments.
Context
npm supply-chain compromise is an identity and credential problem as much as a software distribution problem. A poisoned dependency becomes dangerous when it can run in the same context as CI jobs, developer shells, and Kubernetes workloads that already hold secrets.
The governance gap is persistent secret availability at runtime. If API keys, tokens, and kubeconfigs are present as files or environment variables, an attacker does not need to defeat the application, only the credential exposure model supporting it.
This pattern is not unique to npm. The article treats npm as the clearest example of a broader dependency-chain risk that affects modern engineering pipelines wherever install-time execution can inherit access.
Key questions
Q: How should security teams handle npm packages that run code during install?
A: Security teams should treat install-time scripts as executable code and restrict them by policy. That means allowlisting trusted packages, blocking unnecessary lifecycle hooks, and testing dependency changes in isolated environments before they reach CI. The main goal is to prevent package installation from becoming a hidden execution path for secret theft.
Q: Why do persistent secrets make a poisoned package far more dangerous than the package itself?
A: Because the package is usually just the entry point. The real damage comes when it can read cloud tokens, registry credentials, or database keys that already exist inside the runtime context. Persistent secrets turn one execution into reusable access, which lets an attacker move from install-time compromise to broader cloud abuse.
Q: What are the signs that runtime secret controls are failing in CI and Kubernetes?
A: Look for secrets stored in environment variables, .npmrc files, kubeconfigs, cached SDK credentials, or pods that keep working only because long-lived credentials were injected at deploy time. If a malicious dependency can steal useful values from a running workload, your runtime secret model is exposing more than it should.
Q: Should teams prioritize just-in-time secret injection over more dependency scanning?
A: They should treat them as different layers, not substitutes. Dependency scanning reduces the chance of a bad package entering the pipeline, but just-in-time injection reduces what that package can steal after execution. If you must choose which control changes the breach outcome, runtime secret injection usually matters more.
Technical breakdown
Install-time execution turns package trust into credential access
npm lifecycle scripts such as preinstall and postinstall execute automatically during install or build time. That means a malicious package does not need user interaction once it lands in the dependency tree. It runs with the privileges of the CI agent or developer environment, which often includes access to environment variables, registry tokens, or cloud SDK credentials. The important technical distinction is that the package is only the delivery vehicle. The exploit succeeds because install-time code can inspect the process environment before any runtime controls have removed persistent secrets from reach.
Practical implication: assume every install-time hook is a credential-access opportunity unless the environment contains no reusable secrets.
Why scanners miss secret exfiltration in build pipelines
Static analysis is strong at identifying known bad packages, vulnerable versions, and typosquats, but it does not observe runtime behavior. A package can look harmless in metadata and still unwrap obfuscated code only when executed in CI or a container build. Once that code runs, the scanner is already out of the loop. The failure mode is not a missed signature alone. It is the mismatch between a package-centric control and a behavior-centric attack that only becomes visible after secrets have already been read and sent out.
Practical implication: pair dependency scanning with runtime controls that remove secrets before a package can execute.
Just-in-time secret injection breaks the payoff chain
Just-in-time secret injection changes the credential model from persistent exposure to process-scoped delivery. Instead of placing keys in environment variables, image layers, or pod files, the secret is supplied only to the process that needs it and only at the moment of use. The article’s example also ties this to workload identity, which matters because the secret becomes bound to a verified runtime context rather than to the host or container. That reduces what a scraper can collect and shrinks the blast radius of a compromised build or pod.
Practical implication: deliver high-value credentials only at use time and bind them to workload identity, not to the container image.
Threat narrative
Attacker objective: The attacker wants reusable credentials that turn a single malicious package execution into durable access across CI, registry, and production environments.
- Entry occurs when a malicious npm package or compromised maintainer account is introduced into the dependency chain and executes during install or build time.
- Credential harvest follows when the payload scans environment variables, .npmrc files, kubeconfigs, and cached SDK credentials, then exfiltrates what it finds.
- Escalation and persistence come next as the attacker uses stolen tokens to publish backdoored images or add workflows that survive the original compromise.
- Impact is a broader cloud breach, with the attacker able to move into production workloads, access internal APIs, and exfiltrate data.
Breaches seen in the wild
- Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.
- SpotBugs token leak 2025: A SpotBugs maintainer's PAT, stolen via a pull_request_target workflow in 2024, started the reviewdog and tj-actions supply chain attack.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Runtime secret exposure, not package compromise, is the real breach amplifier: A poisoned dependency only becomes material when it can reach durable credentials inside CI, developer, or Kubernetes environments. That is the control boundary modern teams keep underestimating. The practical conclusion is that supply-chain security and identity governance now meet at the moment secrets are present in runtime.
Persistent credential storage is an avoidable assumption failure: The article shows that install-time scrapers succeed because many environments still expose secrets in variables, files, or cached SDK state. That setup was designed for a world where code execution was trusted inside the build or pod. The implication is that runtime secrecy, not just package hygiene, has become a governance requirement for NHI and workload identity.
Just-in-time secret injection creates identity blast-radius control: When credentials are issued only to the process that needs them, the attacker’s access path narrows from environment scraping to live authorization. That is a different control philosophy from rotation alone because it eliminates the standing target. Practitioners should treat this as a structural reduction in identity blast radius.
Dependency scanning is necessary but insufficient for machine identity governance: Scanners can flag known package risk, yet they do not govern what happens when a package executes with inherited access. The stronger position is that governance must cover issuance, runtime exposure, and revocation together. Teams should evaluate whether their current controls actually prevent secrets from existing at the point of compromise.
Ephemeral credential trust debt: The article makes clear that every persistent secret sitting in a build or runtime environment is deferred risk waiting for an attacker to realise it. That debt is paid down only when credentials are removed from static reach and delivered just in time. Practitioners should measure success by how little a hostile package can harvest, not by how many packages get scanned.
From our research library:
- Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
- Read next: NHI Lifecycle Management Guide
What this signals
Persistent secret exposure is now the main dependency-chain liability: npm compromise matters because build and runtime environments still hand out credentials that a malicious package can harvest instantly. If a package can read secrets, then package trust has already become identity trust, and that is the control boundary to fix.
Identity blast radius is the right metric for this threat class: The goal is not to stop every package from executing, because modern engineering will not eliminate install-time code paths. The goal is to make the secrets available to that code too small, too short-lived, and too tightly bound to a verified workload to matter.
Runtime secret injection changes the economics of compromise: When secrets are delivered only at use time, a poisoned package may still execute but it cannot easily harvest durable access. That shifts the problem from incident recovery to loss prevention, which is where NHI and workload identity governance should be focusing.
For practitioners
- Remove persistent secrets from build and pod environments Stop placing API keys, registry tokens, and database credentials in environment variables, image layers, or mounted files where install-time payloads can scrape them.
- Bind high-value credentials to workload identity Deliver secrets only to the specific process that needs them so a compromised sidecar, reverse shell, or hostile dependency does not inherit the same access.
- Treat dependency scanning as a front-end control, not the control plane Keep SCA and package vetting in place, but assume they cannot stop runtime exfiltration after code execution begins.
- Instrument credential injection and revocation events Log each injection, policy change, and revocation so responders can prove whether a workload still had access after a suspicious package execution.
- Limit CI runner privileges and publish tokens Reduce the reach of build systems so a compromised dependency cannot immediately pivot into registry publishing or workflow persistence.
Key takeaways
- npm supply-chain attacks become severe when they can reach long-lived credentials in CI, developer, or Kubernetes environments.
- The breach pattern is not only malicious code execution, but secret discovery, credential reuse, and lateral movement through trusted pipelines.
- Just-in-time secret injection changes the attack outcome by removing durable secrets from the places malicious packages can scrape.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centers on malicious packages scraping exposed secrets from runtime environments. |
| NHI-07 — Long-Lived Secrets | Persistent credentials are the core condition that turns a package compromise into a breach. | |
| NHI-05 — Overprivileged NHI | The attack becomes worse when the harvested credentials have broad cloud or registry scope. | |
| Recommendation — Remove exposed secrets from build and runtime contexts and monitor for leakage paths in CI and pods. Replace long-lived secrets with short-lived issuance and verify they are absent from image and pod storage. Constrain NHI privilege so any stolen credential cannot immediately reach registry, CI, or production paths. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authenticator lifecycle and rotation are directly implicated in exposed API keys and tokens. |
| Recommendation — Apply authenticator management to shorten credential lifetime and revoke any secret exposed to runtime scraping. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The article describes credential theft followed by movement through CI, registry, and production systems. |
| Recommendation — Map dependency compromises to credential access and lateral movement to improve detections in build pipelines. | ||
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.
- Runtime Secret Visibility: Runtime secret visibility is the ability to observe when and where secrets are accessed while systems are actively running. It matters because static inventories alone do not show whether a tool, workflow, or workload is reading credentials in memory, files, or logs.
- Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
Deepen your knowledge
NHI governance, identity lifecycle, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org