What is a dependency firewall?
How the Bytesafe Dependency Firewall works, what it protects against, and where it fits next to SCA tools and repository managers.
A dependency firewall is a policy checkpoint between your package managers and public registries. Instead of installing packages directly from npmjs.org or PyPI, your tools install through a firewall endpoint. The firewall fetches packages from its configured upstreams, evaluates your rules, and either serves the package or blocks it.
Think of it as a network firewall for dependencies: traffic still flows through, but rules decide what is allowed, and exceptions document the cases that should pass anyway.
The decision happens at install time, before code reaches a developer machine or CI runner. That is the difference from scanners that report on what you already installed.
How it works
Each firewall endpoint proxies one package ecosystem. A typical setup has one firewall per ecosystem, or several per ecosystem when teams need different policies.
A firewall consists of:
- Upstreams. The registries the firewall fetches from, such as
registry.npmjs.orgor a private registry. Upstreams can be marked internal to protect your own package names, and cached so repeat requests are served from the firewall's own copy. - Rules. Policy statements evaluated against every request. A rule combines an execution phase (version resolution, download, or upload), a selector that decides which packages it applies to, and an effect (block, log, or both).
- Exceptions. Scoped waivers attached to a rule. When a rule blocks a package you need anyway, an exception allows that specific package through, with a documented reason and optional expiration.
- Logs. Every rule match is recorded: who requested what, which rule fired, and whether the request was blocked.
When a rule blocks, the firewall does not serve the package, and the package manager reports a failed install. What the client prints depends on the ecosystem and on which execution phase blocked the request. Investigate a blocked install shows how to trace an error back to the rule that caused it.
What you can enforce
Rules can target package metadata, security signals, publish timing, and request context. Common policies include:
- Delay newly published versions, so the ecosystem has time to catch malicious releases before your builds pick them up. See Delay new versions.
- Block packages with known vulnerabilities above CVSS or EPSS thresholds. See Block vulnerable packages.
- Block packages flagged as malware.
- Block deprecated, yanked, or unlisted releases.
- Block packages by license, with named license sets as deny or allow lists. See Enforce license policy.
- Block publishes of packages containing leaked credentials. See Scan for secrets on publish.
- Protect internal package names against dependency confusion by resolving them only from internal upstreams.
Supported ecosystems
| Ecosystem | Clients |
|---|---|
| npm | npm, yarn, pnpm, Bun |
| PyPI | pip, uv, Poetry |
| Maven | Maven, Gradle |
| NuGet | dotnet, NuGet.exe, Visual Studio |
| Go | go modules via GOPROXY |
| Conda (beta) | conda, mamba, micromamba |
See Ecosystems for setup instructions.
Where it fits
- Compared to SCA scanners. A scanner tells you after the fact that a vulnerable package is in your tree. The firewall stops it from entering. The two answer different questions, and many teams run both: the firewall as the gate, a scanner for inventory and depth.
- Compared to repository managers. Repository managers such as Artifactory and Nexus mirror and host packages. The firewall does not host packages of its own; it applies policy to requests as they pass through. It can sit in front of or beside a repository manager. See Integrate with repository managers.
Next steps
Follow the quickstart to set up your first firewall, or read rule evaluation for the mental model behind rules, selectors, and exceptions.