Code problem processing method and system

Abstract

The invention discloses a code problem processing method and system, and the method comprises the steps: creating a sandbox environment, and obtaining a CI / CD configuration file of a target code system; analyzing the CI / CD configuration file to obtain each construction stage of the target code system and a command corresponding to the construction stage; for each construction stage, executing a command corresponding to the construction stage in the sandbox environment according to the construction stage of the target code system to obtain a dependency relationship corresponding to the construction stage of the target code system; based on the dependency relationship, establishing a dependency chain of a construction stage where the target code system is located, and marking a dependency type corresponding to the dependency chain; according to the dependency relationship, obtaining a four-dimensional coordinate of the target code system; and constructing a four-dimensional dependency graph according to all the four-dimensional coordinates, all the dependency chains and the dependency types corresponding to the dependency chains. Therefore, the CI / CD construction process is put in the sandbox environment, and the problem that the dependency relationship cannot be accurately identified is effectively solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, and in particular to a code problem processing method and system. BACKGROUND

[0002] In the current software development and operation environment, code problem repair has become a core task to maintain system stability and security.

[0003] In the existing technology, SonarQube (a code quality management platform) can detect code problems and potential risks in code by relying on static analysis technology, that is, first receiving code and performing static scanning on the code to obtain a code declaration file, secondly performing static analysis on the code declaration file to obtain an analysis result, then searching for a rule matching the analysis result from a rule library, and generating a security report according to the rule. SonarQube is a powerful code quality and security analysis tool.

[0004] However, the static analysis method of SonarQube has obvious shortcomings in handling dynamically loaded dependencies in the build process. For example, the dependency version specified dynamically through environment variables, build scripts (such as Jenkinsfile) or configuration files, SonarQube often cannot accurately identify and analyze, resulting in a blind area in dynamic dependency detection for SonarQube, making it difficult to cope with the complex dependency relationships commonly seen in modern CI / CD processes. SUMMARY

[0005] Based on the shortcomings of the above existing technology, the present application provides a code problem processing method and system to solve the problem of being unable to accurately identify dependency relationships in the prior art.

[0006] In order to achieve the above purpose, the present application provides the following technical solutions:

[0007] The first aspect of the present application provides a code problem processing method, comprising:

[0008] creating a sandbox environment and obtaining a CI / CD configuration file of a target code system;

[0009] parsing the CI / CD configuration file to obtain each build stage of the target code system and the corresponding command thereof;

[0010] respectively for each build stage, in the sandbox environment, according to the build stage where the target code system is located, executing the command corresponding to the build stage to obtain the dependency relationship corresponding to the build stage where the target code system is located;

[0011] Based on the dependency relationship, a dependency chain of the build stage where the target code system is located is established, and a corresponding dependency type of the dependency chain is marked;

[0012] According to the dependency relationship, four-dimensional coordinates of the target code system are obtained;

[0013] According to all four-dimensional coordinates, and all dependency chains and their corresponding dependency types, a four-dimensional dependency graph is constructed.

[0014] Optionally, in the code problem processing method described above, the creating a sandbox environment comprises:

[0015] A target container is created, and a tool chain in the target container is loaded;

[0016] After loading is completed, a dependency interception hook is injected in the target container through a preset injection tool;

[0017] Based on the target container, the tool chain in the target container, and the dependency interception hook, a sandbox environment is created.

[0018] Optionally, in the code problem processing method described above, the obtaining the dependency relationship corresponding to each build stage of the target code system comprises:

[0019] For each build stage, a command corresponding to the build stage is executed in the sandbox environment according to the build stage where the target code system is located, so as to intercept a dependency download request of the target code system through a dependency interception hook in the sandbox environment;

[0020] A version number, a download time, a dependency system data, and a dependency path of the target code system are extracted from the dependency download request;

[0021] Based on the version number, the download time, the dependency system, and the dependency path, a dependency relationship corresponding to the build stage where the target code system is located is generated.

[0022] Optionally, in the code problem processing method described above, the establishing the dependency chain of the build stage where the target code system is located based on the dependency relationship comprises:

[0023] Dependency system data of the target code system is extracted from the dependency relationship;

[0024] According to the dependency system data, each dependency system on which the target code system depends is obtained;

[0025] According to the dependency order in the dependency system data, the target code system dependency and each of the dependency systems are constructed to obtain a dependency chain of a construction stage in which the target code system is located.

[0026] Optionally, in the method for processing the code problem, the method further comprises:

[0027] An input parameter of the target code system is obtained, wherein the input parameter at least comprises a current version.

[0028] According to the current version, an available secure version of the target code system is queried.

[0029] According to the available secure version, a risk index is calculated.

[0030] When the risk index is greater than a preset threshold, a version upgrade directed graph is generated according to the current version, the available secure version and the risk index, wherein each node in the version upgrade directed graph represents a version, an edge between two connected nodes in the version upgrade directed graph represents an upgrade path, and the risk index between the two nodes is displayed on the edge connecting the two nodes.

[0031] According to the version upgrade directed graph, an optimal upgrade path of the current version is calculated.

[0032] According to the optimal upgrade path, an upgrade of the target code system is evaluated to obtain an evaluation result.

[0033] Optionally, in the method for processing the code problem, the calculating of the risk index according to the available secure version comprises:

[0034] An API variation degree and a scheduling frequency of the available secure version are obtained.

[0035] A product of the scheduling frequency and the API variation degree is calculated to obtain the risk index.

[0036] Optionally, in the method for processing the code problem, the method further comprises:

[0037] It is detected whether a preset vulnerability exists in the target code system.

[0038] If the preset vulnerability exists in the target code system, a code problem feature of the target code system is obtained from a cloud.

[0039] The code problem feature is locally checked.

[0040] If the code problem feature is verified locally, the code problem feature is loaded into the local, and in the loading process, a vulnerability trigger point of the target code is obtained by inserting a bytecode in the code problem feature;

[0041] According to the vulnerability trigger point, the target code system is protected to obtain a protection result.

[0042] The second aspect of the application provides a code problem processing system, comprising:

[0043] A creation unit is configured to create a sandbox environment and obtain a CI / CD configuration file of a target code system.

[0044] A parsing unit is configured to parse the CI / CD configuration file to obtain each build stage of the target code system and a corresponding command thereof.

[0045] An execution unit is configured to execute, for each build stage, the corresponding command of the build stage in the sandbox environment according to the build stage in which the target code system is located, to obtain a dependency relationship corresponding to the build stage in which the target code system is located.

[0046] An establishment unit is configured to establish a dependency chain of the build stage in which the target code system is located based on the dependency relationship, and mark a dependency type corresponding to the dependency chain.

[0047] A four-dimensional coordinate acquisition unit is configured to acquire a four-dimensional coordinate of the target code system according to the dependency relationship.

[0048] A graph construction unit is configured to construct a four-dimensional dependency graph according to all four-dimensional coordinates and all dependency chains and corresponding dependency types thereof.

[0049] Optionally, in the code problem processing system described above, the creation unit comprises:

[0050] A loading unit is configured to create a target container and load a tool chain in the target container.

[0051] An injection unit is configured to inject a dependency interception hook in the target container by a preset injection tool after the loading is completed.

[0052] A creation subunit is configured to create a sandbox environment based on the target container, the tool chain in the target container, and the dependency interception hook.

[0053] Optionally, in the code problem processing system described above, the execution unit comprises:

[0054] The execution subunit is configured to execute, for each of the build stages, a command corresponding to the build stage in the sandbox environment according to a build stage in which the target code system is located, so as to intercept a dependency download request of the target code system through a dependency interception hook in the sandbox environment.

[0055] The data extraction unit is configured to extract, from the dependency download request, a version number, a download time, dependency system data, and a dependency path of the target code system.

[0056] The generation unit is configured to generate a dependency relationship corresponding to the build stage in which the target code system is located based on the version number, the download time, the dependency system, and the dependency path.

[0057] Optionally, in the code problem processing system, the establishment unit comprises:

[0058] The extraction unit is configured to extract, from the dependency relationship, dependency system data of the target code system.

[0059] The first acquisition unit is configured to acquire each dependency system relied on by the target code system according to the dependency system data.

[0060] The construction unit is configured to construct the target code system and each dependency system according to a dependency order in the dependency system data, so as to obtain a dependency chain of the build stage in which the target code system is located.

[0061] Optionally, in the code problem processing system, the system further comprises:

[0062] The parameter acquisition unit is configured to acquire input parameters of the target code system, wherein the input parameters at least include a current version.

[0063] The query unit is configured to query an available safe version of the target code system according to the current version.

[0064] The index calculation unit is configured to calculate a risk index according to the available safe version.

[0065] The graph generation unit is configured to generate a version upgrade directed graph according to the current version, the available safe version, and the risk index when the risk index is greater than a preset threshold, wherein each node in the version upgrade directed graph represents a version, an edge between two connected nodes in the version upgrade directed graph represents an upgrade path, and the edge connecting the nodes displays a risk index between the two nodes.

[0066] The path calculation unit is configured to calculate an optimal upgrade path of the current version according to the version upgrade directed graph.

[0067] an evaluation unit configured to evaluate the upgrade of the target code system according to the optimal upgrade path, to obtain an evaluation result.

[0068] Optionally, in the code problem processing system, the index calculation unit comprises:

[0069] a second acquisition unit configured to acquire an API variation degree and a scheduling frequency of the available security version;

[0070] a calculation unit configured to calculate a product of the scheduling frequency and the API variation degree, to obtain a risk index.

[0071] Optionally, in the code problem processing system, the code problem processing system further comprises:

[0072] a detection unit configured to detect whether the target code system has a preset vulnerability;

[0073] a third acquisition unit configured to acquire, if the target code system has the preset vulnerability, a code problem feature of the target code system from a cloud;

[0074] a verification unit configured to perform local verification on the code problem feature;

[0075] an insertion unit configured to load, if the code problem feature passes the local verification, the code problem feature into a local, and obtain a vulnerability trigger point of the target code by inserting a bytecode into the code problem feature during the loading process;

[0076] a protection unit configured to protect the target code system according to the vulnerability trigger point, to obtain a protection result.

[0077] The code problem processing method provided by the application can create a sandbox environment and acquire a CI / CD configuration file of a target code system, analyze the CI / CD configuration file to obtain each build stage of the target code system and a corresponding command, execute the corresponding command of each build stage in the sandbox environment according to the build stage of the target code system, obtain a dependency relationship of the build stage of the target code system, establish a dependency chain of the build stage of the target code system based on the dependency relationship, mark a dependency type corresponding to the dependency chain, acquire a four-dimensional coordinate of the target code system according to the dependency relationship, and construct a four-dimensional dependency graph according to all four-dimensional coordinates, all dependency chains and corresponding dependency types. Thus, the CI / CD build process can be put into the sandbox environment, so that dynamic dependencies that cannot be recognized by static analysis can be captured, the problem that dependency relationships cannot be accurately recognized can be effectively solved, and the false negative rate can be greatly reduced. BRIEF DESCRIPTION OF THE DRAWINGS

[0078] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are merely embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without any creative work.

[0079] Figure 1 A schematic diagram of the structure of a system for processing code problems provided in an embodiment of the present application;

[0080] Figure 2 A flowchart of a method for handling code problems provided in an embodiment of the present application;

[0081] Figure 3 A flowchart of a method for creating a sandbox environment provided in another embodiment of the present application;

[0082] Figure 4 A flowchart of a method for obtaining a dependency relationship provided in another embodiment of the present application;

[0083] Figure 5 A flowchart of a method for obtaining a dependency chain provided in another embodiment of the present application;

[0084] Figure 6 A flowchart of a method for repairing a code problem provided in another embodiment of the present application;

[0085] Figure 7 A flowchart of a method for calculating a risk index according to another embodiment of the present application is provided;

[0086] Figure 8 A flowchart of a method for protecting against code problems provided in another embodiment of the present application;

[0087] Figure 9 A schematic structural diagram of a system for solving code problems provided in another embodiment of the present application. DETAILED DESCRIPTION

[0088] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0089] In this application, the terms such as first and second are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between such entities or operations. Moreover, the terms "include", "contain" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such a process, method, article or device. Without more limitations, the element defined by the statement "includes a" does not exclude the presence of additional identical elements in the process, method, article or device including the element.

[0090] The embodiment of the present application provides a code problem processing method applied to a code problem processing system to solve the problem that a dependency relationship cannot be accurately identified in the prior art.

[0091] Optionally, as shown in the figure, the processing system adopts a hierarchical design, and therefore the embodiment of the present application provides a code problem processing system including a data collection layer, an intelligent analysis layer and a response treatment layer, each layer realizes data interaction through a RESTful API, and ensures loose coupling and high expansibility between modules. Figure 1

[0092] The data collection layer includes a multi-SCM adapter cluster, a CI / CD log parser and a build environment sandbox.

[0093] (1) Multi-SCM (multi-source code management system) adapter cluster: realizing GitLab / GitHub API protocol conversion.

[0094] (2) CI / CD log parser: extracting dependency metadata in build logs such as GitHub Actions.

[0095] (3) Build environment sandbox: replaying the build process in an isolated container and intercepting dependency download requests.

[0096] The intelligent analysis layer includes a spatiotemporal dependency graph database, a code problem propagation prediction model and a compatibility matrix engine.

[0097] (1) Spatiotemporal dependency graph database: recording four-dimensional coordinates of dependency relationships.

[0098] (2) Code problem propagation prediction model: calculating code problem diffusion paths based on a graph neural network.

[0099] (3) Compatibility matrix engine: storing API compatibility data of each version component.

[0100] ​The response processing layer includes a hot patch distribution system and a virtual patch generator.

[0101] (1) Hot patch distribution system: patch cascade update is realized through K8s Operator.

[0102] (2) Virtual patch generator: intercept code problem trigger points at the bytecode level.

[0103] Therefore, based on the above-provided code problem processing system, the embodiments of the present application correspondingly provide a code problem processing method, as shown in the following steps: Figure 2

[0104] S201, create a sandbox environment and obtain a CI / CD configuration file of a target code system.

[0105] It can be understood that, in order to improve code security, maintainability and automatic management, a secure environment needs to be created to dynamically capture dependencies, so in the embodiments of the present application, the sandbox environment is used to capture dependencies of the target code system.

[0106] The sandbox environment provides a secure space isolated from the production environment, allowing developers, testers or automated tools to execute target code without directly affecting the operation of the real system. In this way, even if the executed code has vulnerabilities or is malicious code, it will not cause damage to the main system or data leakage risk, and the sandbox environment can isolate the target code from other system resources to avoid unnecessary interference or potential malicious activities.

[0107] In addition, after creating the sandbox environment, the CI / CD configuration file of the target code system needs to be obtained. The CI / CD (Continuous Integration / Continuous Delivery) configuration file helps manage and unify various aspects of software development, including code checking, unit testing, code quality analysis, build generation, etc., avoiding inconsistent processes used by different developers or teams.

[0108] It should be noted that the combination of the sandbox environment and the CI / CD configuration file helps to achieve more efficient version control and historical tracking. These configuration files record the history of code integration, change logs and deployment steps, making it easy for the team to track and audit the code change process, thereby better capturing the dependencies of the target code system.

[0109] It should also be noted that each CI / CD configuration file records the process of building, testing and deploying, helping the development team to master the history and evolution of the code.

[0110] The target code system refers to a multi-source code management system (SCM).

[0111] ​Optionally, in another embodiment of the present application, a specific implementation of creating a sandbox environment in step S201 includes the following steps, as shown in the following table: Figure 3

[0112] S301, create a target container and load a tool chain in the target container.

[0113] It can be understood that the target container refers to a lightweight and isolated running environment, such as a Docker container.

[0114] The tool chain usually includes a set of development, building, testing and other tools that can help automate the compilation, building, deployment and other processes, so the purpose of loading the tool chain in the target container is to ensure that all the required tools are included in the container so that the subsequent operations can be performed smoothly. Optionally, the tool chain can be JDK 11 and Node.js 16.

[0115] S302, after loading, inject a dependency interception hook in the target container through a preset injection tool.

[0116] It should be noted that in order to capture the dependency relationship in the subsequent process, the dependency download process can be recorded, so the dependency interception hook needs to be injected in the target container. The hook will intercept the loading of external dependencies, libraries or system calls inside the container, so that every operation performed by the container is under monitoring. This is very important for capturing unsafe operations, potential vulnerabilities or performance bottlenecks. Among them, the dependency interception hook can be an interceptor for Maven.

[0117] S303, based on the target container, the tool chain in the target container and the dependency interception hook, create a sandbox environment.

[0118] Specifically, through steps S301 and S302, the target container has been configured and loaded with the tool chain, and the interception hook has been injected, so a created sandbox environment can be obtained. The sandbox environment is an isolated running environment that can safely execute code, test and verify, preventing potential risks or errors from affecting the main system. This environment is completely independent and is usually used for security testing, performance analysis or other risk assessment of code. In a containerized environment, the sandbox is not only a running environment, but also a tool for monitoring and controlling all operations during running. In this way, it can be ensured that the code will not adversely affect the production environment or other systems.

[0119] S202, parse the CI / CD configuration file to obtain each build stage of the target code system and the corresponding command.

[0120] ​It can be understood that the CI / CD configuration file (such as GitHub Actions log, GitLab CI configuration file, Travis CI configuration file, etc.) defines the whole process of automated building. There are usually multiple building stages (such as compilation, testing, packaging, deployment, etc.) and specific commands required to be executed in each stage in these configuration files. By parsing these files, you can clearly understand the building process of the target code system, the tasks and dependencies of each stage. Building stage: may include compilation (build), testing (test), packaging (package), deployment (deploy), etc. Corresponding command: there will be a series of specific commands (such as mvn clean install, npm run build, docker build, etc.) in these stages to perform specific tasks in this stage, so the CI / CD configuration file can be parsed by the CI / CD log parser, and the dependency metadata in the build log such as GitHub Actions, wherein the dependency metadata can include each building stage of the target code system and the corresponding command of the building stage.

[0121] S203, for each building stage, execute the command corresponding to the building stage in the sandbox environment according to the building stage of the target code system, to obtain the dependency relationship corresponding to the building stage of the target code system.

[0122] It can be understood that by parsing the CI / CD configuration file in step S202, it is possible to execute the building command in a sandbox environment by stage. This can simulate the real building process, ensure that each stage is executed correctly according to the specified command, and capture the dynamic dependencies in each building stage (for example, some dependencies are downloaded at runtime), so that in this way it can help developers and testers understand the dependencies and changes in the building process in different environments, so as to have more information in the testing and optimization process.

[0123] Specifically, since each building stage in the process of the CI / CD configuration file usually produces some dependencies, these dependencies may be external libraries, modules or services downloaded during the compilation, testing or packaging process. Therefore, by executing the corresponding command in the sandbox environment according to the building stage, these dynamic dependencies can be captured and recorded.

[0124] Optionally, in another embodiment of the present application, a specific implementation of step S203 includes the following steps as shown in Figure 4

[0125] ​S401、respectively for each build stage, in the sandbox environment according to the build stage where the target code system is located, execute the command corresponding to the build stage to intercept the dependency download request of the target code system through the dependency interception hook in the sandbox environment.

[0126] It can be understood that for each build stage (such as compilation, testing, packaging, etc.) of the target code system, the command of the stage is executed in the sandbox environment, so as to ensure that the external environment or production environment will not be affected through sandbox isolation, and the dependency download request occurring in the build process will be intercepted through the dependency interception hook in the sandbox environment. These requests will usually try to download libraries, packages or modules from external resources. The goal of this step is to capture these download operations for further analysis and management.

[0127] S402、extract the version number, download time, dependency system data and dependency path of the target code system from the dependency download request.

[0128] Specifically, during each build process, the target code system may download some external dependencies, which may be external libraries, packages or other components. Therefore, through the intercepted download request, the following information can be extracted: version number: identify the specific version of the downloaded dependency. Download time: record the time when the dependency is downloaded. Dependency system data: indicates the source of the dependency, such as the remote repository or mirror image where the dependency is located. Dependency path: indicates the location or storage path of the dependency in the target code system.

[0129] S403、based on the version number, download time, dependency system and dependency path, generate the dependency relationship corresponding to the build stage where the target code system is located.

[0130] Optionally, through the version number, download time, dependency system and dependency path, etc. The dependency relationship diagram of this build stage can be generated. This dependency relationship diagram describes which external libraries, modules or components are downloaded during the build process, and what the relationship between these dependencies is. This can help developers better understand the architecture of the target code system dependencies, and track the use of specific versions of libraries or modules.

[0131] S204、based on the dependency relationship, establish the dependency chain of the build stage where the target code system is located, and mark the dependency type corresponding to the dependency chain.

[0132] It can be understood that the dependency chain refers to the hierarchical relationship between the target code system and each build stage dependency external library, module, package, etc. Each stage in the build process may depend on different external resources, which may be direct dependencies (libraries directly referenced in the build command) or indirect dependencies (libraries introduced by other dependencies).

[0133] Then, according to the type and transmission relationship of the dependency analyzed by the dependency chain, that is, whether it is a declarative dependency (direct dependency), a dynamic dependency (downloaded at runtime), or an implicitly transmitted dependency (indirectly introduced through other dependencies), the dependency type is marked by establishing the dependency chain, so that all external resources and their mutual relationships that the target code system and its construction stage depend on can be clearly understood. This helps to optimize dependency management, improve controllability and traceability of the construction process, avoid potential version conflicts, and ensure the stability and security of the system.

[0134] Optionally, in another embodiment of the present application, a specific implementation of establishing the dependency chain of the construction stage where the target code system is located based on the dependency relationship in step S204 includes the following steps: Figure 5

[0135] S501. Extract the dependency system data of the target code system from the dependency relationship.

[0136] Specifically, the dependency system data contains information about which external dependencies the target code system needs, the source, version, order, etc. of these dependencies.

[0137] All dependency information required by the target code system can be extracted by deconstructing the dependency items in the build tool configuration file (such as pom.xml, build.gradle, package.json, etc.).

[0138] S502. According to the dependency system data, obtain each dependency system that the target code system depends on.

[0139] It can be understood that in order to obtain the specific dependency systems that the target code system depends on in one step, the direct dependencies of the target code system need to be analyzed one by one, and the dependency system of each direct dependency needs to be extracted.

[0140] In addition, according to the definition of each direct dependency, its indirect dependencies can be identified. That is, if a direct dependency itself has other external dependencies, these external dependencies should also be included in the dependency range of the target code system, and then the dependency relationship of each dependency system is recursively extracted until all dependencies are identified and listed, and finally a list containing all dependency systems is obtained, which includes all direct and indirect dependencies that the target code system depends on.

[0141] S503. According to the dependency order in the dependency system data, construct the target code system and each dependency system to obtain the dependency chain of the construction stage where the target code system is located.

[0142] ​Specifically, in the dependency system data, there is usually order information of dependencies, for example, some dependencies must be built before other dependencies. The dependency order is determined by topological sorting or other methods.

[0143] First, according to the dependency order, the basic dependencies of the target system are built first, and then other dependent systems are built step by step, ensuring that the construction process of each dependent system does not violate the dependency relationship, and then according to the dependency order and the construction process of each dependency, a complete dependency chain is formed. This chain represents the sequential relationship from the target code system to all external dependent systems, and finally a complete dependency chain is obtained.

[0144] For example: GitLab project A→Bitbucket submodule B→GitHub dependent library C.

[0145] S205, according to the dependency relationship, obtaining the four-dimensional coordinates of the target code system.

[0146] It can be understood that according to the dependency management tool of the target code system (such as Maven, Gradle, NPM, etc.), the version, time, source and path of the dependency can be extracted from the CI / CD configuration file according to the dependency relationship, and by accessing the metadata of the repository or the local file system, the four-dimensional coordinate information of each dependency can be obtained. Four-dimensional coordinates refer to the four dimensions of recording dependencies, which usually include: version: version number of the dependency. Time: update time or modification time of the dependency. Source: source library or source of the dependency. Path: path or positioning method of the dependency.

[0147] S206, according to all four-dimensional coordinates, and all dependency chains and their corresponding dependency types, constructing a four-dimensional dependency graph.

[0148] It can be understood that constructing a four-dimensional dependency graph is a process of integrating all dependency information (version, time, source and path) in the target code system into a visual graph. By displaying all dependencies and their four-dimensional coordinates (including version, time, source and path) in a graph, developers and maintainers can more clearly understand the dependency relationship, version changes, timeline and other information of the project. Specifically, using a graphical tool to construct according to all four-dimensional coordinates, and all dependency chains and their corresponding dependency types.

[0149] Optionally, in addition to the problem that the target code system dependency cannot be identified, the dynamic dependency is difficult to capture, and the target code system may also have the problem of code problem repair and strategy conflict, therefore, in order to solve this kind of problem, in another embodiment of the present application, a code problem repair method is provided, as shown in Figure 6 The specific steps include:

[0150] S601, acquire an input parameter of a target code system.

[0151] The input parameter can include a current version, and can also include code problem information, business constraints, and SLA.

[0152] S602, query available secure versions of the target code system according to the current version.

[0153] Specifically, in order to ensure that the system can repair the problems in the current version while avoiding the introduction of new security vulnerabilities, compatibility problems or performance bottlenecks, thereby ensuring the security, stability and compliance of the system, while improving the repair efficiency. Therefore, the available secure versions in the target code system will be queried according to the current version information (for example, log4j-2.14.0). The specific process is as follows: first, the version currently in use needs to be identified, such as log4j-2.14.0. This will serve as the basis for the query, determining the available versions that follow, and then the available secure repair versions for that version will be queried from the secure version library. The secure version library contains versions that have been verified and have fixed known vulnerabilities or incompatibility issues. Finally, versions that are compatible with the current version and are secure will be listed, and the selected target secure version will be used as a candidate version for the subsequent repair path.

[0154] For example, assuming that log4j-2.14.0 has known vulnerabilities, a higher version repair version such as log4j-2.17.1 will be found after querying.

[0155] S603, calculate a risk index according to the available secure versions.

[0156] It can be understood that in order to quantitatively evaluate the risks and potential impacts brought by secure versions, help the development team make more informed decisions, and ensure that the system remains stable, compatible and performant while repairing security vulnerabilities, thereby achieving an efficient and low-risk repair process, it is necessary to calculate a risk index according to the available secure versions.

[0157] Optionally, in another embodiment of the present application, one specific implementation of step S603 includes the following steps as shown in Figure 7

[0158] S701, acquire the API variation degree and scheduling frequency of the available secure versions.

[0159] Specifically, the API variation degree refers to the degree of change in APIs (such as classes, methods, fields, etc.) between the new version and the current version. If the new version makes large-scale modifications to the interface, the variation degree is high, and the risk is also high.

[0160] ​Call frequency: refers to the frequency of using the API in the current version. If an API is used a lot, its changes will have a greater impact on the system.

[0161] S702, calculate the product of the scheduling frequency and the API change degree to obtain a risk index.

[0162] Specifically, the calculation formula of the risk index is: risk index = API change degree x call frequency.

[0163] S604, when the risk index is greater than a preset threshold, generating a version upgrade directed graph according to the current version, available safe versions and the risk index.

[0164] Each node in the version upgrade directed graph represents a version, and the edge between two connected nodes in the version upgrade directed graph represents an upgrade path, and the risk index between the two nodes is displayed on the edge connecting the nodes.

[0165] It should be noted that in order to help the development team clearly evaluate the risk when facing the selection of safe versions, select the optimal path, avoid high-risk operations, and ensure the stability, compatibility and security of the system during the system upgrade process, when the risk index is greater than the preset threshold, a version upgrade directed graph is constructed according to the current version, available safe versions and the risk index, and the risk index of each edge provides a quantitative basis for decision-making, so that the team can evaluate the potential impact of each upgrade path.

[0166] Optionally, when the risk index is not greater than the preset threshold, the available safe version is directly selected as the repair path, and the current version only needs to be upgraded to the available safe version.

[0167] S605, calculating the optimal upgrade path of the current version according to the version upgrade directed graph.

[0168] Specifically, after the version upgrade directed graph is constructed, the cumulative risk index of different paths needs to be calculated to select the path with the smallest risk index, so as to ensure that the upgrade does not introduce uncontrollable risks, and then by evaluating all paths, the most suitable version upgrade strategy is found to avoid function loss or performance problems during the upgrade process. It should be noted that the compatibility between versions also needs to be considered during calculation, and the path with the best compatibility is selected to ensure the stable operation of the system.

[0169] Therefore, the embodiments of the present application use Dijkstra algorithm to calculate the optimal upgrade path of the current version. Dijkstra algorithm is a classic shortest path algorithm that can find the shortest path from the starting point (current version) to the target (fixed version). In this problem, the shortest path not only refers to the number of version jumps, but also needs to consider the risk index of each jump to select a path with lower risk as much as possible.

[0170] For example, assuming from log4j-2.14.0 to log4j-2.17.1, the optimal upgrade path can be obtained through the following path: log4j-2.14.0→log4j-2.16.0→log4j-2.17.1.

[0171] S606, according to the optimal upgrade path, the upgrade of the target code system is evaluated, and the evaluation result is obtained.

[0172] It can be understood that in order to smoothly transition the system to the new version while repairing the path, the negative effects of the upgrade are reduced, so it is necessary to evaluate the upgrade effect of the optimal path to confirm whether the upgrade can repair the security vulnerability while ensuring the stability and compatibility of the system. That is, to evaluate the feasibility of the upgrade path, including the influence of code, system architecture and external dependencies. Ensure that the system after the final upgrade can meet the business requirements and can run normally. In the evaluation process, in addition to considering security and compatibility, the cost, time and resources required for testing of the upgrade also need to be evaluated to ensure that the security is ensured while trying to reduce the cost in other aspects.

[0173] For example, some fixes may cause updates to other associated libraries, so the system needs to evaluate whether other related components need to be upgraded at the same time, and then according to the repair scheme, the system may need to restart. Assuming that each update will cause a 5-minute restart time, the system needs to evaluate this impact in the repair path to ensure that it meets the SLA requirements.

[0174] Optionally, in addition to the dynamic dependency being difficult to capture and the target code system also having a code problem repair and policy conflict problem, it also involves emergency situations such as 0day code problems, so as to provide a protection mechanism in a timely manner, so in another embodiment of the present application, a code problem protection method is provided, as shown in Figure 8 The method specifically comprises the following steps:

[0175] S801, detecting whether the target code system has a preset vulnerability.

[0176] It can be understood that in order to deal with emergency situations such as 0day code problems, a real-time protection mechanism can be provided, so it is necessary to detect in real time whether the target code system has a preset vulnerability, and if the target code system has a preset vulnerability, the protection mechanism needs to be started, so step S802 is executed.

[0177] Optionally, if the target code system does not have a preset vulnerability, the protection mechanism does not need to be started, and the detection of the target code system continues.

[0178] S802, obtaining the code problem characteristics of the target code system from the cloud.

[0179] Specifically, when the target code system has a preset vulnerability, the cloud will push the latest feature code to the local system according to real-time data or changes in security problems. The push mechanism of the cloud ensures that the latest security information can reach the local in a timely manner for protection.

[0180] S803, locally checking the code problem feature.

[0181] Specifically, after receiving the feature code pushed by the cloud, the code problem feature is checked for digital signature to ensure the legality and integrity of the feature code. The digital signature is generated by encrypting the rule file with a private key. This signature can ensure that the file has not been tampered with during transmission.

[0182] First, the signature of the code problem feature is decrypted using the public key, and then the decrypted data is compared with the file itself to confirm that the file content has not been tampered with.

[0183] S804, determining whether the code problem feature passes the local check.

[0184] Specifically, if the code problem feature passes the local check, it means that the code problem feature has not been tampered with, so step S805 is executed.

[0185] If the code problem feature does not pass the local check, it means that the code problem feature has been tampered with. At this time, the code problem feature of the target code system can be reacquired from the cloud until the code problem feature passes the local check.

[0186] S805, loading the code problem feature to the local, and in the loading process, inserting bytecode in the code problem feature to obtain the vulnerability trigger point of the target code.

[0187] It can be understood that when the code problem feature passes the local verification, the verified code problem feature is dynamically loaded into the local protection module and immediately takes effect without stopping the system or service. In the loading process, the code problem feature is parsed to identify the defined vulnerability features or attack patterns, and then these features are inserted into the target code through bytecode instrumentation technology. Bytecode instrumentation can insert additional security check code into specific code segments (such as functions, methods or classes) to monitor and prevent the triggering of vulnerabilities in real time.

[0188] Specifically, before the execution of a specific function or method, security check logic is inserted to check the legitimacy of input data, preventing buffer overflow, SQL injection, and other issues. In the code problem features, markers are inserted, and when the program executes to these marker positions, security checks are triggered to ensure that no operations that may cause vulnerabilities are performed. For example, security verification can be added before performing sensitive operations such as database access and file operations, so that through the instrumented bytecode, potential attacks or unsafe operations can be dynamically intercepted. Vulnerability detection is performed at runtime, and according to the rules, interception or repair is performed.

[0189] In addition, the inserted bytecode will monitor in real time whether a vulnerability trigger occurs. If the trigger point is activated, the vulnerability trigger point will be intercepted in time and recorded, so that by loading the code problem features and inserting the bytecode, the vulnerability trigger point of the target code can be detected and repaired at runtime. This method effectively combines feature code hot loading and virtual patch injection technology to provide an efficient and flexible dynamic security protection mechanism for the system.

[0190] S806, according to the vulnerability trigger point, protecting the target code system to obtain a protection result.

[0191] It can be understood that when the inserted bytecode detects a vulnerability trigger point, appropriate measures are taken for protection to obtain a protection result. For example, if it is a SQL injection vulnerability, the system can prevent data leakage or database damage by refusing to execute malicious SQL statements.

[0192] For known vulnerabilities, virtual patching technology can be used to dynamically repair the target code without modifying the source code or redeploying the application. This repair usually patches vulnerabilities through bytecode modification at runtime, thereby avoiding further exploitation of vulnerabilities.

[0193] Specifically, if a vulnerability is triggered, the system will not only prevent further malicious behavior, but also record detailed log information to help developers track the attack source and vulnerability type, providing support for subsequent analysis and repair.

[0194] The application provides a code problem processing method, which comprises the following steps: creating a sandbox environment, and obtaining a CI / CD configuration file of a target code system; analyzing the CI / CD configuration file to obtain each build stage of the target code system and corresponding commands; executing the corresponding commands of each build stage in the sandbox environment according to the build stage where the target code system is located, obtaining the corresponding dependency relationship of the build stage where the target code system is located, establishing a dependency chain of the build stage where the target code system is located based on the dependency relationship, and marking the dependency type corresponding to the dependency chain; obtaining the four-dimensional coordinates of the target code system according to the dependency relationship; and constructing a four-dimensional dependency graph according to all the four-dimensional coordinates, all the dependency chains and the corresponding dependency types. Thus, the CI / CD build process is put into the sandbox environment, so that dynamic dependencies that cannot be recognized by static analysis can be captured, thereby effectively solving the problem of being unable to accurately recognize dependency relationships, and the false negative rate is greatly reduced.

[0195] Another embodiment of the application provides a code problem processing system, as shown in the following table: Figure 9 The system comprises the following units:

[0196] A creating unit 901 is configured to create a sandbox environment and obtain a CI / CD configuration file of a target code system.

[0197] An analyzing unit 902 is configured to analyze the CI / CD configuration file to obtain each build stage of the target code system and corresponding commands.

[0198] An executing unit 903 is configured to execute the corresponding commands of each build stage in the sandbox environment according to the build stage where the target code system is located, and obtain the corresponding dependency relationship of the build stage where the target code system is located.

[0199] An establishing unit 904 is configured to establish a dependency chain of the build stage where the target code system is located based on the dependency relationship, and mark the dependency type corresponding to the dependency chain.

[0200] A four-dimensional coordinate obtaining unit 905 is configured to obtain the four-dimensional coordinates of the target code system according to the dependency relationship.

[0201] A graph constructing unit 906 is configured to construct a four-dimensional dependency graph according to all the four-dimensional coordinates, all the dependency chains and the corresponding dependency types.

[0202] It should be noted that the specific working processes of the above modules in the embodiments of the application can be correspondingly referred to steps S101-S106 in the above method embodiments, which will not be described here.

[0203] Optionally, another embodiment of the present application provides a code problem processing system, wherein the creating unit 901 comprises:

[0204] The loading unit is configured to create a target container and load a tool chain in the target container.

[0205] The injecting unit is configured to inject a dependency interception hook into the target container through a preset injection tool after the loading is completed.

[0206] The creating sub-unit is configured to create a sandbox environment based on the target container, the tool chain in the target container and the dependency interception hook.

[0207] Optionally, another embodiment of the present application provides a code problem processing system, wherein the executing unit 903 comprises:

[0208] The executing sub-unit is configured to execute a command corresponding to a build phase in the sandbox environment according to a build phase in which the target code system is located, so as to intercept a dependency download request of the target code system through the dependency interception hook in the sandbox environment.

[0209] The data extracting unit is configured to extract a version number, a download time, dependency system data and a dependency path of the target code system from the dependency download request.

[0210] The generating unit is configured to generate a dependency relationship corresponding to the build phase in which the target code system is located based on the version number, the download time, the dependency system data and the dependency path.

[0211] Optionally, another embodiment of the present application provides a code problem processing system, wherein the establishing unit 904 comprises:

[0212] The extracting unit is configured to extract dependency system data of the target code system from the dependency relationship.

[0213] The first acquiring unit is configured to acquire each dependency system relied on by the target code system according to the dependency system data.

[0214] The building unit is configured to build the target code system and each dependency system according to a dependency order in the dependency system data, so as to obtain a dependency chain of the build phase in which the target code system is located.

[0215] Optionally, another embodiment of the present application provides a code problem processing system, further comprising:

[0216] The parameter acquiring unit is configured to acquire an input parameter of the target code system, wherein the input parameter at least comprises a current version.

[0217] The querying unit is configured to query an available security version of the target code system according to the current version.

[0218] an index calculation unit, configured to calculate a risk index according to the available security version.

[0219] a graph generation unit, configured to generate a version upgrade directed graph according to the current version, the available security version and the risk index when the risk index is greater than a preset threshold, wherein each node in the version upgrade directed graph represents a version, and an edge between two connected nodes in the version upgrade directed graph represents an upgrade path, and the risk index between the two nodes is displayed on the edge connecting the nodes.

[0220] a path calculation unit, configured to calculate an optimal upgrade path of the current version according to the version upgrade directed graph.

[0221] an evaluation unit, configured to evaluate the upgrade of the target code system according to the optimal upgrade path to obtain an evaluation result.

[0222] Optionally, another embodiment of the present application provides a code problem processing system, and an index calculation unit comprises:

[0223] a second acquisition unit, configured to acquire an API change degree and a scheduling frequency of the available security version.

[0224] a calculation unit, configured to calculate a product of the scheduling frequency and the API change degree to obtain the risk index.

[0225] Optionally, another embodiment of the present application provides a code problem processing system, and the system further comprises:

[0226] a detection unit, configured to detect whether a preset vulnerability exists in the target code system.

[0227] a third acquisition unit, configured to acquire a code problem feature of the target code system from a cloud end if the preset vulnerability exists in the target code system.

[0228] a verification unit, configured to perform local verification on the code problem feature.

[0229] an insertion unit, configured to load the code problem feature into the local if the code problem feature passes the local verification, and obtain a vulnerability trigger point of the target code by inserting a bytecode into the code problem feature in a loading process.

[0230] a protection unit, configured to perform protection on the target code system according to the vulnerability trigger point to obtain a protection result.

[0231] It should be noted that the specific working processes of the various modules provided in the above embodiments of the present application can be correspondingly referred to the corresponding steps in the above method embodiments, which will not be described here.

[0232] It should be further noted that the code problem processing system provided by the embodiments of the present application has the technical effects of any one of the above embodiments, and the embodiments of the present application will not be repeated here.

[0233] Those skilled in the art will further appreciate that the units and algorithms described in connection with the examples disclosed herein can be embodied directly in hardware, in software, or in a combination of the two. To the extent that the described functionality is implemented in software, the functions can be stored and executed in one or more of the central processing units 1010. A sentry or watchdog timer can be used to monitor the execution of the software and to reset the system if the software does not meet predefined criteria. As such, the software can be monitored and controlled during execution.

[0234] The above description of disclosed embodiments provides enough information to enable those with skill in the art to make and use the application. Various modifications will be readily apparent to those skilled in the art, and the generic principles defined herein can be applied to other embodiments without departing from the spirit or scope of the application. Accordingly, the application is not to be restricted as only described in the description herein but is to be defined by the claims and their equivalents in the broadest sense.

Claims

1. A method for handling code problems, characterized in that: include: Create a sandbox environment and obtain the CI / CD configuration file of the target code system; Parsing the CI / CD configuration file to obtain each construction phase of the target code system and its corresponding commands; For each of the construction stages, respectively, in the sandbox environment, according to the construction stage of the target code system, executing commands corresponding to the construction stage, and obtaining a dependency relationship corresponding to the construction stage of the target code system; Based on the dependency relationship, a dependency chain of the target code system in the construction phase is established, and a dependency type corresponding to the dependency chain is marked; According to the dependency relationship, obtaining the four-dimensional coordinates of the target code system; Construct a four-dimensional dependency graph based on all four-dimensional coordinates, all dependency chains and their corresponding dependency types.

2. The method according to claim 1, characterized in that The step of creating a sandbox environment includes: Create a target container and load the toolchain in the target container; After loading is completed, the dependency interception hook is injected into the target container through the preset injection tool; A sandbox environment is created based on the target container, the tool chain in the target container, and the dependency interception hook.

3. The method according to claim 1, characterized in that For each of the construction stages, executing commands corresponding to the construction stage in the sandbox environment according to the construction stage of the target code system to obtain the dependency relationship corresponding to the construction stage of the target code system includes: For each of the construction stages, executing commands corresponding to the construction stage in the sandbox environment according to the construction stage of the target code system, so as to intercept the dependency download request of the target code system through the dependency interception hook in the sandbox environment; Extracting the version number, download time, dependent system data and dependent path of the target code system dependency from the dependency download request; Based on the version number, the download time, the dependent system and the dependent path, a dependency relationship corresponding to the construction phase of the target code system is generated.

4. The method according to claim 1, wherein The step of establishing a dependency chain for the target code system in the construction phase based on the dependency relationship includes: extracting dependent system data of the target code system from the dependency relationship; According to the dependent system data, obtaining each dependent system on which the target code system depends; According to the dependency order in the dependency system data, the target code system dependency and each of the dependency systems are constructed to obtain a dependency chain of the target code system at the construction stage.

5. The method according to claim 1, wherein Also includes: Obtaining input parameters of the target code system; wherein the input parameters include at least the current version; According to the current version, querying the available secure version of the target code system; Calculating a risk index based on the available security versions; When the risk index is greater than a preset threshold, a version upgrade directed graph is generated based on the current version, the available safe version, and the risk index; wherein each node in the version upgrade directed graph represents a version; an edge between two connected nodes in the version upgrade directed graph represents an upgrade path, and the risk index between the two nodes is displayed on the edge connecting the nodes; Calculating the optimal upgrade path for the current version based on the version upgrade directed graph; The upgrade of the target code system is evaluated according to the optimal upgrade path to obtain an evaluation result.

6. The method according to claim 5, characterized in that Calculating a risk index according to the available security version includes: Obtain the API change degree and scheduling frequency of the available security version; The product of the scheduling frequency and the API volatility is calculated to obtain a risk index.

7. The method according to claim 1, characterized in that Also includes: Detecting whether the target code system has a preset vulnerability; If the target code system has the preset vulnerability, obtaining the code problem feature of the target code system from the cloud; Performing local verification on the code problem characteristics; If the code problem feature passes the local verification, the code problem feature is loaded into the local computer, and during the loading process, bytecode is inserted into the code problem feature to obtain the vulnerability trigger point of the target code; According to the vulnerability trigger point, the target code system is protected to obtain a protection result.

8. A system for processing code problems, characterized in that: include: Create a unit to create a sandbox environment and obtain the CI / CD configuration file of the target code system; A parsing unit, configured to parse the CI / CD configuration file to obtain the various construction phases of the target code system and their corresponding commands; An execution unit is configured to execute, for each of the construction stages, in the sandbox environment according to the construction stage of the target code system, a command corresponding to the construction stage, and obtain a dependency relationship corresponding to the construction stage of the target code system; An establishing unit, configured to establish a dependency chain for the construction phase of the target code system based on the dependency relationship, and mark a dependency type corresponding to the dependency chain; A four-dimensional coordinate acquisition unit, configured to acquire the four-dimensional coordinates of the target code system according to the dependency relationship; The graph construction unit is used to construct a four-dimensional dependency graph based on all four-dimensional coordinates, all dependency chains and their corresponding dependency types.

9. The system according to claim 8, characterized in that The creation unit includes: A loading unit, configured to create a target container and load a toolchain into the target container; An injection unit, configured to inject a dependency interception hook into the target container using a preset injection tool after loading is completed; A subunit is created, which is used to create a sandbox environment based on the target container, the tool chain in the target container, and the dependency interception hook.

10. The system according to claim 8, wherein: The execution unit includes: an execution subunit, configured to execute, for each of the construction stages, in the sandbox environment according to the construction stage of the target code system, a command corresponding to the construction stage, so as to intercept the dependency download request of the target code system through the dependency interception hook in the sandbox environment; A data extraction unit, configured to extract the version number, download time, dependent system data, and dependent path of the target code system dependency from the dependency download request; A generating unit is configured to generate a dependency relationship corresponding to the construction phase of the target code system based on the version number, the download time, the dependent system, and the dependent path.

Images