SAP npm supply chain attack exposes why runtime controls matter

At a glance

What this is: This article analyses the SAP npm supply chain attack and shows how malicious preinstall scripts harvested credentials, secrets, and CI/CD tokens before detection-based tools could react.

Why it matters: It matters to IAM, PAM, and NHI teams because developer tokens, service account credentials, and pipeline secrets are all high-value identities that need inline protection, not just post-execution alerting.

By the numbers:

• 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.
• 17 minutes

👉 Read AccuKnox's analysis of the SAP npm supply chain attack and runtime controls

Context

Software supply chain attacks increasingly exploit trusted installation paths rather than obvious malware delivery. In this case, the critical failure was not just package compromise, but the speed at which a malicious preinstall hook could reach developer credentials, cloud secrets, and CI/CD tokens before any reactive tooling could intervene. For NHI governance, that means build-time identities and secrets are part of the attack surface, not a separate operational concern.

The article sits at the intersection of supply chain security and identity control. npm tokens, SSH keys, cloud credentials, Kubernetes configs, and GitHub secrets are all non-human identities or closely related credentials that can be harvested, replayed, and used to expand access. That makes the boundary between application security and identity governance much thinner than many programmes assume.

Key questions

Q: What breaks when malicious npm packages execute during CI/CD installs?

A: The main failure is that package installation becomes code execution inside a trusted build context. That lets attacker-controlled scripts read memory, steal secrets, and potentially publish more malicious artifacts before defenders notice. The control that breaks is the assumption that dependency installation is operationally harmless. Treat install-time execution as a governed security boundary, not a routine developer convenience.

Q: Why do CI/CD runners create such high credential risk?

A: They often contain many reusable secrets at once, including cloud keys, package tokens, SSH material, and cluster credentials. That concentration turns a single compromise into broad access. The risk rises when those secrets are stored in files, environment variables, or memory-backed paths that any process can read.

Q: How can security teams tell whether secret management is actually working?

A: Look for fewer plaintext secrets, narrower reuse, faster rotation, and a shrinking set of credentials that remain valid across multiple systems. If the same password or API key can still unlock several services, secret management is not yet reducing blast radius in practice.

Q: Who is accountable when a supply chain package steals credentials and machine access?

A: Accountability usually sits across engineering, platform security, and identity teams because the failure spans software intake, endpoint execution, and credential governance. The right control owners are the teams that approve package trust, manage secret lifecycles, and define which identities may exist on developer workstations.

Technical breakdown

How malicious npm preinstall hooks turn installs into execution paths

npm preinstall scripts execute automatically during package installation, before many endpoint or workload controls can meaningfully inspect the resulting behaviour. A poisoned package can download a secondary runtime, launch an obfuscated payload, and use the installer’s own trust path to blend in with normal developer activity. The danger is not only code execution, but execution happening inside a workflow that administrators expect to be routine. In practice, this makes the install step itself a security boundary, especially in CI/CD runners where credentials are already present.

Practical implication: treat package installation as an execution control point and block unapproved binaries before they can run.

Why proc filesystem reads expose credentials faster than detection can react

Attackers target common credential locations such as ~/.aws/credentials, ~/.ssh, ~/.npmrc, Kubernetes service account paths, and /proc/self/environ because those sources often contain reusable secrets in plain text or memory-backed state. Once a malicious process can read those paths, the data can be encrypted and exfiltrated in a few seconds. Detection tools may still generate a signal, but they are observing a completed read rather than preventing it. This is a classic timing failure between visibility and enforcement.

Practical implication: restrict file and proc access at the syscall layer so secret reads fail before contents are exposed.

How worm-like token theft turns one compromised developer into many

When attackers steal npm tokens or GitHub credentials, they often move from theft to propagation by publishing poisoned packages or abusing repository access under the victim’s identity. That creates a loop in which the first compromise seeds the next wave of compromise. From an identity perspective, the stolen credential is not just an access key, but a delivery mechanism for trust amplification across the ecosystem. This is why package trust, token lifecycle, and publishing rights cannot be governed separately.

Practical implication: segment publishing rights, rotate tokens rapidly, and break the propagation loop with scoped, time-bound credentials.

Threat narrative

Attacker objective: The attacker wants to harvest reusable developer and CI/CD credentials fast enough to expand access, exfiltrate data, and propagate the compromise through additional package publishing.

1. Entry occurs when the victim installs a poisoned npm package that runs a malicious preinstall script inside a trusted workflow.
2. Credential harvesting follows as the payload reads cloud credentials, SSH keys, GitHub tokens, Kubernetes configs, and environment variables from local paths and /proc/self/environ.
3. Impact lands when the stolen secrets are encrypted, exfiltrated, and reused to poison additional packages under the victim’s identity.

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

Inline runtime enforcement is now the decisive control boundary for supply chain identity theft. Detection-based tooling can still be useful for investigation, but it fails as the primary containment layer when secret exfiltration completes in seconds. This article shows that the real control question is whether a malicious process can ever read credential files or proc-backed environment data at all. For NHI governance, kernel-level denial matters more than downstream alerting.

Developer credentials are NHI assets, not just user convenience tokens. npm tokens, GitHub PATs, SSH keys, cloud provider keys, and Kubernetes service account secrets all function as machine identities with reuse potential. Once stolen, they can authenticate silently across build systems and repositories. That means lifecycle control, scope minimisation, and rotation discipline must be applied to developer and pipeline identities with the same seriousness as privileged human access.

Secret sprawl in CI/CD creates a blast-radius problem, not just a visibility problem. The attack succeeds because too many credentials sit in memory, files, environment variables, and pipeline context at the same time. That is a governance assumption failure: the environment assumes secrets are safe because they are part of the build process. Practitioner conclusion: minimise where secrets live, shorten their lifetime, and prevent any one runner from exposing the full credential estate.

Default-allow execution is incompatible with modern package supply chain threats. When downloaded runtimes and postinstall payloads can execute freely, the package manager becomes an attack platform. The practical lesson is not to add more alerts, but to move to allowlisted execution and syscall-aware enforcement. For organisations operating CI/CD at scale, this is a governance change, not just a tooling update.

Credential propagation through published packages is a named failure mode: trust amplification. The first compromise is not the end state. Stolen publishing tokens let attackers convert one poisoned install into multiple compromised packages, which multiplies the blast radius across consumers. Practitioners should treat publish rights as a privileged security function and not as a routine developer entitlement.

From our research:

• 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, according to the State of Secrets Sprawl 2026.
• From our research: 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to the State of Secrets Sprawl 2026.
• Forward-looking angle: Read the Guide to the Secret Sprawl Challenge for the operational controls that reduce exposure across code, pipelines, and runtime environments.

What this signals

Secret concentration in build systems is becoming a governance liability, not just a hygiene issue. The more credentials, tokens, and keys a runner can touch, the more useful it becomes to an attacker after a single package compromise. Teams should expect pressure to separate build trust from secret trust and to document where secret access is intentionally allowed versus inherited by default.

Trust amplification is the emerging concept practitioners need to watch. When one stolen publishing token can seed additional poisoned packages, the attacker turns identity trust into propagation capacity. That changes programme priorities: scope publish rights, reduce token reuse, and link package-release governance to NHI lifecycle controls rather than treating them as separate workflows.

For practitioners

• Block unapproved execution in build environments Enforce process allowlisting so downloaded runtimes, postinstall scripts, and unexpected binaries cannot execute inside CI/CD runners or developer workstations.
• Deny direct reads of secret-bearing paths Restrict access to ~/.ssh, ~/.aws/credentials, ~/.npmrc, Kubernetes service account tokens, and /proc/self/environ at the syscall layer.
• Scope and rotate publish tokens aggressively Separate package publishing credentials from routine development access, apply narrow repository scope, and rotate tokens after any suspicious install or build event.
• Reduce secret concentration inside runners Keep CI/CD runners from holding long-lived cloud keys, GitHub secrets, and cluster credentials at the same time, especially on shared build infrastructure.
• Link package trust to identity lifecycle controls Treat package maintainers, automation tokens, and release pipelines as governed identities with offboarding, revocation, and review processes tied to every publish path.

Key takeaways

• This attack shows that package installs can become credential-extraction events when runtime controls are missing.
• The scale of the secrets problem is already large enough that post-execution detection cannot be the main defence.
• Inline denial, strict execution allowlisting, and tighter token lifecycle governance are the controls that change the outcome.

Key terms

• Preinstall Hook: A preinstall hook is package code that runs before an application installs or starts. In supply-chain attacks, it becomes a hidden execution point that can steal secrets, alter environments, or drop further payloads before normal controls see the package's behaviour.
• Proc Filesystem: The proc filesystem is a Linux virtual filesystem that exposes live process information such as open file descriptors, command lines, and environment variables. It is useful for administration but dangerous when application-level file access flaws let attackers read process details they should never see.
• Trust Amplification: A condition where a small identity or policy exception expands into a much larger attack path after compromise. In Microsoft 365, broad allow lists, unmanaged device enrollment, and default external access settings can multiply the effect of one stolen credential or one trusted sender.
• Inline Runtime Enforcement: Inline runtime enforcement blocks unsafe actions before they complete by making policy decisions at execution time. Unlike detection-only tooling, it can deny file access, process spawn, or network exfiltration in the kernel path, which matters when attacks complete in seconds.

What's in the full article

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

• Kernel-level enforcement mechanics using eBPF and Linux Security Modules in workload environments.
• How file access controls stop reads from ~/.ssh, ~/.aws/credentials, ~/.npmrc, and /proc/self/environ.
• Process whitelisting behaviour for blocking downloaded runtimes such as Bun before execution.
• CI/CD-specific deployment patterns for Kubernetes runners, VMs, and bare-metal build hosts.

👉 The full AccuKnox post covers the attack chain, kernel enforcement path, and CI/CD deployment details.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners connect identity lifecycle controls to real-world exposure in build, cloud, and automation environments.