Protocol
Audit the version before merging an AI-added dependency
A real dependency can still be a known vulnerable dependency.
When it fits
- The package is legitimate, but the agent chose a version from stale training or an old example.
When to avoid it
- Vulnerability databases can lag or miss issues; high-risk components may need deeper supply-chain review.
Why it matters
Run the project's normal dependency and vulnerability checks on every new or changed dependency. Inspect the lockfile and release provenance, pin versions according to project policy, and separate 'latest' from 'approved.' Treat a clean scan as one signal, not a guarantee.
Steps
- Dependency audit run.
- Lockfile inspected.
- Version matches policy.
- Known vulnerability sources checked.
- License/provenance checks run if required.
An example
A valid library is rejected at the AI-suggested version because the project's scanner identifies a known vulnerability fixed in a later release.
Check your result
The dependency version is justified by current project security checks rather than model memory.
Keep this limit in mind
- Vulnerability databases can lag or miss issues; high-risk components may need deeper supply-chain review.
Evidence and sources
OWASP recommends auditing AI-suggested dependencies and versions against current vulnerability information rather than assuming a model knows recent CVEs or legitimate package names.
Dependency scanners also have coverage and freshness limits; manual package identity and provenance checks can still matter.
Secure Coding with AI Cheat Sheet · Hallucinated and Outdated Dependencies
NIST SSDF recommends integrating secure development practices into the software lifecycle rather than treating security as a separate late-stage review.
The framework is high-level and must be tailored to the organization's development model and risk.
Secure Software Development Framework (SSDF) Version 1.1 · SSDF overview