GitHub’s new package firewall ships with a minimum package age of one day. I would set it to a week or more on any pipeline that installs dependencies without a person watching.
The firewall entered public preview for GitHub Enterprise Cloud customers on October 20. According to GitHub’s changelog, it sits between endpoints or internal registries and the upstream package registries, and inspects both metadata requests and package downloads as an install-time policy gate. GitHub says the case for it is a flood of malware attacks that exploit systems at package installation time, and that agents and CI runners are particularly exposed because they install dependencies to finish a task or build with no human in the loop.
GitHub’s documentation lists the controls. Block known malware checks the GitHub Advisory Database and defaults to on. Block vulnerability advisories defaults to critical only. Block attestation downgrades and block newly introduced install scripts both default to on. Minimum package age accepts a value from 1 to 365 days, 0 disables it, and the default is 1 day. Today the firewall supports only npm.
The malware and vulnerability controls depend on someone having already published an advisory. The cooldown works on a package nobody has examined yet. GitHub’s documentation describes its purpose as allowing time for threats to be discovered before you install them. Time is the whole mechanism, so the length of the window decides how much protection it gives.
A day is a short window. A poisoned release published on a Friday afternoon clears a one-day cooldown on Saturday, when fewer people are watching and your CI runners are still building. I would pick a value from what your own detection and review need. If your team takes several days to read an advisory and decide, a window shorter than that adds little. For build systems and coding agents that run unattended, I would start at seven days and shorten it only with evidence.
The strongest objection is that waiting delays fixes. A new version may close a vulnerability that is being exploited, and a cooldown holds it back. GitHub anticipates this. Its documentation uses exactly that example, a new package version with a security fix blocked by the minimum age policy, and describes an exception workflow. The npm output includes a URL for requesting an override, and enterprise administrators and security managers review the requests. A security fix you need today goes through a short human decision. A routine version bump from an unreviewed publisher waits. That trade favors the cooldown.
A second objection is that old malware is still malware. A release that evades detection can outlast any window. That is true, and it is why the cooldown belongs beside the advisory, attestation and install-script checks. Each control covers a different way a bad version reaches a build.
The setup also has gaps to close by hand. The firewall only protects endpoints that use it. GitHub’s guidance for Artifactory says to exclude remotes that fetch packages directly from the public npm registry so they cannot bypass the firewall, and the same applies to any developer laptop or agent sandbox whose .npmrc still points at the public registry. Support for Artifactory is experimental, the whole service is in public preview, and GitHub says it will be charged by metered usage once it reaches general availability. Those facts belong in the decision about where to start.
My advice has three parts. Route CI runners and coding agents through the firewall first, since they install the most without review. Set the minimum package age to match your response time, and write that number down with the person who owns it. Staff the exception queue, because a cooldown with a slow override process invites people to switch it off.
The default of one day is a reasonable place for a vendor to start a preview. Your policy should be set from how fast your team can catch a bad release, and for most teams that is longer than a day. Earlier coverage of attacks that spread through build systems is in our report on GhostAction, and a related argument about keeping automation off the public internet is in our opinion on self-hosted CI servers.
Source: GitHub changelog: package firewall in public preview
