As more teams rely on public repositories in their software supply chain, the dependency chain has become both a critical foundation and a potential blind spot. Dependency chain abuse is not new, but a growing list of attack vectors - like typosquatting, dependency confusion, and now slopsquatting - means security leaders need to respond quickly as attackers adopt new techniques.
Let’s take a look at how dependency chain abuse works, why it’s growing more dangerous in the age of GenAI, and what you can do to protect your supply chain.
What is Dependency Chain Abuse?
Dependency chain abuse refers to a broad set of attacks that exploit how software dependencies are sourced and managed - whether accessed during development, within CI/CD pipelines, or across runtime environments. Attackers can manipulate the package retrieval process, tricking systems into installing malicious software that poses as a legitimate dependency.
Most development teams rely on a mix of internal registries (like Cloudsmith) and public ecosystems like npm, PyPI, RubyGems, etc. But this open and distributed model creates a porous perimeter. A single unverified or malicious package could potentially lead to:
- Credential theft
- Remote code execution
- Installing Persistent backdoors
- Compromising the entire software supply chain
Classic Dependency Chain Abuse in the Wild
The official OWASP Top 10 CI/CD documentation cites some of the better-known ways attackers exploit dependencies:
| Attack Vector | Description |
|---|---|
| Dependency Confusion | Uploading malicious packages to public repositories with names matching private ones. |
| Dependency Hijacking | Gaining control of a maintainer’s account to inject malware into popular packages. |
| Typosquatting | Using misspelled or lookalike package names to trick developers. |
| Brandjacking | Imitating trusted organizational naming conventions to gain developer trust. |
These methods rely on lapses in developer vigilance or CI/CD misconfigurations - but now there’s a new adversary for compliance teams: GenAI.
Introducing Slopsquatting
Slopsquatting is a novel attack vector that exploits a well-known weakness of generative AI systems: their tendency to "hallucinate" - that is, to produce plausible but incorrect or fabricated information - especially when generating code..
A study from Cornell University, titled A Comprehensive Analysis of Package Hallucinations by Code-Generating LLMs, examined 16 popular large language models using two distinct prompt datasets. The researchers generated 576,000 code samples across two programming languages and analyzed them for hallucinated packages. Their findings revealed that, on average, commercial models hallucinated packages in at least 5.2% of cases, while open-source models did so at a much higher rate of 21.7%. Alarmingly, they identified 205,474 unique hallucinated package names, highlighting just how widespread and serious this vulnerability has become
Why Dependency Chain Attacks Are So Damaging
Once a malicious dependency is in play, it’s often too late. Even if the payload is dormant or the package "works as advertised," it could potentially:
- Harvest environment variables and secrets
- Exfiltrate data
- Pivot across systems and escalate privileges
- Remain unnoticed across builds and deployments
These attacks go well beyond the developer’s workstation. These are full-on supply chain threats with long-lasting consequences.
Mitigating the Risk of Dependency Chain Abuse
Securing the software supply chain requires a multi-layered approach, particularly when managing dependencies across various language-specific package managers and build environments. While configurations may differ, the core principle remains the same: clients should never fetch packages directly from untrusted or public sources. Instead, all third-party packages should be routed through internal proxies, enabling organizations to enforce security controls, log activity, and respond quickly in the event of an incident.
Wherever possible, direct access to external repositories should be disabled, and clients should be configured to pull only from internal, pre-vetted repositories.
To further reduce risk, organizations should implement strict integrity and version control. This includes enforcing checksum and signature verification for all packages, avoiding use of "latest" tags in favor of fixed, vetted versions, and using lockfiles or version pinning mechanisms provided by each language ecosystem. All internal packages should be properly namespaced to the organization, with clients configured to only retrieve scoped packages from internal sources. Configuration files (e.g. .npmrc, pip.conf) must reside within project repositories to override any insecure global settings on developer machines.
Conclusion
By enforcing trust boundaries, verifying package integrity, and adopting zero-trust tooling like Cloudsmith, organisations can significantly reduce their exposure to dependency chain abuse. As software supply chains grow more complex and AI-generated code becomes more common, securing how and where your dependencies are sourced has never been more critical. If you found this content helpful and want to dive deeper into securing your CI/CD pipelines, be sure to check out our free Cloudsmith eBook on the OWASP Top 10 for CI/CD systems – download it here.
