How AI-Driven Automated Vulnerability Discovery Is Reshaping Cybersecurity Offense and Defense

Recent industry discussion around a model-driven automated code-scanning effort illustrates the shift: covering a large operating system kernel at a cost in the millions produced hundreds of high-severity candidate vulnerabilities, translating to roughly the thousand-dollar level per vulnerability. The most important point is not whether a model can find vulnerabilities. It is that the cost structure of vulnerability discovery, validation, remediation, and governance is being redistributed.

Work that once depended on highly skilled security experts auditing code section by section is being broken into a pipeline: context collection, model-generated candidates, dynamic tool validation, human risk decisions, and patch regression. Both attackers and defenders may gain stronger automation. What determines effectiveness is not the raw number of findings from a single scan, but the validation loop, access control, response speed, and governance.

1. Cost Structure Changes: Discovery Gets Cheaper, but Validation and Remediation Remain Bottlenecks

Model-assisted auditing first changes the marginal cost of vulnerability discovery. Traditional manual auditing is constrained by the number of experts, code size, and audit cycles, so coverage is often limited. Models can perform pattern recognition, data-flow tracing, and suspicious-path generation across large amounts of code in a relatively short time, expanding the supply of candidate vulnerabilities. But a candidate is not a confirmed vulnerability; confirmation is not the same as exploitability; and exploitability does not mean a finding should be fixed first. The real cost of a vulnerability includes at least scanning cost, false-positive management, dynamic reproduction, impact assessment, patch development, regression testing, and post-release monitoring.

Therefore, a figure on the order of a thousand dollars per vulnerability only suggests that discovery-phase costs may fall. It does not directly imply that total security cost will fall. If the model produces a high false-positive rate, security teams can be overwhelmed by low-quality alerts, and expert time is consumed by triage. Enterprises should shift metrics from “how many vulnerabilities were found” to “how many high-risk vulnerabilities were confirmed and fixed, average validation time, average remediation time, regression failure rate, and false-positive handling cost.” Compute is necessary but not sufficient. Without code context, dependency relationships, runtime information, and validation tools, simply adding compute only produces more candidates to screen.

2. Technical Lessons from a Scorer Bypass Case

A representative case discussed publicly involved a math-answer scorer that only allowed letter input and then normalized visually similar characters into ordinary letters in later processing. The attack input used character-shape differences to pass the check, then accessed object documentation strings and extracted characters by position to assemble executable semantics. The resulting expression executed external side effects while returning a normal numeric value, causing the scorer to misclassify it as a correct answer. The lesson is that a security boundary cannot be based on “what a character looks like.” It must be based on “what is allowed to happen after parsing.”

First, character checks and execution semantics can diverge. If a whitelist runs before normalization, input may bypass the check; if it runs after normalization, new ambiguity may be introduced. A more robust approach is to parse the input into an abstract syntax tree and then constrain node types, name calls, attribute access, subscripting, strings, and import capabilities through a whitelist.

Second, data can become code. Documentation strings, metadata, comments, and configuration fields are not code by themselves, but once they are accessed reflectively and used in concatenation, they can become a source of code fragments. Untrusted input should not be given access to reflection interfaces, metadata, or dynamic evaluation capabilities.

Third, side effects and return values must be audited separately. A scorer that checks only the return value and ignores external side effects such as system command execution can misclassify input that “executed a command but returned a normal value” as correct. A secure evaluator should disable external side effects by default and monitor file, network, process, and resource usage in a sandbox.

Fourth, least privilege is the last line of defense. Even if a check is bypassed, a read-only file system, disabled network, timeouts, resource limits, system-call filtering, and a low-privilege account can limit the impact. Fifth, observability is essential. Recording raw input, parsing results, system calls, and resource consumption is necessary to reconstruct bypass paths and improve rules.

3. Changes for Attackers and Defenders: From Point Capabilities to Platform Competition

For the attack side, models can accelerate code auditing, configuration review, social-engineering content generation, and exploit ideation, and the scale of vulnerability discovery may increase. But attacks are still constrained by target visibility, permissions, stealth, and detection pressure. Automated generation does not equal reliable exploitability.

For the defense side, models can support left-shifted code auditing, dependency-risk identification, patch suggestions, regression testing, and log anomaly analysis. Defenders also have advantages such as asset inventories, permission boundaries, and release processes. The key is whether they can engineer those advantages.

Vulnerability economics will also change. As discovery costs fall, the value of validation, exploitation, and remediation rises relatively. Enterprises need stricter vulnerability lifecycle management, including severity classification, reproduction, impact assessment, canary patching, monitoring and alerting, and postmortems. Offense and defense competition is no longer just about “whose model is smarter.” It is a combined competition across data quality, compute supply, toolchain completeness, access control, response speed, and governance capability.

4. Enterprise Adoption: Build a Closed Loop of Candidate Generation, Isolated Validation, and Human Decision-Making

The first step is asset and context collection, including code repositories, dependency lists, configurations, runtime information, logs, and ticket data, with proper classification and data masking. The second step is model-assisted auditing. Candidate generation can use code slicing, cross-file context, prompt templates, and deduplication and ranking. Output must include an evidence chain, such as file location, data-flow path, trigger conditions, and impact scope.

The third step is dynamic validation. The validation environment should use isolated sandboxes, least privilege, read-only file systems, disabled network access, timeouts, and resource limits, while monitoring system calls and external side effects. On Baidu AI Cloud, teams can build isolated validation and audit environments using general container platforms, logging services, and monitoring and alerting capabilities, but the core remains least privilege and fail-closed behavior. The fourth step is judgment and scoring, using abstract syntax tree whitelists, type constraints, differential testing, fuzzing, and human review. High-risk and exploitable issues must be confirmed by people. The fifth step is the remediation loop, including patch suggestions, regression testing, canary releases, monitoring and alerting, and postmortems. The sixth step is governance, including permission tiers, audit logs, data isolation, red-team evaluation, and compliance checks.

5. Secure Scorer Example: Parse First, Constrain, Then Monitor

The following is simplified pseudocode for a secure evaluator. The main point is not the specific implementation, but the design principles:

allowed_nodes = {constants, binary operations, unary operations,
                 addition, subtraction, multiplication, division}
function safe_eval(expression):
    ast = parse_to_abstract_syntax_tree(expression)
    for node in traverse(ast):
        if type(node) not in allowed_nodes:
            reject_and_log()
    result = restricted_interpreter(ast, read_only_symbol_table)
    if this_evaluation_produced_external_side_effects:
        reject_and_alert()
    return result

The key points are: parse before validation; prohibit name calls, attribute access, subscripting, strings, imports, and loops; limit execution time and memory; monitor side effects; and fail closed on any exception. For a scorer, the input is untrusted code, not ordinary text. A check that “only allows letters” is far from sufficient.

6. Talent and Organization: Expert Value Shifts to Defining Boundaries and Making Decisions

Models will not simply eliminate security experts. They will change where experts focus. Experts will move from large amounts of manual vulnerability hunting to defining audit objectives, designing prompts and toolchains, validating model output, assessing business impact, maintaining evaluation benchmarks, and making risk decisions. Teams need combined capabilities: security engineering, model evaluation, and platform engineering. Organizational KPIs should shift from vulnerability counts to confirmed high-risk remediation rate, average remediation time, false-positive cost, and regression failure rate.

Conclusion

AI-driven automated vulnerability discovery will not reduce cybersecurity offense and defense to a simple contest of compute. It expands the supply of vulnerability discovery and moves the bottleneck to validation, remediation, and governance. Defenders should build an engineering system that combines model-generated candidates, tool-based validation, human decision-making, and a remediation loop, using isolation, least privilege, semantic whitelists, and audit monitoring to control risk. The ultimate competition is a combined competition across compute, data, engineering, and governance. The value of security experts lies in defining boundaries, explaining risk, and owning decisions.