Build fluency in the vocabulary of preventing a malicious package from impersonating an internal one.
0 / 5 completed
1 / 5
At standup, a dev mentions an attack where a malicious public package is published under the exact same name as a company's internal private package, tricking a misconfigured build into installing the malicious public version instead. What is this attack called?
Dependency confusion is an attack where a malicious actor publishes a public package under the exact same name as a company's internal private package, tricking a misconfigured build system into installing the malicious public version instead of the intended private one. A normal, legitimate internal package update comes from the company's own trusted internal registry, not from an external public source impersonating it. This attack specifically exploits an ambiguity in how a build system decides which registry to pull a same-named package from.
2 / 5
During a design review, the team wants their build system to always resolve an internal package name from their private registry first, with no fallback to a public registry for that same name. Which capability supports this?
Registry scoping configures the build system to always resolve an internal package name from the intended private registry first, with no fallback to a public registry for that exact same name. Letting the system resolve from whichever registry responds first, public or private, is precisely the ambiguity a dependency confusion attack exploits. This explicit scoping closes that ambiguity, ensuring an internal package name can only ever resolve to the company's genuine internal source.
3 / 5
In a code review, a dev notices every internal package name is prefixed with the company's own reserved namespace, like an organization-specific scope, making an exact name collision with an unrelated public package far less likely. What does this represent?
Namespacing internal packages under the company's own reserved scope makes an exact name collision with an unrelated public package far less likely in the first place, since the reserved scope isn't something an outside attacker can typically claim. Publishing under a generic, unscoped name leaves the door open to exactly the kind of collision a dependency confusion attack depends on. This namespacing is a proactive, preventive measure that reduces the attack's viability before it ever reaches the registry-resolution stage.
4 / 5
An incident report shows a build pipeline pulled a malicious package from a public registry because an internal package of the exact same name existed only in the private registry with no explicit registry priority configured. What practice would prevent this?
Explicitly configuring the build system's registry priority or scoping ensures an internal package name can never accidentally resolve from an untrusted public registry, closing the exact gap this incident exploited. Leaving the resolution order unconfigured and dependent on whichever registry responds first is the root misconfiguration that makes a dependency confusion attack possible. This explicit configuration is a foundational, low-effort control against this specific and well-documented supply-chain attack.
5 / 5
During a PR review, a teammate asks why the team explicitly scopes and namespaces every internal package instead of trusting that their build system will naturally prefer the intended private registry by default. What is the reasoning?
A build system with no explicit registry priority configured can genuinely be tricked into pulling a same-named malicious package from an untrusted public registry instead of the intended private one. Explicit registry scoping and reserved-namespace naming both close off that ambiguity from two complementary angles. The tradeoff is the upfront configuration and process discipline needed to consistently apply both practices across every internal package a company publishes.