A Go module typosquat is a malicious package name that differs by a small typing error from a legitimate dependency. It relies on human mistakes or compromised mirrors to divert imports into attacker-controlled code while preserving enough compatibility to avoid obvious functional failure.
Expanded Definition
A Go module typosquat is a dependency name engineered to look like a legitimate module path while changing only a character or segment that a developer, build system, or mirror might miss. In Go ecosystems, this matters because module resolution can happen automatically during builds, and a deceptively similar path can be fetched before the mistake is noticed. The risk is not only human typing error but also dependency confusion across internal and public module sources.
In NHI and software supply chain governance, the term sits at the intersection of package integrity, trust in registries, and credentialed access to source control or artifact systems. Guidance varies across vendors on how much module path similarity alone should be treated as malicious, but the operational signal is consistent: a typosquat is designed to capture imports that were intended for a trusted dependency. The NIST Cybersecurity Framework 2.0 reinforces the need to identify and manage software supply chain risks before code is promoted into production.
The most common misapplication is treating typosquats as simple spelling mistakes, which occurs when organisations rely on manual review instead of enforcing module provenance and namespace controls.
Examples and Use Cases
Implementing protection against Go module typosquats rigorously often introduces friction in dependency management, requiring organisations to weigh fast, automated builds against stricter source validation and approval gates.
- A developer imports a module path that differs by one character from an internal package, and the build pulls attacker-controlled code from a public registry.
- A compromised mirror serves a lookalike module path during CI, causing the pipeline to compile and test malicious logic that appears dependency-compatible.
- An attacker publishes a module with a near-identical namespace to a private library, relying on transitive dependency resolution to draw in the fake package.
- A release process fails to pin expected module origins, so a typo in Ultimate Guide to NHIs-style service automation can silently switch trust from a maintained dependency to a hostile one.
- Security teams use NIST Cybersecurity Framework 2.0 mapping to require dependency provenance checks before modules are accepted into a software bill of materials.
These cases are common in CI/CD systems that auto-fetch dependencies and in organisations that allow broad network access from build runners. They become more dangerous when module fetching is coupled with privileged secrets in pipelines.
Why It Matters in NHI Security
Go module typosquats matter because they turn routine software delivery into a credentialed trust problem. If a build agent, deployment pipeline, or developer workstation resolves the wrong module, the attacker can inherit the execution context of the build, including tokens, certificates, and cloud access used by non-human identities. That makes a packaging mistake an identity event, not just a code quality defect. NHIMG research shows that Ultimate Guide to NHIs reports 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage, which underscores how often supply chain weaknesses translate into real compromise.
Typosquats also amplify over-privileged automation. When a build service account has broad access, the malicious module may reach artifact repositories, signing systems, or deployment targets. Stronger dependency controls should be paired with NIST Cybersecurity Framework 2.0 practices for asset, access, and supply chain risk management. Organisations typically encounter the consequences only after a poisoned build, at which point typosquat detection becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret exposure and dependency trust failures that typosquats exploit. |
| NIST CSF 2.0 | ID.SC-4 | Addresses software supply chain risk management for third-party and open-source components. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires every fetched dependency and build action to be explicitly trusted and verified. | |
| NIST AI RMF | Supports governance for automated systems that may ingest malicious code through supply chain paths. | |
| OWASP Agentic AI Top 10 | A2 | Agentic systems can auto-ingest packages, making typosquat defense part of tool-use security. |
Add dependency provenance checks to AI and automation pipelines before code execution or model training.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 21, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
