Prevention model

A dependency firewall is a policy enforcement point between your package managers and public registries. Clients install through it; the firewall applies your rules to every version list, download, and publish, and either serves the request or blocks it. This page is the mental model; for the request mechanics see Rule evaluation.

Prevention, not detection

Most dependency security tooling is detection: it scans what you already depend on and files findings after the fact. A firewall is prevention: the package that violates policy never enters a build to begin with.

The difference is when the control acts:

Both matter. A scanner covers what is already inside; the firewall decides what gets in from now on. The firewall's rules also consume the same kind of intelligence scanners use (vulnerability data, malware verdicts), but apply it at request time.

Before an advisory exists

Several firewall controls act without waiting for a vulnerability advisory. They use package age, artifact findings, install behavior, package origin, and publishing evidence rather than requiring a CVE:

• Package maturity delay. Delay new versions filters newly published releases for a configurable period, giving problems time to surface before builds can select them.
• Malware scanning. Block malware evaluates malicious-package intelligence and package-content analysis on downloaded and published artifacts.
• Install-script controls. Block install scripts matches npm and PyPI packages that declare code hooks which run during installation or build.
• Dependency confusion protection. Prevent dependency confusion keeps public packages from replacing package names already supplied by an internal upstream.
• Publishing-trust checks. Block trust downgrades matches npm releases published with weaker trust evidence than earlier releases of the same package.

Compared to a repository manager

Repository managers (private registries, artifact proxies) also sit between clients and public registries, primarily to host internal packages and cache external ones. The firewall shares that proxy position and adds policy as the first-class object:

• Rules, not just allowlists. Policy is expressed as rules over execution phases and selectors: age windows, vulnerability thresholds, malware scans, name patterns, upstream origin.
• Exceptions with expiry and reasons. Waivers are scoped, justified, and time-bounded, not permanent edits to a list.
• A decision log. A matching rule with logging enabled writes an entry answering who requested what, which rule fired, and why. See View logs.

The firewall also covers the repository manager's core moves where policy needs them: it proxies and caches upstreams, serves internal packages from internal upstreams, and receives publishes. Existing repository managers can sit behind it as upstreams.

One firewall per ecosystem

A firewall speaks its ecosystem's native protocol: npm registry, PyPI simple index, Maven repository layout, NuGet v3, GOPROXY, Conda channel. Clients need a URL change and a token, nothing installed. One namespace typically runs several firewalls for different ecosystems, each with its own rules and upstreams. See Ecosystems.

Who owns policy

The teams that feel a bad dependency first (platform, security) set policy centrally; developers keep using their normal tools. When a rule blocks something a developer needs, the resolution path is an exception, reviewed and time-bounded, instead of an ad-hoc registry bypass.

Related

• Concept: Rule evaluation, Upstreams and caching
• Getting started: Quickstart