SAP npm supply chain compromise exposes dev and CI/CD credentials

At a glance

What this is: A malicious npm supply chain compromise in SAP development tooling turned routine installs into a credential-theft path across build and deployment environments.

Why it matters: IAM and NHI teams need to treat build runners, package caches, and service tokens as part of the SAP security boundary, not as separate DevOps concerns.

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.

👉 Read Pathlock's analysis of the SAP npm supply chain incident

Context

A software supply chain compromise is different from a classic application vulnerability because the malicious code executes during dependency installation, before the application itself is used. In SAP development, that matters because CAP, MTA builds, CI/CD runners, and package caches often hold the very credentials that control deployment and service binding. For NHI governance, the issue is not just code integrity. It is whether ephemeral build activity can reach durable credentials with business impact.

The source article describes a pattern that is now familiar across modern development environments: trusted packages become the delivery vehicle, and the real target is identity material. That makes this relevant well beyond SAP customers. Any organisation using automated builds, shared runners, or long-lived tokens should assume the same trust gap exists until proven otherwise. This is a typical exposure pattern for cloud-native delivery, not an edge case.

Key questions

Q: How should security teams contain a supply chain incident in build environments?

A: Containment starts with identifying every runner, workstation, cache, and container image that resolved the affected package versions. Quarantine or re-image systems where compromise is confirmed or cannot be ruled out, then revoke credentials that were reachable from those hosts. Package removal alone is not enough because the real risk is credential reuse and hidden persistence in automation artifacts.

Q: Why do build pipelines create such a large NHI risk?

A: Build pipelines often hold service accounts, deployment tokens, registry credentials, and cloud keys that allow software to move from code to production. When a malicious package executes during install, it can collect those secrets without touching the application itself. That makes the pipeline a privileged identity zone, not a low-risk support function.

Q: What breaks when secrets are stored on CI runners and developer machines?

A: Secrets on shared or long-lived runners break the assumption that installation is a harmless administrative step. A malicious dependency can harvest environment variables, config files, and local tokens, then use them to alter repositories or publish new packages. The failure is both technical and governance-related because one compromise can spread across several trust domains.

Q: What should teams do in the first 24 to 72 hours after suspected package compromise?

A: Teams should isolate affected hosts, preserve forensic evidence, rotate exposed credentials, and inspect repositories for unauthorized workflow or package changes. They should also review internal mirrors and caches, because malicious versions may persist there after public removal. The goal is to stop reuse of stolen identities before the attacker expands access.

Technical breakdown

How npm install-time execution turns dependencies into an entry point

npm packages can execute code during install through lifecycle scripts such as preinstall, which means the payload runs before the application is ever launched. In this incident, the malicious package introduced setup logic that bootstrapped a second stage and executed during dependency resolution. That shifts the attack surface from runtime to supply chain. Security tools that only watch the application process miss the initial execution path, especially when the payload uses a separate runtime or looks like routine setup activity. The practical risk is that install-time code can reach secrets stored on a developer workstation or CI runner without any obvious user action.

Practical implication: Treat dependency installation as code execution and inspect package lifecycle behavior in build and developer environments.

Why build runners and package caches expand the NHI blast radius

Build systems often hold more than source code. They carry cloud tokens, package registry credentials, service bindings, and repository write access that make automation possible. When malicious code runs in that environment, it can enumerate files, environment variables, and configuration artifacts that represent non-human identities. Package caches, container layers, and internal mirrors also extend exposure because they preserve tainted artifacts after the public registry changes. That means a single install can affect multiple downstream systems, even if the original package is later removed. The architecture problem is not only theft, but persistence of trust across pipeline stages.

Practical implication: Inventory where build-time secrets live and assume that any runner or cache touched during exposure may need credential rotation.

How the malware attempts propagation after secret theft

The article describes a second-stage pattern that uses stolen tokens to modify repositories, inject workflow or IDE files, and publish additional malicious packages. That is a common escalation path in supply chain compromise: initial access yields authentication material, and that material is then used to widen access and create persistence. By targeting GitHub and npm tokens, the malware moves from credential collection to environment control. In NHI terms, the attacker is not just stealing secrets. The attacker is attempting to turn those secrets into repeatable access paths across development systems, repositories, and package publishing workflows.

Practical implication: Block token reuse by scoping publish rights tightly and monitoring for unauthorized repository or workflow changes.

Threat narrative

Attacker objective: The attacker aims to harvest developer and deployment credentials, then reuse them to expand control across source control, package publishing, and SAP deployment paths.

1. Entry occurs when a malicious npm package version is resolved during a normal install or CI dependency update.
2. Escalation happens as install-time code launches a secondary payload that searches the host for credentials, secrets, and configuration files.
3. Impact follows when stolen tokens are used to create repositories, alter workflows, and publish further malicious packages.

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

Supply chain compromise has become an NHI governance problem, not just a DevSecOps problem. The article shows that build-time secrets, package registries, and deployment tokens now sit inside the security boundary for SAP landscapes. That means governance teams must treat automation identities as production-adjacent, with the same review discipline applied to privileged human access. The practitioner conclusion is simple: if a build runner can deploy, it can also be compromised.

Install-time execution creates an ephemeral credential trust debt. The control gap is not limited to whether a secret exists, but whether a trusted package can reach that secret before any runtime guardrail sees it. This is the kind of failure OWASP NHI guidance is trying to surface: identity material is exposed through legitimate automation paths, not only through obvious theft. The practitioner conclusion is to reduce trust in package installation and minimize what any single runner can see.

Build infrastructure now needs identity blast-radius mapping. Once a CI runner or developer workstation is touched, the question is no longer just whether code was altered. The real question is which tokens, service keys, and cloud bindings were reachable from that host. That changes incident handling from package removal to credential-scoped containment. The practitioner conclusion is to map every runner to the identities it can reach.

The market signal is that software supply chain telemetry and NHI controls are converging. Teams can no longer keep package security, secrets management, and repository governance in separate programmes because the attacker uses all three together. This increases the value of controls that tie runtime identity, build provenance, and secret exposure into one view. The practitioner conclusion is to align NHI governance with pipeline telemetry, not just with account administration.

SAP customers should expect more attacks against extension layers than core ERP targets. The development and automation paths often contain broader credentials than the productive application layer, so they are attractive entry points. That does not reduce the importance of SAP hardening. It means hardening must extend outward to the tools that build and deploy SAP-connected services. The practitioner conclusion is to widen the scope of SAP security reviews now.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, which helps explain why pipeline exposure keeps recurring even in mature programmes.
• The control lesson is not just to detect exposure faster, but to pair detection with revocation and lifecycle governance, as discussed in The State of Secrets Sprawl 2026.

What this signals

Identity blast radius is now the right lens for supply chain incidents. A single compromised build host can expose several identity classes at once, from GitHub tokens to SAP BTP service keys, so teams should map which automation identities can reach production-adjacent systems. With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, the broader pattern is clear: machine-readable trust material is proliferating faster than most governance programmes can track it.

Security teams should expect tighter convergence between software supply chain monitoring and NHI controls over the next planning cycle. The operational priority is to know which runners, registries, and package mirrors can still be trusted after an exposure event, then prove that token rotation and repository review actually closed the path. That is where governance moves from policy to evidence.

For practitioners

• Map all affected build and developer hosts Identify every workstation, CI runner, container image, and cache that installed the malicious package versions or resolved them through lockfiles, mirrors, or dependency updates.
• Rotate credentials reachable from the blast radius Revoke and recreate GitHub tokens, npm tokens, cloud keys, SAP BTP service keys, Kubernetes credentials, and any deployment secrets present on exposed hosts.
• Review repository and workflow tampering Search for unauthorized repositories, branch pushes, workflow edits, .vscode tasks, and .claude files that may indicate persistence or propagation attempts.
• Harden dependency installation paths Pin high-risk build dependencies, isolate runners, remove reusable workspace state, and limit package publishing rights to short-lived, least-privilege credentials.
• Add continuous exposure checks to SAP delivery Correlate SAP BTP, source control, and CI telemetry so that credential use after package exposure is visible before it becomes a production incident.

Key takeaways

• Malicious npm packages in SAP build workflows turn routine dependency installation into a credential-theft path across developer and CI environments.
• The exposure is not limited to source code, because build runners and caches often hold the tokens that can reach deployment, cloud, and SAP service identities.
• Practitioners should treat package compromise as an identity incident, with host isolation, credential rotation, and repository review as first-order actions.

Key terms

• Software Supply Chain Compromise: A software supply chain compromise is an attack that inserts malicious code into trusted build, package, or deployment paths. The goal is often not immediate application failure, but secret theft, persistence, or unauthorized changes that travel downstream through automated systems.
• Build Runner: A build runner is the machine or container that executes automated development tasks such as installs, tests, packaging, and deployment. Because it often has access to tokens and service credentials, it should be treated as a privileged NHI environment rather than disposable infrastructure.
• Identity Blast Radius: Identity blast radius is the amount of systems, data, and automation an exposed credential can reach before it is revoked. In modern pipelines, one compromised token may affect source control, package publishing, cloud services, and deployment workflows at the same time.
• Install-time Execution: Install-time execution is when package code runs during dependency installation instead of during normal application use. This matters because it gives malicious packages an early chance to read local secrets, modify files, or establish persistence before many controls begin monitoring.

Deepen your knowledge

SAP build pipeline exposure and NHI blast radius are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are securing SAP CAP, MTA, or CI/CD environments with the same identity patterns, it is worth exploring.

This post draws on content published by Pathlock: SAP npm supply chain incident affecting CAP and MTA build workflows. Read the original.