BytesafeDependency Firewall

Prevention model

The preventive control model. How a dependency firewall differs from scanners and from repository managers.

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:

Prevention
Package publishedpublic registry
Installdeveloper or CI
Dependency firewallrules evaluated
Package enters buildallowed by policy
Install failsblocked, log entry written
Scanner finds issueticket, PR, later

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.

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. Every rule match is a log 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.

On this page