Scope - What This Guide Covers
This guide provides detection, prevention, and response strategies for supply chain attacks targeting package registries. It includes steps for securing your dependency management, CI/CD pipelines, and developer environments against credential-harvesting malware.
The recent pgserve and automagik incidents — affecting approximately 8,044 weekly downloads combined — highlight attacks that exploit the trust model of open-source ecosystems. While this guide focuses on npm, the principles apply to PyPI, RubyGems, and other registries.
What's covered:
- Registry-level security controls
- Developer workstation hardening
- CI/CD pipeline isolation
- Incident response procedures
What's not covered:
- General malware detection (outside the supply chain context)
- Code-level vulnerability scanning
- Network security controls
Key Concepts and Definitions
Typosquatting: Publishing packages with names similar to legitimate ones (e.g., "automagik/genie" mimicking a real package).
Credential Harvesting: Automated extraction of authentication tokens, API keys, and environment variables. The compromised pgserve versions 1.1.11, 1.1.12, and 1.1.13 injected a 1,143-line script for this purpose.
Registry-to-Repo Mismatch: When a package's claimed source repository doesn't match its actual code. This is your first detection signal.
Decentralized Exfiltration: Using resilient infrastructure, such as an Internet Computer Protocol (ICP) canister, to receive stolen data while avoiding traditional takedown mechanisms.
Blast Radius: The scope of systems potentially compromised when a developer installs a malicious package. For credential harvesters, this extends beyond the local machine to any service those credentials can access.
Requirements Breakdown
PCI DSS v4.0.1 Implications
Requirement 6.3.2: Protect all system components and software from known vulnerabilities, including build-time dependencies.
Requirement 8.3.1: Implement multi-factor authentication for all access. If your npm tokens lack MFA, a credential harvester bypasses this control entirely.
Requirement 11.6.1: Detect and respond to security failures. Monitor your dependency installation process.
NIST CSF v2.0 Mapping
ID.SC-4: Routinely assess suppliers and third-party partners using audits and other evaluations. For open-source, use automated composition analysis, not manual review.
PR.DS-6: Use integrity checking mechanisms to verify software and information integrity. Lock files alone don't satisfy this — you need hash verification and signature checking.
DE.CM-8: Perform vulnerability scans, including your node_modules directory, not just deployed artifacts.
Implementation Guidance
1. Pre-Installation Controls
Enable package provenance verification:
npm config set audit-level moderate
npm config set ignore-scripts true
Setting ignore-scripts to true prevents automatic execution of install hooks — the primary infection vector. The pgserve malware relied on these scripts to inject its harvesting code.
Implement registry mirroring:
Point your .npmrc to an internal Artifactory or Verdaccio instance that performs automated scanning before packages reach developers. This adds a 4-12 hour delay but creates a chokepoint for detection.
2. Automated Detection
Deploy software composition analysis (SCA) tools that flag:
- Registry-to-repo mismatches (Socket, Snyk, or Sonatype Nexus Lifecycle)
- Packages with install scripts not present in previous versions
- Sudden dependency additions in minor version bumps
- Download count anomalies (a package with 50 weekly downloads suddenly showing 5,000)
GitHub Actions example:
- name: Check for supply chain risks
uses: step-security/harden-runner@v2
with:
egress-policy: block
allowed-endpoints: registry.npmjs.org:443
This configuration would have prevented the ICP canister exfiltration by blocking unexpected network egress.
3. Least Privilege Token Management
Scope npm tokens to specific packages:
npm token create --read-only --cidr=10.0.0.0/8
If your organization uses 10 packages, create 10 tokens. When a credential harvester steals one token, it gains access to one package's publishing rights, not your entire registry presence.
Rotation schedule:
- Read-only tokens: 90 days
- Publish tokens: 30 days
- CI/CD tokens: 14 days
The 1,300 weekly downloads of compromised pgserve versions suggest a 7-10 day detection window. Aggressive rotation limits the window of compromise.
4. CI/CD Pipeline Isolation
Run npm install in ephemeral containers with:
- No access to production credentials
- Network policies limiting egress to your registry mirror only
- File system mounts that are read-only except for
node_modules
Dockerfile pattern:
FROM node:20-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci --ignore-scripts
# Verify integrity before proceeding
RUN npm audit signatures
The npm audit signatures command (available in npm 8.15.0+) validates package signatures against the public registry's provenance data.
Common Pitfalls
Pitfall 1: Trusting download counts as a quality signal The fake automagik/genie package showed 6,744 weekly downloads. Attackers inflate these numbers through automated installs or by timing attacks to coincide with legitimate package popularity.
Pitfall 2: Running npm audit only in CI
Run it locally before every npm install. The 1,143-line injection in pgserve wouldn't appear in standard vulnerability databases for days or weeks.
Pitfall 3: Ignoring minor version updates The pgserve compromise occurred in versions 1.1.11 through 1.1.13 — minor patches that most teams auto-approve. Treat minor updates with the same scrutiny as major releases.
Pitfall 4: Storing credentials in environment variables
Credential harvesters scrape process.env. Use secret management services (AWS Secrets Manager, HashiCorp Vault) with short-lived tokens instead.
Pitfall 5: Assuming package removal solves the problem Even after npm removes malicious packages, you must rotate every credential that existed on any machine where the package was installed. The ICP canister receiving exfiltrated data remains operational after takedown.
Quick Reference Table
| Control | Implementation | Detection Window | Compliance Mapping |
|---|---|---|---|
| Registry mirroring | Artifactory/Verdaccio with scanning | 4-12 hours | PCI DSS 6.3.2, NIST CSF ID.SC-4 |
| Install script blocking | npm config set ignore-scripts true |
Immediate | PCI DSS 6.3.2 |
| SCA tooling | Socket/Snyk/Sonatype | 15-60 minutes | NIST CSF DE.CM-8 |
| Token rotation | Automated via CI/CD | 14-90 days | PCI DSS 8.3.1 |
| Signature verification | npm audit signatures |
Per-install | NIST CSF PR.DS-6 |
| Network egress controls | GitHub Actions harden-runner | Immediate | NIST 800-53 SC-7 |
| Ephemeral build environments | Docker multi-stage builds | Per-build | SOC 2 CC6.6 |
Immediate actions if you've installed compromised packages:
- Rotate all credentials on affected machines (API keys, cloud provider tokens, SSH keys)
- Review access logs for unauthorized activity during the exposure window
- Scan for persistence mechanisms (cron jobs, systemd services, shell profile modifications)
- Update your dependency lock file and re-install from a clean state
- File an incident report per PCI DSS Requirement 12.10.1 if payment data is in scope
The sophistication of these attacks — from decentralized exfiltration infrastructure to targeting minor version bumps — means your detection window is measured in hours, not days. Bookmark this guide and review your controls quarterly.
