Check every install at your web proxy, with no setup on any machine
Your company web proxy, such as Zscaler, Prisma Access or Squid, hands registry traffic to Dependency Firewall. Laptops, CI runners and AI agents keep their default registry settings, and every install behind the web proxy is checked against your rules.
How web proxy chaining works
1Create a proxy
Attach the firewalls it covers, such as your npm, PyPI and Maven firewalls. The Setup tab lists the registry hosts they serve.
2Forward those hosts
Your network team adds one forwarding rule on the web proxy and installs the Bytesafe CA certificate there. The Setup tab has snippets for Squid and a checklist for Zscaler.
3Install as before
Package managers keep asking for the public registry, such as registry.npmjs.org or pypi.org. The web proxy hands each request to the firewall for that ecosystem, which checks it against its rules.
Why it scales to a large organization
- Nothing to set up per machine
- No registry setting, access token or certificate on laptops, CI runners or agent sandboxes. A new machine behind the web proxy is covered from its first install.
- No reliance on each user's setup
- A stale .npmrc, a CI job with the public registry hardcoded or an agent that ignores its instructions still asks for the public registry, and the web proxy sends that request to the firewall.
- One place to change
- Attach another firewall and the host list on the Setup tab grows. Your network team updates one forwarding rule.
- The same rules and log
- Rules, exceptions and blocked-install messages apply unchanged. The log shows which proxy each install came through, and who was signed in when your web proxy sends that in a header.
Questions
Do developers need to change anything?
No. Package managers keep the public registry as their source, and nothing is installed on their machines. The Bytesafe certificate goes on the web proxy only.
What does our web proxy need?
It has to decrypt TLS to the package registries already, as Zscaler, Prisma Access or Squid with SSL bump do. It forwards the registry hosts to Bytesafe and trusts a Bytesafe CA certificate.
Which ecosystems does it cover?
Each package ecosystem whose firewall you attach, including the hosts of its upstreams, so an internal registry behind a firewall is routed too. Container (OCI) firewalls cannot be attached.
Does other traffic go through Bytesafe?
No. The web proxy forwards only the hosts on the Setup tab, and Bytesafe refuses requests for any other host.
Can we see who installed a package?
The log shows which proxy each install came through. If your web proxy sends the signed-in user in a header, such as X-Authenticated-User, the log shows that user too. It is the web proxy's claim and does not change permissions or rules.
Is it available now?
It is in beta. Contact us for early access.
All features
- Hold new releases until they have cooled offRelease delay
- Block malicious packagesMalware blocking
- Set the rules centrally for every team and agentCentralize firewall rules
- Developers request exceptions to policy and the security team decidesException workflow
- Block versions with known vulnerabilitiesVulnerability blocking
- Resolve internal names from your own registryDependency confusion
- Block packages by licenseLicense enforcement
- Run image pulls through the same rulesContainer firewalling
- Check every install at your web proxy, with no setup on any machineWeb proxy chaining, this page
Web proxy chaining is in beta
Tell us which web proxy you run, and we set up early access for your organization.