Your AI coding assistant just added 47 dependencies to your project. You approved the PR because the feature works and the tests pass. Three months later, you're patching a critical vulnerability in a transitive dependency four layers deep that nobody on your team knew existed.
AI-assisted development is increasing open source consumption. When your developers use AI to generate code, they're pulling from models trained on public data snapshots with knowledge cutoffs. The AI doesn't know which packages are deprecated, which maintainers abandoned their projects, or which versions contain known vulnerabilities. It knows what code patterns worked in its training data.
This checklist helps you implement dependency governance that keeps pace with AI-accelerated development without blocking your engineering team.
Prerequisites
Before you start, you need:
- SBOM generation capability integrated into your CI/CD pipeline (CycloneDX or SPDX format)
- Dependency scanning tools that can parse AI-generated code (Snyk, Dependabot, or equivalent)
- Policy enforcement point where you can block or flag builds (GitHub Actions, GitLab CI, Jenkins, or similar)
- Baseline inventory of currently approved dependencies and their risk profiles
If you don't have these, start there. You can't govern what you can't see.
Dependency Governance Checklist
1. Establish a Dependency Approval Workflow
Every new dependency introduced by AI-generated code requires explicit approval before merge, with documented justification for inclusion.
What good looks like: Your PR template includes a "New Dependencies" section. When an AI assistant adds a package, the developer must document: why this specific package, what alternatives were considered, and who approved it. You have audit logs showing approval decisions.
2. Implement Least-Privilege Access for AI Agents
Your AI coding assistants operate with restricted permissions that prevent them from directly committing code or modifying dependency manifests without human review.
What good looks like: AI tools can suggest code but cannot merge PRs. They cannot modify package.json, requirements.txt, go.mod, or equivalent files without triggering a separate review workflow. Your CI logs show which AI agent made which suggestion, and which human approved it.
3. Define Dependency Risk Tiers
You've categorized dependencies into risk levels with specific approval requirements for each tier.
What good looks like:
- Tier 1 (Pre-approved): Core frameworks from established maintainers (React, Django, etc.) - auto-approved with version constraints
- Tier 2 (Standard review): Common utilities with active maintenance - requires team lead approval
- Tier 3 (Enhanced review): New packages, packages with <100 GitHub stars, or packages from unknown maintainers - requires security team review
- Tier 4 (Prohibited): Deprecated packages, known vulnerable versions, or packages from blocked sources - CI fails automatically
4. Set Version Pinning Requirements
Your dependency manifests use exact version pins (not ranges) for all production dependencies, with automated alerts for new versions.
What good looks like: Your package.json shows "express": "4.18.2" not "express": "^4.18.0". You have a scheduled job that checks for updates weekly and creates review tickets. AI-generated code that uses version ranges fails CI with a message explaining the pinning requirement.
5. Create a Transitive Dependency Visibility System
You can trace any package in your build to its introduction point and see the full dependency tree for AI-generated code.
What good looks like: When a vulnerability appears in a transitive dependency, you can identify which PR introduced it, which AI assistant suggested it, and which direct dependency pulled it in. Your SBOM includes metadata tagging AI-generated code sections.
6. Implement Automated Vulnerability Scanning Gates
Your CI pipeline scans all dependencies (including those suggested by AI) and blocks merges for HIGH or CRITICAL CVEs.
What good looks like: A developer uses an AI assistant to add a package. The PR triggers automated scanning. If the package or any of its dependencies have known vulnerabilities above your threshold, the build fails with specific CVE numbers and remediation guidance. You track mean-time-to-remediation separately for AI-suggested vs. human-selected dependencies.
7. Establish License Compliance Checks
Every dependency has a validated license compatible with your usage, with automated blocking for incompatible licenses.
What good looks like: Your CI checks license metadata against your approved list (MIT, Apache 2.0, BSD, etc.). When an AI assistant suggests a GPL-licensed package for a proprietary product, the build fails immediately. You maintain an exception list with legal approval documentation.
8. Configure Dependency Update Policies
You have documented SLAs for updating dependencies based on vulnerability severity and automated enforcement.
What good looks like: CRITICAL vulnerabilities require patching within 48 hours. HIGH within 7 days. MEDIUM within 30 days. Your ticketing system automatically creates issues when vulnerabilities are detected, assigns them based on the original PR author, and escalates if SLAs are missed.
Common Mistakes
Treating AI-suggested dependencies like human-selected ones. AI models don't evaluate maintenance status, community health, or long-term viability. They suggest what statistically fits the code pattern.
Blocking all AI-generated dependency additions. This creates shadow IT where developers disable scanning or work around controls. Instead, make approval fast for low-risk packages.
Ignoring transitive dependencies. AI assistants often suggest packages with deep dependency trees. A simple utility might pull in 50 transitive dependencies. Scan the whole tree.
Setting policies without tooling. "Developers should check licenses" doesn't work at scale. Automate the check or it won't happen consistently.
Forgetting to update your AI agent's knowledge. If your AI coding assistant has a knowledge cutoff, it might suggest packages that were safe six months ago but have since been compromised or deprecated.
Next Steps
Start with items 1, 2, and 6. You need visibility (SBOM), control (least-privilege AI), and automated gates (vulnerability scanning) before the other controls add value.
Then add risk tiers (item 3) based on what you learn from your first month of dependency audits. You'll quickly identify which package ecosystems and maintainer patterns correlate with problems.
Finally, implement the policy enforcement (items 4, 5, 7, 8) once you have baseline data. Setting a 48-hour CRITICAL patch SLA is meaningless if you don't know your current mean-time-to-patch.
Your AI coding assistants will keep suggesting dependencies. This checklist ensures you know what's coming in and can manage the risk without slowing down development.
