How to Scan AI-Generated Code for Vulnerabilities Before Merge

How do you scan AI-generated code for vulnerabilities before merge?

To scan AI-generated code for vulnerabilities, wire three automated checks into your CI pipeline as required status checks: a dedicated secrets scanner, a software composition analysis (SCA) step that verifies every dependency actually exists, and a SAST scan running in blocking mode. None of this works as a suggestion. It only works as a gate that nothing merges past until it passes.

That's the short version. Here's why, and how to build it.

Why does AI-generated code need a different security gate?

AI coding assistants are no longer a developer tool. They're a company-wide one. Across the business, people who've never shipped software before are using Copilot, Cursor, or Claude Code to build internal dashboards, scripts, and small apps, often without IT ever knowing. Roughly 78% of employees use AI tools their IT department hasn't approved, and 46% say they'd keep using them even if the company banned them outright.

That matters because the code these tools produce doesn't fail the way human code fails. GitGuardian detected 28.65 million new hardcoded secrets in public GitHub commits in 2025, a 34% jump year over year and the largest single-year increase it has recorded in five years of tracking. Commits assisted by Claude Code leaked secrets at roughly 3.2%, about double GitHub's overall baseline of around 1.5%.

Volume compounds it. Apiiro's analysis of enterprise repositories found AI-assisted teams shipped code roughly four times faster, but their pull request volume fell by nearly a third while the security findings in that smaller volume of code rose roughly tenfold. Faster, bigger, and riskier at once is exactly the pattern that breaks manual code review.

What security risks are unique to AI-generated code?

Two risks show up in AI-generated code that have no real equivalent in code a person types line by line.

• Hardcoded secrets. Models default to inline credentials and placeholder keys because that's the fastest way to make a demo "work." Leaks tied to AI service credentials, like API keys and LLM tokens, grew 81% year over year to 1,275,105 in 2025. A big share of that comes from one specific habit: MCP server configuration files alone exposed 24,008 unique secrets, because MCP's own documentation often recommends putting credentials straight into config files.
• Slopsquatting (hallucinated dependencies). A USENIX Security 2025 study generated 2.23 million code samples across 16 LLMs and found that 19.7% contained at least one hallucinated package name, totaling 205,474 unique fabricated packages. Open-source models hallucinated at 21.7%, versus 5.2% for commercial models. Attackers exploit the fact that these fake names repeat predictably across prompts and models, so they pre-register the name on PyPI or npm before anyone installs it, turning a hallucination into a working supply chain attack. We cover the mechanics of this in the slopsquatting risk breakdown.

A third, newer pattern is worth knowing: attackers hide malicious instructions using invisible Unicode characters inside AI agent rules files, like Cursor rules or CLAUDE.md, so every subsequent AI-generated session is silently compromised without anyone noticing a change.

How do you scan for secrets at every commit and pull request?

Run a secrets scanner at two points: a pre-commit hook on the developer's machine, and a required CI job on every pull request. Tools like Gitleaks, TruffleHog, or GitGuardian are built for exactly this.

Don't assume your SAST tool already covers it. Secret detection depends on continuously updated regex patterns, entropy heuristics, and live credential verification, things general-purpose static analysis engines aren't optimized for. TruffleHog's verified-detector approach, for example, makes a real API call against services like AWS, Stripe, or Slack to confirm whether a found credential is actually still valid, across more than 700 detectors. That distinction between "looks like a key" and "is a live key" tells you whether a finding needs an emergency rotation or just a cleanup.

Retire the assumption that private repos are safer. Internal repositories are roughly six times more likely to contain hardcoded secrets than public ones, because teams treat "private" as a substitute for "secure." Scan everything, not just what's public.

How do you gate dependencies against hallucinated and malicious packages?

Treat every package name an AI assistant suggests as untrusted input, the same way you'd treat an unverified user upload. Before anything installs:

1. Pin lockfiles. Lock exact versions so a dependency can't silently resolve to something that didn't exist last week.
2. Verify package existence and publish history. Confirm the package has a real, aged publishing history before it enters your build, not just that the name resolves on the registry.
3. Use a package firewall or allowlist. Block installs of anything outside an approved list by default, and route new requests through a quick manual check instead of letting CI pull them automatically.
4. Flag AI-suggested dependencies for extra scrutiny. If a package name came out of a prompt rather than a known internal standard list, it gets a second look before merge, no exceptions.

This is where SCA earns its place alongside secrets scanning and SAST. It solves a different problem than either, and skipping it is how a hallucinated name becomes a live malware install.

How should you run SAST on every AI-authored pull request?

Configure your SAST tool in blocking mode so specific rule violations fail the check and stop the merge, not just flag a warning someone can ignore. Semgrep and comparable platforms support this directly: select the ruleset, set it to block, and it applies to every scan going forward.

Scope the ruleset to the vulnerability classes AI-generated code actually tends to introduce. Veracode tested more than 100 LLMs against 80 coding tasks and found that 45% of samples introduced an OWASP Top 10 vulnerability. That number gets worse for specific categories: 72% for Java and 86% for cross-site scripting checks specifically. A narrower, well-tuned ruleset catches those patterns without drowning reviewers in noise on everything else.

Keep PR size limits in place too. Apiiro's data on falling PR volume paired with rising defect counts is a reminder that bigger AI-generated diffs are harder for both humans and tools to review accurately. The guide to reviewing AI-generated code before it ships walks through acceptance gates built for volume rather than vibes.

How do you enforce it with branch protection and required status checks?

None of the above matters if any of it is optional. On GitHub, branch protection rules with required status checks block a pull request from merging until the designated jobs, your secrets scan, SCA step, and SAST run, report success. GitLab has an equivalent in merge request pipelines.

A few practical notes when setting this up:

• Name jobs uniquely across workflows. GitHub's own guidance flags that required status check names need to be unambiguous, or the protection rule can't match the right job.
• Account for merge queues. If you run a merge queue, confirm the required checks re-run against the queued merge commit, not just the original branch head.
• Lock down bypass permissions. Admin override exists for emergencies. If it's available by default to anyone with write access, it isn't a gate, it's a suggestion.

This is the mechanical enforcement point that turns a security policy into something that actually happens on every PR, including the ones written entirely by someone outside the engineering org.

How do you close the loop with SBOM, rotation, and ownership?

Scanning catches what's new. It doesn't fix what's already loose. GitGuardian's research found that nearly 70% of secrets confirmed valid in 2022 were still active and unrevoked as of January 2025, and 64% remained exposed and unrevoked a year after that. Detection without rotation just means you know about the exposure, not that you've closed it.

Build this into standard practice:

1. Generate an SBOM for codebases with meaningful AI-assisted contributions, so you have an actual inventory, not a guess, of what's in production.
2. Write a credential rotation playbook that triggers automatically on any verified secret leak, not one that waits for a quarterly audit.
3. Assign explicit ownership for every internal tool employees build with AI, so a leaked key or a slopsquatted package has someone accountable for fixing it instead of sitting in an orphaned repo nobody checks.

That ownership piece matters more as more non-engineers build real software. If your organization lets employees build internal tools with AI platforms, the same gates described here should sit underneath those platforms too, not instead of them. A tool that makes building easy doesn't make the resulting software exempt from scanning. The governance guide for employee-built AI apps goes deeper on keeping that kind of self-built software accountable.

What does this gate catch that code review alone misses?

Manual review was already missing a lot before AI entered the picture. A 2021 Stanford/NYU study of GitHub Copilot found that roughly 40% of 1,689 generated programs across 89 security-relevant scenarios contained exploitable vulnerabilities tied to MITRE's CWE Top 25, and reviewers weren't catching most of it by eye. AI-generated code just raised the stakes and the volume on a gap that already existed.

A pre-merge pipeline of secrets scanning, dependency verification, and blocking SAST isn't about distrusting AI coding tools. It's about building the same accountability layer for AI-assisted and employee-built software that engineering teams already expect for their own code. Shadow AI isn't going away, and banning it only pushes the risk somewhere less visible. Gating the merge is the part that actually works.