A vulnerability fixing method, device, equipment and storage medium

Abstract

The present specification relates to the technical field of system security, and particularly relates to a vulnerability repair method and device, equipment and a storage medium. The method comprises the following steps: scanning a running state application process by using a vulnerability detection intelligent agent to obtain a running state path of the application process; matching the running state path of the application process with a path feature table, wherein the path feature table at least comprises a feature path and a vulnerability repair script identifier; obtaining a vulnerability repair script according to the vulnerability repair script identifier corresponding to the matched controlled component; and injecting the feature path into the vulnerability repair script and executing the vulnerability repair script. The vulnerability repair can be automatically completed, and the labor cost is saved.

Description

Technical Field

[0001] This specification relates to the field of system security technology, and in particular to a vulnerability repair method, apparatus, device, and storage medium. Background Technology

[0002] In today's software development environment, open-source components are commonly used to improve development efficiency. However, some of these components contain vulnerabilities, which could stem from coding errors or deliberate malicious intent. If these vulnerabilities are exploited, they could cause serious business incidents. Such vulnerable components are called risky components. Existing remediation solutions are based on recommendations made by security personnel when vulnerabilities are discovered, addressing the issue by upgrading risky components.

[0003] Current vulnerability remediation technologies primarily rely on a multi-stage linear process, involving periodic vulnerability detection, analysis of common vulnerability and vulnerability exposure (CVE) information, investigation of affected components, tracking of remediation results, and secondary scanning verification. The entire process of vulnerability self-detection, remediation, and verification is often completed manually or semi-automatically by the security team.

[0004] Therefore, how to automatically fix component vulnerabilities is an urgent problem to be solved. Summary of the Invention

[0005] To address the problems in the prior art, embodiments of this specification provide a vulnerability repair method, apparatus, device, and storage medium, which solves the problems of low efficiency and high cost in the prior art that rely on manual vulnerability repair.

[0006] This specification provides an embodiment of a vulnerability remediation method, including: By using a vulnerability detection agent to scan running application processes, the running paths of the application processes can be obtained. The running path of the application process is matched with the path feature table, wherein the path feature table includes at least the feature path and the vulnerability remediation script identifier. Based on the vulnerability remediation script identifier corresponding to the matched controlled component, the vulnerability remediation script is obtained; The characteristic path is injected into the vulnerability remediation script, and the vulnerability remediation script is executed.

[0007] As a further aspect of this specification, it also includes: when the application goes online, recording the characteristic paths of all controlled components in the application and the vulnerability remediation script identifiers of the controlled components to form the path characteristic table.

[0008] As a further aspect of this specification, based on the vulnerability remediation script identifier corresponding to the matched controlled component, the vulnerability remediation script further includes: Match the vulnerability repair script identifier in the vulnerability repair script library to find the corresponding vulnerability repair script.

[0009] As a further aspect of this specification, it also includes: updating the vulnerability patching scripts for different controlled components in the vulnerability patching script library according to predetermined rules.

[0010] As a further aspect of this specification, the use of a vulnerability detection agent to scan runtime application processes to obtain the runtime path of the application process further includes: By scanning the running application, the physical memory address of the application's environment variables can be obtained; Obtain at least one candidate running path of the application process based on the physical memory address of the environment variable.

[0011] As a further aspect of this specification, the use of a vulnerability detection agent to scan runtime application processes to obtain the runtime path of the application process further includes: Determine whether the running application is running inside a container; If it runs within a container, then by combining the path of the container and the path of the container's host machine, at least one candidate running state path for the application process is obtained.

[0012] As a further aspect of this specification, the at least one candidate running path is scored according to a preset scoring rule, and the candidate running path with the highest score is selected as the running path.

[0013] As a further aspect of this specification, the preset scoring rules include at least one of the following rules: If the candidate runtime path is obtained through the path of the container and the path of the container's host machine, then verify whether the candidate path actually exists in the file system of the host machine. If it exists, increase the score of the candidate runtime path; otherwise, do not score it. Extract multiple keywords from the candidate running path, and increase the score of the candidate running path based on the number of matches of the multiple keywords in the key feature word library.

[0014] This specification also provides a vulnerability remediation device, including: The runtime path acquisition unit is used to scan runtime application processes using a vulnerability detection agent to obtain the runtime path of the application process. A matching unit is used to match the running path of the application process with a path feature table, wherein the path feature table includes at least a feature path and a vulnerability repair script identifier. The script acquisition unit is used to obtain the vulnerability remediation script based on the vulnerability remediation script identifier corresponding to the matched controlled component; The repair unit is used to inject the characteristic path into the vulnerability repair script and execute the vulnerability repair script.

[0015] This specification also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method described above.

[0016] This specification also provides a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the above-described method.

[0017] This specification also provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described method.

[0018] Using the examples in this specification, vulnerability patching can be automated, saving manpower costs. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 The diagram shown is a schematic representation of a vulnerability repair system according to an embodiment of this specification. Figure 2 The diagram shown is a flowchart of a vulnerability repair method according to an embodiment of this specification; Figure 3 The diagram shown is a flowchart of another vulnerability repair method according to an embodiment of this specification; Figure 4 The diagram shown is a structural schematic of a vulnerability repair device according to an embodiment of this specification. Figure 5 The image shown is a computer device provided in an embodiment of this specification.

[0021] [Explanation of Labels in the Attached Image]

[0022] 101. Application Server; 102. Vulnerability Detection Intelligent Agent; 103. Vulnerability remediation server; 104. Vulnerability remediation database; 1041. Path Feature Table; 1042. Vulnerability remediation script library; 401. Running Path Acquisition Unit; 402. Matching unit; 403. Script Acquisition Unit; 404, Repair Unit; 502. Computer equipment; 504, Processor; 506. Memory; 508. Drive mechanism; 510. Input / output module; 512. Input devices; 514. Output devices; 516. Presentation equipment; 518. Graphical User Interface; 520. Network interface; 522. Communication link; 524. Communication bus. Detailed Implementation

[0023] The technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this specification.

[0024] It should be noted that the acquisition, storage, use, and processing of data in the technical solution of this application all comply with the relevant provisions of relevant laws and regulations.

[0025] It should be noted that in the embodiments of this specification, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, they do not mean that the applicant has used or necessarily used the solution.

[0026] like Figure 1The diagram shown is a schematic of a vulnerability repair system according to an embodiment of this specification. It may include: an application server 101, a vulnerability detection agent 102, a vulnerability repair server 103, and a vulnerability repair database 104. The vulnerability repair database 104 further includes a path feature table 1041 and a vulnerability repair script library 1042. The vulnerability detection agent 102 is located within the application server 101. The application server 101, the vulnerability repair server 103, and the vulnerability repair database 104 communicate via a network, which may include a local area network (LAN), a wide area network (WAN), the Internet, or a combination thereof. Application server 101 runs various applications to implement various service functions. Vulnerability detection agent 102 scans running applications by embedding itself inside the application server 101 system and obtains the running paths of the running applications. Vulnerability repair server 103 matches the running paths in the path feature table 1041 in the vulnerability repair database 104, finds the matching record, obtains the corresponding vulnerability repair script identifier, and obtains the vulnerability repair script from the vulnerability repair script library 1042 according to the vulnerability repair script identifier. The vulnerability repair server 103 injects the feature path into the vulnerability repair script and executes the vulnerability repair script to repair the vulnerability of application server 101.

[0027] In the embodiments described in this specification, the application server 101, the vulnerability repair server 103, and the vulnerability repair database 104 can be independent physical servers, or server clusters or distributed systems composed of multiple physical servers. They can also be cloud servers that provide basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.

[0028] In an optional embodiment, the application server 101 may include, but is not limited to, various electronic devices. Optionally, the operating system running on the electronic device may include, but is not limited to, Android, iOS, Linux, Windows, etc. Of course, the application server 101 is not limited to the aforementioned physical electronic devices; it may also be software running on the aforementioned electronic devices.

[0029] In addition, it should be noted that, Figure 1 The example shown is merely one application environment provided in this disclosure. In practical applications, it may also include multiple application servers 101 and multiple vulnerability repair servers 103. This specification does not impose any restrictions.

[0030] The embodiments in this specification provide, for example Figure 2 The diagram shows a flowchart of a vulnerability repair method according to an embodiment of this specification. This specification provides the operational steps of the method described in the embodiment or flowchart, but based on conventional or non-inventive labor, more or fewer operational steps may be included. The order of steps listed in the embodiment is merely one possible execution order among many and does not represent the only possible execution order. In actual system or device products, the method can be executed sequentially or in parallel according to the embodiment or the accompanying drawings. The diagram illustrates how to obtain the running path of an application process by scanning the running application process. When a vulnerability risk exists in the running path of a process, the vulnerability repair script of the controlled component can be matched through the running path. The vulnerability repair script and the characteristic path of the corresponding controlled component are used to achieve the purpose of automatic repair of the application vulnerability, eliminating the need to manually locate the application where the vulnerability risk occurs and manually repair the vulnerability. Specifically, this includes: Step 201: Use a vulnerability detection agent to scan the running application process to obtain the running path of the application process; Step 202: Match the running path of the application process with the path feature table, wherein the path feature table includes at least the feature path and the vulnerability repair script identifier. Step 203: Obtain the vulnerability remediation script based on the vulnerability remediation script identifier corresponding to the matched controlled component; Step 204: Inject the characteristic path into the vulnerability repair script and execute the vulnerability repair script.

[0031] The methods described in this specification can automatically detect application vulnerabilities and fix them using corresponding vulnerability repair scripts, eliminating the need for manual path searching and script adaptation. This reduces vulnerability repair time from "days" to "minutes," saving manpower costs and improving repair efficiency. The runtime path capture also solves the problem of repair failures caused by custom directories.

[0032] In the embodiments of this specification, when the application is launched, the characteristic paths of all controlled components in the application and the vulnerability repair script identifiers of the controlled components are recorded to form the path characteristic table.

[0033] In this embodiment, before the application goes live, software composition analysis tools (such as Syft and Trivy) are used to scan the application's container image or file system to automatically identify all dependent components and their installation locations. The application's deployment configuration files (such as Ansible Playbooks, Terraform scripts, and Kubernetes manifests) are parsed to extract the component installation directory variables.

[0034] The actual installation path of the Java application server is determined by identifying environment variables (such as CATALINA_HOME and TOMCAT_HOME). The obtained path is then standardized and normalized, removing dynamically changing parts such as version numbers, while retaining core characteristics (such as / opt / tomcat instead of / opt / tomcat-9.0.65). These environment variables are runtime configuration parameters provided by the operating system to processes; they exist as key-value pairs and specify the runtime environment of the system or application. A process may have multiple path-related environment variables.

[0035] The path feature table includes the vulnerability name, component name (or component ID), feature path, and vulnerability remediation script identifier. The vulnerability name ensures that the extracted path was indeed triggered for remediation due to a specific vulnerability (such as Log4j), preventing false positives. The component name distinguishes components; for example, essentially the same component might have a special version from a particular company and a regular open-source version. The two versions perform similar functions but have different characteristics. The feature path records the physical root directory of the component in a standard installation (e.g., / opt / tomcat). The vulnerability remediation script identifier indexes vulnerability remediation scripts in the vulnerability remediation script library. For example, see Table 1 below:

[0036] In the embodiments of this specification, the scanning of runtime application processes by a vulnerability detection agent to obtain the runtime path of the application process further includes: By scanning the running application, the physical memory address of the application's environment variables can be obtained; Obtain at least one candidate running path of the application process based on the physical memory address of the environment variable.

[0037] In this embodiment, when scanning the running application to obtain the physical memory address of the application's environment variables, the application's virtual memory region can be obtained first. Executable and private memory segments within the virtual memory region are then filtered out. The addresses of these memory segments are converted to physical page frame numbers, and the physical memory addresses of the environment variables within them are determined based on these page frame numbers. The virtual memory region is a contiguous virtual address range (such as a code segment, heap, or stack), with independent access permissions (read / write / execute) and attributes (anonymous / file mapping). It is a kernel-managed memory mapping data structure; for example, kernel data structures can be directly accessed via system calls to obtain information about the virtual memory region. The r-xp memory segments within the virtual memory region are filtered out. The r-xp permissions mean: r indicates readable, - indicates non-writable, x indicates executable, and p indicates private. These memory segments typically contain the process's binary code and core libraries (such as / bin / bash and / lib / libc.so), which are the basic code executed by the process. By analyzing these memory segments, the application's true entry point and dependent library paths can be located, avoiding misleading information from tampered command-line parameters. The virtual memory start and end addresses of the memory segment are converted using the physical page table to obtain the actual memory location of the memory segment. This location can be represented by a block device number and a block number. The block device number identifies the storage device (e.g., a hard disk partition), with the format major device number:minor device number (e.g., 08:02 represents the second partition of a SCSI hard disk). The block number is the index of a logical block in the file system, determined by the block pointer array in the inode structure. Based on the physical page frame number of the memory segment, the complete environment variable block of the application process (a contiguous area storing environment variables in process memory) is read from the physical memory. This block contains all environment variables and their values ​​(e.g., PATH= / bin: / usr / bin). The physical page frame number of the memory segment allows the retrieval of the environment variable block stored in a binary stream format in physical memory. Environment variables within the block are separated by null bytes (\0), with the format: Var1=Value1\0Var2=Value2\0...\0\0. This binary stream contains the byte distribution pattern, reflecting the physical memory layout structure. Files may lose byte separation information, making it impossible to accurately reconstruct the memory layout structure. Based on the null bytes between environment variables in the environment variable block, the exact location of the environment variable in physical memory can be identified. The null byte (\0) at the end of the environment variable value in the environment variable block serves as a padding boundary marker. By analyzing the distribution pattern of null bytes (such as the position of consecutive null bytes), the physical memory location of the environment variable can be accurately located. Since the physical memory location of the environment variable is determined based on the physical page frame number, that is, the environment variable is obtained within a trusted physical page, it can be guaranteed that the environment variable has not been dynamically tampered with (e.g., virtual environment variable data forged by a rootkit), thus ensuring its reliability.

[0038] In obtaining at least one candidate runtime path for the application process based on the physical memory address of the environment variables, a feature string corresponding to the candidate runtime path is identified in the physical memory address of the environment variables, and the identified feature string is converted into the candidate runtime path. The feature string may include, for example, a binary string corresponding to JAVA_HOME and a binary string corresponding to CATALINA_BASE. JAVA_HOME is the root directory of the Java runtime environment (e.g., / usr / lib / jvm / java-11), and CATALINA_BASE is the base directory of the Tomcat server (containing critical paths such as bin and conf).

[0039] In the embodiments of this specification, the scanning of runtime application processes by a vulnerability detection agent to obtain the runtime path of the application process further includes: Determine whether the running application is running inside a container; If it runs within a container, then by combining the path of the container and the path of the container's host machine, at least one candidate running state path for the application process is obtained.

[0040] In this embodiment, the presence of a running application within a container is determined by comparing the process's mounted namespace with the host machine's mounted namespace. For example, this can be achieved using the process's inode number (index node number), which uniquely identifies the process's mounted namespace. The inode number is compared to the host machine's inode number; if they match, the process is not within a container; otherwise, it resides in an independent namespace, indicating that the process is running within a container. This avoids misinterpreting the process's path within the container as a path on the host machine. If the process is running within a container, the path within the container is combined with the path on the container's host machine to form at least one candidate running path for the application process. For example, if the application process's path within the container is / app / tomcat, this can be determined using readlink / proc / . <pid>The ` / root` directive retrieves the actual mount point path on the host machine. Finally, the candidate run-state path of the application process on the host machine might be ` / var / lib / docker / overlay2 / ... / diff / app / tomcat`.

[0041] A process may have multiple environment variables pointing to different paths (such as JAVA_HOME, CATALINA_HOME, PATH, etc.), the application may read path information from multiple configuration files, the application may cache multiple paths in memory, and the mapping relationship between the container path and the host machine path may involve multiple levels and may obtain multiple candidate runtime paths.

[0042] In the embodiments of this specification, the at least one candidate running path is scored according to a preset scoring rule, and the candidate running path with the highest score is selected as the running path.

[0043] In this embodiment, the preset scoring rules include, for example, one of the following: If the candidate runtime path is obtained through the path of the container and the path of the container's host machine, then verify whether the candidate path actually exists in the file system of the host machine. If it exists, increase the score of the candidate runtime path; otherwise, do not score it. Extract multiple keywords from the candidate running path, and increase the score of the candidate running path based on the number of matches of the multiple keywords in the key feature word library.

[0044] The candidate runtime path is obtained through the path of the container and the path of the container's host machine. The candidate runtime path is the physical path of the host machine. A system call (e.g., access(path, F_OK)) is used to check the existence of the candidate runtime path in the host machine's file system. If it exists, a corresponding score is added to the score item of the candidate runtime path. If the candidate runtime path exists, it can be further verified whether it is located within the physical memory page range corresponding to the memory segment to ensure the security of the candidate runtime path, and additional points can be added to the score item. Alternatively, the candidate runtime paths of application processes running in containers at different levels can be scored differently based on the container's hierarchical relationship (number of image layers or mount depth).

[0045] Multiple keywords are extracted from the candidate runtime path. Based on the number of matches of the multiple keywords in the key feature word library, the extracted keywords are matched with the preset key feature word library. The key feature word library includes keywords such as bin, lib, conf, tomcat, java, and spring. The keywords in the candidate runtime path are divided into different levels. Successful matching of keywords at different levels means adding different scores to the candidate runtime path. For example, the score for path level matching (such as / bin) is higher than that for filename matching (such as mybin.jar).

[0046] In other embodiments, the scores of candidate running paths obtained according to different preset scoring rules can also be obtained by weighted decision-making to obtain a weighted score, and then the candidate running path with the highest score is selected as the running path based on the weighted score.

[0047] In the embodiments of this specification, before executing the vulnerability repair script, the method further includes: taking a snapshot backup of the original files of the target application targeted by the vulnerability repair script; and during the execution of the vulnerability repair script, monitoring the return code of the vulnerability repair script, the business process inventory status and port availability in real time. If a repair anomaly is detected, the target application is restored using the snapshot backup.

[0048] The methods described in this specification can automatically detect application vulnerabilities and fix them using corresponding vulnerability remediation scripts, eliminating the need for manual path searching and script adaptation. This reduces vulnerability remediation time from "days" to "minutes," saving manpower costs and improving remediation efficiency. The runtime path capture solves the problem of remediation failures caused by custom directories. Furthermore, the built-in automated rollback mechanism ensures high availability of services, achieving automated operation of the entire vulnerability lifecycle from discovery, analysis, handling to verification.

[0049] like Figure 3 The diagram shown is a flowchart of another vulnerability repair method according to an embodiment of this specification. This diagram illustrates the overall process using Log4j vulnerability repair as an example, wherein: Step 301: Establish a path feature table.

[0050] In this step, the latest vulnerability information can be periodically obtained from national vulnerability databases (such as NVD and CNNVD) and commercial vulnerability intelligence services. During the security scanning phase before application deployment, tools (such as Trivy and Syft) will detect known vulnerabilities in components and record their names. Standardized component names, such as Apache Tomcat, Spring Framework, and OpenSSL, are parsed from system development manuals or manifests. The default installation path of the component in mainstream operating systems or container images is obtained from the component's installation specifications; or, during application deployment, the actual installation root directory of the component in the current environment is obtained by parsing deployment scripts (such as AnsiblePlaybook and Terraform configurations) or environment variables (such as CATALINA_HOME); or, static analysis of deployed applications is performed to identify the paths of their core executable files or library files. During the application development phase, vulnerability remediation scripts are pre-installed in the vulnerability remediation script library, with each script corresponding to a specific component and vulnerability type.

[0051] Step 302: Obtain the PID of the process with the vulnerability through the vulnerability detection agent.

[0052] In this step, the PID of the vulnerable Log4j process is obtained: PID is 28451.

[0053] Step 303: Extract candidate running paths of the process.

[0054] In this step, in existing technologies, attackers can use tools such as rootkits to forge virtual data, thereby forging the runtime path of processes. For example, a rootkit can intercept and modify / proc / using kernel module hooking techniques. <pid> / maps、 / proc / <pid>When attempting to read system files such as ` / cmdline`, the rootkit returns tampered data to hide the true memory layout of the malicious process when attempting to read the process's memory mapping. Therefore, a process-level memory view snapshot can be obtained, capturing the virtual memory region of the process with PID 28451. Executable and private memory segments within this virtual memory region are then selected, and their addresses are converted to physical page frame numbers. The physical page frame numbers of these memory segments are used to determine the physical memory addresses of environment variables. These environment variable physical memory addresses are considered reliable. Then, feature strings corresponding to the candidate runtime paths are identified within the physical memory addresses of the environment variables, and these identified feature strings are converted back to the candidate runtime paths.

[0055] Step 304: Score the candidate running paths and select the candidate running path with the highest score as the running path of the process.

[0056] In this step, the candidate running paths can be scored according to the method in the foregoing embodiments, and the candidate running path with the highest score can be taken as the running path of the application process.

[0057] Step 305: Match the running path in the path feature table.

[0058] In this step, if the match is successful, the component name and vulnerability remediation script identifier corresponding to the feature path are obtained, confirming that Log4j is a controlled component, and the vulnerability can be remediated on the controlled component.

[0059] Step 306: Match the vulnerability repair script identifier in the vulnerability repair script library.

[0060] In this step, the vulnerability patching script identifier is used to match the corresponding vulnerability patching script in the vulnerability patching script library.

[0061] Step 307: Inject the characteristic path into the matching vulnerability remediation script.

[0062] In this step, the feature path that matches the runtime path from the previous steps is injected into the matched vulnerability remediation script.

[0063] Step 308: Execute the vulnerability remediation script.

[0064] In this step, the vulnerability repair script is automatically executed to replace the log4j component in the application server, and the application server is restarted to complete the repair of the log4j component vulnerability.

[0065] like Figure 4 The diagram shown is a structural schematic of a vulnerability repair device according to an embodiment of this specification. The diagram illustrates the structure of various functional modules and units implemented by a computer. In this embodiment, the logic components implementing the above method can be implemented by a general-purpose processor or a specially configured processor. The device specifically includes: The runtime path acquisition unit 401 is used to scan the runtime application process using the vulnerability detection agent to obtain the runtime path of the application process. The matching unit 402 is used to match the running path of the application process with the path feature table, wherein the path feature table includes at least a feature path and a vulnerability repair script identifier. The script acquisition unit 403 is used to obtain the vulnerability remediation script based on the vulnerability remediation script identifier corresponding to the matched controlled component; Repair unit 404 is used to inject the characteristic path into the vulnerability repair script and execute the vulnerability repair script.

[0066] The apparatus described in the embodiments of this specification can automatically detect application vulnerabilities and repair them using corresponding vulnerability repair scripts, eliminating the need for manual path searching and script adaptation. This reduces vulnerability repair time from "days" to "minutes," saving labor costs and improving the efficiency of vulnerability repair. The runtime path capture solves the problem of repair failure caused by custom directories.

[0067] like Figure 5 The illustration shows a computer device provided in an embodiment of this specification. The vulnerability repair method in this embodiment can be implemented using the computer device in this embodiment. The computer device 502 may include one or more processors 504, such as one or more central processing units (CPUs), each CPU implementing one or more hardware threads. The computer device 502 may also include any memory 506 for storing information of any kind, such as code, settings, data, etc. Non-limitingly, for example, the memory 506 may include any type of RAM, any type of ROM, flash memory, hard disk, optical disk, etc. More generally, any memory can use any technology to store information. Further, any memory can provide volatile or non-volatile retention of information. Further, any memory may represent a fixed or removable component of the computer device 502. In one case, when the processor 504 executes associated instructions stored in any memory or combination of memories, the computer device 502 can perform any operation of the associated instructions. The computer device 502 also includes one or more drive mechanisms 508 for interacting with any memory, such as hard disk drive mechanisms, optical disk drive mechanisms, etc.

[0068] Computer device 502 may also include an input / output module 510 (I / O) for receiving various inputs (via input device 512) and providing various outputs (via output device 514). A specific output mechanism may include a presentation device 516 and an associated graphical user interface (GUI) 518. In other embodiments, the input / output module 510 (I / O), input device 512, and output device 514 may be omitted, and the device may function solely as a computer device within a network. Computer device 502 may also include one or more network interfaces 520 for exchanging data with other devices via one or more communication links 522. One or more communication buses 524 couple the components described above together.

[0069] Communication link 522 can be implemented in any way, such as via a local area network, a wide area network (e.g., the Internet), a point-to-point connection, or any combination thereof. Communication link 522 may include any combination of hardwired links, wireless links, routers, gateway functions, name servers, etc., governed by any protocol or combination of protocols.

[0070] This specification also provides computer-readable instructions, wherein when a processor executes the instructions, the program therein causes the processor to perform the methods described above.

[0071] It should be understood that in the various embodiments of this specification, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this specification.

[0072] It should also be understood that, in the embodiments of this specification, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this specification generally indicates that the preceding and following related objects have an "or" relationship.

[0073] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this specification can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this specification.

[0074] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0075] In the several embodiments provided in this specification, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the couplings or direct couplings or communication connections shown or discussed may be indirect couplings or communication connections through some interfaces, devices, or units, or they may be electrical, mechanical, or other forms of connection.

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

[0077] Furthermore, the functional units in the various embodiments of this specification can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

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

[0079] This specification uses specific embodiments to illustrate the principles and implementation methods of this specification. The descriptions of the embodiments above are only for the purpose of helping to understand the methods and core ideas of this specification. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this specification. Therefore, the content of this specification should not be construed as a limitation of this specification.< / pid> < / pid> < / pid>

Claims

1. A vulnerability remediation method, characterized in that, include: By using a vulnerability detection agent to scan running application processes, the running paths of the application processes can be obtained. The running path of the application process is matched with the path feature table, wherein the path feature table includes at least the feature path and the vulnerability remediation script identifier. Based on the vulnerability remediation script identifier corresponding to the matched controlled component, the vulnerability remediation script is obtained; The characteristic path is injected into the vulnerability remediation script, and the vulnerability remediation script is executed.

2. The method according to claim 1, characterized in that, Also includes: When an application is launched, the characteristic paths of all controlled components in the application and the vulnerability remediation script identifiers of the controlled components are recorded to form the path characteristic table.

3. The method according to claim 2, characterized in that, Based on the vulnerability remediation script identifier corresponding to the matched controlled component, the vulnerability remediation script further includes: Match the vulnerability repair script identifier in the vulnerability repair script library to find the corresponding vulnerability repair script.

4. The method according to claim 3, characterized in that, Also includes: According to predetermined rules, update the vulnerability patching scripts for different controlled components in the vulnerability patching script library.

5. The method according to claim 1, characterized in that, By using a vulnerability detection agent to scan runtime application processes, the runtime path of the application process is further obtained, including: By scanning the running application, the physical memory address of the application's environment variables can be obtained; Obtain at least one candidate running path of the application process based on the physical memory address of the environment variable.

6. The method according to claim 1, characterized in that, By using a vulnerability detection agent to scan runtime application processes, the runtime path of the application process is further obtained, including: Determine whether the running application is running inside a container; If it runs within a container, then by combining the path of the container and the path of the container's host machine, at least one candidate running state path for the application process is obtained.

7. The method according to claim 5 or 6, characterized in that, According to the preset scoring rules, the at least one candidate running state path is scored, and the candidate running state path with the highest score is selected as the running state path.

8. The method according to claim 7, characterized in that, The preset scoring rules must include at least one of the following rules: If the candidate runtime path is obtained through the path of the container and the path of the host machine of the container, then verify whether the candidate path actually exists in the file system of the host machine. If it exists, increase the score of the candidate runtime path; otherwise, do not score it. Extract multiple keywords from the candidate running path, and increase the score of the candidate running path based on the number of matches of the multiple keywords in the key feature word library.

9. A vulnerability repair device, characterized in that, include: The runtime path acquisition unit is used to scan runtime application processes using a vulnerability detection agent to obtain the runtime path of the application process. A matching unit is used to match the running path of the application process with a path feature table, wherein the path feature table includes at least a feature path and a vulnerability repair script identifier. The script acquisition unit is used to obtain the vulnerability remediation script based on the vulnerability remediation script identifier corresponding to the matched controlled component; The repair unit is used to inject the characteristic path into the vulnerability repair script and execute the vulnerability repair script.

10. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method described in any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the method described in any one of claims 1-8.

12. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-8.

Images