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.

When the firewall actsCopy Anchor Link

Most dependency security tools scan what you already depend on and file findings afterwards. A firewall acts earlier. A package that breaks your policy is stopped at install time and never reaches the build.

The difference is when the control acts:

Both matter. A scanner covers everything already inside; the firewall decides what gets in from now on, and keeps checking what it let in (after a package is served). 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 existsCopy Anchor Link

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-time code execution. Block install-time code execution matches npm lifecycle scripts, PyPI source-build hooks, and Composer plugins.
• 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.

After a package is servedCopy Anchor Link

A rule decides with what is known at the moment of the request. An advisory or malware report published the next day does not change that decision for the builds that already have the package.

So the firewall keeps checking what it served. Every day it looks up each package version served in the last 30 days in the latest advisory and malware data, using the name and version. A team you choose gets an alert when a new vulnerability or malware report turns up, or when a known vulnerability becomes critical or exploited. What was already known when the package was served does not trigger an alert.

Packages already in a build stay there until someone upgrades them. The alert names the package version and the firewalls that served it, so you know what to upgrade, and a webhook lets your own tooling start that work. Your rules keep the version out of new installs.

This sees only what passed through the firewall, which is less than a scanner covers. It also needs no setup in your repositories. See Get risk alerts after download.

Compared to a repository managerCopy Anchor Link

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 ecosystemCopy Anchor Link

A firewall speaks its ecosystem's native protocol (npm's registry API, PyPI's simple index, Maven's repository layout, and so on), so existing clients need only a URL change and a token, nothing installed. One namespace typically runs several firewalls, one per ecosystem, each with its own rules and upstreams. See Ecosystems for the full list and each client's setup.

Who owns policyCopy Anchor Link

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.

RelatedCopy Anchor Link

• Concept: Rule evaluation, Upstreams and caching, Observability
• How-to: Get risk alerts after download
• Getting started: Quickstart