Source Code Analysis in AI-Assisted Vulnerability Discovery

AI-assisted source code analysis doesn't just turn up more vulnerabilities in a codebase. It changes the category of vulnerability that gets found, and the category it favors happens to be the one attackers care about most. Google Threat Intelligence Group studied vulnerabilities found from January 2025 through August 2026, and when AI-assisted methods found them, they led to remote code execution roughly half the time, compared to roughly a quarter for vulnerabilities found through other means. That gap traces back to where AI-assisted programs choose to look: infrastructure code and the privilege boundaries that guard it, the exact terrain an attacker needs to cross to go from "found a bug" to "controls the machine." When a team points an AI-assisted review at a target, it aims at the exact spots an intruder would aim at first, not at speed over thoroughness.

What Makes AI-Assisted Analysis Structurally Different from Traditional Static Analysis

Static analysis tools have had two decades to get good at flagging risky functions and suspicious data flows. What they've never been good at is answering the question that actually matters: can an attacker reach this code, and can they control what happens once they do? If a dangerous function sits behind three layers of input validation, it is not a vulnerability. A suspicious data flow that terminates in a sanitized string is not a vulnerability either. Traditional static analysis can't tell the difference reliably, so it produces long lists that security teams triage by hand, usually by guessing. AI-assisted analysis adds a reasoning layer on top of that same static analysis foundation, and that layer is built specifically to answer the reachability question: is this exploitable, under what conditions, with what real-world impact.

One researcher's workflow produced four remote code execution vulnerabilities across open-source projects with a combined download count above 105 million, and it shows what that reasoning layer does in practice. Static analysis finds the risky primitives first. An AI model then builds a theory of exploitability around each one. A second, opposing model is set loose to attack that theory and find the holes in it. Only after surviving that adversarial round does a candidate get handed to a human for manual reproduction. The AI never delivered a final answer in this process. It connected scattered signals into theories specific enough to test.

The four CVEs that came out of that workflow make the pattern concrete. CVE-2026-47117, in OpenMed, scored 9.8 on CVSS: a model-loading path that could be influenced by a user-controlled model name, trusting remote code it should never have trusted. CVE-2026-47103, in Python StateMachine, also scored 9.8: attacker-controlled SCXML expressions reaching unsafe evaluation behavior. CVE-2026-9147, in uproot, scored 7.8: metadata from a crafted file finding its way into dynamically generated Python source. CVE-2026-10036, in SpeechBrain, scored 8.8: checkpoint metadata triggering unsafe YAML parsing during the discovery phase, before any file was even selected for use. Four different weakness classes, four different libraries, one shared skeleton: external data crossing a trust boundary and turning into executable behavior. The reasoning layer is what takes that abstract skeleton and turns it into a traceable, testable path in each individual codebase.

This model of operation is not confined to independent research. Mandiant runs an Agentic Vulnerability Discovery Harness, AVDH, across proactive reviews, penetration tests, red team operations, and incident response engagements. AVDH pairs multi-agent orchestration with a human expert-driven layer on top: structured analysis steps, built-in skepticism at each stage, and domain expertise injected directly into the pipeline from the start. You can find this reasoning-layer approach running inside one of the largest security practices in the industry, at volume, across real engagements.

Why AI-Generated Candidates Still Fail at the Ends of the Vulnerability Lifecycle

The reasoning layer produces genuinely sharper candidates than pattern-matching static analysis alone, but the vulnerability lifecycle doesn't end at candidate generation, and this is where AI-assisted analysis runs into trouble it can't reason its way out of. The scarcity that used to define this field was volume: not enough analysts to review enough code. That scarcity has shifted. Candidates are now cheap to produce. Confirming that a candidate is real, reachable, and genuinely fixed once a patch ships remains hard and expensive, and that's the part AI struggles with most.

Fix-completeness is the least obvious of these failure points, and it's also the most dangerous, because it hides behind a passing test suite. Drishti's audit of Open5GS and free5GC turned up a defective patch on CVE-2025-69248: the defense-in-depth check the fix was supposed to add turned out to be dead code sitting before the authentication point it was meant to protect. The patch passed its own tests. The hardening it was supposed to deliver never ran.

A natural objection here is that more AI inference should fix this: if one model's theory can be wrong, why not run three more models against the same patch and let consensus settle it? The data doesn't support that shortcut. Researchers looked into the datasets behind learning-based vulnerability analysis and found that label accuracy in widely used vulnerability corpora sits well below reliable thresholds, that near-duplicate train/test pairs inflate reported accuracy, and that for most disclosed vulnerabilities, no executable proof-of-concept exists to confirm them one way or the other. Models reasoning about exploitability are trained on data that frequently can't confirm exploitability. Stacking more automated passes on top of that foundation produces more confident-sounding wrong answers, not fewer. AI can misread framework behavior, miss a version-specific safeguard, or assume an attacker has control they don't actually have, and it can do all three while sounding certain. The discriminating signal comes from a human expert checking the work, not from another round of inference checking the same blind spots.

The four-CVE workflow treated this as a hard gate, not a courtesy step. Every candidate had to be manually reproduced in a controlled environment before it became a disclosure. Validation wasn't quality assurance tacked onto the end of the pipeline. Validation was the condition a finding had to meet to exist.

Data-Flow Tracing: Turning Trust-Boundary Failures into Proven Exploit Paths

Everything in the previous two sections depends on one resource: the actual source code. Data-flow tracing is the technique that turns a trust-boundary failure into a proven, reproducible exploit path, and it only works end to end when the analyst can see the full code, not just the programs that call it from outside. Without that access, tracing stops wherever the API surface stops, and everything past that point turns into a guess about what the internals might be doing.

The four CVEs described earlier are a map of exactly where that guessing would have failed. In OpenMed, the vulnerable path ran through model-loading logic that a user-controlled name could influence, logic with no visible footprint from outside the application. In Python StateMachine, the exploit depended on tracing attacker-controlled SCXML expressions all the way to an unsafe evaluation call, a chain that only exists as source-level control flow. In uproot, the injection point lived inside the code that dynamically generates Python source from file metadata, a part of the program that doesn't correspond to any external interface an outside tester could even point at. In SpeechBrain, the vulnerability triggered during checkpoint discovery, before a file was selected for use: whether the dangerous code path runs at all could only be answered by reading the checkpoint-loading source directly.

Hardcoded secrets form a separate but equally source-dependent category of finding. Developers routinely delete a credential from the current version of a file without ever rotating the credential itself, which leaves it sitting in Git history, fully readable by anyone who clones the repository. That history is invisible to any tool that only sees the application as it runs today. Finding it requires the kind of access that lets an analyst read not just the code, but the code's past.

Why Whitebox Access Is the Decisive Variable

Security testing is usually framed as a choice between three approaches: blackbox, greybox, and whitebox. What matters more is which attack surfaces each approach can actually see.

Blackbox testing simulates an attacker with no prior knowledge and no credentials, probing only what's visible from outside. That's a legitimate and necessary exercise: it tells a team what an opportunistic, unauthenticated attacker would see on day one. Greybox testing adds partial internal knowledge, things like authenticated credentials or network diagrams, so it opens up authenticated attack paths, and it often ends up being the most practical lens for assessing insider threats or what happens after a user account is compromised. Whitebox testing goes further still: you get full source code, cloud configuration, and internal documentation on the table. The trust-boundary failures traced in the previous section, the model-loading path in OpenMed, the code-generation injection in uproot, the checkpoint discovery flaw in SpeechBrain, the secrets sitting in Git history, are not partially harder to find without source access. They are not findable.

The instinct to treat blackbox testing as "realistic" and whitebox testing as merely "thorough" doesn't hold up against how real breaches happen. An attacker who obtains source code through a breach, a compromised vendor in the supply chain, or a disgruntled insider is operating with whitebox knowledge from the moment they get it. If you test only the attack surface visible to an anonymous outsider, you leave the entire post-compromise scenario unexamined, and that's exactly where the highest-severity damage tends to happen.

Mandiant's deployment reflects this directly: AVDH's point-in-time deep analysis runs alongside CodeMender's ongoing scanning, pairing deep periodic review with continuous coverage. That pairing isn't redundancy. Whitebox depth and continuous surface monitoring are built to catch different things, and a program that only runs one of them is blind to whatever the other was built to see.

A Security Program Built on Code-Level Analysis

A security program built around code-level analysis treats whitebox AI-assisted review and certified human validation as one continuous system, not two separate projects, and it runs that system against the code as it changes, not just once a year. A single point-in-time penetration test, even one done with full whitebox access, only captures the attack surface as it existed on the day of the test. AI coding tools are introducing new vulnerabilities into codebases at an accelerating pace, so a whitebox test completed six months before a major feature ships can miss an entire class of trust-boundary failures the shipped feature introduces on its way out the door.

The structure that addresses this runs AI-assisted source code analysis continuously, so that every pull request introducing a new execution boundary gets surfaced as a candidate the moment it's written, not months later. Deep whitebox penetration testing then runs at key milestones, and it validates exploit paths and measures real-world impact on the candidates that matter most. Every finding that reaches a report needs sign-off from a certified human expert, OSCP or an equivalent credential, before it counts as a finding.

Proof is not optional at any stage of this. A finding needs a working exploit behind it, a curl command, a Python script, or a documented step-by-step reproduction sequence for logic flaws that don't reduce to a single payload. A candidate that can't be reproduced is noise, and including it in a report weakens every other finding sitting next to it.

Remediation doesn't end the process either. Drishti's discovery of the defective patch on CVE-2025-69248, the fix that left its own protection as dead code before the authentication check, is a direct demonstration that a passing test suite says nothing reliable about whether a fix is actually complete. Retesting after remediation, ideally by the team that found the original issue and still has access to the patched source, is the only way to confirm a fix did what it was supposed to do.

This same structure happens to be what compliance frameworks ask for directly. SOC 2, HIPAA, and ISO 27001 all require an audit-ready report built on a stated methodology, findings ranked by risk, concrete remediation guidance, and a retest attestation confirming the fix held. A rigorous whitebox engagement, run the way described above, produces all four of those as a natural byproduct of doing the work correctly, not as paperwork assembled afterward to satisfy an auditor. The security program and the compliance evidence end up being the same document, because they were built from the same rigorous process all along.