Because many package managers allow install-time scripts and other lifecycle hooks to run as part of setup. If an attacker gets a malicious package selected, the package can execute before the application even imports it. That turns a naming mistake into a runtime compromise, especially when the build context still contains secrets or publishing rights.
Why this is code execution risk, not just dependency hygiene
Typosquatting and slopsquatting matter because package installation is often an execution step, not a passive file download. Build tools may run setup, postinstall, or other lifecycle hooks during resolution, so the wrong package can execute before the application ever imports it. Once that happens, the risk shifts from “bad dependency” to “attacker code running in your build or developer environment.”
The practical distinction is that dependency mistakes can change functionality, but malicious packages can change control. If the install context has network access, source code, tokens, signing material, or publishing rights, the package may be able to read, exfiltrate, or abuse them. That is why naming confusion becomes a code execution problem and often a supply chain problem at the same time.
That risk is amplified by how modern package ecosystems work: dependency resolution is automated, transitive, and often trusted by default. A malicious package only needs to be selected once at install time to gain a foothold, while downstream application code may never get a chance to validate what ran during setup.
Where the execution path comes from
Install-time execution usually comes from lifecycle hooks, build scripts, or package manager behaviors that assume packages are legitimate. In other words, the package manager is not just fetching code, it is participating in the software build process. That is why the attack surface includes CI jobs, developer laptops, ephemeral containers, and any system that installs dependencies with elevated access or sensitive environment variables.
This is also why the exact failure mode depends on the ecosystem. Some managers discourage scripts, some support them by default, and some expose more execution opportunities than teams realise. The security question is not whether the package is imported later, but whether the install process already gave it a chance to run. If it did, the attacker may already have code execution, even if the dependency is never used at runtime.
Typosquatting and slopsquatting are especially effective because the selection mistake happens before security review gets a chance to inspect behavior. A poisoned package can be chosen by humans, dependency bots, or AI-assisted development workflows that generate plausible but incorrect names. NHIMG’s Malicious Package and Dependency Confusion Guide covers the same trust boundary from the package-manager side, including install scripts, provenance, and credential response.
What makes the blast radius so large
The real danger is not only that the package runs, but what it can reach once it does. Build and development environments frequently hold secrets that are useful far beyond the local machine: publishing tokens, cloud credentials, API keys, signing keys, and access to internal registries or source control. A malicious install script can try to steal those values, alter build artifacts, or prepare follow-on access that survives the original typo being fixed.
There is also a propagation problem. If the compromised environment is allowed to publish packages, commit code, or sign artifacts, one malicious install can become a software supply chain compromise rather than a single-host incident. That is why the same event can end in credential theft, tampered releases, or downstream compromise of consumers who trust the resulting artifact.
For teams building AI-assisted developer workflows, the boundary is even wider. NHIMG’s AI Coding Agents Security Guide is relevant here because agentic tooling can install packages, run commands, and chain tools with access to the same secrets and repositories that a human developer would protect. The execution risk is therefore both software-supply-chain risk and delegated-action risk.
Risk and Threat Considerations
Typosquatting and slopsquatting are dangerous because they convert a search or naming error into an execution path. The attacker does not need to wait for the vulnerable package to be imported, because the installer itself may execute attacker-controlled logic during setup or build.
Failure mechanism: A malicious package is selected during dependency resolution, then its install-time scripts or build hooks run inside a trusted environment that already has access to code, credentials, or publishing workflows.
Impact: The attacker can achieve code execution, secret theft, build tampering, or further supply chain compromise before the mistake is noticed, which makes the dependency issue an immediate compromise path instead of a mere quality defect.
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 addresses the attack and risk surface, while CIS Controls v8, SLSA and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Typosquatted packages can expose secrets during install-time execution. |
| NHI-05 — Overprivileged NHI | Package install contexts often hold unnecessary publish or cloud privileges. | |
| Recommendation — Remove secrets from build contexts and rotate any exposed credentials immediately. Reduce build and publishing privileges to the minimum required for installation. | ||
| CIS Controls v8 | CIS-5 — Account Management | Install-time compromise often abuses overly broad credentials in build systems. |
| Recommendation — Limit and review privileged accounts used by CI and package publishing workflows. | ||
| SLSA | Supply Chain Levels for Software Artifacts | The question is about package-driven code execution in the software supply chain. |
| Recommendation — Adopt provenance and hermetic build controls for dependency resolution and artifact creation. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Install scripts and build hooks are architecture-level execution risks in software delivery. |
| Recommendation — Design build pipelines to restrict untrusted code execution during dependency installation. | ||
Practitioner Guidance
What to prioritise: Treat install-time execution as the main security control point. The decision is not just “is this dependency correct,” but “what is allowed to run when it is installed and what can that execution reach?”
What to verify: Confirm whether your package managers, CI jobs, and developer environments allow lifecycle scripts, preinstall hooks, or other automated execution by default. If they do, verify that those environments are stripped of unnecessary secrets and publishing rights before dependency resolution occurs.
Decision rule: If a build context can access production credentials, signing keys, or registry publish privileges, treat any typo-selected package as a potential code execution event and investigate blast radius before assuming the package was harmless.
Common mistake: Teams often focus on whether the wrong package version was downloaded and miss the more important question of whether the package executed during installation. That distinction determines whether the incident is a dependency error or a runtime compromise.
Practitioner takeaway: The security boundary is the installation step, not the first import, so the safest response is to assume a malicious package can run before your application ever has a chance to reject it.
Related resources from NHI Mgmt Group
- Why do non-human identities create more risk than many human accounts?
- Why do non-human identities create more remediation risk than many human accounts?
- Why do malicious skills create a bigger risk than ordinary code dependencies?
- Why do third-party dependencies create more supply chain risk than first-party code?