These questions started showing up in security Slack channels right after StepSecurity flagged two hijacked npm packages in the React Native ecosystem. These packages, with over 30,000 downloads per week, were modified to deliver multi-stage malware using Solana blockchain as a command channel. Your team probably has questions. Here are the answers we're giving ours.
Understanding the Threat
A maintainer account gets compromised. Malicious code gets pushed. Your CI/CD pipeline pulls it automatically. By the time you notice, the malware has already established persistence using a blockchain-based C2 channel that's nearly impossible to block. This isn't theoretical—it's what happened with the Glassworm campaign targeting React Native developers.
The questions below reflect what security teams are actually asking when they realize their dependency update process might have introduced a threat actor into their environment.
Q1: "Our dependency bot just updated to a compromised version. What do we check first?"
Start with process inspection, not file scanning. The malware from these packages executed during installation—before your runtime security tools would even see it.
Check your CI/CD logs for:
- npm install timestamps matching the compromised package versions
- Post-install script execution (look for lifecycle hooks:
preinstall,postinstall) - Outbound network connections during build, especially to unfamiliar domains or blockchain endpoints
Then check running systems for persistence mechanisms. This campaign established scheduled tasks and modified shell profiles. Look for:
- Cron jobs or systemd timers created in the last 30 days
- Changes to
.bashrc,.zshrc, or equivalent shell configs - New processes connecting to Solana RPC endpoints (typically port 8899)
Don't rely on antivirus signatures. By the time signatures exist, you're dealing with containment, not detection.
Q2: "Why would attackers use blockchain for C2?"
It's about resilience. Traditional C2 infrastructure has single points of failure: domains get seized, IPs get blocked, DNS gets sinkholed. Blockchain-based C2 eliminates those chokepoints.
When malware uses Solana for command channels, it's reading instructions from transaction memos or smart contract state. You can't block "the Solana blockchain" without breaking legitimate services. You can't seize the domain. You can't get a court order to take down the infrastructure.
This forces you to detect the malware behavior itself, not the infrastructure it connects to. Your network rules need to evolve from "block this domain" to "alert on any process writing to blockchain endpoints during package installation."
For compliance: This matters for PCI DSS v4.0.1 Requirement 6.4.3, which requires you to review custom scripts before deployment. If your package manager is executing arbitrary code from the internet during installation, those are scripts. You need visibility into what they're doing.
Q3: "How do we prevent our package manager from running malicious install scripts?"
You have three levers, and you need all of them:
Disable automatic script execution in CI/CD:
npm install --ignore-scripts
This breaks some legitimate packages that need compilation, so you'll need an allowlist. Maintain it explicitly. When a package needs scripts enabled, that's your trigger to review what those scripts actually do.
Implement package integrity verification:
Use Sigstore for npm packages that support it. For everything else, pin exact versions with lock files and verify checksums. Your package-lock.json isn't just for reproducible builds—it's your integrity manifest.
Require security review for new dependencies:
Not every dependency. That's not realistic. But any package with:
- Post-install scripts
- Native compilation requirements
- Network access during installation
- Fewer than 1,000 weekly downloads
These are the risk vectors. Route them through a human review before they hit production dependencies.
Q4: "We have 847 dependencies. How do we know which ones to worry about?"
Stop trying to review all 847. Focus on the supply chain chokepoints—packages where compromise creates maximum impact.
Build a dependency graph and identify:
- Direct dependencies with install scripts: You explicitly chose these, and they run code during installation
- Transitive dependencies with >100 dependents in your tree: If compromised, they affect multiple parts of your application
- Packages with maintainer changes in the last 90 days: Account compromise is the attack vector here
Tools like npm ls show you the tree. Combine that with npm audit output, but don't stop there—audit only catches known vulnerabilities, not supply chain compromises.
For the packages that matter, set up monitoring:
- GitHub watch notifications for the repositories
- RSS feeds for npm package update announcements
- Webhook alerts when new versions publish
When a critical package updates, you want to know within hours, not days.
Q5: "What should our incident response look like if we detect a compromised package?"
Assume the compromise happened during installation, not at runtime. This changes your containment strategy.
Immediate actions:
- Identify which systems ran
npm installwith the compromised version (check CI/CD logs, developer machines) - Isolate those systems from production networks
- Check for persistence mechanisms (the Glassworm campaign used scheduled tasks)
- Review outbound network logs for blockchain RPC connections
Evidence collection:
- Capture the compromised package version before it's unpublished
- Export package-lock.json from affected systems
- Collect shell history from developer machines
- Preserve CI/CD pipeline logs showing the installation
Notification requirements:
If you're SOC 2 Type II certified, this is a security incident affecting system integrity. Your response timeline matters for your next audit. Document when you detected it, when you contained it, and what controls failed.
If you process payment card data, PCI DSS v4.0.1 Requirement 12.10.1 requires you to have an incident response plan that covers supply chain compromises. Test whether your plan actually addresses scenarios where the threat is introduced during the build process, not at runtime.
Q6: "Should we stop using npm entirely? Switch to a different ecosystem?"
No. The attack vector isn't specific to npm—it's inherent to any ecosystem with automated dependency resolution and install-time code execution. PyPI has the same risks. RubyGems has the same risks. Maven has the same risks.
The question isn't which package manager to use. It's whether your security controls account for the fact that npm install is a code execution event, not just a file copy operation.
If your security model treats dependency installation as "safe" and only scrutinizes runtime behavior, you're missing the attack surface that matters.
Where to Go for More
Your package manager documentation has security flags you're probably not using. Read the npm security documentation, specifically the sections on script execution and package verification.
The NIST Cybersecurity Framework Supply Chain Risk Management category (SC.GV, SC.RA) provides a structure for thinking about these risks at the program level, not just the technical level.
And talk to your developers. They're the ones running npm install dozens of times per day. If your security controls make their job harder without making them safer, they'll route around your controls. Build detection and response capabilities that work with their workflow, not against it.
