What do security teams get wrong about typosquatted packages?

Why This Matters for Security Teams

Typosquatted packages are not mainly a naming problem; they are a supply chain delivery problem. Security teams often harden package allowlists and still miss what happens after install: malicious post-install scripts, credential theft, and environment probing that turns a single developer action into broad compromise. The real risk is that package install time becomes an execution path with access to CI variables, cloud metadata, and publishing tokens.

This is why NHI governance matters even for software dependency events. A package can be the lure, but the objective is often the same as in other NHI attacks: harvest secrets, pivot into build systems, and reuse standing credentials. NHI Mgmt Group research on the Ultimate Guide to NHIs shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations, which is exactly the exposure typosquatted packages try to exploit. The control question is not just “Is this package name trustworthy?” but “What can this install process reach?”

Practitioner teams tend to discover this only after a developer workstation, CI runner, or release pipeline has already exposed tokens to code that was never meant to execute in the first place.

How It Works in Practice

Defending against typosquatted packages requires treating dependency install as an execution boundary, not a routine fetch. The first layer is provenance: verify where the package came from, who published it, and whether the artifact matches expected signing or registry metadata. The second layer is runtime restriction: block or tightly constrain install-time scripts, outbound network access, and access to cloud instance metadata endpoints. NIST guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls supports disciplined control over execution, least privilege, and monitoring around software supply chain events.

For NHI-heavy environments, the key is to remove standing secrets from install contexts. CI variables, publishing tokens, and cloud credentials should be short-lived, scoped, and injected only when a pipeline step truly needs them. NHI Mgmt Group’s LiteLLM PyPI package breach illustrates the practical pattern: the malicious package was useful because it could reach secrets during execution, not because the name was convincing. Good controls therefore include ephemeral tokens, restricted egress, artifact signing checks, and alerting on unusual package-install behavior.

• Use private indexes, pin versions, and verify hashes where ecosystem support is mature.
• Separate build credentials from developer credentials and issue them just in time.
• Disable or sandbox install scripts in high-risk pipelines.
• Prevent package jobs from reading metadata services, vault roots, or publish scopes.

These controls tend to break down in legacy CI systems that require broad network access and long-lived publish tokens because package execution and secret access are still treated as normal developer convenience.

Common Variations and Edge Cases

Tighter package controls often increase build friction, so organisations must balance developer velocity against the blast radius of compromise. That tradeoff is especially visible in polyglot repositories, self-hosted runners, and internal package mirrors, where policy can become inconsistent across ecosystems.

Best practice is evolving on how far install-time execution should be restricted. Some teams block all scripts by default; others allow only signed or approved packages with context-aware exceptions. There is no universal standard for this yet, but current guidance suggests prioritising the environments where tokens are richest and rebuilds are easiest. For example, a development laptop may tolerate more flexibility than a release pipeline that can publish to production registries.

Edge cases also matter. Public package names are only one route; attackers can target transitive dependencies, namespace confusion, or “helpful” setup scripts inside otherwise legitimate packages. Visibility is therefore as important as prevention. The supply chain lesson is consistent with broader NHI risk: the threat is usually not the object itself, but what it can access once execution begins. NHIMG’s State of Non-Human Identity Security shows that only 1.5 out of 10 organisations are highly confident in securing NHIs, which helps explain why secret exposure during software installs remains such an easy path.

Related resources from NHI Mgmt Group

• What do security teams get wrong about preinstall hooks?
• What do security teams get wrong about peer-to-peer infrastructure risk?
• What do security teams get wrong about shell quoting in build tools?
• What do security teams get wrong about detecting malicious packages?