Required Reading
~5 min

Incident Playbooks

Step‑by‑step actions for common npm threat scenarios.

Postinstall downloads a binary

  1. Block PR/update. Capture the tarball and diff recent versions.
    Stops propagation while you verify what changed and whether payload is legitimate.
  2. Verify host: must be trusted GitHub Releases/CDN. If unknown, treat as malicious.
    Attackers commonly host payloads on throwaway domains to avoid scrutiny.
  3. Look for obfuscation and child_process launches. Remove the dependency if non‑essential.
    Hidden behavior plus shell execution is a strong indicator of malware.
  4. Quarantine build containers; rotate tokens if any env secrets were accessible.
    If the payload ran, credentials may be compromised; rotate to be safe.

Suspected typosquat

  1. Check maintainers and repo; confirm legitimate lineage.
    Typosquats often have unknown maintainers or no real upstream project.
  2. Inspect README and code size; tiny or empty repos are red flags.
    Malicious packages minimize content and hide behavior in postinstall.
  3. Replace with the intended package; add allow‑lists to prevent recurrence.
    Prevents future accidents in CI and developer machines.

Supply‑chain compromise

  1. Pin to last known‑good version; block auto‑upgrades.
    Freezes to a safe state while investigation proceeds.
  2. Audit changes in the compromised release: look for obfuscation, network I/O, or env access.
    These are common attacker behaviors in compromised releases.
  3. Run builds with --network=none and scrubbed HOME until confidence restored.
    Limits blast radius and stops exfil while you assess.
  4. Monitor maintainer activity; require two‑person review for re‑adoption.
    Adds friction and oversight for future releases.

child_process in install scripts

  1. Assume high risk. Identify exact command and purpose.
    Shell commands during install can touch filesystem, network, and secrets.
  2. If purely build‑related and host chain is trusted, isolate and whitelist.
    Some native builds need compilers; whitelist only after verification.
  3. Otherwise, remove or replace the dependency; report to registry/security teams.
    Prevents propagation and helps the ecosystem respond quickly.

Unexpected network activity during install

  1. Capture logs; identify which package initiates outbound connections.
    Pinpoints the source for targeted mitigation.
  2. Run with --network=none; confirm build still succeeds.
    Proves whether network access is truly required.
  3. Allowlist domains if needed and verify checksums/signatures.
    Minimizes exposure when network dependency is legitimate.

Maintainer change flagged

  1. Freeze to last known‑good version; audit diffs of latest release.
    Stabilizes while you verify new ownership.
  2. Check repo activity and communication; look for transparency.
    Legitimate handovers are usually documented.
  3. Require two‑person review for first re‑adopted versions.
    Adds oversight during the riskiest period.