Why slopsquatting is becoming the next big AI software supply chain risk

Slopsquatting is an emerging supply chain attack

AI is changing software development at an incredible pace. Developers can now generate code, solve problems, and build applications much faster than before. That is a real advantage. But every new capability creates a new attack surface. Slopsquatting is one of the latest examples.

Slopsquatting happens when an AI coding assistant recommends a software package that does not actually exist. Large language models sometimes generate package names that sound legitimate because they predict the most likely answer instead of checking whether the package is real. If an attacker notices that a particular fake package name appears repeatedly, they can register that name in a public package repository and upload malicious code.

The next step is straightforward. A developer accepts the AI recommendation without verifying the dependency, installs the package, and unknowingly introduces malware into the application. The compromise begins during software development rather than after deployment. That makes this a software supply chain issue.

This is different from traditional typosquatting. Typosquatting depends on developers making spelling errors when installing legitimate packages. Package registries have spent years building defenses against that type of attack. Slopsquatting bypasses many of those protections because the package names are entirely new rather than misspelled versions of existing libraries. Current detection systems were not designed for AI-generated package hallucinations at scale.

For executives, this changes the way AI adoption should be governed. Productivity gains from AI coding assistants are real, but they should not be treated as a substitute for established software security controls. Organizations need processes that verify AI-generated dependencies before they become part of production systems. AI should increase development speed while security systems continue to validate what enters the software supply chain.

AI hallucinations have evolved

Most discussions about AI hallucinations focus on incorrect answers. In software development, the consequences are more serious. A hallucinated package name is not just inaccurate information. It can become an entry point for malicious code.

Large language models generate responses based on probability. They do not confirm that every recommendation exists in an official software repository. As AI coding assistants become more capable, developers naturally place greater trust in their suggestions. That trust creates an opportunity for attackers. If criminals know which fictional package names a model commonly produces, they can create those packages before developers discover they were never legitimate.

The challenge is that these hallucinations are often consistent. They are not completely random. Models can repeatedly recommend the same nonexistent dependency across different users and projects. That consistency gives attackers a predictable target instead of requiring them to guess what developers might install.

The risk extends beyond today’s models. Researchers have shown that adversarial techniques, including token-level manipulation and retrieval poisoning, can increase the likelihood of specific hallucinations. In other words, attackers may eventually influence AI systems to recommend the exact malicious packages they want developers to install. That shifts AI from being a passive source of mistakes to a technology that sophisticated threat actors may actively manipulate.

The research shows this is not a rare event. One study found hallucination rates ranging from 50% to 82%, depending on the language model and prompting method. Even GPT-4o, the strongest-performing model in that study, reached a minimum hallucination rate of 23% despite prompt-based mitigation techniques.

For business leaders, the conclusion is clear. AI-generated code should be treated with the same governance applied to code written by people. Every dependency should be validated against trusted repositories, automated security checks should be part of the development pipeline, and AI outputs should be considered recommendations rather than verified facts. Organizations that combine AI productivity with disciplined software governance will be in a much stronger position than those that rely on AI alone.

Slopsquatting can lead to prolonged, hard-to-detect breaches

One of the biggest concerns with slopsquatting is not how malware enters a system. It is how long it can remain there without being noticed.

When a developer installs a malicious package that appears legitimate, it can become part of the application’s normal dependency chain. From that point, the malicious code may continue operating across development, testing, and production environments. Because modern software often depends on hundreds or even thousands of third-party packages, identifying a single malicious dependency can be difficult, especially if it behaves quietly.

This creates a challenge for organizations that focus primarily on preventing attacks at the network perimeter. Supply chain attacks begin much earlier in the software lifecycle. If malicious code is introduced during development, it may pass through standard deployment processes and become embedded in business-critical applications before security teams detect anything unusual.

The broader software ecosystem is already showing signs of increasing pressure. According to recent research, one team analyzed 31,267 vulnerabilities across 14,675 software packages covering 10 programming languages. They found that reported vulnerabilities are increasing by 98% annually, while the number of open-source software packages is growing by 25% each year. The same research also found that the average lifespan of vulnerabilities has increased by 85%, suggesting that security issues are taking longer to identify and resolve.

For executives, these numbers highlight an operational issue rather than simply a technical one. As organizations increase their use of open-source software and AI-assisted development, security teams must manage a growing number of dependencies without a proportional increase in visibility. The result can be greater business risk, longer remediation cycles, and higher costs when vulnerabilities remain undiscovered.

The practical response is to improve visibility across the software supply chain. Continuous monitoring, software bill of materials (SBOM) management, dependency scanning, and regular security reviews should become standard practices. Organizations that know exactly which components they use are in a much stronger position to identify and respond to compromised packages before they affect customers or critical operations.

AI-generated package recommendations often appear legitimate

The success of slopsquatting depends on credibility. AI-generated package names often look realistic enough that developers assume they are genuine. They may closely resemble existing libraries, differ by only a small variation, or simply sound like a package that should already exist.

The challenge becomes greater because AI presents these recommendations confidently and within otherwise correct code. Developers naturally focus on whether the code solves the programming problem, not whether every dependency has been independently verified. Under project deadlines and increasing pressure to deliver software quickly, it becomes easy to accept an AI recommendation without additional validation.

This creates a human decision problem as much as a technical one. The more reliable AI becomes in many situations, the more likely users are to trust it in situations where it is incorrect. High-quality output in one area can unintentionally increase confidence in recommendations that should still be verified.

For business leaders, this is an important governance issue. Security policies should evolve alongside AI adoption. Development teams should not be expected to manually verify every recommendation through individual effort alone. Organizations should instead build verification into the development process through automated checks that confirm package names exist in trusted repositories before software is deployed.

Executive leadership also has a role in shaping organizational culture. AI should be positioned as a productivity tool. Teams should be encouraged to validate AI-generated recommendations without slowing innovation. When verification becomes part of the standard workflow rather than an optional extra step, organizations can benefit from AI-assisted development while significantly reducing the likelihood of introducing malicious packages into their software.

LLM-generated hallucinations are common and can be manipulated through adversarial techniques

Hallucinations are not an occasional flaw in large language models. They are a consequence of how these systems generate responses. An LLM predicts the most likely sequence of words based on patterns in its training data. It does not independently verify whether a software package actually exists before recommending it.

This matters because attackers do not need to exploit a software vulnerability in the traditional sense. Instead, they can exploit predictable behavior in the AI itself. If a model repeatedly generates the same fictitious package name, an attacker can register that package and wait for developers to install it. As AI-assisted coding becomes more common, the potential number of affected projects increases.

The risk could become even greater as adversarial techniques mature. Token-level manipulation and retrieval poisoning as examples of methods that could influence a model’s output. Token-level manipulation seeks to alter how the model predicts specific words or package names, while retrieval poisoning targets the external information sources that some AI systems use to generate responses. If successful, these techniques could increase the likelihood that developers receive attacker-controlled recommendations.

Widespread hallucinations remain. One study found hallucination rates ranging from 50% to 82%, depending on the language model and prompting method. Even GPT-4o, the strongest-performing model in that study, achieved a minimum hallucination rate of 23% despite prompt-based mitigation techniques. These findings suggest that better prompting alone is unlikely to eliminate the problem.

For executives, this reinforces an important principle: AI safety and cybersecurity are becoming increasingly connected. Organizations should not assume that improvements in model quality will remove the need for security controls. Verification systems, secure software development practices, and continuous monitoring should remain core requirements regardless of which AI platform is adopted. As AI capabilities improve, attackers are also likely to adapt their methods, making ongoing governance an essential part of enterprise AI strategy.

Not all language models are equally prone to generating maliciously exploitable hallucinations

The likelihood of slopsquatting depends partly on the AI model being used. According to the new research, proprietary models currently generate fewer hallucinated package names than many open-source alternatives. This reduces the probability of recommending a nonexistent dependency, but it does not eliminate the underlying risk.

The study evaluated 30 different AI systems, generating approximately 576,000 code samples that referenced 2.23 million software packages. Overall, 19.7% of those package references were hallucinated. GPT-4.0 Turbo recorded a hallucination rate of 3.59%, while DeepSeek 1B, identified as the best-performing open-source model tested, produced a hallucination rate of 13.63%. Based on these results, the researchers concluded that organizations relying on open-source coding models could face roughly four times greater exposure to slopsquatting attacks.

These findings are useful for strategic planning, but they should not be interpreted as a permanent ranking of AI security. Language models continue to evolve through new training methods, software updates, and changing architectures. Performance measured today may not reflect performance six months from now. Likewise, attackers will continue to study both proprietary and open-source systems to identify new opportunities.

For business leaders, the choice between proprietary and open-source AI should extend beyond hallucination rates. Cost, flexibility, regulatory requirements, data privacy, integration with existing systems, and long-term vendor strategy all influence the decision. Security is an important consideration, but it is one component of a broader enterprise technology strategy.

The more sustainable approach is to assume that every AI coding assistant can make mistakes. Security controls should therefore be designed around validating outputs rather than trusting the model itself. Organizations that build verification directly into their software development lifecycle will be better positioned to benefit from AI regardless of which model they choose today or in the future.

The increasing reliance on AI-assisted coding is expanding the attack surface for slopsquatting

AI-assisted software development is quickly becoming part of everyday engineering work. Developers use coding assistants to generate functions, explain code, identify bugs, and recommend software dependencies. This increases development speed, but it also increases the number of AI-generated recommendations entering production environments.

Developers estimate more than 40% of the code they commit already includes AI assistance, and many expect that percentage to continue growing over the next few years. It also reports that 72% of developers who have tried AI tools now use them daily. These figures show that AI-assisted development is becoming a standard operating model rather than an experimental capability.

As adoption grows, organizations should expect the volume of AI-generated dependencies to increase as well. Every dependency introduced into an application represents a potential point of risk if it is not properly verified. The issue is not that AI-generated code is inherently insecure. The issue is that faster software delivery can unintentionally reduce the amount of scrutiny applied to third-party packages if governance does not evolve alongside development practices.

Executives should view this as a business scaling challenge. Productivity improvements are valuable, but they also require investment in processes that scale with them. Development teams should not be expected to manually inspect every AI recommendation as adoption grows. Instead, organizations should strengthen automated dependency validation, software composition analysis, and continuous security testing so that security keeps pace with development speed.

Organizations that successfully combine AI-driven productivity with disciplined governance will be better positioned to innovate without introducing unnecessary operational risk. AI can accelerate software delivery, but long-term success depends on ensuring that speed does not come at the expense of software integrity.

Organizations can reduce slopsquatting risk through stronger package validation and continuous security monitoring

Slopsquatting is a manageable risk when organizations treat AI-generated code as an input that requires verification rather than automatic acceptance. The objective is not to slow development but to ensure that software dependencies are validated before they become part of production systems.

One of the most effective measures is to automatically verify package names against trusted public or private repositories before installation. This simple control can prevent developers from installing packages that do not exist in approved registries or that have been registered by attackers to exploit AI hallucinations. Integrating these checks directly into development pipelines reduces reliance on manual review while improving consistency across engineering teams.

Continuous monitoring is equally important after software has been deployed. Security teams should watch for unexpected package installations, unusual dependency updates, and abnormal software behavior that may indicate a compromised component. Combined with current threat intelligence on known slopsquatting campaigns, these capabilities improve an organization’s ability to identify and contain threats before they spread across multiple systems.

For executives, this is ultimately a governance issue rather than simply a technical implementation detail. AI adoption should be accompanied by updated software development policies, stronger dependency management practices, and clear accountability for validating third-party components. These measures help ensure that AI contributes to faster innovation without weakening the organization’s security posture.

The broader lesson extends beyond slopsquatting. As AI becomes embedded across enterprise software development, organizations will need security frameworks that evolve as quickly as the technology itself. Companies that invest early in automated validation, continuous monitoring, and secure development practices will be better prepared to adopt future AI capabilities with confidence while maintaining resilience across their software supply chains.

Final thoughts

AI-assisted software development is no longer an emerging trend. It is becoming part of how modern organizations build products, deliver services, and compete. The productivity gains are substantial, but every increase in capability changes the security landscape. Slopsquatting is one example of how attackers are adapting just as quickly as the technology itself.

For business leaders, the priority should not be slowing AI adoption. It should be adopting AI responsibly. Organizations that treat AI-generated code as trusted by default will expose themselves to unnecessary risk. Organizations that combine AI with strong governance, automated validation, and continuous monitoring will be able to move quickly without compromising software integrity.

This is also an opportunity to rethink software supply chain security more broadly. Dependency management, code validation, and secure development practices should become strategic capabilities rather than isolated technical functions. As AI becomes embedded throughout the software development lifecycle, these capabilities will directly influence operational resilience, customer trust, and long-term business performance.

The organizations that gain the greatest competitive advantage from AI will not necessarily be those that generate code the fastest. They will be the ones that build secure, reliable software at scale while maintaining confidence in every component that reaches production. In the years ahead, that balance between speed and trust will become a defining characteristic of technology leadership.