Package firewalls: controlling dependency intake before installation

Dated development · October 20, 2026

GitHub adds an install-time checkpoint

GitHub introduced a package firewall in public preview for Enterprise Cloud. Administrators can route npm metadata and package downloads from Actions runners, coding agents and other endpoints through a controlled proxy. The preview supports cooldown periods, malware and vulnerability checks from the GitHub Advisory Database, and supply-chain checks such as attestation downgrades.

The current scope matters: this is an npm-only preview, not a universal package-security layer. Platform teams should evaluate it against representative lockfiles, registries and failure modes before making it a production dependency.

Control architecture

Put policy between the endpoint and registry

1. Route package traffic. Configure CI runners and agent sandboxes to use the firewall as their registry endpoint.
2. Authenticate workloads. Give each runner class or agent pool a traceable identity; avoid shared developer tokens.
3. Evaluate before delivery. Apply cooldown, advisory, malware and provenance policies before the artifact reaches the package manager.
4. Verify after delivery. Preserve lockfile integrity and signature or attestation checks in the build.
5. Contain installation. Execute lifecycle scripts with minimal filesystem, network, credential and secret access.
6. Record the decision. Retain policy version, artifact identity, outcome and any exception for incident response.

Layered policy

Use independent signals for independent risks

A cooldown period reduces exposure to just-published malicious versions, while advisory and malware checks address known evidence. An attestation-downgrade rule detects when a package version loses provenance that previous versions carried. These controls answer different questions and should remain visible as separate policy results.

Keep exact-version lockfiles, integrity hashes and internal allowlists where appropriate. Generate an SBOM from the resolved build, scan the artifact that will be deployed and monitor for advisories after release. No intake decision stays complete once new evidence appears.

Governance

Exceptions must be narrow, logged and temporary

False positives and emergency restores make an exception path necessary. Scope a bypass to the exact package, version, environment and requesting workload. Require an owner, reason, reviewer and expiry. A global “allow anyway” switch quietly turns the firewall into an optional warning system.

Keep a break-glass path for registry or firewall outages, but separate it from normal credentials and log its activation. Builds produced during bypass should be reviewed and, where feasible, rebuilt after normal policy is restored.

Agent-aware development

Assume the requester can be persuaded

A coding agent can add a dependency because generated code imports it, a tool response recommends it or untrusted repository text instructs the agent to install it. The package firewall should therefore sit outside the agent's authority. The agent may request an artifact; it must not rewrite the policy, approve its own exception or retrieve a reusable bypass credential.

Run agent package installation in an isolated workspace with task-scoped credentials, restricted egress and no production secrets. Surface denied-package reasons to the developer without exposing sensitive policy internals, and require human review when the agent proposes an alternative package.

Practical rollout

A seven-step adoption sequence

1. Inventory package managers, registries, mirrors, runner types and agent environments.
2. Measure baseline installs and cache behavior before changing endpoints.
3. Start in observation mode with representative repositories and cold caches.
4. Define policy owners, exception criteria, expiry and incident escalation.
5. Enforce first on ephemeral CI and coding-agent pools.
6. Test firewall failure, upstream failure and documented break-glass recovery.
7. Review denied requests, exception aging and bypass builds on a fixed cadence.

The durable improvement is a controlled dependency-intake path: packages cross into engineering environments only after an accountable policy decision, then execute inside a boundary designed for compromise.