[KongchangAI]
· 2 min read· 1,133 words

AI Agents + SRC in Practice: Building a Vulnerability Discovery Workbench from Scratch

AI Agents + SRC in Practice: Building a Vulnerability Discovery Workbench from Scratch

AI-assisted SRC vulnerability discovery doesn't change the three-step method or four elements—its value lies in reducing cost and boosting efficiency.

The article discusses the paradigm shift in enterprises using AI for SRC vulnerability discovery: from experience-driven manual testing by security personnel to "humans design workflows, AI executes workflows." The core point is that AI doesn't change the underlying methodology—the universal three-step method (information gathering—vulnerability verification—deliverable output) and the four elements of a vulnerability report (URL, reproduction steps, impact description, remediation recommendations) still apply, and AI's value lies in lowering the execution cost of each stage. The article specifically distinguishes between web chat and a dedicated workbench: the former suits consultation and idea organization, while only the latter can support multi-step vulnerability hunting workflows that require tool calls and context preservation. It also emphasizes that remediation recommendations and severity judgments must be human-reviewed, and offers advice for beginners and experienced practitioners at different starting points.

Why Enterprises Are Starting to Use AI for Vulnerability Discovery

SRC (Security Response Center) vulnerability discovery is undergoing a paradigm shift in tooling. In the traditional model, security personnel relied on experience-driven manual testing, with efficiency limited by individual skill level and time cost. The introduction of AI agents is gradually shifting vulnerability discovery from "humans finding vulnerabilities" to "humans designing workflows, AI executing workflows."

According to an analysis of a hands-on tutorial by a Bilibili creator, the core demand for enterprises using SRC is to continuously discover real risks at a controllable cost. AI does not change this goal; what it changes is the means of achieving it—delegating repetitive information gathering, payload attempts, and report organization to the model, while leaving judgment and decision-making to humans.

Overview of the AI-assisted vulnerability discovery workbench

SRC (Security Response Center) is a security emergency response center established by enterprises or platforms, dedicated to receiving vulnerability reports submitted by external security researchers and responsible for verification, rating, fix tracking, and reward distribution. For white-hat hackers, SRC is a legal, authorized channel for vulnerability submission; for enterprises, SRC is a mechanism for continuously acquiring external security intelligence and reducing security risk through crowdsourced testing. Major domestic internet companies, open-source communities, and even some government and enterprise institutions have established SRCs, and the Bug Bounty ecosystem built around SRC is also an important way for security practitioners to accumulate hands-on experience. Understanding how SRC operates helps clarify why AI-assisted vulnerability discovery emphasizes "real risk" and "controllable cost"—what SRC pursues is not the number of vulnerabilities but verifiable, fixable, valid vulnerabilities.

The Universal Three-Step Method for Vulnerability Discovery—AI Can't Bypass It Either

The tutorial repeatedly emphasizes one point: whether it's traditional manual vulnerability hunting or AI-assisted vulnerability hunting, the underlying methodology is the same. The so-called universal three-step method is essentially a closed loop of "information gathering—vulnerability verification—deliverable output."

The value of AI agents is not in skipping these three steps but in lowering the execution cost of each step. For example, in the information gathering phase, agents can automatically crawl target assets, parse response headers, and identify tech stacks; in the verification phase, they can batch-generate and send test requests; in the output phase, they can organize the evidence chain according to templates.

This is especially important for beginners: don't expect that plugging in a model will automatically produce vulnerabilities—the quality of workflow orchestration determines the final output.

"Tech stack identification" in information gathering refers to determining the programming language, web framework, middleware, database, front-end libraries, and version information used by the target website. Common methods include parsing HTTP response headers (such as Server, X-Powered-By), analyzing page characteristics (such as the naming and directory structure of JS files), identifying favicon hashes, and probing default files at specific paths. The tech stack directly determines the subsequent verification direction: for example, if Spring Boot is identified, priority can be given to Actuator endpoints and SpEL injection; if ThinkPHP is identified, focus on historical RCEs and deserialization. The advantage of AI agents here is their ability to process large numbers of response features in parallel and summarize matches, but maintenance of the feature library and correction of false positives still require human intervention.

The Four Elements of a Vulnerability Report: What AI Can't Omit

The tutorial explicitly mentions the four elements of a vulnerability report—URL, reproduction steps, impact description, and remediation recommendations. These four elements are equally indispensable in AI-assisted scenarios.

Illustration of the four elements of a vulnerability report

What the model can help with: extracting URLs and parameters from request responses, organizing verification steps into a reproducible sequence of steps, and generating draft impact descriptions based on vulnerability type. However, the accuracy of remediation recommendations and the judgment of severity levels still require human review. Letting AI generate all four elements without verification is the easiest pitfall to fall into in practice.

The impact description needs to answer "what can this vulnerability be used for," and typically requires assessing the scope of impact in the context of business scenarios—for example, whether it can lead to user data leakage, privilege escalation, or server takeover. Remediation recommendations should provide actionable solutions targeting specific causes, such as parameterized queries, output encoding, access control hardening, or dependency upgrades. Severity level judgment often references standards such as CVSS (Common Vulnerability Scoring System), scoring across dimensions including attack vector, complexity, privileges required, user interaction, and confidentiality/integrity/availability impact. Because these judgments depend on understanding of business context and attack chains, models tend to produce generic, templated conclusions, making human review indispensable.

Web Chat vs. Workbench: The Difference Between Two Ways of Using AI

The tutorial contrasts a key distinction: directly opening web-based chat tools like DeepSeekAd or Kimi versus building a dedicated AI vulnerability discovery workbench are two usages of different magnitudes.

Moving from web chat to workbench mode

Web chat is a linear question-and-answer interaction, suitable for quick consultation and idea organization, but it cannot support multi-step vulnerability hunting workflows that require tool calls and context preservation. Workbench mode integrates the model into an orchestratable workflow, enabling agents to execute tasks according to preset steps, call external tools, and record intermediate results.

For those who want to seriously pursue AI-assisted SRC, the workbench is a necessary investment. The tutorial demonstrates the basic operation of interacting with the DeepSeek website as a contrast to illustrate the limitations of web mode.

The interaction interface of web chat mode

The technical foundation of workbench mode is the Agent and Tool Calling/Function Calling capability: the model no longer only outputs text but can decide which tool to call and what parameters to pass according to an orchestrated workflow, then read the tool's return results to continue reasoning. Common workbench forms include workflows built on frameworks such as LangChain, Dify, and Coze, as well as platforms that support protocols like MCP (Model Context Protocol) to connect external tools. Workbenches also need context management and intermediate result persistence capabilities to support multi-step vulnerability hunting tasks. This is the fundamental reason why web chat cannot replace the workbench—web mode lacks the two key capabilities of tool execution and state preservation.

Practical Advice for Different Starting Points

The paths for cybersecurity beginners and seasoned experts differ, but the destination is the same: both deliver results according to the three-step method and four elements. Beginners can start by reproducing the workbench setup process from the tutorial, first getting a minimal closed loop running; experienced security personnel can focus their energy on the soundness of workflow design—for example, how to design prompts so the model judges response anomalies more accurately, and how to set up human review checkpoints.

AI-assisted vulnerability discovery doesn't replace security capability; it amplifies it. Methodology is the skeleton, AI is the accelerator—neither can be dispensed with.

#AI vulnerability discovery#SRC#AI agents#Bug Bounty#security workbench
Share:

Related articles