Notifications
Clear all
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.
NHIMG editorial — based on content published by Pathlock: SAP npm supply chain incident affecting CAP and MTA build workflows
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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?
👉 Read Pathlock's analysis of the SAP npm supply chain incident →
Explore further
02/06/2026 1:00 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: SAP npm supply chain compromise exposes dev and CI/CD credentials
