TL;DR: PhantomRaven hides malware outside the npm registry with Remote Dynamic Dependencies, bypassing many scanners while stealing developer credentials, CI/CD tokens, and system data from build environments, according to NowSecure. The real governance issue is that install-time trust, AI-assisted dependency choice, and mobile build pipelines create a larger attack surface than registry scanning alone can see.
NHIMG editorial — based on content published by NowSecure: PhantomRaven and npm supply-chain attack analysis
By the numbers:
- PhantomRaven published 200+ malicious packages and accumulated tens of thousands of downloads.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: What breaks when remote dynamic dependencies are not controlled in npm builds?
A: Build security breaks because the installer becomes the execution engine.
Q: Why do npm supply chain attacks create such a large IAM risk?
A: Because npm, GitHub, and cloud credentials often coexist in the same developer and build environments.
Q: What do security teams get wrong about dependency scanning?
A: They often assume a clean manifest means a clean environment.
Practitioner guidance
- Block install-time network fetches by default Enforce egress allowlisting on build agents so npm, node, and yarn can only reach approved registries and internal mirrors during dependency installation.
- Disable lifecycle scripts in unattended builds Set npm config ignore-scripts true in CI and create a narrow allowlist for scripts that have been reviewed and explicitly required.
- Contain developer and CI/CD credentials as NHIs Use short-lived scoped tokens, vault-backed secrets, and a rotation playbook for developer, npm, publishing, and pipeline credentials after any suspicious install activity.
What's in the full article
NowSecure's full article covers the operational detail this post intentionally leaves for the source:
- Package-by-package examples of Remote Dynamic Dependencies and how they appear in package.json files
- Stepwise detection signals for npm install behaviour, lifecycle scripts, and unexpected outbound network connections
- Mobile build hardening guidance for React Native, Ionic, and Capacitor pipelines that need release integrity
- Practical mitigation patterns for protecting signing keys, CI tokens, and app-store publishing access
👉 Read NowSecure's analysis of PhantomRaven and npm supply-chain malware →
PhantomRaven and mobile build risk: what IAM teams need to know?
Explore further
Remote dependency execution is the named governance failure here: the control plane assumes package trust can be judged from the registry artifact, but PhantomRaven moves execution outside that boundary. That makes provenance, execution, and inspection three different problems, not one. Security teams should stop treating package metadata as a complete trust signal and instead govern what the installer is allowed to fetch and run.
A question worth separating out:
Q: How should teams reduce supply-chain risk in mobile build pipelines?
A: They should treat the pipeline as a privileged identity environment. That means deterministic installs, restricted egress, disabled or allowlisted lifecycle scripts, isolated signing keys, and review gates for new or AI-suggested dependencies. Mobile release integrity depends on controlling both code provenance and the machine identities that move code into release.
👉 Read our full editorial: PhantomRaven shows how npm supply-chain attacks reach mobile builds