Container mirror image vulnerability source code level repairing method and device, equipment and storage medium

Abstract

The invention discloses a container mirror image vulnerability source code level repairing method and device, equipment and a storage medium, and the method comprises the steps: scanning a to-be-constructed container mirror image, and obtaining a vulnerability report; performing vulnerability positioning according to the vulnerability report, and mapping the DiffID of the vulnerability to a Dockerfile instruction; source code level repairing is carried out according to the Dockerfile instruction, after it is detected that the vulnerability of the to-be-constructed container mirror image is repaired, the to-be-constructed container mirror image is pushed to the mirror image warehouse, vulnerability repairing can be directly carried out from the Dockerfile source, the vulnerability can be automatically eliminated in the mirror image construction process, repeated scanning and repairing are avoided, the mirror image size is reduced, and the safety of the to-be-constructed container mirror image is improved. According to the method, a bug repairing layer is prevented from being additionally added, mirror image transmission and deployment management are facilitated, mirror image layer redundancy is avoided, and the container mirror image bug source code level repairing speed and efficiency are improved.

Description

Technical Field

[0001] The present invention relates to the field of container security technology, and in particular to a method, device, equipment and storage medium for repairing container image vulnerabilities at source code level. Background Art

[0002] In the field of container security, with the widespread application of containerization technology, Docker has gradually become the mainstream container platform; the security of container images is directly related to the stable and reliable operation of applications, so ensuring the security of container images is one of the important links in containerized applications; currently, there are often known security vulnerabilities in container images, and unfixed vulnerabilities may be exploited by attackers, thus posing a threat to system security, so timely and efficient repair of these vulnerabilities is the key to ensuring the security of container images.

[0003] At present, the method of identifying security vulnerabilities in container images is relatively mature. Container images are usually scanned through container security scanning tools (such as Trivy, Clair, etc.) to discover known security vulnerabilities in the images. These tools can efficiently identify vulnerabilities in images and provide support for the security maintenance of images.

[0004] However, there are still great difficulties in effectively repairing the discovered vulnerabilities. Some current repair methods usually repair the vulnerabilities by adding new layers on top of the existing images after the vulnerabilities are discovered. Although this method solves the vulnerability problem to a certain extent, it has some inherent defects: First, this method fails to solve the problem from the source Dockerfile, resulting in the failure to eliminate the source of the vulnerability during the build process, especially in the CI / CD pipeline environment. The vulnerability may reappear after each image is built, and vulnerability scanning and repair are still required, which significantly reduces efficiency; secondly, since the vulnerability repair layer is only superimposed on the existing image, as the number of repairs increases, the redundant patch layers in the image will continue to accumulate, resulting in an increase in the image size, which is not conducive to the transmission and deployment management of the image. Summary of the invention

[0005] The main purpose of the present invention is to provide a method, device, equipment and storage medium for source code level repair of container image vulnerabilities, aiming to solve the technical problem that the source of vulnerabilities cannot be eliminated during the image construction process in the prior art, the vulnerability may reappear after each image construction, and vulnerability scanning and repair are still required, which significantly reduces the efficiency. In addition, as the number of repairs increases, redundant patch layers in the image will continue to accumulate, resulting in an increase in the image size, which is not conducive to the transmission and deployment management of the image.

[0006] In a first aspect, the present invention provides a method for repairing a container image vulnerability at a source code level, the method comprising the following steps:

[0007] Scan the container image to be built and obtain vulnerability reports;

[0008] Locate the vulnerability based on the vulnerability report and map the vulnerability's DiffID to the Dockerfile instruction;

[0009] Perform source code level repair according to the Dockerfile instruction, and after detecting that the vulnerability of the container image to be built has been repaired, push the container image to be built to the image warehouse.

[0010] Optionally, scanning the container image to be built to obtain a vulnerability report includes:

[0011] Use container security scanning tools to scan the container image to be built and obtain vulnerability reports.

[0012] Optionally, locating the vulnerability according to the vulnerability report and mapping the DiffID of the vulnerability to a Dockerfile instruction includes:

[0013] Parse the vulnerability report to obtain image layer information and corresponding DiffID associated with the vulnerability;

[0014] The DiffID is mapped to a Dockerfile instruction according to the image layer information.

[0015] Optionally, mapping the DiffID to a Dockerfile instruction according to the image layer information includes:

[0016] Use the docker history command according to the image layer information to obtain the construction history of the container image to be built;

[0017] The DiffID is associated with a build command in the Dockerfile according to the build history.

[0018] Optionally, the source code level repair is performed according to the Dockerfile instruction, and after detecting that the vulnerability of the container image to be built has been repaired, before pushing the container image to be built to the image repository, the container image vulnerability source code level repair method further includes:

[0019] Determine whether the Dockerfile instruction is repaired in the original layer;

[0020] If the repair cannot be performed in the original layer, create a new RUN command in the Dockerfile to perform the repair.

[0021] Optionally, performing source code level repair according to the Dockerfile instruction and pushing the container image to be built to an image repository after detecting that the vulnerability of the container image to be built has been repaired includes:

[0022] Modify the corresponding build command in the current Dockerfile according to the Dockerfile instruction, and specify the affected software package to install the repair version according to the modified build command;

[0023] After detecting that the vulnerability of the container image to be built has been repaired, the container image to be built is pushed to the image warehouse.

[0024] Optionally, after detecting that the vulnerability of the container image to be built has been repaired, pushing the container image to be built to an image repository includes:

[0025] After detecting that the vulnerability of the container image to be built has been fixed, determining whether user confirmation is required;

[0026] When user confirmation is required, submit the repair report to the user terminal, and rebuild the container image after receiving the user's confirmation instruction;

[0027] Rebuild the container image directly without user confirmation;

[0028] A vulnerability scan is performed on the reconstructed target container image, and after no vulnerability exists in the target container image, the target container image is saved in the image repository.

[0029] In a second aspect, to achieve the above-mentioned purpose, the present invention further proposes a container image vulnerability source code level repair device, the container image vulnerability source code level repair device comprising:

[0030] Vulnerability scanning module, used to scan the container image to be built and obtain vulnerability reports;

[0031] A positioning mapping module, used to locate the vulnerability according to the vulnerability report and map the DiffID of the vulnerability to a Dockerfile instruction;

[0032] The vulnerability repair module is used to perform source code level repair according to the Dockerfile instruction, and after detecting that the vulnerability of the container image to be built has been repaired, push the container image to be built to the image warehouse.

[0033] In the third aspect, to achieve the above-mentioned purpose, the present invention also proposes a container image vulnerability source code level repair device, the container image vulnerability source code level repair device comprising: a memory, a processor, and a container image vulnerability source code level repair program stored on the memory and executable on the processor, the container image vulnerability source code level repair program being configured to implement the steps of the container image vulnerability source code level repair method as described above.

[0034] In a fourth aspect, in order to achieve the above-mentioned purpose, the present invention also proposes a storage medium, on which a container image vulnerability source code level repair program is stored, and when the container image vulnerability source code level repair program is executed by a processor, the steps of the container image vulnerability source code level repair method as described above are implemented.

[0035] Dockerfile instructions are used to locate the vulnerability and then map the DiffID of the vulnerability to a Dockerfile instruction. The Dockerfile instructions are used to perform source code level repairs, and after detecting that the vulnerability of the container image to be built has been repaired, the container image to be built is pushed to an image repository. After detecting the security vulnerability in the container image, the vulnerability can be repaired directly from the Dockerfile source, so that the vulnerability is automatically eliminated during the image building process, and repeated scanning and repairing can be avoided. The image size is reduced, and the repeated introduction of vulnerabilities with the iteration of code development is avoided. For the newly installed software in the RUN instruction, the repair version is supported to be directly installed, and an additional vulnerability repair layer is avoided, which is beneficial to the transmission and deployment management of the image, avoids image layer redundancy, and improves the speed and efficiency of source code level repair of container image vulnerabilities. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Figure 1 A schematic diagram of the device structure of the hardware operating environment involved in the embodiment of the present invention;

[0037] Figure 2 This is a flow chart of a first embodiment of a method for repairing a container image vulnerability at source code level according to the present invention;

[0038] Figure 3 This is a flow chart of a second embodiment of a method for repairing a container image vulnerability at source code level according to the present invention;

[0039] Figure 4 This is a flow chart of a third embodiment of a method for repairing a container image vulnerability at source code level according to the present invention;

[0040] Figure 5 This is a flow chart of a fourth embodiment of a method for repairing a container image vulnerability at source code level according to the present invention;

[0041] Figure 6 This is a flow chart of a fifth embodiment of a method for repairing a container image vulnerability at source code level according to the present invention;

[0042] Figure 7 This is a functional module diagram of the first embodiment of the container image vulnerability source code level repair device of the present invention.

[0043] The realization of the purpose, functional features and advantages of the present invention will be further explained in conjunction with embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0044] It should be understood that the specific embodiments described herein are only used to explain the present invention, and are not used to limit the present invention.

[0045] The solution of the embodiment of the present invention is mainly: by scanning the container image to be built, obtaining a vulnerability report; locating the vulnerability according to the vulnerability report, and mapping the DiffID of the vulnerability to the Dockerfile instruction; performing source code level repair according to the Dockerfile instruction, after detecting that the vulnerability of the container image to be built has been repaired, pushing the container image to be built to the image warehouse, and being able to directly repair the vulnerability from the Dockerfile source after detecting the security vulnerability in the container image, so that the vulnerability is automatically eliminated during the image building process, avoiding repeated scanning and repair, and reducing the image size, avoiding the repeated introduction of vulnerabilities with code development iterations, and supporting direct installation of repaired versions for new software installed in the RUN instruction, avoiding the additional increase of vulnerability repair layers, which is beneficial to the transmission and deployment management of the image, avoiding image layer redundancy, and improving the speed and efficiency of source code level repair of container image vulnerabilities, and solving the problem that the source of vulnerabilities cannot be eliminated during the image building process in the prior art, the vulnerability may reappear after each image building, and vulnerability scanning and repair are still required, which significantly reduces the efficiency, and as the number of repairs increases, the redundant patch layers in the image will continue to accumulate, resulting in an increase in the image size, which is not conducive to the transmission and deployment management of the image.

[0046] Reference Figure 1 , Figure 1 The figure is a schematic diagram of the device structure of the hardware operating environment involved in the embodiment of the present invention.

[0047] like Figure 1As shown, the device may include: a processor 1001, such as a CPU, a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. Among them, the communication bus 1002 is used to realize the connection and communication between these components. The user interface 1003 may include a display screen (Display), an input unit such as a keyboard (Keyboard), and the optional user interface 1003 may also include a standard wired interface and a wireless interface. The network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a Wi-Fi interface). The memory 1005 may be a high-speed RAM memory, or it may be a stable memory (Non-Volatile Memory), such as a disk memory. The memory 1005 may optionally be a storage device independent of the aforementioned processor 1001.

[0048] Those skilled in the art will understand that Figure 1 The device structure shown in the figure does not constitute a limitation of the device, and may include more or less components than shown in the figure, or combine certain components, or arrange the components differently.

[0049] like Figure 1 As shown, the memory 1005 as a storage medium may include an operating device, a network communication module, a user interface module, and a container image vulnerability source code level repair program.

[0050] The device of the present invention calls the container image vulnerability source code level repair program stored in the memory 1005 through the processor 1001, and performs the following operations:

[0051] Scan the container image to be built and obtain vulnerability reports;

[0052] Locate the vulnerability based on the vulnerability report and map the vulnerability's DiffID to the Dockerfile instruction;

[0053] Perform source code level repair according to the Dockerfile instruction, and after detecting that the vulnerability of the container image to be built has been repaired, push the container image to be built to the image warehouse.

[0054] The device of the present invention calls the container image vulnerability source code level repair program stored in the memory 1005 through the processor 1001, and also performs the following operations:

[0055] Use container security scanning tools to scan the container image to be built and obtain vulnerability reports.

[0056] The device of the present invention calls the container image vulnerability source code level repair program stored in the memory 1005 through the processor 1001, and also performs the following operations:

[0057] Parse the vulnerability report to obtain image layer information and corresponding DiffID associated with the vulnerability;

[0058] The DiffID is mapped to a Dockerfile instruction according to the image layer information.

[0059] The device of the present invention calls the container image vulnerability source code level repair program stored in the memory 1005 through the processor 1001, and also performs the following operations:

[0060] Use the docker history command according to the image layer information to obtain the construction history of the container image to be built;

[0061] The DiffID is associated with a build command in the Dockerfile according to the build history.

[0062] The device of the present invention calls the container image vulnerability source code level repair program stored in the memory 1005 through the processor 1001, and also performs the following operations:

[0063] Determine whether the Dockerfile instruction is repaired in the original layer;

[0064] If the repair cannot be performed in the original layer, create a new RUN command in the Dockerfile to perform the repair.

[0065] The device of the present invention calls the container image vulnerability source code level repair program stored in the memory 1005 through the processor 1001, and also performs the following operations:

[0066] Modify the corresponding build command in the current Dockerfile according to the Dockerfile instruction, and specify the affected software package to install the repair version according to the modified build command;

[0067] After detecting that the vulnerability of the container image to be built has been repaired, the container image to be built is pushed to the image warehouse.

[0068] The device of the present invention calls the container image vulnerability source code level repair program stored in the memory 1005 through the processor 1001, and also performs the following operations:

[0069] After detecting that the vulnerability of the container image to be built has been fixed, determining whether user confirmation is required;

[0070] When user confirmation is required, submit the repair report to the user terminal, and rebuild the container image after receiving the user's confirmation instruction;

[0071] Rebuild the container image directly without user confirmation;

[0072] A vulnerability scan is performed on the reconstructed target container image, and after no vulnerability exists in the target container image, the target container image is saved in the image repository.

[0073] This embodiment uses the above scheme to obtain a vulnerability report by scanning the container image to be built; locate the vulnerability according to the vulnerability report, and map the DiffID of the vulnerability to the Dockerfile instruction; perform source code level repair according to the Dockerfile instruction, and push the container image to be built to the image warehouse after detecting that the vulnerability of the container image to be built has been repaired. After detecting the security vulnerability in the container image, the vulnerability can be repaired directly from the Dockerfile source, so that the vulnerability is automatically eliminated during the image building process, avoiding repeated scanning and repair, reducing the image size, avoiding the repeated introduction of vulnerabilities with the iteration of code development, and supporting the direct installation of the repaired version for the newly installed software in the RUN instruction, avoiding the additional vulnerability repair layer, which is beneficial to the transmission and deployment management of the image, avoiding image layer redundancy, and improving the speed and efficiency of source code level repair of container image vulnerabilities.

[0074] Based on the above hardware structure, an embodiment of a method for repairing a container image vulnerability at source code level of the present invention is proposed.

[0075] Reference Figure 2 , Figure 2 This is a flow chart of a first embodiment of a method for repairing a container image vulnerability at source code level according to the present invention.

[0076] In a first embodiment, the container image vulnerability source code level repair method includes the following steps:

[0077] Step S10: Scan the container image to be built to obtain a vulnerability report.

[0078] It should be noted that the container image to be built is a container image to be built, and a vulnerability report can be generated by performing vulnerability scanning on the container image to be built.

[0079] Step S20: locate the vulnerability according to the vulnerability report, and map the DiffID of the vulnerability to a Dockerfile instruction.

[0080] It should be understood that by locating the vulnerability according to the vulnerability report, the location of the vulnerability can be locked, and the difference identifier (Difference Identifier, DiffID) of the vulnerability can be mapped to the Dockerfile instruction.

[0081] Step S30: Perform source code level repair according to the Dockerfile instruction, and after detecting that the vulnerability of the container image to be built has been repaired, push the container image to be built to the image warehouse.

[0082] It is understandable that source code-level repair can be performed according to the Dockerfile instruction, and after detecting that the vulnerability of the container image to be built has been repaired, the container image to be built can be pushed to the image warehouse in a timely manner.

[0083] This embodiment uses the above scheme to obtain a vulnerability report by scanning the container image to be built; locate the vulnerability according to the vulnerability report, and map the DiffID of the vulnerability to the Dockerfile instruction; perform source code level repair according to the Dockerfile instruction, and push the container image to be built to the image warehouse after detecting that the vulnerability of the container image to be built has been repaired. After detecting the security vulnerability in the container image, the vulnerability can be repaired directly from the Dockerfile source, so that the vulnerability is automatically eliminated during the image building process, avoiding repeated scanning and repair, reducing the image size, avoiding the repeated introduction of vulnerabilities with the iteration of code development, and supporting the direct installation of the repaired version for the newly installed software in the RUN instruction, avoiding the additional vulnerability repair layer, which is beneficial to the transmission and deployment management of the image, avoiding image layer redundancy, and improving the speed and efficiency of source code level repair of container image vulnerabilities.

[0084] Further, Figure 3 FIG. 1 is a flow chart of a second embodiment of a method for repairing a container image vulnerability at source code level according to the present invention. Figure 3 As shown, a second embodiment of the container image vulnerability source code level repair method of the present invention is proposed based on the first embodiment. In this embodiment, the step S10 specifically includes the following steps:

[0085] Step S11: Use a container security scanning tool to scan the container image to be built and obtain a vulnerability report.

[0086] It should be noted that in the continuous integration CI / continuous deployment CD process, container security scanning tools are used to scan the container image to be built and generate vulnerability reports.

[0087] In a specific implementation, the vulnerability scanning process can be:

[0088] FROM debian:9.1

[0089] #Install necessary packages

[0090] RUN apt-get update&&\

[0091] apt-get install-y--no-install-recommends\

[0092] ca-certificates\

[0093] curl\

[0094] wget&&\

[0095] rm -rf / var / lib / apt / lists / *

[0096] #Install unzip (vulnerable package)

[0097] RUN apt-get update&&\

[0098] apt-get install-y--no-install-recommends\

[0099] bzip2\

[0100] unzip\

[0101] xz-utils&&\

[0102] rm -rf / var / lib / apt / lists / *

[0103] …and other build content

[0104] You can build an image based on Debian 9.1 and install some business software. Use Trivy to scan the image and find that the unzip package has the CVE-2018-1000035 vulnerability. The detailed information includes but is not limited to:

[0105] Vulnerability ID: CVE-2018-1000035

[0106] Affected packages: unzip

[0107] Installed version: 6.0-21

[0108] ·Repair version: 6.0-21+deb9u1

[0109] ·Layer DiffID: sha256:6327a15187719a56fb9a18190bd345ca88c3317f203a1e56a85ed06207e79c08.

[0110] Through the above scheme, this embodiment uses a container security scanning tool to scan the container image to be built to obtain a vulnerability report, which can quickly generate a vulnerability report and improve the speed and efficiency of source code level repair of container image vulnerabilities.

[0111] Further, Figure 4 FIG. 1 is a flow chart of a third embodiment of a method for repairing a container image vulnerability at source code level according to the present invention. Figure 4 As shown, a third embodiment of the method for repairing a container image vulnerability at source code level according to the present invention is proposed based on the first embodiment. In this embodiment, step S20 specifically includes the following steps:

[0112] Step S21: parse the vulnerability report to obtain image layer information and corresponding DiffID associated with the vulnerability.

[0113] It should be noted that the process of vulnerability location is to obtain the image layer information and corresponding DiffID associated with the vulnerability after parsing the vulnerability report.

[0114] Step S22: Map the DiffID to a Dockerfile instruction according to the image layer information.

[0115] It should be understood that the DiffID may be mapped to a Dockerfile instruction according to the image layer information.

[0116] Furthermore, the step S22 specifically includes the following steps:

[0117] Use the docker history command according to the image layer information to obtain the construction history of the container image to be built;

[0118] The DiffID is associated with a build command in the Dockerfile according to the build history.

[0119] It can be understood that mapping to Dockerfile instructions, that is, using the docker history command, obtains the build history of the image and associates the DiffID with the build command in the Dockerfile.

[0120] In the specific implementation, the vulnerability location process is:

[0121] Use methods such as docker history to obtain the build history of the image and find the corresponding build command through DiffID:

[0122] RUN apt-get update&&\

[0123] apt-get install-y--no-install-recommends\

[0124] bzip2\

[0125] unzip\

[0126] xz-utils&&\

[0127] rm -rf / var / lib / apt / lists / *

[0128] The mapping to the Dockerfile instruction process is:

[0129] According to the output of docker history, associate DiffID with the build command in Dockerfile, and perform bash syntax parsing on the build command. For example, the above command can obtain two lines of commands, apt-get and rm, and the rest are parameters. When locating the repair location, filter the commands according to the whitelist list (apt, apt-get, yum, etc.) to prevent mismatching, and locate the RUN instruction for installing the unzip package.

[0130] Through the above scheme, this embodiment parses the vulnerability report to obtain the image layer information and the corresponding DiffID associated with the vulnerability; maps the DiffID to the Dockerfile instruction according to the image layer information, and can directly repair the vulnerability from the Dockerfile source after detecting the security vulnerability in the container image, so that the vulnerability is automatically eliminated during the image building process, avoiding repeated scanning and repair, and reducing the image size.

[0131] Further, Figure 5 FIG. 4 is a flow chart of a fourth embodiment of a method for repairing a container image vulnerability at source code level according to the present invention. Figure 5 As shown, a fourth embodiment of the method for repairing a container image vulnerability at source code level of the present invention is proposed based on the first embodiment. In this embodiment, before step S30, the method for repairing a container image vulnerability at source code level further includes the following steps:

[0132] Step S301, determine whether the Dockerfile instruction is repaired in the original layer.

[0133] It should be noted that before repairing the vulnerability, you can first determine whether the repair can be performed on the original layer.

[0134] Step S302: If the original layer cannot be repaired, create a new RUN command in the Dockerfile to repair it.

[0135] It is understandable that when the original layer cannot be repaired, that is, when the original layer cannot be modified directly, a new layer is added to execute the repair command, that is, a new RUN command is created in the Dockerfile for repair.

[0136] In the specific implementation, if the vulnerability point is not found in the build instructions of the vulnerable layer and the original layer build instructions cannot be modified to directly fix it, a new RUN instruction can be added:

[0137] #Add a new layer for repair

[0138] RUN apt-get update&&\

[0139] apt-get install-y unzip=6.0-21+deb9u1&&\

[0140] rm -rf / var / lib / apt / lists / *

[0141] Ensure that in special circumstances, a fallback repair strategy can be implemented. After the fallback strategy is repaired, when the image dockerfile is updated later, the image built again will also fix the vulnerability by default. There is no need to build a vulnerable version image and then wait for the vulnerability scan to identify it and then repair the image over and over again.

[0142] This embodiment uses the above scheme to determine whether the Dockerfile instruction is repaired in the original layer; if the repair cannot be performed in the original layer, a new RUN command is created in the Dockerfile for repair, which can ensure the integrity of the repair and improve the speed and efficiency of source code level repair of container image vulnerabilities.

[0143] Further, Figure 6 FIG. 5 is a flow chart of a fifth embodiment of a method for repairing a container image vulnerability at a source code level according to the present invention. Figure 6 As shown, a fifth embodiment of the method for repairing a container image vulnerability at source code level according to the present invention is proposed based on the first embodiment. In this embodiment, step S30 specifically includes the following steps:

[0144] Step S31: modify the corresponding build command in the current Dockerfile according to the Dockerfile instruction, and specify the affected software package to install the repair version according to the modified build command.

[0145] It should be noted that when repairing on the original layer, the corresponding build command in the Dockerfile is directly modified to specify the affected software package to install the repair version, and the vulnerability is repaired on the original layer as much as possible.

[0146] In the specific implementation, the Dockerfile source code modification process is: if the vulnerable software is successfully mapped to the RUN instruction in the Dockerfile, the fixed version in the vulnerability scan report is automatically extracted and the corresponding installation command in the specified one is replaced. For example:

[0147] RUN apt-get update&&\

[0148] apt-get install-y--no-install-recommends\

[0149] bzip2\

[0150] unzip=6.0-21+deb9u1\

[0151] xz-utils&&\

[0152] rm -rf / var / lib / apt / lists / *

[0153] In this way, when building the image, the unzip package will directly install the fixed version 6.0-21+deb9u1, which fixes the problem directly from the source code layer. It will not be reflected in the process of building a vulnerability and then fixing a vulnerability. The vulnerable version will not be generated directly, and the addition of a new image layer is avoided.

[0154] Step S32: After detecting that the vulnerability of the container image to be built has been repaired, push the container image to be built to the image repository.

[0155] It is understandable that after detecting that the vulnerability of the container image to be built has been repaired, the container image to be built can be pushed to the image warehouse in a timely manner.

[0156] Furthermore, the step S32 specifically includes the following steps:

[0157] After detecting that the vulnerability of the container image to be built has been fixed, determining whether user confirmation is required;

[0158] When user confirmation is required, submit the repair report to the user terminal, and rebuild the container image after receiving the user's confirmation instruction;

[0159] Rebuild the container image directly without user confirmation;

[0160] A vulnerability scan is performed on the reconstructed target container image, and after no vulnerability exists in the target container image, the target container image is saved in the image repository.

[0161] It should be understood that after detecting that the vulnerability of the container image to be built has been fixed, it can be determined whether user confirmation is required; generally, two modes, automatic repair and user-confirmed repair, are provided. When user confirmation is required, a repair report is submitted to the user terminal, and after receiving the user confirmation instruction, the container image is rebuilt; when user confirmation is not required, the container image is directly rebuilt; the image is rebuilt using the modified Dockerfile, and the new image is scanned for vulnerabilities. After confirming that the vulnerability has been fixed, it is pushed to the image repository.

[0162] In the specific implementation, user confirmation is supported, that is, the system supports configuration as default repair, and also supports configuration as repair after notification of user confirmation. When the configuration notifies the user to confirm the repair, if a vulnerability is detected, repair instructions will be automatically generated for the Dockerfile based on the above strategy. The generated instructions will be submitted to the code library or other locations specified by the user only after the user confirms, thus completing the repair of the Dockerfile source code.

[0163] Use the modified Dockerfile to rebuild the image, and use Trivy and other vulnerability scanning tools to scan the new image again to confirm whether the vulnerability is completely fixed. Once the vulnerability is confirmed to be fixed, it can be submitted to the warehouse to complete the process. If it is not fixed, a repair error alarm will be generated. At this time, the user can be notified to manually intervene in the analysis and processing.

[0164] This embodiment uses the above scheme to modify the corresponding build command in the current Dockerfile according to the Dockerfile instruction, and specifies the affected software package to install the repair version according to the modified build command; after detecting that the vulnerability of the container image to be built has been repaired, the container image to be built is pushed to the image warehouse, and after detecting the security vulnerability in the container image, the vulnerability can be repaired directly from the Dockerfile source, so that the vulnerability is automatically eliminated during the image building process, avoiding repeated scanning and repair, and reducing the image size, avoiding the repeated introduction of vulnerabilities with the iteration of code development, and for the new software installed in the RUN instruction, it supports the direct installation of the repair version, avoiding the additional vulnerability repair layer, which is beneficial to the transmission and deployment management of the image, avoiding the redundancy of the image layer, and improving the speed and efficiency of the source code level repair of the container image vulnerability.

[0165] Accordingly, the present invention further provides a container image vulnerability source code level repair device.

[0166] Reference Figure 7 , Figure 7 This is a functional module diagram of the first embodiment of the container image vulnerability source code level repair device of the present invention.

[0167] In a first embodiment of the device for repairing a container image vulnerability at source code level of the present invention, the device for repairing a container image vulnerability at source code level comprises:

[0168] The vulnerability scanning module 10 is used to scan the container image to be built and obtain a vulnerability report.

[0169] The positioning and mapping module 20 is used to locate the vulnerability according to the vulnerability report and map the DiffID of the vulnerability to a Dockerfile instruction.

[0170] The vulnerability repair module 30 is used to perform source code level repair according to the Dockerfile instruction, and after detecting that the vulnerability of the container image to be built has been repaired, push the container image to be built to the image warehouse.

[0171] The vulnerability scanning module 10 is also used to use a container security scanning tool to scan the container image to be built to obtain a vulnerability report.

[0172] The positioning mapping module 20 is further used to parse the vulnerability report, obtain the image layer information associated with the vulnerability and the corresponding DiffID; and map the DiffID to a Dockerfile instruction according to the image layer information.

[0173] The positioning mapping module 20 is further used to obtain the construction history of the container image to be constructed by using the docker history command according to the image layer information; and associate the DiffID with the construction command in the Dockerfile according to the construction history.

[0174] The vulnerability repair module 30 is also used to determine whether the Dockerfile instruction is repaired in the original layer; if the repair cannot be performed in the original layer, a new RUN command is created in the Dockerfile for repair.

[0175] The vulnerability repair module 30 is also used to modify the corresponding build command in the current Dockerfile according to the Dockerfile instruction, and specify the affected software package to install the repair version according to the modified build command; after detecting that the vulnerability of the container image to be built has been repaired, push the container image to be built to the image warehouse.

[0176] The vulnerability repair module 30 is also used to determine whether user confirmation is required after detecting that the vulnerability of the container image to be built has been repaired; when user confirmation is required, submit a repair report to the user terminal, and rebuild the container image after receiving the user confirmation instruction; when user confirmation is not required, directly rebuild the container image; perform vulnerability scanning and verification on the rebuilt target container image, and after there are no vulnerabilities in the target container image, save the target container image to the image warehouse.

[0177] Among them, the steps implemented by each functional module of the container image vulnerability source code level repair device can refer to the various embodiments of the container image vulnerability source code level repair method of the present invention, and will not be repeated here.

[0178] In addition, an embodiment of the present invention further provides a storage medium, on which a container image vulnerability source code level repair program is stored. When the container image vulnerability source code level repair program is executed by a processor, the following operations are implemented:

[0179] Scan the container image to be built and obtain vulnerability reports;

[0180] Locate the vulnerability based on the vulnerability report and map the vulnerability's DiffID to the Dockerfile instruction;

[0181] Perform source code level repair according to the Dockerfile instruction, and after detecting that the vulnerability of the container image to be built has been repaired, push the container image to be built to the image warehouse.

[0182] Furthermore, when the container image vulnerability source code level repair program is executed by the processor, the following operations are also implemented:

[0183] Use container security scanning tools to scan the container image to be built and obtain vulnerability reports.

[0184] Furthermore, when the container image vulnerability source code level repair program is executed by the processor, the following operations are also implemented:

[0185] Parse the vulnerability report to obtain image layer information and corresponding DiffID associated with the vulnerability;

[0186] The DiffID is mapped to a Dockerfile instruction according to the image layer information.

[0187] Furthermore, when the container image vulnerability source code level repair program is executed by the processor, the following operations are also implemented:

[0188] Use the docker history command according to the image layer information to obtain the construction history of the container image to be built;

[0189] The DiffID is associated with a build command in the Dockerfile according to the build history.

[0190] Furthermore, when the container image vulnerability source code level repair program is executed by the processor, the following operations are also implemented:

[0191] Determine whether the Dockerfile instruction is repaired in the original layer;

[0192] If the repair cannot be performed in the original layer, create a new RUN command in the Dockerfile to perform the repair.

[0193] Furthermore, when the container image vulnerability source code level repair program is executed by the processor, the following operations are also implemented:

[0194] Modify the corresponding build command in the current Dockerfile according to the Dockerfile instruction, and specify the affected software package to install the repair version according to the modified build command;

[0195] After detecting that the vulnerability of the container image to be built has been repaired, the container image to be built is pushed to the image warehouse.

[0196] Furthermore, when the container image vulnerability source code level repair program is executed by the processor, the following operations are also implemented:

[0197] After detecting that the vulnerability of the container image to be built has been fixed, determining whether user confirmation is required;

[0198] When user confirmation is required, submit the repair report to the user terminal, and rebuild the container image after receiving the user's confirmation instruction;

[0199] Rebuild the container image directly without user confirmation;

[0200] A vulnerability scan is performed on the reconstructed target container image, and after no vulnerability exists in the target container image, the target container image is saved in the image repository.

[0201] Those skilled in the art will appreciate that all or part of the steps in the above-mentioned implementation method can be accomplished by instructing related hardware through a program, and the program is stored in a storage medium, including a number of instructions for enabling a device (which may be a single-chip microcomputer, chip, etc.) or a processor to execute all or part of the steps of the method described in each implementation method of the present application; and the aforementioned storage medium is a computer-readable storage medium, including: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a disk or an optical disk, and other media that can store program codes.

[0202] It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element.

[0203] The serial numbers of the above embodiments of the present invention are only for description and do not represent the advantages or disadvantages of the embodiments.

[0204] The above are only preferred embodiments of the present invention, and are not intended to limit the patent scope of the present invention. Any equivalent structure or equivalent process transformation made using the contents of the present invention specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present invention.

Claims

1. A method for repairing container image vulnerabilities at source code level, characterized in that: The container image vulnerability source code level repair method includes: Scan the container image to be built and obtain vulnerability reports; Locate the vulnerability based on the vulnerability report and map the vulnerability's DiffID to the Dockerfile instruction; Perform source code level repair according to the Dockerfile instruction, and after detecting that the vulnerability of the container image to be built has been repaired, push the container image to be built to the image warehouse.

2. The method for repairing a container image vulnerability at source code level according to claim 1, characterized in that: The container image to be built is scanned to obtain a vulnerability report, including: Use container security scanning tools to scan the container image to be built and obtain vulnerability reports.

3. The method for repairing a container image vulnerability at source code level according to claim 1, characterized in that: The vulnerability is located according to the vulnerability report, and the DiffID of the vulnerability is mapped to a Dockerfile instruction, including: Parse the vulnerability report to obtain image layer information and corresponding DiffID associated with the vulnerability; The DiffID is mapped to a Dockerfile instruction according to the image layer information.

4. The method for repairing a container image vulnerability at source code level according to claim 3, characterized in that: Mapping the DiffID to a Dockerfile instruction according to the image layer information includes: Use the docker history command according to the image layer information to obtain the construction history of the container image to be built; The DiffID is associated with a build command in the Dockerfile according to the build history.

5. The method for repairing a container image vulnerability at source code level according to claim 1, wherein: The method of performing source code level repair according to the Dockerfile instruction, after detecting that the vulnerability of the container image to be built has been repaired, and before pushing the container image to be built to the image warehouse, the container image vulnerability source code level repair method also includes: Determine whether the Dockerfile instruction is repaired in the original layer; If the repair cannot be performed in the original layer, create a new RUN command in the Dockerfile to perform the repair.

6. The method for repairing a container image vulnerability at source code level according to claim 1, characterized in that: The performing source code level repair according to the Dockerfile instruction, and after detecting that the vulnerability of the container image to be built has been repaired, pushing the container image to be built to the image warehouse, includes: Modify the corresponding build command in the current Dockerfile according to the Dockerfile instruction, and specify the affected software package to install the repair version according to the modified build command; After detecting that the vulnerability of the container image to be built has been repaired, the container image to be built is pushed to the image warehouse.

7. The method for repairing a container image vulnerability at source code level according to claim 6, characterized in that: After detecting that the vulnerability of the container image to be built has been repaired, pushing the container image to be built to the image repository includes: After detecting that the vulnerability of the container image to be built has been fixed, determining whether user confirmation is required; When user confirmation is required, submit the repair report to the user terminal, and rebuild the container image after receiving the user's confirmation instruction; Rebuild the container image directly without user confirmation; A vulnerability scan is performed on the reconstructed target container image, and after no vulnerability exists in the target container image, the target container image is saved in the image repository.

8. A container image vulnerability source code level repair device, characterized in that: The container image vulnerability source code level repair device comprises: Vulnerability scanning module, used to scan the container image to be built and obtain vulnerability reports; A positioning mapping module, used to locate the vulnerability according to the vulnerability report and map the DiffID of the vulnerability to a Dockerfile instruction; The vulnerability repair module is used to perform source code level repair according to the Dockerfile instruction, and after detecting that the vulnerability of the container image to be built has been repaired, push the container image to be built to the image warehouse.

9. A container image vulnerability source code level repair device, characterized in that: The container image vulnerability source code level repair device includes: a memory, a processor, and a container image vulnerability source code level repair program stored on the memory and executable on the processor, wherein the container image vulnerability source code level repair program is configured to implement the steps of the container image vulnerability source code level repair method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that: The storage medium stores a container image vulnerability source code level repair program, and when the container image vulnerability source code level repair program is executed by the processor, the steps of the container image vulnerability source code level repair method according to any one of claims 1 to 7 are implemented.

Images