Topic starter
02/06/2026 12:58 pm
TL;DR: Malicious npm packages used in SAP CAP and MTA build workflows executed during dependency installation, targeting developer machines, CI/CD runners, build containers, and repositories for secrets, tokens, and cloud credentials, according to Pathlock and SAP Security Note 3747787. The incident shows that SAP security now has to cover the software supply chain that builds and deploys extensions, not just the application stack.
Editorial analysis by NHI Mgmt Group, based on content published by Pathlock: “SAP npm Supply Chain Incident | CAP & MTA Build Workflows Impacted”.
Key questions
Q: What breaks when a malicious npm package runs inside SAP build workflows?
A: The assumption that dependency installation is a safe, pre-runtime activity breaks immediately.
Q: Why do CI/CD runners and developer machines make supply chain attacks more damaging?
A: They often hold cloud credentials, repository tokens, deployment keys, and other high-value identities in one place.
Q: What signs suggest a package-based supply chain compromise has spread beyond source code?
A: Look for unexpected workflow changes, new repositories, unusual package publishes, injected IDE or automation files, and token activity that does not match approved developer behaviour.
Practitioner guidance
- Identify every affected install path Search source repositories, lockfiles, package caches, artifact repositories, container layers, and CI/CD logs for the compromised package versions and related install jobs.
- Quarantine build hosts with exposure Isolate developer machines and CI/CD runners that installed the affected versions, and re-image systems where compromise is confirmed or cannot be ruled out.
- Rotate credentials in the build blast radius Revoke and recreate GitHub tokens, npm tokens, cloud credentials, Kubernetes config, SSH keys, SAP BTP service keys, and any deployment secrets present on affected hosts.
Bottom line: This incident shows that malicious npm packages can turn SAP build workflows into credential collection points, not just code delivery paths.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/06/2026 1:00 pm
Build identity has become part of the SAP security boundary: The compromise worked because dependency installation is now a privileged identity event, not a neutral software step. CAP and MTA workflows can execute code with access to deployment tokens, cloud credentials, and repository secrets before any runtime control exists. The practical implication is that SAP security programmes must treat build runners, caches, and package managers as governed identity surfaces, not just engineering infrastructure.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should teams reduce build-system identity risk without slowing delivery?
A: Start with exact version pinning, least-privilege publishing rights, isolated ephemeral runners, and short-lived credentials on build hosts. Then add provenance checks and tighter review of dependency updates so installation-time execution has fewer opportunities to reach sensitive identities.
👉 Read our full editorial: SAP npm supply chain compromise exposes dev and CI/CD credentials