Install-Path Security

5 npm security rules every team should enforce today

npm supply chain attacks are recurring operational risk, not a rare anomaly. Maintainer takeovers, typosquats, install-script malware, protestware, and vulnerable versions continue to hit widely used packages.

Teams need controls that run before code reaches laptops and CI. nproxy evaluates package requests at fetch/install time and can block or warn before dependency resolution completes.

Published April 2, 2026

Real incidents this maps to

Timeline
  • 2018-09-09 - event-stream@3.3.6 introduced a malicious dependency path through flatmap-stream.
  • 2021-10-22 - ua-parser-js@0.7.29, 0.8.0, and 1.0.0 were published with malicious install-stage behavior.
  • 2022-01-05 to 2022-01-08 - faker@6.6.6 and colors@1.4.44-liberty-2 sabotage releases caused widespread CI failures.
  • 2022-03 - node-ipc protestware behavior appeared in releases including 10.1.1, 10.1.2, and 9.2.2.
  • 2026-03-24 - another wave of npm typosquat packages targeting crypto developers was publicly reported.

One-minute setup before policy enforcement

These commands were validated against the current CLI help output.

1) Configure .npmrc for your organization
npx @nproxy/cli setup acme-security
2) Verify proxy connectivity and headers
npx @nproxy/cli verify acme-security
3) Install through nproxy
npm install <package> \
  --registry=https://acme-security.nproxy.app/

This post is framed as five controls. The fifth combines two rule engines: malware and vulnerability. That gives coverage across six high-signal install-path checks.

Rule 1: Quarantine brand-new package names

Use first_seen in block mode. This catches new package names in a quarantine window (default 7 days), which is where many typosquat and short-lived malware campaigns operate.

Incident Example: crossenv (2017) and recent typosquat waves

Typosquats rely on newly created package names that are easy to miss in review. Quarantining brand-new names cuts off this attack path early.

Install-path behavior
$ npm install crossenv --registry=https://acme-security.nproxy.app/
BLOCKED crossenv@1.0.0 - first_seen: package created 2 days ago (threshold: 7)
resolution failed - blocked package in dependency graph

Rule 2: Flag publisher identity changes

Use publisher_change in warn mode at minimum. Sudden maintainer/publisher shifts are a known precursor to supply chain abuse.

Incident Example: event-stream maintainer transfer (2018)

event-stream changed publisher before the malicious dependency chain was introduced. This is exactly the anomaly this rule is meant to surface.

Install-path behavior
$ npm install event-stream --registry=https://acme-security.nproxy.app/
WARN event-stream@3.3.6 - publisher_change: publisher changed from dominictarr to right9ctrl
install proceeds (warn mode)

Rule 3: Alert on unexpected dependency additions

Use unexpected_deps to detect versions that add new dependencies not present in prior releases. This catches dependency injection patterns.

Incident Example: event-stream adding flatmap-stream

event-stream introduced a new dependency, flatmap-stream, which carried the malicious payload. A dependency-shape delta is often the first high-signal clue.

Install-path behavior
$ npm install event-stream@3.3.6 --registry=https://acme-security.nproxy.app/
WARN event-stream@3.3.6 - unexpected_deps: new dependency flatmap-stream not present in prior versions
install proceeds (warn mode)

Rule 4: Detect install-time script execution

Use install_scripts to surface lifecycle hooks (preinstall, postinstall, etc.) that execute code during package install.

Incident Example: ua-parser-js compromised releases (2021)

Malicious ua-parser-js versions added preinstall behavior. Teams with install-script visibility would have had an immediate signal in the install path.

Install-path behavior
$ npm install ua-parser-js@0.7.29 --registry=https://acme-security.nproxy.app/
WARN ua-parser-js@0.7.29 - install_scripts: package defines preinstall script
install proceeds (warn mode)

Rule 5: Block known-bad versions (malware + vulnerability)

Keep malware and vulnerability in block mode. This provides hard enforcement for known malicious versions and published CVEs.

Incident Examples: node-ipc protestware and CVE-2021-4229

When threat intelligence marks a version as malware/protestware, the malware rule can block it. When an advisory is published (for example, CVE-2021-4229), the vulnerability rule can block affected versions by severity policy.

Install-path behavior
$ npm install node-ipc@10.1.2 --registry=https://acme-security.nproxy.app/
BLOCKED node-ipc@10.1.2 - malware: version flagged by threat intelligence

$ npm install ua-parser-js@0.7.29 --registry=https://acme-security.nproxy.app/
BLOCKED ua-parser-js@0.7.29 - vulnerability: GHSA-pjwm-rvh2-c87w (CVE-2021-4229, HIGH)

Where colors/faker fits in this model

colors/faker was maintainer-authored sabotage, not a publisher takeover. That incident is a good reminder to use layered controls and avoid single-signal dependence.

  • Keep known-bad blocking (malware, vulnerability) always on.
  • Keep behavior-anomaly detection on (publisher_change, unexpected_deps, install_scripts).
  • Use first_seen to suppress fresh package-name risk where typosquats usually land first.

No rule set guarantees zero malicious packages. The goal is risk reduction by enforcing policy before dependency resolution completes.

Sources

Stop risky packages before they reach production

Put npm policy checks in the install path today and keep your existing developer workflow.

npx @nproxy/cli setup your-org-slug
Protect a repoRead the docs