Cloud-native container asset dynamic image incremental vulnerability scanning method and system

Abstract

The application provides a cloud-native container asset dynamic image incremental vulnerability scanning method and system, relates to the technical field of cloud-native security vulnerability detection, and specifically comprises the following steps: S1: constructing a container image benchmark feature library with a time sequence index; S2: continuously monitoring cluster dynamic change events, filtering invalid changes, and then issuing image layering difference comparison trigger instructions; S3: calling historical data of the image benchmark feature library; S4: only performing vulnerability matching scanning on a lightweight incremental data set; S5: real-time pulling container running unit runtime dynamic parameters; S6: time sequence aggregation of inventory vulnerabilities, incremental vulnerabilities, and vulnerability data after attribute division, generation of a complete container asset dynamic inspection report according to multi-dimensional classification. The method focuses on container vulnerability detection and risk inspection scenarios throughout the process, does not have asset camouflage and anti-detection related technical features, and is suitable for the normal security inspection needs of various K8s micro-service production clusters.

Description

Technical Field

[0001] This invention relates to the field of cloud-native security vulnerability detection technology, and more specifically, to a method and system for incremental vulnerability scanning of dynamic images of cloud-native container assets. Background Technology

[0002] Currently, there are two completely separate technical approaches in the field of cloud-native Kubernetes (Container Orchestration Platform) cluster security protection: container asset camouflage protection technology and traditional full container vulnerability scanning technology. Both existing technologies have inherent defects that cannot adapt to the dynamic iteration scenario of microservices. Firstly, existing technologies only focus on container asset stealth and anti-probe camouflage functions, with the core goal of hiding cluster asset topology information. The entire solution does not include any vulnerability detection or risk identification related technical logic, and cannot identify security vulnerabilities in image files and third-party dependency packages. It cannot meet the needs of routine vulnerability inspection of the cluster, and its solution does not overlap with the technical goal of this invention.

[0003] Secondly, the industry-standard traditional container vulnerability scanning solutions uniformly adopt a full-image periodic scanning mode, which has multiple shortcomings in adaptability and detection accuracy: First, there is no image layering quantification differential discrimination logic, which cannot distinguish between minor configuration changes without security risks and changes to underlying system files / dependencies with high-risk vulnerabilities. Any change to the image triggers a full image scan, resulting in a large amount of repetitive calculation and serious consumption of computing resources. Second, there is no image time-series benchmark feature library and a mechanism for persistent storage and reuse of existing vulnerabilities. Each image version iteration rescans all image layers, making it impossible to reuse vulnerability detection results of historically unchanged components. Each scan is time-consuming, and the inspection efficiency is extremely low in high-frequency iteration scenarios of business clusters. Third, there is a lack of cluster dynamic change event filtering logic, which cannot distinguish between temporary test Pods (container runtime units) with a lifespan of less than 300 seconds and short-term test images. A large number of invalid changes will continue to issue scan tasks, further wasting cluster computing power. Summary of the Invention

[0004] The purpose of this invention is to solve the problem that the current industry lacks a complete incremental scanning technology solution that integrates layered quantitative differential scanning, event filtering, reuse of existing vulnerabilities, and correction of runtime vulnerabilities.

[0005] To achieve the above-mentioned objectives and improve the aforementioned problems, this invention provides a method for incremental vulnerability scanning of dynamic images of cloud-native container assets, comprising the following steps: S1: Connects to the container image repository and the K8s cluster, collects multi-dimensional raw image data, and builds a container image benchmark feature library with time-series index; S2: Continuously monitor cluster dynamic change events, filter invalid changes, and then issue image layer differential comparison trigger commands; S3: Retrieve historical data from the mirror baseline feature library, substitute it into the stratification change weight formula to quantify and determine incremental stratification, extract the pure incremental dataset to be scanned, and the stratification change weight formula is: ; in The weights are changed for a single-layer mirror image. =0.6 is the fixed coefficient for file hash changes; To match the differences in the hierarchical hash, assign 1 if the hierarchical hashes are completely different and 0 if they are completely consistent. =0.3 is the dependency package change factor; Add / remove dependency packages to this layer; =0.1 is the configuration change coefficient; Modify the number of configuration entries for this layer; the single-layer weight determination threshold is fixed at 0.2; S4: Perform vulnerability matching scans only on lightweight incremental datasets, reuse historical detection results of unchanged components in the benchmark library, and quantify the resource saving ratio using a scanning computing power saving efficiency calculation formula. The scanning computing power saving efficiency calculation formula is as follows: ; in This saves computational power for a single scan. Standard time for full image scan; The actual time taken to scan the incremental dataset; S5: Real-time pull of dynamic parameters of container runtime units, binary distinction between static image vulnerabilities and runtime dynamic vulnerabilities, and correction of the original scan vulnerability risk level; S6: Time-series aggregation of existing vulnerabilities, new vulnerabilities, and vulnerability data after attribute classification, generating a complete dynamic inspection report of container assets according to multi-dimensional classification.

[0006] As a preferred technical solution of this application, step S1 specifically includes: S101: Establish a two-way long-connection communication channel, call the image repository application interface and the K8s cluster application interface server to synchronously pull all business image data, filter temporary test images with a lifespan of less than 300 seconds, destroy temporary container running unit assets in one go, and retain the images corresponding to long-term stable running business containers. S102: Perform layered decomposition operations on each version of the image, extract four types of benchmark data layer by layer: image layer file hash verification value, complete list of built-in system components, accurate version number of third-party dependency packages, container static deployment configuration parameters, and synchronously bind the image's unique version ID, cluster namespace label, and image build time, thereby constructing a container image benchmark feature library with time-series index. S103: Store all hierarchical feature data into the container image benchmark feature library with time-series index using hierarchical hash values ​​as the main index, and generate an immutable image benchmark feature set. S104: Perform a full vulnerability scan on the new image that is added to the database for the first time, match the common vulnerability disclosure number to obtain the initial vulnerability list, bind and associate each vulnerability with the corresponding image layer, component, and dependency package, and store it in the constructed image baseline feature library to form a retrievable historical vulnerability dataset.

[0007] As a preferred technical solution of this application, step S2 specifically includes: S201: Deploy an event interception chain within the cluster to continuously monitor four types of exclusive change events: new version push events from the image repository, creation, destruction, start and stop events of K8s container runtime units, configuration mapping resource configuration file update events, and stateless application controller image version replacement events. S202: Set a fixed threshold of 300 seconds for asset lifespan, automatically filter temporary asset change events whose lifespan has not reached the threshold, and output a differential comparison execution command to S3 after verification, carrying the new version ID of the image.

[0008] As a preferred technical solution of this application, step S3 specifically includes: S301: Based on the image version ID carried by the differential comparison execution instruction issued by S202, retrieve the hierarchical feature data of the previous complete version of the image from the time series benchmark feature library built by S1. S302: Substitute each layer of data in the new version image into the image layer change weight discrimination formula to calculate the weight value, distinguish the four types of change structures: adding layers, modifying layers, replacing layers, and deleting layers, and retain only the changed layers with a weight W≥0.2; S303: Extract newly added system files, third-party dependency packages, and modified configuration entries from the filtered change layers, discard all data in the unchanged layers, generate a lightweight incremental dataset, and transfer it to S4 for targeted vulnerability scanning.

[0009] As a preferred technical solution of this application, step S4 specifically includes: S401: Input the lightweight incremental dataset output by S3 into the vulnerability matching engine, match the incremental content with the general vulnerability disclosure number, the official vulnerability database, and the enterprise's custom business risk rules, without performing a full image traversal scan; S402: Directly retrieve historical vulnerability detection records without changes in layering from the S1 baseline feature library, substitute them into the scanning computing power saving efficiency calculation formula to calculate the resource saving ratio of this scan, and synchronously transmit the original detection results of incremental vulnerabilities to S5 to complete environment verification and correction.

[0010] As a preferred technical solution of this application, step S5 specifically includes: S501: Real-time query of the native runtime parameters of the corresponding container runtime unit; S502: Perform attribute division on the original incremental vulnerability detection results output by S4, and output the accurate vulnerability data after verification to S6.

[0011] As a preferred technical solution of this application, step S6 specifically includes: S601: Aggregates three types of vulnerability data: The baseline library of S1 retains historical vulnerabilities, the newly added vulnerabilities of S4, and the vulnerability data of S5 after attribute classification. S602: Two-layer linkage rules determine high-risk, medium-risk, and low-risk vulnerabilities, among which: First-level judgment criterion: based on calculations. determination, The higher the value, the greater the inherent potential harm of the vulnerability. The second layer of judgment criteria: Based on the original operating parameters of the container operating unit collected by S5, the operating conditions are extracted and divided into three categories: fully exploitable, limited exploitable, and unexploitable. S603: Integrate vulnerability information and attach it to the report. The calculation results are used to output a complete closed-loop dynamic vulnerability inspection report for container assets.

[0012] As a preferred technical solution in this application, the high-risk vulnerability is: ≥0.3, and the operating status is fully available; Medium-risk vulnerabilities: one of them is ≥0.3 but with limited availability / unavailability under certain operating conditions; the second is 0.2≤ <0.3 and the running status is fully available.

[0013] The cloud-native container asset dynamic image incremental vulnerability scanning system employs the cloud-native container asset dynamic image incremental vulnerability scanning method as described in any one of claims 1-8 above, including an image baseline feature library construction module, a dynamic event listening and triggering module, an image layered differential identification module, an incremental targeted vulnerability scanning module, a runtime vulnerability identification and correction module, and an asset vulnerability report generation module. The image baseline feature library construction module specifically includes: The data source connection submodule establishes a two-way communication link with the image repository and Kubernetes cluster, filtering short-term temporary test assets; the layered feature extraction submodule performs layered analysis of the images, collecting four types of features: files, components, dependency packages, and configurations; the time-series persistent storage submodule stores benchmark data using layered hashes as indexes; the existing vulnerability binding submodule performs a full scan of the images newly added to the repository, associating vulnerabilities with the corresponding image layers and storing them in the benchmark repository, providing basic reference data for subsequent differential comparisons and report summaries; The dynamic event listening and triggering module specifically includes: The cluster event capture submodule continuously collects four types of events: image push, container runtime unit start-up and shutdown, configuration update, and image version replacement; the invalid change filtering submodule removes temporary change behaviors based on the asset survival time threshold; the differential instruction issuing submodule pushes differential comparison execution instructions carrying image identifiers to the differential identification module. The mirror layer differential recognition module specifically includes: After receiving the instruction, the baseline data retrieval submodule reads the historical baseline layered data of the image; the layer change judgment submodule judges layer by layer whether there are valid changes with security risks; the incremental data purification submodule removes all data of the unmodified layers, exports the change files, dependency packages, and configurations to form a lightweight incremental dataset, and transmits it to the scanning module.

[0014] As a preferred technical solution of this application, the incremental targeted vulnerability scanning module specifically includes: The incremental vulnerability matching submodule only matches the vulnerability database to obtain the original vulnerability information for lightweight incremental datasets; the historical result reuse submodule directly retrieves historical vulnerability records in the benchmark database that have not been changed in layering, without the need for repeated detection; the scan resource statistics submodule compares the time taken by full scan and incremental scan and records the resource savings. The runtime vulnerability identification and correction module specifically includes: The runtime parameter acquisition submodule obtains runtime parameters such as container account permissions, open ports, and directory mounts in real time; the vulnerability type classification submodule distinguishes between static image vulnerabilities and runtime dynamic vulnerabilities; the risk level correction submodule combines runtime environment exploitation conditions to eliminate false high-risk vulnerabilities with no actual threat and outputs corrected vulnerability data. The asset vulnerability report generation module specifically includes: The multi-source vulnerability aggregation submodule summarizes baseline inventory vulnerabilities, incremental scan vulnerabilities, and corrected vulnerabilities, and removes duplicate and expired records; the vulnerability classification and sorting submodule classifies vulnerabilities into high-risk, medium-risk, and low-risk categories based on the risk level of layered changes and the exploitability conditions of container operation, and completes the sorting; the standardized report output submodule embeds scan resource saving information and generates a complete dynamic inspection report of container assets.

[0015] Compared with the prior art, the beneficial effects of the present invention are as follows: In the scheme of this application: 1. A layered, weighted, differential discrimination mechanism based on image mapping achieves significant savings in computing power and automatic filtering of risk-free modifications. Layered change weights quantify and differentiate between effective risky changes and risk-free configuration tweaks such as modifying comments and spaces. Incremental scanning is initiated only for changes to underlying files and third-party dependency packages that meet the weight criteria, eliminating the need for full image traversal. Weight coefficients are differentiated based on the probability of triggering vulnerabilities for various changes, with the highest weight assigned to changes to underlying system files, ensuring that high-risk modifications are not filtered out, balancing computing power savings with comprehensive vulnerability coverage. 2. By combining a time-series benchmark feature library with a persistent storage and reuse mechanism for existing vulnerabilities, redundant calculations from repeated scans are eliminated. After a full scan is completed for the first image added to the library, existing vulnerabilities are persistently stored in the benchmark library by binding them to the corresponding image layers. During subsequent image iterations, if the layers are not changed, historical detection results can be retrieved directly without repeated vulnerability matching calculations. At the same time, temporary test asset changes with a lifespan of less than 300 seconds are automatically filtered out to prevent invalid scanning tasks from continuously consuming cluster server resources. 3. Through full-coverage cluster dynamic event monitoring and pre-filtering logic, proactive real-time vulnerability inspection is achieved. It fully monitors four types of cluster native change events: new image version push, Pod start and stop, configuration mapping update, and application controller image replacement. Differential scanning is triggered immediately when the image undergoes real business iteration, eliminating the lag of traditional fixed-period passive scanning. It can identify security vulnerabilities carried by newly added components in the iteration in the first time, and significantly reduce the probability of missed scans of dynamic assets. 4. By employing a binary vulnerability identification and correction mechanism at runtime, we simultaneously reduce both false positives and false negatives. We collect runtime parameters such as container running account permissions, open network ports, and host directory mount permissions in real time. Vulnerabilities are categorized into static image vulnerabilities and runtime dynamic vulnerabilities. We eliminate false high-risk vulnerabilities without runtime exploitation conditions, while marking dynamic high-risk vulnerabilities with attack potential, thus accurately correcting the original scan results. 5. A two-tiered hierarchical classification rule combining layered change weights and runtime conditions clearly prioritizes vulnerability handling. Without introducing external independent scoring standards, it automatically categorizes vulnerabilities into high, medium, and low risk based solely on the layered change weights and exploitable container runtime conditions generated internally by the solution. High-risk vulnerabilities are displayed first, and exploitable runtime vulnerabilities at the same risk level are listed first. Each vulnerability includes a layered change tracing path and attack prerequisites. The output inspection report directly guides operations personnel in targeted risk remediation, significantly improving its practicality. 6. Using a hierarchical differential mechanism alone can only improve scanning speed, and using runtime vulnerability identification alone can only optimize vulnerability determination accuracy. This application, by connecting two sets of technical links in series, can significantly reduce computing power consumption while greatly reducing the number of dynamic vulnerability scans. Attached Figure Description

[0016] Figure 1 The flowchart of the incremental vulnerability scanning method and system for dynamic images of cloud-native container assets provided in this application. Detailed Implementation

[0017] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0018] To enable those skilled in the art to better understand the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings.

[0019] It should be noted that, unless otherwise specified, the embodiments and features and technical solutions in the embodiments of the present invention can be combined with each other.

[0020] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0021] Please refer to Figure 1 As shown, the incremental vulnerability scanning method for dynamic images of cloud-native container assets includes the following steps: S1: Connects to the container image repository and Kubernetes (container orchestration platform) cluster, collects multi-dimensional raw image data, and builds a container image benchmark feature library with time-series index, specifically including: S101: Establish a two-way long-connection communication channel, call the image repository application interface and the K8s cluster application interface server to synchronously pull all business image data, filter temporary test images with a lifespan of less than 300 seconds, destroy temporary container running unit assets in one go, and retain the images corresponding to long-term stable running business containers. S102: Perform layered decomposition operations on each version of the image, extract four types of benchmark data layer by layer: image layer file hash verification value, complete list of built-in system components, accurate version number of third-party dependency packages, container static deployment configuration parameters, and synchronously bind the image's unique version ID, cluster namespace label, and image build time, thereby constructing a container image benchmark feature library with time-series index. S103: Store all hierarchical feature data into a container image benchmark feature library with time-series index using hierarchical hash values ​​as the main index, and generate an immutable image benchmark feature set, which serves as the sole reference data source for S3. S104: Perform a full vulnerability scan on the new image that is added to the database for the first time, match the common vulnerability disclosure number to obtain the initial vulnerability list, bind and associate each vulnerability with the corresponding image layer, component, and dependency package, and store it in the constructed image baseline feature library to form a retrievable historical vulnerability dataset.

[0022] S2: Continuously monitors four types of dynamic change events in the cluster, filters out invalid changes, and then issues image layered differential comparison trigger commands, specifically including: S201: Deploy an event interception chain within the cluster to continuously monitor four types of exclusive change events: new version push events from the image repository, creation, destruction, start and stop events of K8s container runtime units, configuration mapping resource configuration file update events, and stateless application controller image version replacement events. S202: Set a fixed threshold of 300 seconds for asset lifespan, automatically filter temporary asset change events whose lifespan has not reached the threshold, and output a differential comparison execution command to S3 after verification, carrying the new version ID of the image.

[0023] S3: Retrieve historical data from the mirror baseline feature library, substitute it into the stratification change weight formula to quantify and determine incremental stratification, extract the pure incremental dataset to be scanned, and the stratification change weight formula is: ; in The weights are changed for a single-layer mirror image. =0.6 is the fixed coefficient for file hash changes; To match the differences in the hierarchical hash, assign 1 if the hierarchical hashes are completely different and 0 if they are completely consistent. =0.3 is the dependency package change factor; Add / remove dependency packages to this layer; =0.1 is the configuration change coefficient; Modify the number of configuration entries for this layer; the single-layer weight determination threshold is fixed at 0.2; + + =1, the priority of assignment is determined based on actual test statistics of three dimensions: the probability of occurrence of cloud-native container vulnerabilities, the severity of vulnerabilities, and the difficulty of exploitation of vulnerabilities: =0.6 (Highest weight for file hash changes): The underlying system files, binary programs, and kernel dependencies in the image layering are all identified by hash values. File hash changes represent the replacement or tampering of the underlying core files of the system. Such changes are very likely to introduce high-risk vulnerabilities such as privilege escalation and remote code execution. Industry statistics show that the probability of triggering high-risk vulnerabilities by changes in underlying files exceeds 65%, which is the highest security risk. Therefore, the maximum weight of 0.6 is assigned. =0.3 (Secondary weight for dependency package changes): Third-party components and open-source dependency packages are the main carriers of vulnerabilities with common vulnerability disclosure numbers. The frequency of vulnerability occurrence is second only to the underlying system files. However, most dependency package vulnerabilities require specific call paths to be triggered, and the upper limit of harm is slightly lower than that of the underlying system files. Industry statistics show that the probability of dependency package changes triggering vulnerabilities is about 30%, so a weight of 0.3 is assigned. =0.1 (Minimum weight for configuration changes): Only configuration parameters, comment text, and port mapping descriptions are modified. There are no changes to program code or binary files. Most configuration changes cannot directly inject executable vulnerabilities. Only a very small number of permission configuration errors will cause security risks. The probability of vulnerability triggering is less than 5%. It has the lowest risk and is assigned a weight of 0.1. The threshold of 0.2 is determined based on actual test data from tens of thousands of image iterations in the cluster. It is used to distinguish between minor changes with no security risks and effective incremental changes with vulnerability risks: scenarios involving only a single configuration comment modification. =1、 =0、 =0, calculated as follows =0.1, less than 0.2, indicating no need for scanning, thus avoiding incremental scanning triggered by numerous meaningless minor configuration changes and saving computing power; Adding a third-party dependency package scenario: =1, with all other parameters set to 0, the calculation yields... =0.3, greater than 0.2, indicating a vulnerability risk; incremental scan initiated; underlying system file replacement scenario: =1, =0.6, far exceeding the threshold, forcing the entry into the incremental scanning process; this threshold can accurately filter out risk-free operations such as only modifying comments, adjusting spaces, and adjusting text breaks, while not missing high-risk modifications to files and dependency packages, balancing scanning accuracy and computing power consumption. S3 specifically includes: S301: Based on the image version ID carried by the differential comparison execution instruction issued by S202, retrieve the hierarchical feature data of the previous complete version of the image from the time series benchmark feature library built by S1. S302: Substitute each layer of data in the new version image into the image layer change weight discrimination formula to calculate the weight value, distinguish the four types of change structures: adding layers, modifying layers, replacing layers, and deleting layers, and retain only the changed layers with a weight W≥0.2; S303: Extract newly added system files, third-party dependency packages, and modified configuration entries from the filtered change layers, discard all data in the unchanged layers, generate a lightweight incremental dataset, and transfer it to S4 for targeted vulnerability scanning.

[0024] S4: Perform vulnerability matching scans only on lightweight incremental datasets, reuse historical detection results of unchanged components in the benchmark library, and quantify the resource saving ratio using a scanning computing power saving efficiency calculation formula. The scanning computing power saving efficiency calculation formula is as follows: ; in This saves computational power for a single scan. Standard time for full image scan; The actual time taken to scan the incremental dataset, in S4, specifically includes: S401: Input the lightweight incremental dataset output by S3 into the vulnerability matching engine, match the incremental content with the general vulnerability disclosure number, the official vulnerability database, and the enterprise's custom business risk rules, without performing a full image traversal scan; S402: Directly retrieve historical vulnerability detection records without changes in layering from the S1 baseline feature library. No need for repeated calculations. Substitute the data into the scanning computing power saving efficiency calculation formula to calculate the resource saving ratio of this scan. Synchronously transmit the original detection results of incremental vulnerabilities to S5 to complete environment verification and correction.

[0025] S5: Real-time retrieval of dynamic parameters from container runtime units, binary differentiation between static image vulnerabilities and runtime dynamic vulnerabilities, and correction of the original scanned vulnerability risk levels, specifically including: S501: Real-time query of the native parameters of the corresponding container running unit, including container running account permissions, list of open network ports, host directory mount permissions, and process running whitelist; S502: Perform attribute classification on the original incremental vulnerability detection results output by S4: mark defects in image files and dependent packages, and vulnerabilities that can be triggered without runtime conditions as static image vulnerabilities; mark vulnerabilities that can only be exploited with high privileges, open ports, and other runtime conditions as runtime dynamic vulnerabilities; eliminate false high-risk vulnerabilities without exploitation conditions; correct the original risk level of vulnerabilities; and output the accurate vulnerability data after verification to S6.

[0026] S6: Time-series aggregation of existing vulnerabilities, incremental vulnerabilities, and vulnerability data after attribute classification, generating a complete dynamic inspection report of container assets according to multi-dimensional classification, specifically including: S601: Aggregates three types of vulnerability data: The S1 baseline library retains historical vulnerabilities, the S4 contains newly added and incremental vulnerabilities, and the S5 vulnerabilities are classified and archived according to four dimensions: cluster, namespace, image version, and change layer path. S602: Two-layer linkage rules determine high-risk, medium-risk, and low-risk vulnerabilities, among which: First-level judgment criterion: based on calculations. determination, The higher the value, the greater the inherent potential harm of the vulnerability. The second layer of judgment criteria: Based on the native operating parameters of the container running unit collected by S5, the conditions for its operation are extracted and divided into three categories: fully exploitable (container root account, publicly accessible port, host directory read / write mount), limited exploitable (ordinary business account, only internal port, host directory read-only mount), and unexploitable (restricted low-privilege account, no external port, no host directory mount). S603: Integrate vulnerability information and attach it to the report. The calculation results are used to output a complete closed-loop dynamic vulnerability inspection report for container assets. Among them, high-risk vulnerabilities include: ≥0.3 and the runtime status is fully exploitable; this type of vulnerability originates from changes in underlying system files or third-party dependency packages, and the container runtime environment has complete conditions for vulnerability exploitation, which can directly trigger serious risks such as privilege escalation and container escape. Medium-risk vulnerabilities: one of them is ≥0.3 but with limited availability / unavailability under certain operating conditions; the second is 0.2≤ <0.3 and fully exploitable in runtime; the vulnerability has inherent risks, but the runtime environment has exploitation limitations, and it can only cause local business data anomalies; Low-risk vulnerabilities: The vulnerability is less than 0.3 and operates under limited exploitable or unexploitable conditions; the vulnerability originates only from minor configuration tweaks and does not present an attack path that can break through container isolation, resulting only in a slight information redundancy leak. Vulnerability sorting rules: All vulnerabilities are sorted in order of high risk first, medium risk second, and low risk last; within the same risk level, S5-marked runtime dynamic vulnerabilities are sorted first, and static image vulnerabilities are sorted last; each vulnerability is accompanied by source information: corresponding incremental layered path, vulnerability-related component type, and runtime exploitation prerequisites.

[0027] The cloud-native container asset dynamic image incremental vulnerability scanning system includes an image baseline signature library construction module, a dynamic event listening and triggering module, an image layered differential identification module, an incremental targeted vulnerability scanning module, a runtime vulnerability identification and correction module, and an asset vulnerability report generation module. The image baseline signature library construction module specifically includes: The data source connection submodule establishes a two-way communication link with the image repository and Kubernetes cluster, filtering short-term temporary test assets; the layered feature extraction submodule performs layered analysis of the images, collecting four types of features: files, components, dependency packages, and configurations; the time-series persistent storage submodule stores benchmark data using layered hashes as indexes; the existing vulnerability binding submodule performs a full scan of the images newly added to the repository, associating vulnerabilities with the corresponding image layers and storing them in the benchmark repository, providing basic reference data for subsequent differential comparisons and report summaries; The dynamic event listener triggering module specifically includes: The cluster event capture submodule continuously collects four types of events: image push, container runtime unit start-up and shutdown, configuration update, and image version replacement; the invalid change filtering submodule removes temporary change behaviors based on the asset survival time threshold; the differential instruction issuing submodule pushes differential comparison execution instructions carrying image identifiers to the differential identification module. The mirror layer differential recognition module specifically includes: After receiving the instruction, the baseline data retrieval submodule reads the historical baseline layered data of the image; the layer change judgment submodule judges layer by layer whether there are valid changes with security risks; the incremental data purification submodule removes all data of the unmodified layers, exports the change files, dependency packages, and configurations to form a lightweight incremental dataset, and transmits it to the scanning module.

[0028] The incremental targeted vulnerability scanning module specifically includes: The incremental vulnerability matching submodule only matches the vulnerability database to obtain the original vulnerability information for lightweight incremental datasets; the historical result reuse submodule directly retrieves historical vulnerability records in the benchmark database that have not been changed in layering, without the need for repeated detection; the scan resource statistics submodule compares the time taken by full scan and incremental scan and records the resource savings. The runtime vulnerability identification and correction module specifically includes: The runtime parameter acquisition submodule obtains runtime parameters such as container account permissions, open ports, and directory mounts in real time; the vulnerability type classification submodule distinguishes between static image vulnerabilities and runtime dynamic vulnerabilities; the risk level correction submodule combines runtime environment exploitation conditions to eliminate false high-risk vulnerabilities with no actual threat and outputs corrected vulnerability data. The asset vulnerability report generation module specifically includes: The multi-source vulnerability aggregation submodule summarizes baseline inventory vulnerabilities, incremental scan vulnerabilities, and corrected vulnerabilities, and removes duplicate and expired records; the vulnerability classification and sorting submodule classifies vulnerabilities into high-risk, medium-risk, and low-risk categories based on the risk level of layered changes and the exploitability conditions of container operation, and completes the sorting; the standardized report output submodule embeds scan resource saving information and generates a complete dynamic inspection report of container assets.

[0029] In this invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," "linking," and "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection, an electrical connection, or a connection that allows communication between them; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components, unless otherwise explicitly limited. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0030] Obviously, the embodiments described above are merely some embodiments of the present invention, not all embodiments. The accompanying drawings show preferred embodiments of the present invention, but do not limit the patent scope of the present invention. The present invention can be implemented in many different forms; rather, these embodiments are provided to provide a more thorough and complete understanding of the disclosure of the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing specific embodiments, or make equivalent substitutions for some of the technical features. Any equivalent structures made using the content of this specification and drawings, directly or indirectly applied to other related technical fields, are similarly within the patent protection scope of this invention.

Claims

1. A method for incremental vulnerability scanning of dynamic images of cloud-native container assets, characterized in that, The following steps are included: S1: Connects to the container image repository and the K8s cluster, collects multi-dimensional raw image data, and builds a container image benchmark feature library with time-series index; S2: Continuously monitor cluster dynamic change events, filter invalid changes, and then issue image layer differential comparison trigger commands; S3: Retrieve historical data from the mirror baseline feature library, substitute it into the stratification change weight formula to quantify and determine incremental stratification, extract the pure incremental dataset to be scanned, and the stratification change weight formula is: ； in The weights are changed for a single-layer mirror image. =0.6 is the fixed coefficient for file hash changes; To match the differences in the hierarchical hash, assign 1 if the hierarchical hashes are completely different and 0 if they are completely consistent. =0.3 is the dependency package change factor; Add / remove dependency packages to this layer; =0.1 is the configuration change coefficient; Modify the number of configuration entries for this layer; the single-layer weight determination threshold is fixed at 0.2; S4: Perform vulnerability matching scans only on lightweight incremental datasets, reuse historical detection results of unchanged components in the benchmark library, and quantify the resource saving ratio using a scanning computing power saving efficiency calculation formula. The scanning computing power saving efficiency calculation formula is as follows: ； in This saves computational power for a single scan. Standard time for full image scan; The actual time taken to scan the incremental dataset; S5: Real-time pull of dynamic parameters of container runtime units, binary distinction between static image vulnerabilities and runtime dynamic vulnerabilities, and correction of the original scan vulnerability risk level; S6: Time-series aggregation of existing vulnerabilities, new vulnerabilities, and vulnerability data after attribute classification, generating a complete dynamic inspection report of container assets according to multi-dimensional classification.

2. The incremental vulnerability scanning method for dynamic images of cloud-native container assets according to claim 1, characterized in that, Specifically, S1 includes: S101: Establish a two-way long-connection communication channel, call the image repository application interface and the K8s cluster application interface server to synchronously pull all business image data, filter temporary test images with a lifespan of less than 300 seconds, destroy temporary container running unit assets in one go, and retain the images corresponding to long-term stable running business containers. S102: Perform layered decomposition operations on each version of the image, extract four types of benchmark data layer by layer: image layer file hash verification value, complete list of built-in system components, accurate version number of third-party dependency packages, container static deployment configuration parameters, and synchronously bind the image's unique version ID, cluster namespace label, and image build time, thereby constructing a container image benchmark feature library with time-series index. S103: Store all hierarchical feature data into the container image benchmark feature library with time-series index using hierarchical hash values ​​as the main index, and generate an immutable image benchmark feature set. S104: Perform a full vulnerability scan on the new image that is added to the database for the first time, match the common vulnerability disclosure number to obtain the initial vulnerability list, bind and associate each vulnerability with the corresponding image layer, component, and dependency package, and store it in the constructed image baseline feature library to form a retrievable historical vulnerability dataset.

3. The incremental vulnerability scanning method for dynamic images of cloud-native container assets according to claim 2, characterized in that, Specifically, S2 includes: S201: Deploy an event interception chain within the cluster to continuously monitor four types of exclusive change events: new version push events from the image repository, creation, destruction, start and stop events of K8s container runtime units, configuration mapping resource configuration file update events, and stateless application controller image version replacement events. S202: Set a fixed threshold of 300 seconds for asset lifespan, automatically filter temporary asset change events whose lifespan has not reached the threshold, and output a differential comparison execution command to S3 after verification, carrying the new version ID of the image.

4. The incremental vulnerability scanning method for dynamic images of cloud-native container assets according to claim 3, characterized in that, Specifically, S3 includes: S301: Based on the image version ID carried by the differential comparison execution instruction issued by S202, retrieve the hierarchical feature data of the previous complete version of the image from the time series benchmark feature library built by S1. S302: Substitute each layer of data in the new version image into the image layer change weight discrimination formula to calculate the weight value, distinguish the four types of change structures: adding layers, modifying layers, replacing layers, and deleting layers, and retain only the changed layers with a weight W≥0.2; S303: Extract newly added system files, third-party dependency packages, and modified configuration entries from the filtered change layers, discard all data in the unchanged layers, generate a lightweight incremental dataset, and transfer it to S4 for targeted vulnerability scanning.

5. The cloud-native container asset dynamic image incremental vulnerability scanning method according to claim 4, characterized in that, Specifically, S4 includes: S401: Input the lightweight incremental dataset output by S3 into the vulnerability matching engine, match the incremental content with the general vulnerability disclosure number, the official vulnerability database, and the enterprise's custom business risk rules, without performing a full image traversal scan; S402: Directly retrieve historical vulnerability detection records without changes in layering from the S1 baseline feature library, substitute them into the scanning computing power saving efficiency calculation formula to calculate the resource saving ratio of this scan, and synchronously transmit the original detection results of incremental vulnerabilities to S5 to complete environment verification and correction.

6. The incremental vulnerability scanning method for dynamic images of cloud-native container assets according to claim 5, characterized in that, Specifically, S5 includes: S501: Real-time query of the native runtime parameters of the corresponding container runtime unit; S502: Perform attribute division on the original incremental vulnerability detection results output by S4, and output the accurate vulnerability data after verification to S6.

7. The incremental vulnerability scanning method for dynamic images of cloud-native container assets according to claim 6, characterized in that, Specifically, S6 includes: S601: Aggregates three types of vulnerability data: The baseline library of S1 retains historical vulnerabilities, the newly added vulnerabilities of S4, and the vulnerability data of S5 after attribute classification. S602: Two-layer linkage rules determine high-risk, medium-risk, and low-risk vulnerabilities, among which: First-level judgment criterion: based on calculations. determination, The higher the value, the greater the inherent potential harm of the vulnerability. The second layer of judgment criteria: Based on the original operating parameters of the container operating unit collected by S5, the operating conditions are extracted and divided into three categories: fully exploitable, limited exploitable, and unexploitable. S603: Integrate vulnerability information and attach it to the report. The calculation results are used to output a complete closed-loop dynamic vulnerability inspection report for container assets.

8. The incremental vulnerability scanning method for dynamic images of cloud-native container assets according to claim 7, characterized in that, The high-risk vulnerability mentioned: ≥0.3, and the operating status is fully available; Medium-risk vulnerabilities: one of them is ≥0.3 but with limited availability / unavailability under certain operating conditions; the second is 0.2≤ <0.3 and the running status is fully available.

9. A cloud-native container asset dynamic image incremental vulnerability scanning system, employing the cloud-native container asset dynamic image incremental vulnerability scanning method as described in any one of claims 1-8, comprising an image baseline feature library construction module, a dynamic event listening and triggering module, an image layered differential identification module, an incremental targeted vulnerability scanning module, a runtime vulnerability identification and correction module, and an asset vulnerability report generation module, characterized in that, The mirror benchmark feature library construction module specifically includes: The data source connection submodule establishes a two-way communication link with the image repository and Kubernetes cluster, filtering short-term temporary test assets; the layered feature extraction submodule performs layered analysis of the images, collecting four types of features: files, components, dependency packages, and configurations; the time-series persistent storage submodule stores benchmark data using layered hashes as indexes; the existing vulnerability binding submodule performs a full scan of the images newly added to the repository, associating vulnerabilities with the corresponding image layers and storing them in the benchmark repository, providing basic reference data for subsequent differential comparisons and report summaries; The dynamic event listening and triggering module specifically includes: The cluster event capture submodule continuously collects four types of events: image push, container runtime unit start-up and shutdown, configuration update, and image version replacement; the invalid change filtering submodule removes temporary change behaviors based on the asset survival time threshold; the differential instruction issuing submodule pushes differential comparison execution instructions carrying image identifiers to the differential identification module. The mirror layer differential recognition module specifically includes: After receiving the instruction, the baseline data retrieval submodule reads the historical baseline layered data of the image; the layer change judgment submodule judges layer by layer whether there are valid changes with security risks; the incremental data purification submodule removes all data of the unmodified layers, exports the change files, dependency packages, and configurations to form a lightweight incremental dataset, and transmits it to the scanning module.

10. The cloud-native container asset dynamic image incremental vulnerability scanning system according to claim 9, characterized in that, The incremental targeted vulnerability scanning module specifically includes: The incremental vulnerability matching submodule only matches the vulnerability database to obtain the original vulnerability information for lightweight incremental datasets; the historical result reuse submodule directly retrieves historical vulnerability records in the benchmark database that have not been changed in layering, without the need for repeated detection; the scan resource statistics submodule compares the time taken by full scan and incremental scan and records the resource savings. The runtime vulnerability identification and correction module specifically includes: The runtime parameter acquisition submodule obtains runtime parameters such as container account permissions, open ports, and directory mounts in real time; the vulnerability type classification submodule distinguishes between static image vulnerabilities and runtime dynamic vulnerabilities; the risk level correction submodule combines runtime environment exploitation conditions to eliminate false high-risk vulnerabilities with no actual threat and outputs corrected vulnerability data. The asset vulnerability report generation module specifically includes: The multi-source vulnerability aggregation submodule summarizes baseline inventory vulnerabilities, incremental scan vulnerabilities, and corrected vulnerabilities, and removes duplicate and expired records; the vulnerability classification and sorting submodule classifies vulnerabilities into high-risk, medium-risk, and low-risk categories based on the risk level of layered changes and the exploitability conditions of container operation, and completes the sorting; the standardized report output submodule embeds scan resource saving information and generates a complete dynamic inspection report of container assets.

Images