Learn the vocabulary of malicious packages published under misspelled names of popular dependencies.
0 / 5 completed
1 / 5
At standup, a dev mentions attackers publishing a malicious package under a name that is a common misspelling of a popular package, hoping a developer will typo the install command and pull in the malicious code instead. What is this attack called?
Typosquatting is exactly this: attackers publish a malicious package under a name that is a common misspelling or lookalike of a popular package's name, hoping a developer will typo an install command and pull in the malicious package instead of the legitimate one. A hash collision is an unrelated hash-table concept about two keys sharing a bucket. This mimic-a-popular-name approach is exactly why typosquatting is a persistent supply-chain risk in public package registries.
2 / 5
During a design review, the team adds automated dependency-name verification against a known-package allowlist to its build pipeline, specifically because catching a misspelled package name before installation avoids a typosquatted package ever reaching production. Which capability does this provide?
Automated dependency-name verification here provides early detection of typosquatted dependencies before they're installed, since comparing every dependency name against a known-package allowlist catches a misspelled, lookalike name before it can pull in malicious code. A build pipeline with no dependency-name verification at all installs whatever name is listed, typo and all, without any check. This catch-the-misspelling-before-install behavior is exactly why dependency-name verification is a standard supply-chain defense.
3 / 5
In a code review, a dev notices a build pipeline installs every dependency name listed in a manifest with no verification against a known-package allowlist, letting a single typo silently pull in whatever package happens to exist under that misspelled name. What does this represent?
This is a missed opportunity to catch typosquatting, since verifying dependency names against a known-package allowlist would catch a misspelled, lookalike name before it silently pulls in malicious code. A cache eviction policy is an unrelated concept about discarded cache entries. This no-verification pattern is exactly the kind of supply-chain gap a reviewer flags once a single typo could pull in an unverified package.
4 / 5
An incident report shows a production build silently included a malicious package, because a manifest had a single misspelled dependency name and the build pipeline installed it with no verification against a known-package allowlist. What practice would prevent this?
Adding dependency-name verification against a known-package allowlist flags and blocks a typosquatted name before installation. Continuing to install every dependency name listed in the manifest with no verification regardless of how easily a single typo could pull in a malicious package is exactly what caused the issue described in this incident. This allowlist-verification approach is the standard fix once a manifest is confirmed capable of silently installing an unverified package.
5 / 5
During a PR review, a teammate asks why the team adds automated allowlist verification against typosquatting instead of simply asking every developer to type dependency names carefully. What is the reasoning?
Automated allowlist verification catches a misspelled name reliably every time regardless of human attention, while asking developers to type carefully depends entirely on individual vigilance and will eventually miss a typo, especially under time pressure or when copy-pasting from an untrusted source. This is exactly why automated verification is the standard defense against typosquatting, while careful typing alone is never considered sufficient.