Dependency Confusion Prevention
Internal package names resolve from your private registry, every time. Dependency Firewall checks upstreams in the order you set, so a public package with the same name and a higher version number is blocked.
Developer laptop or CI runner
npm install acme-auth-client@^2.1.0
Dependency Firewall
Internal package names resolve from the private registry only
Private registry
Artifactory, priority 1
acme-auth-client 2.1.4
Published by your platform team
Public registry
registry.npmjs.org, priority 2
acme-auth-client 99.0.0
Published 2 days ago by an unknown account
Public registries accept any unclaimed name
If an internal package name is free on the public registry, anyone can publish it there. A client that looks in both places can pick the public copy because its version number is higher.
- Internal names are easy to find
- Lockfiles, error messages and published front-end bundles contain the names of internal packages.
- Mixed sources resolve by version number
- pip with --extra-index-url, and virtual repositories that merge public and private sources, take the highest version they find.
- Every project has its own config
- Each .npmrc and pip.conf has to be right. One wrong file is enough.
How it works with Dependency Firewall
1Add your private registry as an upstream
Artifactory, Nexus, GitLab, GitHub Packages or Azure Artifacts, next to the public registry.
2Set the priority
Internal names and namespaces resolve from the private upstream. Public copies of those names are blocked.
3Developers change nothing
Package names in manifests stay the same. The firewall decides where each one comes from.
One registry URL for both sources
Developers and pipelines point at the firewall only. It fetches internal packages from your private registry and everything else from the public one, so no project lists two sources.
# npm, Yarn and pnpmnpm config set registry https://registry.bytesafe.dev/r/<firewall-id>/# pippip config set global.index-url https://registry.bytesafe.dev/pypi/<firewall-id>/simple/# Go modulesexport GOPROXY=https://registry.bytesafe.dev/go/<firewall-id>/,direct
Who works with it
- Security teams
- Set the upstream priority once. Every install through the firewall follows it.
- Developers
- Internal packages install as before, with no per-project configuration.
- Platform engineers
- Retire the extra-index and scope settings spread across repositories.
Questions
Do developers need to change how they reference internal packages?
No. Package names stay the same. The firewall handles where they resolve from.
Does this work with scoped npm packages?
Yes. Rules can match a namespace or scope as well as a single package name.
Which ecosystems are covered?
Every supported package ecosystem, including npm, PyPI, Maven, NuGet, Go, Cargo, RubyGems and Composer.
More Dependency Firewall use cases
All use cases- Malware BlockingBlock malicious packages and account-takeover payloads before anyone installs them.
- Vulnerability Blocking at InstallStop packages with known CVEs at the registry before they land in a build.
- CI/CD Pipeline ProtectionRoute CI/CD pipelines through Dependency Firewall and enforce the same rules on every build.
- Zero-Day Safety DelayHold newly published versions for a configurable window before developers can install them.
- License Enforcement at InstallBlock packages with disallowed open source licenses before they land in a build.
Try it on one registry
Point one package manager at Dependency Firewall and check the log after the next install. The trial runs 14 days.
