A container-oriented exception evaluation and repair method

Abstract

The application provides a container-oriented exception evaluation and repair method, which comprises the following steps: obtaining configuration information of a container, constructing a scenario-adapted rule for evaluation, and performing configuration risk evaluation; performing multi-tool collaborative scanning on a container image to generate multiple scanning results, converting the multiple scanning results into a single trusted result, and performing image risk evaluation; collecting service base information of the container to identify a CPE component, collecting runtime indicators of the container, and performing service risk evaluation; extracting non-compliance item information, constructing a local security knowledge base, performing knowledge matching in the local security knowledge base to generate a repair decision prompt word, guiding a large language model of private deployment to make a repair decision, and performing container repair. The method realizes the organic integration of three-dimensionally independent evaluation results, and fundamentally solves the data island and alarm fatigue problems existing in the prior art. Moreover, the repair process is changed from manual driving to intelligent and automatic driving.

Description

A container-oriented method for anomaly assessment and repair Technical Field

[0001] This invention relates to the field of container safety technology, and in particular to a method for anomaly assessment and repair of containers. Background Technology

[0002] In today's cloud-based digital infrastructure, containerization technology, with its inherent advantages such as lightweightness, portability, and scalability, has become a key technological support for enterprises evolving from traditional monolithic services to modern microservice architectures. However, while accelerating application delivery and deployment, container technology also introduces complex and multi-dimensional security challenges. Due to the architectural characteristic of containers sharing the host machine kernel, their security boundaries are relatively blurred, leading to significant security risks for the underlying platform and adjacent applications.

[0003] While existing container security detection and assessment technologies can initially identify risks within containers, the dispersed and heterogeneous nature of container security data makes it difficult to establish a unified and reliable assessment basis. Furthermore, the short lifecycle and dynamic deployment characteristics of containers make it difficult to capture real-time risk changes using traditional, periodic scanning and assessment methods, easily leading to biased or delayed assessment results. These results fail to accurately reflect the true risk level of containers in specific business scenarios, posing a significant challenge to effective container assessment. Moreover, container security risk remediation and verification rely on manual intervention. Remediation decisions not only heavily depend on operations personnel's deep understanding of the complex container technology stack but also require them to manually correlate vulnerability lifecycle data and assess the scope of business impact. This entire process is inefficient and costly in terms of manpower. This manual, reactive remediation model fundamentally contradicts the highly dynamic and large-scale deployment characteristics of container environments, making it difficult to meet the dual demands of modern cloud-native applications for agility and security.

[0004] Existing automated assessment and remediation solutions for container security mainly include automated solutions based on multiple open-source toolchains, solutions based on commercial unified security platforms, and solutions combining machine learning and threat intelligence. Among these, the automated solution based on multiple open-source toolchains essentially involves linearly chaining together multiple independent, single-function tools. While this method aggregates data from multiple sources, existing solutions stop at simply piling heterogeneous JSON or log results into a unified storage. When different tools produce different or even contradictory scan results for the same image, security personnel are forced to manually integrate information and verify the authenticity of multiple heterogeneous reports, making it difficult to make accurate decisions.

[0005] The core of solutions based on unified commercial security platforms is to provide a powerful, one-stop commercial product. Their core detection engines and risk assessment algorithms are typically closed-source, and in pursuit of universality, their rules and policies are mostly based on general international standards. This "black-box" nature makes it difficult for users to conduct in-depth audits and build trust. Their delivery model directly leads to unacceptable data privacy and compliance risks, especially for industries subject to strict data compliance regulations, such as government and finance. The universality of their strategies results in inherently weak customization capabilities, making it difficult to quickly adapt to specific internal security processes or meet unique compliance requirements.

[0006] The core of the solution combining machine learning and threat intelligence is to establish a "normal baseline" for container behavior and discover anomalies by identifying activities that deviate from this baseline. This approach focuses on analyzing runtime performance rather than the static state of the infrastructure. Because its model training relies on large-scale, high-quality data, it is not only costly to train but also has limited generalization ability in complex and ever-changing business environments, easily generating high false positive rates and exacerbating "alarm fatigue." Furthermore, this solution cannot effectively correlate detected runtime anomalies with infrastructure-level risks, and cannot provide root cause analysis or accurate remediation recommendations.

[0007] Therefore, it is necessary to provide a container-oriented anomaly assessment and remediation method to address the technical challenges in the current container security field, such as incomplete risk coverage and inefficiency and high risk caused by reliance on manual remediation processes. Summary of the Invention

[0008] The purpose of this invention is to provide a container-oriented anomaly assessment and repair method, which provides a full-link, intelligent, secure and controllable automated container security assessment and repair technical solution with multi-dimensional assessment as the core.

[0009] The container-oriented anomaly assessment and remediation method provided by this invention includes: acquiring container configuration information and security benchmarks; defining industry-preset rules; constructing scenario-based adaptation rules based on the container's business scenarios and security benchmarks; conducting configuration risk assessment on the container's configuration information based on the scenario-based adaptation rules and business scenarios; performing multi-tool collaborative scanning of the container image to generate multiple scan results; converting the multiple scan results into a single trusted result; obtaining the container image's CVE baseline score based on the single trusted result; calculating the detection credibility of the single trusted result; and conducting image risk assessment based on the CVE baseline score, detection credibility, and container operating scenario; collecting container service... The system uses basic information to identify CPE components, associates CPE components with CVE vulnerability data, collects runtime metrics of containers, sets impact quantification rules to assess service impact, and performs service risk assessment based on runtime metrics, associated CVE vulnerability data, and service impact. It extracts non-compliance information from configuration risk assessment, image risk assessment, and service risk assessment results, builds a local security knowledge base, performs knowledge matching in the local security knowledge base based on non-compliance information to generate remediation decision prompts, uses these prompts to guide the large language model of the private deployment to make remediation decisions, and performs container anomaly remediation based on the remediation decisions.

[0010] The beneficial effects of the container-oriented anomaly assessment and remediation method provided by this invention are as follows: It proposes and implements a three-dimensional collaborative assessment framework that spans the container lifecycle from static to dynamic perspectives. This framework organically integrates three independent modules—configuration assessment, image assessment, and service assessment—into a cohesive whole, fundamentally solving the data silos and alarm fatigue problems caused by single assessment dimensions and fragmented risk views in existing technologies. Furthermore, it proposes a remediation scheme based on a privately deployed large language model combined with a dynamic security knowledge base, transforming the remediation process from manually driven to intelligently automated.

[0011] In one possible embodiment, obtaining the container's configuration information includes: reading the original configuration information when the container is created; collecting all configuration information of the container during runtime according to a preset period; after each collection of the container's runtime configuration information, comparing the obtained runtime configuration information with the original configuration information according to a predefined list of key fields, and performing differential verification according to the type of key fields to obtain the verified container configuration information; wherein, the differential verification rules include: the security boundary field requires the runtime configuration information to be consistent with the original configuration information, the resource threshold field allows for differences within a set floating error and uses the content in the original configuration information as the verified information, and the runtime status field allows for differences and uses the content in the runtime configuration information as the verified information.

[0012] In another possible embodiment, industry-preset rules are defined, and scenario-based adaptation rules are constructed based on the container's business scenario and security benchmarks. Configuration risk assessment of container configuration information is then performed based on these scenario-based adaptation rules and the business scenario. This includes: defining industry-preset rules for specific industries; extracting the security requirements of each rule from the security benchmarks to obtain basic rules; constructing scenario-based adaptation rules by combining the basic rules, industry-preset rules, and custom rules based on the container's business scenario; defining a business importance mapping rule library based on the business scenario to assess the container's business importance; and using the scenario-based adaptation rules to perform a risk quantification assessment of the container's configuration information. The quantification criteria for each configuration rule include security impact and attack exploitation difficulty. A single rule score is obtained by merging the security impact score, attack exploitation difficulty score, and business importance score. The configuration risk quantification result of the container is obtained by merging the scores of all rules.

[0013] In other possible embodiments, converting multiple scan results into a single trusted result includes identifying conflicts between the multiple scan results and repairing the identified conflicts according to predefined conflict priorities and repair strategies. The conflict priorities and corresponding repair strategies are designed as follows: defining scoring conflicts as P0 level conflicts, when there are CVE scoring conflicts between multiple scan results, the score of the highest priority trusted source is selected as the final score according to the preset trusted source priority; defining package name / version conflicts as P1 level conflicts, when there are disputed components that are not reported by all scan results, the image data is exported and the file system layers in the exported image data are traversed layer by layer to verify the actual existence of the disputed components; defining time conflicts as P2 level conflicts, when the CVE update times reported by multiple scan results are different, the latest date is selected as the update time of the CVE; defining tool compatibility conflicts as P3 level conflicts, when there are vulnerabilities that are not reported by all scan results, the result of a higher priority trusted source is used.

[0014] Image risk assessment is performed based on CVE base score, detection credibility, and container runtime scenario. This includes: obtaining the CVE score from a single trusted result as the base CVE score for the vulnerability; determining the deployment environment coefficient and component importance coefficient based on the container runtime scenario; obtaining the scenario coefficient based on the deployment environment coefficient and component importance coefficient; and integrating the CVE base score, detection credibility, and scenario coefficient to obtain the quantitative result of the container image risk.

[0015] Collect basic service information of the container to identify CPE components, and associate CPE components with CVE vulnerability data. This includes: comparing the basic service information of the container with the package list obtained by image scanning to identify components dynamically installed after the container starts; using the built-in mapping library and regular expressions to convert the identified component information into CPE strings; and querying the official database to verify the validity of the CPE strings and establish the association between CPE and CVE data.

[0016] Service risk assessment is conducted based on runtime metrics, associated CVE vulnerability data, and service impact. This includes: determining the usage frequency of service images and the quantification coefficient of service request numbers based on the collected runtime metrics and fusing them to obtain a risk quantification base; identifying vulnerability patch availability and exploitation activity based on associated CVE data to adjust the risk quantification base to obtain a risk probability index; obtaining the vulnerability CVSS score from the associated CVE vulnerability data; and fusing the risk probability index, CVSS score, and service impact in the business system to obtain the container service risk quantification result.

[0017] A local security knowledge base is constructed. Based on non-compliance information, knowledge matching is performed within the local security knowledge base to generate remediation decision prompts. This includes: collecting security benchmark libraries, official remediation documents, remediation templates for different scenarios, internal historical remediation cases, and internal business constraint rules; and continuously acquiring external real-time threat intelligence, open-source communities, and vendor security announcements to obtain a dataset for building the local security knowledge base. The structured data in the dataset is parsed and converted into JSON objects. Document parsing technology or natural language processing technology is used to identify entity information in semi-structured data and normalize it into JSON objects. The converted data is segmented into knowledge blocks and metadata tags are attached. A high-dimensional vector representing each knowledge block is generated using a pre-trained sentence vector model. A vector index and keyword index for all knowledge blocks are constructed to obtain the local security knowledge base. Non-compliance information is input into the local security knowledge base for retrieval to match professional knowledge. The retrieval results and issue summaries are used together to generate remediation decision prompts.

[0018] The system utilizes repair decision prompts to guide a large language model deployed in a private environment to make repair decisions. Based on these decisions, it performs container anomaly repair, including: guiding the large language model to reason, assessing the risks and impacts of different repair paths, and making a repair decision; generating a target state list based on the repair decisions, which includes the unique identifier of the target container and the target state after repair; and using a smart repair agent running on the container to continuously compare the container's real-time state with the target state to identify differences. Within its authorized scope, the smart repair agent uses its own capability modules to eliminate these differences and achieve repair.

[0019] Before performing anomaly repair on a container, the container information is backed up. After performing anomaly repair on a container based on the repair decision, the following steps are also taken: the repaired container is verified, including verifying whether the repair failed and evaluating the repaired container to determine whether new security risks have emerged. When the repair fails or new security risks emerge in the repaired container, the operation of the repaired container is stopped, and the original environment of the container is rebuilt based on the backup data. Attached Figure Description

[0020] Figure 1 is a flowchart illustrating a container-oriented anomaly assessment and repair method provided in an embodiment of the present invention;

[0021] Figure 2 is a schematic diagram of a process for performing a container configuration risk assessment according to an embodiment of the present invention;

[0022] Figure 3 is a schematic diagram of a process for conducting a container mirror risk assessment according to an embodiment of the present invention;

[0023] Figure 4 is a schematic diagram of a service risk assessment process for containers provided by an embodiment of the present invention;

[0024] Figure 5 is a schematic diagram of a container repair process provided by an embodiment of the present invention;

[0025] Figure 6 is a schematic diagram of an electronic device structure provided by an embodiment of the present invention. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions in the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without inventive effort are within the scope of protection of this invention. Unless otherwise defined, the technical or scientific terms used herein should have the ordinary meaning understood by those skilled in the art. The terms "comprising" and similar expressions used herein mean that the element or object preceding the word covers the element or object listed following the word and its equivalents, but do not exclude other elements or objects.

[0027] This embodiment provides a container-oriented method for anomaly assessment and repair.

[0028] Referring to Figure 1 in the specification, the method includes:

[0029] S101: Obtain the container's configuration information and security benchmarks, define industry-preset rules, construct scenario-based adaptation rules based on the container's business scenarios and security benchmarks, and conduct configuration risk assessments on the container's configuration information based on the scenario-based adaptation rules and business scenarios.

[0030] In one possible embodiment, obtaining the container's configuration information includes: reading the original configuration information at the time of container creation; collecting all configuration information of the container during runtime according to a preset period; after each collection of the container's runtime configuration information, comparing the obtained runtime configuration information with the original configuration information according to a predefined list of key fields, and performing differential verification based on the key field type to obtain the verified container configuration information. The differential verification rules include: the security boundary field requires the runtime configuration information to be consistent with the original configuration information; the resource threshold field allows for differences within a set floating error range, using the content of the original configuration information as the verified information; and the runtime status field allows for differences, using the content of the runtime configuration information as the verified information.

[0031] In one possible embodiment, industry-preset rules are defined, and scenario-based adaptation rules are constructed based on the container's business scenario and security benchmarks. Based on these scenario-based adaptation rules and the business scenario, a configuration risk assessment is performed on the container's configuration information. This includes: defining industry-preset rules for specific industries; extracting the security requirements of each rule from the security benchmarks to obtain basic rules; constructing scenario-based adaptation rules by combining the basic rules, industry-preset rules, and custom rules based on the container's business scenario; defining a business importance mapping rule library based on the business scenario to assess the container's business importance; and using the scenario-based adaptation rules to perform a risk quantification assessment of the container's configuration information. The quantification criteria for each configuration rule include security impact and attack exploitation difficulty. A single rule score is obtained by merging the security impact score, attack exploitation difficulty score, and business importance score. The configuration risk quantification result of the container is obtained by merging the scores of all rules.

[0032] Referring to Figure 2 in the specification, in one specific embodiment, a dual-source trusted data acquisition and verification mechanism is designed. Container configuration information is collected through a combination of real-time capture of dynamic configuration via an Application Programming Interface (API) and static configuration tracing via the file system. Specifically, the API dynamic configuration real-time capture uses an automated script to periodically send requests to the Docker daemon's REST API endpoint `GET / containers / {id} / json`. The API endpoint returns a JSON object containing all configuration information for the container runtime. The script precisely parses the key fields required for evaluation from the returned JSON object, such as `"HostConfig.Memory"` (memory limit) and `"HostConfig.Privileged":true` (whether it is a privileged container). Static configuration tracing and backup directly accesses the Docker (containerization platform) data directory on the host via a script. The static configuration of each container is stored in the directory corresponding to its ID. The system directly reads and parses the JSON file storing the container's static configuration. This JSON file contains the original configuration at the time of container creation and is an immutable, highly reliable data source. To ensure consistency between the dynamic configuration real-time capture data and the static configuration tracing backup data, and to avoid evaluation bias due to an anomaly in a single data source, [further details are provided]. After each API data collection is completed, a comparison script is launched. This script simultaneously retrieves JSON objects from the API and reads JSON objects from backup files, and iterates through a predefined list of key fields to rigorously compare the configuration information in the two data sources.

[0033] The list of key fields corresponds to information about container configuration items, and is categorized into three types based on the security impact and expected variability of these configuration items: security boundary fields, resource threshold fields, and runtime state fields. During data comparison, differential verification is performed based on the field type. Specific differential verification rules include: security boundary fields relate to the container's core security boundaries, and their runtime state must be absolutely consistent with the declarations in the static configuration file; any changes may represent serious security risks. Zero tolerance is applied to the verification of security boundary fields. If any inconsistency exists between the runtime configuration information dynamically captured by the API and the data in the static configuration source backup file, it is immediately identified as a high-risk security event, and an alert is issued directly.

[0034] The resource threshold field primarily relates to resource limitations and typically allows for a ±5% fluctuation to accommodate dynamic adjustments at runtime. If there is an inconsistency between the runtime configuration information dynamically captured by the API and the data in the static configuration backup file, an alarm log will be logged, and the data in the static configuration backup file will be forced to be used for configuration risk assessment. When an inconsistency occurs in the resource threshold field, the difference between the runtime configuration information dynamically captured by the API and the data value in the static configuration backup file will be calculated. If the difference is within the allowed fluctuation range, it is considered normal fluctuation; if the difference exceeds the allowed fluctuation range, an alarm log will indicate that the configuration item has experienced abnormal drift.

[0035] Runtime state fields reflect the container's current running state, which is expected to change. The runtime configuration information dynamically captured by the API is the de facto authoritative data source, while the static configuration backup file serves only as an initial state reference. Differences between the runtime configuration information dynamically captured by the API and the data in the static configuration backup file are not considered errors; instead, the runtime configuration information is used as data for configuration risk assessment.

[0036] Obtaining security benchmarks involves acquiring authoritative benchmarks published by international standardization organizations (such as ISO), national agencies (such as NIST and the China Academy of Information and Communications Technology), and industry authorities (such as CIS), focusing on rules related to "container configuration" and excluding rules related to non-container layers such as host hardware and operating system kernels. Automated scripts are used to parse the security benchmark documents, extracting security requirement fields such as "rule number, security requirements, inspection methods, and risk level," and storing them as a basic rule table in JSON format.

[0037] In one possible implementation, when parsing the security benchmark document, the security requirement description text of each benchmark rule is input into a natural language processing program to generate a corresponding vector embedding. The cosine similarity between different rule vectors is calculated. Rules with similarity scores higher than a set threshold are considered semantic duplicates. For semantically duplicated rules, the most detailed one is retained as the master rule, and the rule numbers of the remaining benchmark rules are stored in the associated benchmark field of the master rule, thereby establishing a mapping relationship from one standardized rule to multiple original benchmark rules.

[0038] Define industry-specific preset rules as preset templates for industries such as finance and government affairs. For example, rules such as "encryption of sensitive data volumes" are mandatory in financial scenarios. The rules support dynamic adjustment of rule weights and compliance thresholds.

[0039] Develop scenario-based adaptation rules, which include basic rules, corresponding industry-preset rules, and custom rules. Custom rules are rules that add or define industry compliance requirements based on specific scenario needs, or rules that adjust the compliance conditions / weights of general rules.

[0040] In one possible embodiment, this application further defines business importance as a dynamic weight adjustment factor applied in the configuration risk assessment of containers. To ensure the automation and objectivity of business importance determination and eliminate subjective intervention, a business importance determination method based on static mapping of metadata and tags is designed. Specifically, for different business environments, the system has a built-in scenario-customized business importance mapping rule library, which maps specific metadata key-value pairs to preset business importance levels. When determining business importance, an automated script automatically collects and parses various metadata associated with the container, mainly including container orchestration platform tags and annotations, and Docker tags. The determination engine extracts the container's metadata and matches it one by one with the rules in the business importance mapping rule library. Once a match is successful, the business importance level of the container is objectively and automatically determined.

[0041] This approach leverages scenario-based adaptation rules and business importance to quantify the risk of container configuration information. Each rule is scored across multiple dimensions, and these scores are then combined using predefined weights to arrive at a single rule score. The weight dimensions used in calculating the single rule score follow and extend the design philosophy of the industry-recognized cybersecurity risk assessment standard—the Common Vulnerability Scoring System (CVSS v3.1). It innovatively applies the core logic of CVSS vulnerability scoring to the scenario of container configuration risk, thereby deriving a self-consistent and interpretable weight system. Specific dimensions include attack exploitation difficulty, security impact, and business importance, corresponding to the "exploitability indicators," "impact indicators," and "environment indicators" in the CVSS base score, respectively, and have a clear mapping relationship with the inherent evaluation logic of CVSS scoring. The weights for each dimension can be dynamically allocated.

[0042] For example, when allocating weights according to the consequences-first principle and the threat balance principle, the consequences-first principle states that the maximum potential loss caused by an action is the primary determinant of risk level across all risk assessment models. Even a vulnerability that is difficult to exploit must be given the highest priority if its exploitation leads to the takeover of the entire cluster. CVSS itself is also non-linear, where impact metrics contribute slightly more to the final score than exploitability metrics. Therefore, the highest weight of 40% is allocated to security impact to ensure the assessment model has the highest sensitivity to configurations with the greatest potential for disruption. The threat balance principle states that whether a configuration item will evolve into a real security incident depends on a combination of two core elements: the technical feasibility of the attack (measured by "exploitation difficulty") and the motivation for the attack (driven by "business importance"). A vulnerability with extremely low exploitability, if located on a worthless test container, will have limited actual threat due to a lack of motivation for attackers. Conversely, a vulnerability located in a core database container, even with high exploitability, will attract attackers to invest more resources in attempting an attack due to its significant business value. Therefore, "attack opportunity" and "attack motivation" are equally important in the process of constituting an actual threat. The remaining 60% weight is evenly distributed between the two dimensions of attack exploitation difficulty and business importance, each accounting for 30%, in order to reflect the two major driving forces that constitute real-world threats in a balanced way.

[0043] For example, a specific definition and quantification standard for weight dimensions are shown in Table 1:

[0044] Table 1. Definition and Quantification Standards of Weight Dimensions

[0045]

[0046] The rule score calculation for a single scenario-based adaptation rule satisfies the following formula: (security impact score × 40% + attack exploitation difficulty score × 30% + business importance score × 30%) × 2, where × 2 is to map the weighted result of 1-5 points to the final weight of 2-10 points, matching the total evaluation score of 100 points.

[0047] Based on the scores of each rule, the container configuration security score is calculated as: (Total score of compliance rules ÷ Total score of all rules) × 100, where the total score of compliance rules is the sum of the weights of the container configuration compliance rules among all rules, and the total score of all rules is the sum of the weights of all rules among the scenario adaptation rules.

[0048] After the calculation is completed, a configuration risk assessment report is generated based on the configuration risk quantification and grading standards. The assessment report includes a risk quantification score and information on non-compliant configurations. The configuration risk quantification and grading standards are shown in Table 2.

[0049] Table 2 Risk Quantification and Classification Standards

[0050]

[0051] S102: Perform multi-tool collaborative scanning of the container image to generate multiple scan results, convert the multiple scan results into a single trusted result, obtain the CVE base score of the container image based on the single trusted result, calculate the detection credibility of the single trusted result, and conduct image risk assessment based on the CVE base score, detection credibility, and container running scenario.

[0052] In one possible embodiment, converting multiple scan results into a single trusted result includes identifying conflicts between the multiple scan results and repairing the identified conflicts according to predefined conflict priorities and repair strategies. The conflict priorities and corresponding repair strategies are designed as follows: defining scoring conflicts as P0 level conflicts, when there are CVE scoring conflicts between multiple scan results, the score of the highest priority trusted source is selected as the final score according to the preset trusted source priority; defining package name / version conflicts as P1 level conflicts, when there are disputed components that are not reported by all scan results, the image data is exported and the file system layers in the exported image data are traversed layer by layer to verify the actual existence of the disputed components; defining time conflicts as P2 level conflicts, when the CVE update times reported by multiple scan results are different, the latest date is selected as the update time of the CVE; defining tool compatibility conflicts as P3 level conflicts, when there are vulnerabilities that are not reported by all scan results, the result of a higher priority trusted source is used.

[0053] In one possible embodiment, image risk assessment is performed based on CVE base score, detection credibility, and container runtime scenario, including: obtaining the CVE score from a single credible result as the vulnerability's CVE base score; determining the deployment environment coefficient and component importance coefficient based on the container runtime scenario; obtaining the scenario coefficient based on the deployment environment coefficient and component importance coefficient; and fusing the CVE base score, detection credibility, and scenario coefficient to obtain the container image risk quantification result.

[0054] Referring to Figure 3 in the specification, in a specific embodiment, when assessing the risk of a container image, mainstream tools are first invoked to perform parallel scans of the container image to obtain multiple scan results. During the scanning process, priorities can be set based on the advantages of each tool.

[0055] For example, four mainstream tools—Trivy, Grype, Snyk, and Clair—are used to scan container images in parallel. The priority is set so that Trivy is called first for system images such as Alpine / Debian; Grype is started synchronously for application images with Java / Python dependencies; Snyk scanning is automatically triggered for enterprise-level images; and Clair is enabled for edge / IoT images.

[0056] Converting fragmented scan results from multiple tools into a single, reliable result first requires identifying conflicts and inconsistencies between the scan results from different tools, including package name / version conflicts, assigner rating conflicts, time conflicts, and tool compatibility conflicts. This invention designs an automatic conflict priority resolution strategy to handle conflicts: P0 level conflicts (rating conflicts): a "trusted source voting" strategy is adopted, prioritizing tools with more accurate database sources. When multiple tools give different CVSS scores for the same CVE, the vulnerability source database for that CVE is queried from each tool's report, and the score from the highest priority database is adopted as the final score. The trusted source priority list of the database is defined as shown in Table 3.

[0057] Table 3 Trusted Source Priority Determination Table

[0058]

[0059] P1-level conflict (package name / version conflict): This strategy prevents false positives from tools by verifying the actual existence of components. For example, when multiple scan results contain a disputed component (e.g., Grype reports the presence of log4j-core-2.17.0.jar while Trivy reports its absence), the system first securely exports the target image as a .tar archive file. This process, involving only reading the image data, is completely safe. Subsequently, this archive file is statically parsed in read-only mode, traversing its internal file system layers to definitively verify the actual existence of the disputed component with forensic-level precision. This zero-execution approach fundamentally eliminates the risk of running untrusted code, providing a more reliable basis for adjudication while significantly improving the security of the assessment platform itself.

[0060] P2 Level Conflict (Time Conflict): Following the principle of prioritizing the most recent modification time, and based on the NIST guidelines that the more frequently the vulnerability database is updated, the more accurate the information, when different tools report different "last modification dates" for the same CVE, the system will simply select the latest date as the update time of the vulnerability information to ensure the timeliness of the assessment basis.

[0061] Level P3 (Tool Compatibility Conflict): Filters low-trust results, i.e., adopts tool results from higher-trust sources. For example, when Clair (a lightweight edge tool) reports a vulnerability but Snyk (an enterprise tool) does not, if the vulnerability only affects an uncommon software package, the system will adopt Snyk's result (i.e., ignore the vulnerability) because Snyk has higher trustworthiness in enterprise application scenarios.

[0062] The formula for quantifying container image risk is: CVE base score × detection credibility (base weight) × scenario coefficient. Here, the CVE base score is the CVE score in a single credible result, representing the inherent severity of the vulnerability; the detection credibility is represented by a base weight assigned based on the empirically verified reliability of the scanning tool's source; the scenario coefficient is a composite indicator determined by the product of the deployment environment coefficient and the component importance coefficient, ensuring that the risk assessment is closely linked to specific business impacts and deployment scenarios. Specifically, the quantification standards for the base weight are shown in Table 4. Furthermore, to prevent the detection credibility of the scanning tool from being affected by version iterations or data, all integrated scanning tools are periodically updated and driven to scan a standardized container image test suite covering multiple operating systems, multiple programming language dependencies, and multiple known vulnerability types. The detection credibility of the scanning tool is then adjusted based on the test results. The quantification standards for the deployment environment coefficient of the scenario are shown in Table 5, and the quantification standards for the component importance coefficient are shown in Table 6.

[0063] Table 4 Basic Weight Quantification Standards

[0064]

[0065] Table 5 Quantification Rules and Standards for Deployment Environment Coefficients

[0066]

[0067] Table 6 Component Importance Coefficient Quantification Rules Standard

[0068]

[0069] After calculating the final image risk quantification value, it is compared with the preset image risk quantification and grading standards, as shown in Table 7. The result is a detailed image risk assessment report, which includes an accurate quantified risk score and a detailed technical description of the specific vulnerabilities.

[0070] Table 7 Mirror Risk Quantification and Grading Standards

[0071]

[0072] It should be noted that since it is common for container images to contain multiple CVE vulnerabilities in actual scans, the risk assessment of a container image involves calculating a risk quantification value for each CVE vulnerability confirmed in a single trusted result, and determining the risk level according to the image risk quantification and grading standard. The final image risk assessment report will list all vulnerabilities contained in the image, their corresponding risk quantification values, and risk levels. The security weakness of an image depends on the most severe vulnerability, and the remediation plan can be arranged according to the vulnerability score.

[0073] S103: Collect basic service information of the container to identify CPE components, associate CPE components with CVE vulnerability data, collect runtime metrics of the container, set impact quantification rules to assess the impact of the service, and conduct service risk assessment based on runtime metrics, associated CVE vulnerability data, and the impact of the service.

[0074] In one possible embodiment, collecting the container's service base information to identify Common Platform Enumeration (CPE) components and associating CPE components with CVE vulnerability data includes: comparing the container's service base information with a list of software packages obtained through image scanning to identify components dynamically installed after the container starts; using a built-in mapping library and regular expressions to convert the identified component information into a CPE string; and querying the official database to verify the validity of the CPE string and establish the association between CPE and CVE data.

[0075] In one possible embodiment, service risk assessment is performed based on runtime metrics, associated CVE vulnerability data, and the impact of services. This includes: determining the usage frequency of service images and the quantification coefficients of service request numbers based on the collected runtime metrics and fusing them to obtain a risk quantification base; identifying the patch availability and exploitation activity of vulnerabilities based on associated CVE data to adjust the risk quantification base to obtain a risk probability index; obtaining the CVSS score of vulnerabilities from the associated CVE vulnerability data; and fusing the risk probability index, CVSS score, and the impact of services in the business system to obtain the service risk quantification result of containers.

[0076] Referring to Figure 4 in the manual, the collection of basic service information and runtime metrics of containers is used for service risk assessment. The collection of basic service information involves using an automated script to call the dockerinspect interface via the Docker SDK to obtain basic information about the container service, including the container core identifier, port exposure details, and service running status. This output is then parsed and compared with the known package list during image scanning to identify components dynamically installed after container startup. Runtime metrics include the number of service requests and image usage frequency. The number of service requests is calculated by monitoring the host kernel's network information file and combining it with the network namespace information of each container to accurately count and distinguish the inbound network connections and data packets flowing to a specific container service, thereby calculating the requests per second (RPS) and concurrent connections for that service. Image usage frequency is collected by calling the Docker API's GET / containers / json?all=true endpoint and then counting the number of container instances with the same ImageID in the returned results. This number directly reflects the deployment scale and usage frequency of a specific image in the current environment.

[0077] Based on the container's service infrastructure information, CPE components are identified and associated with CVE vulnerability data. To ensure the accuracy of CPE generation, the principle of "static analysis as much as possible, and minimizing intrusion when necessary" is followed. When the precise version of a runtime component cannot be determined solely through static image analysis, a pre-defined read-only version query command is executed temporarily and in a controlled manner within the container using the `docker exec` command. This aims to obtain the necessary version information in a way that minimizes the impact on the container's runtime environment. After obtaining the version information, this temporary process is destroyed without any persistent impact. For each identified component, a built-in "vendor-product" mapping library and regular expressions are used to convert it into a standard CPE 2.3 format string (e.g., nginx:1.9.1→cpe:2.3:a:nginx:nginx:1.9.1:*:*:*:*:*:*). Subsequently, a query is initiated to the NVD CPE dictionary API to verify whether the CPE string is valid and exists in the official database, ensuring the accuracy of subsequent CVE associations. Extract "CVE ID-Vulnerability Type-CVSS Base Score" (e.g., CVE-2016-0746-DoS-7.5) to complete the automated association of CPE and CVE data.

[0078] The formula for quantifying the service risk of a container is: Impact (I) × Probability (L) × CVSS Score (S). Here, Probability (L) is a composite dynamic indicator. Its risk quantification base is constructed by multiplying the service image usage frequency and the number of service requests by a quantification coefficient. The vulnerability patch availability and activity level are used to adjust the risk quantification base to obtain the final risk probability index. The CVSS Score (S) directly adopts the official score of the vulnerability associated with the service. Impact (I) quantifies the importance of the service within the business system.

[0079] Specifically, the quantification standards for service image usage frequency are shown in Table 8, and the quantification standards for service request numbers are shown in Table 9. The adjustment of the risk quantification base based on vulnerability patch availability and exploitation activity is real-time and dynamic: when quantifying risk probability, the availability of CVE patches and exploitation activity are automatically identified to adjust the risk quantification base. For example, if an official patch has been released for a CVE vulnerability, the risk quantification base will be multiplied by a mitigation factor of 0.7; if the CVE vulnerability is in an active exploitation period, the risk quantification base will be multiplied by an aggravation factor of 1.3. The quantification standards for impact are shown in Table 10.

[0080] Table 8 Service Image Usage Frequency Coefficient Quantification Rules Standard

[0081]

[0082] Table 9 Service Request Quantification Rules Standard

[0083]

[0084] Table 10 Influence Coefficient Quantification Rules and Standards

[0085]

[0086] After calculating the quantified service risk value, it is mapped to the preset service risk quantification and grading standard to generate a comprehensive assessment report. The assessment report includes the service risk quantification score and a detailed description of the specific vulnerabilities in service management and their risk performance during operation. The service risk quantification and grading standard is shown in Table 11.

[0087] Table 11 Service Risk Quantification and Grading Standards

[0088]

[0089] S104: Extract non-compliance information from the results of configuration risk assessment, image risk assessment and service risk assessment, build a local security knowledge base, perform knowledge matching in the local security knowledge base based on the non-compliance information to generate remediation decision prompts, use the remediation decision prompts to guide the large language model of private deployment to make remediation decisions, and perform container anomaly repair based on the remediation decisions.

[0090] In one possible embodiment, a local security knowledge base is constructed. Based on non-compliance information, knowledge matching is performed within the local security knowledge base to generate remediation decision prompts. This includes: collecting security benchmark libraries, official remediation documents, remediation templates for different scenarios, internal historical remediation cases, and internal business constraint rules; and continuously acquiring external real-time threat intelligence, open-source communities, and vendor security announcements to obtain a dataset for constructing the local security knowledge base; parsing the structured data in the dataset and converting it into JSON objects; using document parsing technology or natural language processing technology to identify entity information in semi-structured data and normalizing it into JSON objects; segmenting the converted data into knowledge blocks and attaching metadata tags; generating high-dimensional vectors representing each knowledge block using a pre-trained sentence vector model; constructing vector indexes and keyword indexes for all knowledge blocks to obtain the local security knowledge base; inputting non-compliance information into the local security knowledge base for retrieval to match professional knowledge; and using the retrieval results and issue summaries together to generate remediation decision prompts.

[0091] In one possible embodiment, a repair decision prompt is used to guide a privately deployed large language model to make a repair decision, and the container anomaly is repaired based on the repair decision. This includes: the repair decision prompt guides the privately deployed large language model to perform reasoning, assess the risks and impacts of different repair paths, and make a repair decision; a target state list is generated based on the repair decision, the target state list includes the unique identifier of the target container and the target state of the container after repair; an intelligent repair agent running on the container cyclically compares the real-time state of the container with the target state to find differences, and the intelligent repair agent uses its own capability modules within its authorized scope to eliminate the differences to achieve repair.

[0092] In one possible embodiment, container information is backed up before abnormal container repair is performed; after abnormal container repair is performed according to the repair decision, the method further includes: performing repair verification on the repaired container, which includes verifying whether the repair failed and evaluating the repaired container to determine whether new security risks have emerged; when the repair fails or new security risks emerge in the repaired container, the operation of the repaired container is stopped, and the original environment of the container is rebuilt based on the backup data.

[0093] Referring to Figure 5 in the manual, a local knowledge base is designed and constructed to drive precise decision-making using a Large Language Model (LLM) for private deployment. The local knowledge base is a structured, multi-source information fusion entity. It collects data from the Docker security benchmark library (integrating authoritative standards such as CIS Docker Benchmark, Cybersecurity Classified Protection 2.0, and NIST SP 800-190), official Docker remediation documentation, remediation templates for different scenarios (templates for modifying running container configurations, Dockerfile optimization, image version management, etc.), historical remediation cases from within the enterprise (recording solutions to past container non-compliance issues, adapted business scenarios, and effects), and internal business constraint rules (requiring business suspension before container remediation in the production environment, prohibiting the deletion of core image backups, and prohibiting the exposure of specific ports, etc.). It also continuously accesses external real-time threat intelligence, open-source communities, and vendor security announcements via API to dynamically supplement the data source.

[0094] Building a local knowledge base requires transforming data from diverse sources and formats into a unified knowledge system that can be efficiently utilized by retrieval-enhanced generative (RAG) models. The process of building a local knowledge base includes: multi-source data extraction and structured normalization, intelligent chunking and metadata tagging, and hybrid index construction.

[0095] Specifically, multi-source data extraction and structured normalization include: for structured data, parsing the inherent "rule ID-description-risk-remediation suggestion" structure of this type of data, extracting each security baseline rule and converting it into an independent JSON object; for semi-structured data, using document structure parsing libraries based on Markdown and HTML or natural language processing (NLP) technology, identifying key entities such as headings, paragraphs, code blocks, and tables, and normalizing the text content into JSON objects containing these fields.

[0096] Intelligent segmentation and metadata tagging include: dividing normalized data into semantically complete and appropriately sized knowledge blocks, and automatically attaching key metadata tags to each knowledge block, such as its source (e.g., CIS_Benchmark_v1.4.0), type (e.g., compliance_rule or historical_case), and core entity (e.g., CVE-2021-44228), which can be used for precise filtering in subsequent searches.

[0097] The hybrid index construction involves: inputting the text content of each knowledge block into a pre-trained sentence vector model to generate a high-dimensional vector representing the semantics of the knowledge block; and embedding and storing the vectors of all knowledge blocks in a vector database to complete the vector index construction. This allows the system to quickly find the most relevant knowledge blocks based on the semantics of the question. A keyword index is then built on the metadata of all knowledge blocks to complete the keyword index construction, allowing for efficient metadata filtering during retrieval. The hybrid index, which combines vector and keyword indexes, is designed to leverage both the precision of keyword retrieval and the semantic similarity of vector retrieval.

[0098] Based on the risk assessment results of the container configuration, image, and service generated in steps S101 to S103, output a JSON format report to ensure that the program can be parsed, and extract key information of non-compliance items to generate a searchable problem summary.

[0099] The key information extracted regarding non-compliance items refers to the abnormal entity objects (such as configuration item names, affected package names, and service identifiers), abnormal state descriptions (such as current parameter values, vulnerability CVE numbers, and port exposure status), and risk level identifiers parsed and structured from the risk assessment results. This information collectively constitutes the core query elements used for vector retrieval and keyword matching in the local knowledge base. Non-compliance items are specific technical objects that, during the container risk assessment, are deemed to deviate from security benchmarks, possess known vulnerabilities, or exhibit abnormal states. Depending on the assessment dimensions, non-compliance items specifically include the following three logical definitions:

[0100] For the configuration dimension, non-compliance items refer to configuration parameters that violate baseline rules, including: non-compliant configuration parameter names: i.e., specific Docker parameter fields, such as HostConfig.Privileged, User, etc., which are key keys for retrieving remediation scripts; current anomalous values ​​and expected compliant values: for example, "current value: root, expected value: non-root" or "current value: true (privileged mode), expected value: false", which determines what kind of modification commands LLM needs to generate; associated baseline rule ID or name: for example, "CIS-Docker-5.1", used to accurately retrieve the corresponding official remediation guide in the knowledge base.

[0101] For the mirror dimension, non-compliance items mainly refer to CVE vulnerabilities and related components assessed as high-risk, including: affected component name and current version: for example, openssl version 1.0.1, which is the basis for the intelligent remediation agent to call the package manager for upgrades; unique vulnerability identifier (CVE ID): for example, CVE-2021-44228, used to retrieve specific patch information or mitigation measures for the vulnerability in the knowledge base; target remediation version: scanning tools usually suggest a remediation version, and if this information is included in the report, it should also be extracted as key information to directly guide the remediation target status.

[0102] For the service dimension, non-compliance items refer to high-risk exposure states or business violations during runtime, including: service runtime context labels: such as "Public Exposed Port", "Core Business", "High Traffic", which are used by LLM to determine the aggressiveness of the remediation strategy (e.g., whether to restart immediately or wait for a window period); the associated high-risk vulnerability and service mapping relationship: clearly indicating which service (container) is running an image containing a specific vulnerability, establishing a bridge between "runtime and static vulnerability".

[0103] After analyzing the evaluation results, the problem summary generated based on the extracted key information of non-compliance items is input into the local security knowledge base for preliminary retrieval. The purpose is to quickly match relevant professional knowledge and generate professional and accurate remediation decision prompts. This ensures that the large language model deployed in the private location can accurately call the required reference information when performing inference, avoiding the generation of unrealistic suggestions. For example, when receiving the problem summary: "The container is running as the root user," RAG is used to retrieve the most relevant contextual information from the local security knowledge base—related CIS clauses, internal policies that prohibit root users, and historical cases of successful remediation through the --user parameter. This information, along with the problem summary, is then packaged into a content-rich remediation decision prompt template.

[0104] The generated remediation decision prompts are sent to a privately deployed large language model. This model performs deep reasoning based on the context provided in the remediation strategy prompts, assesses the risks and impacts of different remediation paths, and ultimately makes the optimal decision. The large language model compiles its decision results into a highly readable and structurally precise list of target states, which is then distributed to the intelligent remediation agent for use in container remediation.

[0105] The target state list is a structured data file generated by a large language model deployed in a private location based on multi-dimensional evaluation results of the container. The target state list precisely describes the target state that a security-compliant container should present after remediation. Its content is specific and accurate, covering all attributes that need to be corrected, such as package status, kernel parameters, process status, and configuration items.

[0106] For example, to ensure both machine and human readability, the target state manifest uses YAML format, consisting of two main parts: metadata and spec. Metadata stores descriptive information about the manifest itself, such as the unique identifier of the target container, ensuring the manifest can be accurately applied to the specified container. The spec is layered according to the evaluation dimensions and attributes of the remediation content, covering package status, kernel parameters, process status, configuration items, etc. For example: configuration items define the correct core configuration parameters for container runtime; kernel parameters define the correct interaction permissions between the container and the host kernel for precise control; package status describes the package status inside the container to fix vulnerabilities in the image; and process status defines the process status inside the container during runtime to detect and terminate abnormal processes, etc.

[0107] The SmartRepair Agent is a privileged container running on each Docker host, possessing control over the Docker daemon. Its core operation is a continuous tuning loop that iteratively compares the target state list with the container's real-time state to ensure consistency. When a discrepancy is detected, the SmartRepair Agent autonomously decides which of its capabilities to invoke to eliminate the difference. Internally, the SmartRepair Agent employs a series of atomic capabilities or executors, such as PackageManager, KernelTuner, and FileSystemManager. For example, if the SmartRepair Agent detects that the OpenSSL version is too low, it calls PackageManager.Upgrade("openssl",">=1.1.1t-1) to achieve a repair effect.

[0108] In one possible implementation, while ensuring the high privileges required for the intelligent repair agent's repair, the agent's permissions are strictly limited: First, all unnecessary kernel permissions are stripped away using Linux's Capabilities mechanism (--cap-drop=ALL discards all default permissions and precisely adds the required ones); second, a custom AppArmor or SELinux security configuration file is loaded to create an unbypassable mandatory access control "security fence" at the operating system kernel level, strictly restricting its access to the host file system and network; then, a streamlined Seccomp system call whitelist is used to intercept and terminate any dangerous system calls beyond its intended scope of functionality. Finally, within the agent's application logic, a hard-coded command whitelist and a strict parameter purging mechanism are used to defend against risks arising from misled LLM decisions. This restrictive design of the intelligent repair agent ensures that while it can execute its legitimate repair tasks via Docker sockets, its attack surface is greatly reduced, effectively preventing the risks of privilege abuse and container escape.

[0109] In one possible embodiment, a remediation verification mechanism is designed, including: backing up the container before remediation to prevent problems from occurring during the remediation process; after the automated remediation of the container is completed, the container is re-evaluated to ensure that no new security risks emerge after remediation; if new risks are found during container verification or remediation fails, a rollback process is immediately triggered, i.e., the operation of the remediated container is stopped, and the original environment is rebuilt based on the backup data. Detailed logs of remediation failures are recorded and fed back to a local knowledge base as valuable experience for future LLM decisions, forming a closed loop of continuous learning and iteration.

[0110] This invention provides a container-oriented anomaly assessment and repair method, proposing and implementing a three-dimensional collaborative assessment framework that spans the container lifecycle from static to dynamic perspectives. It organically integrates three independent modules—configuration assessment, image assessment, and service assessment—into a cohesive whole, fundamentally solving the data silos and alarm fatigue problems caused by single assessment dimensions and fragmented risk views in existing technologies. Furthermore, this assessment framework specifically incorporates:

[0111] By employing a dual-source trusted data collection and verification mechanism, container configuration information is collected through a combination of dynamic real-time capture via API and static configuration tracing via the file system. A verification engine with differentiated tolerance strategies intelligently categorizes configuration items into three types based on their security impact and expected variability: "zero-tolerance" security boundary fields, "static upper limit" resource threshold fields, and "dynamic authority" runtime state fields. Different verification logics are applied to each category, achieving a precise and innovative verification solution that breaks through traditional limitations. Combined with the normalization processing of multi-source heterogeneous benchmarks and a dynamic weight model strongly correlated with business scenarios, a precise, reliable, and dynamically adaptable configuration baseline assessment scheme is established for container security.

[0112] By designing a multi-tool collaboration and four-level conflict intelligent calibration mechanism, conflict reports from different scanning tools are automatically and deterministically normalized into a single high-confidence result. This solves the industry problem that is common in existing technologies: the detection blind spots of a single scanning tool, and the result conflicts and alarm storms that occur when multiple tools are scanned.

[0113] By integrating runtime dynamic metrics (service request count, image usage frequency) with the importance of static vulnerabilities and business scenarios, a scenario-based dynamic weighted model is constructed. This model can accurately quantify the risks of services in real-world operating environments and dynamically calculate the actual risk level of vulnerabilities in real-world environments. It achieves precise quantification from static vulnerabilities to dynamic risks, thereby truly enabling accurate risk prioritization. This fills the gap in traditional static assessments that cannot cover dynamic risks and overcomes the limitations of traditional static analysis.

[0114] This invention proposes a container-oriented anomaly assessment and remediation method that combines a privately deployed large language model with a dynamic security knowledge base. The method first constructs a local security knowledge base integrating authoritative benchmarks, remediation templates, historical cases, and business constraint rules. During the remediation decision-making phase, the "credibility" of the decision is addressed through the privately deployed large language model + RAG, and deep reasoning is performed through the dynamic security knowledge base to generate a declarative "target state list." The execution phase is handled by an intelligent remediation agent with restricted permissions, adhering to the defense-in-depth principle. Its continuous tuning loop ensures consistency between the container state and the target state. Furthermore, the method integrates a security mechanism of "full backup before remediation, automatic verification after remediation, and automatic rollback of anomalies," forming a fully automated closed loop of "assessment-decision-execution-verification-rollback." This achieves high controllability and reliability of the remediation process while ensuring data privacy and security. It transforms the remediation process from manually driven to intelligently automated, and solves the core pain points of excessively high executor privileges and uncontrollable risks in traditional automated remediation processes. This significantly improves the accuracy of container security management while greatly enhancing the efficiency and security of the remediation process.

[0115] In other embodiments of this application, an electronic device is disclosed, as shown in FIG6. The electronic device 300 may include: one or more processors 301; a memory 302; a display 303; one or more application programs (not shown); and one or more computer programs 304. The above-mentioned devices can be connected via one or more communication buses 305. The one or more computer programs 304 are stored in the memory and configured to be executed by the one or more processors 301. The one or more computer programs 304 include instructions that can be used to perform the steps shown in FIG1 and the corresponding embodiments.

[0116] Through the above description of the embodiments, those skilled in the art will clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

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

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

[0119] The above description is merely a specific implementation of the embodiments of this application, but the protection scope of the embodiments of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the embodiments of this application should be covered within the protection scope of the embodiments of this application. Therefore, the protection scope of the embodiments of this application should be determined by the protection scope of the claims.

Claims

1. A container-oriented anomaly assessment and repair method, characterized in that, include: The process involves: acquiring container configuration information and security benchmarks; defining industry-preset rules; constructing scenario-based adaptation rules based on the container's business scenarios and security benchmarks; and conducting configuration risk assessments on the container's configuration information based on these scenario-based adaptation rules and business scenarios. This includes: defining industry-preset rules for specific industries; extracting the security requirements of each rule from the security benchmarks to obtain basic rules; constructing scenario-based adaptation rules by combining the basic rules, industry-preset rules, and custom rules based on the container's business scenarios; defining a business importance mapping rule base based on business scenarios to assess the container's business importance; and using the scenario-based adaptation rules to perform risk quantification assessments on the container's configuration information, including the quantification of each configuration rule. The standard includes security impact and attack exploitation difficulty. A single rule score is obtained by integrating the security impact score, attack exploitation difficulty score, and business importance score. The scores of all rules are then combined to obtain the container's configuration risk quantification result. Multiple scan results are generated through multi-tool collaborative scanning of the container image. These multiple scan results are then converted into a single trusted result. Based on this single trusted result, the CVE baseline score of the container image is obtained. The detection credibility of the single trusted result is calculated. Based on the CVE baseline score, the detection credibility, and the container's operating scenario, an image risk assessment is performed, including: obtaining the CVE score from the single trusted result as the vulnerability's CVE baseline score; and determining the deployment environment system based on the container's operating scenario. The system calculates the risk quantification result of container images by combining the importance coefficients of the deployment environment and components, and then integrating these coefficients with the CVE base score, detection reliability, and scenario coefficients. It collects basic service information of the container to identify CPE components, associates CPE components with CVE vulnerability data, collects runtime metrics of the container, sets impact quantification rules to assess the service's impact, and performs service risk assessment based on the runtime metrics, associated CVE vulnerability data, and service impact. This includes determining the quantification coefficients of service image usage frequency and service request count based on the collected runtime metrics and integrating them to obtain a risk quantification base, and identifying... The vulnerability patch availability and exploitation activity are used to adjust the risk quantification base to obtain a risk probability index; the vulnerability CVSS score is obtained from the associated CVE vulnerability data; the risk probability index, the CVSS score, and the service's impact on the business system are combined to obtain the container service risk quantification result; non-compliance information is extracted from the results of configuration risk assessment, image risk assessment, and service risk assessment, and a local security knowledge base is constructed. Knowledge matching is performed in the local security knowledge base based on the non-compliance information to generate remediation decision prompts. The remediation decision prompts are used to guide the private deployment's large language model to make remediation decisions, and container anomaly remediation is performed based on the remediation decisions.

2. The method according to claim 1, characterized in that, Obtaining container configuration information includes: reading the original configuration information when the container is created; collecting all configuration information of the container during runtime according to a preset period; after each collection of container runtime configuration information, comparing the obtained runtime configuration information with the original configuration information according to a predefined list of key fields, and performing differential verification according to the key field type to obtain the verified container configuration information; wherein, the differential verification rules include: the security boundary field requires that the runtime configuration information be consistent with the original configuration information, the resource threshold field allows for differences within a set floating error and uses the content in the original configuration information as the verified information, and the runtime status field allows for differences and uses the content in the runtime configuration information as the verified information.

3. The method according to claim 1, characterized in that, Converting multiple scan results into a single reliable result involves identifying conflicts between the multiple scan results and repairing the identified conflicts according to predefined conflict priorities and repair strategies. The conflict priority and corresponding remediation strategy design includes: defining scoring conflicts as P0 level conflicts; when there are CVE scoring conflicts among multiple scan results, the score of the highest priority trusted source is selected as the final score according to the preset trusted source priority; defining package name / version conflicts as P1 level conflicts; when there are disputed components that are not reported by all scan results, the image data is exported and the file system layer in the exported image data is traversed layer by layer to verify the actual existence of the disputed components; defining time conflicts as P2 level conflicts; when the CVE update times reported by multiple scan results are different, the latest date is selected as the update time of the CVE; and defining tool compatibility conflicts as P3 level conflicts; when there are vulnerabilities that are not reported by all scan results, the result of a higher priority trusted source is adopted.

4. The method according to claim 1, characterized in that, Collect basic service information of the container to identify CPE components, and associate CPE components with CVE vulnerability data. This includes: comparing the basic service information of the container with the package list obtained by image scanning to identify components dynamically installed after the container starts; using the built-in mapping library and regular expressions to convert the identified component information into CPE strings; and querying the official database to verify the validity of the CPE strings and establish the association between CPE and CVE data.

5. The method according to claim 1, characterized in that, A local security knowledge base is constructed. Based on non-compliance information, knowledge matching is performed within the local security knowledge base to generate remediation decision prompts. This includes: collecting security benchmark libraries, official remediation documents, remediation templates for different scenarios, internal historical remediation cases, and internal business constraint rules; and continuously acquiring external real-time threat intelligence, open-source communities, and vendor security announcements to obtain a dataset for constructing the local security knowledge base. The structured data in the dataset is parsed and converted into JSON objects. Document parsing technology or natural language processing technology is used to identify entity information in semi-structured data and normalize it into JSON objects. The converted data is segmented into knowledge blocks and metadata tags are attached. A high-dimensional vector representing each knowledge block is generated using a pre-trained sentence vector model. A vector index and keyword index for all knowledge blocks are constructed to obtain the local security knowledge base. The non-compliance information is input into the local security knowledge base for retrieval to match professional knowledge. The retrieval results and issue summaries are used together to generate remediation decision prompts.

6. The method according to claim 1, characterized in that, The process involves using the repair decision prompts to guide a privately deployed large language model to make repair decisions, and then performing container anomaly repair based on these decisions. This includes: the repair decision prompts guiding the privately deployed large language model to perform reasoning, assessing the risks and impacts of different repair paths, and making a repair decision; generating a target state list based on the repair decisions, which includes the unique identifier of the target container and the target state after container repair; and a smart repair agent running on the container cyclically comparing the container's real-time state with the target state to identify differences, and then using its own capabilities within its authorized scope to eliminate these differences and achieve repair.

7. The method according to claim 1, characterized in that, Before performing anomaly repair on a container, the container information is backed up. After performing anomaly repair on a container based on the repair decision, the following steps are also taken: the repaired container is verified, including verifying whether the repair failed and evaluating the repaired container to determine whether new security risks have emerged. When the repair fails or new security risks emerge in the repaired container, the operation of the repaired container is stopped, and the original environment of the container is rebuilt based on the backup data.

Images