How Security LLMs for Scalable Vulnerability Discovery Will Reshape Attack and Defense

1. The Real Issue Is Not “How Many Vulnerabilities Were Found”

When a security LLM reports hundreds of high-risk issues at once, the numbers are usually what spread fastest. What is most easily lost is the methodology behind those numbers.

A code defect typically goes through multiple stages from being flagged by a model to being recognized as an independent high-risk vulnerability:

1. Filter potentially security-sensitive areas from a large codebase.
2. Perform static analysis on the target code and generate candidate issues.
3. Verify in an isolated environment whether the issue can be triggered reliably.
4. Determine whether the defect crosses an existing security boundary.
5. Assess whether it has realistic exploitation conditions.
6. Merge multiple trigger methods caused by the same root cause.
7. Generate remediation proposals and run regression tests.
8. Complete final human confirmation, severity rating, and disclosure.

As a result, the number of candidate findings, successfully reproduced issues, exploitable issues, independent root causes, and patches each describe outcomes at different stages. Writing any one of these numbers directly as “total new vulnerabilities found” or “total vulnerabilities fixed” will cause serious misinterpretation.

Some public research may ultimately produce hundreds of independent high-risk issues, even though it actually examined only a single-digit percentage of a large codebase. This fact reveals two important conclusions. On one hand, models can already significantly increase audit output within limited coverage. On the other hand, such experiments do not prove that the remaining code is safe, nor can they be used to extrapolate the total number of vulnerabilities across the entire codebase.

2. How Security LLMs Perform Vulnerability Discovery at Scale

Traditional vulnerability research depends on security experts reading code, constructing inputs, analyzing crashes, and validating attack paths. Security LLMs do not eliminate these steps. Instead, they automate much of the repetitive work and divide responsibilities across multiple specialized agents.

1. Code Reconnaissance: First Determine “Where It Is Worth Looking”

Faced with tens of millions of lines of code, line-by-line analysis is not only expensive but also produces large amounts of low-value output. The first stage typically filters targets based on conditions such as:

• Whether low-privilege input can reach the code;
• Whether the code involves memory, permissions, identity, parsing, or resource management;
• Whether it processes external data from networks, files, devices, or interprocess communication;
• Whether it sits in modules with a history of defects or frequent changes;
• Whether it contains complex state machines, boundary calculations, or concurrency control;
• Whether the code runs in a high-privilege or high-trust environment.

The core goal of this stage is not to find vulnerabilities directly, but to build an attack surface map. Only by combining reachability, privilege boundaries, and data flow can the model avoid spending most of its time on code that cannot be triggered externally.

Enterprises can assign a risk score to code units similar to the following:

Risk score =
    External input reachability × 0.25
  + Execution privilege level × 0.20
  + Memory operation complexity × 0.20
  + Historical defect density × 0.15
  + Recent change frequency × 0.10
  + Business impact scope × 0.10

This is not a universal standard, but an illustrative method for understanding the idea. Actual weights should be adjusted based on business type, threat model, and programming language.

2. Static Analysis: Generate Candidate Issues from Code

Within target areas, the model analyzes control flow, data flow, privilege checks, and resource lifecycles, focusing on risk patterns such as:

• Incorrect array or buffer boundary handling;
• Integer overflow, truncation, and signedness conversion issues;
• Access to objects after they are freed;
• Double free or failure to release resources;
• Null pointers, wild pointers, and use of uninitialized data;
• Checks and uses that are not synchronized in concurrent environments;
• Missing identity verification, authorization decisions, or state checks;
• Parser state confusion under abnormal input;
• Error-handling branches that break security assumptions;
• Sensitive information leaked through logs, return values, or shared resources.

The strength of large models is their ability to form hypotheses by combining cross-function semantics, comments, call relationships, and business context. Their weakness is that they may mistake “looks dangerous” for “actually exploitable.” Static analysis can therefore produce only candidate conclusions, not final vulnerability triage.

3. Dynamic Reproduction: Make Candidate Issues Actually Trigger

Candidate issues must enter an isolated environment for verification. The verification system prepares controlled inputs, runs the target program, records crash information, and determines whether the results are reproducible.

This stage must answer at least four questions:

• Can the issue be triggered reliably in a clean environment?
• Does triggering depend on rare configurations, race conditions, or special privileges?
• Does the crash originate from the target defect rather than a test environment anomaly?
• Does the same input no longer trigger in the fixed version?

Dynamic reproduction can eliminate many static false positives, but “the program crashes” still does not mean “a high-risk vulnerability exists.” Some crashes only terminate the current process, some can be triggered only by high-privilege users, and others are blocked by existing protections.

4. Exploitability Assessment: Determine Whether a Security Boundary Can Be Crossed

The truly expensive and sensitive part is determining whether a defect can be turned into privilege escalation, data leakage, arbitrary code execution, or security control bypass.

A mature process does not test only in an idealized environment with protections disabled. It should verify under configurations close to production, including:

• Address space layout randomization;
• Kernel and user-space access isolation;
• Non-executable memory protection;
• Control-flow integrity constraints;
• Least-privilege policies;
• Container or virtualization isolation;
• Default compile-time and runtime protections.

This is the most costly stage in the entire chain in terms of computation, environment construction, and expert review. The reason is that moving from an abnormal crash to reliable boundary crossing requires understanding memory layout, object lifecycle, scheduling timing, and protection mechanisms. Models can improve analysis efficiency, but they cannot bypass the complexity of real systems.

To reduce abuse risk, internal exploitability verification should be strictly controlled: run only on authorized assets, use isolated environments without outbound internet access, restrict the export of artifacts, and require two-person approval for high-risk actions.

5. Variant Merging: Avoid Counting One Vulnerability Multiple Times

The same root cause may produce multiple trigger samples. For example, a missing length check may be triggered through different input paths, or may manifest as different crashes in several adjacent functions. Counting by crash samples will significantly inflate the number of vulnerabilities.

Variant merging usually considers:

• The code location of the defect;
• Data flow and call paths;
• Crash stack similarity;
• Trigger conditions;
• Scope affected by the remediation patch;
• Root-cause category;
• Regression results before and after the fix.

Only after root-cause merging can an accurate “number of independent vulnerabilities” be obtained. Therefore, hundreds of patches, hundreds of trigger samples, and hundreds of independent vulnerabilities cannot be directly equated.

3. Why Measurement Definitions Matter More Than Model Leaderboards

When evaluating security LLMs, enterprises should not focus only on the total number of candidate findings. More candidates do not necessarily mean stronger capability; they may also indicate insufficient false-positive control.

At minimum, organizations should disclose metrics such as the following.

1. Code Coverage

Organizations should state how much code was analyzed, which modules were not covered, and whether coverage is calculated by file count, lines of code, function count, or reachable paths. If only a small set of high-risk areas was scanned, the results cannot represent the security state of the entire codebase.

2. Candidate Confirmation Rate

The candidate confirmation rate can be expressed as:

Candidate confirmation rate =
    Candidates successfully reproduced dynamically
  / Total static candidates

It reflects how many static analysis results have real triggering conditions, but it still cannot replace vulnerability precision.

3. Security Boundary Breakout Rate

Boundary breakout rate =
    Issues that cross security boundaries
  / Reproduced issues

This metric is closer to real risk than crash count alone, but the criteria for “crossing a security boundary” must be clearly defined.

4. Root-Cause Merge Rate

If many samples ultimately map to a small number of root causes, the raw finding count has strong duplication. Enterprises should record the mapping among “trigger sample—candidate issue—independent root cause—patch” to ensure the audit process is traceable.

5. Patch Effectiveness

A patch must not only prevent the original sample from triggering; it must also satisfy the following:

• It does not introduce new security defects;
• It does not break normal functionality;
• It does not significantly degrade performance;
• It does not change necessary compatibility behavior;
• It covers other variants of the same root cause.

Therefore, automatically generated patches cannot be directly regarded as completed remediation. A patch without regression testing, code review, and canary validation may simply move the problem from one path to another.

4. How These Capabilities Will Change Defensive Systems

1. Vulnerability Auditing Will Move from Sampling to Continuous Operation

Traditional manual audits are often concentrated before major releases, and coverage is limited by budget and the number of experts. Security LLMs can embed auditing into code commits, version builds, and release processes, turning it into a continuous capability.

A practical layered strategy is:

• Run low-cost rule checks on every code commit;
• Perform semantic analysis on changed modules daily;
• Run dynamic verification on high-risk paths weekly;
• Conduct a complete attack surface review before major releases;
• Periodically conduct manual audits of core privilege boundaries.

This controls compute costs while exposing issues as early as possible in development.

2. The Security Team’s Bottleneck Will Shift from “Discovery” to “Disposition”

When models produce large numbers of candidate issues every day, security teams may face a new backlog: who confirms them, who assigns severity, who fixes them, which release includes them, and whether users need to be notified.

Enterprises therefore need automated triage mechanisms:

• Prioritize by asset criticality and reachability;
• Raise priority for internet-exposed assets;
• Expedite issues with signs of abnormal access;
• Merge same-root-cause issues into one remediation task;
• Automatically associate responsible teams, code owners, and release windows;
• Trigger management escalation for overdue high-risk issues.

In the future, the gap in defensive capability will not only depend on who finds more issues, but also on who can convert findings into effective fixes faster.

3. Patch Engineering Will Become More Important

Finding vulnerabilities is only the starting point. Complex foundational software often has extensive compatibility constraints, and any patch may affect performance, stability, or existing interfaces.

Security LLMs can propose remediation suggestions, generate test cases, and explain root causes, but final patches should still go through:

1. Code owner review;
2. Security expert review;
3. Unit and integration testing;
4. Performance and compatibility testing;
5. Variant regression verification;
6. Staged release;
7. Online monitoring and rollback readiness.

If an organization lacks mature software supply chain and release governance, more findings can instead create unmanageable security debt.

5. Attackers Will Benefit Too, but Not Symmetrically

Security LLMs lower the barrier to code understanding, vulnerability filtering, and test sample generation. Attackers may also use these capabilities to study public code in bulk, analyze patch differences, or find systems that have not yet been upgraded.

However, attack and defense are not completely symmetrical.

Defenders have complete code, build environments, test data, asset inventories, and logs, and can perform continuous analysis under authorized conditions. Attackers usually lack this context, but they need to succeed only once at one entry point. Defenders must protect all critical paths and ensure that patches do not break business operations.

This means future attacker-defender competition will place greater emphasis on time gaps:

• How long after a defect is discovered until it is confirmed;
• How long after a patch is released until production assets are covered;
• How long after abnormal behavior appears until an alert is triggered;
• Whether high-risk services can be temporarily mitigated before remediation;
• Whether new variants targeting the same root cause can be identified.

Models shorten the discovery cycle and may also shorten attack preparation cycles. Enterprises can no longer rely on the implicit defense that “vulnerabilities are hard to discover.” They should focus on least privilege, defense in depth, rapid remediation, and continuous monitoring.

6. Controls Enterprises Should Establish During Deployment

1. Define Authorization Boundaries Clearly

All scanning, reproduction, and verification activities must be limited to assets owned by the enterprise or explicitly authorized. The task system should record the requester, approver, target code, test environment, execution time, and output destination.

2. Isolate High-Risk Execution Environments

Dynamic reproduction environments should be isolated from production networks and configured with:

• No default outbound internet access;
• Temporary credentials and least privilege;
• Resource quotas;
• Process and file system isolation;
• Complete operation auditing;
• Environment destruction after task completion;
• Export approval for high-risk artifacts.

3. Control the Actions Models Can Perform

Models can propose hypotheses and generate test plans, but they should not have production operation permissions by default. A more reasonable approach is tiered authorization:

• Low risk: read code, generate explanations, and suggest tests;
• Medium risk: compile, run, and collect logs in a sandbox;
• High risk: validate privilege boundaries and generate executable validation samples;
• Strictly controlled: access production data, modify critical configurations, or release patches.

The higher the risk, the stricter human approval and environmental restrictions should be.

4. Ensure Data and Conclusions Are Traceable

Every finding should retain the following evidence:

• Affected code version;
• Trigger conditions and minimal reproduction input;
• Analysis process and key logs;
• Basis for risk determination;
• Root-cause merge relationships;
• Fix commits and test results;
• Human review comments;
• Release and rollback records.

Model conclusions without an evidence chain should not directly enter high-risk vulnerability statistics, and should certainly not automatically trigger production changes.

7. How to Judge Whether Security LLMs Create Real Value

Enterprises should not make “how many reports were generated” a core objective. They should focus on business and security metrics such as:

• Whether the average confirmation time for high-risk issues is reduced;
• Whether the time from confirmation to remediation decreases;
• Whether the proportion of recurring defects of the same type in production decreases;
• Whether the additional cost of false positives on engineering teams is controllable;
• Whether fixes cover other code paths with the same root cause;
• Whether effective audit coverage of critical code increases;
• Whether the failure rate caused by patches after release is acceptable;
• Whether the overall discovery and remediation cost per valid issue decreases.

Only when models enter a complete governance loop, reduce real risk, and improve remediation efficiency do they become security productivity tools. If they merely generate large batches of candidate reports without validation, merging, remediation, and release capabilities, then even large finding numbers may simply become a new source of noise.

8. Conclusion

The fundamental change brought by security LLMs is not that machines can suddenly replace all security researchers. Rather, vulnerability research is beginning to become industrialized, parallelized, and continuous. Code reconnaissance, candidate generation, and initial reproduction can be automated at scale, while security experts devote more effort to threat modeling, root-cause analysis, risk judgment, and remediation decisions.

At the same time, models do not eliminate false positives, coverage gaps, environment differences, or patch risks. Hundreds of candidate findings do not equal hundreds of independent vulnerabilities. Successful triggering does not equal exploitability. Generating a patch does not equal completing remediation.

In the future, a truly competitive security system will not be defined by possessing a single stronger model. It will be defined by a complete loop from asset identification, code analysis, isolated validation, and human review to patch release and continuous monitoring. For enterprises, the most important question is no longer “how many issues can the model find,” but “can the organization safely, accurately, and quickly enough digest those findings.”