AI-Assisted Source Code Review for Vulnerability Discovery

AI-assisted source code review is a genuine advance in vulnerability discovery because it extends the analysis expert reviewers can do. It can examine attack paths and logic flaws that pattern-based scanners and crash-focused testing miss. But discovery is only the start. A finding becomes useful when a human expert has tested it, understood it and shown it to be exploitable.

Why vulnerability discovery has entered a new phase in 2026

IBM X-Force’s 2026 analysis found a sharp rise in the number of publicly disclosed CVEs across Oracle, Microsoft, Google Chrome and Apache. Disclosure volumes had tracked historical baselines through Q1 2026 before accelerating from April onward. The timing aligns with wider use of frontier AI models by security researchers and organizations. The data gives security teams a concrete reason to reconsider assumptions about the volume of vulnerabilities they must handle.

Historically, discovery constrained much of that work. Finding vulnerabilities and identifying exposed assets shaped how teams spent their time. AI-assisted research changes the balance by making it cheaper to find candidates to check, but judging which ones pose serious exposure still takes judgment. The constraint moves toward prioritization and remediation. For organizations facing that shift, the practical response is to prepare for larger patch cycles, greater prioritization demands and shorter remediation timelines, rather than treating each increase in disclosures as a temporary backlog.

This is more than a claim that scanners have become faster. A faster version of the same detector would still search for the same kinds of defects. The deeper change is the ability to examine code in context and reason about behavior that does not fit a known bad pattern. That changes what enters the review queue. That also explains why the number of disclosures alone cannot show all that AI-assisted review can do.

What AI-assisted source code review actually does that traditional SAST cannot

Traditional static application security testing, or SAST, relies on fixed rules that match known vulnerability patterns. AI-assisted review uses learned code representations to reason about how data flow and logic work in context. The distinction is not simply speed or presentation. One approach checks whether code matches a rule, while the other can check whether the code does what it was meant to do. That can help find flaws whose importance depends on how parts of the codebase work together.

Many tools marketed as “AI SAST” retain deterministic detection engines and use AI only to sort findings or suggest fixes. Their discovery coverage still depends on the underlying detector. Hybrid architectures go further by combining a static analysis pass for known patterns with an AI review agent that works with full codebase context on every pull request. In that design, the two methods serve different roles rather than one merely rewriting the other’s output.

Access control flaws, path traversal, business logic failures and server-side request forgery, or SSRF, can leave a program running normally while it does something unsafe. Detecting them requires attention to the intended boundary and the code that crosses it. A crash is not the test of failure. AI-assisted review can pursue those relationships at a scale that expert-only review cannot, although its interpretation still needs validation before it becomes a trusted finding.

The vulnerability classes fuzzers structurally miss — and that AI review reaches

In NOVA’s taxonomy, memory and calculation issues made up only a small share of total findings. Even after resource-management and denial-of-service issues were included, fuzzing-friendly categories accounted for a small fraction of the whole. Most findings belonged to other categories entirely. These included access control flaws, path traversal, code injection, prototype pollution and SSRF, where unsafe behavior does not necessarily cause the program to break.

A tool waiting for a crash has no signal when the application completes an unauthorized action without crashing. More coverage of inputs does not, by itself, supply an understanding of what the application should allow. AI-assisted source review reaches into that gap by examining logic and context.

The same dataset also showed how language and architecture shape the work. C and C++ findings clustered in memory safety, while JavaScript and TypeScript findings clustered in injection, prototype pollution and SSRF. PHP, Java and Python findings were dominated by broken access control. The supply chain widened the exposure further. Hundreds of flaws in dependency packages generated several times that number of downstream exposures, with a large share validated through a working proof of concept launched from the downstream application.

Why AI-generated code makes source code review more urgent, not less

AI coding tools are accelerating vulnerability introduction at the same time that AI review tools are accelerating discovery. The production side of that loop is currently ahead. AI-generated code introduces security vulnerabilities at a higher rate than human-authored code, particularly in SSRF, broken access control and missing authentication controls. These are precisely the weaknesses that demand analysis of intent and permissions. Generating more code therefore increases the need for deeper review.

The recurring failures sit in application logic. They include OAuth implementation failures, missing WebSocket authentication, inadequate rate limiting and weak JWT secret management with hardcoded fallbacks. SSRF has become a dominant AI-generated vulnerability class, while broken access control now formally subsumes SSRF in the OWASP framing. Applications that track many kinds of user run into this broader weakness again and again. The code must respect the distinctions the product depends on.

GitGuardian’s State of Secrets Sprawl 2026 report documented millions of new hardcoded secrets in public GitHub commits during 2025. It recorded a record single-year jump and the largest year-over-year increase ever recorded, with AI-assisted commits exposing secrets at roughly twice the rate of human-written code. Traditional development controls, including design reviews, SAST, software composition analysis and CI/CD approval gates, were built around deliberately human-written and human-reviewed software. AI-driven pipelines have broken that assumption by producing insecure defaults, excessive permissions and unsafe logic those gates were not designed to catch.

Shared patterns create a further risk. When AI tools share training data or templates, much the same insecure code can spread through thousands of unrelated codebases at machine speed. That makes scalable, context-aware review a necessary part of handling the output of AI coding tools. That review must produce reliable security findings without overwhelming the people who must validate and fix them.

How practitioners are combining AI candidate generation with human validation in production

Mandiant’s Agentic Vulnerability Discovery Harness combines multi-agent orchestration with subject-matter expertise during proactive reviews, penetration tests, red team operations and incident response. It has uncovered dozens of assignable flaws in widely used web extensions and open-source projects, resulting in 12 assigned CVEs. In one client engagement, it quickly found a remote code execution vulnerability that enabled initial access. The workflow is not an unattended model review. AI widens the search, while human experts guide the analysis and check the findings.

A*STAR’s Drishti framework, presented at CPSIoTSec’26, separates that validation work into distinct responsibilities. AI finds candidates, while humans take on verification, reachability assessment, impact measurement and patch completeness review. Each asks a different question about the candidate. A defect may exist without being reachable by an attacker, and a reachable defect still needs an assessment of its consequences. Even after a patch, the reviewer must establish whether the underlying vulnerability has actually been addressed.

Drishti’s audits of Open5GS and free5GC produced three confirmed findings. They included a pre-authentication NULL-dereference in the Open5GS NRF multipart parser, fixed upstream with a CVE requested. An ASN.1-PER memory amplification in the free5GC NGAP decoder allowed a 2-byte input from a rogue gNodeB to cause the AMF to be terminated due to memory exhaustion in 6.2 seconds. The third finding showed that a patch on CVE-2025-69248 was faulty because its defense-in-depth check was dead code before authentication. A patch can guard the crash site without providing an effective fix.

TitanCA demonstrates the scale available from a pipeline. By March 2026, its multiple LLM-based agents had analyzed a large corpus of GitHub repositories, identified hundreds of zero-day vulnerabilities and contributed to scores of published CVEs. The Drishti paper reports that Chrome shipped a large number of security fixes in a single stable release after AI tools lowered the cost of candidate generation. More candidates are useful only when validation and repair can absorb them.

Where AI source code review still falls short and why human expert review is not optional

AI review can yield findings that look sound and still miss real vulnerabilities. Precision and recall are still unresolved for individual tools, and tools differ enough to change how teams work. A majority of correct findings does not establish broad coverage. A long report is also no proof that the review found the issues that could do the most harm. These are separate tests of performance, and an evaluation that considers only one can hide weakness in the other.

False positives cost more than the time spent reviewing them. Repeated invalid alerts erode developer trust and can cause genuine vulnerabilities to be overlooked. Confirmation bias is another way LLM-based security review can fail, with false-negative bias greater than false-positive bias. The risk can spread through widely used dependencies as these tools enter software supply chains. Human triage is therefore not a ceremonial approval step after the model has finished the real work.

When a large codebase cannot fit in a model’s context window, review must operate on fragments, degrading detection of vulnerabilities that depend on cross-module data flow. Access to source code alone does not resolve that limitation. The review process must still account for the relationships that make an attack possible.

MITRE’s guidance rates automated static analysis effectiveness as “Limited” for certain weakness classes because automated techniques alone struggle to detect them reliably. A model’s explanation cannot establish that an exploit works. Without a working proof of concept, its output remains an unverified candidate. These limits make the case for keeping AI review under the AI-led, human-directed architecture. For a SaaS security team, they also define what a credible penetration test must include.

What rigorous AI-assisted source code review looks like inside a penetration test

For technical founders and engineering leaders, buying a security engagement means looking for whitebox access combined with certified human expert sign-off on every finding. Both are required for credible coverage and reporting. Meaningful review needs access to the full codebase, cloud configurations and product documentation, because the source alone does not supply every part of the application’s intended behavior. Black-box access and context limits narrow the range of vulnerability classes the review can find.

Security vendors should be judged by their validation process. Mandiant and Drishti show why candidate generation and expert assessment belong in the same workflow. A penetration test that skips the expert layer reproduces the failure modes of automated review. Working proof-of-concept exploits give teams a way to back up their findings. The report sent to an auditor or enterprise customer should contain findings demonstrated to work.

Coverage also has a time dimension. AI-generated code can introduce vulnerabilities on every pull request, so an annual source review that is not repeated after code changes measures a snapshot. The corresponding action is to repeat review as the code changes rather than treat the annual test as ongoing protection. For SOC 2, HIPAA and ISO 27001, rigorous whitebox testing with expert-reviewed findings can support both audit-readiness and real security. A shallow report that finds no real risk gives no sound measure of exposure and lacks the substance auditors are looking for.