Resolve internal names from your own registry
A public package with the name of one of your internal packages is never served. When an upstream you mark as internal knows a package, Dependency Firewall serves its versions from internal upstreams only.
How dependency confusion prevention works
1Mark your private registry as internal
Add Artifactory, Nexus, GitLab, GitHub Packages or Azure Artifacts as an upstream next to the public registry, and turn on Internal registry.
2Internal names resolve internally
When an internal upstream knows a package, its versions come from internal upstreams only. A public copy is left out, whatever its version number.
3Reserve the names you have not published
A rule blocks your prefix from external upstreams, for example @acme/*. A name under it can then only come from an internal upstream.
What changes for internal packages
- Each project lists one source
- Developers and pipelines point at the firewall only. No project lists two sources, and package names in manifests stay the same.
- A higher version number does not win
- A public 99.9.9 is never merged with your internal 1.4.0, so a client cannot pick it.
- Any naming convention
- The rule matches whatever marks your internal packages: an npm scope, a Maven group prefix or a Go module path prefix.
- Check it in the log
- A request for an internal package is logged with the upstream that served it.
{ "id": "acme-scope-internal-only", "executionPhase": "versions", "selector": { "packageName": "@acme/*", "upstreamType": "external" }, "ruleEffect": { "block": true, "log": true }}Questions
Do developers need to change how they reference internal packages?
No. Package names stay the same. The firewall decides where each one comes from.
Does this work with scoped npm packages?
Yes. A rule 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.
What about a name our registry no longer serves?
Marking the registry as internal covers the names it serves today. The rule for your prefix covers the rest, such as a package you deleted or a prefix you have reserved.
More features
- Hold new releases until they have agedRelease delay
- Block malicious packagesMalware blocking
- Set the rules centrally for every team and agentCentralize firewall rules
- Block versions with known vulnerabilitiesVulnerability blocking
- Block packages by licenseLicense enforcement
- Run image pulls through the same rulesContainer firewalling
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.