Automatic web vulnerability detection and verification method based on large model

Abstract

The invention discloses an automatic web vulnerability detection and verification method based on a large model. The method specifically comprises the following steps: collecting network equipment traffic through a bypass, identifying Web traffic by adopting feature code matching, and analyzing key elements. The method comprises the following steps: firstly, comparing with a vulnerability library to realize rapid early warning of known vulnerabilities, if the vulnerabilities are not hit, entering a large model detection link, deeply analyzing multi-dimensional data based on a fine tuning model, outputting vulnerability types and accurately positioning. And after potential vulnerabilities are detected, the system automatically generates a POC script for verification, and a successful case is supplemented to a vulnerability library to form a closed loop learning mechanism. According to the method, through a three-layer architecture of feature matching, model reasoning and dynamic verification, the detection efficiency and the coverage capability are considered, meanwhile, the vulnerability library is continuously optimized, and the self-evolution of the detection capability is realized.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and mainly to a method for automated web vulnerability detection and verification based on a large model. Background Technology

[0002] As global digitalization accelerates, web applications have permeated core sectors such as finance, government affairs, and healthcare. However, their increased complexity has also spurred an explosive growth in security vulnerabilities. According to CNNVD data in 2024, web-related vulnerabilities accounted for 44.9% of all vulnerabilities. Traditional vulnerabilities such as cross-site scripting (XSS) and SQL injection remain dominant, while new threats such as API abuse and cloud-native configuration errors continue to emerge. The necessity of early vulnerability detection is increasingly evident, not only to avoid huge economic losses from data breaches but also to prevent critical service disruptions. Faced with the rapid evolution of attack methods, early vulnerability detection has become the most cost-effective and efficient core component of an enterprise's security defense system.

[0003] Web vulnerability discovery technology is currently undergoing a critical transition from traditional methods to combat emerging threats, but its development is still constrained by multiple disadvantages. At the automation level, while scanning tools cover basic vulnerabilities such as SQL injection and XSS, comprehensive coverage is difficult. Furthermore, when facing new attack surfaces like API abuse and container escape in cloud-native architectures, traditional vulnerability scanning applications require pre-configured scan paths and parameters, resulting in insufficient coverage. Static analysis tools have a false positive rate as high as 30%-40% and struggle to identify the contextual relationships of business logic vulnerabilities. In terms of manual auditing, complex vulnerabilities such as unauthorized payments and multi-step permission escape require an average of 8-12 hours of in-depth analysis per case, resulting in significant efficiency bottlenecks. More seriously, AI-driven dynamic attacks (such as adaptive SQL injection) have compressed the vulnerability exploitation cycle to 45 days, while traditional patch analysis techniques rely on vendor disclosures, resulting in a response lag of at least 72 hours for zero-day vulnerabilities. In addition, non-code vulnerabilities such as cloud environment misconfigurations (such as open S3 bucket permissions) lack quantitative assessment standards, and existing detection methods can only detect about 15% of such risks. These disadvantages expose the lack of systematic solutions to fundamental problems such as "blurred trust boundaries" (e.g., the stateless verification defects of JWT) and "logical inconsistency" in current technologies. There is an urgent need to break through the semantic understanding bottleneck of automated tools and establish automated detection. Summary of the Invention

[0004] To address the above-mentioned issues, this invention proposes an automated web vulnerability detection and verification system based on a large model. It rapidly detects web vulnerabilities and automatically constructs corresponding Proof-of-Concept (POC) scripts to verify them by combining bypass traffic acquisition and parsing techniques with large model technology. According to a first aspect of this invention, a method for automated web vulnerability detection and verification based on a large model is proposed, with the following specific steps:

[0005] S1. Real-time collection of bypass traffic from network devices, identification and classification of traffic using signature matching method to obtain Web traffic data;

[0006] S2. Parse the Web traffic data and extract the request method, request URL path, request header, request parameters and request name;

[0007] S3. Based on the request method, request URL path, and parameter name, search the vulnerability database for a corresponding vulnerability; if it exists, output a vulnerability warning and end the detection; if it does not exist, proceed to the next step.

[0008] S4. Input the Web request data parsed in step S2 into the vulnerability detection big model obtained through micro-training. Use the vulnerability detection big model to perform potential vulnerability detection on the request method, request URL path, request header, request parameters and request name. If a potential vulnerability is detected, output the vulnerability type and location. If no vulnerability is detected, output "not found" and end the detection.

[0009] S5. Based on the Web request data parsed in step S2 and the detection results in step S4, generate the corresponding POC verification script using the vulnerability detection big model and execute it. Determine whether the POC verification is successful based on the execution result. If successful, store the request method, request URL path, request header, request parameters, request name and the corresponding POC verification script in the vulnerability database and output vulnerability warning information. If unsuccessful, determine whether to continue executing the POC verification until successful or the threshold is reached based on a preset threshold.

[0010] Preferably, the collection of bypass traffic includes collecting mirror traffic and dynamically generating a unique session identifier for each session at the collection end, and maintaining the correspondence with the subsequent POC verification results to form a backtracking training sample link.

[0011] Preferably, during the identification and classification process, the TLS / QUIC fingerprint information of the encrypted traffic is written into the training samples along with the parsed HTTP fields, and used as an auxiliary feature vector input to the vulnerability detection model during micro-training.

[0012] Preferably, the process of obtaining the vulnerability detection large model includes:

[0013] Obtain normal web traffic samples and web traffic samples containing various vulnerabilities, and annotate them to obtain labeled samples;

[0014] The labeled samples are preprocessed to extract the request method, request URL path, request header, request parameters and request name, and combined with the annotation results to form a data format adapted to the LLaMA-Factory micro-training framework.

[0015] Using the open-source deepseek-R1 model as the base model, and fine-tuning the training with the preprocessed samples, a large vulnerability detection model with Web vulnerability detection and inference capabilities is obtained.

[0016] Preferably, the generation of the POC verification script is based on the semantic understanding and programming capabilities of the large model, and the execution result of the POC verification script is used to update the vulnerability database, thereby realizing the automatic accumulation and expansion of vulnerability samples.

[0017] Preferably, the training samples of the vulnerability detection large model adopt an instruction-driven structured format, including: [instruction field, input field, output field].

[0018] Preferably, the instruction field includes a natural language task instruction; the input field includes a request method, a request URL path, request headers, request parameters, and a request name; the output field labels the vulnerability detection results in the form of double labels, wherein the first label is the vulnerability type, and the second label is the specific injection point or field location where the vulnerability is located.

[0019] According to a second aspect of the present invention, a computer program product is provided, on which one or more computer programs are stored, which, when executed by a computer processor, implement the method described above.

[0020] The above-described one or more technical solutions in the embodiments of this application have at least one of the following technical effects:

[0021] This invention presents an automated web vulnerability detection and verification system based on a large model, combining bypass traffic acquisition and parsing technology with open-source large model technology. This invention is the first to propose using bypass traffic acquisition and parsing technology to replace traditional trigger-based security vulnerability scanning applications. It collects and parses web traffic data from the user environment in real time. The collected and parsed request methods, request URLs, request headers, and request parameters are all real data from the target system, eliminating the need for pre-setting scan paths and parameters. This effectively solves the problem of traditional trigger-based security vulnerability scanning applications requiring pre-setting scan paths and parameters, which prevents coverage of the real paths and parameters of the entire target web system. The micro-trained vulnerability detection large model possesses both the professional ability to detect potential vulnerabilities and retains the natural language understanding capabilities of large models. It has advantages such as intelligent parsing of web application logical structures and the ability to identify the contextual relevance of business logic vulnerabilities. This effectively solves the shortcomings of traditional web vulnerability testing, such as high reliance on manual intervention, expert-designed rules, difficulty in identifying complex business logic vulnerabilities, low efficiency, and delayed detection of zero-day vulnerabilities.

[0022] Experiments show that this method can automate the detection and verification of web vulnerabilities, effectively solving the problem of incomplete coverage caused by path explosion in traditional web testing. It also effectively addresses the issues of high manual reliance, expert rule design, difficulty in identifying complex business logic vulnerabilities, low efficiency, and delayed discovery of zero-day vulnerabilities in traditional web vulnerability testing. Once the system is running, it is fully automated, requiring no pre-setting of scanning paths and parameters for the target, and no prior design of corresponding Proof-of-Concept (POC) for the target system. This significantly improves the efficiency of web vulnerability detection and verification, and reduces the human resource costs associated with vulnerability discovery. Attached Figure Description

[0023] The accompanying drawings are included to provide a further understanding of the embodiments and are incorporated in and constitute a part of this specification. The drawings illustrate embodiments and, together with the description, serve to explain the principles of the invention. Other embodiments and many anticipated advantages of the embodiments will be readily recognized as they become better understood through reference to the following detailed description. Elements in the drawings are not necessarily to scale. The same reference numerals refer to corresponding similar parts.

[0024] Figure 1 A schematic diagram of a framework for automated web vulnerability detection and verification based on a large model according to an embodiment of the present invention is shown.

[0025] Figure 2 A schematic diagram illustrating the specific process of automated web vulnerability detection and verification based on a large model according to an embodiment of the present invention is shown.

[0026] Figure 3A schematic diagram of a sample with vulnerabilities obtained according to an embodiment of the present invention is shown.

[0027] Figure 4 A schematic diagram of a normal sample obtained according to an embodiment of the present invention is shown.

[0028] Figure 5 A schematic diagram of the micro-training output of a large vulnerability detection model according to an embodiment of the present invention is shown.

[0029] Figure 6 This is a schematic diagram of the structure of a computer system suitable for implementing the electronic devices of the present application embodiments. Detailed Implementation

[0030] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0031] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0032] Figure 1 This diagram illustrates a framework for automated web vulnerability detection and verification based on a large model, according to an embodiment of the present invention. Figure 2 The detailed flowchart of the automated web vulnerability detection and verification based on the large model is shown below:

[0033] S1. Real-time collection of bypass traffic from network devices, identification and classification of traffic using signature matching method to obtain Web traffic data;

[0034] Bypass traffic collection mirrors the real business traffic and sends it to the monitoring device, which then only observes and does not intercept it. This invention not only collects the mirrored traffic but also dynamically generates a unique session identifier for each session at the collection end and maintains a correspondence with subsequent Proof-of-Concept (POC) verification results, thereby forming a traceable training sample chain to improve the continuous learning capability of the vulnerability detection model.

[0035] During the identification and classification process, the TLS / QUIC fingerprint information (JA3 / JA4) of the encrypted traffic is written into the training samples along with the parsed HTTP fields, and used as an auxiliary feature vector input into the vulnerability detection model during micro-training; among them, the TLS / QUIC fingerprint information (JA3 / JA4) hashes the ClientHello / ServerHello parameters to give client / session features.

[0036] S2. Parse the web traffic data to extract the IP address, request method, request URL path, request header, request parameters, and request name. By collecting and parsing web access data in the user environment in real time through steps S1 and S2, the problem of insufficient coverage caused by the need to pre-set scan paths and parameters in traditional security vulnerability scanning applications can be solved.

[0037] By analyzing IP addresses, request methods, URL paths, request headers, request parameters, and request names in real-time web traffic, this method achieves dynamic detection without manually predefined scanning paths and parameters, directly acquiring access data from the user's real-world environment. Compared to traditional security vulnerability scanning tools that rely on manual configuration and suffer from insufficient coverage, this method uses bypass real-time collection and automatic parsing to directly transform real traffic into detection input, constructing a configuration-free, high-coverage detection mechanism that overcomes the limitations of static preset scanning.

[0038] S3. Based on step S2, search the vulnerability database for a corresponding vulnerability according to the IP address, request method, request URL path, and parameter name. If a vulnerability exists, output a vulnerability warning and end the detection. If no vulnerability exists, proceed to the next step.

[0039] By analyzing request methods, URL paths, and parameter names in web traffic in real time, and quickly comparing them with vulnerability databases, the system provides immediate warnings and filtering for known vulnerabilities, avoiding duplicate detections. If no match is found, the system automatically proceeds to the deep detection process. This dual-layer mechanism of rapid matching and deep detection overcomes the limitations of the traditional either-or approach of vulnerability scanning and feature matching. It improves detection efficiency through vulnerability database comparison while ensuring coverage by dynamically expanding the detection scope, achieving an optimal balance between speed and accuracy.

[0040] S4. Input the Web request data parsed in step S2 into the vulnerability detection big model obtained through micro-training. Use the vulnerability detection big model to perform potential vulnerability detection on the request method, request URL path, request header, request parameters and request name. If a potential vulnerability is detected, output the vulnerability type and location. If no vulnerability is detected, output "not found" and end the detection.

[0041] Structured web request data is input into a micro-trained large model, which can output not only whether vulnerabilities exist, but also the type and specific location of the vulnerabilities. This makes the detection results interpretable, allowing security personnel to quickly locate problems and shorten investigation time.

[0042] S5. Based on the web request data parsed and extracted in step S2 and the vulnerability types and specific locations of the vulnerabilities in the web request data detected in step four, the large model generates a corresponding POC verification script using its semantic and programming capabilities, and automatically executes the verification script. Based on the return results of the verification script execution, the large model further analyzes and determines whether the POC verification script executed successfully. If successful, the request method, URL path, parameter names, and the corresponding POC verification script are stored in the vulnerability database, and a corresponding vulnerability warning is generated. If execution fails, it further determines whether the generation and execution of the POC verification script have reached a pre-set threshold. If so, the current detection ends; otherwise, step five continues until the POC verification script executes successfully or the pre-set threshold is reached.

[0043] The POC verification script is generated based on the semantic understanding and programming capabilities of the large model. The execution result of the POC verification script is used to update the vulnerability database, thereby realizing the automatic accumulation and expansion of vulnerability samples.

[0044] The generation and execution of POC verification scripts are not only used for vulnerability confirmation, but also write back the successfully verified POCs and their corresponding request contexts to the training set in the form of "script-sample pairs". This forms a closed loop of model inference, POC verification and training data update, enabling the large vulnerability detection model to have self-iterative optimization capabilities.

[0045] The process of obtaining the large vulnerability detection model includes:

[0046] The web traffic data from various systems and web traffic data containing various types of vulnerabilities are acquired, and these web traffic data are classified to form normal web traffic samples and web traffic samples with various types of vulnerabilities. These classified web traffic samples are then labeled.

[0047] The labeled samples are preprocessed to extract the request method, request URL path, request header, request parameters and request name from the web traffic data, and combined with the annotation results to form a data format adapted to the LLaMA-Factory micro-training framework.

[0048] Using the open-source deepseek-R1 model as a base model, the parameters of the pre-trained model were adjusted, and the LLaMA-Factory framework was used for fine-tuning the model training. After training with preprocessed web traffic samples, the resulting vulnerability detection model possesses the ability to detect and infer potential web vulnerabilities. Figure 5 The diagram shows the output results of the micro-training of the large-scale vulnerability detection model.

[0049] The training samples for the vulnerability detection model adopt an instruction-driven structured format, including: [instruction field, input field, output field].

[0050] The instruction field is used to describe Figure 4 The task is a natural language task with instructions such as “Analyze the potential vulnerabilities in the following HTTP requests”. The input fields include structural elements such as request method, request URL path, request headers, request parameters, and request name. The output fields are labeled with vulnerability detection results in the form of two labels, where the first label is the vulnerability type and the second label is the specific injection point or field location where the vulnerability is located.

[0051] like Figure 3 The sample example shown contains a vulnerability. The output indicates that the vulnerability type is command injection and provides the specific injection point (dir: " / bin / ", args: ...). Therefore, Figure 3 The image shown is a sample with location labels. For example... Figure 4 The normal sample shown in the output is marked with "vulnerability_type": "not found" and the injection point is "", indicating that this is a sample explicitly marked as vulnerability-free. Therefore, this method is not a simple binary classification, but rather a label with both classification and location information.

[0052] In summary, this method achieves configuration-free detection by collecting real traffic in a bypass manner in real time. It first uses a vulnerability database to quickly filter known vulnerabilities, then fine-tunes a large model to deeply analyze unknown threats, and combines automatic POC verification and self-learning mechanisms to build a comprehensive, efficient and intelligent closed-loop security detection system.

[0053] The following is for reference. Figure 6 It shows a schematic diagram of the structure of a computer system 600 suitable for implementing electronic devices according to embodiments of the present application. Figure 6 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0054] like Figure 6 As shown, the computer system 600 includes a central processing unit (CPU) 601, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 602 or programs loaded from storage section 608 into random access memory (RAM) 603. The RAM 603 also stores various programs and data required for the operation of the system 600. The CPU 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0055] The following components are connected to I / O interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a liquid crystal display (LCD) and speakers, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card and a modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to I / O interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 610 as needed so that computer programs read from it can be installed into storage section 608 as needed.

[0056] Specifically, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable storage medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 609, and / or installed from removable medium 611. When the computer program is executed by central processing unit (CPU) 601, it performs the functions defined in the methods of this application. It should be noted that the computer-readable storage medium of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. The computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can also be any computer-readable storage medium other than a computer-readable storage medium that can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. Program code contained on a computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0057] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages—such as Java, Smalltalk, and C++—as well as conventional procedural programming languages—such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0058] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0059] The modules described in the embodiments of this application can be implemented in software or in hardware.

[0060] On the other hand, this application also provides a computer-readable storage medium, which may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into the electronic device. The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by the electronic device, the electronic device causes the following: to collect bypass traffic of the network device in real time, identify and classify the traffic using a feature code matching method to obtain Web traffic data; to parse the Web traffic data, extracting the request method, request URL path, request header, request parameters, and request name; to search for the existence of corresponding vulnerabilities in a vulnerability database based on the request method, request URL path, and parameter name; if a vulnerability exists, output a vulnerability warning message and end the detection; if not, proceed to the next step; and to input the parsed Web request data into a micro-training process. The vulnerability detection model is used to perform potential vulnerability detection on the request method, request URL path, request headers, request parameters, and request name. If a potential vulnerability is detected, the vulnerability type and location are output; if no vulnerability is detected, "not found" is output and the detection ends. The vulnerability detection model is used to generate a corresponding Proof-of-Concept (POC) verification script and execute it. The execution result determines whether the POC verification is successful. If successful, the request method, request URL path, request headers, request parameters, request name, and corresponding POC verification script are stored in the vulnerability database and a vulnerability warning is output. If unsuccessful, a preset threshold is used to determine whether to continue executing the POC verification until success or the threshold is reached.

[0061] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A method for automated web vulnerability detection and verification based on a large model, characterized in that, include: S1. Real-time collection of bypass traffic from network devices, identification and classification of traffic using signature matching method to obtain Web traffic data; S2. Parse the Web traffic data and extract the request method, request URL path, request header, request parameters and request name; S3. Based on the request method, request URL path, and parameter name, search the vulnerability database for a corresponding vulnerability; if it exists, output a vulnerability warning and end the detection; if it does not exist, proceed to the next step. S4. Input the Web request data parsed in step S2 into the vulnerability detection big model obtained through micro-training. Use the vulnerability detection big model to perform potential vulnerability detection on the request method, request URL path, request header, request parameters and request name. If a potential vulnerability is detected, output the vulnerability type and location. If no vulnerability is detected, output "not found" and end the detection. S5. Based on the Web request data parsed in step S2 and the detection results in step S4, generate the corresponding POC verification script using the vulnerability detection big model and execute it. Determine whether the POC verification is successful based on the execution result. If successful, store the request method, request URL path, request header, request parameters, request name and the corresponding POC verification script in the vulnerability database and output vulnerability warning information. If unsuccessful, determine whether to continue executing the POC verification until successful or the threshold is reached based on a preset threshold.

2. The method according to claim 1, characterized in that, The collection of bypass traffic includes collecting mirrored traffic and dynamically generating a unique session identifier for each session at the collection end, maintaining the correspondence with the subsequent POC verification results, and forming a backtracking training sample link.

3. The method according to claim 1, characterized in that, In the identification and classification process, the TLS / QUIC fingerprint information of the encrypted traffic is written into the training samples along with the parsed HTTP fields, and used as an auxiliary feature vector input to the vulnerability detection model during micro-training.

4. The method according to claim 1, characterized in that, The process of obtaining the large vulnerability detection model includes: Obtain normal web traffic samples and web traffic samples containing various vulnerabilities, and annotate them to obtain labeled samples; The labeled samples are preprocessed to extract the request method, request URL path, request header, request parameters and request name, and combined with the annotation results to form a data format adapted to the LLaMA-Factory micro-training framework. Using the open-source deepseek-R1 model as the base model, and fine-tuning the training with the preprocessed samples, a large vulnerability detection model with Web vulnerability detection and inference capabilities is obtained.

5. The method according to claim 1 or 4, characterized in that, The POC verification script is generated based on the semantic understanding and programming capabilities of the large model. The execution result of the POC verification script is used to update the vulnerability database, thereby realizing the automatic accumulation and expansion of vulnerability samples.

6. The method according to claim 1, characterized in that, The training samples of the vulnerability detection model adopt an instruction-driven structured format, including: [instruction field, input field, output field].

7. The method according to claim 1, characterized in that, The instruction field includes natural language task instructions; the input field includes request method, request URL path, request header, request parameters and request name; the output field labels the vulnerability detection results in the form of double labels, wherein the first label is the vulnerability type and the second label is the specific injection point or field location where the vulnerability is located.

8. A computer program product, characterized in that, It stores a computer program that, when executed by a processor, implements the method as described in any one of claims 1-7.

9. A computing system, characterized in that, It includes a processor and a memory, the processor being configured to perform the method as described in any one of claims 1-7.

Images