Your AI coding assistant just suggested installing a package. It doesn’t exist. You install it anyway. Now you’re compromised.

This isn’t hypothetical—AI models hallucinate non-existent package names in 5-21% of generated code. Research analyzing 576,000 code samples found 205,000+ unique phantom packages, with 58% recurring predictably across sessions.

Attackers exploit this by monitoring AI outputs, registering these hallucinated packages with malware, and waiting for developers to blindly install them. It’s called “slopsquatting.”

While exploring AI supply chain risks (wrote about it here: https://lnkd.in/dS3D-zwt), I built SlopGuard to detect these attacks before they reach production.

🔍 Technical approach: • 3-stage lazy-loading trust scorer (downloads → dependents → maintainer/GitHub) • 87% of packages exit at stage 1 (basic trust), only 3% need full analysis • Detects typosquatting (Levenshtein distance), namespace squatting, download inflation, ownership changes • Automated scoring from verifiable signals—no manual whitelists that break ⚡ Validated performance: • <3% false positives (tested against 500 legitimate + 500 malicious packages) • 96% detection rate on documented supply chain attacks • 7 seconds to scan 700+ packages (warm cache)

Built in Ruby, ~2,500 lines, fully open source (MIT). ━━━━━━━━━━━━━━━━━━━━━━━━ Current stage: Early development, personal research project. RubyGems/PyPI/Golang for now. Metadata-based detection—can’t analyze behavioral patterns.

Looking for technical peer review: • Are trust thresholds (80/70/40) optimal for production? • What attack patterns am I missing? • Would you deploy this in CI/CD, or does it solve the wrong problem?

Try it: https://lnkd.in/dHyvucVQ GitHub: https://lnkd.in/d2TsnQ3s

If you work on supply chain security or AI security research—where are the blind spots in this approach?

Disclaimer: This is my personal project in early development. The algorithms are based on academic research (TypoSmart, Sonatype data).