Digital supply chains can be unpredictable, with new attack vectors constantly emerging. Often, they exploit software inter-dependencies – where one piece of software relies on another to function – as well as the implicit trust many people have in in code repositories.
Most developer teams will have rightly focused their efforts on addressing vulnerabilities within their own code bases. But one of the most subtle, overlooked threats today comes from elsewhere. And it’s a risk that’s rarely given enough attention.
This is dependency chain abuse (DCA), where attackers target the building blocks that software developers rely on, hiding malicious code in this tangle of software. And DCA is becoming a useful weapon for cyber criminals seeking to compromise businesses, at scale.
What is slopsquatting and why does it matter?
This year, security researchers detailed a theoretical type of cyber attack: slopsquatting. This exploit relies on generative AI’s tendency to hallucinate when writing code.
Code is often hosted on public-access repositories, such as Github, and organised into packages – essentially libraries of reproducible, efficient code that developers can copy.
AI coding tools like ChatGPT and Cursor are known to make up software package names that don’t actually exist. Hackers can take advantage of this by guessing which names these tools might suggest, or by spotting common mistakes developers make – and then registering those fake names on places developers regularly use to pull in third-party code, such as public code libraries.
As more companies utilise AI tools to generate code, the risk of accidentally pulling in malicious or fake packages is growing. It’s a quiet but serious supply chain threat that most companies are oblivious to.
This threat is a next-generation version of ‘typosquatting’, where malicious actors register names that resemble legitimate ones – exploiting typos, naming conventions or even placeholder references that developers leave in their code. If you’re a hacker, this can allow you to slip past unnoticed and run your code undetected.
Cybersecurity company Socket details a recent example where a malicious package mimicked a widely used open-source library. Attackers were using this imitator to steal OAuth credentials on the 15th of each month. Stealthy, patient and precise. This kind of attack – which was almost surgical in its approach – emphasises how critical it is that organisations re-evaluate how they handle third-party dependencies.
A brewing supply chain crisis
Research shows that LLMs tend to hallucinate package names roughly 20% of the time when recommending libraries in generated code snippets. That’s a serious enough risk by itself, but there’s an unsettling twist.
Developers are increasingly using AI to help generate code, meanwhile adversaries are developing new attacks, such as typosquatting and slopsquatting, which use fabricated names in public registries. the result is a supply chain crisis brewing just beneath the surface.
The emergence of slopsquatting highlights the need for secure artifact management. This refers to any by-products of the software development process. Organisations must understand the software artifacts their business consumes, including source code, configuration files, and documentation.
How to stop slopsquatting
Let’s go back to basics. Slopsquatting is a form of DCA, which is not new. In fact, DCA is categorised as an entire security-control category in the Open Worldwide Application Security Project’s (OWASP) top 10 risks for CI/CD pipelines, a veritable bible for DevSecOps practitioners.
Whether you’re talking about typosquatting, brandjacking, dependency hijacking or AI hallucination risks, the impact associated with these attacks, and the best practices to mitigate them, are highlighted by OWASP. Studying this documentation gives developers a great starting point to mount a defence against DCA.
Fighting slopsquatting with dependency hygiene
Your first step should be to take dependency hygiene seriously. Enforce internal proxies for all external package requests. This creates a single chokepoint for scanning, logging and validation. Developers also shouldn’t download directly from public sources such as npm or PyPI.
Next, we need to control what gets in. Only use third-party packages that are pre-vetted, signed and verified through a controlled-promotion pipeline before being made available internally. Avoid auto-upgrade mechanisms such as ‘latest version’ by default. By locking package versions tightly and committing those version files into source control, you can prevent unreviewed updates from sneaking in.
Lastly, using clear naming rules for your internal software packages is a powerful way to reduce risk. Every private package should sit under a clearly labelled name that signals it’s from your company.
If a developer tries to pull in a package that’s missing this label – perhaps it has a name that could be confused with something public – your systems should block it. This helps stop a common trick where attackers upload fake packages with similar names to trusted ones, hoping someone will install them by mistake.
Protecting the entire software supply chain
It’s good to see people taking slopsquatting seriously. But it’s just one of the many parasites hounding modern software development pipelines. The OWASP Top 10 for CI/CD framework is a useful reference to help us understand and address a wider set of threats, from poisoned pipeline execution to weak credential management.
It’s also a reminder that robust supply chain security takes more than hunting and identifying individual attack vectors. Our most effective recourse will always be to enforce secure defaults across the entire development lifecycle.
Nigel Douglas is head of developer relations at CloudSmith.
Digital supply chains can be unpredictable, with new attack vectors constantly emerging. Often, they exploit software inter-dependencies – where one piece of software relies on another to function – as well as the implicit trust many people have in in code repositories.
Most developer teams will have rightly focused their efforts on addressing vulnerabilities within their own code bases. But one of the most subtle, overlooked threats today comes from elsewhere. And it’s a risk that’s rarely given enough attention.
This is dependency chain abuse (DCA), where attackers target the building blocks that software developers rely on, hiding malicious code in this tangle of software. And DCA is becoming a useful weapon for cyber criminals seeking to compromise businesses, at scale.
