Dependency Confusion Prevention
Block dependency confusion attacks where a public package with the same name as an internal one gets installed instead. Upstream priority rules make internal packages always win.
Package managers can be tricked into fetching the wrong source
Attackers register the same package name on a public registry with a higher version number. Package managers that check public registries fetch the attacker's version instead of the internal one.
Internal package names are visible in build artifacts
Lockfiles and build logs reveal internal package names. Attackers register them on public registries with higher version numbers.
Package managers resolve from the highest version, regardless of source
Without upstream priority rules, the public version wins even when a private version exists.
What your team gets
Internal packages always resolve from your private registry
Upstream priority rules make your private registry the first source checked, and it always wins for internal package names.
No configuration required per developer or project
Rules live in the firewall. Every developer and pipeline inherits the protection automatically.
Works across all supported ecosystems
Covers npm, Maven, PyPI, NuGet, Go and OCI.
How Dependency Firewall handles this
Dependency Firewall's upstream priority rules prevent internal packages from resolving from a public registry, regardless of version number.
- Upstream priority configuration per package or namespace
- Blocks public resolution for internal package names
- Works across npm, Maven, PyPI, NuGet, Go and OCI
Built for the teams involved
- Security teams
Configure upstream priority once. Dependency confusion protection applies to all installs without developer action.
- Developers
Internal packages install as expected. No per-project configuration required.
What changes in practice
Internal packages cannot be substituted by public ones
Upstream rules enforce that internal names always resolve from your private registry.
No per-project configuration needed
Every install through the firewall inherits the rules.
Questions about this use case
Does this require changes to how developers reference internal packages?
No. Internal package names continue to work as before. The firewall handles the routing.
Does this work with scoped npm packages?
Yes. Rules can be applied at the namespace or scope level.
Talk to us about dependency confusion prevention.
We can walk through the product fit for your environment and where each Observer product fits.