Your AI coding assistant produces syntactically perfect code. It passes your linter. It looks clean in the PR review. And it’s harboring a missing authorization check that lets any authenticated user read anyone else’s data.
That’s the gap at the center of AI generated code security CI/CD pipeline design today: teams are patching a 2026 problem with 2020 tooling. According to Veracode’s 2025 GenAI Code Security Report, security pass rates for AI-generated code have stayed flat at 45–55% since 2023 — even as syntax pass rates climbed from ~50% to 95%. The code looks correct. It isn’t safe.
This guide gives you something most articles don’t: working, copy-paste GitHub Actions configuration using Gitleaks, Socket, and Semgrep that specifically targets the vulnerability patterns AI assistants introduce — along with the tuning guidance to prevent the alert fatigue that causes teams to disable their scanners entirely.
Why Your Existing Security Scanner Has a Blind Spot for AI-Generated Code
Most static analysis tools were trained and tuned on repositories of human-written code. They’re excellent at catching SQL injection in a Rails controller or buffer overflows in C. They’re built on the assumption that developers make certain kinds of mistakes in certain kinds of contexts.
AI assistants make different mistakes. And they make them consistently.
“Security pass rates for AI-generated code have remained flat at 45–55% since 2023, even as syntax pass rates climbed from ~50% to 95%. Larger models do not produce significantly more secure code than smaller ones.” — Veracode Spring 2026 GenAI Code Security Update
The failure mode isn’t a syntax error your linter catches. It’s structurally sound code with absent security primitives — routes that authenticate but never authorize, dependencies that don’t exist in any public registry, secrets baked into config files because the model optimized for a working example rather than a production-safe one.
At least 35 CVEs disclosed in March 2026 were directly attributed to AI-generated code, up from 6 in January 2026, with researchers at Georgia Tech’s Vibe Security Radar project estimating the true ecosystem count at 400–700 cases. A separate scan of 5,600 vibe-coded applications turned up 2,000+ vulnerabilities, 400+ exposed secrets, and 175 instances of exposed PII (Autonoma, 2026). Your existing scanner almost certainly has no rules calibrated for any of these patterns.
The Four Vulnerability Patterns AI Assistants Consistently Introduce
Before configuring a single tool, you need to understand what you’re hunting. These four patterns account for the vast majority of security failures in AI-generated code.
1. Hallucinated and slopsquatted dependencies
AI models recommend packages that don’t exist. A study of 576,000 code samples generated by 16 LLMs found nearly 20% of recommended packages were absent from any public registry — open-source models hallucinated at ~21.7%, and commercial models like GPT-4 still reached ~5% (University of Texas at San Antonio / Virginia Tech / University of Oklahoma, 2025).
The dangerous part: 43% of those hallucinated package names are repeated when the same prompt is reused across 10 queries. That consistency makes them reliable targets for attackers who register the fake package name with malicious code before your install step runs.
2. Hardcoded secrets
AI models optimize for runnable examples. Hardcoding an API key gets the code working. A scan of 100 AI-generated apps found 45% contained hardcoded secrets — API keys, JWT secrets, and database URLs sitting directly in source code (DEV Community, 2025). These don’t always appear in `config.js`. They show up in middleware, test setup files, and Docker entrypoints.
3. Missing authorization checks (IDOR)
This is the pattern traditional scanners miss most often. The AI writes a route that correctly validates authentication — the user is logged in — but never checks whether that user is permitted to access the requested resource. Veracode’s testing found AI-generated code produces 1.91x more insecure direct object references than human-written code.
4. Wildcard CORS with credentials
`Access-Control-Allow-Origin: *` combined with `Access-Control-Allow-Credentials: true` is an invalid combination per spec, yet it appears in approximately 70% of reviewed AI-generated codebases (PinkLime / GetShipReady, 2026). The AI produces it because it appears frequently in training data and makes demos work. It signals a broader pattern of security primitives copied without understanding.
The Tool Stack and Why Stage Ordering Is Non-Negotiable
The three tools doing the work here are:
- Gitleaks — secret detection across current files and full git history
- Socket — dependency behavior analysis that catches hallucinated and malicious packages before `npm install`
- Semgrep — customizable SAST with rules you write targeting AI-specific patterns
Every article that covers these tools treats selection and configuration as independent decisions. They’re not. Pipeline order is a security decision.
Gitleaks must run before any SAST tool. If a secret exists in the codebase, you want that finding isolated and surfaced first — before other scanner output buries it.
Socket must intercept before install. Running Socket after `npm install` means malicious code may have already executed in install scripts. Its entire job is to block the install from happening. Running it afterward defeats the purpose.
The correct order: `gitleaks → socket-scan → npm install → semgrep → build/test`
Running them out of sequence doesn’t only reduce effectiveness — it creates a false sense of safety, which is worse than running nothing.
Step 1 — Catching Hardcoded Secrets with Gitleaks (Pre-Commit + CI History Scan)
Gitleaks operates in two modes, and you need both.
The pre-commit hook catches secrets before they ever enter the repository:
“`bash
# Distribute via .pre-commit-config.yaml for team consistency
repos:
- repo: https://github.com/gitleaks/gitleaks
rev: v8.18.0
hooks:
- id: gitleaks
“`
The `pre-commit` framework ensures every developer on the team runs the same hook version without manual setup.
The CI stage with history scan closes a blind spot almost never addressed in how-to content: secrets that were added and then deleted. Deleting a secret from the current file doesn’t remove it from git history. Anyone with repository access — or anyone who accesses a leaked repository — can recover it with a single `git log` command.
Add this to your GitHub Actions workflow:
“`yaml
- name: Gitleaks Secret Scan (Full History)
uses: gitleaks/gitleaks-action@v2
with:
args: detect –source . –log-opts “–all” –redact -v
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
“`
The `–log-opts “–all”` flag scans every commit in the repository’s history, not only the current HEAD. This is the flag that closes the deletion blind spot. The `fetch-depth: 0` setting on your `actions/checkout` step is required for this to work — without it, Actions only fetches a shallow clone.
Step 2 — Blocking Slopsquatted Dependencies with Socket
Socket analyzes package behavior and metadata signals — network access, obfuscated code, install scripts, publish anomalies — rather than matching against a CVE database. This is why it catches hallucinated packages that Snyk and Dependabot miss: those tools require a known vulnerability record. A hallucinated package registered yesterday has no CVE.
Add Socket to your pipeline before any install step:
“`yaml
- name: Install Socket CLI
run: npm install -g @socketsecurity/cli
- name: Socket Dependency Scan (pre-install)
run: socket scan –strict –json > socket-report.json
# –strict exits non-zero on any high-severity finding
# This blocks the job before npm install runs
- name: Upload Socket Report
uses: actions/upload-artifact@v4
with:
name: socket-report
path: socket-report.json
- name: Install Dependencies
run: npm ci
# Only executes if Socket scan passed
“`
Treat any package flagged for `install-scripts`, `network-access`, or `obfuscated-code` as a hard blocker. Upload the JSON report as a workflow artifact so you maintain an audit trail without re-running the scan during incident review.
Step 3 — Writing Semgrep Rules That Target AI Anti-Patterns
Off-the-shelf Semgrep rules cover a lot of ground, but the IDOR and wildcard CORS patterns require custom rules because they’re patterns of omission — the absence of an authorization check, not the presence of a broken function. This is where Semgrep custom rules for AI code pay off.
Custom rule: IDOR (auth without authZ)
“`yaml
# .semgrep/ai-patterns.yaml
rules:
- id: auth-without-authz
patterns:
- pattern: |
app.$METHOD($PATH, $MIDDLEWARE, async ($REQ, $RES) => {
…
})
- pattern-inside: |
requireAuth(…)
- pattern-not: |
$REQ.user.id === $PARAMS.id
- pattern-not: |
hasPermission(…)
- pattern-not: |
checkOwnership(…)
message: >-
Route is authenticated but may lack authorization.
Verify resource ownership is checked before returning data.
languages: [javascript, typescript]
severity: ERROR
“`
Custom rule: Wildcard CORS with credentials
“`yaml
- id: cors-wildcard-with-credentials
pattern: |
cors({
origin: “*”,
credentials: true,
…
})
message: >-
Wildcard CORS combined with credentials is invalid per spec
and exposes your API to cross-origin attacks. Use an explicit
allowed origin list instead.
languages: [javascript, typescript]
severity: ERROR
“`
Save these to `.semgrep/ai-patterns.yaml` at your repository root. Then run Semgrep in your Actions pipeline:
“`yaml
- name: Semgrep SAST Scan
uses: semgrep/semgrep-action@v1
with:
config: >-
p/owasp-top-ten
p/secrets
.semgrep/ai-patterns.yaml
generateSarif: “1”
“`
Combining the OWASP ruleset with your custom rules gives you broad baseline coverage plus targeted detection for the patterns standard rulesets miss.
Putting It Together: Your AI Code Security CI/CD Pipeline YAML
Here’s the complete workflow. Copy this into `.github/workflows/security-gate.yml`:
“`yaml
name: AI Code Security Gate
on:
pull_request:
branches: [main, develop]
jobs:
secrets-scan:
name: Gitleaks — Secret Detection
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0 # Required for full history scan
- name: Gitleaks Full History Scan
uses: gitleaks/gitleaks-action@v2
with:
args: detect –source . –log-opts “–all” –redact -v
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
dependency-scan:
name: Socket — Dependency Behavior Analysis
runs-on: ubuntu-latest
needs: secrets-scan
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: ’20’
- name: Install Socket CLI
run: npm install -g @socketsecurity/cli
- name: Socket Scan (pre-install)
run: socket scan –strict –json > socket-report.json
- name: Upload Socket Report
uses: actions/upload-artifact@v4
with:
name: socket-report
path: socket-report.json
- name: Install Dependencies
run: npm ci
sast-scan:
name: Semgrep — SAST with AI Pattern Rules
runs-on: ubuntu-latest
needs: dependency-scan
steps:
- uses: actions/checkout@v4
- name: Semgrep Scan (Critical/High — Blocking)
uses: semgrep/semgrep-action@v1
with:
config: >-
p/owasp-top-ten
p/secrets
.semgrep/ai-patterns.yaml
generateSarif: “1”
- name: Upload SARIF to GitHub Security Tab
uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: semgrep.sarif
medium-low-findings:
name: Semgrep — Non-Blocking (Medium/Low)
runs-on: ubuntu-latest
needs: dependency-scan
continue-on-error: true # Never blocks the PR
steps:
- uses: actions/checkout@v4
- name: Semgrep Scan (Medium/Low — Informational)
uses: semgrep/semgrep-action@v1
with:
config: >-
p/default
.semgrep/ai-patterns.yaml
auditOn: push
“`
The `needs:` chain enforces ordering. Secrets must pass before dependencies are scanned; dependencies must pass before SAST runs. The `medium-low-findings` job runs in parallel with `sast-scan` but carries `continue-on-error: true` — findings are surfaced and logged but never block a merge.
Tuning for Signal — Blocking vs. Non-Blocking Jobs and Suppressing False Positives
A pipeline that produces 40 findings per PR will be disabled within two sprints. Tuning is the part most implementation guides skip, and it determines whether this security gate survives contact with your team.
The blocking/non-blocking split is already in the YAML above. Critical and high findings from your custom rules and the OWASP ruleset block the PR. Medium and low findings appear in the non-blocking job — visible in Actions, logged, but never a merge blocker.
Suppressing known false positives in Semgrep uses inline comments:
“`javascript
// nosemgrep: auth-without-authz
router.get(‘/public/status’, async (req, res) => {
// Intentionally unauthenticated — public health check endpoint
res.json({ status: ‘ok’ });
});
“`
Use suppressions sparingly, and require a comment explaining why the suppression is legitimate. Suppressions without explanation become invisible technical debt that nobody questions six months later.
Review your false-positive rate monthly. If more than 20% of critical/high findings on a given rule are being suppressed, that rule needs tightening. If a rule surfaces zero findings over 90 days, evaluate whether it’s still relevant or only adding scan time.
The goal is not zero false positives — it’s a false-positive rate low enough that developers trust the scanner and engage with its output rather than route around it.
Semgrep’s own benchmark data shows that targeted rules combined with active tuning reduce false positives by 25% and increase detected true positives by 250% versus baseline pattern-only scanning (Semgrep / We45 analysis). Those gains don’t come from the tool alone — they come from the tuning discipline your team maintains.
Conclusion
Building a reliable AI generated code security CI/CD pipeline isn’t about picking any scanner — it’s about matching the right tool to each vulnerability class, sequencing them correctly, and tuning them so developers engage rather than disable. Gitleaks closes the secrets blind spot across current files and git history. Socket intercepts hallucinated and malicious packages before they install. Semgrep custom rules target the specific anti-patterns AI assistants reliably produce.
The pipeline above is a starting point, not a finished product. Run it for two weeks, identify which rules are generating the most suppression noise, and tighten them. The goal is a pre-merge security gate your team trusts — one that surfaces real risks in AI-generated code before they reach production.
Start by adding the Gitleaks history scan to an existing workflow. One job, fifteen minutes of setup, and you’ll likely surface something that’s been sitting in your git history longer than you’d want.