GitHub Package Firewall: npm checks before installation

GitHub has introduced a package firewall for npm: a check that compares every package with the company’s policy before it is installed and blocks known malware, critical vulnerabilities and versions published too recently. heise Security reported on it on 23 October, Help Net Security on the 28th and The Hacker News on 29 October 2026. The technical details below come from Help Net Security, which also gathered answers from two GitHub product leads.

The firewall is one of four security additions that GitHub links to the growth of software written with the help of AI agents. The stated goal is to catch problems before a package reaches a developer’s laptop, a build or a coding agent’s environment.

How the firewall works

According to Help Net Security:

• the check runs at install time, comparing the requested package with a policy defined at enterprise level;
• there are three blocking criteria: known malware, critical vulnerabilities and brand-new versions;
• any developer can turn it on by pointing npm at the firewall: in practice, packages no longer come straight from the registry but pass through the filter.

To decide whether a version is “too new”, GitHub’s Adam Leftik explained, the firewall uses the release date in the package metadata, which is the package manager’s responsibility. Companies can modify the rules and create custom policies with a waiting period (soak time or cool-down) before a new version can be installed.

The available sources do not describe the exact configuration, availability across GitHub plans or any licences required, and they only mention npm.

Why the waiting period matters

In our reading, the rule on new versions is the most interesting part. A malicious version of a legitimate package, published with stolen credentials or by exploiting a weakness in the publishing process (as in this month’s SlugFest case in npm Trusted Publishing), is most dangerous in the first hours and days, before it is reported and pulled. A waiting period shrinks that window; blocking known malware covers versions that have already been identified. The relevant MITRE ATT&CK technique is T1195.001 (Compromise Software Dependencies and Development Tools).

Some limits to keep in mind, again in our reading:

• the filter only protects installs that go through the firewall: a workstation, CI job or agent configured differently bypasses it;
• the waiting period also delays urgent security fixes, which need an exception procedure;
• the new-version rule depends on correct dates in the metadata, as GitHub itself points out.

The other announcements

Help Net Security also describes the other three additions, which work on code and alerts:

• AI Scan checks every pull request for vulnerabilities in languages that rule-based scanning does not cover, including PHP, Shell and COBOL. It can also scan a whole repository on demand, reaching code that has already been merged;
• the GitHub Security extension for the Copilot app checks a developer’s changes before a pull request exists; together with GitHub Code Security it brings code scanning alerts into the app, AI Scan findings included;
• reachability analysis for Dependabot alerts checks whether the code actually calls the vulnerable function of a dependency: the call path can be inspected in GitHub and alerts can be ranked by it.

On fixes, GitHub’s Pierre Tempel pointed both to fix suggestions in pull requests and to Agentic Autofix, which remediates alerts in bulk across all GitHub tools and more than 70 partner tools.

Impact for European and Italian companies

npm is the main registry for JavaScript and TypeScript and feeds web applications, development tools and build pipelines in most companies that write software. A compromised package runs code on developer workstations and CI runners, where tokens, keys and access to production systems live. AI coding agents increase the number of installs made without human review.

For NIS2 entities, supply chain and development security is among the required measures: a filter with written rules, applied at install time, is a concrete and documentable measure, provided it really covers every place packages are installed from.

What to do now

1. If you use GitHub Enterprise, check GitHub’s documentation for the package firewall’s availability and requirements on your plan: the sources do not report them.
2. Define the policy: block known malware and critical vulnerabilities, set a waiting period for new versions and an exception procedure, with an owner, for urgent security patches.
3. Make the firewall mandatory: set the npm configuration centrally in repositories, CI runners, container images and AI agent environments. Where possible, prevent build networks from reaching the public registry directly, so the filter cannot be bypassed.
4. Keep the basic defences: versions pinned with the lockfile, installs with npm ci in pipelines and, where possible, install scripts disabled (--ignore-scripts).
5. Use reachability to set priorities, not to close alerts: a vulnerable dependency that is not called today may be called tomorrow.

How ARXDOME helps

ARX Sentry collects the software and process inventory of computers and servers: it helps you find where Node.js, npm and coding agents run, and therefore which machines must follow the policy. ARX Shield shows open vulnerabilities by machine and by package and, if a machine has installed a suspicious version, lets you isolate it from the network while checks are carried out.

Last updated: 29 October 2026