AI for Vulnerability Discovery and Triage Guide

AI systems now find real vulnerabilities in mature code, which means more findings for your own teams to triage and more reports, good and bad, arriving at your disclosure inbox. Since 2024, LLM-based agents have found an exploitable SQLite bug that fuzzing had missed, a Linux kernel use-after-free, a two-decade-old OpenSSL flaw and dozens of issues in DARPA's AI Cyber Challenge. At the same time, maintainers such as curl report that a growing share of submissions are AI-generated noise. This guide is for application security leads, PSIRT and vulnerability management teams deciding how to use AI discovery tools on their own code and how to triage the extra volume, whatever its source. It covers what the published evidence shows, where these tools fit beside fuzzing and SAST, governance and data handling, a triage process with validation gates, rollout, metrics and failure patterns. It describes defensive use only and contains no exploitation methods. For the wider programme see the Vulnerability Management Guide.

Key takeaways

The capability is real but noisy. Published results show genuine finds alongside high false positive rates: one researcher reported a signal-to-noise ratio of about 1 in 50 for a kernel bug found with an LLM.
Validation is the control that matters. The strongest systems reproduce a finding in a sandbox or with a proof of vulnerability before a human sees it; treat unvalidated AI findings as hypotheses.
Complement, do not replace. Google's Big Sleep team states that a target-specific fuzzer is likely at least as effective today; AI earns its place on code fuzzers and rules do not reach.
Plan for inbound volume. Disclosure programmes need intake rules, reproduction requirements and a fast path for valid reports, because AI raises both genuine and junk submissions.
Govern it like any privileged tool. Source code, repository tokens and sandbox credentials flow into these systems, so data handling, scoping and identity controls come first.

What the evidence shows so far

Claims in this area move quickly and are often vendor-reported. The table summarises primary-source results a practitioner can check, with the caveats their authors give.

Result	Source and date	What was found	Caveats stated by the source
Big Sleep (Google Project Zero and DeepMind)	Project Zero blog, October 2024	An exploitable stack buffer underflow in SQLite's `generate_series` extension, found by variant analysis from a previously fixed commit and fixed the same day, before release	"Highly experimental"; authors believe a target-specific fuzzer is at present likely at least as effective. AFL ran 150 CPU-hours on the target without finding it
OSS-Fuzz AI-generated fuzz targets	Google Online Security Blog, November 2024	26 new vulnerabilities, including CVE-2024-9143 in OpenSSL, plus coverage extended to 272 C/C++ projects and over 370,000 new lines covered	LLM crash triage is not yet reliable enough to skip human review
CVE-2025-37899 in Linux ksmbd	Sean Heelan, May 2025	A use-after-free in the SMB2 logoff handler, found while benchmarking a model on a known bug	Signal-to-noise about 1:50; the known bug was found in 8 of 100 runs on a small code slice and 1 of 100 on a larger one; performance drops with input size
DARPA AI Cyber Challenge final	DARPA, August 2025	Systems found 54 of 63 synthetic vulnerabilities (86%) and patched 43 (68%), and found 18 real vulnerabilities; average cost about $152 per task	Competition targets; all seven finalist systems to be released as open source
Aardvark, now Codex Security (OpenAI)	OpenAI, October 2025 with a March 2026 update	Vendor reports 92% recall on benchmark repositories with known and synthetic bugs, and ten open-source CVEs	Vendor-reported; patches and findings are presented for human review

The pattern across these sources is consistent: AI is strongest at variant analysis, reasoning over a bounded code slice and generating fuzz harnesses, and weakest when asked to scan a large codebase cold. Every source keeps a human, a sanitizer or a reproduction step between the model and a filed vulnerability.

Where AI fits beside fuzzing, SAST and human review

Method	Strengths	Weaknesses	Best use
Coverage-guided fuzzing	Findings come with a crashing input; sanitizers give a reliable oracle	Needs harnesses; saturates on mature targets; poor at logic bugs	Parsers, codecs, protocol handlers. See the Fuzzing Guide
Rule-based SAST	Fast, deterministic, cheap to run in CI	High false positives on some rule sets; misses context-dependent bugs	Known weakness classes on every commit. See the SAST Triage and False Positive Management Guide
LLM-assisted harness generation	Extends fuzzing to code nobody wrote harnesses for, with the fuzzer as oracle	Generated harnesses can themselves be buggy, causing false crashes	Raising coverage on large open-source or internal libraries
LLM code reasoning and variant analysis	Finds logic, lifetime and authorisation flaws that resemble a known bug	Non-deterministic, many false positives, weaker on large inputs	After each fixed vulnerability, to look for siblings; focused reviews of high-risk components
Agentic systems with validation	Threat modelling, commit scanning and sandbox reproduction in one pipeline	Costly, needs repository and sandbox access, vendor claims vary	Continuous review of critical repositories with human approval of patches. See the AI-Assisted Code Review and AI SAST Guide
Expert manual review	Highest precision, understands design intent	Scarce and slow	Final judgement on severity and design flaws

Decision guidance

Small team, few critical components: start with AI-generated fuzz harnesses for your parsers and variant analysis after each security fix; both have a built-in oracle or a narrow scope.
Large engineering organisation: pilot an agentic scanner on two or three critical repositories, measure precision against your SAST baseline, and only then consider commit-level scanning at scale.
Open-source maintainer or vendor PSIRT: invest in intake and reproduction first; inbound volume is the bigger operational change. See the PSIRT Guide.
Regulated code (safety, medical, payments): keep AI as an additional detection layer; do not let generated patches bypass existing review and verification gates.

Governance, data handling and safe use

An AI discovery system is a privileged tool: it reads source code, may hold repository and package registry tokens, executes code in a sandbox and can open pull requests. Govern it on that basis.

Data handling: confirm whether code and findings leave your environment, retention periods, training use and regional processing before connecting a repository. OWASP lists sensitive information disclosure as LLM02 in its 2025 Top 10 for LLM Applications. See the OWASP LLM Top 10 LLM02 Sensitive Information Disclosure Guide.
Scope and authorisation: run discovery only on code and systems you own or are contracted to test, and write that scope into the tool configuration. Third-party and production targets need the same authorisation as a penetration test. See the AI-Assisted and Autonomous Penetration Testing Guide.
Sandbox isolation: validation steps execute untrusted code; isolate them with no access to production networks, secrets or cloud credentials. See the AI Agent Sandboxing and Code Execution Guide.
Limit agency: the tool may propose patches and open draft pull requests, but merging stays with humans and normal branch protection. OWASP LLM06 Excessive Agency describes the risk of granting more functionality, permissions or autonomy than needed.
Treat output as unverified: OWASP LLM09 Misinformation covers confident but wrong output; a plausible vulnerability narrative is not evidence.
Handle findings as sensitive: an unpatched, validated vulnerability with a reproduction is dangerous information. Store it in the vulnerability tracker with restricted access, not in chat logs or shared tickets.

A triage process with validation gates

Whether a finding comes from your own AI tooling or from an external reporter who used AI, the same gates apply. The goal is to spend expert time only on findings that have passed cheaper checks.

Intake and deduplication: normalise findings into one format (SARIF for tool output), attach commit, file and function, and deduplicate against open issues and previous reports.
Reproduction gate: require a reproducer: a crashing input with sanitizer output, a failing test, or a sandboxed proof of vulnerability. Findings without one go to a low-priority queue, not to engineers.
Reachability check: confirm the vulnerable code is built, shipped and reachable from an untrusted input in a supported configuration. Many AI findings are in test code, dead paths or unsupported options.
Harness and tooling check: for fuzz-derived crashes, confirm the bug is in the project and not in the generated harness. Google's OSS-Fuzz triage asks the model exactly this first, but still requires human review.
Severity scoring: score with CVSS v4 using the reproduced impact, not the model's description, and add exploitation context such as EPSS and KEV for external components. See the CVSS v4 Guide.
Fix and verify: AI-proposed patches go through code review and the reproducer becomes a regression test. Re-run variant analysis on the fix.
Disclosure: for third-party code, report to the maintainer with the reproducer, a clear human-written explanation and a coordinated timeline. curl's policy asks reporters to write "in your own human voice" and not paste massive AI-generated explanations.

Handling inbound AI-assisted reports

Report characteristic	Likely meaning	Response
Long narrative, no reproducer, references functions that do not exist	Hallucinated report	Close with a standard request for a reproducer; track the reporter
Correct code references, plausible flaw, no reproducer	Possible real issue, unvalidated	Ask for a test case or input; time-box internal reproduction
Reproducer with sanitizer output or failing test	Likely valid	Fast-track to the owning team and start the disclosure clock
Many similar reports from one source	Automated scanning at scale	Batch triage, rate limits on the intake platform

Update your vulnerability disclosure policy to state reproduction expectations and how AI use should be described, using the Vulnerability Disclosure Policy Template. The ISO/IEC 30111 handling process applies unchanged; see the ISO/IEC 29147 and 30111 Vulnerability Disclosure and Handling Guide.

Implementing AI-assisted discovery

Choose targets: pick two or three components with known vulnerability history, untrusted inputs and an owner willing to review findings.
Set up governance: data handling review, scoped repository access with a dedicated read-only token, an isolated validation sandbox and a restricted findings store.
Baseline: record what fuzzing, SAST and past reports already find on those components so new findings can be compared fairly.
Pilot in report-only mode: the tool files findings into a triage queue but cannot open pull requests; run for four to eight weeks.
Measure: precision after the reproduction gate, unique valid findings not found by other methods, engineer hours per valid finding and cost per finding.
Expand or stop: widen to more repositories and allow draft patches only if precision and unique yield justify the triage cost. Rollback is revoking the tool's tokens and disabling its integration; findings already in the tracker stay.

Where identity fits

These tools run on non-human credentials: repository tokens or GitHub App installations, CI tokens to run tests, package registry tokens for dependency resolution, and cloud credentials for sandboxes. A leaked token from an AI security tool can give read access to every connected repository. Use short-lived, least-privilege tokens per repository, keep write scopes off by default, record an owner for every integration and include them in access reviews. See the Non-Human Identity (NHI) Guide and the OWASP NHI Top 10 NHI5 Overprivileged NHI Guide.

Detection and measurement

Precision after validation: share of AI findings that pass the reproduction and reachability gates. Track it per tool and per component.
Unique yield: valid findings per month not already found by fuzzing, SAST or human review.
Triage cost: engineer hours per valid finding, including time spent rejecting false ones. curl's maintainers report each security report engaging three to four team members for 30 minutes to three hours.
Inbound report validity: share of disclosure reports that are valid, per quarter; curl reported only about 5% of its 2025 submissions were genuine by July.
Time to remediate: days from validated AI finding to merged fix, compared with other sources.
Tool access hygiene: number of AI tool tokens with write scopes or no owner, target zero.

Log the tool's own activity too: repositories read, sandboxes started, pull requests opened and tokens used, so misuse of the integration is visible.

Framework mapping

Framework	References
NIST SP 800-53 Rev. 5	RA-5 Vulnerability Monitoring and Scanning, RA-5(11) Public Disclosure Program, SA-11 Developer Testing and Evaluation, SA-15 Development Process, Standards, and Tools, SI-2 Flaw Remediation
NIST CSF 2.0	ID.RA-01 (vulnerabilities identified, validated and recorded), ID.RA-08 (processes for vulnerability disclosures), PR.PS-06 (secure software development practices)
NIST SP 800-218 SSDF 1.1	RV.1 identify and confirm vulnerabilities, RV.2 assess, prioritise and remediate, RV.3 analyse root causes (variant analysis supports RV.3)
ISO/IEC 27001:2022 Annex A	A.8.8 Management of technical vulnerabilities, A.8.28 Secure coding, A.8.29 Security testing in development and acceptance
OWASP Top 10 for LLM Applications 2025	LLM02 Sensitive Information Disclosure, LLM06 Excessive Agency, LLM09 Misinformation (for the tooling itself)

Common failure patterns

Treating model output as a finding: filing unvalidated AI narratives as vulnerabilities floods engineering queues and erodes trust in the security team. Gate on reproduction.
Scanning a whole monorepo cold: published results show performance falls as input grows; focused slices and variant analysis give far better yield.
Merging generated patches unreviewed: a patch that silences a crash can hide the real bug or introduce a new one; keep review and regression tests.
Over-privileged integrations: giving the tool organisation-wide write tokens or a sandbox with cloud credentials turns a security tool into an attack path.
Ignoring the inbox: PSIRTs that do not adapt intake to AI volume either drown in noise or miss the valid report buried in it.
Disclosing carelessly: pasting raw AI output to maintainers, or sharing unpatched findings in public channels, damages relationships and raises risk.

Lessons from incidents

Externally found AI flaws arrive fast: in the McKinsey AI platform hack, a security start-up's autonomous agent reportedly found an unauthenticated SQL injection in about two hours; McKinsey acknowledged the report the next day and patched within hours. A working intake and fix path is what made that outcome possible. The data exposure figures were claimed by the researcher and are unverified.
Attackers have the same tools: discovery speed applies to adversaries too, which shortens the time between a flaw existing and it being found. See the Autonomous AI Attack Agents guide.

Practitioner checklist

Run a data handling and scope review before connecting any repository to an AI discovery tool.
Give each integration a dedicated, short-lived, read-only token and an owner.
Isolate validation sandboxes from production networks and secrets.
Require a reproducer before any AI finding reaches an engineering team.
Check reachability and harness correctness before scoring severity with CVSS v4.
Keep human review and regression tests for every AI-proposed patch.
Run variant analysis after each fixed security bug.
Update the disclosure policy with reproduction expectations and an AI use statement.
Track precision, unique yield and triage hours per valid finding for each tool.
Store unpatched findings in a restricted tracker, never in chat or public issues.

AI for Vulnerability Discovery and Triage Guide: Using It Safely and Handling the Report Surge