Vibe Coding and Security Code Review:
Why AI-Generated Code Demands Mandatory SAST.

Why the Security Review Model Is Broken for Vibe Coding

Security code review is built on assumptions that hold in traditional development: developers commit code they understand, reviewers can evaluate the intent of changes, and review throughput is roughly proportional to development throughput.

Vibe coding invalidates all three assumptions:

• Developers don't understand every line — by definition, vibe-coded code includes implementations the developer didn't write and may not fully comprehend
• Reviewers can't evaluate intent for AI output — when a PR contains 500 lines of AI-generated code, a reviewer is seeing that code for the first time alongside the PR author
• Review throughput doesn't scale — AI coding 5× developer velocity means 5× the code to review with the same number of reviewers; review becomes a bottleneck or gets rushed

Common Security Failures in AI-Generated Code

Understanding where AI consistently fails helps calibrate security testing focus. Research and empirical analysis consistently find:

• Cryptographic mistakes — using outdated algorithms (MD5, SHA1), incorrect modes (ECB), and insufficient randomness for key material
• Input validation gaps — AI generates code that handles the happy path correctly but omits validation for edge cases: null inputs, overlong strings, special characters
• SQL injection through string formatting — AI frequently generates database queries with f-strings or string concatenation rather than parameterised queries, especially in Python
• Hardcoded values — placeholder credentials, API endpoints, and timeout values that were appropriate for a proof-of-concept end up in production code
• Insecure defaults in configuration code — generated configuration often enables all options rather than following least-privilege principles
• Missing authorisation checks — AI generates the core logic of an endpoint without the surrounding authorisation middleware

SAST as the Primary Security Gate

SAST scales with code volume in a way that human review does not. A SAST scanner runs in the same time regardless of whether the PR is 50 lines or 5000 lines. This makes it the natural primary security control for vibe coding environments.

For SAST to serve this role effectively, it needs to be:

• Blocking — SAST must gate the PR merge, not just report findings. In a vibe coding environment where reviewers are under pressure, advisory-only findings get deferred indefinitely.
• Fast — if SAST adds 20 minutes to a PR cycle, it creates pressure to skip it. Target under 5 minutes for PR-time scanning.
• Low false-positive rate — high false-positive rates train reviewers to dismiss findings; tune for precision over recall in SAST rules used as merge gates
• Tuned for AI code patterns — generic SAST rules miss AI-specific failure modes; rules must be calibrated for the patterns AI models consistently produce

SAST Rules Tuned for AI Code Patterns

Beyond standard SAST rules, vibe coding environments benefit from rules specifically targeting AI code failure modes:

rules:
  - id: ai-sql-fstring-injection
    patterns:
      - pattern: cursor.execute(f"... {$VAR} ...")
      - pattern: cursor.execute("..." + $VAR + "...")
      - pattern: cursor.execute("...%s..." % $VAR)
    message: SQL query constructed with string formatting
    severity: ERROR
    metadata:
      ai-pattern: true  # Common in AI-generated code

Additional high-value rules for AI code:

• Weak hash usage in authentication context: hashlib.md5(password), hashlib.sha1(password)
• Math.random() / random.random() used for token/session generation
• Hardcoded credential patterns in any context
• Missing authorisation decorator on route handlers
• eval/exec with non-constant arguments

Where to Focus Human Security Review

In vibe coding organisations, human security review time is a scarce resource that must be allocated strategically. Focus it where automated scanning has the highest false-negative rates:

• Business logic and authorisation design — SAST cannot assess whether the authorisation model is correct for the business requirements; only a human who understands both can
• Cryptographic architecture — the choice of algorithm and key management approach requires expert judgment beyond what SAST rules check
• Any PR touching authentication, session management, or access control — these areas have the highest blast radius from mistakes
• Third-party integrations and API clients — how secrets are passed, whether responses are validated, and how errors are handled
• Infrastructure and configuration code — IaC generated by AI needs security review as much as application code

Security Review Process for Vibe Coding Teams

A practical process that balances security and velocity:

1. Automated gate on every PR: SAST + SCA + secrets scanning. Must pass before merge. No exceptions.
2. AI code labelling: PRs containing AI-generated code (>20% AI authorship by volume) get an ai-generated label triggering enhanced review rules
3. Risk-tiered human review: Low-risk PRs (UI changes, non-security utility code) merge after passing automated gates. Medium-risk PRs (new features, dependency changes) require one human reviewer. High-risk PRs (auth, crypto, access control) require security engineer review.
4. Post-merge scanning: Run deeper SAST analysis on merged code nightly; findings become security debt tickets rather than merge blockers
5. Periodic red-team exercise: Quarterly review of AI-generated code in security-critical areas by a security engineer who wasn't in the original review flow