analyst @ nohacky :~/briefings $
cat / briefings / how-ai-finds-security-bugs.html
analyst@nohacky:~/briefings/how-ai-finds-security-bugs.html
reading mode 8 min read
category vulnerability
published March 2025
read_time 8 min

How AI Finds Security Bugs

Automated vulnerability discovery used to mean slow scanners and mountains of false positives. AI has changed that calculus — and the results are starting to show up in real CVEs, real bug bounties, and real patches.

For decades, finding security bugs was a fundamentally human exercise. A skilled researcher would sit with source code or a running binary, apply pattern recognition built from years of experience, and eventually surface something exploitable. Automated tools helped at the margins — flagging obvious issues like strcpy calls or SQL string concatenation — but they were noisy, shallow, and easy to outrun with even modest obfuscation.

That picture has shifted considerably. AI-powered vulnerability discovery is no longer experimental. Google's OSS-Fuzz project reported in 2024 that its AI-assisted fuzzing had found over 26 new vulnerabilities in widely deployed open source projects. Researchers at Anthropic, OpenAI, and academic institutions have demonstrated that large language models can reason about code in ways that resemble expert auditing — catching logic flaws that pattern-matching tools have never touched. The question is no longer whether AI can find bugs. It is how it does it, what it does well, and where it still falls short.

Static Analysis Gets Smarter

Traditional static analysis tools — think Semgrep, Coverity, or CodeQL — work by matching code against a library of known-bad patterns. They are fast, deterministic, and cheap to run at scale. They are also fundamentally limited: they can only find what their rules describe, and they have no understanding of intent, context, or control flow across large codebases.

AI-augmented static analysis changes this by adding a reasoning layer. Instead of simply asking "does this line look like a known vulnerability," these tools ask "given the full context of this function, this data flow, and this calling convention, could an attacker manipulate this input to reach an unsafe state?" That is a much harder question, and one that requires something closer to semantic understanding than pattern matching.

note

LLM-based code analysis is already being embedded in commercial tools like GitHub Copilot's security features, Snyk Code, and Amazon CodeGuru. These are not research prototypes — they are shipping in production environments handling real codebases today.

A key advantage of the LLM approach is cross-function and cross-file reasoning. A classic buffer overflow might only become apparent when you trace a value from user input through three intermediate functions to a memcpy with no bounds check. Older tools struggle with this kind of taint propagation at scale. Models trained on large code corpora can hold more of this context in their effective working memory, flagging the dangerous path even when it spans file boundaries.

The tradeoff is that LLMs also hallucinate. They will sometimes flag code as vulnerable when it is not, or miss a real vulnerability because the code pattern does not resemble anything in their training distribution. Security teams using AI-augmented static analysis still need human review on findings — but the nature of that review changes. Instead of sorting through thousands of low-confidence alerts, analysts receive a much smaller set of higher-confidence, context-aware reports with natural language explanations attached.

AI-Guided Fuzzing

Fuzzing — feeding a program large volumes of malformed or unexpected input to trigger crashes — has been a cornerstone of vulnerability research for years. Tools like AFL and libFuzzer made coverage-guided fuzzing accessible and produced a steady stream of real-world findings. The limitation is that traditional fuzzers are largely blind to program semantics. They know which code paths they have covered, but they do not understand what those paths do or why certain inputs might be particularly dangerous.

AI changes this in a few concrete ways. First, models can generate semantically meaningful test cases rather than random mutations. If a function expects a serialized protobuf, a random bit-flip is unlikely to get past the parser. An AI that understands the protocol can construct inputs that reach deeper program states — and therefore deeper bugs.

# Example: AI-assisted corpus generation for a parser target
$ llm-fuzz generate --target ./parse_config --format json --depth 4
[+] Generated 1,240 semantically valid test cases
[+] Coverage: 84.3% of reachable branches
[+] Crash detected: heap-buffer-overflow in config_expand_var() at line 312

Second, AI can analyze crash reports to determine exploitability. Not every segfault is a security issue. Traditional triage required a human researcher to examine register state, memory layout, and the surrounding code to decide whether a crash represented a real vulnerability or just a minor robustness issue. Models trained on vulnerability data can make an initial exploitability assessment automatically — routing the interesting crashes to human reviewers while discarding the noise.

Google's Project Zero and the OSS-Fuzz team have both published work showing that LLM-guided fuzzing finds qualitatively different bugs than coverage-guided fuzzing alone — not just more bugs, but bugs in previously unexplored code regions that required semantic understanding to reach.

warning

AI-guided fuzzing also lowers the barrier for attackers. The same techniques that help defenders find bugs before release can be used by threat actors to discover zero-days in deployed software. This is not a hypothetical — vulnerability research firms and nation-state actors have access to the same tools and model capabilities as the defensive security community.

LLMs as Code Auditors

Perhaps the most direct application of AI to vulnerability discovery is using large language models as interactive code auditors. Instead of running an automated pipeline, a security researcher can paste a function into a chat interface and ask: "What are the security implications of this code? Could an attacker control the value of user_input here, and if so, what happens?"

This sounds simple, but the results have been significant. Researchers have used this approach to find previously unknown vulnerabilities in mature, well-audited projects — the kind of code that had passed through multiple security reviews by experienced humans. The model does not get tired. It does not have favorite code paths. It applies the same level of scrutiny to the thousandth function as the first.

The model found a race condition in the locking code that three of us had looked at and missed. It described the exact interleaving that would produce the vulnerability. — Independent security researcher, presented at DEF CON 32

The workflow that has emerged in serious security research looks roughly like this: run automated static analysis to get initial signal, use an LLM to triage and contextualize the findings, then conduct human-led manual review on the highest-confidence results. The AI handles scale; the human handles judgment.

What AI-assisted auditing does not yet handle well is novel vulnerability classes. Models trained on known vulnerability patterns will find instances of those patterns reliably. But a genuinely new class of bug — one that has never appeared in training data — is much harder for a model to recognize. That is still the domain of expert human research, at least for now.

critical

Sharing production source code with third-party LLM APIs introduces its own risk surface. Organizations handling sensitive or proprietary codebases should evaluate on-premise model deployment or contractual data-handling guarantees before integrating AI code review into their security pipeline.

Key Takeaways

  1. AI augments, not replaces, human auditors: The most effective current deployments pair AI-generated findings with human triage. Models excel at scale and consistency; humans provide judgment on novel or ambiguous cases.
  2. Fuzzing has been transformed: Semantic-aware, AI-guided fuzzing reaches code paths that coverage-guided fuzzing cannot, and it has already produced real CVEs in real software. This is not experimental — it is in active use at Google, Microsoft, and independent research shops.
  3. The attacker-defender gap is narrowing: The same AI capabilities available to security teams are available to adversaries. Organizations that are not incorporating AI into their vulnerability management pipeline are falling behind threat actors who already are.
  4. Data exposure is a real concern: Using cloud-hosted AI tools for security analysis requires careful evaluation of what code is being sent where, and under what terms.

The trajectory is clear. AI is not going to make security bugs disappear — software complexity is growing faster than any tool can fully cover. What it will do is shift the economics of vulnerability discovery, making it faster and cheaper to find known classes of bugs while raising the floor of what qualifies as a "hard to find" vulnerability. For defenders, that is an opportunity. For everyone else, it is a reason to patch faster.

— end of briefing