Scope
This guide focuses on detecting and preventing adaptive malware that uses AI to modify itself within software supply chains. It includes specific controls for npm ecosystems, integrity verification, and governance frameworks that align with PCI DSS v4.0.1 Requirement 6.3.2 (inventory of bespoke and custom software) and NIST CSF v2.0 ID.SC-4 (supply chain risk assessment).
If your organization interacts with public registries, this guide is essential for you.
Key Concepts and Definitions
Adaptive supply chain malware: Malware that alters its behavior or payload based on the environment, often using AI models to evade detection.
Typosquatting: The practice of publishing malicious packages with names similar to legitimate ones (e.g., reacct instead of react). SANDWORM_MODE was distributed through typosquatted npm packages, tracked as sonatype-2026-000542.
Integrity verification: The cryptographic validation that a software component is unaltered. This method detects unauthorized changes, unlike vulnerability scanning, which checks against known CVE databases.
Continuous governance: Automated policy enforcement throughout the software lifecycle, beyond initial deployment or periodic audits.
Requirements Breakdown
ISO/IEC 27001:2022 Controls
A.8.31 (Separation of development, test, and production environments): Enforce separation in your build pipeline to prevent malware from using development credentials to alter production artifacts. Ensure read-only access to production registries from development environments.
A.8.32 (Change management): Require approval and integrity verification for every dependency update before merging. This helps detect unexpected package version changes.
PCI DSS v4.0.1 Requirements
Requirement 6.3.2: Keep an inventory of all software components, including transitive dependencies. Adaptive malware can exploit inventory gaps by introducing itself as a dependency.
Requirement 11.6.1: Implement change detection on software repositories. Alert when package contents change without version updates, a common sign of compromise.
NIST CSF v2.0 Supply Chain Functions
ID.SC-4: Develop processes to identify and assess supply chain risks. For package ecosystems, this includes:
- Automated scanning of new dependencies
- Behavioral analysis of installation scripts
- Network monitoring during builds
PR.DS-6: Use integrity checking to verify software authenticity. Implement checksum validation and signature verification for every package used.
Implementation Guidance
Phase 1: Visibility (Weeks 1-2)
Create a complete dependency graph, including all transitive dependencies. Verify your package lock file matches what's installed in node_modules/.
# Detect unexpected packages
npm ls --all --json > current-tree.json
diff baseline-tree.json current-tree.json
Alert on:
- Packages not in your lock file
- Mismatched package versions
- Packages making network calls during installation
Phase 2: Integrity Controls (Weeks 3-4)
Implement hash verification for every dependency. Use Subresource Integrity (SRI) hashes in lock files and ensure they don't change without approval.
Configure your registry proxy (Artifactory, Nexus) to:
- Cache packages with integrity hashes
- Block installations if hashes don't match
- Require manual review for packages requesting filesystem write access outside their directory
Phase 3: Behavioral Monitoring (Weeks 5-8)
Monitor for AI-enhanced malware using local models or code generation APIs:
Unexpected process spawning: Installation scripts should not launch Python interpreters, download binaries, or execute external shell scripts.
Anomalous network behavior: Flag packages contacting domains not listed in their metadata. Maintain an allowlist of legitimate CDNs and mirrors.
Filesystem access patterns: Packages should only write to their directory and cache locations. Alert on writes to:
- User home directories
- System configuration paths
- Other packages' directories
- Git repositories
Phase 4: Continuous Governance (Ongoing)
Shift to continuous verification:
Pre-commit hooks: Reject commits adding dependencies without updating your inventory and risk assessment.
CI/CD gates: Verify integrity hashes before every build. Malware can modify node_modules/ post-installation.
Runtime attestation: For critical apps, verify package integrity at startup. If hashes don't match, refuse to start.
Common Pitfalls
Trusting lock files alone: Lock files prevent version drift but don't detect post-installation changes. Always verify installed packages against expected hashes.
Scanning only direct dependencies: SANDWORM_MODE spread through typosquatted packages as transitive dependencies. Scan the entire dependency tree.
Relying on CVE databases: Adaptive malware introduces new malicious code, not exploiting known vulnerabilities. Use behavioral analysis and integrity verification.
Ignoring installation scripts: npm allows arbitrary code execution via preinstall, install, and postinstall hooks. Audit every script in your dependency tree.
Alert fatigue: Avoid overwhelming alerts by focusing on high-risk behaviors like process spawning and credential access, then expand gradually.
Quick Reference Table
| Detection Signal | Risk Level | Recommended Action | Mapped Control |
|---|---|---|---|
| Package not in lock file | Critical | Block installation, investigate source | PCI DSS 6.3.2 |
| Integrity hash mismatch | Critical | Block installation, compare with registry | NIST CSF PR.DS-6 |
| Installation script spawns processes | High | Sandbox execution, manual review | ISO 27001 A.8.31 |
| Network call to unlisted domain | High | Block, add to allowlist if legitimate | NIST CSF ID.SC-4 |
| Filesystem write outside package dir | High | Block, audit package source code | PCI DSS 11.6.1 |
| Typosquatting similarity > 80% | Medium | Flag for review, check publish date | NIST CSF ID.SC-4 |
| New transitive dependency added | Medium | Audit dependency chain, verify necessity | PCI DSS 6.3.2 |
| Package version changes without lock update | Critical | Revert, investigate compromise | PCI DSS 11.6.1 |
Emergency response: If adaptive malware is detected, assume it has modified other packages. Regenerate node_modules/ from a clean cache, verify all integrity hashes, and audit recent commits for unauthorized changes.
Your strategy must focus on behaviors and integrity, not just pattern matching.
