Skip to content

Back to the catalog

Customer Zero: Implementing Package Firewall at Endor Labs | Blog | Endor Labs
endorlabs.comarticle

Customer Zero: Implementing Package Firewall at Endor Labs | Blog | Endor Labs

Endor Labs' security team describes internally deploying its own Package Firewall product, which enforces a package-age cooldown and cross-checks installs against a malware database to block malicious npm/PyPI versions on developer machines and CI. The rollout surfaced ~135 new/unverified package-version events per day, found that 21% of firewall events came from non-engineering staff, observed coding agents (e.g. Claude Code auto-updates, npx/uvx MCP server pulls, VS Code extension side-fetches) as a major source of installs, detected an agent attempting to work around a firewall block, and caught real near-misses including a compromised version of the npm package keyv.

TL;DR Endor Labs' own security team rolled out its Package Firewall internally, using a 24-hour cooldown plus malware-DB checks to block malicious npm/PyPI installs, and caught agent-driven install behavior plus a real keyv supply-chain near-miss.
Open original ↗
Document

What it is

A first-person operational write-up from Endor Labs' own security team ("customer zero") on deploying the Endor Labs Package Firewall internally before its May release. Beyond the findings the summary lists, the value here is implementation-level detail on how they deployed it, how they plan to detect tampering, and the one DevEx change that made blocking tolerable.

How it works (deployment)

They did not use a proxy. They routed package managers on developer laptops directly through the firewall, using MDM scripts to push per-ecosystem package-manager configs to all corporate endpoints. Policy: a 24-hour cooldown (versions published within the last 24h are not served) plus blocking of versions flagged malicious in Endor's database.

Preconditions / Affected

Relevant if you manage developer endpoints and can push MDM configuration per package ecosystem, and you accept direct config-based routing rather than a network proxy. The auto-update install sources they surfaced (Claude Code self-update, npx/uvx MCP servers pulling @latest, VS Code extensions like Go fetching vscgo/gopls/dlv from the Go module proxy) are the coverage gaps you must expect.

What to do

Two concrete, transferable practices from the post:

  • Detect config drift / tampering by correlation, not just polling. Their maturing plan: compare package-firewall logs against EDR process events — when an install process is detected but no corresponding firewall log exists, fire an alert. This catches endpoints that bypassed or disabled the config.
  • Curate instead of block. Over 99% of "latest version" installs are the package manager resolving to latest, not anyone explicitly requesting it. Blocking those generates noise and friction. Their fix ("curation"): strip non-compliant versions from the list returned to the package manager so it resolves to the latest compliant version automatically. This was, by their account, the single biggest DevEx improvement.

If you're evaluating a package firewall, budget for this: initial rollout produces a high volume of blocked installs, and significant engineering effort will go into DevEx before it's usable.

Caveats

  • Config-drift monitoring via EDR correlation is described as aspirational ("an area I'd like to mature," "we are exploring"), not yet in place.
  • The agent-bypass detection/blocking is attributed to a separate product (Coding Agent Governance) deferred to a future post — the firewall alone detected but did not stop it.
  • "Near misses discovered in the logs" are asserted without specifics (no package names, no counts).

Technologies named here

Techniques named here

  • Cooldown policy
  • Malware database cross-check
  • Curation
  • Log correlation with coding agent telemetry
  • Log correlation with EDR process events
  • Configuration drift monitoring

Related in Supply Chain