AI Code Security Scanning: From Alerts to Evidence

Overview

Traditional code scanners are good at producing alerts. The hard part is everything that happens after: deciding whether the finding is real, whether it matters in this system, how to fix it, and whether the fix worked.

That is where model-based code security scanning changes the workflow. The model is not just looking for suspicious code. It follows the data, considers the architecture and deployment context, and asks whether a real attack can be demonstrated.

The unit of work changes from:

Does this line match a known-bad pattern?

to:

Given how this system is actually built, what could an attacker do, and can I demonstrate it?

That reframing enables the rest of the pipeline: threat modeling, adversarial verification, chain analysis, patch generation, and fix validation.

A quick caveat: Model-based scanning does not have to replace every deterministic rule. Lightweight rules can still serve as fast filters, especially in Continuous Integration (CI). The shift is that models take over the work SAST often struggles with: proving reachability, understanding business logic, reasoning about trust boundaries, and producing validated fixes.

From Pattern Matching to Reasoning

Traditional static analysis (SAST) often leaves three gaps that model-based scanning directly addresses:

1. Rules versus reasoning. Rules engines only find vulnerability classes someone already encoded and cannot evaluate business logic. A model reasons over entry points and data flows in your specific codebase to surface unscripted security logic flaws.

2. Noise versus judgment. Pattern-driven scanners often report suspicious code before the full reachability story is settled. A model evaluates reachability during triage and discards unprovable findings, reducing false positives.

3. Alerts versus proof. Classic SAST hands you a file location and a category. Model-based scanning verifies exploitability, ranks risk in context, proposes a patch, and confirms the fix closed the issue.

The trade-off is important. A rules engine is deterministic and cheap. A model is probabilistic, so you should not trust the first response without verification. As explored in my AI-assisted development workflow and autonomous LLM guardrails articles, the discipline is sequencing: first establish evidence and priority through threat modeling, adversarial verification, and operational questions, then engineers use that order to review patches and deliver fixes with AI assistance.

Why Context Files Matter

Source code shows endpoints, queries, and authorization checks, but cannot prove deployment facts or runtime controls. Context files answer those questions before a single line of code is read:

• Deployment & Exposure: Cloud/on-prem, container boundaries, public vs. internal access, WAFs, reverse proxies, and private subnets.
• Identity & Data Controls: IdP enforcement (Okta, Active Directory), RBAC boundaries, row-level security, tenant filters, and database constraints.
• Scope & Design Intent: In-scope environments, sensitive data boundaries, and intentional trade-offs driven by volume, latency, or legacy integrations.

A finding behind a private subnet, reverse proxy, and database-enforced tenant check carries lower risk than the same pattern on a public endpoint. Accurate context sharpens findings and reduces false alarms. Inaccurate context makes the pipeline confidently wrong.

The Pipeline

Model-based scanning operates in two distinct phases: a cached Plan Phase (surveying build/deployment roots and establishing shard boundaries) and an Execute Phase (scanning shards, merging findings, threat modeling, triaging, patching, and analyzing attack chains).

Figure: The two-phase model-based scanning architecture, separating cached shard planning (Plan Phase) from interview-driven scanning, deduplication, full threat modeling, patching, and post-patch chain analysis (Execute Phase).

P1-P2. Plan Phase: Survey the Codebase and Define Shards

The survey pass detects build roots, deployment configs, and entry points to partition the codebase into shards: bounded slices of 30 to 40 files, small enough to scan deeply in one pass. It also defines seam sweeps across boundary files. The resulting shard plan is cached and reused across future scans, keeping partitioning deterministic over time.

E1. Context and Engagement Interview

The execution phase loads context files and asks targeted scoping questions to capture facts code cannot reveal: trust perimeters, authorization boundaries, sensitive data locations, and deployment assumptions. This forms the scoping context for downstream threat modeling and triage.

E2. Scan Shards and Boundaries for Vulnerabilities

Vulnerability detection fans out in parallel across isolated shard processes. Concurrently, inline researchers run boundary sweeps over seam files. Shard agents focus deeply on local logic, while seam researchers hunt for join-dependent vulnerabilities between components.

E3. Merge and Semantic Deduplication

Findings from all shard processes and boundary sweeps are collected into a central workspace. A semantic-deduplication pass merges identical or adjacent issues, collapsing symptoms stemming from the same root cause into a single finding.

E4. Full-Depth Threat Modeling

The pipeline constructs a codebase-wide threat model by folding in scoping interview answers and merged finding context. Findings in subsystems handling sensitive records receive higher exploitability weighting than patterns in isolated, multi-guarded components.

E5. Triage and Adversarial Verification

Candidate findings are evaluated against the threat model by verifier ensembles dynamically matched to the vulnerability type:

• Auth & Access Control: Verifies session token claims, RBAC boundaries, and state transitions.
• Injection (SQLi, Command, SSRF): Traces taint flows from inputs to sinks and checks sanitization.
• Business Logic & Memory: Simulates boundary guards and state machine edge cases.

An evidence gate evaluates verifier outputs. A candidate finding only survives if at least one verifier produces a defensible reachability or exploitability argument that independent reviewers fail to refute. The entire verification pipeline runs autonomously until the list of surviving vulnerabilities is produced.

Figure: Multi-verifier adversarial verification: candidate findings are routed to verifier ensembles matched to the vulnerability type, passing through an evidence gate before surviving to triage.

E6. Patch Generation and Review

For confirmed findings, a patch agent generates candidate fixes using full architectural context. An independent reviewer agent evaluates the diff before human review, ensuring author and reviewer separation to catch blind spots. Patches remain inert diffs until human approval.

E7. Chain Analysis Across Candidate Fixes

Attackers combine smaller findings across services into multi-step breach paths. Chain analysis operates in two passes: pre-patch chain analysis prioritizes remediation chokepoints that break the most attack chains, while post-patch chain analysis verifies whether any multi-step exploit paths remain across candidate fixes.

E8. Operational Checks, Fix Verification, and PR Delivery

The pipeline isolates deployment questions (WAF coverage, reverse proxies, private subnets) rather than assuming worst-case scenarios. Those answers adjust chain severity and remediation priority first.

After priority is settled, the pipeline re-runs the adversarial verifiers against each candidate patch to confirm the finding no longer reproduces. Engineers then review the verified patches in order, and for human-approved fixes, they can have AI create feature branches and open PRs in the normal review queue.

Why the Velocity of Fixing Goes Up

Traditional scanning wastes developer time on manual handoffs: sorting through large alert volumes, filtering false positives, verifying reachability, designing fixes, and building regression tests.

Model-based scanning compresses this overhead. Findings arrive verified, prioritized by threat-model exploitability and operational context, and paired with candidate patches.

Just as important, review becomes interactive: engineers can ask the model to explain a vulnerability or attack chain, provide missing context, challenge severity, and refine the fix. Engineers still decide what ships. The difference is that they are reviewing evidence, not deciphering a raw alert.

Model-Based Scanning in the Wild

• Anthropic (Claude Code Security): Multi-agent scanning that reasons about data flows to catch business logic flaws, generating patch files and integrating via the claude-code-security-review GitHub Action.
• OpenAI (Aardvark): Autonomous security researcher that threat models projects, confirms exploitability, and generates patches.
• Google DeepMind (Big Sleep & CodeMender): Discovery agents combined with remediation agents that rewrite vulnerable code and validate fixes.

The common thread across these efforts is the shift from pattern matching to evidence-backed security review.

You Can Also Roll Your Own

Building this workflow with general-purpose LLM building blocks (model, sandbox, multi-agent orchestrator) provides three key advantages over hosted scanners:

1. Context Control: Your real threat model, exposure, and deployment facts.
2. Data Ownership: Complete privacy for proprietary or air-gapped codebases.
3. Custom Gates: Tailored trust boundaries, review thresholds, and severity bars.

Key Takeaways

• Model-based code security scanning is a security review workflow encoded as a pipeline: understand how the system is built and deployed, ask what an attacker could do, prove whether it is real, fix it, and verify the fix.
• Traditional SAST can still help with cheap filtering. Models earn their cost by turning pattern or data-flow alerts into verified evidence: reachability, business logic, trust boundaries, deployment facts, and exploitability.
• Adversarial verification and chain analysis turn noisy findings into an ordered remediation plan: keep what can be defended, then fix the chokepoints that break real attack paths.
• Context files are the biggest quality lever. Accurate context sharpens findings; inaccurate context makes the pipeline confidently wrong.
• The velocity gain comes from removing human handoffs: findings arrive verified and prioritized first, then paired with candidate patches so engineers review and accept what fits instead of starting from raw alerts.

The goal is not more alerts. It is fewer findings, backed by evidence, ordered by risk, and paired with fixes engineers can review.