AI for Cybersecurity: Vulnerability Discovery and Validation in Practice

From Code Review to Vulnerability Validation: The Boundaries of AI-Assisted Security Research

One of the most closely watched applications of AI in cybersecurity is helping analyze large codebases for potential defects. Unlike simple searches for dangerous functions or matches against known vulnerability patterns, models with code-understanding and reasoning capabilities can attempt to trace data flow, control flow, and privilege boundaries, then generate test materials to validate their hypotheses.

But finding suspicious code is not the same as finding an exploitable vulnerability. A reliable vulnerability research process needs to answer at least three questions: Does the issue actually exist? Can its triggering conditions be reproduced consistently? Is its impact significant enough to constitute a security risk? AI’s value depends on whether it helps researchers complete this entire process more effectively—not merely produce more candidate reports.

1. What Are the Stages of Vulnerability Research?

1.1 Identify suspicious code paths

Researchers first narrow a large codebase to areas of interest, such as input parsing, memory management, permission checks, serialization and deserialization, and interactions across component boundaries. AI can help interpret function call relationships, trace data from entry points to sensitive operations, and flag places where validation or state constraints may be missing.

This analysis is useful for reducing the search space, but a model’s explanation should be treated as a hypothesis to verify. The code context may be incomplete, and a given path may depend on constraints imposed by callers, compiler options, or runtime state. Reviewers should therefore inspect the actual code and build configuration to confirm that the model’s assumptions hold.

1.2 Verify that the issue can be triggered

Candidate issues need to be tested using methods such as unit or integration tests, fuzzing, static analysis, or execution in a controlled environment. Validation is about more than whether the program crashes: it should also establish the triggering input, execution path, system state, and reproducibility. Without this information, a report may amount to a theoretical risk that engineering teams cannot readily reproduce or fix.

AI can help organize reproduction steps, construct test cases, or interpret unexpected behavior. However, generated tests must be reviewed and run in an isolated environment. For scenarios involving memory corruption, privilege bypass, or remote input, execution permissions, network access, and the scope of readable and writable data should be restricted to prevent the research process from causing real-world impact.

1.3 Assess impact and support remediation

Severity should not be determined by an anomalous behavior alone. It must be assessed in context, including the attacker’s initial privileges, the difficulty of triggering the issue, affected components, potential privilege-escalation paths, and available mitigations. A research report should identify affected versions or configurations, prerequisites, observable outcomes, and supporting evidence so maintainers can independently review the finding.

Fixes also need engineering validation. Adding an input check may create compatibility issues, while changing a permission check may disrupt legitimate functionality. A more reliable approach is to propose a minimal patch direction, targeted regression tests, and checks for adjacent code paths rather than merging model-generated changes directly.

2. What Public Research Cases Can Tell Us

A publicly disclosed code security study reported that researchers identified 81 previously unreported issues in a large client codebase that had undergone extensive review. The issues were subsequently rated as high severity. The researchers also noted that the risk ratings of 30 known issues might warrant reassessment. The team provided evidence and potential remediation directions for maintainers to review.

The significance of this case is not that it proves AI can conduct a security audit independently. Rather, it shows that new analysis methods may uncover overlooked issues even in code that has already received multiple rounds of manual and automated review. At the same time, the number of findings alone says nothing about the model’s overall accuracy. Evaluating effectiveness also requires knowing how many candidate reports were submitted, how many were false positives, how long validation took, and whether fixes ultimately passed testing and were deployed.

Another study focused on operating system kernel code and reported reproducing 1,724 vulnerabilities, of which 948 resulted in working privilege-escalation exploits. It also reported model-call costs of approximately $1.21 million. These figures need to be understood in the context of the study’s scope and process: reproducing a vulnerability and constructing a working exploit are different levels of difficulty. The latter also depends on environmental conditions, reliability, and privilege requirements. Cost estimates should account not only for model calls, but also for human review, environment setup, failed attempts, and subsequent maintenance.

These cases can offer reference points for research capabilities and resource requirements, but their results cannot be assumed to apply to every codebase, model, or organization. Programming languages, build systems, test coverage, and security boundaries vary widely across projects, so practical effectiveness must be evaluated locally.

3. An Implementation Workflow for Security Teams

3.1 Define authorization and scope

Before analysis begins, specify which repositories, versions, build targets, and test environments are in scope. Also identify systems, data, and network resources that must not be accessed. Automated tasks should follow the principle of least privilege and should not give models or execution agents access to production credentials, real user data, or unnecessary write permissions.

For workflows that execute code, use disposable or resettable isolated environments and record inputs, outputs, file changes, and execution results. This helps reduce the risk of unintended actions and supports later auditing and reproduction.

3.2 Separate discovery from exploit validation

The workflow can be divided into stages with progressively controlled permissions: begin with read-only code analysis, move on to generating minimal tests, and then conduct limited validation in an isolated environment. More hazardous exploit-oriented testing should be performed only when clearly authorized and necessary. Each stage should have a human review gate so unverified hypotheses do not automatically escalate into actions with real-world impact.

This staged approach also helps identify why a candidate issue failed to reproduce. The cause may be a misunderstanding of the code, an inconsistent environment configuration, or a triggering condition that does not hold. Teams can investigate these possibilities rather than attributing every failure to model limitations.

3.3 Establish auditable reporting standards

Each candidate report should include, at a minimum, the affected code location, complete triggering conditions, reproduction steps, observed results, impact analysis, confidence level, and potential remediation direction. Any dependencies on specific compiler options, platforms, or user permissions must also be stated.

Teams should track false positives and duplicate reports and use that information to improve subsequent workflows. Useful measures include the proportion of findings confirmed by human reviewers, average review time, reproduction success rate, time to remediation, and the number of regression defects. Counting only the number of findings generated by a model is not enough.

3.4 Integrate patches into standard engineering governance

AI-proposed fixes should follow the project’s existing code review, testing, and release processes. Before merging a patch, reviewers should check whether it addresses the root cause, whether it could bypass other security checks, and whether it changes expected behavior. Changes involving privilege boundaries, parsing logic, or memory safety warrant particular attention, including targeted tests and a review of compatibility impact.

4. Conclusion: Capability Gains Must Be Matched by Governance

AI is expanding the search and validation capabilities available to security researchers, but vulnerability management remains a shared effort involving tools, researchers, and software maintenance processes. Models can reduce the time needed to understand code and construct tests, but they cannot replace authorization controls, impact assessment, human review, or engineering quality assurance.

For organizations, a prudent path is to start with code reviews of clearly defined scope, then gradually introduce isolated testing, structured reporting, and effectiveness measurement. Teams should continually assess false-positive rates, remediation value, and total costs. AI-assisted analysis becomes a sustainable security improvement only when discovery, validation, remediation, and review form a complete cycle.