Supply chain
Typosquatting
Typosquatting is a supply-chain attack where an attacker publishes a package under a name close to a popular one so that a mistyped or confused install pulls the attacker's code.
What it means
Typosquatting is the registration of a name that a person is likely to type by mistake. The term comes from domain names: CAPEC-630 describes an adversary who registers a domain that differs from a trusted one by at least one character.
In package registries the target is the install command. An attacker publishes a package whose name sits one slip away from a popular one and waits for developers to mistype or otherwise confuse the two.
Registries close the cheapest variants:
- npm strips punctuation from a new name and rejects it when the result matches an existing package, and says it detects and blocks other typosquats too.
- PyPI, following PEP 503, treats names that differ only in case or in runs of dots, dashes, and underscores as the same project.
A swapped letter, a dropped character, or an added word falls outside the published rules, and such packages have reached both registries more than once.
Why it matters for AI-written code
A person typing an install command usually glances at the name. A coding agent can write the import, add the install line, and run it in one step, so often no one reads the name before the registry answers.
The OpenSSF guide for AI code assistants asks them not to add dependencies that may be malicious or hallucinated and to install through the official package manager rather than by copying snippets. The guidance holds only as long as the assistant follows it, and look-alikes with a changed character have still reached PyPI and npm.
What remains is the project’s own install path:
- whether the lockfile pins what was reviewed;
- how young a package may be before it is accepted;
- whether a freshly resolved package may run code during installation.
Where it appears in Enji Guard
Enji Guard does not treat a look-alike package as a category of its own. It belongs to the dependency hygiene audit, one of the recurring checks that keep a project in the green zone.
The audit inventories dependency sources across manifests, lockfiles, Dockerfiles, CI workflows, package-manager and registry config, install scripts, generated clients, and SBOMs. A package that an agent’s install line wrote into one of those files is on the inventory whether or not anyone noticed it. Because the audit reruns regularly, it is inventoried again on the next run.
How Enji Guard helps
The dependency hygiene audit reads every install, CI, build, release, deploy, and bootstrap path as text and records the controls that decide what a wrong name can do:
- frozen or locked install mode and lockfile use;
- package-age gates and registry quarantine or private mirrors;
- lifecycle-script controls.
A privileged acquisition path that can resolve fresh public packages and run unreviewed package code while those controls are missing is rated critical. That is the exact combination a typosquatted package needs: a mistyped name resolves to whatever was published under it, and its install script runs before anyone looks.
When OSV-Scanner runs, its advisories can include the malicious-package reports that OpenSSF publishes in OSV format, so a look-alike that was already reported shows up as an advisory.
The audit does not compare package names with a popularity list and does not stop an install. It is read-only and never changes manifests or lockfiles.
The result is a finding with the path, the missing control, and a safe next action. A vulnerable package with a proven safe target version is a candidate for the dependency updates improvement, which prepares an issue or a reviewable update; a missing control, or a package that has to be removed, stays with the team.
Enji Guard