GitHub Package Firewall Hits Public Preview: Every Package Your Coding Agent Installs Gets Frisked First

On October 20, GitHub announced that Package Firewall is entering public preview. In one sentence: it is a package-installation checkpoint standing between your Actions runners, coding agents, and upstream npm registries — every package passes five policy checks before it can be downloaded.

Why this matters is not "one more enterprise security feature." It is the first time install policy has become first-class infrastructure for coding agents. npm install used to be typed by a human who could glance at a package name, hesitate over a version published three days ago, and decide. Now an agent installs a dozen dependencies you have never heard of in thirty seconds, with no human in the loop. When the installer changes from person to agent, the install policy has to become infrastructure.

GitHub's own framing names the era: "An increasing number of malware attacks exploit systems at package installation time, harvesting credentials on CI/CD hosts or developer workstations without even running the package's code." Supply-chain attacks have moved upstream — from "explodes when it runs" to "steals credentials the moment it installs."

Where it sits and what it checks

The placement is the key design decision: the firewall is not antivirus on your laptop, nor a static lockfile scanner. It is an enterprise-specific npm registry proxy. Admins configure policy at the enterprise level, then point .npmrc on coding agents, CI runners, and dev machines at https://package-firewall.githubapp.com/npm/enterprises/<enterprise>. Metadata requests and package downloads flow through it and are evaluated against policy. (docs)

The five controls, with defaults verified from the official docs:

• Cooldown period: newly published versions sit out a configurable minimum age (0–365 days; 1 day by default, 0 disables). Most poisoned packages are discovered and taken down within days of release — a 24-hour waiting room blocks a large share of them. Think of it as a mandatory cooling-off period for the AI's impulse shopping.
• Malware advisories: blocks packages with active malware advisories in the GitHub Advisory Database. On by default.
• Vulnerability severity threshold: blocks versions affected by advisories at a chosen severity — Critical only, High+, Medium+, or any. Defaults to Critical only.
• Attestation downgrade check: compares attestations of the requested version against earlier ones. If a package used to ship SLSA attestations and the new version doesn't, the publishing pipeline was likely compromised — block it. On by default.
• Install script check: flags packages that recently added install-time scripts (preinstall/postinstall), which can run arbitrary commands and are the classic credential-theft vector. On by default.

False positives get an escape hatch borrowed from other GitHub Advanced Security features: when the firewall blocks a package, the npm output or CI log includes a URL for requesting an exception, with fields pre-filled (repository, ecosystem, package, version, reason). Enterprise admins review and approve; approved overrides are written back into policy and can be revoked anytime. (docs) The docs' own example is telling: a new version carrying a security fix is exactly what a minimum-age policy would block — the exception flow is the lifeline.

Onboarding is low-friction by design: the token needs nothing beyond read-only access to public repositories, and JFrog Artifactory shops can point a remote repository through the firewall (marked experimental) so public and private packages keep flowing through one virtual repo — with public packages now frisked on the way in.

Why the agent era makes this urgent

Dissect a typical npm poisoning: the attacker compromises a maintainer account, publishes a patch release (4.2.1 → 4.2.2, looks harmless), and hides a postinstall script that exfiltrates NPM_TOKEN or CI secrets from environment variables. It runs during npm install, in seconds, without the package's "real" code ever executing. The malicious act lives in the gap between dependency resolution and code execution — a gray zone nobody watches. Code scanners look for malicious logic in the package body (the install script is a "legitimate feature" of npm); lockfile audits look for known CVEs (a package poisoned two hours ago isn't in any advisory DB yet). The firewall's five checks lock that gray zone one door at a time: install-script check for behavior, cooldown for the time window, malware advisories for known bad actors, attestation downgrade for hijacked publishing, severity threshold for known risk.

Note that GitHub inspects metadata requests too, not just downloads ("inspecting both metadata requests and package downloads"). The earlier defense moves, the cheaper it gets.

And the attestation-downgrade check deserves its own spotlight. npm's provenance (SLSA signatures proving "this version really came from that CI build") has been rolling out for two years. Attackers who hijack a publishing pipeline usually can't produce matching signatures — so "had attestations before, doesn't now" is an extremely strong anomaly signal. The firewall productizes that signal and turns it on by default. Only a platform player can do this: no point tool has the ecosystem-wide signature history; GitHub does.

Four honest caveats

1. npm only. The changelog's shortest sentence is its last: "Currently the package firewall only supports npm packages." No PyPI, no crates.io, no Go modules — while vibe coders' stacks long ago stopped being JS-only. GitHub says more is coming "based on customer demand"; until then it secures only part of your dependency tree.

2. Enterprise Cloud gate. Public preview is for GitHub Enterprise Cloud customers (including data-residency editions) only. Individual developers and small teams — the vibe coders whose agents install packages most recklessly — are outside the gate.

3. The cooldown has a cost. One day sounds painless until a 0-day drops and every emergency patch triggers the exception flow. The exception pipeline is well designed, but it converts "security delay" into "process delay" — teams need to decide up front which packages deserve fast-track exceptions and who approves them, or the policy becomes a stealth tax on shipping speed.

4. It guards download time, not runtime. A "clean but vulnerable" package can still be exploited at runtime; the firewall doesn't replace Dependabot or code scanning. It's a new layer of defense in depth, not the finish line.

One transparency note on pricing: GitHub says the service is free during preview and metered at GA, "similar to Actions billing" — vendor wording, with no numbers yet. (changelog) Budget accordingly.

What vibe coders can do today

You probably aren't an Enterprise Cloud customer. But the five checks double as a personal install-safety checklist, each with a DIY equivalent:

• A homemade cooldown: have your agent report package name, version, and publish date before installing anything (npm view <pkg> time shows it). Don't install versions published hours ago. Put it in your AGENTS.md/CLAUDE.md: "report name, version, and publish date of any new dependency and wait for confirmation."
• Lock the lockfile, audit install scripts: committing package-lock.json is the baseline; npm install --ignore-scripts lets you review preinstall scripts one by one — the manual version of the firewall's default-on check.
• Prefer packages with provenance: favor packages shipping npm provenance (SLSA signatures); npm audit signatures verifies them. A break in signature history is a red flag — the attestation-downgrade check, by hand.
• Least-privilege tokens for agents: the firewall docs model "read-only access to public repos is enough to install." Apply the same to your agents' tokens and CI secrets — stolen credentials hurt less when they were already minimal.
• Run npm audit regularly: the firewall's default is "Critical only" — a fine starting threshold for personal projects too. Zero-CVE perfectionism can wait.

Boundary note with our existing dependency supply-chain security guide: that piece is the methodology for indie developers; this is the product news of GitHub turning several of those checks into enterprise infrastructure. Complementary, not overlapping.

What to watch next: GA pricing granularity (per-request vs. per-byte will decide SMB adoption); whether PyPI is next ("currently, only npm is supported" leaves the door visibly open); and the community discussion GitHub linked — real-world false-positive rates from early adopters will be more informative than the docs.

The symbolism outweighs the feature list: Package Firewall marks the moment platforms admitted that once AI starts running npm install for humans, "who decides what gets installed" is itself a security problem that needs productizing. Cooldowns, exception flows, metered billing — all answers to one question: how do you put the right brakes on an executor much faster than you. npm is only the first stop; PyPI and crates.io versions won't be far behind. Your homemade cooldown can start today.