Ask any developer who ships code weekly and they'll tell you the same thing: AI coding assistants have quietly become the most productive junior engineer on the team. GitHub reported that Copilot users accept roughly 30% of its suggestions, and a 2024 survey from Stack Overflow found that 76% of developers were using or planning to use AI tools in their workflow. That's a staggering amount of machine-authored code flowing into production.
Here's the uncomfortable part. When an AI model suggests import leftpad from 'left-pad' or pins a package version it hallucinated, it doesn't know whether that dependency is maintained, malicious, or entirely fictional. Security researchers have documented "slopsquatting," where attackers register the fake package names that LLMs invent, then wait for someone to install them. One study found that popular models hallucinated non-existent package names in up to 20% of code samples. Every one of those is a supply chain landmine.
This guide walks through how to audit AI-generated code for supply chain risks in a practical, repeatable way. You'll get a worked example with real numbers, a comparison of scanning tools, and a step-by-step audit workflow you can run on your next pull request. No theory-heavy lectures, just the checks that actually catch problems before they reach your users.
Key Takeaways
- Treat AI output as untrusted input. Every dependency an assistant suggests needs the same scrutiny as code from an unknown contributor.
- Verify packages exist and are maintained before installing. Hallucinated and slopsquatted package names are a real, growing attack vector.
- Generate an SBOM (software bill of materials) for every build so you know exactly what you shipped.
- Pin and lock dependencies with hashes, not floating version ranges that let a compromised update slip in.
- Automate the boring parts with SCA scanners in CI, but keep a human review gate for anything an AI touched.
- Audit transitive dependencies, not just the ones you named. Most risk hides two or three levels deep.
Why AI-Generated Code Is a Supply Chain Problem
Supply chain risk used to mean worrying about the libraries you deliberately chose. AI changed the shape of that risk. Now the code that selects your dependencies is itself probabilistic and prone to confident mistakes.
Three failure modes matter most:
- Hallucinated packages. The model invents a plausible-sounding library that doesn't exist. If an attacker has registered that name first, your
npm installpulls malware. - Outdated or vulnerable suggestions. Models are trained on snapshots of the internet. They happily recommend a version of a package that was patched for a critical CVE two years ago.
- Insecure patterns copied wholesale. AI reproduces the average of what it learned, including hardcoded secrets, disabled TLS verification, and SQL string concatenation.
The reason this is a supply chain issue rather than a plain code-quality one is scale. A single accepted suggestion can add a dependency tree with hundreds of transitive packages. You didn't review those. The AI didn't either. That's how one bad line becomes a systemic exposure.
If you're already thinking about how to vet automated agents, the same instincts apply here as when you vet AI HR agents before letting them touch employee data. The tool is helpful, but trust is earned through verification, not assumed.
What a Supply Chain Audit Actually Checks
An audit isn't a single scan. It's a layered set of questions you answer about every artifact the AI produced. Here's the mental checklist I run through.
1. Provenance
Where did this dependency come from? Is the package name real, spelled correctly, and published by a legitimate maintainer? A name that's one character off from a popular package (reqeusts vs requests) is a classic typosquat.
2. Integrity
Does the installed artifact match a known-good hash? Lockfiles with integrity hashes (like npm's integrity field or a requirements.txt with --hash) let you detect tampering between install runs.
3. Known vulnerabilities
Does any package, direct or transitive, carry a published CVE? This is where software composition analysis (SCA) tools earn their keep by cross-referencing your dependency tree against vulnerability databases.
4. Maintenance health
Is the package abandoned? A library with no commits in three years and a single maintainer is a takeover risk, exactly the kind of scenario that leads teams to harden their plugins against takeover exploits.
5. Secrets and insecure code
Did the AI leave an API key, a weak crypto call, or an injection-prone query in the generated code itself?
A Worked Example: Auditing an AI-Generated API Client
Let's make this concrete. Say your assistant generated a Node.js module to call a payment API. It produced 214 lines of code and a package.json with 6 direct dependencies. Here's what the audit surfaced.
Step 1 — Verify every direct dependency exists and is correct. Five checked out. The sixth, axios-retry-helper, didn't exist on npm at all. The model had confused it with the real axios-retry. Had an attacker registered axios-retry-helper the day before, I'd have installed it blind. Caught: 1 hallucinated package.
Step 2 — Expand the tree. Those 5 legitimate direct dependencies pulled in 143 transitive packages. So the AI effectively made 143 decisions I never reviewed.
Step 3 — Run an SCA scan. npm audit flagged 4 vulnerabilities: 1 critical (a prototype pollution issue in a nested package), 2 moderate, and 1 low. The critical one traced back to a version the AI pinned that was released before the fix.
Step 4 — Scan for secrets. A regex sweep found a hardcoded test API key the model had helpfully "filled in" from its training data. That key belonged to someone else's Stripe test account.
Step 5 — Review insecure patterns. The retry logic disabled TLS certificate validation with rejectUnauthorized: false. Convenient. Also a man-in-the-middle waiting to happen.
Final tally on 214 lines of generated code:
- 1 hallucinated package (would've failed install, or worse, installed malware)
- 1 critical + 3 lesser CVEs in the dependency tree
- 1 leaked third-party secret
- 1 disabled security control
That's five findings from a five-minute prompt. Every one of them is exactly the kind of thing that never shows up when you eyeball code and think "looks fine."
Tools to Audit AI-Generated Code: A Comparison
No single tool covers everything, so most teams stack two or three. Here's how the common options compare across the checks that matter.
| Tool | Hallucinated packages | Known CVEs | Secret detection | SBOM output | CI integration |
|---|---|---|---|---|---|
| npm audit / pip-audit | No | Yes | No | Partial | Easy |
| OWASP Dependency-Check | No | Yes | No | Yes | Moderate |
| Snyk | Partial | Yes | Partial | Yes | Easy |
| Trivy | No | Yes | Yes | Yes | Easy |
| gitleaks / TruffleHog | No | No | Yes | No | Easy |
The honest takeaway: no scanner reliably catches hallucinated packages on its own. That check still relies on a human verifying the package exists and is legitimately maintained before you ever run install. Combine an SCA scanner (Trivy or Snyk) with a secret scanner (gitleaks) and a manual provenance check, and you cover the realistic threat surface.
If you're evaluating dedicated tooling, it's worth browsing the AI Tools category alongside broader desktop utilities to see what integrates with your stack rather than assuming one vendor does it all.
A Step-by-Step Audit Workflow You Can Run Today
Here's the workflow I use on any branch where an assistant contributed code. It takes about ten minutes once and can be mostly automated after that.
- Diff what the AI changed. Isolate the AI-authored lines with
git diff. You want to know precisely what to scrutinize rather than reviewing the whole repo. - List every new dependency. Compare the old and new lockfiles. For each added package, confirm the exact name on the official registry and check its download count, last publish date, and maintainer.
- Reject anything suspicious. Zero downloads, published yesterday, a name close to a popular package, or no source repository link are all red flags. Do not install to "just check."
- Generate an SBOM. Run a tool like
syftor Trivy to produce a CycloneDX or SPDX bill of materials. This is your record of exactly what shipped. - Scan for CVEs. Feed the SBOM or lockfile to your SCA scanner. Triage anything critical or high before merging.
- Sweep for secrets. Run gitleaks or TruffleHog across the diff. AI models leak keys from training data more often than you'd expect.
- Review the code itself. Look specifically for disabled TLS checks, string-built SQL,
eval, overly broad permissions, and unvalidated input. - P
Cover image: The Torch Graduate circuit board (bottom) by Chris Whytehead, licensed under BY-SA 3.0 via Openverse.
