Scope
This guide addresses the governance gap between AI coding assistant adoption and dependency security controls. If your team uses GitHub Copilot, Amazon CodeWhisperer, or similar tools, you're accepting package suggestions that may not exist, may be typosquatted, or may contain known vulnerabilities. This guide covers the controls you need at the point of code selection, before AI-suggested dependencies enter your codebase.
Key Concepts and Definitions
Slopsquatting: When AI coding assistants generate package names that don't exist, creating opportunities for attackers to publish malicious packages under those names. Unlike traditional typosquatting, which exploits human typos, slopsquatting exploits AI model training gaps.
Point of selection governance: Security controls applied when a developer accepts an AI suggestion, not after code review or CI/CD scanning. This shifts left beyond traditional "shift left", preventing vulnerabilities from entering version control.
AI-co-authored code: Any code snippet, function, or dependency suggestion generated or completed by an AI assistant. According to Kusari's Application Security in Practice report, this now represents a significant portion of enterprise codebases, with 85% of organizations using AI coding assistants.
Requirements Breakdown
Coverage Under Existing Standards
PCI DSS v4.0.1 Requirement 6.3.2 requires security of bespoke and custom software throughout the software development lifecycle. AI-suggested code falls under this requirement; you can't claim you've secured custom software if you're blindly accepting AI-generated dependencies.
OWASP ASVS v4.0.3 Requirement 14.2.1 addresses dependency management: "Verify that all components are up to date, preferably using a dependency checker during build or compile time." Your dependency checker needs to run before the AI suggestion becomes a committed dependency.
ISO 27001 Control 8.31 implies you need controls preventing unvetted packages from reaching any environment. AI-suggested dependencies bypass this control if accepted without validation.
The Defect Rate Problem
A CodeRabbit analysis found AI-co-authored contributions carried 70% more defects than human-authored code. This isn't just about code quality; it's about the increased attack surface when AI suggests dependencies without understanding your threat model, compliance requirements, or internal security standards.
Implementation Guidance
Pre-Commit Validation Layer
Build a validation hook between AI suggestion and developer acceptance:
Package existence verification: Before accepting any import statement, confirm the package exists in your approved registry. A USENIX Security study analyzed sixteen popular code-generation models across 500,000+ code samples and found consistent hallucination patterns. Your validation layer needs to catch these.
Known vulnerability scanning: Query your SCA tool's API before the import enters your IDE. If the AI suggests a package with a CVSS 7.5+ vulnerability, block it at suggestion time, not at PR review.
License compatibility check: AI assistants don't understand your organization's license policies. If you prohibit AGPL dependencies and the AI suggests one, your validation layer should flag it immediately.
Registry Controls
Configure your AI coding assistant to only suggest packages from your approved internal registry:
- Mirror public registries through your own infrastructure.
- Apply security and license policies at mirror sync time.
- Configure IDE plugins to query your registry, not public ones directly.
- Monitor for requests to packages not in your mirror, indicating either a gap in your mirror or a hallucination.
Governance for the 9%
Only 9% of organizations have dedicated AI AppSec controls despite 85% using AI coding assistants. If you're building these controls from scratch:
Week 1-2: Inventory which AI tools your developers use and whether they can be configured to respect custom registries.
Week 3-4: Deploy a package validation proxy that sits between your developers' IDEs and public package registries. Log every suggestion for baseline analysis.
Week 5-6: Implement blocking rules for known-vulnerable packages, non-existent packages, and license violations.
Week 7-8: Add human review workflow for packages that pass automated checks but aren't in your pre-approved list.
Common Pitfalls
Treating AI suggestions like human suggestions: When a senior developer suggests a dependency, they've usually researched it. When an AI suggests one, it's pattern-matching from training data that may be years old or completely fabricated.
Relying on post-commit scanning: By the time your CI/CD pipeline catches a vulnerable AI-suggested package, it's already in version control, potentially merged to main, and definitely in your incident response metrics. Shift the control earlier.
Assuming AI tools understand your context: AI coding assistants don't know you're in a PCI DSS environment, that you've banned certain licenses, or that you maintain an internal fork of a popular library. They suggest based on statistical likelihood, not your security policies.
Ignoring the maintenance burden: When AI suggests niche or abandoned packages, you're inheriting maintenance responsibility. The package may work today, but who's patching it when a CVE drops?
Quick Reference Table
| Control Point | Check | Tool/Method | Blocking Threshold |
|---|---|---|---|
| Pre-acceptance | Package exists | Registry API query | Non-existent package |
| Pre-acceptance | Known vulnerabilities | SCA API (Snyk, Sonatype, etc.) | CVSS ≥7.0 |
| Pre-acceptance | License compatibility | Internal policy engine | Prohibited license |
| Pre-acceptance | Maintenance status | Last commit date, open issues | No commits >18 months |
| Post-suggestion | Hallucination pattern | Log analysis | Repeated suggestions of non-existent packages |
| Monthly review | AI suggestion acceptance rate | Telemetry from IDE plugins | Acceptance >40% without validation |
Start here: If you don't have any controls yet, begin with package existence verification. It's the lowest-effort, highest-impact control. Preventing slopsquatting requires only a registry API call. Build from there toward comprehensive pre-acceptance validation.
