npm Package Vetting Checklist for Supply Chain Defense

If your team installs packages from public registries, you need a systematic way to catch trojanized dependencies before they reach production. The recent RedC2 4.0 campaign, where attackers published 14 functional npm packages that secretly installed an AI-powered Linux backdoor, shows that traditional code review isn't enough. Malicious packages can work exactly as advertised while running implants in the background.

This checklist provides a repeatable process for vetting npm packages, particularly those from unfamiliar publishers. Use it during dependency selection, not after installation.

Purpose of This Checklist

This template helps you evaluate npm packages before adding them to package.json. It's designed for:

• Security engineers reviewing dependency requests from development teams
• DevSecOps teams building automated supply chain controls
• Compliance managers implementing PCI DSS v4.0.1 Requirement 6.3.2 (inventory of bespoke and custom software and third-party software components)

The RedC2 case involved packages like [email protected] and [email protected], both functional utilities that installed a Linux implant with an LLM-backed command execution layer called Red Agent. Your goal is to catch these patterns before npm install runs.

Prerequisites

Before using this checklist, ensure you have:

• Access to npm registry metadata: Use npm view <package-name> or the npm API.
• Static analysis tools: Install npm-audit, socket.dev CLI, or similar.
• Baseline behavioral monitoring: Know what normal package installation looks like in your environment (file system writes, network calls, subprocess creation).
• Approval workflow: A documented process where someone reviews this checklist before packages enter your dependency tree.

If you're implementing this for PCI DSS v4.0.1 compliance, map this process to Requirement 6.3.3 (security of bespoke and custom software and third-party software components are defined and documented).

The Checklist Template

Copy this into your wiki, ticketing system, or code review template:

## npm Package Vetting Checklist

Package Name: _______________
Version: _______________
Requested By: _______________
Date: _______________

### 1. Publisher Verification
- [ ] Publisher has other packages in the registry
- [ ] Publisher account created more than 6 months ago
- [ ] Publisher identity matches documentation/GitHub org
- [ ] Package name matches expected naming convention (no typosquatting)

**Red flags**: New account, single package, name similar to popular package

### 2. Metadata Review
- [ ] Package description matches actual functionality
- [ ] Repository URL points to accessible, legitimate source code
- [ ] README contains usage examples and documentation
- [ ] License is specified and appropriate
- [ ] Weekly download count exceeds 100 (or justified for niche tool)

**Red flags**: Missing repo link, generic description, zero documentation

### 3. Version History Analysis
- [ ] Package has multiple versions (not just 1.0.0)
- [ ] Version increments follow semantic versioning
- [ ] Time between versions is reasonable (not all published same day)
- [ ] No suspicious version gaps or rapid-fire releases

**Red flags**: Only v1.0.0 exists, 10 versions in 24 hours, long dormancy then sudden activity

### 4. Dependency Tree Inspection
Run: `npm view <package-name> dependencies`

- [ ] Number of dependencies is reasonable for stated functionality
- [ ] All dependencies are from known publishers
- [ ] No dependencies with suspicious names or recent creation dates
- [ ] Dependency tree depth is shallow (fewer than 3 levels)

**Red flags**: Unexpected dependencies, deep trees, obfuscated package names

### 5. Installation Behavior Check
Run in isolated environment: `npm install <package-name> --dry-run`
Then install in sandbox and monitor.

- [ ] Install scripts are documented or absent
- [ ] No postinstall scripts that download external binaries
- [ ] No network calls during installation (except to npm registry)
- [ ] File writes are limited to node_modules directory
- [ ] No subprocess creation during install

**Red flags**: Undocumented postinstall, curl/wget in scripts, writes to /tmp or /usr/local

### 6. Source Code Audit (Required for High-Risk Packages)
Clone repository and review:

- [ ] Source matches published package (run `npm pack` and compare)
- [ ] No obfuscated code or encoded strings
- [ ] No eval() or Function() constructor usage
- [ ] No dynamic imports from external URLs
- [ ] No file system operations outside expected scope

**Red flags**: Base64 strings, obfuscation, network calls to non-registry domains

### 7. Runtime Behavior Validation
Run package in monitored sandbox:

- [ ] No unexpected network connections after installation
- [ ] No persistence mechanisms (cron jobs, systemd services)
- [ ] No privilege escalation attempts
- [ ] Resource usage matches expected profile

**Red flags**: Connections to unknown IPs, background processes, elevated permissions

### 8. Community Signal Check
- [ ] GitHub issues/PRs show legitimate development activity
- [ ] No recent security reports or CVEs
- [ ] Package not flagged by Socket.dev, Snyk, or npm audit
- [ ] Search for package name + "malware" or "backdoor" returns nothing

**Red flags**: Security tool alerts, recent malware reports, no community engagement

---

**Approval Decision**: [ ] APPROVED  [ ] REJECTED  [ ] NEEDS FURTHER REVIEW

**Reviewer Name**: _______________
**Reviewer Signature**: _______________

**If approved, add to**: 
- [ ] Approved package inventory
- [ ] SBOM (Software Bill of Materials)
- [ ] Dependency monitoring dashboard

How to Customize It

Adjust this template based on your risk tolerance:

For high-security environments (financial services, healthcare):

• Add mandatory source code review for all packages
• Require two-person approval for new dependencies
• Implement automated behavioral analysis in CI/CD
• Add "last security audit date" field

For faster-moving teams:

• Automate sections 1-4 with Socket.dev or Snyk
• Focus manual review on sections 5-7
• Create "pre-approved" list for common packages
• Use risk scoring (low/medium/high) instead of binary approval

For compliance requirements:

• Map each section to specific requirements (PCI DSS v4.0.1 Requirement 6.3.2, NIST 800-53 SA-10)
• Add fields for compliance framework checkboxes
• Include retention requirements for completed checklists
• Link to your software inventory system

The RedC2 campaign advertised on Hack Forums in early June 2026 demonstrates that attackers publish fully functional packages to avoid suspicion. Your customization should account for this: even if a package works perfectly, it might still contain malicious code.

Validation Steps

After implementing this checklist:

1. Test with known-good packages: Run three legitimate packages through the process to establish baseline timing (should take 10-15 minutes per package for manual review).

2. Test with known-bad packages: If you have access to security research or honeypot data, validate that the checklist catches red flags.

3. Measure false positive rate: Track how many packages get rejected but turn out to be safe. If it's above 30%, your criteria might be too strict.

4. Audit compliance: Review 10 random completed checklists monthly to ensure teams fill them out correctly.

5. Update your SBOM tooling: Ensure approved packages automatically flow into your Software Bill of Materials. PCI DSS v4.0.1 Requirement 6.3.2 requires maintaining an inventory of all software components.

6. Monitor approved packages: Just because a package passed vetting at v1.0.0 doesn't mean v1.0.1 is safe. Implement continuous monitoring with npm audit or commercial tools.

The RedC2 backdoor included an AI assistant for command execution, showing that malware is getting more sophisticated. Your vetting process needs to be equally systematic. This checklist won't catch everything, but it'll force your team to look before they install, and that's where most supply chain compromises start.