A complex network vulnerability autonomous reproduction verification method and system

Abstract

This application discloses a method and system for autonomous reproduction and verification of complex network vulnerabilities. The method includes: acquiring input information for a vulnerability reproduction and verification task and generating a stateful task object; obtaining candidate information based on the task object and performing structured processing to obtain structured verification information; generating an execution plan including the current verification path and path switching conditions based on the task object, structured verification information, and historical execution records; generating a protocol-independent verification step sequence based on the structured verification information, and executing the verification step sequence according to the security device verification path or vulnerability environment verification path to collect verification evidence; writing execution observation information back to the task object; determining the verification result or updating the execution plan to continue verification based on the execution observation information and evidence status; and archiving the verification result and related evidence information. This method improves the verification adaptability and execution stability in complex vulnerability scenarios and provides a unified basis for reviewing verification results.

Description

Technical Field

[0001] This application relates to the field of network security verification technology, and in particular to a method and system for autonomously reproducing and verifying complex network vulnerabilities. Background Technology

[0002] With the widespread deployment of information systems, cloud computing platforms, industrial control systems, business middleware, and various network services, the number and types of network vulnerabilities are constantly increasing. To assess vulnerability risks, verify security protection capabilities, and support vulnerability remediation efforts, it is typically necessary to reproduce and verify network vulnerabilities. For network vulnerabilities involving multiple components, protocols, versions, or complex triggering conditions, the reproduction and verification process often requires a comprehensive analysis combining information from multiple aspects, including vulnerability descriptions, affected versions, operating environments, network interaction processes, and actual response results.

[0003] In related technologies, network vulnerability reproduction and verification typically rely on manual analysis of vulnerability announcements, retrieval of public information, setup of test environments, configuration of target services, construction of verification requests, and observation of verification results. Some automated verification tools can perform detection operations for specific vulnerabilities based on preset scripts or fixed rules, but this type of approach is usually suitable for scenarios with clear triggering conditions, simple interaction processes, or few environmental dependencies. When vulnerabilities involve multiple preconditions, different product versions, authentication constraints, service dependencies, or multi-stage network interactions, existing methods often require manual and repeated adjustments to verification parameters, correction of the operating environment, and judgment of verification results, resulting in low verification efficiency and stability. Furthermore, different personnel or different tools may have inconsistent criteria for judging verification success, failure, and intermediate abnormal states, making it difficult to establish a unified basis for verification of request responses, operating logs, environmental states, and analysis conclusions generated during the verification process.

[0004] Therefore, in the reproduction and verification of complex network vulnerabilities, the high degree of reliance on manual processes in the reproduction process, insufficient adaptability to complex scenarios, poor stability of the verification process, and inconsistent criteria for verifying results have become urgent problems to be solved. Summary of the Invention

[0005] This application provides a method and system for autonomous reproduction and verification of complex network vulnerabilities, aiming to solve the problems of high reliance on manual processes, insufficient adaptability to complex scenarios, poor stability of verification processes, and inconsistent verification results in the reproduction and verification of complex network vulnerabilities in existing technologies.

[0006] Firstly, a method for autonomously reproducing and verifying complex network vulnerabilities, the method comprising: Obtain the input information for the vulnerability reproduction and verification task; The input information is parsed and processed to generate a stateful task object. The stateful task object is used to record basic vulnerability information, verification condition information, path status, historical execution records, and evidence status. Based on the stateful task object, candidate information related to the vulnerability reproduction and verification task is obtained, and the candidate information is filtered and structured to obtain structured verification information. An execution plan is generated based on the stateful task object, the structured verification information, and the historical execution records. The execution plan includes the current verification path and path switching conditions. The current verification path includes a security device verification path or a vulnerability environment verification path. Based on the structured verification information, a protocol-independent verification step sequence is generated. The verification step sequence is used to generate at least one of the following: verification request, protocol message, test traffic, verification script, and multi-stage interaction sequence. The verification step sequence is executed according to the current verification path to collect rule hit verification evidence under the security device verification path, or vulnerability effect verification evidence under the vulnerability environment verification path. Collect execution observation information generated during the execution of the verification step sequence, and write the execution observation information back to the stateful task object; Determine whether the verification success condition or the verification termination condition is met based on the execution observation information and the evidence status. If the verification success condition or the verification termination condition is met, the verification result is determined; If the verification success condition and the verification termination condition are not met, and the execution observation information meets the path switching condition, the execution plan is updated and the verification continues. The verification results and the evidence information associated with the verification results are archived.

[0007] Optionally, in the above scheme, parsing the input information to generate a stateful task object includes: Entity recognition is performed on the input information to obtain at least one of vulnerability entity information, product entity information, version entity information, and external reference information. At least one of the vulnerability entity information, the product entity information, the version entity information, and the external reference information is subjected to field normalization processing to obtain a normalized field set; The vulnerability basic information and verification condition information are determined based on the normalized field set; The stated task object is obtained by initializing the path state, historical execution records, and evidence state based on the vulnerability basic information and the verification condition information.

[0008] Optionally, in the above scheme, the method further includes: After each round of verification is completed, obtain at least one of the following: execution summary, environment status, failure reason, valid clues, and evidence object corresponding to this round of verification; Generate the current round history based on at least one of the execution summary, the environment state, the failure reason, the valid clues, and the evidence object; Write the current round history into the historical execution record of the stateful task object to obtain the updated task object; The next round of execution plan is generated based on the updated task object, and the candidate information and verification path required for the next round of verification are determined according to the next round of execution plan.

[0009] Optionally, in the above scheme, generating an execution plan based on the stateful task object, the structured verification information, and the historical execution records includes: The state of the detection feature availability, the state of the verification condition completeness, and the state of the environment buildability are determined based on the state of the task object. The completeness of the triggering conditions and the complexity of the protocol interaction are determined based on the structured verification information. Based on the historical execution records, determine the executed paths, reasons for failure, and reusable clues; The current verification path and path switching conditions are determined based on at least one of the following: the availability status of the detection features, the completeness status of the verification conditions, the constructability status of the environment, the completeness of the triggering conditions, the complexity of the protocol interaction, the executed path, the reason for failure, and the reusable clues. The execution plan is generated based on the current verification path and the path switching conditions.

[0010] Optionally, in the above scheme, updating the execution plan and continuing the verification process when the verification success condition and the verification termination condition are not met, and the execution observation information meets the path switching condition, includes: If the verification path in this round is a security device verification path, the rule hit status and the reason for the miss are determined based on the execution observation information; When the rule hit status indicates that the target rule has not been hit, and the reason for the miss is related to at least one of the following: incomplete trigger field, missing authentication conditions, and unmet timing constraints, the current verification path is switched to the vulnerability environment verification path to obtain the first update path. The execution plan is updated according to the first update path, and the vulnerability environment verification is performed based on the updated execution plan; If valid trigger information is obtained in the vulnerability environment verification, the valid trigger information is written back to the structured verification information to obtain the updated structured verification information; Based on the updated structured verification information, a protocol-independent sequence of verification steps for the security device verification path is regenerated.

[0011] Optionally, in the above scheme, the step of obtaining candidate information related to the vulnerability reproduction and verification task based on the stateful task object, and filtering and structuring the candidate information to obtain structured verification information includes: The information retrieval conditions are determined based on the stateful task object, and the information retrieval conditions include at least one of the following: vulnerability identification conditions, product version conditions, protocol conditions, vulnerability type conditions, and source conditions. Based on the information retrieval conditions, multi-source candidate information is obtained, which includes at least one of the following: official announcements, patch differences, publicly available verification code, technical articles, code repositories, security device feature information, and historical verification samples. The multi-source candidate information is subjected to source normalization and content deduplication to obtain normalized candidate information; The standardized candidate information is subjected to relevance screening and conflict resolution to obtain the target candidate information; The target candidate information is structured and refined to obtain structured verification information including at least one of the following: preconditions, triggering actions, protocol elements, authentication conditions, timing constraints, expected responses, and vulnerability effects.

[0012] Optionally, in the above scheme, the step of generating a protocol-independent verification step sequence based on the structured verification information includes: Extract the preconditions, protocol elements, triggering actions, execution constraints, and expected observation results from the structured verification information; Based on the preconditions, protocol elements, triggering actions, execution constraints, and expected observation results, generate protocol-independent step description information; The verification step sequence is obtained by sorting the execution order and dependencies between the described steps. Each verification step in the verification step sequence includes at least one of the following: step identifier, protocol type, key field set, execution constraints, and expected observation results; Generate at least one of the following based on the verification step sequence: verification request, protocol message, test traffic, verification script, and multi-stage interaction sequence.

[0013] Optionally, in the above scheme, if the current verification path is a vulnerability environment verification path, the step of executing the verification step sequence according to the current verification path includes: The target environment conditions are determined based on the stateful task object and the structured verification information. Match a reusable environment template based on the target environment conditions; If the reusable environment template is matched, a vulnerability verification environment is started based on the reusable environment template; If no reusable environment template is matched, environment deployment information is generated based on the target environment conditions, and a vulnerability verification environment is started based on the environment deployment information. Perform an availability self-test on the vulnerability verification environment and obtain the environment self-test results; If the environment self-test results indicate that the vulnerability verification environment is available, the vulnerability trigger verification action is executed based on the verification step sequence.

[0014] Optionally, in the above scheme, the method further includes: If the environment self-test result indicates that the vulnerability verification environment is unavailable, obtain at least one of the following: startup log, exception information, and dependency status information corresponding to the vulnerability verification environment; The cause of environment failure is determined based on at least one of the startup log, the exception information, and the dependency status information. Generate environmental correction information based on the reasons for the environmental failure; The environment deployment information is updated based on the environment correction information to obtain the updated environment deployment information; Restart the vulnerability verification environment based on the updated environment deployment information and re-perform the availability self-test; If the number of times the availability self-check is repeated reaches a preset number, or if the cause of the environment failure does not meet the correctable conditions, an environment verification failure message is generated and written back to the stateful task object.

[0015] Secondly, a system for autonomously reproducing and verifying complex network vulnerabilities, the system comprising: The task object construction module is used to obtain the input information of the vulnerability reproduction and verification task, parse and process the input information, and generate a stateful task object. The stateful task object is used to record the basic vulnerability information, verification condition information, path status, historical execution records, and evidence status. The information processing module is used to obtain candidate information related to the vulnerability reproduction and verification task based on the stateful task object, and to filter and structure the candidate information to obtain structured verification information. The planning module is used to generate an execution plan based on the stateful task object, the structured verification information, and the historical execution records. The execution plan includes the current verification path and path switching conditions. The current verification path includes a security device verification path or a vulnerability environment verification path. The step generation module is used to generate a protocol-independent verification step sequence based on the structured verification information. The verification step sequence is used to generate at least one of the following: verification request, protocol message, test traffic, verification script, and multi-stage interaction sequence. The verification execution module includes a security device verification submodule and a vulnerability environment verification submodule. The security device verification submodule is used to collect rule-hit verification evidence according to the verification step sequence when the current verification path is a security device verification path. The vulnerability environment verification submodule is used to collect vulnerability effect verification evidence according to the verification step sequence when the current verification path is a vulnerability environment verification path. The observation feedback module is used to collect execution observation information generated during the execution of the verification step sequence and write the execution observation information back to the stateful task object; The result determination module is used to determine whether the verification success condition or the verification termination condition is met based on the execution observation information and the evidence status, and to determine the verification result if the verification success condition or the verification termination condition is met. The observation feedback module is connected to the planning module. The planning module is also used to update the execution plan and trigger the verification execution module to continue the verification if the verification success condition and the verification termination condition are not met, and the execution observation information meets the path switching condition. The archiving module is used to archive the verification results and the evidence information associated with the verification results.

[0016] Compared with the prior art, this application has at least the following beneficial effects: This application, based on further analysis and research of existing technical problems, recognizes that existing technologies suffer from several drawbacks in complex network vulnerability reproduction and verification, including high reliance on manual processes, insufficient adaptability to complex scenarios, poor stability of the verification process, and inconsistent verification result verification criteria. By acquiring the input information of the vulnerability reproduction and verification task and generating a stateful task object, this application enables the continuous recording and transmission of basic vulnerability information, verification condition information, path status, historical execution records, and evidence status within the same object. Furthermore, based on the task object, candidate information is obtained and structured to obtain structured verification information, transforming scattered vulnerability-related information into unified information usable for subsequent verification execution. Further, based on the stateful task object, structured verification information, and historical execution records, an execution plan including the current verification path and path switching conditions is generated. And based on the structured verification information, a protocol-independent verification step sequence is generated, enabling complex vulnerabilities with different protocols, triggering conditions, and interaction forms to be reproduced and verified. Verification is performed according to a unified procedure; then, the verification step sequence is executed according to the security device verification path or vulnerability environment verification path, collecting rule-hitting verification evidence or vulnerability effect verification evidence, and writing the execution observation information back to the task object with status. This allows the system to determine whether the verification success condition or verification termination condition is met based on the actual observation results during the execution process, or to update the execution plan and continue verification when the path switching condition is met. Finally, the verification results and related evidence information are archived, thereby transforming the verification of complex network vulnerability reproduction from a process that relies on manual sequencing and experience-based judgment into a closed-loop verification process based on task status, verification path, execution observation, and evidence status. This improves the adaptability to complex scenarios and the stability of the verification process, and provides a unified basis for reviewing the verification results by archiving related evidence. This solves the problems of high reliance on manual intervention, insufficient adaptability to complex scenarios, poor stability of the verification process, and inconsistent review basis for verification results in the verification of complex network vulnerability reproduction. Attached Figure Description

[0017] Figure 1 A flowchart illustrating a method for autonomously reproducing and verifying complex network vulnerabilities provided in one embodiment of this application; Figure 2 A closed-loop diagram of autonomous reproduction and verification of complex network vulnerabilities based on AI Agent provided in one embodiment of this application; Figure 3 This is a flowchart illustrating the autonomous planning, path switching, and environment correction process of an AI Agent as provided in one embodiment of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0019] In one embodiment, such as Figure 1 As shown, a method for autonomously reproducing and verifying complex network vulnerabilities is provided, including the following steps: Obtain the input information for the vulnerability reproduction and verification task; The input information is parsed and processed to generate a stateful task object. The stateful task object is used to record basic vulnerability information, verification condition information, path status, historical execution records, and evidence status. Based on the stateful task object, candidate information related to the vulnerability reproduction and verification task is obtained, and the candidate information is filtered and structured to obtain structured verification information. An execution plan is generated based on the stateful task object, the structured verification information, and the historical execution records. The execution plan includes the current verification path and path switching conditions. The current verification path includes a security device verification path or a vulnerability environment verification path. Based on the structured verification information, a protocol-independent verification step sequence is generated. The verification step sequence is used to generate at least one of the following: verification request, protocol message, test traffic, verification script, and multi-stage interaction sequence. The verification step sequence is executed according to the current verification path to collect rule hit verification evidence under the security device verification path, or vulnerability effect verification evidence under the vulnerability environment verification path. Collect execution observation information generated during the execution of the verification step sequence, and write the execution observation information back to the stateful task object; Determine whether the verification success condition or the verification termination condition is met based on the execution observation information and the evidence status. If the verification success condition or the verification termination condition is met, the verification result is determined; If the verification success condition and the verification termination condition are not met, and the execution observation information meets the path switching condition, the execution plan is updated and the verification continues. The verification results and the evidence information associated with the verification results are archived.

[0020] In one embodiment, this application provides a method for autonomously reproducing and verifying complex network vulnerabilities. This method can be executed by a system for autonomously reproducing and verifying complex network vulnerabilities. The system can be deployed on a server, virtualization platform, containerization platform, security verification platform, or vulnerability analysis platform. This method is applicable to scenarios involving the reproduction and verification of complex network vulnerabilities, and is particularly suitable for scenarios where the vulnerability triggering conditions are unclear, the protocol interaction process is complex, the operating environment has many dependencies, or the verification results need to be reviewed and archived.

[0021] First, the system obtains the input information for the vulnerability reproduction and verification task. This input information may include at least one of the following: vulnerability identifier, vulnerability name, target product information, version information, vulnerability description, and reference information. For example, the vulnerability identifier may be a CVE number, an internal vulnerability number, or a security device rule association number; the target product information may include a product name, component name, middleware name, or service name; the version information may include the affected version, patch version, target image version, or software build version; and the reference information may include announcement links, patch descriptions, technical articles, code repository addresses, security device signature sources, or historical verification records. Through this step, the system obtains the initial information used to initiate the vulnerability reproduction and verification task.

[0022] The system then parses and processes the input information to generate stateful task objects. Specifically, the system can perform entity recognition, field extraction, format unification, and field normalization on the input information, converting input content from different sources and in different formats into a unified data object. The stateful task objects are used to record basic vulnerability information, verification condition information, path status, historical execution records, and evidence status. The basic vulnerability information may include vulnerability identifier, vulnerability name, target product, target component, version constraints, and vulnerability type; verification condition information may include protocol type, authentication constraints, environment dependencies, detection feature availability status, and triggering conditions; path status may indicate whether the current state is a security device verification path, a vulnerability environment verification path, or a pending state; historical execution records may record executed request summaries, verification script summaries, environment status, failure reasons, corrective actions, valid clues, and evidence objects; evidence status may indicate whether rule-hit verification evidence, vulnerability effect verification evidence, or failure reason evidence has been formed. Through stateful task objects, the system can incorporate vulnerability reproduction tasks under different input conditions into the same task status management chain.

[0023] Next, the system obtains candidate information related to the vulnerability reproduction and verification task based on the stateful task object, and filters and structures the candidate information to obtain structured verification information. Candidate information can come from sources such as official announcements, patch differences, publicly available verification code, vulnerability databases, technical articles, code repositories, security device characteristic information, and historical verification samples. The system can filter candidate information based on relevance according to information source, vulnerability identifier matching degree, product version matching degree, protocol type matching degree, contextual consistency, and historical verification validity. For content that differs between different sources, conflict resolution can be achieved by combining version matching relationships, source credibility, and cross-consistency. The processed structured verification information can include at least one of the following fields: preconditions, triggering actions, protocol elements, authentication conditions, timing constraints, expected response, vulnerability effect, and evidence association fields. This structured verification information is used to support the subsequent generation of execution plans and verification step sequences.

[0024] Subsequently, the system generates an execution plan based on the stateful task object, the structured verification information, and the historical execution records. The execution plan includes the current verification path and path switching conditions. The current verification path can be either a security device verification path or a vulnerability environment verification path. Specifically, the system can determine the preferred verification path for the current round based on factors such as the availability of detection features, the completeness of structured verification information, the clarity of vulnerability triggering conditions, the feasibility of constructing the target environment, the complexity of protocol interactions, and the presence of failure reasons in the historical execution records. For example, when the security device detection features are relatively complete and can be verified through test traffic, the security device verification path can be prioritized; when it is necessary to observe vulnerability effects such as command execution, file status changes, database results, process status, or abnormal responses, the vulnerability environment verification path can be prioritized. Path switching conditions can include conditions such as rule mismatch, incomplete trigger fields, missing authentication conditions, unmet timing constraints, unavailable environment, valid trigger information already obtained, or evidence objects unable to form a valid association.

[0025] Then, the system generates a protocol-independent verification step sequence based on the structured verification information. This protocol-independent verification step sequence is used to generate at least one of the following: verification request, protocol message, test traffic, verification script, and multi-stage interaction sequence. Specifically, the system can abstract the preconditions, protocol elements, triggering actions, execution constraints, and expected observations in the structured verification information into a unified step description, making this step description independent of a single protocol template. For HTTP, HTTPS, TCP, UDP, RPC, database protocols, or multi-round interaction protocols, a unified expression can be achieved through step identifiers, protocol types, key field sets, execution constraints, and expected observations. Based on this verification step sequence, the system can generate corresponding verification requests, protocol messages, test traffic, verification scripts, or multi-stage interaction sequences, thereby supporting unified execution in complex vulnerability scenarios.

[0026] Subsequently, the system executes the verification step sequence according to the current verification path to collect rule-hit verification evidence under the security device verification path, or vulnerability effect verification evidence under the vulnerability environment verification path. When the current verification path is the security device verification path, the system can generate test traffic according to the verification step sequence and initiate interaction with the target verification link, simultaneously collecting information such as request responses, packet capture traffic, security device alarms, rule numbers, and session identifiers to form rule-hit verification evidence. When the current verification path is the vulnerability environment verification path, the system can construct or invoke a vulnerability verification environment, and, provided the environment is available, execute verification scripts, command sequences, or protocol interaction actions. Simultaneously, it judges the vulnerability effect through information such as response content, log changes, file status, database results, and process status to form vulnerability effect verification evidence.

[0027] During the execution of the verification step sequence, the system collects execution observation information and writes it back to the stateful task object. The execution observation information may include at least one of the following: request / response information, traffic information, rule hit information, log information, environment status information, vulnerability effect information, failure reason information, and valid clue information. After being written back to the task object, the historical execution records and evidence status are updated. The system can then perform subsequent result judgments, path switching, or execution plan updates based on the updated task object, thereby avoiding the repeated execution of invalid verification actions.

[0028] Furthermore, the system determines whether the verification success or termination conditions are met based on the execution observation information and evidence status. If the verification success or termination conditions are met, the system determines the verification result. Verification success conditions may include successful security device verification or successful vulnerability effect verification; verification termination conditions may include failure to meet the triggering prerequisites after continuous corrections, incomplete key fields, inability to construct the target environment, inability to form a valid association between evidence objects, or reaching a preset limit on the number of iterations. If the verification success or termination conditions are not met, but the execution observation information meets the path switching conditions, the system updates the execution plan and continues the verification. For example, if the security device verification path does not hit the target rule and lacks valid triggering details, it can switch to the vulnerability environment verification path; after the vulnerability environment verification path confirms valid triggering information, it can write the key message fields, timing relationships, authentication context, and parameter constraints back to the structured verification information and regenerate the verification step sequence for the security device verification path.

[0029] Finally, the system archives the verification results and related evidence. Archived content may include basic vulnerability information, intelligence sources, structured verification information, final verification request, protocol messages, test traffic, verification scripts, environment configuration, packet capture files, log information, evidence association conclusions, failure reasons, and execution summaries. Through unified archiving, a traceable, verifiable, and reusable vulnerability reproduction and verification archive can be created.

[0030] This embodiment transforms the vulnerability reproduction and verification task into a stateful task object, and generates an execution plan based on the task object, constructs a protocol-independent verification step sequence, executes a security device verification path or a vulnerability environment verification path, writes back execution observation information, and archives evidence. This transforms the complex vulnerability reproduction and verification process from a manual sequential process to a state-driven closed-loop execution process, reducing the degree of reliance on manual intervention, improving the adaptability and stability of the verification process in complex scenarios, and enhancing the verifiability of the verification results through unified evidence archiving.

[0031] In this embodiment, the step of parsing and processing the input information to generate a stateful task object includes: Entity recognition is performed on the input information to obtain at least one of vulnerability entity information, product entity information, version entity information, and external reference information. At least one of the vulnerability entity information, the product entity information, the version entity information, and the external reference information is subjected to field normalization processing to obtain a normalized field set; The vulnerability basic information and verification condition information are determined based on the normalized field set; The stated task object is obtained by initializing the path state, historical execution records, and evidence state based on the vulnerability basic information and the verification condition information.

[0032] In one embodiment, when the system parses and processes the input information to generate a stateful task object, it can first perform entity recognition on the input information to obtain at least one of vulnerability entity information, product entity information, version entity information, and external reference information. Entity recognition can be completed through keyword matching, named entity recognition, field rule parsing, contextual semantic recognition, or historical record matching. Vulnerability entity information may include vulnerability number, vulnerability name, vulnerability type, or vulnerability announcement identifier; product entity information may include product name, component name, service name, or middleware name; version entity information may include affected version, patched version, image tag, or software build information; external reference information may include announcement address, patch description, code repository, technical article, security device feature source, or historical verification record source.

[0033] After obtaining the aforementioned entity information, the system performs field normalization on at least one of the following: vulnerability entity information, product entity information, version entity information, and external reference information, resulting in a normalized field set. Specifically, for different naming methods of the same product from different sources, the system can unify them into a preset product name; for version ranges, version number formats, patch numbers, and image tags, the system can convert them into a unified version constraint expression; for protocol types, authentication methods, environment dependencies, and vulnerability types, the system can map them to preset fields. Through field normalization, the impact of differences in expression between different information sources on subsequent planning and execution can be reduced.

[0034] Subsequently, the system determines the basic vulnerability information and verification condition information based on the normalized field set. The basic vulnerability information may include vulnerability identifier, target product, target component, version constraints, vulnerability type, and reference source; the verification condition information may include at least one of the following: protocol type, authentication constraints, environment dependencies, detection characteristic status, candidate information sources, target port, target service, and expected observation method. This step transforms the raw input into a data foundation capable of supporting the subsequent generation of the execution plan.

[0035] Finally, the system initializes the path state, historical execution records, and evidence state based on the vulnerability basic information and verification condition information, resulting in a stateful task object. The path state can be initialized to a pending planning state, or it can be initialized to a security device verification path or a vulnerability environment verification path based on the availability of detection features or the constructibility of the environment; the historical execution records can be initialized to empty records, or reusable records from historical verification samples can be included; the evidence state can be initialized to a state where no evidence has been formed. The stateful task object generated in this way can be continuously updated during subsequent candidate information acquisition, execution plan generation, verification path execution, observation feedback, and evidence archiving processes.

[0036] This embodiment transforms vulnerability inputs from different formats and sources into continuously updated stateful task objects through entity recognition, field normalization, determination of vulnerability basic information and verification condition information, and state initialization. This provides a unified data foundation for subsequent automatic planning, path selection, verification execution, and result archiving, thereby reducing the cost of manually organizing input information and improving the standardization of complex vulnerability reproduction and verification processes.

[0037] In this embodiment, the method further includes: After each round of verification is completed, obtain at least one of the following: execution summary, environment status, failure reason, valid clues, and evidence object corresponding to this round of verification; Generate the current round history based on at least one of the execution summary, the environment state, the failure reason, the valid clues, and the evidence object; Write the current round history into the historical execution record of the stateful task object to obtain the updated task object; The next round of execution plan is generated based on the updated task object, and the candidate information and verification path required for the next round of verification are determined according to the next round of execution plan.

[0038] In one embodiment, after each round of verification is completed, the system obtains at least one of the following: execution summary, environment status, failure reason, valid clues, and evidence object corresponding to this round of verification. The execution summary may include a summary of the verification step sequence, verification request summary, protocol message summary, test traffic summary, verification script summary, or multi-stage interaction sequence summary; the environment status may include environment startup status, service listening status, version matching status, dependency connectivity status, key interface response status, and process health status; the failure reason may include rule mishit, missing authentication conditions, missing trigger fields, unmet timing constraints, environment unavailability, abnormal dependent services, or insufficient evidence association; valid clues may include key fields, parameter constraints, authentication context, timing relationships, response characteristics, or log keywords that can be used for subsequent correction; the evidence object may include rule hit records, packet capture data, request-response records, log fragments, file change records, database change records, or process status records.

[0039] The system generates the current round's historical record based on at least one of the following: execution summary, environment status, failure reason, valid clues, and evidence object. This historical record can be stored according to a unified field structure, including, for example, round identifier, execution path, execution time, verification step summary, execution result, failure attribution, correction suggestions, valid clues, and evidence index. For failed tasks, the historical record can explicitly identify the failure reason and unmet conditions; for partially successful tasks, the historical record can record the confirmed trigger fields, authentication context, or reusable environment conditions; for successful tasks, the historical record can be associated with the final evidence object and archive identifier.

[0040] Subsequently, the system writes the current round's historical record into the historical execution record of the stateful task object, resulting in an updated task object. The updated task object retains not only the initial vulnerability information and verification conditions, but also the observations, failure attributions, corrective actions, and evidence objects generated in each round of execution. This allows the system to leverage existing execution context in subsequent planning, avoiding repeated attempts at the same failed paths.

[0041] Furthermore, the system generates the next round of execution plan based on the updated task object, and determines the candidate information and verification path required for the next round of verification based on the next round of execution plan. For example, if the current round of security device verification fails to hit the target rule, and the failure reason points to missing authentication conditions, the next round of execution plan can prioritize supplementing the authentication context or switch to the vulnerability environment verification path; if a valid trigger field is confirmed in the current round of vulnerability environment verification, the next round of execution plan can write the trigger field back to the structured verification information and generate a new security device verification step sequence.

[0042] This embodiment generates a history record of the current round after each round of verification and writes back the task object with state, so that the vulnerability reproduction verification process has contextual continuity. It can be replanned based on the executed path, failure reason and valid clues, thereby reducing repeated invalid execution and improving the convergence efficiency and stability of complex vulnerability verification process.

[0043] In this embodiment, generating an execution plan based on the stateful task object, the structured verification information, and the historical execution records includes: The state of the detection feature availability, the state of the verification condition completeness, and the state of the environment buildability are determined based on the state of the task object. The completeness of the triggering conditions and the complexity of the protocol interaction are determined based on the structured verification information. Based on the historical execution records, determine the executed paths, reasons for failure, and reusable clues; The current verification path and path switching conditions are determined based on at least one of the following: the availability status of the detection features, the completeness status of the verification conditions, the constructability status of the environment, the completeness of the triggering conditions, the complexity of the protocol interaction, the executed path, the reason for failure, and the reusable clues. The execution plan is generated based on the current verification path and the path switching conditions.

[0044] In one embodiment, when the system generates an execution plan based on a stateful task object, structured verification information, and historical execution records, it can first determine the detection feature availability status, verification condition integrity status, and environment buildability status based on the stateful task object. The detection feature availability status indicates whether there are detection features, rule information, or security device feature information that can be used for security device verification; the verification condition integrity status indicates whether the vulnerability basic information, protocol type, authentication constraints, target product version, and triggering conditions meet the execution requirements; and the environment buildability status indicates whether there are reusable environment templates, container images, orchestration manifests, historical environment snapshots, or sufficient environment dependency information to generate deployment configurations.

[0045] The system can also determine the completeness of triggering conditions and the complexity of protocol interactions based on structured verification information. The completeness of triggering conditions can be determined by whether the preconditions, triggering actions, key fields, authentication conditions, timing constraints, and expected responses are complete. The complexity of protocol interactions can be determined by the number of protocol types, interaction rounds, field dependencies, authentication process complexity, and the number of timing constraints. This step can determine whether the current structured verification information is sufficient to directly perform verification, or whether supplementary information, path switching, or environment building is required.

[0046] The system further determines the executed paths, reasons for failure, and reusable clues based on historical execution records. Executed paths can represent security device verification paths or vulnerability environment verification paths that have been executed previously; reasons for failure can represent previous failures related to rule mismatch, unavailable environment, missing authentication conditions, insufficient trigger fields, unmet timing requirements, or insufficient evidence; reusable clues can represent parameters, fields, authentication contexts, environment configurations, log keywords, or verification script fragments that have been confirmed to be valid during historical execution.

[0047] After determining the aforementioned states and clues, the system determines the verification path and path switching conditions for this round based on at least one of the following: the availability of detection features, the completeness of verification conditions, the constructability of the environment, the completeness of triggering conditions, the complexity of protocol interactions, the executed path, the reason for failure, and reusable clues. If the detection features are available and the verification conditions are relatively complete, the verification path for this round can be preferentially determined as the security device verification path; if it is necessary to observe the vulnerability effect in a real environment, or if the security device verification lacks triggering details, the verification path for this round can be determined as the vulnerability environment verification path. The path switching conditions can be pre-set based on the failure attribution and evidence status. For example, when the rule is not hit and the triggering fields are insufficient, the system switches to the vulnerability environment verification path; after the environment path confirms valid triggering information, it switches back to the security device verification path.

[0048] Finally, the system generates an execution plan based on the current verification path and path switching conditions. In addition to the current verification path and path switching conditions, the execution plan may also include the target set, candidate information source list, tool call sequence, rollback conditions, environment construction strategy, and termination conditions. The execution plan guides the generation of subsequent verification step sequences, the execution of verification paths, the collection of observation information, and subsequent path adjustments.

[0049] This embodiment generates an execution plan by comprehensively considering the availability of detection features, the completeness of verification conditions, the constructability of the environment, the completeness of triggering conditions, the complexity of protocol interactions, and historical execution records. This enables the system to select a more suitable verification path based on different vulnerability scenarios and pre-set path switching conditions, thereby improving the adaptability and execution stability of complex network vulnerability reproduction and verification.

[0050] In this embodiment, updating the execution plan and continuing the verification process when the verification success condition and the verification termination condition are not met, and the execution observation information meets the path switching condition, includes: If the verification path in this round is a security device verification path, the rule hit status and the reason for the miss are determined based on the execution observation information; When the rule hit status indicates that the target rule has not been hit, and the reason for the miss is related to at least one of the following: incomplete trigger field, missing authentication conditions, and unmet timing constraints, the current verification path is switched to the vulnerability environment verification path to obtain the first update path. The execution plan is updated according to the first update path, and the vulnerability environment verification is performed based on the updated execution plan; If valid trigger information is obtained in the vulnerability environment verification, the valid trigger information is written back to the structured verification information to obtain the updated structured verification information; Based on the updated structured verification information, a protocol-independent sequence of verification steps for the security device verification path is regenerated.

[0051] In one embodiment, when the verification success condition and verification termination condition are not met, but the execution observation information meets the path switching condition, the system can update the execution plan and continue the verification. This process is particularly suitable for collaborative verification scenarios between the security device verification path and the vulnerability environment verification path.

[0052] Specifically, when the verification path in this round is the security device verification path, the system determines the rule hit status and the reason for the miss based on the execution observation information. The rule hit status can be determined based on security device alarm information, rule number, session identifier, traffic hit records, and time window matching results; the reason for the miss can be determined based on request and response, packet capture traffic, rule logs, test traffic construction process, and the completeness of structured verification information. For example, the reason for the miss may be related to incomplete trigger fields, missing authentication conditions, unmet timing constraints, insufficient request details, inconsistent protocol field encoding methods, or insufficient target rule matching conditions.

[0053] When a rule hit status indicates a failure to hit the target rule, and the reason for the failure is related to at least one of the following: incomplete trigger field, missing authentication conditions, or unmet timing constraints, the system switches the current verification path to the vulnerability environment verification path, obtaining the first update path. This step is used to further confirm the vulnerability triggering details and vulnerability effects through a real or simulated vulnerability verification environment when the security device verification cannot confirm a rule hit.

[0054] The system updates the execution plan according to the first update path and performs vulnerability environment verification based on the updated execution plan. The updated execution plan may include environment template matching, deployment configuration generation, environment startup, self-check, verification script execution, protocol interaction action execution, and vulnerability effect observation. Under the vulnerability environment verification path, the system can confirm valid trigger information through information such as response content, log changes, file status, database results, process status, and abnormal responses.

[0055] Once valid trigger information is obtained during vulnerability environment verification, the system writes this information back to the structured verification information, resulting in updated structured verification information. Valid trigger information may include key message fields, parameter value ranges, field encoding methods, authentication context, handshake order, time intervals, interaction rounds, expected response characteristics, and vulnerability side effects. After being written back, the structured verification information is updated from its incomplete state to a state more suitable for verification by security devices.

[0056] Finally, the system regenerates a protocol-independent verification step sequence for the security device verification path based on the updated structured verification information. The regenerated verification step sequence can be used to generate new test traffic, protocol messages, or multi-stage interaction sequences to re-execute the security device verification path and collect rule-hit verification evidence.

[0057] This embodiment switches to the vulnerability environment verification path when the security device verification fails and the cause of failure is attributable. It writes back the valid trigger information obtained from the environment verification to the structured verification information and then regenerates the verification step sequence of the security device verification path. This enables the two types of verification paths to form a collaborative closed loop, improving the rule verification hit rate and the automatic convergence capability of complex vulnerability reproduction verification.

[0058] In this embodiment, the step of obtaining candidate information related to the vulnerability reproduction and verification task based on the stateful task object, and filtering and structuring the candidate information to obtain structured verification information includes: The information retrieval conditions are determined based on the stateful task object, and the information retrieval conditions include at least one of the following: vulnerability identification conditions, product version conditions, protocol conditions, vulnerability type conditions, and source conditions. Based on the information retrieval conditions, multi-source candidate information is obtained, which includes at least one of the following: official announcements, patch differences, publicly available verification code, technical articles, code repositories, security device feature information, and historical verification samples. The multi-source candidate information is subjected to source normalization and content deduplication to obtain normalized candidate information; The standardized candidate information is subjected to relevance screening and conflict resolution to obtain the target candidate information; The target candidate information is structured and refined to obtain structured verification information including at least one of the following: preconditions, triggering actions, protocol elements, authentication conditions, timing constraints, expected responses, and vulnerability effects.

[0059] In one embodiment, the system acquires candidate information related to the vulnerability reproduction and verification task based on a stateful task object, and filters and structures the candidate information to obtain structured verification information. When obtaining structured verification information, the system can first determine information retrieval conditions based on the stateful task object. These information retrieval conditions may include at least one of vulnerability identifier conditions, product version conditions, protocol conditions, vulnerability type conditions, and source conditions. For example, the system can retrieve official announcements and vulnerability databases based on the vulnerability identifier, retrieve patch differences and version descriptions based on the product version, retrieve protocol interaction samples based on the protocol condition, retrieve historical verification samples of the same type based on the vulnerability type condition, and limit the source range of candidate information based on the source condition.

[0060] The system retrieves multi-source candidate information based on information retrieval criteria. This multi-source candidate information may include at least one of the following: official announcements, patch differences, publicly available verification code, technical articles, code repositories, security device characteristic information, and historical verification samples. Official announcements can be used to confirm the scope of vulnerability impact and affected versions; patch differences can be used to analyze changes in code logic before and after patching; publicly available verification code and technical articles can be used to obtain triggering conditions and request construction clues; code repositories can be used to confirm interfaces, parameters, protocol fields, or configuration requirements; security device characteristic information can be used to determine rule matching elements; and historical verification samples can be used to reuse verified environment configurations, verification steps, and evidence association methods.

[0061] After acquiring multi-source candidate information, the system performs source normalization and content deduplication on the multi-source candidate information to obtain normalized candidate information. Source normalization may include unified source identifier, unified timestamp, unified vulnerability identifier, unified product name, and unified version expression; content deduplication can be processed based on text similarity, code snippet similarity, field repetition relationship, and source reference relationship to reduce the interference of duplicate information on structured extraction.

[0062] Subsequently, the system performs relevance screening and conflict resolution on the standardized candidate information to obtain target candidate information. Relevance screening can be judged by combining vulnerability identifier matching, product version matching, protocol type matching, vulnerability type matching, and contextual semantic consistency. Conflict resolution can determine the content to be retained when there are inconsistencies in the affected version, trigger path, authentication conditions, parameter fields, or expected response from different sources, based on source credibility, release time, version correspondence, cross-validation results, and the validity of historical samples.

[0063] Finally, the system performs structured extraction of the target candidate information to obtain structured verification information. This structured verification information may include at least one of the following: preconditions, triggering actions, protocol elements, authentication conditions, timing constraints, expected responses, and vulnerability effects. Preconditions may represent the target product version, configuration conditions, or authentication status; triggering actions may represent requests, protocol interactions, or scripted verification actions that need to be executed; protocol elements may represent protocol type, request path, key fields, parameter patterns, encoding methods, or handshake order; timing constraints may represent the order of multi-stage interactions or waiting times; and expected responses and vulnerability effects are used to confirm subsequent verification results.

[0064] This embodiment determines information retrieval conditions based on task objects and performs source normalization, content deduplication, relevance filtering, conflict resolution, and structured extraction on multi-source candidate information. This can transform scattered and inconsistent vulnerability-related information into unified structured verification information, thereby improving the accuracy of subsequent verification step generation and path execution.

[0065] In this embodiment, the generation of a protocol-independent verification step sequence based on the structured verification information includes: Extract the preconditions, protocol elements, triggering actions, execution constraints, and expected observation results from the structured verification information; Based on the preconditions, protocol elements, triggering actions, execution constraints, and expected observation results, generate protocol-independent step description information; The verification step sequence is obtained by sorting the execution order and dependencies between the described steps. Each verification step in the verification step sequence includes at least one of the following: step identifier, protocol type, key field set, execution constraints, and expected observation results; Generate at least one of the following based on the verification step sequence: verification request, protocol message, test traffic, verification script, and multi-stage interaction sequence.

[0066] In one embodiment, when the system generates a protocol-independent verification step sequence based on structured verification information, it can first extract preconditions, protocol elements, triggering actions, execution constraints, and expected observations from the structured verification information. Preconditions may include target version, authentication status, configuration status, dependent service status, or environmental conditions; protocol elements may include protocol type, request path, command type, message fields, parameter pattern, encoding method, session identifier, or connection method; triggering actions may include sending a verification request, executing a verification script, establishing a protocol connection, submitting parameters, calling an interface, or performing a multi-stage interaction; execution constraints may include execution order, time interval, authentication context, field dependencies, and retry conditions; expected observations may include response content, status code, alarm records, log keywords, file status, database results, or process status.

[0067] The system generates protocol-independent step description information based on preconditions, protocol elements, triggering actions, execution constraints, and expected observations. Protocol independence means that the step description information is not limited to a single fixed protocol format, but rather uses a unified structure to describe verification actions under different protocols. For example, for HTTP interactions, the request path, request method, parameter fields, and expected response can be included in the step description information; for TCP or UDP interactions, connection information, message fields, sending order, and response characteristics can be included; for database protocols or RPC protocols, the authentication process, calling method, parameter fields, and return results can be included. Thus, the system can represent complex verification processes under different protocols in a unified way.

[0068] Next, the system sorts the steps according to their execution order and dependencies, resulting in a sequence of verification steps. The sorting can be based on the priority of preconditions, authentication actions, protocol handshake order, field dependencies, multi-stage interaction order, and expected observation order to determine the execution position of each step. For vulnerabilities requiring authentication before triggering, the authentication step precedes the triggering step; for vulnerabilities requiring data initialization before verification, the initialization step precedes the protocol interaction step; and for vulnerabilities requiring multiple rounds of interaction to trigger their effects, the system generates the corresponding order based on the number of interaction rounds.

[0069] Each verification step in the verification step sequence may include at least one of the following: step identifier, protocol type, key field set, execution constraints, and expected observation results. The step identifier distinguishes different verification steps; the protocol type identifies the protocol or interaction method corresponding to that step; the key field set records the path, parameters, message fields, authentication context, or environment variables; the execution constraints record the order, dependencies, time intervals, and retry conditions between steps; and the expected observation results are used to subsequently determine whether the execution has achieved the expected results.

[0070] Finally, the system generates at least one of the following based on the verification step sequence: verification request, protocol message, test traffic, verification script, and multi-stage interaction sequence. For security device verification paths, the system can generate test traffic based on the verification step sequence; for vulnerability environment verification paths, the system can generate verification scripts, command sequences, or multi-stage interaction actions based on the verification step sequence. If the execution result does not trigger the expected effect, the system can also adjust parameters, encoding, field order, authentication context, time interval, and interaction rounds based on packet capture information, log information, target response, and environment status, and regenerate the verification step sequence.

[0071] This embodiment abstracts structured verification information into protocol-independent step description information and forms a verification step sequence based on execution order and dependencies. This enables complex vulnerability verification processes with different protocols, different interaction rounds, and different triggering conditions to be uniformly expressed and automatically executed, thereby enhancing the adaptability to complex vulnerability scenarios.

[0072] In this embodiment, when the current verification path is a vulnerability environment verification path, executing the verification step sequence according to the current verification path includes: The target environment conditions are determined based on the stateful task object and the structured verification information. Match a reusable environment template based on the target environment conditions; If the reusable environment template is matched, a vulnerability verification environment is started based on the reusable environment template; If no reusable environment template is matched, environment deployment information is generated based on the target environment conditions, and a vulnerability verification environment is started based on the environment deployment information. Perform an availability self-test on the vulnerability verification environment and obtain the environment self-test results; If the environment self-test results indicate that the vulnerability verification environment is available, the vulnerability trigger verification action is executed based on the verification step sequence.

[0073] In one embodiment, when the current verification path is a vulnerability environment verification path, when the system executes the verification step sequence according to the current verification path, it can first determine the target environment conditions based on the stateful task object and structured verification information. The target environment conditions may include at least one of the following: target product name, target product version, component dependencies, operating system type, middleware version, database type, port exposure requirements, network topology, initialization data, configuration files, startup parameters, and authentication conditions. The target environment conditions are used to determine whether an existing environment can be reused or whether a new deployment configuration needs to be generated.

[0074] The system then matches a reusable environment template based on the target environment conditions. Reusable environment templates can include historical environment templates, container images, virtual machine images, orchestration manifests, initialization scripts, historical environment snapshots, or verified environment configurations. The system can perform template matching based on product name, version constraints, dependency structure, port mappings, service composition, and historical successful verification records. The matching result is used to determine whether the vulnerability verification environment can be directly started.

[0075] If a reusable environment template is matched, the system starts the vulnerability verification environment based on the reusable environment template. For example, the system can start the target service and its dependent services based on a container image, orchestration manifest, and initialization script, and load the corresponding configuration files and initialization data. After startup, the system can record the environment instance identifier, port mapping information, service status, and template source for subsequent execution of verification steps and archiving.

[0076] If no reusable environment template is found, the system generates environment deployment information based on the target environment conditions and starts the vulnerability verification environment based on this information. Environment deployment information may include deployment configurations, network parameters, port mappings, mount directories, database initialization scripts, service startup order, environment variables, configuration file parameters, and startup commands. The system can generate and start the vulnerability verification environment based on containerized resources, virtualized resources, or other isolated execution resources.

[0077] After the environment starts, the system performs an availability self-check on the vulnerability verification environment and obtains the self-check results. The availability self-check may include port listening checks, network connectivity checks, service fingerprinting, version string comparison, dependency connectivity checks, critical interface response checks, log keyword matching, critical process checks, and health check interface calls. The environment self-check results may indicate that the environment is available, unavailable, or that some conditions need to be corrected.

[0078] If the environment self-check results indicate that the vulnerability verification environment is available, the system executes vulnerability-triggered verification actions based on the verification step sequence. These actions may include sending a verification request, executing a verification script, executing a command sequence, performing protocol interactions, accessing interfaces, submitting parameters, or performing multi-stage interactions. During execution, the system collects information such as response content, log changes, file status, database results, process status, and abnormal responses to determine whether vulnerability effect verification evidence has been formed.

[0079] This embodiment determines the target environment conditions based on the task object and structured verification information, prioritizes matching reusable environment templates, and automatically generates environment deployment information and performs environment self-checks when no template is available. This enables the vulnerability environment verification path to automatically complete environment preparation and availability confirmation, thereby improving the construction efficiency and verification stability of complex vulnerability verification environments.

[0080] In this embodiment, the method further includes: If the environment self-test result indicates that the vulnerability verification environment is unavailable, obtain at least one of the following: startup log, exception information, and dependency status information corresponding to the vulnerability verification environment; The cause of environment failure is determined based on at least one of the startup log, the exception information, and the dependency status information. Generate environmental correction information based on the reasons for the environmental failure; The environment deployment information is updated based on the environment correction information to obtain the updated environment deployment information; Restart the vulnerability verification environment based on the updated environment deployment information and re-perform the availability self-test; If the number of times the availability self-check is repeated reaches a preset number, or if the cause of the environment failure does not meet the correctable conditions, an environment verification failure message is generated and written back to the stateful task object.

[0081] In one embodiment, if the environment self-test result indicates that the vulnerability verification environment is unavailable, the system obtains at least one of the following: startup logs, exception information, and dependency status information corresponding to the vulnerability verification environment. Startup logs may include container logs, service startup logs, system logs, middleware logs, database logs, or application logs; exception information may include error codes, exception stack traces, startup failure messages, interface return exceptions, or process exit information; dependency status information may include database connection status, middleware status, network connectivity status, port occupancy status, dependent service startup order, and configuration file loading status.

[0082] The system determines the cause of environment failure based on at least one of the following: startup logs, exception information, and dependency status information. Causes of environment failure may include image version mismatch, incorrect service startup order, missing environment variables, incorrect database account, initialization script execution failure, incorrect configuration file parameters, port conflicts, unreachable dependent services, inconsistent target versions, or unavailable critical interfaces. The system can also determine the cause of environment failure through log keyword matching, exception code mapping, dependency status comparison, and historical correction record matching.

[0083] Subsequently, the system generates environment correction information based on the cause of the environment failure. This correction information can include image tag correction, service startup order adjustment, environment variable completion, database account modification, initialization script correction, configuration file parameter adjustment, port mapping adjustment, dependent service restart, network topology adjustment, or version configuration adjustment. This correction information can serve as input for the next environment deployment, enabling the environment build process to have automatic correction capabilities.

[0084] The system updates the environment deployment information based on the environment correction information, resulting in updated environment deployment information. The updated environment deployment information can replace the original image tags, modify port mappings, add environment variables, adjust the startup order, update configuration files, supplement initialization scripts, or update dependent service parameters. Through this step, the reasons for environment failure are transformed into executable deployment corrections.

[0085] Afterwards, the system restarts the vulnerability verification environment based on the updated environment deployment information and performs a new availability self-check. During the re-self-check, the system can again perform port listening checks, version matching checks, dependency connectivity checks, log health checks, critical process checks, and critical interface response checks to confirm whether the environment fix is ​​effective. If the environment is available, the system proceeds to the vulnerability trigger verification action; if the environment is still unavailable, the system continues to determine whether the fix conditions or termination conditions are met.

[0086] If the number of availability self-checks performed reaches a preset number, or if the environment failure does not meet the correctable conditions, the system generates an environment verification failure message and writes it back to the stateful task object. The environment verification failure message may include attempted deployment configurations, corrective actions, failure reasons, unmet conditions, and reusable intermediate clues. After writing it back to the task object, the system can update the execution plan based on this failure message, such as switching back to the security device verification path, supplementing candidate information, or terminating the current task.

[0087] This embodiment automatically acquires logs, anomalies, and dependency states when the environment is unavailable, determines the cause of environment failure, generates environment correction information, and then redeploys and performs self-checks. At the same time, it sets correction termination conditions, which can reduce the manual repair cost in the process of building complex vulnerability environments, avoid invalid loop retries, and improve the success rate of environment construction and the controllability of system execution.

[0088] In one embodiment, a system and method for autonomously reproducing and verifying complex network vulnerabilities based on AIAgent are provided. The overall logic for Agent reproduction verification is as follows: Figure 2 As shown, the core modules of the system include: Task Status Recording Layer: Responsible for identifying vulnerability inputs, constructing stateful task objects, and maintaining historical execution records.

[0089] Feature and Condition Recognition Layer: Responsible for acquiring detection features, version constraints, authentication conditions, and environmental dependencies.

[0090] Planning layer: Responsible for generating execution plans and determining the current verification path.

[0091] Intelligence fusion layer: responsible for accessing information from multiple sources, performing correlation screening, and extracting structured information.

[0092] Action construction layer: responsible for generating protocol-independent exploitation step sequences as well as candidate payloads, PoCs, or interaction sequences.

[0093] Path execution layer: responsible for executing security device verification paths or vulnerability environment verification paths.

[0094] Observation and Analysis Layer: Responsible for collecting traffic, logs, and environmental status, and analyzing the results.

[0095] Archive storage layer: responsible for storing the final script, traffic, environment configuration, evidence association conclusions, and execution summary.

[0096] The specific logical steps are as follows: Step S101: Receiving Vulnerability Input and Instantiating Task Object The system receives the CVE number, vulnerability name, product version, vulnerability description or reference link, performs entity identification and field normalization on the input, and generates a stateful task object T.

[0097] Step S102: Feature and Condition Recognition The system queries the security device detection characteristics, target product version, certification conditions, environmental dependencies, and historical execution context, and writes the relevant constraints into the task object.

[0098] Step S103: Initial Planning and Path Selection Based on the detection features in the task object, the completeness of the structured utilization information, environmental conditions, and historical execution results, the system generates an execution plan that includes the target path, a list of candidate information sources, a tool call sequence, and switching conditions.

[0099] Step S104: Acquisition of multi-source intelligence and source standardization The system obtains official announcements, patch differences, public PoCs, technical articles, code repositories, and security device characteristic information, and converts them into processable text, code snippets, or structured objects.

[0100] Step S105: Relevance Screening and Structured Information Extraction The system performs deduplication, topic consistency checks, and conflict resolution on candidate intelligence, extracting preconditions, triggering actions, protocol elements, authentication context, timing constraints, expected responses, and vulnerability effects to form a structured exploitation information set.

[0101] Step S106: Protocol-independent generation using step sequence The system constructs a sequence of exploitation steps based on structured exploitation information and generates one or more candidate payloads, PoC scripts, or interaction sequences.

[0102] Step S107: Execution of security device verification path If the current plan selects the security device verification path, the system will initiate test traffic according to the exploitation step sequence and simultaneously collect request responses, packet capture traffic, rule hit logs, and session identifiers.

[0103] Step S108: Execution of the vulnerability environment verification path If the current plan selects the vulnerability environment verification path, the system will prioritize reusing the template environment; if no template can be reused, the system will automatically generate the deployment configuration and start the environment, and then perform environment self-checks and PoC / interactive actions.

[0104] Step S109: Environmental self-check and automatic correction When a self-check in the environment path fails, the system automatically generates a corrective plan and redeploys it based on logs, error codes, and dependency status.

[0105] Step S110: Observation Feedback and Evidence Collection The system aggregates request responses, rule hits, packet captures, container logs, system logs, process status, file changes, and database changes to form the evidence object for the current round and writes it back to the historical execution record.

[0106] Step S111: Result Analysis and Path Switching Decision The system analyzes the results of the current round by combining rule hits, vulnerability effects, environment status, and execution logs. If it can be confirmed that the security device verification or vulnerability effect verification is successful, the task ends. If there are still factors that can be corrected, the current path optimization continues or the system switches to another verification path. Otherwise, a failure conclusion is output.

[0107] Step S112: Unified archiving output The system archives vulnerability basic information, intelligence sources, structured exploitation information, final payload, PoC script, environment configuration, packet capture files, logs, evidence correlation conclusions, failure reasons, and execution summaries in a unified manner.

[0108] The logic of planning, route switching, and environmental modification is as follows: Figure 3 As shown, the core modules include: Candidate Information Access Unit: Responsible for importing official announcements, patch differences, public PoCs, technical blogs, code repositories, security device characteristic information, and historical execution records.

[0109] The information fusion unit is responsible for performing structured extraction and conflict resolution to generate an executable set of exploitable information.

[0110] The plan generation unit is responsible for generating an execution plan based on the task status and the set of information, selecting a verification path, and defining rollback conditions.

[0111] Environment processing unit: responsible for template matching, deployment configuration generation, environment startup, self-check, and log-driven correction.

[0112] Action Execution Unit: Responsible for packet verification, script execution, protocol interaction, and observation data collection.

[0113] Historical record update unit: responsible for writing the results of this round, failure attribution, correction strategies and valid clues back to the historical execution record.

[0114] Results Analysis Unit: Responsible for outputting final conclusions or next round of decision-making recommendations based on multiple types of observation results.

[0115] The specific logical steps are as follows: Step S201: Importing Candidate Intelligence The system imports official announcements, patch differences, public PoCs, technical articles, code repositories, and security device characteristic information, and establishes a candidate pool.

[0116] Step S202: Utilizing information fusion The system performs deduplication, topic consistency analysis, version matching judgment, and cross-consistency verification on the candidate pool, and generates a structured set of exploitation information.

[0117] Step S203: Execution Plan Generation The planning unit generates an execution plan based on the information set, historical execution records, and current conditions. The execution plan includes at least the target set, the current path, the tool call sequence, the candidate information source list, the rollback conditions, and the switching conditions.

[0118] Step S204: Path Selection The system determines the priority verification path based on current observations, the completeness of information utilized, and environmental conditions, and records the switching conditions in the plan.

[0119] Step S205: Template matching or deployment configuration generation If a vulnerability environment verification path is selected, a reusable environment template will be matched first; if the template is unavailable, deployment configuration, network parameters, initialization scripts and startup instructions will be automatically generated.

[0120] Step S206: Environment Startup and Availability Self-Check The system starts the target environment and performs port listening, version matching, dependency connectivity, log health, and critical process and interface response checks to confirm whether the environment meets the vulnerability triggering conditions.

[0121] Step S207: Log-driven fix If the environment still does not meet the operating requirements, the system performs cluster analysis on the startup logs, exception codes, and dependent service status, automatically generates corrective actions, and returns to step S205 for redeployment.

[0122] Step S208: Execute and collect observations using the step sequence. The system executes packet sending, script calls, or multi-stage protocol interactions according to the sequence of steps, and simultaneously collects packet captures, rule hits, response data, file changes, database changes, and log records.

[0123] Step S209: Write back historical execution records and replan The system writes the valid clues, failure attributions, correction strategies, and evidence objects of this round back to the historical execution record, and generates the next round execution plan when necessary.

[0124] Step S210: Output and Archiving of Results Once the termination conditions are met or sufficient evidence is formed, the system outputs the final conclusion and archives the final script, traffic, environment configuration, evidence association conclusion, and execution summary in a unified manner.

[0125] The output results include: when the task is successful, the system outputs the final payload, PoC script, environment configuration, packet capture file, log evidence, and conclusion.

[0126] When a task fails, the system outputs the attempted paths, reasons for failure, unmet conditions, and reusable intermediate clues, facilitating subsequent re-execution or manual review.

[0127] At the end of the task, the system archives the final script, verification traffic, environment configuration, observation logs, and execution summary.

[0128] The AI ​​Agent in this embodiment is only an exemplary implementation. In other embodiments, the corresponding functions can also be implemented using a rule engine, workflow orchestration engine, task scheduling module, or automated decision-making component.

[0129] In one embodiment, a system for autonomously reproducing and verifying complex network vulnerabilities is provided, comprising: The task object construction module is used to obtain the input information of the vulnerability reproduction and verification task, parse and process the input information, and generate a stateful task object. The stateful task object is used to record the basic vulnerability information, verification condition information, path status, historical execution records, and evidence status. The information processing module is used to obtain candidate information related to the vulnerability reproduction and verification task based on the stateful task object, and to filter and structure the candidate information to obtain structured verification information. The planning module is used to generate an execution plan based on the stateful task object, the structured verification information, and the historical execution records. The execution plan includes the current verification path and path switching conditions. The current verification path includes a security device verification path or a vulnerability environment verification path. The step generation module is used to generate a protocol-independent verification step sequence based on the structured verification information. The verification step sequence is used to generate at least one of the following: verification request, protocol message, test traffic, verification script, and multi-stage interaction sequence. The verification execution module includes a security device verification submodule and a vulnerability environment verification submodule. The security device verification submodule is used to collect rule-hit verification evidence according to the verification step sequence when the current verification path is a security device verification path. The vulnerability environment verification submodule is used to collect vulnerability effect verification evidence according to the verification step sequence when the current verification path is a vulnerability environment verification path. The observation feedback module is used to collect execution observation information generated during the execution of the verification step sequence and write the execution observation information back to the stateful task object; The result determination module is used to determine whether the verification success condition or the verification termination condition is met based on the execution observation information and the evidence status, and to determine the verification result if the verification success condition or the verification termination condition is met. The observation feedback module is connected to the planning module. The planning module is also used to update the execution plan and trigger the verification execution module to continue the verification if the verification success condition and the verification termination condition are not met, and the execution observation information meets the path switching condition. The archiving module is used to archive the verification results and the evidence information associated with the verification results.

[0130] The specific implementation details of each module can be found in the above description of the limitations of the method for autonomous reproduction and verification of complex network vulnerabilities, and will not be repeated here.

[0131] In one embodiment, this application also provides a system for autonomous reproduction and verification of complex network vulnerabilities. This system can be deployed on servers, security verification platforms, vulnerability analysis platforms, target range management platforms, cloud computing platforms, or enterprise security operation platforms. The system can utilize a containerized execution environment, a virtualized execution environment, or a combination of both to form its runtime environment, enabling different vulnerability reproduction and verification tasks to be executed in relatively isolated and reusable runtime environments. The system can use stateful task objects as the core of data flow and form a closed-loop processing mechanism through task state-driven planning, tool invocation, path execution, observation feedback, and result archiving.

[0132] In one implementation, the autonomous reproduction and verification system for complex network vulnerabilities includes a task object construction module, an information processing module, a planning module, a step generation module, a verification execution module, an observation feedback module, a result determination module, and an archiving module. Furthermore, the system can also configure task status recording units, feature and condition recognition units, intelligence fusion units, tool collaboration units, dynamic environment construction and self-checking units, multi-protocol exploitation construction units, execution observation and path switching units, and evidence archiving units within each module to achieve input parsing, status recording, information extraction, plan generation, environment construction, verification execution, result confirmation, and evidence accumulation during the reproduction and verification process of complex network vulnerabilities.

[0133] The task object construction module is used to acquire input information for vulnerability reproduction and verification tasks, and parse and process the input information to generate a stateful task object. The input information may include at least one of the following: vulnerability identifier, vulnerability name, target product information, version information, vulnerability description, and reference information. The task object construction module can perform entity recognition, field extraction, format unification, and field normalization processing on the input information, transforming raw inputs such as CVE number, vulnerability name, product name, affected version, vulnerability description, reference link, or historical verification context into unified task data. The stateful task object is used to record basic vulnerability information, verification condition information, path status, historical execution records, and evidence status. Specifically, basic vulnerability information may include vulnerability identifier, product components, version constraints, and vulnerability type; verification condition information may include protocol type, authentication constraints, environment dependencies, and detection feature status; path status may indicate whether the current state is pending planning, a security device verification path, or a vulnerability environment verification path; historical execution records may save request summaries, environment status, failure reasons, corrective actions, valid clues, and evidence objects; evidence status may indicate whether rule-hit verification evidence, vulnerability effect verification evidence, or failure reason evidence has been formed.

[0134] In one implementation, the task object construction module may further include a task input and status recording unit and a feature and condition recognition unit. The task input and status recording unit receives input information from vulnerability reproduction and verification tasks and creates, saves, and updates stateful task objects. The feature and condition recognition unit identifies detection features, version constraints, authentication conditions, protocol types, and environmental dependencies based on the input information and candidate information, and writes the recognition results into the stateful task object. Through this structure, the system can uniformly incorporate different task types, such as those with and without vulnerability identifiers, known and unknown verification code, and single and multiple protocols, into the same state management link.

[0135] The information processing module is used to acquire candidate information related to the vulnerability reproduction and verification task based on stateful task objects, and to filter and structure this candidate information to obtain structured verification information. Candidate information can come from at least one of the following: official announcements, patch differences, publicly available verification code, vulnerability databases, technical articles, source code repositories, security device characteristic information, and historical verification samples. The information processing module can perform source normalization, content deduplication, relevance filtering, topic consistency judgment, version matching judgment, and conflict resolution on the candidate information to obtain target candidate information. Subsequently, the information processing module performs structured extraction on the target candidate information to obtain structured verification information including at least one of the following fields: preconditions, triggering actions, protocol elements, authentication conditions, timing constraints, expected response, vulnerability effect, and evidence association fields.

[0136] In one implementation, the information processing module may include an intelligence fusion unit and a tool coordination unit. The intelligence fusion unit is used to access multi-source candidate information and organize the candidate information based on source credibility, version matching, and cross-consistency. The tool coordination unit is used to coordinate at least one of the following tools according to the execution plan generated by the planning module: search tools, code retrieval tools, patch comparison tools, container deployment tools, packet capture tools, log parsing tools, script execution tools, network packet sending tools, and environment observation tools, to support candidate information acquisition, structured extraction, environment processing, verification execution, and evidence collection. Through the cooperation of the information processing module and the tool coordination unit, the system can transform scattered vulnerability information into subsequently executable and verifiable structured verification information.

[0137] The planning module generates an execution plan based on stateful task objects, structured verification information, and historical execution records. The execution plan includes the current verification path and path switching conditions. The current verification path can be either a security device verification path or a vulnerability environment verification path. The planning module can determine the current verification path based on the availability of detection features, the completeness of verification conditions, the buildability of the environment, the completeness of triggering conditions, the complexity of protocol interactions, and historical execution records. For example, if the detection features are relatively complete and can verify security device rules through test traffic, the planning module can determine the current verification path to be a security device verification path; if it is necessary to observe vulnerability effects such as command execution, file writing, database changes, abnormal responses, or process states, the planning module can determine the current verification path to be a vulnerability environment verification path.

[0138] The planning module is also used to set path switching and rollback conditions. Path switching conditions can include rule misses, incomplete trigger fields, missing authentication conditions, unmet timing constraints, unavailable environment, valid trigger information already obtained, or evidence objects failing to form a valid association. Rollback conditions can include continuous failure to correct the current path, incomplete key fields, unmet environmental dependencies, or reaching a preset limit on the number of iterations. After each round of execution, the planning module can receive execution observation information written back by the observation feedback module and regenerate the execution plan based on the updated task objects, enabling the system to adjust the verification path and verification strategy according to new observation results during execution.

[0139] The step generation module generates a protocol-independent sequence of verification steps based on structured verification information. This sequence generates at least one of the following: verification request, protocol message, test traffic, verification script, and multi-stage interaction sequence. Specifically, the step generation module extracts preconditions, protocol elements, triggering actions, execution constraints, and expected observations from the structured verification information and abstracts them into unified step description information. Each verification step may include at least one of the following: step identifier, protocol type, key field set, execution constraints, and expected observations. For HTTP, HTTPS, TCP, UDP, RPC, database protocols, or multi-stage interaction protocols, the step generation module can generate corresponding verification actions based on the unified step description information.

[0140] In one implementation, the step generation module may include a multi-protocol exploitation construction unit. This unit generates or adjusts verification requests, protocol messages, test traffic, verification scripts, candidate payloads, or multi-stage interaction sequences based on the verification step sequence. For vulnerability verification processes requiring multiple rounds of authentication, handshakes, parameter submissions, or callback confirmations, the multi-protocol exploitation construction unit can organize multiple verification actions according to the execution order and dependencies between verification steps. If the execution result does not trigger the expected observation result, the multi-protocol exploitation construction unit can also adjust parameters, encoding methods, field order, authentication context, time interval, or interaction rounds based on packet capture information, log information, target response, and environment status collected by the observation feedback module, and regenerate the verification step sequence.

[0141] The verification execution module includes a security device verification submodule and a vulnerability environment verification submodule. The security device verification submodule, when the current verification path is a security device verification path, collects rule-hit verification evidence according to the verification step sequence. Specifically, the security device verification submodule can generate test traffic or protocol packets based on the verification step sequence and initiate interaction with the target verification link, while simultaneously collecting request responses, packet captures, security device alarms, rule numbers, session identifiers, and time window information. Based on this information, the system can determine whether the test traffic hits the target security device rules and generate rule-hit verification evidence.

[0142] The vulnerability environment verification submodule is used to collect vulnerability effect verification evidence according to the verification step sequence when the current verification path is the vulnerability environment verification path. Specifically, the vulnerability environment verification submodule can call an existing vulnerability verification environment, or it can construct a new vulnerability verification environment based on structured verification information and stateful task objects. After the environment is available, the vulnerability environment verification submodule executes verification scripts, command sequences, protocol interaction actions, or multi-stage interaction sequences, and determines whether the vulnerability effect has occurred based on information such as response content, container logs, system logs, file status, database results, process status, abnormal responses, and service status changes.

[0143] In one implementation, the vulnerability environment verification submodule may include a dynamic environment construction and self-testing unit. This unit, upon entering the vulnerability environment verification path, prioritizes matching reusable environment templates, container images, virtual machine images, orchestration manifests, initialization scripts, or historical environment snapshots. If no directly reusable environment exists, it generates environment deployment information based on the target product version, dependent services, exposed ports, network topology, mount directories, database initialization, configuration files, environment variables, and startup parameters. After the environment starts, the dynamic environment construction and self-testing unit performs availability self-tests on the vulnerability verification environment through methods such as port listening checks, network connectivity checks, service fingerprinting, version string comparison, dependency connectivity checks, key interface response checks, log keyword matching, key process checks, and health check interface calls.

[0144] If the environment self-test results indicate that the vulnerability verification environment is unavailable, the dynamic environment construction and self-test unit can also obtain startup logs, exception information, and dependency status information, and determine the cause of environment failure based on these information. Causes of environment failure may include image version mismatch, incorrect service startup order, missing environment variables, incorrect database account, failed initialization script, incorrect configuration file parameters, port conflicts, unreachable dependent services, or inconsistent target versions. The dynamic environment construction and self-test unit generates environment correction information based on the cause of environment failure, updates the environment deployment information based on the correction information, restarts the vulnerability verification environment, and re-executes the self-test. If the number of re-self-tests reaches a preset number or the cause of environment failure does not meet the correctable conditions, the dynamic environment construction and self-test unit generates environment verification failure information and provides this information to the observation and feedback module to write back the stateful task object.

[0145] The observation and feedback module is used to collect execution observation information generated during the execution of the verification step sequence and write the execution observation information back to the task object with status. The execution observation information may include at least one of the following: request / response information, traffic information, rule hit information, log information, environment status information, vulnerability effect information, failure reason information, and valid clue information. During each round of execution, the observation and feedback module can synchronously collect request / response data, packet capture traffic, security device alarms, rule numbers, session identifiers, container logs, system logs, process status, file changes, and database changes, and write the execution summary, environment status, failure reason, corrective actions, valid clues, and evidence objects of the current round into the historical execution record.

[0146] The observation feedback module is connected to the planning module. The planning module can update the execution plan based on the execution observation information written back by the observation feedback module. For example, if the security device verification path fails to hit the target rule and the reason for the failure is related to incomplete trigger fields, missing authentication conditions, or unmet timing constraints, the planning module can switch the current verification path to the vulnerability environment verification path. After the vulnerability environment verification path confirms valid trigger information, the observation feedback module can write back the key message fields, authentication context, parameter constraints, timing relationships, and expected responses to the structured verification information, and the planning module can then regenerate the execution plan for the security device verification path based on this information. Through the above connection, the system can achieve closed-loop collaboration between execution observation, task status updates, and path replanning.

[0147] The result determination module is used to determine whether the verification success conditions or verification termination conditions are met based on the execution observation information and evidence status, and to determine the verification result if the verification success conditions or verification termination conditions are met. Verification success conditions can include security device verification success conditions and vulnerability effect verification success conditions. Security device verification success conditions can be determined based on the correlation between rule hits, rule numbers, session identifiers, test traffic, and time windows; vulnerability effect verification success conditions can be determined based on the correlation between response content, log changes, file changes, database changes, process status, environment status, and vulnerability side effects. Verification termination conditions can include situations where continuous corrections still fail to meet the environment triggering prerequisites, key fields cannot be completed, evidence objects cannot form a valid correlation, or the number of iterations reaches a preset limit.

[0148] The results determination module can also jointly verify multiple types of evidence. When a single piece of evidence is insufficient to form a conclusion, the results determination module can make a comprehensive judgment by combining the combined relationships between rule hit information, traffic evidence, time windows, session identifiers, vulnerability side effects, environmental states, and log records. For tasks that fail to be verified, the results determination module can output the attempted paths, key reasons for failure, unmet technical prerequisites, and reusable intermediate clues for subsequent re-execution or manual review.

[0149] The archiving module is used to archive verification results and related evidence information. It can save basic vulnerability information, candidate information sources, structured verification information, final verification requests, protocol messages, test traffic, verification scripts, environment deployment information, environment remediation records, packet capture files, log information, rule hit records, vulnerability effect evidence, evidence association conclusions, failure reasons, and execution summaries. The archiving module can also generate an archiving identifier for each reproduction verification task and write the identifier back to the stateful task object. For successful verification tasks, the archiving module can save the final payload, verification script, environment configuration, and conclusion description; for unsuccessful verification tasks, the archiving module can save attempted paths, unmet conditions, failure reasons, and reusable intermediate clues.

[0150] In one implementation, the system can form an initial task object through a task object construction module, generate structured verification information through an information processing module, determine the verification path for the current round through a planning module, generate a protocol-independent sequence of verification steps through a step generation module, execute the security device verification path or the vulnerability environment verification path through a verification execution module, write the execution observation information back to the task object through an observation feedback module, determine the verification result through a result determination module, and save the verification result and evidence information through an archiving module. Data is transferred between the modules through stateful task objects and execution plans, enabling the system to replan, switch paths, or adjust the environment based on new observation information after each round of execution.

[0151] This embodiment sets up a task object construction module, information processing module, planning module, step generation module, verification execution module, observation feedback module, result determination module, and archiving module at the system level. It further configures a security device verification submodule, a vulnerability environment verification submodule, a dynamic environment construction and self-testing unit, and a tool collaboration unit. This enables the system to operate on a containerized or virtualized execution environment as its foundation, forming a closed-loop processing process around stateful task objects, from input parsing, information fusion, plan generation, step construction, dual-path verification, execution observation, path replanning, environment correction, result confirmation, to evidence archiving. This reduces the reliance on human experience for complex network vulnerability reproduction verification, improves environment adaptability, path coverage, and execution stability in complex vulnerability scenarios, and enhances the traceability, verifiability, and reusability of verification results by uniformly storing verification evidence and execution summaries.

[0152] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

Claims

1. A method for autonomously reproducing and verifying complex network vulnerabilities, characterized in that, The method includes: Obtain the input information for the vulnerability reproduction and verification task; The input information is parsed and processed to generate a stateful task object. The stateful task object is used to record basic vulnerability information, verification condition information, path status, historical execution records, and evidence status. Based on the stateful task object, candidate information related to the vulnerability reproduction and verification task is obtained, and the candidate information is filtered and structured to obtain structured verification information. An execution plan is generated based on the stateful task object, the structured verification information, and the historical execution records. The execution plan includes the current verification path and path switching conditions. The current verification path includes a security device verification path or a vulnerability environment verification path. Based on the structured verification information, a protocol-independent verification step sequence is generated. The verification step sequence is used to generate at least one of the following: verification request, protocol message, test traffic, verification script, and multi-stage interaction sequence. The verification step sequence is executed according to the current verification path to collect rule hit verification evidence under the security device verification path, or vulnerability effect verification evidence under the vulnerability environment verification path. Collect execution observation information generated during the execution of the verification step sequence, and write the execution observation information back to the stateful task object; Determine whether the verification success condition or the verification termination condition is met based on the execution observation information and the evidence status. If the verification success condition or the verification termination condition is met, the verification result is determined; If the verification success condition and the verification termination condition are not met, and the execution observation information meets the path switching condition, the execution plan is updated and the verification continues. The verification results and the evidence information associated with the verification results are archived.

2. The method for autonomous reproduction and verification of complex network vulnerabilities according to claim 1, characterized in that, The step of parsing and processing the input information to generate a stateful task object includes: Entity recognition is performed on the input information to obtain at least one of vulnerability entity information, product entity information, version entity information, and external reference information. At least one of the vulnerability entity information, the product entity information, the version entity information, and the external reference information is subjected to field normalization processing to obtain a normalized field set; The vulnerability basic information and verification condition information are determined based on the normalized field set; The stated task object is obtained by initializing the path state, historical execution records, and evidence state based on the vulnerability basic information and the verification condition information.

3. The method for autonomous reproduction and verification of complex network vulnerabilities according to claim 2, characterized in that, The method further includes: After each round of verification is completed, obtain at least one of the following: execution summary, environment status, failure reason, valid clues, and evidence object corresponding to this round of verification; Generate the current round history based on at least one of the execution summary, the environment state, the failure reason, the valid clues, and the evidence object; Write the current round history into the historical execution record of the stateful task object to obtain the updated task object; The next round of execution plan is generated based on the updated task object, and the candidate information and verification path required for the next round of verification are determined according to the next round of execution plan.

4. The method for autonomous reproduction and verification of complex network vulnerabilities according to claim 1, characterized in that, The step of generating an execution plan based on the stateful task object, the structured verification information, and the historical execution records includes: The state of the detection feature availability, the state of the verification condition completeness, and the state of the environment buildability are determined based on the state of the task object. The completeness of the triggering conditions and the complexity of the protocol interaction are determined based on the structured verification information. Based on the historical execution records, determine the executed paths, reasons for failure, and reusable clues; The current verification path and path switching conditions are determined based on at least one of the following: the availability status of the detection features, the completeness status of the verification conditions, the constructability status of the environment, the completeness of the triggering conditions, the complexity of the protocol interaction, the executed path, the reason for failure, and the reusable clues. The execution plan is generated based on the current verification path and the path switching conditions.

5. The method for autonomous reproduction and verification of complex network vulnerabilities according to claim 4, characterized in that, The step of updating the execution plan and continuing the verification process when the verification success condition and the verification termination condition are not met, and the execution observation information meets the path switching condition, includes: If the verification path in this round is a security device verification path, the rule hit status and the reason for the miss are determined based on the execution observation information; When the rule hit status indicates that the target rule has not been hit, and the reason for the miss is related to at least one of the following: incomplete trigger field, missing authentication conditions, and unmet timing constraints, the current verification path is switched to the vulnerability environment verification path to obtain the first update path. The execution plan is updated according to the first update path, and the vulnerability environment verification is performed based on the updated execution plan; If valid trigger information is obtained in the vulnerability environment verification, the valid trigger information is written back to the structured verification information to obtain the updated structured verification information; Based on the updated structured verification information, a protocol-independent sequence of verification steps for the security device verification path is regenerated.

6. The method for autonomous reproduction and verification of complex network vulnerabilities according to claim 1, characterized in that, The process involves obtaining candidate information related to the vulnerability reproduction and verification task based on the stateful task object, and then filtering and structuring the candidate information to obtain structured verification information, including: The information retrieval conditions are determined based on the stateful task object, and the information retrieval conditions include at least one of the following: vulnerability identification conditions, product version conditions, protocol conditions, vulnerability type conditions, and source conditions. Based on the information retrieval conditions, multi-source candidate information is obtained, which includes at least one of the following: official announcements, patch differences, publicly available verification code, technical articles, code repositories, security device feature information, and historical verification samples. The multi-source candidate information is subjected to source normalization and content deduplication to obtain normalized candidate information; The standardized candidate information is subjected to relevance screening and conflict resolution to obtain the target candidate information; The target candidate information is structured and refined to obtain structured verification information including at least one of the following: preconditions, triggering actions, protocol elements, authentication conditions, timing constraints, expected responses, and vulnerability effects.

7. The method for autonomous reproduction and verification of complex network vulnerabilities according to claim 6, characterized in that, The generation of a protocol-independent verification step sequence based on the structured verification information includes: Extract the preconditions, protocol elements, triggering actions, execution constraints, and expected observation results from the structured verification information; Based on the preconditions, protocol elements, triggering actions, execution constraints, and expected observation results, generate protocol-independent step description information; The verification step sequence is obtained by sorting the execution order and dependencies between the described steps. Each verification step in the verification step sequence includes at least one of the following: step identifier, protocol type, key field set, execution constraints, and expected observation results; Generate at least one of the following based on the verification step sequence: verification request, protocol message, test traffic, verification script, and multi-stage interaction sequence.

8. The method for autonomous reproduction and verification of complex network vulnerabilities according to claim 1, characterized in that, When the current verification path is a vulnerability environment verification path, the step of executing the verification step sequence according to the current verification path includes: The target environment conditions are determined based on the stateful task object and the structured verification information. Match a reusable environment template based on the target environment conditions; If the reusable environment template is matched, a vulnerability verification environment is started based on the reusable environment template; If no reusable environment template is matched, environment deployment information is generated based on the target environment conditions, and a vulnerability verification environment is started based on the environment deployment information. Perform an availability self-test on the vulnerability verification environment and obtain the environment self-test results; If the environment self-test results indicate that the vulnerability verification environment is available, the vulnerability trigger verification action is executed based on the verification step sequence.

9. The method for autonomous reproduction and verification of complex network vulnerabilities according to claim 8, characterized in that, The method further includes: If the environment self-test result indicates that the vulnerability verification environment is unavailable, obtain at least one of the following: startup log, exception information, and dependency status information corresponding to the vulnerability verification environment; The cause of environment failure is determined based on at least one of the startup log, the exception information, and the dependency status information. Generate environmental correction information based on the reasons for the environmental failure; The environment deployment information is updated based on the environment correction information to obtain the updated environment deployment information; Restart the vulnerability verification environment based on the updated environment deployment information and re-perform the availability self-test; If the number of times the availability self-check is repeated reaches a preset number, or if the cause of the environment failure does not meet the correctable conditions, an environment verification failure message is generated and written back to the stateful task object.

10. A system for autonomously reproducing and verifying complex network vulnerabilities, characterized in that, The system includes: The task object construction module is used to obtain the input information of the vulnerability reproduction and verification task, parse and process the input information, and generate a stateful task object. The stateful task object is used to record the basic vulnerability information, verification condition information, path status, historical execution records, and evidence status. The information processing module is used to obtain candidate information related to the vulnerability reproduction and verification task based on the stateful task object, and to filter and structure the candidate information to obtain structured verification information. The planning module is used to generate an execution plan based on the stateful task object, the structured verification information, and the historical execution records. The execution plan includes the current verification path and path switching conditions. The current verification path includes a security device verification path or a vulnerability environment verification path. The step generation module is used to generate a protocol-independent verification step sequence based on the structured verification information. The verification step sequence is used to generate at least one of the following: verification request, protocol message, test traffic, verification script, and multi-stage interaction sequence. The verification execution module includes a security device verification submodule and a vulnerability environment verification submodule. The security device verification submodule is used to collect rule-hit verification evidence according to the verification step sequence when the current verification path is a security device verification path. The vulnerability environment verification submodule is used to collect vulnerability effect verification evidence according to the verification step sequence when the current verification path is a vulnerability environment verification path. The observation feedback module is used to collect execution observation information generated during the execution of the verification step sequence and write the execution observation information back to the stateful task object; The result determination module is used to determine whether the verification success condition or the verification termination condition is met based on the execution observation information and the evidence status, and to determine the verification result if the verification success condition or the verification termination condition is met. The observation feedback module is connected to the planning module. The planning module is also used to update the execution plan and trigger the verification execution module to continue the verification if the verification success condition and the verification termination condition are not met, and the execution observation information meets the path switching condition. The archiving module is used to archive the verification results and the evidence information associated with the verification results.

Images