How to Protect Your Projects From Malicious npm Packages (and What GitHub's New Package Firewall Does)

What GitHub Announced

GitHub's changelog describes the package firewall as a service that "sits between endpoints or internal registries and the upstream package repositories" and "inspects both metadata requests and package downloads" (GitHub changelog). In practice, developer laptops, CI/CD runners and coding agents fetch npm packages through the firewall instead of going straight to the public registry.

Administrators set the rules once for the whole enterprise. If a request breaks a rule, the install is refused before the package reaches the machine. Help Net Security summarised the effect simply: the checks run before a package reaches a laptop, a build or a coding agent (Help Net Security).

How the Package Firewall Works

GitHub's documentation lists five policy controls. Each one targets a pattern seen in real supply chain attacks (GitHub Docs):

Two of these deserve a closer look. An attestation downgrade is a strong warning sign: if a package has always been built and signed by a trusted CI pipeline and a new version suddenly is not, someone may have published it by hand with stolen credentials. A newly added install script is equally suspicious, because install scripts run automatically on your machine and are the most common way malicious packages execute code.

If a package is blocked by mistake, the error in npm or the CI log includes a link to request an exception. Enterprise administrators and security managers review and approve these requests, and approved exceptions become part of the policy (GitHub changelog, GitHub Docs).

Who Can Use It and What It Costs

According to GitHub, the firewall is "available today in public preview for all GitHub Enterprise Cloud customers, including data-resident GitHub Enterprise Cloud." It supports npm packages only for now.

The service is free during the preview. GitHub says that at general availability it "will be charged based on metered usage, similar to Actions billing" (GitHub changelog). No general availability date or price has been published, and neither GitHub nor the coverage we reviewed mentions support for Free, Pro or Team plans.

How Enterprise Teams Turn It On

Setup has two parts: an administrator sets the policy, then each endpoint points npm at the firewall. GitHub's documentation describes it as follows (GitHub Docs):

• Set the policy: in your enterprise, open Policies, then Package firewall, and choose the controls. Enterprise owners and security managers can change it by default, and the permission can be delegated through a custom role.
• Create a token: use a GitHub token from a user or bot account that belongs to the enterprise. GitHub says it needs no more than read-only access to public repositories. Keep it in a secret store, never in your repository.
• Point npm at the firewall: set the npm registry to your enterprise's firewall URL and add the token, either in the user-level .npmrc file or with npm config commands.
• Cover CI and agents too: runners and coding agents need the same registry setting, or they can bypass the firewall by going straight to the public registry.
• Artifactory users: GitHub describes an experimental route that adds the firewall as an upstream remote repository. Remove any other remote that pulls straight from the public npm registry so nothing goes around it.

npm config set registry https://package-firewall.githubapp.com/npm/enterprises/ENTERPRISE
npm config set '//package-firewall.githubapp.com/npm/enterprises/ENTERPRISE/:_authToken=${GITHUB_TOKEN}'

Why a Cooldown Helps, and Where It Falls Short

Most malicious npm releases are found and removed within hours or days, because researchers, scanners and the registry watch new uploads closely. A cooldown means your systems simply do not install anything that new, so a poisoned version is often gone before your rule would allow it in.

It is not a complete answer. Socket, quoted by The Hacker News, points out that "malicious code also doesn't magically become harmless with age. A release that escapes detection can simply outlast the cooldown." The same source notes the trade-off: legitimate fixes must wait too, unless someone grants an exception (The Hacker News).

The answer is layers. A cooldown buys time, malware and vulnerability checks catch what has been reported, and attestation and install-script checks catch suspicious changes that nobody has reported yet. The same thinking applies to the steps below, which work with or without GitHub's firewall.

10 Steps to Protect Any Project From Malicious npm Packages

You do not need an enterprise contract to apply the same ideas. These steps suit freelancers, startups and established teams alike, and most take minutes:

• 1. Commit your lockfile and install with npm ci. A committed package-lock.json pins exact versions and integrity hashes, and npm ci installs exactly those, so a new malicious version cannot slip in during a routine build.
• 2. Add a release-age delay. If you cannot use a firewall, wait before adopting new versions. Dependabot supports a cooldown setting for version updates, pnpm and Yarn offer minimum release age settings, and npm install --before lets you resolve versions as of an earlier date.
• 3. Turn off install scripts by default. Run npm config set ignore-scripts true, then allow scripts only for the few packages that truly need them. This removes the most common way malicious packages run code at install time.
• 4. Check signatures and provenance. Run npm audit signatures in CI to verify registry signatures and provenance attestations, and be wary when a package that used to publish with provenance suddenly stops.
• 5. Review new dependencies before adding them. Check the maintainer history, download trends, repository link, recent ownership changes and whether the name is a near miss of a popular package (typosquatting).
• 6. Keep fewer dependencies. Every package you remove is one less maintainer account that could be compromised. Prefer well-maintained packages and the standard library where it does the job.
• 7. Scan continuously. Use npm audit, Dependabot alerts or a similar scanner, and treat dependency fixes as routine patch management. Look up specific issues with our CVE Search tool.
• 8. Give CI the least privilege it needs. Apply least privilege to build tokens, keep publishing credentials out of jobs that install third-party code, and use short-lived tokens where you can, so a malicious package has little to steal.
• 9. Protect your own publishing accounts. If you maintain packages, turn on multi-factor authentication with a phishing-resistant method, use trusted publishing from CI with provenance, and treat any unexpected login or password reset email as a possible account takeover attempt.
• 10. Put AI coding agents behind the same rules. Agents install packages quickly and without pausing to think. Make sure they use the same registry, lockfile and script settings as humans, and review the packages they add before merging.

# Turn off package install scripts first, so nothing runs during installs
npm config set ignore-scripts true

# Install exactly what the lockfile says (use in CI; the flag also covers fresh runners)
npm ci --ignore-scripts

# Verify registry signatures and provenance attestations
npm audit signatures

# Check installed packages for known vulnerabilities
npm audit

What to Do If You Installed a Malicious Package

If an advisory shows that a package you installed was malicious, assume the code ran on every machine that installed it. Treat it as an incident response case, not a routine update:

• Find where it landed: search lockfiles across repositories, CI logs and developer machines for the affected package and version.
• Remove it and pin a known-good version, then rebuild from clean images and caches.
• Rotate every secret the affected machines could reach: npm and GitHub tokens, cloud keys, SSH keys and CI secrets. Malicious packages very often steal credentials.
• Check for persistence and new activity: unexpected GitHub workflows, new repositories, new npm publishes from your accounts, and unusual cloud activity.
• Tell the people who depend on you if any of your own packages or releases may have been affected.

What We Still Do Not Know

A few questions remain open while the firewall is in preview:

• Pricing: GitHub has said only that it will be metered "similar to Actions billing" at general availability.
• Other ecosystems: only npm is supported today. GitHub has not published a timeline for others such as PyPI or Maven.
• Smaller plans: neither GitHub nor the coverage we reviewed says whether the firewall will reach plans below Enterprise Cloud.
• Behaviour during outages: the documentation we reviewed does not say what happens to installs if the firewall service is unavailable.

We will follow updates in our daily cybersecurity news briefing.

Final Thoughts: Make Install Time a Checkpoint

For years, npm install has been an act of trust: whatever the registry served, ran. GitHub's package firewall is a welcome sign that the industry now treats install time as a security checkpoint, and enterprise teams should test it during the free preview.

Everyone else can adopt the same mindset today. Pin what you install, refuse install scripts by default, wait before adopting brand-new releases, verify where packages came from and keep secrets away from build jobs. Those habits turn a supply chain attack from a crisis into a non-event.