Fragile environment construction method and device, equipment, storage medium and product

Abstract

The application relates to the technical field of multi-agent, and discloses a fragile environment construction method and device, equipment, a storage medium and a product, which comprise the following steps: acquiring a project warehouse address of a target project; based on the project warehouse address, analyzing a source code warehouse corresponding to the project warehouse address by a planning domain agent, and generating an environment construction blueprint; based on an execution domain agent, generating an executable command sequence according to the environment construction blueprint, and executing the executable command sequence in an isolated environment to obtain a fragile environment. Through the setting of the double-domain architecture of separating the planning domain and the execution domain, the planning responsibility and the execution responsibility of the fragile environment construction task are respectively assumed by different function domains, the problems of context window over-limit and reasoning error rate increase caused by a single agent simultaneously assuming multiple heterogeneous tasks such as analysis, planning and execution are avoided, and therefore, the automatic construction of the fragile environment with high success rate and low cost is realized.

Description

Technical Field

[0001] This application relates to the field of multi-agent technology, and in particular to a method, apparatus, device, storage medium and product for constructing fragile environments. Background Technology

[0002] Existing automation solutions, in the process of rebuilding fragile environments, typically assign heterogeneous tasks such as source code structure analysis, dependency resolution, build command generation, service startup and verification to a single or a few agents. This makes the context window of a single agent very easy to exceed the limit, and errors and tool call timeouts frequently occur during inference. Furthermore, failure of local steps can easily trigger a global cascading crash, requiring the entire build process to be retried from the beginning. When facing large, complex, or poorly documented open source projects, the failure rate remains high. Summary of the Invention

[0003] The main objective of this application is to provide a method, apparatus, device, storage medium, and product for constructing fragile environments, aiming to solve the technical problems of existing automated solutions where the context window of a single intelligent agent is easily exceeded during the reconstruction of fragile environments, and errors and tool call timeouts frequently occur during inference.

[0004] To achieve the above objectives, this application proposes a method for constructing a fragile environment, the method comprising: Obtain the project repository address of the target project; Based on the project repository address, the source code repository corresponding to the project repository address is analyzed by the planning domain agent to generate an environment construction blueprint; Based on the execution domain agent, an executable command sequence is generated according to the environment blueprint, and the executable command sequence is executed in an isolated environment to obtain a fragile environment.

[0005] Optionally, the planning domain agent includes a structure analysis agent, a dependency resolution agent, and a blueprint generation agent; The step of analyzing the source code repository corresponding to the project repository address using a planning domain agent to generate an environment construction blueprint based on the project repository address includes: The structure analysis agent parses the source code repository to generate structured project metadata. The dependency resolution agent generates a list of dependency constraints for the target project based on the project metadata and the vulnerability identifier information corresponding to the target project. The intelligent agent is generated through the blueprint, and the environment construction blueprint is generated based on the dependency constraint list and the project meta information.

[0006] Optionally, before generating the environment construction blueprint based on the dependency constraint list and the project metadata, the process further includes: The agent is generated using the blueprint, and the repository skill library is retrieved using the project repository address as an index to obtain the historical construction blueprint of the source code repository; Accordingly, the step of generating an intelligent agent through the blueprint, based on the dependency constraint list and the project metadata, to generate the environment construction blueprint includes: The intelligent agent is generated by the blueprint, which integrates the dependency constraint list, the project metadata, and the historical build blueprint to generate an environment build blueprint.

[0007] Optionally, the execution domain agent includes a command generation agent and an execution verification agent; The execution domain-based intelligent agent generates an executable command sequence based on the environment blueprint, and executes the executable command sequence in an isolated environment to obtain a vulnerable environment, including: Based on the command, an intelligent agent is generated, which parses the operation types declared in the environment construction blueprint and obtains the standard operation paradigm that matches the operation type. Based on the commands, an intelligent agent is generated, and according to the standard operating paradigm, the environment construction blueprint is translated into an executable command sequence in an isolated environment; The execution verification agent executes the executable command sequence in the isolated environment to obtain the vulnerable environment.

[0008] Optionally, after generating the intelligent agent based on the command and translating the environment construction blueprint into an executable command sequence in an isolated environment according to the standard operating paradigm, the method further includes: The execution verification agent obtains error information during the execution of the executable command sequence; Determine the fault type of the error message; If the fault type belongs to the planning layer fault, the error information is fed back to the planning domain agent through the execution verification agent to trigger the regeneration of the environment construction blueprint; If the fault type is an execution layer fault, the execution verification agent notifies the command generation agent to adjust the command parameters in the executable command sequence.

[0009] Optionally, after generating an executable command sequence based on the environment blueprint using the execution domain agent and executing the executable command sequence in an isolated environment to obtain the vulnerable environment, the method further includes: Based on the runtime parameters declared in the environment construction blueprint, start the service corresponding to the target project in the vulnerable environment and execute the verification script; When the operational status of the vulnerable environment is verified, the environment construction blueprint and construction process log are stored in the repository skill library with the project repository address as the index, and the executable command sequence is stored in the general skill library with the operation type as the index.

[0010] Furthermore, to achieve the above objectives, this application also proposes a fragile environment construction apparatus, the fragile environment construction apparatus comprising: The retrieval module is used to obtain the project repository address of the target project; The construction module is used to analyze the source code repository corresponding to the project repository address through a planning domain agent based on the project repository address, and generate an environment construction blueprint. An execution module is used to generate an executable command sequence based on the environment blueprint of the execution domain agent, and execute the executable command sequence in an isolated environment to obtain a fragile environment.

[0011] In addition, to achieve the above objectives, this application also proposes a vulnerable environment construction device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the vulnerable environment construction method as described above.

[0012] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and which, when executed by a processor, implements the steps of the fragile environment construction method described above.

[0013] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the fragile environment construction method described above.

[0014] This application sets up a dual-domain architecture that separates the planning domain and the execution domain, so that the planning and execution responsibilities of the fragile environment construction task are undertaken by different functional domains. This avoids the problems of context window exceeding limits and increased inference error rate caused by a single agent undertaking multiple heterogeneous tasks such as analysis, planning and execution at the same time, thereby achieving high success rate and low cost of automatic fragile environment construction. Attached Figure Description

[0015] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating the first embodiment of the fragile environment construction method of this application; Figure 2 This is a flowchart illustrating the second embodiment of the fragile environment construction method of this application; Figure 3 This is a flowchart illustrating the third embodiment of the fragile environment construction method of this application; Figure 4 A simplified flowchart illustrating a method for constructing a fragile environment; Figure 5 This is a schematic diagram of the modular structure of the vulnerable environment construction device according to an embodiment of this application; Figure 6 This is a schematic diagram of the device structure of the hardware operating environment involved in the vulnerable environment construction method in this application embodiment.

[0018] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0019] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0020] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0021] High-quality, reproducible vulnerability environments are an indispensable infrastructure for software security research such as vulnerability detection, fuzzing, and patch verification. With the rapid expansion of the open-source software ecosystem, the number of publicly disclosed CVEs (Common Vulnerabilities & Exposures) continues to grow annually. Manual construction requires security experts to interpret CVE descriptions one by one, locate the version introducing the vulnerability in the code repository, and manually build the operating system and dependent libraries. Reproducing a single vulnerability often takes hours or even days, resulting in small overall dataset size, narrow coverage, and severely delayed updates, making it difficult to keep up with the tens of thousands of new CVEs added each year. Furthermore, differences in background knowledge and operational preferences among experts lead to inconsistent vulnerability environments in terms of configuration accuracy, reproducibility, and documentation completeness. To alleviate the pressure of manual work, academia and industry have begun exploring automated vulnerability reproduction systems in recent years. However, existing automated solutions still generally suffer from the following shortcomings in the core step of "vulnerable environment reconstruction": firstly, slow construction speed and low success rate. Setting up a fragile environment involves multiple complex steps, including source code structure analysis, third-party dependency resolution, compilation and build command execution, service startup, and functional verification. Existing solutions typically assign these tasks to a single or a few agents, leading to a high risk of context window exceeding limits, frequent errors in the inference process, and tool call timeouts. Furthermore, local failures can easily trigger global cascading crashes, resulting in a persistently high failure rate when dealing with large, complex, or poorly documented open-source projects. Secondly, experiential knowledge cannot be reused. Each setup involves starting from scratch, tentatively exploring the project structure, dependencies, and configuration methods. There is a lack of accumulation and reuse of successful experiences from common project types, typical build patterns, and specific code repositories, with a significant amount of time wasted on repeated trial and error. In summary, existing automation solutions have significant shortcomings in both decoupling and collaboration, and knowledge reuse: on the one hand, the analysis and execution responsibilities are not separated, resulting in an excessive burden on individual agents and difficulty in isolating errors; on the other hand, there is a lack of structured accumulation and retrieval mechanisms for successful historical experiences.

[0022] Therefore, there is an urgent need for an automatic method for constructing vulnerable environments that supports the decoupling of planning and execution and has the ability to reuse knowledge. By constructing a multi-agent collaborative architecture that separates "planning and execution" and a two-layer skill library system that can be accumulated and reused, the vulnerable environment reconstruction process can be completed automatically with low trial and error costs and high success rate, thereby providing a large-scale, timely and continuously updated experimental foundation for downstream security research tasks.

[0023] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, knowledge reuse, and program execution functions, such as a computer, or an electronic device capable of performing the above functions. The following description uses a vulnerable environment construction system as an example to illustrate this embodiment and the subsequent embodiments.

[0024] Based on this, embodiments of this application provide a method for constructing a fragile environment, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the fragile environment construction method of this application.

[0025] In this embodiment, the fragile environment construction method includes: Step S10: Obtain the project repository address of the target project.

[0026] It should be noted that the target project is a software project with known security vulnerabilities that requires the construction of a corresponding vulnerable operating environment; this is typically an open-source software project. The project repository address refers to the network address used to uniquely identify and access the source code repository, including but not limited to Uniform Resource Locators (URLs) and version control system addresses. The source code repository contains the target project's source code, build configuration files, dependency declaration files, and version history information.

[0027] Optionally, the project repository address of the target project can be obtained by: receiving the repository address input by the user; querying the repository address associated with the target vulnerability identifier from the vulnerability database; or obtaining it from the official release channel of the target project.

[0028] Specifically, as an optional implementation, the system can obtain the project repository address of the target project by monitoring update events in the vulnerability database. When the vulnerability database includes new CVE records, it typically contains the name of the project affected by the vulnerability and its official repository address. After detecting a new CVE record, the system automatically parses the record and extracts the project repository address from the corresponding field.

[0029] In another optional implementation, after obtaining the project repository address, the project repository address is validated, including verifying network reachability, the existence of the repository, and whether it contains valid source code. If the validation fails, an error message is output.

[0030] It should be understood that when obtaining the project repository address of a target project, the system can first receive a build request input by the user or triggered by the system. This build request contains the target project's identification information. Based on this identification information, the system retrieves the corresponding project repository address from a vulnerability database or project index. For example, after receiving a build request, the system parses the target vulnerability identifier in the request, queries the vulnerability database to obtain the project name and version information corresponding to the vulnerability, and then matches the project's repository address on the code hosting platform from the project index. When the project repository address is directly provided by the user, it is directly obtained as the entry point for accessing the target project's source code repository. For example, if the user enters the target project's GitHub repository URL in the system interface, the system directly uses this URL as the project repository address for subsequent processing.

[0031] Understandably, if the project repository address cannot be obtained or resolved, a failure message will be output and the current build process will be terminated.

[0032] Step S20: Based on the project repository address, analyze the source code repository corresponding to the project repository address through the planning domain agent to generate an environment construction blueprint.

[0033] It should be noted that the planning domain agent is a collection of agents deployed in the planning domain responsible for analysis, planning, and blueprint generation in fragile environment construction tasks. It can automate the analysis of source code repositories through large language models or dedicated inference engines. The planning domain agents and execution domain agents are isolated from each other in terms of responsibility and fault domain. The planning domain agents are only responsible for generating environment construction blueprints and are not involved in the execution of specific commands. Optionally, the planning domain agents can also dynamically adjust the analysis granularity according to the task complexity.

[0034] It is understandable that a source code repository includes the complete codebase corresponding to the project repository address and its historical version information. In this embodiment, the analysis of the source code repository by the planning domain agent covers directory structure parsing, dependency identification, and build scheme generation. Its output is a declarative environment build blueprint independent of the underlying runtime. The environment build blueprint includes the following fields: basic runtime environment type and version, system-level dependency list, language-level dependency list (including precise version number), source code version (commit hash or tag), build command template, and runtime parameters (such as listening port and environment variables). The environment build blueprint does not contain specific installation commands; it only declares "what is needed," which is translated into specific operations by the execution domain according to the sandbox environment.

[0035] Specifically, as an optional implementation, when analyzing the source code repository corresponding to the project repository address using a planning domain agent, the structure analysis agent first parses the directory organization of the source code repository, identifies the build system type and key configuration files, and outputs structured project metadata. Then, the dependency resolution agent parses the dependency declaration file based on the project metadata and the vulnerability identifier information corresponding to the target project to identify third-party dependencies and their version constraints, and outputs a dependency constraint list. Finally, the blueprint generation agent integrates the project metadata and the dependency constraint list to generate the environment build blueprint. For example, if the structure analysis agent parses the source code repository and finds that it uses the Maven build system, identifies the pom.xml configuration file, and outputs project metadata containing the Maven build system type, the dependency resolution agent parses the pom.xml to extract the version range of each dependency, combines the vulnerability identifier information to lock the relevant dependencies into the vulnerable version range, and outputs a dependency constraint list. The blueprint generation agent merges the above information to generate an environment build blueprint containing Maven build command templates.

[0036] Understandably, if the planning domain agent cannot parse the source code repository or generate a valid environment building blueprint, it will output an analysis failure message and terminate the current building process.

[0037] Step S30: Based on the execution domain agent, generate an executable command sequence according to the environment blueprint, and execute the executable command sequence in the isolated environment to obtain the vulnerable environment.

[0038] It should be noted that execution domain agents are a collection of agents deployed in the execution domain responsible for translating the environment build blueprint into specific commands and executing and verifying them. Execution domain agents are decoupled from planning domain agents in terms of responsibilities; execution domain agents are only responsible for command generation and execution verification and do not directly participate in blueprint analysis and generation. An isolated environment refers to a runtime environment isolated from the host system, including but not limited to containerized or virtualized environments, used to ensure the security and reproducibility of the build process. Optionally, the isolated environment can also dynamically allocate computing resources based on resource requirements.

[0039] It is understood that the executable command sequence includes a series of installation, compilation, configuration, and startup commands translated from the environment blueprint. In this embodiment, the execution domain agent includes a command generation agent and an execution verification agent. The command generation agent is responsible for parsing the operation types in the environment blueprint and retrieving the corresponding standard operation paradigms to generate the executable command sequence. The execution verification agent is responsible for executing the executable command sequence in the isolated environment and verifying the build result. A vulnerable environment refers to a successfully built runnable software environment that contains the vulnerability corresponding to the target project. In this embodiment, the execution domain agent drives command generation through a two-layer skill library.

[0040] Optionally, if the execution domain agent is unable to complete the execution of the executable command sequence in the isolated environment or fails to obtain the fragile environment after multiple retries, a complete log is recorded and marked as pending manual review.

[0041] In the specific implementation process, the accumulation of a repository skill library allows different CVEs from the same repository to directly refer to the existing steps of that repository when requesting construction again. The accumulation of a general skill library can continuously enrich and improve various standard operating paradigms. The average number of exploration steps for new tasks and the number of large model calls continuously decrease as the system runtime increases, improving construction efficiency and success rate. At this point, after step S30, the following is also included: Based on the runtime parameters declared in the environment construction blueprint, start the service corresponding to the target project in the vulnerable environment and execute the verification script; When the operational status of the vulnerable environment is verified, the environment construction blueprint and construction process log are stored in the repository skill library with the project repository address as the index, and the executable command sequence is stored in the general skill library with the operation type as the index.

[0042] It should be noted that runtime parameters refer to the parameter information declared in the environment construction blueprint used to start and configure the target service, including but not limited to listening port, environment variables, configuration file path, and service startup mode. Verification scripts refer to executable scripts used to detect the running status of the vulnerable environment and whether the vulnerability triggering conditions are met; their execution results are used to determine whether the vulnerable environment has been successfully built. Optionally, verification scripts may also include both functional verification and security verification.

[0043] Understandably, the skill library is divided into two layers. The general skill library is indexed by operation type, storing standard operation paradigms that can be reused across projects. Each record includes the operation name, applicable scenario description, operation step sequence, and expected result verification rules. For example, the "pip install Python dependencies" record includes the execution steps of `pip install -r requirements.txt`, the verification command for `pip list`, and version verification rules. The repository skill library is indexed by repository URL, storing complete solutions for historically successful builds. Each record includes the environment build blueprint and build process log for that build. When different CVEs from the same repository request a build again, they can directly refer to the existing steps in that repository, reducing exploration.

[0044] In this embodiment, the retrieval strategy adopts a "repository-first, domain-based division of labor" mechanism. During the planning phase, the blueprint generation agent queries the repository skill library using the repository URL: if a record in the same repository is found, its blueprint is extracted as a reference template and merged with the dependency constraints of the current CVE to generate a new blueprint; if no match is found in the repository skill library, the blueprint is generated from scratch entirely based on the structural analysis and dependency resolution results. During the execution phase, the command generation agent retrieves the corresponding standard operation paradigm from the general skill library according to the operation types in the blueprint, and then uses the large model to infer and generate specific execution commands. After each successful build, the system automatically archives the blueprint and logs of that build to the repository skill library, and simultaneously stores the newly generated command sequence in the general skill library after execution verification, forming a positive feedback loop of continuous knowledge accumulation.

[0045] Specifically, as an optional implementation, based on the runtime parameters declared in the environment construction blueprint, when starting the service corresponding to the target project in the vulnerable environment, the verification agent reads the runtime parameters in the environment construction blueprint, configures the corresponding environment variables in the isolated environment, and starts the target service process. After the service starts, the verification script is executed to detect the service response status and vulnerability triggering conditions. For example, the runtime parameters declared in the environment construction blueprint include a listening port of a specific port and environment variables containing a database connection address. After setting the above parameters in the vulnerable environment, the verification agent starts the target service and then executes the verification script containing the vulnerability triggering request to detect whether the service responds normally and whether the vulnerability conditions are met.

[0046] In another optional implementation, when the operational status verification of the vulnerable environment passes, the environment construction blueprint and construction process log are stored in the repository skill library using the project repository address as an index, and the executable command sequence is stored in the general skill library using the operation type as an index. For example, if other vulnerable environments with different vulnerabilities need to be built in the same project repository later, the blueprint generation agent can directly retrieve the historical construction blueprint of that repository from the repository skill library as a reference template; when other project repositories need to perform the same operation type, the command generation agent can retrieve the established standard operation paradigm from the general skill library, reducing the overhead of repetitive reasoning.

[0047] Optionally, when the executable command sequence contains a new operation paradigm not yet recorded in the general skill library, the new operation paradigm is added to the general skill library after execution verification. For example, if a command-generating agent generates a new command sequence for a novel construction system, and after successful execution verification, the command sequence, its applicable scenario description, and expected result verification rules are stored in the general skill library as a new standard operation paradigm.

[0048] It is understandable that if the execution of the verification script determines that the operating status of the vulnerable environment has failed the verification, the verification agent will capture the verification failure information, determine the fault domain based on the failure information, and enter the targeted correction process.

[0049] In this embodiment, by setting up a dual-domain architecture that separates the planning domain and the execution domain, the planning and execution responsibilities of the fragile environment construction task are undertaken by different functional domains. This avoids the problems of context window exceeding limits and increased inference error rate caused by a single agent simultaneously undertaking multiple heterogeneous tasks such as analysis, planning, and execution. As a result, a high success rate and low cost of automatic fragile environment construction can be achieved.

[0050] Reference Figure 2 , Figure 2 This is a flowchart illustrating the second embodiment of the fragile environment construction method of this application. Based on the first embodiment described above, a second embodiment of the fragile environment construction method of this application is proposed.

[0051] In the second embodiment, the planning domain agent includes a structure analysis agent, a dependency resolution agent, and a blueprint generation agent. Step S20 includes: Step S201: The source code repository is parsed by the structure analysis agent to generate structured project metadata.

[0052] It should be noted that the structural analysis agent is responsible for parsing the source code directory organization of the target project, identifying the build system type (such as CMake, Maven, Makefile, setuptools, etc.), entry file location, configuration file path, submodule structure, etc., and outputting structured project metadata, including the build system type, source code directory tree summary, and key configuration file list. The structural analysis agent can extract project structural information through static analysis or pattern matching. Project metadata refers to structured data describing the source code repository organization and build system characteristics, including but not limited to the build system type, source code directory tree summary, key configuration file list, and submodule structure. Optionally, the structural analysis agent can also identify the project's programming language distribution and test framework configuration.

[0053] Specifically, as an optional implementation, when the structural analysis agent parses the source code repository, it can first traverse the root directory and all subdirectories of the source code repository to identify the location and type of the build system entry file; then, based on the build system entry file, locate the key configuration files and extract the configuration file path and file summary information; finally, summarize the directory structure, build system type, key configuration file list, and submodule relationships to generate structured project metadata. For example, when the structural analysis agent parses a source code repository, it identifies the CMakeLists.txt file in the root directory, determines that the build system type is CMake, and then locates and extracts the path and content summary of the CMakeLists.txt file. At the same time, it scans subdirectories such as src and include to generate a directory tree summary, and finally outputs project metadata containing the above information.

[0054] In another optional implementation, when the source code repository contains multiple submodules or nested build systems, the structure analysis agent recursively parses the build configurations of each submodule, identifies the master-slave build relationship and the dependency order between modules. For example, if the main directory of a source code repository is built using Makefile and also contains submodules built using CMake, the structure analysis agent parses the build system type and entry file of each module, identifies the call relationship between the main Makefile and the submodule CMakeLists.txt, and marks the nested structure and build order in the project metadata.

[0055] Step S202: The dependency resolution agent generates a dependency constraint list for the target project based on the project metadata and the vulnerability identifier information corresponding to the target project.

[0056] It should be noted that the dependency resolution agent takes the output of the structural analysis agent and the CVE description as input. It is responsible for identifying the project's third-party dependencies and their version constraints. Specifically, it includes: parsing dependency declaration files (such as requirements.txt, pom.xml, package.json, CMakeLists.txt, etc.) to extract dependency names and version ranges, combining the affected version information that may be mentioned in the CVE description to lock the dependencies into the vulnerable version range, and identifying system-level dependencies (such as databases, message queues, specific system libraries), and outputting a structured list of dependency constraints.

[0057] Understandably, the dependency resolution agent can locate and parse the corresponding dependency declaration files based on the build system type and key configuration files identified in the project metadata.

[0058] It should be understood that vulnerability identification information is used to identify the vulnerabilities corresponding to the target project. A dependency constraint list refers to a structured description of the names, version ranges, and system-level dependency requirements of third-party dependencies. Optionally, the dependency resolution agent can also identify transitive dependencies between dependencies.

[0059] Specifically, the dependency resolution agent first locates the dependency declaration file based on the list of key configuration files in the project metadata; then, it parses the dependency declaration file to extract the name and version range of each dependency; finally, combined with the affected version information described in the vulnerability identification information, it locks the version range of the relevant dependencies to the vulnerable version range and outputs a dependency constraint list containing language-level and system-level dependencies. For example, if the project metadata indicates that the build system type is Maven and locates pom.xml, the dependency resolution agent parses pom.xml to extract the groupId, artifactId, and version range of each dependency. Combined with the vulnerability identification information indicating that the affected version of a certain component is within a specific range, it locks the version range of that component from any originally declared version to that vulnerable version range, generating a dependency constraint list.

[0060] Understandably, when the vulnerability identification information does not explicitly mention specific dependencies, the dependency resolution agent matches related dependencies in the dependency declaration file based on the functional module information in the vulnerability description and marks them as pending confirmation. For example, if the vulnerability identification information describes a vulnerability existing in the data processing module, the dependency resolution agent identifies multiple candidate dependencies related to data processing in the dependency declaration file, marks the version constraints of these dependencies as pending confirmation, and the blueprint generation agent further determines them when building the blueprint in the production environment.

[0061] Optionally, when parsing dependency declaration files, the dependency resolution agent can simultaneously identify system-level dependency requirements, including specific database services, message queue middleware, or operating system function libraries. For example, if it resolves that a dependency requires PostgreSQL database support, the dependency resolution agent appends a system-level dependency to the dependency constraint list, declaring that the PostgreSQL service and its version requirements need to be installed.

[0062] Step S203: Generate an intelligent agent through the blueprint, and generate the environment construction blueprint based on the dependency constraint list and the project meta information.

[0063] It should be noted that the blueprint generation agent receives the output from the first two agents and queries the repository skill library to obtain historical build blueprints for that repository as a reference (if they exist). It is responsible for integrating two parts of information: merging the dependency constraint list and environment metadata into a blueprint skeleton. When the dependency resolution result conflicts with the version constraints in the historical blueprint, the vulnerable version required by the CVE is used, and a complete environment build blueprint is finally output. Optionally, the blueprint generation agent can also optimize and adjust the blueprint based on historical build experience.

[0064] It should be understood that when generating the environment building blueprint, the blueprint generating agent prioritizes the version constraints in the dependency constraint list to ensure the consistency of vulnerable versions. The declarative description of the build steps in the build command template can be translated into specific commands by the execution domain agent based on standard operating paradigms in the general skill library. In this embodiment, the environment building blueprint adopts a structured description in YAML or JSON format.

[0065] Specifically, as an optional implementation, when the blueprint generation agent generates the environment build blueprint, it can first determine the basic runtime environment type and version based on the build system type in the project metadata; then, based on the system-level dependency list and language-level dependency list in the dependency constraint list, it declares the precise version number of each dependency; finally, based on the source code version information and build system characteristics in the project metadata, it declares the build command template and runtime parameters, and integrates them to generate the environment build blueprint. For example, the blueprint generation agent determines that the basic runtime environment includes a Java runtime environment based on the build system type being Maven in the project metadata; it declares the language-level dependency list based on the vulnerable versions of each dependency locked in the dependency constraint list; it declares the source code version based on the commit hash in the project metadata; and finally, it generates an environment build blueprint containing the above fields.

[0066] In the specific implementation process, before blueprint generation, the repository skill library can be retrieved using the project repository address as an index to obtain historical build blueprints. This allows the same repository to reuse existing build experience in different CVE build tasks, significantly reducing the time spent on repetitive analysis of the same repository. At this point, before step S203, the following steps are also included: The agent is generated using the blueprint, and the repository skill library is retrieved using the project repository address as an index to obtain the historical construction blueprint of the source code repository.

[0067] Accordingly, step S203 further includes: The intelligent agent is generated by the blueprint, which integrates the dependency constraint list, the project metadata, and the historical build blueprint to generate an environment build blueprint.

[0068] It should be noted that historical build blueprints are environment build blueprints generated from previous build tasks of the same source code repository within the repository skill library. They contain valid configuration information and build schemes that have been verified through execution. The retrieval strategy adopts a "repository-first" mechanism, that is, it prioritizes searching for historical records that match the current project repository address to achieve cross-task reuse of knowledge. Optionally, the repository skill library can also sort and filter historical build blueprints based on build time or build success rate.

[0069] It should be understood that before generating the environment build blueprint, the blueprint generation agent searches the repository skill library using the project repository address as an index to obtain the historical build blueprint of the source code repository as a reference template. It then integrates the basic runtime environment configuration and build command template from the historical build blueprint with the current dependency constraint list. In case of version constraint conflicts, the vulnerable version in the dependency constraint list takes precedence, generating a new environment build blueprint. For example, if the repository skill library contains a historical build blueprint for that repository, and its declared basic runtime environment is a specific version of Ubuntu and its corresponding system-level dependencies, the blueprint generation agent retains this historical configuration, only updating the language-level dependency list to the vulnerable version corresponding to the current vulnerability, generating the integrated environment build blueprint.

[0070] Optionally, when there are dependencies marked as pending confirmation in the dependency constraint list, the blueprint generation agent infers confirmation based on the functional module description or preset rules in the project metadata, or marks multiple candidate versions of the dependency in the environment construction blueprint for the execution domain agent to select during verification. For example, if a dependency is marked as pending confirmation, the blueprint generation agent infers that it should be a vulnerable version based on the correlation between the functional module to which the dependency belongs and the vulnerability description in the project metadata, and declares this inference result in the environment construction blueprint.

[0071] Understandably, if no historical build blueprint matching the project repository address is found in the repository skill library, the blueprint generation agent directly generates the environment build blueprint based on the project metadata and the dependency constraint list, without performing an integration operation.

[0072] In this embodiment, a planning domain pipeline is formed by a structural analysis agent, a dependency resolution agent, and a blueprint generation agent. This allows the three subtasks of source code repository structural resolution, dependency constraint extraction, and blueprint generation to be completed independently by their respective dedicated agents. Each agent only needs to maintain a simplified context for its own subtask, preventing tool call timeouts or attention drift due to context window exceeding limits, significantly improving analysis accuracy and stability. Simultaneously, the dependency resolution agent, combined with version constraints from vulnerability identification information, locks dependencies to vulnerable version ranges, ensuring that the constructed environment can accurately reproduce the vulnerable states corresponding to CVEs, providing a reliable environmental foundation for subsequent vulnerability verification.

[0073] Reference Figure 3 , Figure 3 This is a flowchart illustrating the third embodiment of the vulnerable environment construction method of this application. Based on the first embodiment described above, a third embodiment of the vulnerable environment construction method of this application is proposed.

[0074] In the third embodiment, the execution domain agent includes a command generation agent and an execution verification agent; step S30 includes: Step S301: Generate an intelligent agent based on the command, parse the operation types declared in the environment construction blueprint, and obtain the standard operation paradigm that matches the operation type.

[0075] It should be noted that the command generation agent is responsible for translating the environment building blueprint into a specific executable command sequence. Based on the various operation modes declared in the blueprint (such as "install Python dependencies", "compile C project", "configure database", etc.), it searches the general skill library by operation type, obtains the corresponding standard operation paradigm, and then combines it with the large model to infer and generate specific execution commands. After the generated results are executed and verified, they are stored in the general skill library.

[0076] Understandably, an operation type refers to an abstract operation category declared in the environment build blueprint, used to describe "what is needed" rather than "how to operate," including but not limited to categories such as dependency installation, source code compilation, service configuration, and environment initialization. A standard operation paradigm refers to a reusable, cross-project operation template stored in a general skill library, indexed by operation type. It includes a sequence of operation steps, parameter placeholder rules, and expected result verification rules. Optionally, the command generation agent can also determine the operation execution order based on the combination relationship of operation types.

[0077] Specifically, the command generation agent first reads the operation type field in the environment build blueprint, identifying the name and parameter declaration of each operation type; then, it searches the general skill library by operation type name and index to obtain the corresponding standard operation paradigm; finally, it establishes a mapping relationship between each operation type and the obtained standard operation paradigm. For example, if the environment build blueprint declares operation types as "Install Python dependencies" and "Compile C project", the command generation agent searches the general skill library to obtain the standard operation paradigm corresponding to "Install Python dependencies" (including the pip install step and pip list validation rules) and the standard operation paradigm corresponding to "Compile C project" (including the configure and make steps), thus establishing a mapping between operation types and standard operation paradigms.

[0078] Step S302: Generate an intelligent agent based on the command, and translate the environment construction blueprint into an executable command sequence in an isolated environment according to the standard operating paradigm.

[0079] It should be noted that the execution verification agent is responsible for executing commands generated by the agent in the isolated sandbox, monitoring error output during the build process, starting services according to runtime parameters in the blueprint, and executing verification scripts to check whether the service is running normally and whether the vulnerability triggering conditions are met.

[0080] Understandably, the command generation agent translates each operation type into a corresponding command subsequence based on the mapping relationship between each operation type and the standard operation paradigm, and then combines the command subsequences into a complete executable command sequence according to their dependencies. During the translation process, the declaration information in the environment construction blueprint, such as the basic runtime environment type, the exact version number of dependencies, the source code version, and runtime parameters, is instantiated into specific command parameters. In this embodiment, the executable command sequence is output in script form.

[0081] In one example, the environment build blueprint declares the base runtime environment as a specific version of Ubuntu. The command generation agent first generates the initialization commands for this environment. For the "Install Python dependencies" operation type, the pip install step in the standard operation paradigm is combined with each dependency and its version number in the dependency constraint list to generate a specific pip install command subsequence. For the "Compile C project" operation type, the configure and make steps in the standard operation paradigm are combined with the source code path to generate a specific compilation command subsequence. Finally, the complete executable command sequence is combined in the order of environment initialization, dependency installation, source code acquisition, and compilation and building.

[0082] In the specific implementation process, error information can be captured by the execution verification agent, and differentiated correction strategies can be implemented according to the fault type to achieve isolation processing of planning layer faults and execution layer faults. This ensures that local errors do not trigger a full process rollback, and the retry overhead is limited to single-step operations in the fault domain, significantly reducing error recovery costs and improving the overall robustness and construction efficiency of the system. At this point, after step S302, the following is also included: The execution verification agent obtains error information during the execution of the executable command sequence; Determine the fault type of the error message; If the fault type belongs to the planning layer fault, the error information is fed back to the planning domain agent through the execution verification agent to trigger the regeneration of the environment construction blueprint; If the fault type is an execution layer fault, the execution verification agent notifies the command generation agent to adjust the command parameters in the executable command sequence.

[0083] It should be noted that error messages are abnormal outputs generated during the execution of an executable command sequence. Fault types include two categories: planning-level faults and execution-level faults. Planning-level faults refer to build failures caused by incorrect dependency version declarations, configuration conflicts, or blueprint structure defects in the environment build blueprint. Execution-level faults refer to build failures caused by factors during the execution phase, such as incorrect command parameters, compilation syntax problems, or runtime timeouts. Optionally, the execution verification agent can also automatically classify errors based on characteristic patterns.

[0084] Understandably, the determination of fault attribution can be based on the source and nature of the error message. Planning layer faults include, but are not limited to, non-existent dependency versions, dependency declaration file parsing errors, blueprint configuration conflicts, and mismatched basic runtime environment types; execution layer faults include, but are not limited to, compilation command syntax errors, service startup timeouts, insufficient permissions, and resource allocation failures. The feedback mechanism adopts a domain-based targeted approach. Error messages from planning layer faults are encapsulated and transmitted to the planning domain agent, while notifications for execution layer faults are sent directly to the command generation agent, achieving fault isolation and targeted correction. In this embodiment, the feedback process does not require a full rollback.

[0085] Specifically, when the execution verification agent reports a build failure, the system enters a correction process: First, it determines the fault domain based on the error message. If the fault is in the planning domain, such as "dependency version not found" or "dependency declaration file parsing error," the system appends the error message to the original blueprint, triggering the dependency resolution agent to re-infer based on the fault feedback, generate a corrected blueprint, and re-enter the execution domain. If the fault is in the execution domain, such as "compilation command syntax error" or "service startup timeout," the system instructs the command generation agent to adjust the command parameters of the corresponding step and retry, without disturbing the planning domain. After the number of retries exceeds a set threshold, the system records a complete log and marks it for manual review. This design ensures that local errors do not trigger a full-process rollback; the retry overhead is only a single-step operation in the fault domain, not the entire build process.

[0086] In one example, if the execution verification agent detects that the `pip install` command returns a non-zero status code with the error output including "No matching distribution found," the matching rule base determines that the dependency version does not exist, classifying it as a planning-level fault. If the execution verification agent detects that the `gcc` compilation command returns a syntax error, it classifies it as an execution-level fault. If the execution verification agent determines that the non-existence of a dependency version is a planning-level fault, it encapsulates the error information and the declaration location of the dependency in the blueprint into a fault feedback package and passes it to the blueprint generation agent. The blueprint generation agent adjusts the version constraints of the dependency based on the feedback and regenerates the environment build blueprint.

[0087] Step S303: The execution verification agent executes the executable command sequence in the isolated environment to obtain the vulnerable environment.

[0088] Specifically, when the execution verification agent executes the executable command sequence in the isolated environment, it first initializes the basic operating state of the isolated environment, including configuring the basic operating environment type and version, setting environment variables, and mounting necessary resources. Then, it executes each command in the execution order of the executable command sequence, monitoring the exit status code and standard output stream of each command. If all commands are successfully executed, the target service is started according to the runtime parameters in the environment building blueprint, and the normal operation of the service process is verified. Instances of normally functioning isolated environments are marked as vulnerable environments. For example, the execution verification agent initializes a containerized isolated environment, configured with a specific version of Ubuntu declared in the environment building blueprint, and executes commands such as environment initialization, dependency installation, source code acquisition, and compilation / building one by one. After all commands are successful, the target service is started and the listening port response is verified, confirming the vulnerable environment.

[0089] In this embodiment, a command generation agent automatically translates the "what is needed" declaratively described in the blueprint into a specific sequence of executable commands in an isolated environment, allowing experience from intermediate operations across different projects to be reused. The execution verification agent executes the command sequence in an isolated sandbox, isolating the build process from the host environment. This ensures host security and eliminates build failures caused by environmental differences through the consistency of the sandbox environment, thus improving the build success rate.

[0090] For example, to help understand the implementation process of the fragile environment construction method obtained by combining this embodiment with the above embodiment one, please refer to... Figure 4 , Figure 4 This is a simplified flowchart of a fragile environment construction method. Specifically: Taking the CVE number and its corresponding repository address as input, the structural analysis agent in the planning domain first parses the project metadata, and the dependency resolution agent extracts the dependency constraint list. Then, the blueprint generation agent integrates these and outputs a declarative environment construction blueprint. Subsequently, it enters the execution domain, where the command generation agent retrieves the general skill library based on the blueprint to generate specific command sequences. The execution verification agent executes the commands in an isolated sandbox and performs verification checks. If the construction is successful, an available fragile environment is output, and skill library storage is triggered. The blueprint and logs are stored in the repository skill library, and the command paradigm is stored in the general skill library, thus forming a positive feedback loop for knowledge reuse. If the verification fails, the system determines the fault domain: planning layer faults are fed back to the blueprint generation agent to correct the blueprint and re-execute; execution layer faults are handled by the command generation agent by adjusting command parameters and retrying. Manual review is only marked when the number of retries exceeds a threshold, thereby achieving local error isolation and targeted recovery, avoiding a full process rollback.

[0091] It should be understood that the vulnerability environment construction method can be used to build an automated vulnerability environment construction system, which can be deployed in vulnerability database maintenance platforms or continuous integration pipelines of security research institutions to provide automated services of "CVE input - vulnerability environment output".

[0092] Once a new CVE record is added, the system automatically triggers the build process. The structural analysis agent and the dependency resolution agent collaborate to analyze the source code repository of the target project, extracting project metadata and dependency constraints. The blueprint generation agent then queries the repository skill library, integrates reference information, and generates the environment build blueprint. Due to the adoption of a decoupled "planning-execution" architecture, the three planning domain agents only need to maintain a simplified context for their respective subtasks. During inference, tool call timeouts or attention drift will not occur due to context window exceeding limits, resulting in a significant improvement in analysis accuracy and stability compared to traditional single-agent solutions.

[0093] Once in the execution phase, the command-generating agent retrieves standard operational paradigms from the general skill library based on the various operation modes in the blueprint, and then uses the large model to infer specific command sequences. Because historical experience is structured, stored, and searchable, the average number of exploration steps and large model calls for new tasks are significantly reduced, resulting in a substantial improvement in construction efficiency compared to traditional zero-based generation schemes.

[0094] After the execution verification agent completes the environment setup in the sandbox, it automatically starts the service and performs verification. If the service starts normally and the vulnerability triggering conditions are met, the vulnerable environment is marked as "available," and its complete build plan is automatically archived to the repository skill library. At the same time, the newly generated command sequence is stored in the general skill library for reference and reuse when building other CVEs in the same repository, forming a positive feedback loop of continuous knowledge accumulation. If the build fails, the system corrects the error according to the fault type: planning layer issues are fed back to the blueprint generation agent to correct the blueprint, and execution layer issues are addressed by the command generation agent by adjusting command parameters and retrying, without the need for a full rollback.

[0095] Based on the standardized vulnerable environment containers output by this system, downstream security tasks can directly integrate and use them. In vulnerability detection scenarios, researchers can connect static analysis tools or dynamic detection tools to this system to obtain ready-to-use environments corresponding to different CVEs in batches, eliminating the need for manual setup. In patch verification scenarios, developers input the source code of two versions before and after a patch, and the system automatically builds two environment instances for comparative analysis of patch effectiveness. In fuzzing scenarios, this system provides standardized capability assessment benchmarks for fuzzing tools. By batch building vulnerable environments for known vulnerabilities, the system verifies the testing tools' ability to trigger and discover specific vulnerability types.

[0096] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the fragile environment construction method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0097] This application also provides a fragile environment construction device, please refer to... Figure 5 The fragile environment construction device includes: Module 10 is used to obtain the project repository address of the target project; Module 20 is used to analyze the source code repository corresponding to the project repository address through a planning domain agent based on the project repository address, and generate an environment construction blueprint. The execution module 30 is used to generate an executable command sequence based on the environment blueprint of the execution domain agent, and execute the executable command sequence in an isolated environment to obtain a fragile environment.

[0098] The fragile environment construction apparatus provided in this application, employing the fragile environment construction method in the above embodiments, can solve the technical problems of existing automated solutions where the context window of a single agent easily exceeds the limit during fragile environment reconstruction, and errors and tool call timeouts frequently occur during inference. Compared with the prior art, the beneficial effects of the fragile environment construction apparatus provided in this application are the same as those of the fragile environment construction method provided in the above embodiments, and other technical features in the fragile environment construction apparatus are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0099] This application provides a vulnerable environment construction device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the vulnerable environment construction method in Embodiment 1 above.

[0100] The following is for reference. Figure 6 The diagram illustrates a structural schematic suitable for implementing a vulnerable environment construction device according to embodiments of this application. The vulnerable environment construction device in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The fragile environment construction device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0101] like Figure 6As shown, the vulnerable environment construction device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the vulnerable environment construction device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. The communication device 1009 allows the vulnerable environment construction device to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows a vulnerable environment construction device with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0102] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0103] The fragile environment construction device provided in this application, employing the fragile environment construction method in the above embodiments, can solve the technical problems of existing automated solutions where the context window of a single agent easily exceeds the limit during fragile environment reconstruction, and errors and tool call timeouts frequently occur during inference. Compared with the prior art, the beneficial effects of the fragile environment construction device provided in this application are the same as those of the fragile environment construction method provided in the above embodiments, and other technical features in this fragile environment construction device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0104] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0105] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0106] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the fragile environment construction method in the above embodiments.

[0107] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0108] The aforementioned computer-readable storage medium may be included in a vulnerable environment construction device, or it may exist independently and not be assembled into a vulnerable environment construction device.

[0109] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the vulnerable environment construction device, cause the vulnerable environment construction device to perform the vulnerable environment construction method described above.

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

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

[0112] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0113] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described fragile environment construction method. This solves the technical problem in existing automated solutions where the context window of a single agent easily exceeds limits during fragile environment reconstruction, and errors and tool call timeouts frequently occur during inference. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the fragile environment construction method provided in the above embodiments, and will not be repeated here.

[0114] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the fragile environment construction method described above.

[0115] The computer program product provided in this application can solve the technical problems of existing automated solutions where the context window of a single agent is easily exceeded during the reconstruction of fragile environments, and errors and tool call timeouts frequently occur during inference. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the fragile environment construction method provided in the above embodiments, and will not be repeated here.

[0116] The above description is only a part of the embodiments of this application and does not limit the scope of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included within the protection scope of this application.

[0117] It should be noted that the data collection, tag management, rule setting, and push decision-making processes involved in this application are designed to work with other technical features to solve technical problems. They do not involve or support any illegal activities. Any data processing that may violate laws and regulations (such as unauthorized collection of privacy data, generation of discriminatory tags, setting unfair rules, or pushing illegal information) is not within the scope of protection of this application's technical solution. Of course, the user data in this application will be encrypted, anonymized, or de-identified before storage to ensure user data security.

Claims

1. A method for constructing a fragile environment, characterized in that, The method for constructing the fragile environment includes: Obtain the project repository address of the target project; Based on the project repository address, the source code repository corresponding to the project repository address is analyzed by the planning domain agent to generate an environment construction blueprint; Based on the execution domain agent, an executable command sequence is generated according to the environment blueprint, and the executable command sequence is executed in an isolated environment to obtain a fragile environment.

2. The method for constructing a fragile environment as described in claim 1, characterized in that, The planning domain agent includes a structure analysis agent, a dependency resolution agent, and a blueprint generation agent; The step of analyzing the source code repository corresponding to the project repository address using a planning domain agent to generate an environment construction blueprint based on the project repository address includes: The structure analysis agent parses the source code repository to generate structured project metadata. The dependency resolution agent generates a list of dependency constraints for the target project based on the project metadata and the vulnerability identifier information corresponding to the target project. The intelligent agent is generated through the blueprint, and the environment construction blueprint is generated based on the dependency constraint list and the project meta information.

3. The method for constructing a fragile environment as described in claim 2, characterized in that, Before generating the environment construction blueprint based on the dependency constraint list and the project metadata, the process of generating the intelligent agent from the blueprint also includes: The agent is generated using the blueprint, and the repository skill library is retrieved using the project repository address as an index to obtain the historical construction blueprint of the source code repository; Accordingly, the step of generating an intelligent agent through the blueprint, based on the dependency constraint list and the project metadata, to generate the environment construction blueprint includes: The intelligent agent is generated by the blueprint, which integrates the dependency constraint list, the project metadata, and the historical build blueprint to generate an environment build blueprint.

4. The method for constructing a fragile environment as described in claim 1, characterized in that, The execution domain agent includes a command generation agent and an execution verification agent; The execution domain-based intelligent agent generates an executable command sequence based on the environment blueprint, and executes the executable command sequence in an isolated environment to obtain a vulnerable environment, including: Based on the command, an intelligent agent is generated, which parses the operation types declared in the environment construction blueprint and obtains the standard operation paradigm that matches the operation type. Based on the commands, an intelligent agent is generated, and according to the standard operating paradigm, the environment construction blueprint is translated into an executable command sequence in an isolated environment; The execution verification agent executes the executable command sequence in the isolated environment to obtain the vulnerable environment.

5. The method for constructing a fragile environment as described in claim 4, characterized in that, The process of generating an intelligent agent based on the command, and translating the environment construction blueprint into an executable command sequence in an isolated environment according to the standard operating paradigm, further includes: The execution verification agent obtains error information during the execution of the executable command sequence; Determine the fault type of the error message; If the fault type belongs to the planning layer fault, the error information is fed back to the planning domain agent through the execution verification agent to trigger the regeneration of the environment construction blueprint; If the fault type is an execution layer fault, the execution verification agent notifies the command generation agent to adjust the command parameters in the executable command sequence.

6. The method for constructing a fragile environment as described in any one of claims 1 to 5, characterized in that, The process of generating an executable command sequence based on the environment blueprint using an execution domain-based intelligent agent, and then executing the executable command sequence in an isolated environment to obtain a vulnerable environment, further includes: Based on the runtime parameters declared in the environment construction blueprint, start the service corresponding to the target project in the vulnerable environment and execute the verification script; When the operational status of the vulnerable environment is verified, the environment construction blueprint and construction process log are stored in the repository skill library with the project repository address as the index, and the executable command sequence is stored in the general skill library with the operation type as the index.

7. A device for constructing a fragile environment, characterized in that, The device includes: The retrieval module is used to obtain the project repository address of the target project; The construction module is used to analyze the source code repository corresponding to the project repository address through a planning domain agent based on the project repository address, and generate an environment construction blueprint. An execution module is used to generate an executable command sequence based on the environment blueprint of the execution domain agent, and execute the executable command sequence in an isolated environment to obtain a fragile environment.

8. A fragile environment construction device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the fragile environment construction method as described in any one of claims 1 to 6.

9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the fragile environment construction method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the fragile environment construction method as described in any one of claims 1 to 6.

Images