{"id":53327,"date":"2025-04-23T14:57:10","date_gmt":"2025-04-23T18:57:10","guid":{"rendered":"https:\/\/www.kaspersky.com\/blog\/?p=53327"},"modified":"2025-04-23T14:57:10","modified_gmt":"2025-04-23T18:57:10","slug":"ai-slopsquatting-supply-chain-risk","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com\/blog\/ai-slopsquatting-supply-chain-risk\/53327\/","title":{"rendered":"How AI creates “slopsquatting” supply-chain risks"},"content":{"rendered":"

AI-generated code is already widespread \u2014 by some estimates around 40% of new code<\/a> this past year was written by AI. Microsoft CTO Kevin Scott predicts that in five years this figure will hit 95%<\/a>. How to properly maintain and protect such code is a burning issue.<\/p>\n

Experts still rate the security of AI code as low<\/a>, as it\u2019s teeming with all the classic coding flaws<\/a>: vulnerabilities (SQL injections, embedded tokens and secrets, insecure deserialization, XSS), logical defects, outdated APIs, insecure encryption and hashing algorithms, no handling of errors and incorrect user input, and much more. But using an AI assistant in software development adds another unexpected problem: hallucinations<\/a>. A new study examines in detail how large language models (LLMs) create hallucinations that pop up in AI code.<\/a> It turns out that some third-party libraries called by AI code simply don\u2019t exist.<\/p>\n

Fictitious dependencies in open-source and commercial LLMs<\/h2>\n

To study the phenomenon of phantom libraries, the researchers prompted 16 popular LLMs to generate 576,000 Python and JavaScript code samples. The models showed varying degrees of imagination: GPT4 and GPT4 Turbo hallucinated the least (fabricated libraries were seen in less than 5% of the code samples); next came DeepSeek models (more than 15%); while CodeLlama 7B was the most fantasy-prone (more than 25%). What\u2019s more, even the parameters used in LLMs to control randomness (temperature, top-p, top-k) are unable to reduce the hallucination rate to insignificant values.<\/p>\n

Python code contained fewer fictitious dependencies (16%) than JavaScript (21%). Age is also a contributing factor. Generating code using packages, technologies and algorithms that started trending only this past year results in 10% more non-existent packages.<\/p>\n

But the most dangerous aspect of phantom packages is that their names aren\u2019t random, and neural networks reference the same libraries over and over again. That was demonstrated by stage two of the experiment, in which the researchers selected 500 prompts that had provoked hallucinations, and re-ran each of them 10 times. This revealed that 43% of hallucinated packages crop up during each code generation run<\/strong>.<\/p>\n

Also of interest is the naming of hallucinated packages: 13% were typical \u201ctypos\u201d that differed from the real package name by only one character; 9% of package names were borrowed from another development language (Python code, npm packages); and a further 38% were logically named but differed more significantly from the real package names.<\/p>\n

Meet slopsquatting<\/h2>\n

All of the can provoke a new generation of attacks on open-source repositories, which has already been dubbed \u201cslopsquatting\u201d by analogy with typosquatting<\/a>. In this case, squatting is made possible not by names with typos, but by names from AI slop (low-quality output). Because AI-generated code repeats package names, attackers can run popular models, find recurring hallucinated package names in the generated code, and publish real\u00a0\u2014 and malicious \u2014 libraries with these same names. If someone mindlessly installs all packages referenced in the AI-generated code, or the AI assistant installs the packages by itself, a malicious dependency gets injected into the compiled application, exposing the supply chain to a full-blown attack (ATT&CK T1195.001<\/a>). This risk is set to rise significantly with the advance of vibe coding\u00a0\u2014 where the programmer writes code by giving instructions to AI with barely a glance at the actual code produced.<\/p>\n

Given that all major open-source repositories have been hit by dozens of malicious packages this past year (1<\/a>, 2<\/a>), and close to 20,000 malicious libraries<\/a> have been discovered in the same time period, we can be sure that someone out there will try to conveyorize this new type of attack. This scenario is especially dangerous for amateur programmers, as well as for corporate IT departments that solve some automation tasks internally.<\/p>\n

How to stop slopsquatting and use AI safely<\/h2>\n

Guidelines on the safe implementation of AI in development already exist (for example, OWASP<\/a>, NIST<\/a> and our own<\/a>), but these tend to describe a very broad range of measures, many of which are long and complicated to implement. Therefore, we\u2019ve compiled a small subset of easy-to-implement measures to address the specific problem of hallucinated packets:<\/p>\n