Notifications
Clear all
Topic starter
02/08/2026 11:39 am
TL;DR: A 38-package NPM campaign shows how dependency confusion, postinstall execution, and rotating publisher accounts can turn ordinary npm install activity into credential theft and exfiltration across CI/CD environments, targeting Apple, Google/GCP, and Alibaba/Aliyun, according to Panther. The pattern shows why build-time trust, not just package integrity, now needs explicit identity and secrets governance.
NHIMG editorial — based on content published by Panther: Frankly Malicious, inside a 38-package NPM supply chain campaign targeting tech giants
By the numbers:
- Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe.
Questions worth separating out
Q: What breaks when dependency confusion is allowed in CI/CD pipelines?
A: Build systems can install malicious public packages instead of trusted internal dependencies, which turns normal package installation into an execution path for secret theft.
Q: Why do CI/CD runners and build tools increase NHI risk?
A: They often hold cloud tokens, publishing credentials, SSH keys, and database secrets that behave like non-human identities.
Q: How do security teams know whether package installation risk is under control?
A: Look for three signals: scripts are blocked or tightly governed during install, runner memory and local secrets are minimized, and package provenance is checked before deployment.
Practitioner guidance
- Enforce private-registry resolution for internal dependencies Require build systems to resolve internal package names only from approved private registries, and block fallback to the public registry for reserved namespaces such as *-internal-* patterns.
- Disable or tightly gate install-time scripts Restrict postinstall and similar lifecycle hooks in pipeline policy, especially for packages that do not require script execution to build.
- Classify CI/CD secrets as privileged non-human identities Inventory NPM tokens, cloud credentials, SSH keys, kubeconfigs, and database secrets as governed identities with owners, expiry, and revocation paths.
What's in the full report
Panther's full blog covers the operational detail this post intentionally leaves for the source:
- Package-by-package breakdown of the 38 malicious NPM artifacts and how each impersonation cluster was structured
- The actor-attribution evidence behind the rotating publisher accounts and recurring alias patterns
- The exfiltration targets observed in each cluster, including cloud tokens, SSH keys, database secrets, and publish credentials
- The technical indicators and package traits defenders can use to hunt similar dependency confusion activity
👉 Read Panther's analysis of the 38-package NPM supply chain campaign →
Dependency confusion in CI/CD pipelines: what IAM teams are missing?
Explore further
02/08/2026 12:52 pm
Dependency confusion is now an identity boundary failure, not just a package hygiene issue. The article shows that the exploit succeeds when build systems treat external registry resolution as trustworthy by default. Once a CI/CD runner installs the wrong package, it exposes secrets that should have been isolated as non-human identities with clear ownership, scope, and revocation. Practitioners should read this as a governance failure in the software delivery identity layer.
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, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
A question worth separating out:
Q: What should teams do after a malicious repository or package is discovered?
A: Contain the repository, revoke any credentials that could have been exposed, and rotate secrets used by the affected developer and CI paths. Then inspect adjacent repositories for reused tokens, copied package names, and shared maintainer identities. The goal is to cut off both the delivery path and any persisted non-human access.
👉 Read our full editorial: Dependency confusion in NPM supply chains is now an identity problem
