Topic starter
20/08/2026 5:55 pm
TL;DR: Dependency confusion in npm let public code stand in for private-looking names, according to Corgea. Package resolution then becomes a trust decision, and build systems can run untrusted code before application controls see it.
Editorial analysis by NHI Mgmt Group, based on content published by Corgea: “oob.moika.tech npm campaign used dependency confusion to profile developer environments”.
Key questions
Q: Why does dependency confusion often become a secret-exposure event?
A: Because install-time code runs in environments that already hold secrets, including CI variables, developer tokens, and deployment credentials.
Q: How should teams reduce risk from malicious npm package installs?
A: Treat package installation as a controlled operation, not an implicit trust event.
Q: What breaks when internal npm scopes are not locked to a private registry?
A: Package resolution can fall back to public code that only looks internal, which means a build can execute untrusted software before any application control sees it.
Practitioner guidance
- Fail closed on internal package scopes Bind internal namespaces to private registries and block public fallback for packages that are intended to be internal only.
- Disable lifecycle scripts by default Use npm ci --ignore-scripts in CI and allow install-time scripts only for reviewed packages with a documented build need.
- Inventory exposed package scopes and versions Search lockfiles, manifests, caches, and build logs for the affected scopes and any republished versions tied to the campaign.
Bottom line: Dependency confusion turns package resolution into a security control, because public code can satisfy private-looking names when registries are not locked down.
Glossary terms: Dependency Confusion, Postinstall Script, Build-Time Trust Boundary, Registry Scoping
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
20/08/2026 6:36 pm
Build-time trust is now a governance boundary: dependency resolution belongs in the same control conversation as authentication and secrets handling. Once package managers can choose public code for private names, the supply chain no longer has a reliable trust boundary. Practitioners should treat namespace resolution as a privileged decision point, not an operational convenience.
A question worth separating out:
Q: Should organisations prioritise registry scoping or secrets rotation first after this kind of issue?
A: Registry scoping comes first because it removes the trust failure that lets public packages stand in for private ones. Secrets rotation is then the containment step after exposure is suspected. Without fail-closed resolution, rotation alone only cleans up the aftermath of the same control gap.
👉 Read our full editorial: Dependency confusion in npm shows how build-time trust breaks