Protecting endpoints from malware with package firewall

[ahpook]

🏷️ Discussion Type

Product Feedback

💬 Feature/Topic Area

Supply chain security

Discussion Details

We've just launched a new package firewall capability in public preview and would love to hear your feedback. Docs are here: https://docs.github.com/enterprise-cloud@latest/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/protecting-endpoints-with-package-firewall

[ebickle]

This is an exciting new feature! We're currently testing it out, but already have some early feedback.

When minimum package age is enabled, we'd like the latest dist-tag (or potentially all dist-tags) to be re-mapped to the latest package that meets the minimum package age rule.

For example, if I type npm install undici I currently get:

npm notice undici: 6 versions blocked by package-firewall due to security policies (version cooldown). Request an override: https://github.com/enterprises//security/bypass-requests/package-firewall/new?ecosystem=npm&package=undici
npm error code ETARGET
npm error notarget No matching version found for undici@8.12.3.
npm error notarget In most cases you or one of your dependencies are requesting a package version that doesn't exist.

The latest version of undici (8.12.3) was published today and I'm testing with a 7 day cooldown period. In this scenario, instead of having latest point to the blocked 8.12.3, it would be a better user experience to point to 8.11.2. Obviously this would be a non-trivial algorithm; it would need to be semver aware as many packages maintain multiple major versions in parallel.

Without the dynamic dist-tag rewriting, we'd expect a very large number of override requests as developers type npm install for frequently updated packages they're adding for the first time.

[hfhbd]

Any chance to not use a PAT but a Fine-grained token?

[ahpook]

Yes, you can use a fine-grained PAT, it just needs to have Public / Read access to repos. I'll update the docs to be more clear about that.

[BenkhiraAhmedBaderEddine1]

i will try it and thanks for it

[ebickle]

Is there any way to combine the package firewall with GitHub Packages? We have a large number of internal-scoped NPM packages within the enterprise.

[ahpook]

It's a good question. Right now it's an either/or because we don't have configurable upstreams for the package firewall, it just pulls from npmjs.org. We do expect to add that kind of configuration as we head toward GA.

[ebickle]

Perfect, thanks!

At least with GitHub packages, what would help is to be able to configure specific scopes (i.e. our GitHub orgs) to route the upstream to GitHub packages and pass along the same token. That way the same GITHUB_TOKEN / PAT / etc can perform double duty - both the GitHub Packages auth and the package firewall auth.

[richards-ensono]

We've been testing this for a couple of days, it feels like a useful defence-in-depth control.

This is our feedback so-far:

1. PAT feels wrong - in this day and age when PATs being exfiltrated does so much harm (Shai-Halud/Miasma/Hades/etc.) training users to go create a PAT to authenticate their account feels wrong. This can be mitigated by using Artifactory although largely just pushes the problem around as instead we are authenticating with Artifactory at some level.
2. Token Admin is a tax on end-users - having to maintain a token in your env and update your .npmrc adds a level of token admin that end-users are pushing back on, the expectation is there should be some gh subcommand wrapper such as gh npm that checked the .npmrc config was correct set the envvar and then exec'ed npm.
3. Misleading Demo - a couple of users saw the demo on the announcement page and interpreted it being a strict allow list, thinking that they would have to put in a request every time a package needed to be updated.
4. Dependabot Mismatch - the current configuration for Dependabot allows for the cooldown to be bypassed in the event a version bump is required to mitigate a vulnerability - Package Firewall doesn't appear to implement the same semantics.
5. Conflict with GITHUB_TOKEN - GITHUB_TOKEN was already in use for several users for example with GitHub Copilot CLI one user accidentally replaced their GITHUB_TOKEN with the no-scope PAT; we've ended up using PACKAGE_FIREWALL_TOKEN instead to deconflict.

From a more positive angle:

1. The experience of adding an exception is clean and intuitive for end-users and administrators.
2. Integrating with CI has otherwise been uneventful which is always a plus.
3. As a capability it's something we had been looking to 3rd parties to solve, so having this part of the existing GitHub Enterprise suite is very welcome.

[ahpook]

This is great feedback, thanks @richards-ensono. With respect to the authentication concerns, how would you expect/prefer this to work?

Sorry about the demo, I wanted to show off the specific bypass request workflow but may have sped through it too fast.

Dependabot Mismatch - the current configuration for Dependabot allows for the cooldown to be bypassed in the event a version bump is required to mitigate a vulnerability - Package Firewall doesn't appear to implement the same semantics.

If I understand correctly, that was the point of the video embed, it's a version which is blocked by cooldown but the user wanted to bypass it for a security fix. (I'll attach a full, slow version on this comment)

package-fw-bypass.mov

[richards-ensono]

With respect to the authentication concerns, how would you expect/prefer this to work?

I suspect your constrained by how the npm executable works so to an extent this is outside of your control.

1. Personally I was comfortable configuring .npmrc and generating a PAT once I realised it was a minimal-scope PAT.
2. One developer we trialled this was frustrated because it didn't work, it turned out that he had a pre-existing GITHUB_TOKEN that wasn't valid.
3. A second developer outright questioned why we should use PATs at all when as an org we have been moving everything to GitHub Applications and discouraging the use of PATs.

We came up with two ideas how auth could work, both leverage gh which already has high adoption across the org:

1. A sub-command like gh package-firewall config --ecosystem=npm is responsible for getting a token via a GitHub-Managed GitHub App via Device Code or similar. Then configures .npmrc idempotently, ideally storing the token in ~/.config / $env:APPDATA with suitable filesystem perms and updating the profile / env accordingly. This way we have one cross-platform way that developers can configure their machines that follows security best practice.
2. A sub-command specifically for npm, i.e. gh npm add o11y@266.25.0 that transparently uses GitHub Package Firewall by setting NPM_CONFIG_REGISTRY, this keeps the token out of the env but requires developers to alias npm=gh npm - other package managers would need to be supported too.

---

Sorry about the demo, I wanted to show off the specific bypass request workflow but may have sped through it too fast.

That's not a problem at all, no need to apologise - it's difficult to know how people will interpret a feature through a demo.

---

Dependabot Mismatch - the current configuration for Dependabot allows for the cooldown to be bypassed in the event a version bump is required to mitigate a vulnerability - Package Firewall doesn't appear to implement the same semantics.

If I understand correctly, that was the point of the video embed, it's a version which is blocked by cooldown but the user wanted to bypass it for a security fix. (I'll attach a full, slow version on this comment)

I don't think I explained myself well, and it's possible I've mis-understood how Dependabot or Package Firewall work - we would have expected the two products (Dependabot and Package Firewall) to support the same policy semantics. From my testing the semantics are different:

• Dependabot: Security Update PRs will be created even if the fixed version is within the cooldown period; Version Updates will be created after the cooldown has been applied. This aligns to both good security policy and general best practice in updating outdated packages via CI/CD.
• GitHub Package Firewall: Always applies the configured cooldown, regardless of security updates. This means that if Package Firewall is configured in CI we need to go through two layers of approval (PR approval, and Dependency Approval), if it's not configured in CI then the next developer who runs npm i will have to request approval before they can start using it. For something like Next.js this would often mean requesting 10+ exceptions.

To paraphrase our policy:

• version updates to dependent packages should be applied weekly;
• version updates must apply a 5-day cooldown;
• security updates must be applied promptly (i.e. CVSS > 7 = 24h, etc.)

We can model this policy almost perfectly in Dependabot, but not in Package Firewall (yet). I appreciate this is in preview, keen to provide our use cases to help you shape this.

[ebickle]

A concern that was raised internally: "We have people who install packages who aren't software developers, will they need a GitHub user license?" A key example is Python, which is heavily used in the AI, data science, and analytics spaces; it could extend to NPM as well.

We could create a single "low permission" PAT and use scripts to deploy it to people's workstations, but that creates a risk of the token being exfiltrated if malware ever runs.

Something that would work better for us is a REST API that can be called from a GitHub App to issue short-lived temporary tokens that are scoped only to the package firewall. When a user logs in to their machine, we can have a script reach out to a custom internal API, which in turn uses the GitHub App to request a temporary package firewall token. The token can be dropped on the users' machine (e.g. as an environment variable). The token lifetime should be 'just' long enough to cover the majority of single user login events; 48 hours might be a good default, with our script attempting a refresh every 24 hours or so.

That way, the risk of an exfiltrated token is guaranteed to be scoped to the package firewall only (no "oops, I forgot it had access to repos..") and any "financial impact" of a bad guy trying to hit the package firewall is limited only to that short lifetime.

Most other package firewall products use the "static API Key / access token" approach (similar to a PAT); having a short-lived stateless API-driven option would be a huge value-add and make enterprise adoption easier.

Edit: With this approach, it should only grant access to "public" packages; PAT auth would still be needed for any integration over to internal/private GitHub Packages.

[derkoe]

Tried this with our GitHub Enterprise with data residency (with a xxx.ghe.com address) and it did not work.

When I try the setup it says

Not Found - GET https://package-firewall.githubapp.com/npm/enterprises/xxx/http-server - enterprise not found

Is this available on GHE with data residency?

[ahpook]

@derkoe we believe this should be working and will investigate why you are seeing this error.

[jurre]

On ghe.com the URL should be: package-firewall.<enterprise>.ghe.com/npm

You should be able to grab that from the policy config page, please let me know if you see something else

[derkoe]

Thx - it works with this in .npmrc and `GITHUB_ENTERPRISE set:

registry=https://package-firewall.${GITHUB_ENTERPRISE}.ghe.com/npm/enterprises/${GITHUB_ENTERPRISE}
//package-firewall.${GITHUB_ENTERPRISE}.ghe.com/npm/enterprises/${GITHUB_ENTERPRISE}/:_authToken=${GITHUB_TOKEN}

[maxkrivich]

This looks super cool! 🚀 Are there plans to support license-based policies, such as blocking packages with licenses our organization doesn’t allow? Also, is support for PyPI on the roadmap, and what would be the timelines?

[jurre]

A license policy is something that we have considered, although a question is if a license always needs blocking at install l-time or if catching them at PR time with https://github.blog/changelog/2026-10-16-open-source-license-compliance-generally-available/ is a better experience. Curious to hear your considerations.

Python support is next up, will make sure to share a timeline here soon!

[maxkrivich]

ohh, I missed that announcement. Thank you! ❤️