From “Model Demo” to “Engineering Pipeline”: The Paradigm Shift in Automated Vulnerability Discovery

Over the past two years, large language models have made visible progress in code understanding and generation. But dropping a model directly into a real network environment to “improvise” tends to run into three engineering walls: excessive alert noise, irreproducible vulnerabilities, and results that cannot be turned into deliverable patches. A recent class of industry explorations addresses this by restructuring “AI bug hunting” from a single-point capability demo into a multi-stage, measurable, and rollback-capable automated pipeline: reconnaissance and alert generation, crash validation and deduplication, exploit-chain construction and privilege-escalation verification, and patch generation with regression testing.

The key to this pipeline lies not in how “powerful” any single model is, but in separating “discovery” from “proof”: discovery can tolerate a certain rate of false positives, but the proof stage must be backed by executable, reproducible crash samples. This article takes a general technical perspective and breaks down the layered design, measurement methods, and security boundaries of such a pipeline, as a reference for teams hoping to introduce intelligent security testing into their own development processes.

Pipeline Layered Design: Four Stages and Their Acceptance Criteria

Stage 1: Reconnaissance — Turning “Code Scale” into a Suspect Ranking

Real kernels or large services can easily contain tens of millions of lines of code, and having a model read every line is both expensive and inefficient. A common engineering pattern is a dual-agent “scout plus analyst” structure:

• The scout agent performs static scanning and slicing, focusing on high-risk patterns such as memory lifecycle, permission boundaries, input validation, and concurrency synchronization, and outputs minimal code snippets with their context;
• The analyst agent performs semantic reasoning on each snippet to determine whether a path from “controllable input to dangerous operation” exists, and outputs structured suspected-vulnerability alerts.

The output of this stage is not a “vulnerability list” but a “queue of hypotheses pending validation.” Each hypothesis should include: the trigger entry point, the tainted path, an impact estimate, and a confidence score. Confidence is used for ranking, not for conclusions.

Example alert structure (pseudo-code)
{
  "id": "H-0001",
  "entry": "ioctl_handler_x",
  "sink": "copy_from_user -> length field used in pointer offset",
  "path": ["user_input", "parse_header", "len_check_missing", "memcpy"],
  "confidence": 0.62,
  "priority": "high"
}

An important engineering lesson: do not treat the false-positive rate as a failure metric—treat it as a cost metric. It is acceptable for a large share of alerts to be disproved during review; what actually determines pipeline usability is the validation cost per real vulnerability.

Stage 2: Validation — Replacing “The Model Says It Crashes” with Real Crashes

Many security teams’ pain point is not “failing to find suspected issues” but “being unable to prove them.” The goal of the validation stage is to turn hypotheses into reproducible crash samples:

• Construct inputs in a controlled sandbox to trigger observable anomalies such as out-of-bounds reads/writes, null pointer dereferences, or race conditions;
• Deduplicate and cluster crash samples so that the same root cause is not counted multiple times;
• Record complete environment information (kernel/runtime version, compiler options, mitigation switches) to guarantee reproducibility.

The measurement criteria must be defined clearly from the start: the number of alerts, the number of crashes triggered, the number of root causes confirmed through manual review, and the false-positive rate. All four are indispensable—otherwise it is easy to reach conclusions that look impressive but are practically unusable. The industry’s common definition of the false-positive rate is “the proportion of alerts disproved during review”; in a mature pipeline this typically needs to be driven down to single-digit percentages before the pipeline is worth deploying into production workflows.

Stage 3: Exploitation — From “Can Crash” to “Can Escalate” Is a Two-Orders-of-Magnitude Leap

Crash validation only proves “a defect exists”; exploit construction proves “the defect can be converted into privilege escalation.” This is often the most expensive stage of the pipeline, and the one that most reflects engineering capability:

• Multiple independent defects must be chained into an attack—for example, information disclosure combined with an out-of-bounds write, combined with an isolation-layer escape;
• Exploit reliability must be verified on systems with modern mitigations enabled (address randomization, stack protection, control-flow integrity, read-only page tables, and so on);
• A distinction must be made between “theoretically exploitable” and “stably exploitable on standard configurations.”

It is advisable to label exploit output at three levels: crash only, controllable execution flow, and stable privilege escalation. Only the third level should count toward the “high-risk exploitable vulnerability” metric. Mixing the first two levels into the statistics seriously overestimates actual risk and capability.

# Example verification environment: modern mitigations enabled
kernel.hardening = on
sandbox.microvm = on
aslr = on
stack_guard = on
cfi = on
# All samples run in isolated instances; external network access is blocked

Stage 4: Remediation — Patches Must Be “Regression-Tested, Rollback-Capable, and Auditable”

The endpoint of automated discovery is not a report but a patch. A deliverable patch should at minimum satisfy the following:

• It ships with a minimal reproducing test case that reliably triggers the bug before the fix and reliably passes after it;
• It passes the existing regression test suite without introducing new crash samples;
• It includes a clear root-cause description and impact assessment, so release managers can make risk judgments at version time;
• It has a rollback path in case the patch itself introduces stability issues.

Including “patch generation” in the pipeline is the watershed between intelligent security testing as a “research demo” and as a “component of the development process.” A patch without regression verification is essentially just another kind of risk.

Cost and Benefit: Replace “Sensational Numbers” with “Cost per Real Vulnerability”

Discussions of automated vulnerability discovery most easily lose focus by fixating on absolute numbers. More reasonable metrics are three ratios:

1. Cost per real vulnerability = total token/compute spend ÷ number of root causes confirmed through review;
2. Exploit conversion rate = number of samples achieving stable privilege escalation ÷ number of confirmed root causes;
3. Return multiple = monetized bug-bounty value ÷ total spend.

Note that the return multiple depends heavily on bounty pricing and the vulnerability severity distribution, making it unsuitable for cross-team comparison. Cost per real vulnerability and the exploit conversion rate are relatively stable and better suited as optimization targets for pipeline iterations. A common pattern in practice: shifting budget from “expanding scan coverage” to “improving validation and clustering quality” significantly reduces unit cost, because duplicate root causes and irreproducible samples are largely eliminated.

Another easily overlooked cost is manual review. An intelligent pipeline outputs a “hypothesis queue”; final classification still requires security engineers. Pipeline design should therefore prioritize reducing “high-cost review items”: merging duplicate alerts for the same code region, delaying validation of low-confidence alerts, and auto-generating review summaries for validated samples.

Security Boundaries: The Stronger the Capability, the Earlier Isolation Must Come

Automated vulnerability discovery inherently carries offensive capability, so engineering rollouts must put security boundaries at the very front rather than patching them in afterward.

1. Execution Isolation

• All validation and exploit construction runs in disposable sandboxes or microVMs, with no external network and no persistent storage by default;
• Each task uses a separate instance; instances are destroyed after the task and verified to leave no residue;
• Escape-type validation gets a separate resource pool, physically isolated from routine validation.

2. Permissions and Audit

• Pipeline “reconnaissance” permissions and “exploitation” permissions are separated: the former has read-only access to code and build artifacts, while the latter is effective only within the isolated environment;
• The full chain—input samples, model calls, executed commands, and outputs—is logged for traceability;
• High-risk operations (such as host-level verification) require dual approval and are time-boxed.

3. Disclosure and Coordination

High-risk vulnerabilities found automatically should follow the standard disclosure process: fix internally first, then assess whether upstream coordination is needed, and only then consider public disclosure. The pipeline itself must not have the ability to “submit externally,” which could prematurely expose false positives or unpatched vulnerabilities.

4. Data Boundaries

Code and crash samples are sensitive assets. The pipeline should define a data retention policy: sample retention period, desensitization rules, whether model calls leave the security domain, and whether data may be used for training. For most teams, “no data leaving the domain + short-term retention + aggregated statistics” is a sound default configuration.

Implementation Advice: Start with One Narrow Pipeline

If a team wants to introduce this kind of capability, chasing “fully automated end-to-end” from day one is unwise. The more pragmatic path is:

1. Pick a narrow scenario: lock onto one high-value, reproducible module first (a specific class of parser, a class of driver interfaces) and get the alert-to-crash-validation segment working;
2. Fix the metrics first: define the four criteria—alerts, crashes, root causes, false positives—before talking about model selection;
3. Subtract first: prioritize improving deduplication and clustering; once duplicate alerts are suppressed, unit cost improves immediately;
4. Close the patch loop: even if patches cover only a small fraction of root causes, establish the “patch + regression test case” workflow;
5. Security before capability: isolation, audit, and approval must be in place before the first exploit-validation run.

Recommended minimal pipeline
[code slicing] -> [alert queue] -> [sandbox validation] -> [crash clustering]
      -> [manual review] -> [patch + regression tests] -> [release]

Conclusion

The value of AI in vulnerability discovery lies not in “how many bugs it finds in one run” but in turning security testing from “labor-intensive sampling” into a “measurable, reproducible, regression-capable engineering capability.” What ultimately determines whether such a pipeline can run over the long term is false-positive governance, validation rigor, and security boundary design—not any single headline number from a demo. For developers and enterprises, building the measurement criteria and isolation mechanisms first, then gradually expanding model coverage, is the lowest-risk, steadiest-return path. Capabilities in general-purpose categories such as container platforms, object storage, logging, and monitoring—such as those offered by Baidu AI Cloud—can serve as one of the infrastructure options for hosting such pipelines, but the pipeline’s design and verification discipline still rest on the team’s own engineering practice.