AI-Assisted Vulnerability Discovery: Capabilities, Limitations, and Implementation

Introduction

Large language models are increasingly being used for code review and vulnerability analysis. They can read large codebases, map call relationships, identify potentially risky paths, and suggest ways to validate them. For security teams, this offers a way to address the coverage limits imposed by scarce expert time.

However, greater capability also makes it important to define how much to trust the results, what they cost, and where their use is appropriate. Rather than evaluating a specific product, this article describes how to organize AI-assisted vulnerability discovery as an engineering workflow, which metrics to monitor, and when an organization may be ready to adopt it.

Why Automate Parts of Vulnerability Discovery?

Large infrastructure codebases contain many lines of code and complex relationships between modules. Given limited time and specialist resources, manual audits can struggle to cover every code path.

Some vulnerability classes follow recognizable patterns. Examples include buffer writes without length checks, missing authorization checks, and race conditions caused by accessing shared state without locks. Models or rule engines can screen for these patterns, expanding coverage and reducing the cost of initial triage.

Finding a candidate is not the same as confirming a vulnerability. Confirmation requires reproducible trigger conditions, a clearly defined range of affected versions, and an assessment of the prerequisites for exploitation. Automation can broaden the candidate pool, but conclusions still need to be established through deterministic methods.

A Standard Workflow

A reliable process typically has six stages:

1. Define the scope: Specify the authorized targets, code versions, and available test environments. Systems without written authorization must not be included in a scan.
2. Build context: Divide the code by module and identify entry points, trust boundaries, and sources of external input. Create structured summaries for subsequent analysis.
3. Generate candidates: Use a model or rule engine to flag high-risk patterns and provide suspected issues with the reasoning behind them.
4. Verify deterministically: Construct inputs in an isolated environment and use unit tests, sandbox execution, or symbolic execution to confirm actual behavior.
5. Prioritize and remediate: Rank findings by impact and exploitability, assign owners, and add regression tests.
6. Review and iterate: Record why false positives occurred, update rules and prompts, and build a traceable body of knowledge.

Stage 4 is essential. Model output is a lead, not a verdict; only validated findings should enter the remediation queue.

Example: Low-Cost Initial Screening with a Rule

Before calling a model, text search can identify obvious high-risk patterns and reduce the volume of code requiring further analysis. The following command searches C source and header files for string-copy calls that do not specify a length limit:

# Find copy calls without an explicit length limit; print file names and line numbers
grep -rnE "\b(strcpy|strcat|sprintf|gets)\s*\(" src/ --include="*.c" --include="*.h"

Search results can be noisy. The command may match comments, test code, and calls that are already protected by boundary checks, so results need to be filtered manually or automatically with the surrounding context in mind.

A confirmed issue might be addressed as follows. snprintf limits the number of characters written and ensures the result is null-terminated:

/* High-risk pattern: destination buffer length is not checked */
strcpy(buf, user_input);
/* Safer pattern: limit the write to the buffer size and ensure termination */
snprintf(buf, sizeof(buf), "%s", user_input);

Record each candidate in a consistent format to support tracking and review:

Candidate ID: C-0142
Location: src/net/parser.c:381
Pattern: Copy without a length check
Input source: Length field in a network packet
Validation status: Pending sandbox reproduction
Exploitability: Not assessed
Owner: Unassigned

How to Measure Effectiveness

Assess AI-assisted discovery using metrics such as:

• Precision: The proportion of candidates confirmed as real issues. Low precision means the team spends more time dismissing false positives.
• Recall: The proportion of known defects found. Use a benchmark set of previously disclosed and fixed vulnerabilities to make measurements comparable.
• Analyst time per confirmed issue: The effort required to reach a conclusion after a candidate is generated.
• Cost per unit: Compute resources consumed per thousand lines of code or per module, to assess whether the approach is viable at scale.
• Remediation time: The time from confirming a finding to releasing a fixed version.

Claims such as “completing years of manual work in a short time” warrant scrutiny. Check whether the sample scope is disclosed, results are deduplicated, findings are classified by impact, and validation criteria are consistent. Counts that have not been deduplicated or classified cannot be compared directly.

Risks and Governance

Dual use. The same capabilities can support defense or be used for attacks. Organizations should restrict access to authorized personnel, log activity, and prohibit scans of unauthorized targets.

Data security. Source code and vulnerability details are sensitive. Conduct analysis in a controlled environment and avoid sending raw code to untrusted external services.

False positives and hallucinations. A model may refer to nonexistent functions or describe a call path that cannot occur in practice. Every conclusion must be independently verified through reproducible steps.

Responsible disclosure. If a vulnerability is found in an upstream component or third-party dependency, report it through the maintainer’s designated channels, allow a reasonable remediation window, and avoid publishing exploitable details before a fix is released.

An Adoption Path for Organizations

Pilot phase. Choose a clearly bounded internal module and establish a benchmark set. Use the system only to generate candidates; do not enable automatic remediation. The goal is to establish precision and cost per unit.

Integration phase. Add scanning to the code review or merge workflow, analyzing only changed code. Incremental analysis can reduce the cost of each run and help developers review findings in context.

Operations phase. Establish a feedback loop for false positives, version-control rules and prompt templates, and periodically rerun the historical benchmark to track the effects of model or rule updates.

Automatic fixes should be limited to lower-risk cases, such as adding boundary checks in a consistent format. All changes still require human review and automated testing, and must pass tests before merging.

AI can broaden audit coverage, but the engineering team’s processes must remain responsible for screening candidates, confirming findings, and managing remediation.