GitHub introduced Package Firewall in public preview for Enterprise Cloud, inspecting metadata requests and package downloads. Initial support is npm-only. Free preview use is distinguished from planned usage-based billing at general availability. GitHub official announcement
Install-time checks add a control point before a malicious dependency executes. An agent or CI job using another registry, direct URLs, or an existing cache may not follow the intended path.
On this page
Dependency installation is an execution boundary
Dependencies can affect a system before the application itself starts. Installation may execute package scripts, and build tools can retrieve additional files. CI runners and coding agents perform these steps automatically as part of completing tasks. Reviewing the final code diff does not necessarily reveal behavior that already occurred during installation. Install-time policy adds a control at that earlier boundary.
A package check provides another opportunity to identify malicious signals and enforce policy; it does not prove every subsequent execution safe. Excessive filesystem or network authority can remain a problem even for a package that appears legitimate. Review the dependency-fetch path and the permissions of the build environment together as separate parts of supply-chain protection.
Metadata and package files must follow the intended route
An installer commonly retrieves version and dependency metadata before downloading the package archive. Partial configuration can send one request through inspection while another goes directly upstream. Check the actual request paths on workstations, CI hosts, and agent environments. Where an internal mirror is used, include the mirror’s upstream downloads in the review rather than stopping at the endpoint configuration.
Treat cached packages separately. Do not assume a download gateway automatically reinspects files already present in a local cache. Direct URLs and alternative repositories can also take a different path. Evaluate against the current npm support scope and avoid presenting other language ecosystems as protected merely because the same project uses the firewall for npm.
Exceptions need a defined scope and lifetime
A new version containing an urgent fix might encounter a cooldown policy. Decide who reviews the evidence, approves an exception, and removes it afterward. Record the reason and narrow the exception to the intended package and version. This reduces the risk of a temporary need becoming a broad allowance for all future releases.
Compare clean-cache and cached installations on representative projects, recording build success and delay. Review whether blocked cases match the intended policy. An outage workaround that simply routes everything directly upstream can remove the inspection boundary, so approve recovery behavior in advance. Budget preview evaluation separately from the announced usage-based charging planned for general availability.
Scope an npm trial
- Review registry configuration, direct downloads, and caches.
- Define approval, exception, and audit handling for legitimate blocks.
- Assess preview limitations and future billing conditions.
Changing installation paths can affect build reliability. Begin with representative projects and apply policies gradually.
Announcement reference date: 2026-10-20 · Checked: October 24, 2026
.jpg){kind=link}