A security crowd test vulnerability intelligent disposal method and system based on multi-agent cooperation

Abstract

The application provides a security crowd test vulnerability intelligent disposal method and system based on multi-agent cooperation, comprising: acquiring a multi-modal vulnerability report for a target asset; calling an analysis agent to structurally analyze the multi-modal vulnerability report to obtain a structured vulnerability report; calling a false alarm filtering agent to screen out effective vulnerability reports by filtering the structured vulnerability report; calling an automatic reproduction agent to execute automatic reproduction verification on the effective vulnerability report in a dynamic isolated sandbox environment to generate a reproduction result containing an evidence chain; and calling a grading agent to grade the reproduction result according to vulnerability risks and output a risk level and grading basis. The application decouples the whole process of vulnerability disposal into special links such as analysis, filtering, reproduction and grading through a multi-agent cooperative pipeline architecture, so that the disposal efficiency is much higher than that of general artificial workers, and end-to-end automatic disposal is realized.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and more specifically, to a method and system for intelligent handling of security crowdsourcing vulnerabilities based on multi-agent collaboration. Background Technology

[0002] As modern software system architectures become increasingly complex, distributed, and microservice-oriented, the network attack surface continues to expand. Crowdsourced Security Testing (CST), a model that discovers system security vulnerabilities by publicly recruiting security testers, has become an important means of building a proactive defense system.

[0003] However, with the explosive growth of the security crowdsourcing industry, the contradiction between the influx of massive vulnerability reports and the traditional manual review model has become increasingly prominent, becoming a core bottleneck restricting platform efficiency.

[0004] The vulnerability handling process of existing crowdsourcing testing platforms is still mainly manual, which has fundamental deficiencies in terms of efficiency, accuracy and standardization. Summary of the Invention

[0005] In view of this, the purpose of this invention is to provide a method and system for intelligent handling of security crowdsourcing vulnerabilities based on multi-agent collaboration, so as to realize intelligent processing of vulnerability data throughout the entire process and improve the efficiency of vulnerability report handling.

[0006] Firstly, a method for intelligent handling of security crowdsourcing vulnerabilities based on multi-agent collaboration is provided, including: Obtain multimodal vulnerability reports targeting the asset; The parsing agent is invoked to perform structured parsing on the multimodal vulnerability report, resulting in a structured vulnerability report. The false alarm filtering agent is invoked to screen structured vulnerability reports for false alarms in order to filter out valid vulnerability reports; The automatic reproduction agent is invoked to perform automated reproduction verification on valid vulnerability reports in a dynamic isolated sandbox environment, generating reproduction results containing a chain of evidence; The hierarchical intelligent agent is invoked to classify the vulnerability risk of the reproduced results and output the risk level and the basis for classification.

[0007] Optionally, the multimodal vulnerability report can be parsed in a structured manner to obtain a structured vulnerability report, including: Extract text information and network protocol data from multimodal vulnerability reports; The extracted text information and parsed network protocol data are concatenated into a complete context and input into a pre-trained large language model; Using a large language model, multiple fields of the complete context are extracted according to preset specifications. These fields include at least the vulnerability type, target asset address, attack payload, reproduction steps, and scope of impact. Verify the logical consistency of each field, and convert the fields that pass the verification into a preset unified format, outputting a structured vulnerability report.

[0008] Optionally, false positive screening can be performed on structured vulnerability reports to filter out valid vulnerability reports, including: The structured vulnerability reports are matched with a historical false alarm sample library to determine the historical false alarm similarity score; The logical rationality of structured vulnerability reports is verified by using a large language model to determine the semantic and logical rationality score. Compare the configuration information of the test environment and the production environment of the target asset to determine the environment consistency score; The false alarm probability is obtained by weighting and fusing the historical false alarm similarity score, semantic logic rationality score, and environmental consistency score based on preset weights. If the false positive probability is less than the preset threshold, the structured vulnerability report is determined to be a valid vulnerability report.

[0009] Optionally, the structured vulnerability report can be matched against a historical false positive sample database to determine a historical false positive similarity score, including: Extract vulnerability type, target access path, involved parameter name, and payload keywords from structured vulnerability reports as core features; count the number of core features that successfully match in the historical false alarm sample library; determine the historical false alarm similarity score based on the ratio of the number of core features to the total number of core features; The logical rationality of structured vulnerability reports is verified using a large language model, and the semantic logical rationality score is determined, including: Input the structured vulnerability report into the large language model; verify the clarity of the reproduction steps, the matching degree between the vulnerability description and the payload, and the logical contradictions; determine the semantic logic rationality score based on the ratio of the number of verified items to the total number of verified items; The environment consistency score is determined by comparing the configuration information of the test environment and the production environment of the target asset, including: The test environment and production environment of the target asset are compared item by item to check the consistency of domain name and port, interface existence and user permission. The environment consistency score is determined based on the ratio of the number of consistent dimensions to the total number of dimensions compared.

[0010] Optionally, in a dynamic isolation sandbox environment, automated reproduction verification is performed on valid vulnerability reports, generating reproduction results containing a chain of evidence, including: Based on the vulnerability type field in the structured vulnerability report, vulnerabilities are classified into standardized vulnerabilities or complex business vulnerabilities. Since the vulnerability type is a standardized vulnerability, a fully automated reproduction strategy is adopted, which automatically generates test scripts and calls dedicated security tools to execute vulnerability reproduction tasks in a dynamic isolated sandbox environment; In response to the fact that the vulnerability type is a complex business vulnerability, a semi-automated reproduction strategy is adopted. The business logic is reasoned based on a large language model and multi-step interactive test cases are constructed. The vulnerability reproduction task is executed in a dynamic isolated sandbox environment based on the multi-step interactive test cases. During the vulnerability reproduction task, the system automatically collects full traffic data, screen recording data, and screenshots of key nodes, and generates a reproduction result containing a chain of evidence by associating the vulnerability number with it.

[0011] Optional, the construction and management of a dynamically isolated sandbox environment includes: Containerization technology is used to allocate an independent container instance for each vulnerability reproduction task, building a strong isolation architecture of single task and single instance; Automatically configure the operating system, browser, and dependency libraries of the container instance based on the technology stack of the target asset; Enable sandbox network management to limit the network access range, traffic rate, and number of connections of container instances, and block port scanning and lateral movement operations; After the vulnerability reproduction task is completed, the corresponding container instance is automatically destroyed to release computing and storage resources.

[0012] Optionally, the vulnerability risk of the reproduced results can be assessed, including: Technical indicators of the reproduction results are extracted according to the general vulnerability scoring system standard; and the basic technical score of the vulnerability is calculated based on the technical indicators. Obtain the business environment factors of the target assets; Based on the preset security policy weights, the risk score of the vulnerability's basic technical score and the business environment factor are weighted and averaged to obtain the risk score of the reproduction result. The risk score is mapped to a preset risk level range to determine the risk level of the vulnerability.

[0013] Optionally, the method also includes: Multiple generic remediation templates are matched based on the vulnerability type of the target asset; Extract the technical stack features of the target asset, calculate the fit between the technical stack features and multiple general repair templates, and select the optimal repair template with the highest fit. By tailoring and adapting the code to fit the optimal repair template execution scenario using a large language model, a customized repair solution can be generated. The customized remediation solution undergoes a two-dimensional verification of integrity and security. Once the verification is successful, a standardized remediation document is output, which includes the cause of the problem, remediation steps, code repair examples, retesting methods, and security hardening suggestions.

[0014] Secondly, a security crowdsourcing vulnerability intelligent handling system based on multi-agent collaboration is provided, including: The parsing agent is used to obtain multimodal vulnerability reports targeting the asset; and performs structured parsing on the multimodal vulnerability reports to obtain structured vulnerability reports. A false alarm filtering agent is used to screen structured vulnerability reports for false alarms in order to filter out valid vulnerability reports; An automated reproduction agent is used to perform automated reproduction verification of valid vulnerability reports in a dynamic isolated sandbox environment, generating reproduction results containing a chain of evidence. The hierarchical intelligent agent is used to classify the vulnerability risk of the reproduced results and output the risk level and the basis for classification.

[0015] Optionally, the system also includes; Repair agents are used to generate customized remediation solutions based on risk level and vulnerability context.

[0016] This invention provides a method and system for intelligent handling of security crowdsourcing vulnerabilities based on multi-agent collaboration. The method involves: acquiring multimodal vulnerability reports targeting a specific asset; calling a parsing agent to perform structured parsing of the multimodal vulnerability reports to obtain structured vulnerability reports; calling a false positive filtering agent to screen the structured vulnerability reports for false positives, thus filtering out valid vulnerability reports; calling an automatic reproduction agent to perform automated reproduction verification of valid vulnerability reports in a dynamic isolation sandbox environment, generating reproduction results containing evidence chains; and calling a grading agent to classify the vulnerability risk of the reproduction results, outputting the risk level and the basis for the classification. This application, through a multi-agent collaborative pipeline architecture, decouples the entire vulnerability handling process into dedicated stages such as parsing, filtering, reproduction, and grading. The agents are seamlessly connected through a unified message bus, eliminating manual waiting and handover costs, supporting both serial pipeline and parallel processing. The efficiency of vulnerability report handling is far higher than that of general manual processing, achieving end-to-end automated handling.

[0017] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1This diagram illustrates the layered architecture of the intelligent vulnerability handling system for crowdsourced security testing based on multi-agent collaboration provided in an embodiment of the present invention. Figure 2 The flowchart illustrates a method for intelligent handling of security crowdsourcing vulnerabilities based on multi-agent collaboration provided by an embodiment of the present invention. Figure 3 A schematic diagram of the parsing intelligent agent processing flow provided in an embodiment of the present invention is shown; Figure 4 A schematic diagram of the false alarm filtering agent processing flow provided in an embodiment of the present invention is shown; Figure 5 This diagram illustrates the automatic reproduction agent processing flow provided in an embodiment of the present invention. Figure 6 A schematic diagram of the hierarchical intelligent agent processing flow provided in an embodiment of the present invention is shown; Figure 7 This diagram illustrates the intelligent agent processing flow for repair suggestions provided in an embodiment of the present invention. Figure 8 A schematic diagram of the multi-agent collaborative workflow provided by an embodiment of the present invention is shown. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0021] like Figure 1 As shown, this embodiment of the invention provides a security crowdsourcing vulnerability intelligent handling system based on multi-agent collaboration. The system architecture includes a user interaction layer, a multi-agent collaboration layer, and an infrastructure layer. The user interaction layer is designed for three types of users: white hat submission, enterprise management, and platform management. The white hat submission is used by security testers to submit vulnerability reports, while the enterprise management reviews the vulnerability reports submitted by the white hat submission. The platform management is used to manage the white hat submission and enterprise management.

[0022] The multi-agent collaboration layer is the core business processing layer, in which five functional agents work together in sequence to complete the entire process of vulnerability processing, and the task flow and parameter adaptation of each agent are uniformly managed by the global agent scheduler. Specifically, the five functional intelligent agents include: The parsing agent is used to obtain multimodal vulnerability reports targeting the asset; and performs structured parsing on the multimodal vulnerability reports to obtain structured vulnerability reports. A false alarm filtering agent is used to screen structured vulnerability reports for false alarms in order to filter out valid vulnerability reports; An automated reproduction agent is used to perform automated reproduction verification of valid vulnerability reports in a dynamic isolated sandbox environment, generating reproduction results containing a chain of evidence. The hierarchical intelligent agent is used to classify the vulnerability risk of the reproduced results and output the risk level and the basis for classification.

[0023] Repair agents are used to generate customized remediation solutions based on risk level and vulnerability context.

[0024] The infrastructure layer includes a dynamic sandbox cluster, a security tool integration module, a vulnerability fingerprint database, and a data storage system. It provides underlying support for upper-layer intelligent agents to isolate testing environments, invoke security tools, compare vulnerability fingerprints, and persist data. Each layer is linked to the next to achieve automated and intelligent processing of security crowdsourcing vulnerabilities.

[0025] Specifically, 1. The dynamic sandbox cluster is the core execution environment for automatic vulnerability reproduction, providing a secure, isolated, and customizable test and execution space for the automatic reproduction agent, fundamentally solving the security threat to the production environment posed by the vulnerability verification process.

[0026] It uses Docker containerization technology to build a strongly isolated architecture of "single task, single container". Each vulnerability reproduction task is assigned an independent lightweight container instance, and the container is automatically destroyed after the task is completed, so as to achieve complete isolation and clean reset of the environment.

[0027] It features a built-in multi-operating system and multi-browser simulation environment, supports mainstream network protocols such as HTTP, HTTPS, and WebSocket, and has fine-grained network behavior control capabilities. It can limit the network access range, traffic rate, and number of connections of containers, automatically block high-risk operations such as port scanning and lateral movement, and also supports automatically installing corresponding dependency packages and configuring running parameters according to the target system's technology stack to maximize the consistency between the reproduction environment and the production environment. It also communicates with the automatic reproduction agent in real time, receives test scripts and execution instructions, and synchronously returns execution status, system logs, and running results.

[0028] 2. The security tool integration module is a unified scheduling hub connecting upper-layer intelligent agents and various security tools, solving the problem of traditional tools being discrete, independent, and unable to coordinate and link, and realizing standardized calling of security tools and unified parsing of results.

[0029] It has built a unified and standardized API gateway, which encapsulates the calling interfaces of mainstream security tools such as Burp Suite Professional, SQLMap, and Nmap, providing a consistent calling method and data format. At the same time, it has established a tool capability map, recording the applicable vulnerability types, detection capabilities, running parameters, and output formats of various tools. It supports automatically matching the optimal verification tool according to the vulnerability type and can automatically complete the entire process of tool calling, parameter passing, and result parsing without manual intervention.

[0030] It also provides an open extension interface, supporting enterprises to access internal dedicated security tools and custom detection scripts, adapting to the personalized needs of different enterprises, and can automatically convert the unstructured output results of various tools into standardized JSON data that the system can recognize, providing data support for subsequent hierarchical intelligent agents and remediation suggestion intelligent agents.

[0031] 3. The vulnerability fingerprint database is the core data infrastructure for enabling rapid vulnerability deduplication and reuse of verification results, which greatly improves system processing efficiency and avoids resource waste caused by repeated verification.

[0032] It stores standardized fingerprint data of hundreds of thousands of real verified vulnerabilities, covering core information such as vulnerability type, target URL characteristics, parameter characteristics, payload characteristics, impact scope, verification results, and risk level. It adopts a fingerprint matching algorithm that combines fuzzy hashing and feature vectors, supports exact matching and similarity matching, and can identify different manifestations and variants of the same vulnerability.

[0033] It works in real time with the analytical agent. After a new vulnerability report is parsed, fingerprint comparison is automatically triggered. If a match is successful, historical verification results and hierarchical data are returned directly without having to repeat the reproduction process. It also supports dynamic updates of the fingerprint database. After each new vulnerability is verified, fingerprint features are automatically extracted and added to the database to continuously expand the coverage of the fingerprint database. A fingerprint database version management mechanism is also established to support historical version backtracking and data auditing, ensuring the accuracy and traceability of fingerprint data.

[0034] 4. The data storage system is the unified data center of this invention, responsible for the persistent storage, management and access of data throughout the entire process, while supporting the system's self-learning and self-iteration capabilities.

[0035] It adopts a distributed hybrid storage architecture, storing structured data in a relational database, unstructured data in an object storage system, and log data in a time-series database, uniformly storing all data throughout the process, including original vulnerability reports, structured parsing results, false alarm filtering data, evidence chains for reproduction, graded results, remediation plans, and manual review records.

[0036] It provides a unified data access interface, supports concurrent data read and write requests from various agents, ensures data consistency and access efficiency, and implements a full-process data feedback mechanism to feed back manual review results, anomaly handling data, vulnerability repair verification data, etc. to the model training module. It also supports data anonymization and access control, strictly protects sensitive corporate data and white-hat personal information, complies with the requirements of the Data Security Law and the Personal Information Protection Law, provides data support for system self-iteration, and continuously optimizes the semantic understanding ability of parsing agents, the recognition accuracy of false alarm filtering agents, and the classification accuracy of hierarchical agents.

[0037] like Figure 2 As shown in the figure, this embodiment of the invention provides a method for intelligent handling of security crowdsourcing vulnerabilities based on multi-agent collaboration, including the following steps: Step S201: Obtain a multimodal vulnerability report for the target asset.

[0038] In this embodiment, a multimodal vulnerability report refers to the original detection record submitted by security testers for a target asset, which contains multiple data formats.

[0039] Due to differences in submission habits among testers, these reports are often highly unstructured. For example, a typical multimodal vulnerability report may simultaneously include vulnerability details described in natural language, screenshots or screen recordings demonstrating the attack's effects, HTTP request and response packets used to prove the vulnerability's existence, and exploit scripts to aid in verification.

[0040] Step S202: Call the parsing agent to perform structured parsing on the multimodal vulnerability report to obtain a structured vulnerability report.

[0041] A parsing agent transforms acquired unstructured, heterogeneous data into a standard format that is understandable and computable by machines. For example, it converts the data into a common data exchange format like JSON, which contains all the key fields needed for subsequent steps.

[0042] After receiving a structured vulnerability report, it is first matched against historical vulnerability fingerprints in a pre-set vulnerability fingerprint database. If the match is successful, the historical verification results and classification data are returned directly without having to repeat the reproduction process. If the match fails, subsequent processes such as false alarm filtering are performed through a false alarm filtering agent.

[0043] Step S203: Call the false alarm filtering agent to screen the structured vulnerability reports for false alarms, so as to filter out the valid vulnerability reports.

[0044] In security crowdsourcing scenarios, submitted vulnerability reports often contain a large amount of invalid data due to scanner false positives. This step effectively avoids invalid data consuming subsequent expensive reproduction computing resources and manual review effort, significantly improving the signal-to-noise ratio and operational efficiency of the overall processing pipeline.

[0045] Step S204: Invoke the automatic reproduction agent to perform automated reproduction verification on the valid vulnerability report in the dynamic isolation sandbox environment, and generate a reproduction result containing the evidence chain.

[0046] The automated reproduction agent is the core execution unit for verifying the authenticity of vulnerabilities. The dynamic isolation sandbox environment provides a completely isolated and controlled testing space from the production environment, ensuring that attack traffic and malicious operations during the vulnerability verification process do not affect the actual business systems.

[0047] Step S205: Call the hierarchical intelligent agent to classify the vulnerability risk of the reproduction results, and output the risk level and the basis for classification.

[0048] The hierarchical intelligent agent calculates risk scores using a quantitative model and maps them to preset risk levels (such as high-risk, medium-risk, low-risk, and information-level). More importantly, while outputting the risk level, the hierarchical intelligent agent also generates detailed classification criteria, clearly demonstrating the contribution of each assessment factor to the final level.

[0049] This design overcomes the shortcomings of traditional manual risk classification, which is highly subjective and lacks clear standards. It ensures the objectivity, consistency, and interpretability of risk classification results, providing a scientific basis for enterprise security teams to prioritize remediation efforts.

[0050] The various intelligent agents are seamlessly connected through standardized data interfaces. The output of the previous stage becomes the input of the next stage, and the entire process from the initial report to the final risk assessment can be completed without human intervention.

[0051] This application adopts a multi-agent collaborative pipeline architecture to decouple the entire vulnerability handling process into dedicated stages such as parsing, filtering, reproduction, and classification. The agents are seamlessly connected through a unified message bus, eliminating human waiting and handover costs. It supports both serial pipeline and parallel processing, and the processing efficiency of vulnerability reports is far higher than that of general manual processing, achieving end-to-end automated handling.

[0052] White-hat hackers submit reports in various formats, including unstructured data such as natural language descriptions, images, videos, and raw HTTP requests. Current technologies lack automated multimodal parsing capabilities, requiring reviewers to manually read each line and extract key features (such as target URLs and payloads). This process is not only extremely time-consuming but also prone to human error, leading to the omission of crucial information or incorrect extraction. Consequently, it fails to standardize and machine-readable vulnerability information.

[0053] Therefore, in the above embodiments, the multimodal vulnerability report is subjected to structured parsing to obtain a structured vulnerability report, including: Step S202A: Extract text information and network protocol data from the multimodal vulnerability report.

[0054] In this step, text information undergoes word segmentation, noise reduction, and format standardization preprocessing; for screenshots or screen recording keyframes in image format, an optical character recognition engine is called to extract the text content and retain the coordinate position of the text in the image and its contextual relationship with surrounding elements; for network protocol data, a protocol parser separates structured elements such as request method, Uniform Resource Locator, request header, request body, response header, and response body from the HTTP data packet.

[0055] It should be understood that the above extraction method is only an example. In practical applications, a keyframe sampling strategy can also be used for video streams, such as extracting a frame every two seconds for recognition, in order to reduce computational overhead while ensuring the integrity of information.

[0056] Step S202B: Concatenate the extracted text information and parsed network protocol data into a complete context and input it into the pre-trained large language model.

[0057] For example, when a screenshot shows a database error message, and the HTTP response data packet happens to contain the corresponding 500 status code and exception stack trace, these two pieces of information will be explicitly associated in the context, enabling the large language model to comprehensively judge the cause of the error like a human expert.

[0058] This cross-modal context construction mechanism effectively solves the problem of comprehension bias caused by insufficient information in a single modality.

[0059] Step S202C: Using a large language model, extract multiple fields of the complete context according to preset specifications.

[0060] This large language model, fine-tuned with security domain knowledge, possesses a deep understanding of vulnerability-related semantics. At the input end, prompts containing predefined patterns are typically constructed to guide the model in extracting information according to predetermined specifications.

[0061] The fields defined in the default specification should include at least the vulnerability type, target asset address, attack payload, reproduction steps, and scope of impact.

[0062] Among them, the vulnerability type is used to identify the technical classification of security risks, such as SQL injection, cross-site scripting attacks, or unauthorized access; the target asset address clarifies the affected system boundary; the attack payload records the specific malicious input that triggers the vulnerability; the reproduction steps provide the operation sequence to verify the existence of the vulnerability; and the scope of impact defines the degree of harm that the vulnerability may cause.

[0063] In addition to the necessary fields mentioned above, the preset specifications can also be expanded to include auxiliary fields such as vulnerability title, risk level estimate, and remediation suggestion summary, depending on actual business needs. This application does not impose strict limitations on these fields.

[0064] Step S202D: Verify the logical consistency of each field, and convert the fields that pass the verification into a preset unified format, outputting a structured vulnerability report.

[0065] Specific verification rules include, but are not limited to: checking whether required fields are missing; verifying the logical consistency between fields, such as whether the vulnerability type matches the attack payload. For example, if the extracted vulnerability type is SQL injection, but the attack payload only contains HTML tags without any database query statements, it is determined to be logically inconsistent; verifying whether the description of the reproduction steps matches the actual operations in the data packet. Only fields that pass the logical consistency verification will be converted to a preset unified format.

[0066] This pre-defined unified format typically uses machine-readable data exchange formats such as JSON, enabling subsequent false alarm filtering agents and automatic reproduction agents to directly read and process the data, thus completely opening up the data path from unstructured manual reports to fully automated machine processing.

[0067] Through the aforementioned multimodal structured parsing mechanism, this embodiment ensures the accuracy and usability of the output data by performing logical consistency checks. This corrects potential illusions or extraction errors that may arise from the model.

[0068] Due to differences in testing environment configurations, limitations of the scanner itself, or misunderstandings by white-hat hackers, submitted reports often contain a large number of false positives. Traditional false positive filtering uses rule matching, which can only rely on keywords to complete a shallow screening. It cannot understand the semantics of the report or identify environmental differences, resulting in a large number of false positives from the scanner, false positives due to environmental differences, and logically contradictory reports being retained, leading to a high overall false positive rate.

[0069] To more clearly explain the working principle of analytical agents, Figure 3 The process of parsing the intelligent agent is shown: 1. Input and Splitting: The system receives vulnerability reports in various formats, including text, images, data packets, and videos.

[0070] First, multimodal data is split, and the hybrid report is decomposed into four independent data streams for processing: Text content: Proceed directly to the text preprocessing stage.

[0071] Images / screenshots: Extract text information from images using OCR (Optical Character Recognition) technology.

[0072] Data packet file: Perform professional data packet parsing to extract key structural information such as HTTP request headers, parameters, and payload.

[0073] Video / Screen Recording: By extracting key frames and using OCR, key operation steps are captured from the video and converted into text descriptions.

[0074] 2. Fusion and Extraction: Large Language Model Semantic Fusion Analysis: By combining the processed text, OCR results, and parsed data, and leveraging the understanding capabilities of the large language model, the true meaning of the vulnerability can be understood by integrating the contextual semantics.

[0075] Structured field extraction and mapping: Based on the preset schema, key fields such as target URL, vulnerability type, and payload are accurately extracted from the fused semantic information and mapped to the standard structure.

[0076] 3. Verification and Output: Field integrity and consistency verification: Check whether the extracted key fields are missing, and whether the information from different sources (such as text descriptions and URLs in data packets) are consistent.

[0077] If the validation passes: Directly output standardized JSON data for subsequent use by the intelligent agent.

[0078] If the validation fails: mark the missing field and prompt the user to supplement it to ensure the accuracy of the data.

[0079] Therefore, based on the above embodiments, false positive screening is performed on structured vulnerability reports to filter out valid vulnerability reports, including: Step S203A: Match the structured vulnerability report with the historical false alarm sample library to determine the historical false alarm similarity score.

[0080] Historical false positive similarity score represents the reuse of experience over time. Its physical meaning is to measure the degree of overlap between the current report and known invalid samples. It is mainly used to quickly intercept feature-fixed false positives generated in batches by automated scanners, as well as historical vulnerabilities that have been disproven and repeatedly submitted by white hats.

[0081] In one feasible implementation, structured vulnerability reports are matched against a historical false positive sample database to determine a historical false positive similarity score, including: Extract vulnerability type, target access path, involved parameter name, and payload keywords from structured vulnerability reports as core features; count the number of core features that successfully match in the historical false alarm sample library; determine the historical false alarm similarity score based on the ratio of the number of features to the total number of core features.

[0082] For example, when a structured vulnerability report is sent into the detection process, it is first parsed to determine that the vulnerability type is SQL injection, the target access path is / api / user / login, the parameter name involved is username, and the payload keyword is 'OR'1'='1'.

[0083] The historical false alarm sample database is searched to see if any records possess all four characteristics. If the search results show that only the vulnerability type, target access path, and payload keywords match successfully, while the parameter names do not match, then the number of successfully matched features is 3, and the total number of core features is 4. In this case, the ratio, three-quarters (0.75), is determined as the historical false alarm similarity score S1. The value of S1 ranges from [0,1]. The larger the value, the more similar it is to historical false alarms, and the higher the probability of a false alarm.

[0084] This ratio-based calculation method avoids the rigidity problem caused by absolute numerical matching. Even if some features are mutated (such as parameter name changes), as long as the main features are still highly similar to known false alarms, the system can still give a high false alarm warning score, thereby effectively intercepting false alarms from various variant scanners.

[0085] Step S203B: Perform logical rationality verification on the structured vulnerability report using a large language model to determine the semantic logical rationality score.

[0086] The semantic logic rationality score represents the inherent self-consistency of the content dimension. Its physical meaning is whether the description in the assessment report is technically sound, such as whether the reproduction steps are clear and executable, whether the attack payload and vulnerability type match, and whether there are contradictions in the descriptions. This dimension utilizes the deep semantic understanding capabilities of the large language model to make up for the shortcomings of traditional regular expressions in identifying logical errors.

[0087] In one feasible implementation, the logical rationality of structured vulnerability reports is verified using a large language model, and the semantic logical rationality score is determined, including: The structured vulnerability report is input into the large language model; the clarity of the reproduction steps, the matching degree between the vulnerability description and the payload, and the logical contradictions are verified; the semantic logic rationality score is determined based on the ratio of the number of verified items to the total number of verified items.

[0088] Clarity of reproduction steps refers to whether the report provides a complete verification process that includes a specific sequence of operations, a request construction method, and an expected response, rather than just giving vague descriptions such as "clicking a button will trigger it"; The vulnerability description and payload matching degree refers to whether the vulnerability principle declared in the report corresponds technically to the actual submitted attack payload. For example, if it is claimed to be a file upload vulnerability but the payload only contains XSS scripts, it will be judged as a mismatch. Logical contradictions refer to whether there are conflicts in the descriptions within and outside the report, such as a title indicating a high-risk RCE vulnerability but a description of the impact scope only stating information leakage.

[0089] In the specific calculation, the system treats the above three items as independent verification items and submits them to the large language model for judgment one by one. For example, if the model determines that the reproduction steps are clear and the description matches the payload, but finds a logical contradiction in the description, then the number of items that pass the verification is 2, and the total number of verification items is 3. Based on this, the system determines two-thirds (approximately 0.67) as the semantic logic reasonableness score S2.

[0090] The higher the S2 score, the more rigorous and credible the report is at the semantic level; conversely, a lower score suggests that there may be misunderstandings leading to an invalid report.

[0091] Step S203C: Compare the configuration information of the test environment and production environment of the target asset to determine the environment consistency score.

[0092] The environmental consistency score represents the objective authenticity in the spatial dimension. Its physical meaning is to quantify the degree of difference between the test environment and the production environment. It is used to identify false positive vulnerabilities caused by reasons such as asynchronous configuration, unavailable interfaces, or inconsistent permissions.

[0093] In one feasible implementation, the environment consistency score is determined by comparing the configuration information of the test environment and the production environment of the target asset, including: The test environment and production environment of the target asset are compared item by item to check the consistency of domain name and port, interface existence and user permission. The environment consistency score is determined based on the ratio of the number of consistent dimensions to the total number of dimensions compared.

[0094] The baseline configuration information of the production environment is obtained by reading the enterprise's configuration management database or asset ledger, and then compared in three dimensions with the test environment information recorded in the vulnerability report.

[0095] Among them, domain name and port consistency ensures the sameness of the test object and the production object at the network entry level; interface existence verification verifies whether the vulnerability trigger point is actually deployed in the real business system, preventing unrealistic vulnerabilities caused by abandoned interfaces left in the test environment; User permission consistency confirms that the test account has the same role and data access scope in both environments, eliminating false alarms of unauthorized access caused by asynchronous privilege escalation configurations.

[0096] For example, if the comparison results show that the domain name, port, and user permissions are consistent, but the target interface has been taken offline and removed from the production environment, then the number of dimensions that are consistent is 2, and the total number of dimensions compared is 3. The system calculates the environment consistency score S3 as two-thirds (approximately 0.67). The value of S3 ranges from [0,1]. The larger the value, the more consistent the environment is and the lower the possibility of false alarms.

[0097] Step S203D: Based on preset weights, the historical false alarm similarity score, semantic logic rationality score, and environmental consistency score are weighted and fused to obtain the false alarm probability.

[0098] Specifically, the three scores are weighted and combined to obtain the final false positive probability P:

[0099] Among these factors, semantic logical rationality has the highest weight (0.5), because reports of logical errors are necessarily false alarms; historical false alarm similarity has a weight of 0.3; and environmental consistency has a weight of 0.2. Enterprises can adjust the weight ratios according to their own business characteristics.

[0100] Step S203E: If the false positive probability is less than the preset threshold, the structured vulnerability report is determined to be a valid vulnerability report.

[0101] In this embodiment, the preset threshold is set to a first preset threshold and a second preset threshold, wherein the first preset threshold is greater than the second preset threshold.

[0102] When the false alarm probability is greater than or equal to the first preset threshold, the report is determined to be a high-probability false alarm, and is automatically marked as invalid and archived to the false alarm sample library without manual intervention, thereby maximizing the release of review manpower.

[0103] When the false alarm probability is between the second preset threshold and the first preset threshold, the report is determined to be a suspected false alarm. It is automatically labeled as pending review and pushed to the manual review queue for secondary confirmation by security experts. This avoids directly discarding potential true positive vulnerabilities and ensures that limited human resources are focused on the most controversial samples.

[0104] When the false alarm probability is less than the second preset threshold, the structured vulnerability report is determined to be a valid vulnerability report and is automatically transferred to the subsequent automatic reproduction agent to perform the verification task.

[0105] For example, P≥0.8: high probability false alarm, automatically marked as false alarm and archived, no manual review required; 0.5≤P<0.8: suspected false alarm, marked and given priority for manual review; P<0.5: valid report, automatically transferred to the automatic reproduction agent.

[0106] This tiered threshold determination mechanism achieves an optimal balance between false alarm removal accuracy and vulnerability detection rate while pursuing fully automated processing efficiency.

[0107] This embodiment constructs a three-tiered, progressive false alarm filtering mechanism: it quickly resolves common scanner false alarms by matching historical false alarm samples; it filters invalid reports with contradictory descriptions by relying on large-scale model semantic logic verification; and it identifies false positive vulnerabilities caused by inconsistent configurations through environmental difference detection. These three mechanisms complement each other, covering the vast majority of false alarm scenarios. This overcomes the fundamental deficiency of traditional technologies, which can only perform superficial screening, and can greatly reduce unnecessary human resource investment for enterprises.

[0108] To more clearly explain the working principle of the false alarm filtering agent, Figure 3 The process of the false alarm filtering agent parsing is shown: After receiving the standardized structured vulnerability data output by the parsing agent, the false positive filtering agent performs detection in a three-step progressive order: "historical feature matching → semantic logic verification → environmental difference detection". First, it quickly matches the historical false positive sample library to filter out known common scanner false positives; then, it verifies the logical rationality of the vulnerability report through a large language model to filter out invalid reports with logical contradictions; finally, it compares the configuration differences between the test environment and the production environment to identify false positive vulnerabilities caused by environmental inconsistencies.

[0109] After completing three independent tests, the agent weights and fuses the results to calculate a comprehensive false positive probability value between 0 and 1. Based on a preset threshold, vulnerability reports are categorized into three types: high-probability false positives, suspected false positives, and valid reports. High-probability false positives are automatically archived; suspected false positives are marked and given priority for manual review; and valid reports are automatically transferred to the automatic reproduction agent to perform subsequent verification processes.

[0110] Existing vulnerability reproduction relies entirely on manual processes, which are lengthy. For complex, non-standard vulnerabilities such as privilege escalation, business logic defects, and unauthorized access, current technologies lack automated reproduction capabilities, requiring manual steps to outline reproduction procedures, construct test requests, and verify business logic. The average reproduction cycle for common vulnerabilities exceeds 48 hours, while complex business vulnerabilities can take more than a week, leading to delays in the handling of high-risk vulnerabilities and posing serious security risks.

[0111] Therefore, based on the above embodiments, automated reproduction verification of valid vulnerability reports is performed in a dynamic isolation sandbox environment, generating reproduction results containing a chain of evidence, including: Step S204A: Based on the vulnerability type field in the structured vulnerability report, classify the vulnerability into a standardized vulnerability or a complex business vulnerability.

[0112] This field is extracted and standardized by the parsing agent. Based on the value of this field, the vulnerabilities to be verified are automatically classified into two main categories: standardized vulnerabilities and complex business vulnerabilities.

[0113] Standardized vulnerabilities refer to security flaws that have clear technical principles, fixed verification processes, and do not depend on specific business states, such as SQL injection, cross-site scripting attacks, weak passwords, and command execution. Complex business vulnerabilities refer to security flaws that can only be triggered by combining specific business processes, user permission status, or multi-step interactive operations, such as unauthorized access, payment logic bypass, and order status tampering.

[0114] Step S204B: In response to the fact that the vulnerability type is a standardized vulnerability, a fully automated reproduction strategy is adopted to automatically generate test scripts and call dedicated security tools to perform vulnerability reproduction tasks in a dynamic isolated sandbox environment.

[0115] In this approach, the automatic reproduction agent acts as both a script generator and a tool scheduler.

[0116] Specifically, the agent automatically generates executable POC test scripts or tool call instructions that conform to the syntax rules, based on the specific characteristics of the vulnerability (such as target URL, parameter name, payload type, etc.).

[0117] The agent integrates security tools through a pre-built tool library to match and invoke the most suitable dedicated security testing tools. For example, for SQL injection vulnerabilities, it automatically generates test payloads containing multiple injection variants and invokes database security testing tools such as SQLMap to perform the probe; for XSS vulnerabilities, it generates corresponding reflected or stored test scripts and invokes front-end security testing tools such as XSSer.

[0118] Throughout the entire process, from script generation to tool execution and result parsing, everything is done automatically by the machine without human intervention. This reduces the verification cycle for such vulnerabilities from hours to minutes, greatly improving the efficiency of handling batch vulnerabilities.

[0119] Step S204C: In response to the vulnerability type being a complex business vulnerability, a semi-automated reproduction strategy is adopted. Based on a large language model, business logic is reasoned and multi-step interactive test cases are constructed. Based on the multi-step interactive test cases, the vulnerability reproduction task is executed in a dynamic isolated sandbox environment.

[0120] Under this approach, the automatic reproduction agent no longer relies on fixed script templates, but instead uses the deep reasoning capabilities of large language models to dynamically construct the verification process.

[0121] Specifically, the intelligent agent first inputs the vulnerability description, reproduction steps, and related business background information into the large language model, guiding the model to reason about the business logic flow relationship and state transition conditions of the target system.

[0122] Based on the reasoning results, the agent autonomously constructs multi-step interactive test cases. These test cases simulate the operation sequence of a real user in the system, such as "login account A → create order → modify order amount → submit payment", etc.

[0123] During execution, the agent will also dynamically adjust subsequent operations based on the response results of each step. For example, when an abnormal error code is detected on the page, it will automatically try to switch accounts or modify parameters to explore boundary conditions. This dynamic feedback mechanism highly replicates the debugging thinking of security experts when manually reproducing the problem.

[0124] In this way, the bottleneck of traditional automation tools in verifying business logic vulnerabilities has been successfully overcome, enabling the automation or semi-automation of complex scenarios that originally could only rely on manual labor.

[0125] In one feasible implementation, the construction and management of a dynamically isolated sandbox environment includes: Step A: Use containerization technology to allocate an independent container instance for each vulnerability reproduction task, and build a strong isolation architecture of single task and single instance.

[0126] A single-task, single-instance strongly isolated architecture means that each container instance has its own independent process namespace, network namespace, mount point, and user permission system. Containers are invisible to each other and do not interfere with each other at the kernel level.

[0127] Even if a container crashes or is compromised due to malicious code execution, its impact is strictly limited to the boundaries of that container and will never affect the host machine or other test tasks running in parallel.

[0128] Compared to traditional virtual machine solutions, containerization technology reduces environment startup time from minutes to seconds while maintaining the same level of isolation, and reduces resource overhead by several orders of magnitude. This enables the system to support high-concurrency vulnerability verification needs without becoming a pipeline bottleneck due to excessively long environment preparation time.

[0129] Step B: Automatically configure the operating system, browser, and dependency libraries of the container instance based on the technology stack of the target asset.

[0130] To ensure that the reproduction environment is highly consistent with the real operating environment of the target asset, the system has the ability to adaptively configure the environment based on the technology stack.

[0131] During the container instance creation phase, the target asset technology stack information recorded in the structured vulnerability report is first read, including but not limited to the development language version, web framework type, middleware type, and database version.

[0132] The system pulls the base operating system image that matches the target asset from the pre-built base image repository, and installs the specified version of the browser, runtime environment and necessary dependency libraries in the container through an automated initialization script.

[0133] For example, if the target asset is a backend management system based on the Java Spring Boot framework, the system will automatically configure a container environment including the corresponding JDK version, Tomcat server, and MySQL driver; if the target asset is a frontend site based on PHP, it will automatically configure Nginx, PHP-FPM, and the corresponding extension modules.

[0134] This automated adaptation mechanism eliminates the "false negative" reproduction failures caused by version differences and configuration omissions when manually setting up environments, ensuring the objectivity and accuracy of verification results, while also significantly reducing the manpower cost of maintaining multiple heterogeneous test environments.

[0135] Step C: Enable sandbox network management to limit the network access range, traffic rate, and number of connections for container instances, and block port scanning and lateral movement operations.

[0136] While ensuring environmental consistency, the sandbox network management mechanism constitutes a security defense against the spillover of testing risks.

[0137] Since vulnerability reproduction essentially simulates attack behavior, unrestricted test traffic could cause denial-of-service attacks on the production network or trigger lateral movement alerts. Therefore, the system implements a fine-grained control strategy at the container network interface layer.

[0138] Specifically, regarding network access scope, the system uses a whitelist mechanism by default, allowing containers to access only the target IP address or domain name specified in the vulnerability report, as well as the tool update source and log collection endpoint within the system. Access to any other Internet address or intranet segment is strictly prohibited, thus blocking the path of sandbox escape and unauthorized probing from the source.

[0139] Regarding traffic rate and number of connections, the system sets hard upper limits on the outbound bandwidth and concurrent connection count of containers through token bucket algorithm or similar rate limiting mechanism to prevent traffic surges caused by automated script infinite loops or malicious payloads from overwhelming network devices.

[0140] More importantly, the system deploys behavior detection probes at the kernel level, which can identify and intercept typical lateral movement and persistence operations such as port scanning, SMB / RDP brute-force attacks, and reverse shell establishment in real time. Once such high-risk behavior is detected, the system will immediately disconnect the container's network connection and log the abnormal event, ensuring that the testing behavior is always within a controllable security boundary.

[0141] Step D: After the vulnerability reproduction task is completed, automatically destroy the corresponding container instance to release computing and storage resources.

[0142] This includes not only stopping and deleting the container instance itself, but also thoroughly erasing associated temporary storage volumes, network configurations, cache files, and log data. This "read-and-burn" lifecycle management ensures that any malicious samples, sensitive credentials, or test traces that may remain in the environment will not be reused or leaked by subsequent tasks, achieving an absolutely clean reset of the environment.

[0143] At the same time, the released CPU, memory, and storage resources will be returned to the resource pool in a timely manner for use in scheduling new reproduction tasks, thereby ensuring the stability and resource utilization efficiency of the system under long-term continuous operation.

[0144] Step S204D: During the execution of the vulnerability reproduction task, automatically collect full traffic data, screen recording data, and key node screenshots, and generate a reproduction result containing the evidence chain by associating the vulnerability number.

[0145] Regardless of the reproduction strategy employed, the entire process of automatic evidence collection will be executed simultaneously during the vulnerability reproduction task to ensure the traceability and legal validity of the reproduction results.

[0146] Specifically, evidence collection covers three dimensions: First, full traffic data. The system captures all HTTP / HTTPS request and response data packets generated during the reproduction process through the underlying network proxy, and fully records the details of the attack payload being sent and the server's feedback. Second, screen recording data, which records the entire desktop operation in the sandbox environment, intuitively showing the interface changes and interaction process when the vulnerability is triggered; Thirdly, key node screenshots are automatically captured at critical moments such as detected status code changes, return of sensitive data, or page errors, serving as static evidence for auxiliary verification.

[0147] More importantly, all the evidence data collected will be automatically labeled with a vulnerability number that uniquely corresponds to the current vulnerability report, and then encrypted, packaged, and stored.

[0148] This correlation mechanism ensures that every reproduction result is verifiable and verifiable, providing not only an objective basis for subsequent hierarchical intelligent agents, but also an immutable digital evidence chain for security audits and dispute tracing, thus solving the audit disputes caused by missing or chaotic evidence in traditional crowdsourcing platforms.

[0149] In another embodiment, the system automatically determines whether the vulnerability has been successfully reproduced based on factors such as changes in system state after exploitation, characteristics of response content, and abnormal business logic.

[0150] Reproduction successful: Package the reproduction result with the complete chain of evidence and automatically output it to the hierarchical intelligent agent for risk assessment.

[0151] Reproduction Failure: The system automatically analyzes the reasons for the failure. If the report information is missing, it prompts the white-hat hacker to supplement the relevant information. If the failure is due to environment incompatibility or complex logic that prevents automatic reproduction, it automatically transfers the case to the manual review channel.

[0152] Current vulnerability classification systems rely heavily on the individual experience of auditors, lacking quantifiable and standardized assessment criteria. Different auditors may classify the same vulnerability by 2-3 levels. This can easily lead to high-risk vulnerabilities being underestimated and delayed remediation, or low-risk vulnerabilities being overclassified, consuming valuable security resources and resulting in a mismatch between security investment and actual risk.

[0153] To more clearly explain the working principle of the automatically reproducing intelligent agent, Figure 5 The workflow of automatically reproducing the intelligent agent is shown: After receiving structured vulnerability data, the automatic reproduction agent first determines the vulnerability type: if it is a standardized vulnerability, it generates a POC script and calls security tools; if it is a non-standardized vulnerability, it uses a large model to infer business logic and constructs interactive test cases.

[0154] The system then automatically configures the environment and performs reproduction operations within a dynamic sandbox, collecting multi-dimensional evidence such as packet captures, screen recordings, and screenshots in real time. Finally, the results are evaluated. If successful, a reproduction result containing a complete chain of evidence is output; if unsuccessful, additional information is requested or the process is transferred to manual review, thus achieving an automated verification loop.

[0155] Therefore, based on the above embodiments, the vulnerability risk is assessed based on the reproduction results, including: Step S205A: Extract the technical indicators of the reproduction results according to the general vulnerability scoring system standard; and calculate the basic technical score of the vulnerability based on the technical indicators.

[0156] For example, the internationally accepted CVSS 3.1 basic score calculation formula is directly adopted, with a value range of [0,10]. Only the 7 most core indicators are extracted (attack vector, attack complexity, access requirements, user interaction, confidentiality impact, integrity impact, and usability impact):

[0157] Examples: A vulnerability that allows remote execution of system commands without authentication has a base CVSS score of 9.8; a vulnerability that requires ordinary user privileges and can only read partial data has a base CVSS score of 6.5.

[0158] The complete CVSSv3.1 User Guide and calculation formulas are publicly available on the FIRST website, and any developer can obtain and implement them for free. As long as the specific values ​​for the seven basic metrics are given, the calculation result is unique and fixed, and will not be elaborated further here.

[0159] These metrics are based entirely on objective technical performance during the vulnerability exploitation process and do not rely on any external environmental assumptions. The above metrics are calculated according to the algorithm logic defined in the CVSS 3.1 specification to obtain the vulnerability's basic technical score.

[0160] This score reflects the upper limit of the theoretical harm of the vulnerability in an idealized, standardized environment, and constitutes the technical baseline for risk assessment.

[0161] However, this baseline alone cannot accurately reflect the actual threat level of vulnerabilities in a specific enterprise network, because the destructive power of the same technical flaw can vary by orders of magnitude in different business scenarios. Therefore, it is necessary to further obtain the business environment factors of the target assets.

[0162] Step S205B: Obtain the business environment factors of the target asset.

[0163] Business environment factors are not subjective management evaluations or business value judgments, but rather technical indicators derived from the quantification of objective technical data within the enterprise's information infrastructure.

[0164] Specifically, business environment factors include at least four dimensions: asset importance factors, business interruption impact factors, field utilization status factors, and repair cost factors.

[0165] All factors have values ​​ranging from [0.8, 1.5]. Higher values ​​indicate higher risk. The quantitative standards for each factor are shown in the table below:

[0166] The asset importance factor is obtained by reading the enterprise's configuration management database (CMDB) or automated asset ledger. The system automatically assigns a value based on the business line level to which the target asset belongs (such as core transaction area, general office area, test and development area).

[0167] The business interruption impact factor is determined based on the operation and maintenance monitoring system or fault drill records. The system analyzes whether the failure of the asset will lead to the interruption of the core business link, the degradation of some functions, or no direct impact, thereby quantifying its technical dependence on system availability.

[0168] The field exploitation situation factor is obtained by connecting to external threat intelligence platforms or local vulnerability knowledge bases. The system searches for whether there is publicly available exploit code (EXP) for this vulnerability type and the extent to which the EXP is actively spread on the Internet. This is a purely cyberspace security technical indicator.

[0169] The cost factor for fixing the vulnerability is determined by querying the change management system or deployment architecture documentation. The system determines whether fixing the vulnerability requires downtime maintenance, service restart, or hot updates, which reflects the technical coupling and maintenance complexity at the system architecture level.

[0170] In this way, all business environment factors are anchored to objective technical data sources that can be collected and verified, completely eliminating human subjectivity and ensuring the object compliance and technical rigor of the hierarchical model.

[0171] Step S205C: Based on the preset security policy weights, calculate the risk score of the vulnerability's basic technical score and the business environment factor by weighted averaging.

[0172] Specifically, the system uses the vulnerability basic technology score as the base and four business environment factors as adjustment coefficients, and performs a fusion calculation according to a preset weight ratio.

[0173] For example, the CVSS baseline score is weighted and averaged with four business factors; the formula is simple and intuitive:

[0174] Enterprises can adjust the weighting ratios according to their own security strategies. For example, the financial industry can increase the weighting of asset importance, while the internet industry can increase the weighting of wilderness utilization status.

[0175] Step S205D: Map the risk score to a preset risk level range to determine the risk level of the vulnerability.

[0176] The preset risk level range is usually divided into four standard levels: high risk, medium risk, low risk, and information level. Each level corresponds to a specific score threshold range. For example, a risk score greater than or equal to 9.0 is considered high risk, between 7.0 and 9.0 is considered medium risk, between 4.0 and 7.0 is considered low risk, and below 4.0 is considered information level.

[0177] To more clearly explain the working principle of hierarchical intelligent agents, Figure 6 The internal workflow diagram of the hierarchical intelligent agent is shown below: The hierarchical intelligent agent receives the reproduction results and structured vulnerability data, and first performs basic indicator quantification and scoring based on the CVSS 3.1 standard. Then, it incorporates multi-dimensional factors such as asset importance, business impact risk assessed by LLM semantics, field exploitation intelligence, and remediation costs for weighted correction. A comprehensive risk score is dynamically calculated using enterprise-defined weights, and the risk level is automatically labeled according to the score range (≥9.0 for high risk, 7.0-9.0 for medium risk, 4.0-7.0 for low risk, and <4.0 for informational vulnerabilities). Finally, it outputs a vulnerability rating result containing detailed classification criteria.

[0178] Based on the above embodiments, the method further includes: Step S106: Match multiple general remediation templates based on the vulnerability type of the target asset.

[0179] The general remediation templates are not unstructured natural language documents, but rather structured data objects pre-installed in the vulnerability remediation knowledge base. Each template contains standard cause analysis for a specific vulnerability type, general remediation logic, multi-language code snippets, and verification methods.

[0180] For example, regarding SQL injection vulnerabilities, the knowledge base may store multiple candidate templates applicable to different technology stacks such as JavaMyBatis, PHPPDO, and PythonSQLAlchemy.

[0181] By reading the vulnerability type field obtained from the parsing, a precise search is performed in the knowledge base to obtain a set of all candidate templates associated with that vulnerability type, providing basic materials for subsequent personalized adaptation.

[0182] Step S107: Extract the technical stack features of the target asset, calculate the fit between the technical stack features and multiple general repair templates, and select the optimal repair template with the highest fit.

[0183] Specifically, three core technology stack features are extracted from the configuration information or parsed context of the target asset: development language, web framework, and middleware or server version.

[0184] These three features are compared with the technical environment applicable to each candidate template, and the fit is determined by accumulating the matching results.

[0185] For example, the fit score formula is:

[0186] in, This indicates the matching score of the development language; This indicates the matching score of the Web framework; This represents the matching score for the server version; each perfect match scores 1 point, a partial match scores 0.5 points, and no match scores 0 points, with a total score range of [0, 3].

[0187] The scores of the three features are summed to obtain the overall fit score of the template, and the template with the highest score is automatically selected as the optimal repair template.

[0188] Step S108: Use a large language model to tailor and adapt the code of the optimal repair template to the specific scenario, and generate a customized repair solution.

[0189] In terms of scenario tailoring, the large language model is guided to identify and remove redundant branches in the template that are irrelevant to the current technology stack. For example, when it is confirmed that the target system is using a MySQL database, the differential processing descriptions for Oracle or PostgreSQL in the template are automatically deleted, making the solution more focused and concise.

[0190] In terms of code adaptation and rewriting, the large language model rewrites the pseudocode or sample code in the template into real executable code that conforms to the project's coding standards, based on the current development language version and framework specifications.

[0191] For example, if the target asset is a Java backend service based on Spring Boot 2.7 and the vulnerability is a reflected XSS, the large language model will not only generate standard code that uses the HtmlUtils.htmlEscape method for escaping, but will also supplement the corresponding @ControllerAdvice global exception handling or filter configuration code according to the characteristics of Spring MVC, and even automatically adjust the import statement to match the package structure of the project.

[0192] This deep rewriting driven by a large model results in a repair solution that is no longer a generic textbook answer, but a customized engineering solution that is truly embedded in the technical context of the target system.

[0193] Step S109: Perform a two-dimensional verification of the integrity and security of the customized repair solution. After the verification is passed, output a standardized repair document containing the cause of the problem, rectification steps, code repair examples, retesting methods, and security hardening suggestions.

[0194] Among them, integrity verification refers to the system automatically scanning the generated repair documents to confirm whether they completely contain the five standardized elements: the cause of the problem, the rectification steps, the code repair example, the retesting method, and the security hardening suggestions. If any element is missing, the verification is deemed to have failed.

[0195] The system uses a large language model or a pre-built security rule engine to conduct a secondary review of the generated code repair examples, checking for unsafe function calls, missing necessary boundary condition checks, and whether the integrity of the original business logic has been compromised.

[0196] For example, when fixing file upload vulnerabilities, if the generated code only verifies the file extension but not the file header magic number, the security verification module will identify this flaw and mark it as high risk.

[0197] Only when a customized repair solution passes both integrity and security checks will the system package it into a standardized repair document and output it. If the check fails, the system will automatically trigger a regeneration process and add the reason for the failure as negative feedback to the prompt words to guide the model to correct itself, until a qualified solution is generated or the maximum number of retries is reached, after which it will switch to the manual writing channel.

[0198] Through this rigorous two-dimensional verification mechanism, this embodiment effectively avoids the illusions or security blind spots that may arise from large language models, ensuring that the final repair documents delivered to R&D personnel are both complete and secure.

[0199] To more clearly explain how the repair suggestion agent works, Figure 7 The internal flowchart of the repair suggestion agent is shown; The remediation suggestion agent receives the vulnerability classification results, vulnerability type, and asset technology stack information output by the hierarchical agent. First, it searches the local vulnerability remediation knowledge base based on the vulnerability type and matches the corresponding general remediation template. Then, by combining the large model with the current system's development language, framework, middleware version, and other technology stack information, it rewrites and adapts the general remediation solution according to the scenario, removing inapplicable content and supplementing corresponding code-level remediation details.

[0200] After the solution is generated, the intelligent agent automatically verifies the correctness, completeness, and security of the repair logic to ensure that the repair method does not introduce new security risks or business failures.

[0201] If the verification passes, a complete remediation document is output, including the cause of the problem, rectification steps, code repair examples, retesting methods, and security hardening suggestions. If the verification fails, a solution is automatically regenerated. If multiple failures occur, manual assistance is provided to write the solution, ultimately resulting in a standardized remediation result that can be directly delivered to R&D for rectification.

[0202] To more clearly illustrate the working principle of multi-agent collaboration in this invention, Figure 8 A schematic diagram of the overall workflow of multi-agent collaboration is shown: The multi-agent collaborative workflow begins with receiving vulnerability reports in multiple formats. The parsing agent extracts structured information and compares it with the vulnerability fingerprint database. If a match is found, the historical results are output. If a match fails, the false positive filtering agent calculates the false positive probability, and high-probability reports are archived directly.

[0203] After filtering, the automatic reproduction agent performs vulnerability reproduction in a sandbox. Successful reproduction generates reproduction logs, screen recording evidence, etc., and a hierarchical agent performs multi-dimensional comprehensive assessment. Finally, a remediation suggestion agent generates a solution. The final results are pushed to the enterprise and white-hat hackers, and the samples are added to the database to optimize the model, forming a closed loop.

[0204] If reproduction fails, you will be prompted to provide additional information or proceed to manual review.

[0205] The system for intelligent classification and automatic reproduction of security vulnerabilities based on multi-agent collaboration provided in this invention embodiment can be specific hardware on a device or software or firmware installed on the device. The system provided in this invention embodiment has the same implementation principle and technical effects as the aforementioned method embodiment. For the sake of brevity, any parts not mentioned in the system embodiment can be referred to the corresponding content in the aforementioned method embodiment. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, units, and processes described above can all be referred to the corresponding processes in the above method embodiments, and will not be repeated here.

[0206] In the embodiments provided by this invention, it should be understood that the disclosed systems and methods can be implemented in other ways. The system embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the shown or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces. Indirect couplings or communication connections between systems or units may be electrical, mechanical, or other forms.

[0207] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0208] In addition, the functional units in the embodiments provided by the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0209] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0210] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In addition, the terms "first", "second", "third", etc. are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0211] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention. All should be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for intelligent handling of security crowdsourcing vulnerabilities based on multi-agent collaboration, characterized in that, include: Obtain multimodal vulnerability reports targeting the asset; The parsing agent is invoked to perform structured parsing on the multimodal vulnerability report, resulting in a structured vulnerability report. The false positive filtering agent is invoked to screen the structured vulnerability reports for false positives, thereby filtering out valid vulnerability reports; The automatic reproduction agent is invoked to perform automated reproduction verification on the valid vulnerability report in a dynamic isolation sandbox environment, generating a reproduction result containing a chain of evidence; The hierarchical intelligent agent is invoked to classify the vulnerability risk of the reproduced results, and the risk level and classification basis are output.

2. The method according to claim 1, characterized in that, The multimodal vulnerability report is parsed in a structured manner to obtain a structured vulnerability report, which includes: Extract the text information and network protocol data from the multimodal vulnerability report; The extracted text information and parsed network protocol data are concatenated into a complete context and input into a pre-trained large language model; Using the large language model, multiple fields of the complete context are extracted according to a preset specification. The multiple fields include at least the vulnerability type, target asset address, attack payload, reproduction steps, and scope of impact. Verify the logical consistency of each field, and convert the fields that pass the verification into a preset unified format, outputting a structured vulnerability report.

3. The method according to claim 1, characterized in that, The structured vulnerability reports are subjected to false positive screening to identify valid vulnerability reports, including: The structured vulnerability report is matched with a historical false alarm sample library to determine the historical false alarm similarity score; The structured vulnerability report is logically validated using a large language model to determine its semantic and logical rationality score. The configuration information of the test environment and the production environment of the target asset is compared to determine the environment consistency score; The false alarm probability is obtained by weighting and fusing the historical false alarm similarity score, the semantic logic rationality score, and the environmental consistency score based on preset weights. If the false positive probability is less than a preset threshold, the structured vulnerability report is determined to be a valid vulnerability report.

4. The method according to claim 3, characterized in that, The step of matching the structured vulnerability report with a historical false positive sample database to determine the historical false positive similarity score includes: Extract vulnerability type, target access path, involved parameter name, and payload keywords as core features from the structured vulnerability report; count the number of features that successfully match the core features in the historical false alarm sample library; determine the historical false alarm similarity score based on the ratio of the number of core features to the total number of core features; The step of performing logical rationality verification on the structured vulnerability report using a large language model to determine the semantic logical rationality score includes: The structured vulnerability report is input into a large language model; the clarity of the reproduction steps, the matching degree between the vulnerability description and the payload, and the logical contradictions are verified; the semantic logic rationality score is determined based on the ratio of the number of verified items to the total number of verified items. The comparison of the configuration information of the test environment and the production environment of the target asset to determine the environment consistency score includes: The consistency scores of the test environment and production environment of the target asset are compared item by item to determine the consistency of the domain name and port, the existence of the interface, and the consistency of user permissions. The ratio of the number of consistent dimensions to the total number of dimensions compared is used to determine the consistency score of the environment.

5. The method according to claim 1, characterized in that, Automated reproduction verification of the valid vulnerability report is performed in a dynamic isolation sandbox environment, generating reproduction results containing a chain of evidence, including: Based on the vulnerability type field in the structured vulnerability report, vulnerabilities are classified into standardized vulnerabilities or complex business vulnerabilities. In response to the fact that the vulnerability type is a standardized vulnerability, a fully automated reproduction strategy is adopted, which automatically generates test scripts and calls dedicated security tools to execute vulnerability reproduction tasks in a dynamic isolated sandbox environment; In response to the fact that the vulnerability type is a complex business vulnerability, a semi-automated reproduction strategy is adopted. The business logic is reasoned based on a large language model and multi-step interactive test cases are constructed. The vulnerability reproduction task is executed in the dynamic isolation sandbox environment based on the multi-step interactive test cases. During the execution of the vulnerability reproduction task, the system automatically collects full traffic data, screen recording data, and screenshots of key nodes, and associates them with the vulnerability number to generate a reproduction result containing a chain of evidence.

6. The method according to claim 1, characterized in that, The construction and management of the dynamic isolation sandbox environment includes: Containerization technology is used to allocate an independent container instance for each vulnerability reproduction task, thus building a strong isolation architecture of single task and single instance; The operating system, browser, and dependency libraries of the container instance are automatically configured according to the technology stack of the target asset; Enable sandbox network management to restrict the network access range, traffic rate, and number of connections of the container instance, and block port scanning and lateral movement operations; After the vulnerability reproduction task is completed, the corresponding container instance is automatically destroyed to release computing and storage resources.

7. The method according to claim 1, characterized in that, The vulnerability risk is assessed based on the reproduced results, including: The technical indicators of the reproduction results are extracted according to the general vulnerability scoring system standard; and the basic technical score of the vulnerability is calculated based on the technical indicators. Obtain the business environment factors of the target assets; Based on the preset security policy weights, the basic technical score of the vulnerability is calculated by weighted averaging with the business environment factors to obtain the risk score of the reproduction result; The risk score is mapped to a preset risk level range to determine the risk level of the vulnerability.

8. The method according to claim 1, characterized in that, The method further includes: Multiple general remediation templates are matched based on the vulnerability type of the target asset; Extract the technical stack features of the target asset, calculate the compatibility between the technical stack features and the multiple general repair templates, and select the optimal repair template with the highest compatibility. By using a large language model to perform scenario-specific tailoring and code adaptation rewriting on the optimal repair template, a customized repair solution is generated. The customized repair solution is subjected to two-dimensional verification of integrity and security. After the verification is passed, a standardized repair document is output, which includes the cause of the problem, rectification steps, code repair examples, retesting methods and security hardening suggestions.

9. A security crowdsourcing vulnerability intelligent handling system based on multi-agent collaboration, characterized in that, include: The analytical agent is used to obtain multimodal vulnerability reports targeting specific assets. The multimodal vulnerability report is then subjected to structured parsing to obtain a structured vulnerability report. A false alarm filtering agent is used to screen the structured vulnerability reports for false alarms in order to filter out valid vulnerability reports; An automated reproduction agent is used to perform automated reproduction verification on the valid vulnerability report in a dynamic isolated sandbox environment, and generate a reproduction result containing a chain of evidence. A hierarchical intelligent agent is used to classify the vulnerability risk of the reproduced results and output the risk level and the basis for classification.

10. The system according to claim 9, characterized in that, The system also includes; A repair agent is used to generate customized repair solutions based on the risk level and vulnerability context.

Images