Q: What is slopsquatting and how does it differ from typosquatting? A: Slopsquatting is a supply chain attack where LLMs hallucinate plausible but non-existent package names that attackers can register and fill with malware. Unlike typosquatting, it does not rely on simple misspellings and can evade registry protections that target typical typo-based squats. Q: How do AI coding tools enable slopsquatting attacks? A: LLMs predict statistically likely text and sometimes invent library names, so developers who copy those suggestions may install packages attackers later register with malicious code. As AI-assisted coding grows, these hallucinations increase the attack surface and malicious packages can remain undetected in production for months. Q: What immediate guardrails should developers enable in AI coding assistants? A: Turn off auto-install or auto-run features, force human review of suggested dependencies, and prefer models with lower hallucination rates while keeping prompts clear and specific. These practices are central to how to prevent slopsquatting attacks because they ensure suggestions are verified before execution. Q: How can CI/CD pipelines validate and block hallucinated packages? A: Add pre-commit or pre-merge checks that validate package names against official registries and block builds when a package is unknown, newly registered, or fails policy checks. Use an allowlist for critical services and require approval for any change to lockfiles before merging. Q: Why are lockfiles and version pinning important in preventing slopsquatting? A: Lockfiles and exact version pins prevent builds from pulling in new, unreviewed packages by banning floating ranges like ^ and ~ in production services. Reviewing and approving any lockfile changes in pull requests keeps builds reproducible and reduces exposure to suddenly registered malicious packages. Q: How does using a private registry proxy reduce the risk of slopsquatting? A: Routing installs through an internal proxy (for example Nexus, Artifactory, or Verdaccio) lets teams mirror upstream registries and permit only reviewed packages into the proxy, blocking everything else by default. Recording who approved each package and when provides auditability and limits exposure to newly created malicious packages. Q: What quick verification checks should developers do before installing a suggested package? A: Search the official registry to confirm the package exists, check owner history, 2FA status where visible, release cadence, README, and linked source repository, and avoid running one-line install commands from unknown sources. Red flags include brand-new packages with near-zero downloads, copycat names, vague documentation, or no source repo. Q: What steps should be in an incident playbook if a slopsquatting package is detected in a build? A: Quarantine the CI/CD runner and affected machines, rebuild from a clean state with a known-good lockfile, and rotate any credentials that were present at build time. Search logs for data exfiltration or command-and-control traffic, document IOCs, and update allowlists and detectors to prevent recurrence.