The Modern Security Review Stack

1The Security Review Challenge

Modern applications face a paradox: codebases are larger and more complex than ever, security threats are more sophisticated, and development cycles are faster. Manual security review doesn't scale. But automated tools miss critical vulnerability classes.

The solution isn't choosing between automation and expertise—it's layering them strategically. This guide examines three complementary approaches to security review and shows how they work together.

The series Introduction catalogs sixteen failure modes that affect agentic AI workflows for software development. The three-layer security model presented here is a direct response to those failure modes: SAST catches pattern-based issues that an AI agent might hallucinate past (phantom grounding), AI-orchestrated review addresses the silent corruption modes—goal substitution, invisible assumptions, completeness gaps—that pattern matching fundamentally cannot detect, and human oversight provides the accountability layer that counters automation complacency, the tendency to rubber-stamp agent output after repeated positive experiences.

2The Three Layers

3SAST: What It Does Well

Static Application Security Testing tools—Semgrep, SonarQube, CodeQL, Checkmarx, Fortify, Snyk Code—have been the backbone of automated security for over a decade. They excel in specific scenarios:

Pattern Detection at Scale

SAST tools maintain extensive rule libraries for known vulnerability patterns:

# Semgrep rule example: SQL injection detection
rules:
  - id: sql-injection
    patterns:
      - pattern: execute($QUERY)
      - pattern-not: execute($QUERY, $PARAMS)
    message: "Potential SQL injection: use parameterized queries"
    severity: ERROR

These rules catch obvious mistakes instantly. A developer writes execute(f"SELECT * FROM users WHERE id = {user_id}"), and the tool flags it before the code leaves their machine.

CI/CD Integration

SAST tools produce deterministic results—same code, same findings, every time. This makes them ideal for automated gates:

# GitHub Actions example
security-scan:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v3
    - name: Run Semgrep
      uses: returntocorp/semgrep-action@v1
      with:
        config: p/security-audit
    - name: Block on high severity
      if: steps.semgrep.outputs.findings != ''
      run: exit 1

Where SAST Falls Short

SAST tools fundamentally operate through pattern matching. They recognize "code that looks dangerous" but cannot assess "code that behaves dangerously in context."

Context Blindness

# SAST flags this as SQL injection
table_name = get_table_from_allowlist(request.table)  # Returns "users" or "orders"
query = f"SELECT * FROM {table_name} WHERE id = ?"
cursor.execute(query, [user_id])

# But it's actually SAFE because:
# 1. table_name comes from a hardcoded allowlist
# 2. The WHERE clause uses parameterized query
# SAST can't trace the allowlist constraint

Authorization Logic

# SAST sees nothing wrong here
@app.get("/api/documents/{doc_id}")
def get_document(doc_id: int, user: User = Depends(get_current_user)):
    return db.query(Document).filter(Document.id == doc_id).first()

# But there's a critical flaw:
# No check that user is authorized to access this specific document
# This is an IDOR vulnerability—SAST cannot detect it

Cross-Boundary Data Flow

When user input travels through message queues, microservice calls, or database round-trips, SAST tools lose track. A malicious payload stored in a database and retrieved by another service won't be flagged as tainted.

4AI Review: Filling the Gaps

AI-orchestrated security review uses large language models to analyze code with contextual understanding. Rather than matching patterns, the AI reasons about what code does and whether that behavior is secure.

Contextual Understanding

Where SAST sees a dangerous pattern, AI review sees the full context:

# AI Review Analysis:
# 
# Examining: query = f"SELECT * FROM {table_name} WHERE id = ?"
#
# Tracing table_name backward:
# - Line 12: table_name = get_table_from_allowlist(request.table)
# - get_table_from_allowlist() returns only "users" or "orders" (line 45-48)
# - User-controlled input (request.table) is validated against allowlist
# - SQL injection not possible for table name
# 
# Checking parameterization:
# - WHERE clause uses ? placeholder with separate params
# - user_id passed as parameter, not interpolated
#
# Finding: FALSE POSITIVE - table name constrained by allowlist,
# value parameterized. No SQL injection vulnerability.

Business Logic Analysis

AI review can detect vulnerabilities that require understanding intent:

# AI Review Analysis:
#
# Examining: GET /api/documents/{doc_id}
#
# Authorization check present: ✓ (get_current_user dependency)
# User authenticated: ✓
# 
# Access control check: ✗ MISSING
# - Function retrieves document by ID only
# - No verification that requesting user owns/can access document
# - Any authenticated user can access any document by ID
#
# Finding: HIGH - Insecure Direct Object Reference (IDOR)
# Attack scenario: Authenticated user changes doc_id parameter
# to access other users' documents.
#
# Recommended fix: Add ownership check
#   document = db.query(Document).filter(
#       Document.id == doc_id,
#       Document.owner_id == user.id  # ADD THIS
#   ).first()

Adaptive Methodology

AI review generates checklists tailored to the specific technology stack and threat model. A review of a multi-tenant SaaS application handling healthcare data will include different checks than a single-tenant internal tool:

# Generated checklist items for multi-tenant healthcare SaaS:

TENANT-01: Verify tenant ID in JWT claims validated on every request
TENANT-02: Check all database queries include tenant filter
TENANT-03: Review admin cross-tenant access controls
PHI-01: Verify PHI fields excluded from logs
PHI-02: Check encryption at rest for PHI columns
PHI-03: Review PHI access audit trail implementation
...

Where AI Review Has Limitations

• Speed — AI analysis is slower than pattern matching; not suitable for every commit in high-velocity repos
• Cost — LLM inference costs more than running static rules
• Consistency — Results may vary slightly between runs (though structured workflows mitigate this)
• Complex Control Flow — Deeply nested conditionals or unusual patterns may confuse analysis
• Dependencies — Cannot scan vulnerability databases for known CVEs (that's SCA tooling)

5Comparison Matrix

This matrix shows which approach is strongest for each vulnerability class:

6The Integrated Workflow

The optimal approach layers these tools strategically, using each where it's strongest:

Cost-Benefit Optimization

7This Series: AI-Orchestrated Security Review

The series Introduction established a taxonomy of sixteen failure modes that affect agentic AI workflows and five structural principles that address them. The remaining parts of this series build the AI layer—structured, repeatable workflows for AI-assisted security review using Claude Code. Each part builds on the previous:

8Frequently Asked Questions