A security verification method, electronic device and storage medium

Abstract

This application relates to the field of network security verification technology, and discloses a security verification method, electronic device, and storage medium. The security verification method includes: obtaining the source runtime image corresponding to the target object and the factors to be verified; constructing a baseline image and a verification image based on the same source runtime image, retaining only the minimum difference change set related to the factors to be verified, synchronously injecting state seeding data into the baseline image and the verification image, and executing a uniformly orchestrated verification task; continuously collecting multi-dimensional runtime evidence generated by the baseline image and the verification image during operation; performing differential analysis based on the runtime evidence; and outputting verification conclusions based on the differential analysis results. By constructing a dual-image runtime environment around the same source runtime image, containing only the minimum difference change set, and executing a uniformly orchestrated verification task in both environments, and combining multi-dimensional runtime evidence for automatic differential analysis, automated and trusted verification of vulnerabilities, PoCs, detection rules, patches, and virtual patches can be achieved.

Description

Technical Field

[0001] This invention relates to the field of network security verification technology, and in particular to a security verification method, electronic device, and storage medium. Background Technology

[0002] With the increasing demand for network security testing, vulnerability verification, and security operations, existing security verification technologies have formed multiple adjacent directions.

[0003] One type of technical solution uses virtual machine images, container images, or sandbox environments to quickly build vulnerability verification environments to improve vulnerability verification efficiency; another type of technical solution uses automated methods to analyze the real impact of vulnerable components on business systems to solve the problem of "whether the vulnerability is truly exploitable"; and some solutions compare manual verification results with automated detection results to evaluate the effectiveness of vulnerability scanners or security detection tools.

[0004] Meanwhile, research on differential testing shows that by building a control test environment around the original system and the modified system, more differences in operational behavior can be discovered compared to traditional regression testing. Vulnerability detection tool evaluation research also indicates that the confidence level of detection results is highly dependent on the consistency of the test environment and the design of the verification scenario.

[0005] Existing vulnerability verification, patch verification, and security detection rule verification technologies typically employ a single-image environment or a single-side runtime environment to perform verification tasks. While these technologies can determine the existence of vulnerabilities or whether rules are applied to a certain extent, they still suffer from the following problems: difficulty in accurately distinguishing between real vulnerability triggers and environmental noise, repetitive verification logic, weak reusability, and a tendency to generate false positives or false negatives. Summary of the Invention

[0006] The purpose of this invention is to provide at least one security verification method, electronic device, and storage medium, which can at least solve the technical problem that existing methods are unable to accurately distinguish between real vulnerability triggers and environmental noise.

[0007] To address the aforementioned technical problems, at least one embodiment of this application provides a security verification method, comprising: Obtain the source runtime image corresponding to the target object and the factors to be verified; A baseline image and a verification image are built based on the same source running image; only the minimum set of differences related to the factor to be verified are retained between the baseline image and the verification image; State seeding data is synchronously injected into the baseline image and the verification image; Perform a unified set of verification tasks on the baseline image and the verification image; During the execution of the verification task, multi-dimensional operational evidence generated by the benchmark image and the verification image during operation is continuously collected. Differential analysis is performed based on the operational evidence of the benchmark image and the verification image; The verification conclusions are output based on the results of the difference analysis.

[0008] At least one embodiment of this application also provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the security verification method described above.

[0009] At least one embodiment of this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the security verification method described above.

[0010] The method provided in the embodiments of this application constructs a dual-image runtime environment with only a minimum set of differences around the same source runtime image, performs a uniformly orchestrated verification task in both environments, and performs automatic differential analysis in combination with multi-dimensional runtime evidence, thereby achieving automated and trusted verification of vulnerabilities, PoCs, detection rules, patches, and virtual patches.

[0011] In some optional embodiments, the source runtime image includes a virtual machine image, a container image, a host snapshot image, a cloud runtime environment image, or a combined runtime image composed of a virtual machine image, a container image, a host snapshot image, and a cloud runtime environment image; The factors to be verified include one or more of the following: vulnerability triggering conditions, PoC scripts, detection rules, security policies, patches, virtual patches, configuration changes, feature switches, and verification scripts. The minimum change set includes component version switching, configuration file modification, patch loading, security rule insertion, feature switch activation / deactivation, code snippet modification, and enabling or disabling vulnerability triggering conditions.

[0012] In some optional embodiments, the state seeding data includes test accounts, business data, session tickets, token information, cached data, environment variables, traffic replay seeds, time offset parameters, and keys and certificates.

[0013] In some optional embodiments, verification conclusions are output based on the differential analysis results, including: when the differential analysis results show that the verification image triggers the target behavior while the baseline image does not trigger the target behavior, the factor to be verified is determined to be valid; when both the verification image and the baseline image trigger the target behavior, environmental noise, rule false alarms, or baseline contamination are determined to exist; when neither the verification image nor the baseline image triggers the target behavior, the verification object is determined to be invalid or the sample is insufficient; when only the baseline image triggers the target behavior while the verification image does not trigger the target behavior, the patch or virtual patch is determined to be valid.

[0014] In some optional embodiments, the unified orchestration means that the task parameters, execution order, time window, concurrency strategy, retry rules, and convergence conditions of the baseline image and the verification image are kept consistent; the verification tasks include vulnerability triggering tasks, PoC execution tasks, detection rule verification tasks, patch validity verification tasks, virtual patch verification tasks, and security policy verification tasks.

[0015] In some optional embodiments, the runtime evidence includes network request and response behavior, process tree changes, system call traces, file access behavior, log events, API call chains, memory changes, database access behavior, middleware state changes, and alarm events.

[0016] In some optional embodiments, the security verification method described above further includes, after each round of verification: Perform a snapshot rollback on the baseline image and the verification image, and reapply parameter perturbations to perform a re-verification; the parameter perturbations include changes in concurrency level, input load, latency, data path, session order, and traffic replay segments. If the results of multiple rounds of retesting are consistent, the confidence level of the final verification conclusion will be increased.

[0017] In some optional embodiments, the above-described security verification method further includes: A reusable verification template is generated based on the verification results; the verification template includes at least some of the information in the source mirror identifier, difference construction method, state seeding package, task orchestration rules, difference threshold, evidence collection strategy, and re-verification parameters. Attached Figure Description

[0018] One or more embodiments are illustrated by way of example with reference to the accompanying drawings, and these illustrative descriptions do not constitute a limitation on the embodiments.

[0019] Figure 1 This is a flowchart of a security verification method provided in an embodiment of this application; Figure 2 This is a schematic diagram illustrating the principle of the security verification method provided in the embodiments of this application; Figure 3 This is a schematic diagram of a security verification device provided in an embodiment of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the various embodiments of this application will be described in detail below with reference to the accompanying drawings. However, those skilled in the art will understand that many technical details have been provided in the various embodiments of this application to help readers better understand this application. However, the technical solutions claimed in this application can be implemented even without these technical details and various changes and modifications based on the following embodiments. The division of the various embodiments below is for the convenience of description and should not constitute any limitation on the specific implementation of this application. The various embodiments can be combined with and referenced by each other without contradiction.

[0021] To facilitate understanding of the embodiments of this application, relevant content regarding the prior art will be introduced first.

[0022] Existing vulnerability verification, patch verification, and security detection rule verification technologies typically employ a single-image environment or a single-side runtime environment to perform verification tasks. While these technologies can determine the existence of vulnerabilities or whether rules have been applied to a certain extent, they still suffer from the following problems: Existing technologies typically execute verification tasks in a single runtime environment. During verification, these processes are easily affected by factors such as system version, dependent components, cache status, business data, session context, and network conditions. This makes it difficult to accurately distinguish between real vulnerability triggers and environmental noise, resulting in low confidence levels in verification conclusions and a lack of a strictly controlled control environment. Because factors such as system version, dependent components, cache status, session context, network environment, and time baseline can all influence verification results, existing technologies struggle to accurately differentiate between real vulnerability triggers and environmental noise.

[0023] Most existing solutions are designed for a specific scenario among vulnerability verification, Proof of concept (PoC) verification, detection rule verification, or patch verification. There is no unified framework that supports automated differential verification of vulnerabilities, PoCs, detection rules, patches, and virtual patches, resulting in duplicated verification logic and weak reusability.

[0024] Existing technologies typically rely solely on logs, returned results, or alarm information for judgment, lacking joint analysis of multi-dimensional operational evidence such as network behavior, system calls, process behavior, file access, memory changes, and API (Application Programming Interface) call chains. This can easily lead to false positives or false negatives, making it difficult to effectively reduce false positives and false negatives.

[0025] In addition, existing solutions typically lack a unified snapshot rollback and verification mechanism. When verification results are affected by concurrency, timing, cache status, or random factors, it is difficult to reproduce the verification results stably and confirm them credibly.

[0026] Therefore, how to construct an automated security verification system based on strictly controlled variables and achieve credible differential analysis through multidimensional operational evidence has become an important issue in the current field of network security verification.

[0027] To address the technical problem of existing methods' inability to accurately distinguish between real vulnerability triggers and environmental noise, this invention proposes a security verification method, electronic device, and storage medium. The implementation details of the security verification method in this embodiment are described below. These details are provided for ease of understanding and are not essential for implementing this solution.

[0028] Example 1: The security verification method of this embodiment can be applied to electronic devices with communication, computing, and data storage capabilities. Its specific process can be as follows: Figure 1 As shown, it includes: Step 101: Obtain the source running image corresponding to the target object and the factors to be verified.

[0029] Specifically, the source runtime image includes virtual machine images, container images, host snapshot images, cloud runtime environment images, or a combination of virtual machine images, container images, host snapshot images, and cloud runtime environment images. Factors to be verified include one or more of the following: vulnerability triggering conditions, PoC scripts, detection rules, security policies, patches, virtual patches, configuration changes, signature switches, and verification scripts.

[0030] Step 102: Build a baseline image and a verification image based on the same source running image; retain only the minimum set of differences related to the factors to be verified between the baseline image and the verification image.

[0031] In its implementation, the system constructs a first image and a second image based on the same source runtime image. The first image serves as the baseline image, and the second image as the verification image. Only the minimum set of changes related to the factors to be verified is retained between the two images; the rest of the runtime environment remains consistent. The minimum set of changes includes component version switching, configuration file modification, patch loading, security rule insertion, feature switch activation / deactivation, code snippet changes, and enabling or disabling of vulnerability triggering conditions. A dual-image verification environment with only the minimum set of changes is constructed based on the same source runtime image, achieving a security verification mechanism with strict variable control through the minimum set of changes.

[0032] In some cases, the two mirrors maintain consistency in dimensions such as system version, dependent components, network environment, middleware configuration, business data, account system, cache status, and time baseline to form a dual-mirror verification environment with strict control over variables.

[0033] Step 103: Synchronously inject state seeding data into the baseline image and the verification image.

[0034] After the dual-image construction is completed, state seeding data is synchronously injected into the dual images. The dual-image state synchronous seeding mechanism is used to achieve running state alignment before verification.

[0035] In its implementation, state seeding is performed in an idempotent manner, and a unique verification identifier is generated for each round of verification. State seeding data includes test accounts, business data, session tickets, token information, cached data, environment variables, traffic replay seeds, time offset parameters, as well as keys and certificates.

[0036] In some examples, state seeding is performed in an idempotent manner, and a unique verification identifier is generated for each round of verification for the association and alignment of evidence in subsequent runs, so as to ensure that the two mirrors are in an alignable initial state before the verification task is performed.

[0037] Step 104: Perform a unified orchestration verification task on the baseline image and the verification image.

[0038] Specifically, unified orchestration means maintaining consistency in task parameters, execution order, time windows, concurrency strategies, retry rules, and convergence conditions between the baseline and verification images. Verification tasks include vulnerability triggering tasks, PoC execution tasks, detection rule verification tasks, patch validity verification tasks, virtual patch verification tasks, and security policy verification tasks. Unified orchestration reduces environmental noise introduced by differences in execution paths, improving the comparability of results from both sides. The unified orchestration's bilateral synchronous verification mechanism is used to reduce environmental noise caused by differences in execution paths.

[0039] Step 105: During the execution of the verification task, continuously collect multi-dimensional operational evidence generated by the benchmark image and the verification image during operation.

[0040] During the verification task execution, multi-dimensional operational evidence generated during the dual-mirror operation is continuously collected. Specifically, operational evidence includes network request and response behavior, process tree changes, system call traces, file access behavior, log events, API call chains, memory changes, database access behavior, middleware state changes, and alarm events. Furthermore, the operational evidence from both sides is correlated and aligned based on verification identifiers, timestamps, and task types.

[0041] Step 106: Perform differential analysis based on the operational evidence of the baseline image and the verification image.

[0042] The differential analysis mechanism based on multidimensional runtime evidence is used to jointly analyze runtime evidence such as network behavior, system calls, process behavior, file access, log events, and memory changes.

[0043] Step 107: Output verification conclusions based on the differential analysis results.

[0044] Specifically, when the differential analysis results indicate that the verification image triggers the target behavior while the baseline image does not, the factor to be verified is deemed valid; when both the verification image and the baseline image trigger the target behavior, environmental noise, rule false alarms, or baseline contamination are identified; when neither the verification image nor the baseline image triggers the target behavior, the verification object is deemed invalid or the sample is insufficient; when only the baseline image triggers the target behavior while the verification image does not, the patch or virtual patch is deemed valid.

[0045] In some examples, after completing the collection of operational evidence, event normalization, time alignment, noise removal, feature extraction, differential analysis, and weight calculation are performed on the bilateral operational evidence. Furthermore, differential feature vectors and differential confidence scores are generated to achieve differential analysis. When the verification image triggers the target behavior while the baseline image does not, the factor to be verified is determined to be valid; when both sides trigger, environmental noise, rule false alarms, or baseline contamination are determined; when neither side triggers, the verification object is determined to be invalid or the sample is insufficient; when only the baseline image triggers and the verification image does not, the patch or virtual patch is determined to be valid. Based on the automatic confidence calculation mechanism of the differential feature vectors, differential analysis results are obtained, and verification conclusions are output, realizing a unified automated differential verification framework for vulnerabilities, PoCs, detection rules, patches, and virtual patches.

[0046] The method in this embodiment achieves security verification based on minimum difference dual-images. It constructs a dual-image runtime environment with only minimum difference changes around the same source image, executes a uniformly orchestrated verification task in both environments, and performs automatic differential analysis by combining multi-dimensional runtime evidence, thereby achieving automated and trusted verification of vulnerabilities, PoCs, detection rules, patches, and virtual patches.

[0047] In some embodiments, the security verification method described above further includes, after each round of verification: Perform snapshot rollback on the baseline and validation images, and reapply parameter perturbations to perform a revalidation; If the results of multiple rounds of retesting are consistent, the confidence level of the final verification conclusion will be increased.

[0048] In practice, an automatic re-verification mechanism based on snapshot rollback is implemented. After each round of verification, a snapshot rollback is performed on both images, and parameter perturbations are reapplied for re-verification. Specifically, parameter perturbations include changes in concurrency level, input load, latency, data path, session order, and traffic replay segments. If the results of multiple rounds of re-verification remain consistent, the confidence of the final verification conclusion is increased, thereby enhancing the stability and reproducibility of the verification results.

[0049] In some embodiments, the security verification method described above further includes: Generate a reusable verification template based on the verification results.

[0050] Specifically, the verification template includes at least some of the information from the source mirror identifier, difference construction method, state seeding package, task orchestration rules, differential threshold, evidence collection strategy, and re-verification parameters.

[0051] By condensing the verification results into reusable verification templates that include source image identifiers, differential construction methods, state seeding packages, task orchestration rules, differential thresholds, evidence collection strategies, and re-verification parameters, it is easy to automate the reuse of verification for similar vulnerabilities, rules, PoCs, or patch scenarios in the future.

[0052] The method in this embodiment achieves security verification based on minimum difference dual-images. It constructs a dual-image runtime environment with only minimum difference changes based on the same source running image, and combines state synchronization seeding, unified task orchestration, multi-dimensional runtime evidence collection, differential feature analysis, and snapshot rollback verification mechanism to achieve automated and reliable verification of vulnerabilities, PoCs, detection rules, patches, and virtual patches, thereby improving the accuracy, stability, reproducibility, and interpretability of security verification results.

[0053] Example 2: Based on the above embodiments, this embodiment provides an application example of a security verification method.

[0054] The security verification method in this embodiment constructs a dual-image runtime environment around a shared source image, containing only a minimal set of differences. A uniformly orchestrated verification task is executed in both environments, and automatic differential analysis is performed using multi-dimensional runtime evidence. This enables automated and trusted verification of vulnerabilities, Proof-of-Concept (PoC), detection rules, patches, and virtual patches. The principle of this security verification method is as follows: Figure 2 As shown.

[0055] First, obtain the source runtime image and the factors to be verified corresponding to the target object. The source runtime image can be a virtual machine image, container image, host snapshot image, cloud runtime environment image, or a combination of the above. Factors to be verified can include vulnerability triggering conditions, PoC scripts, detection rules, security policies, patches, virtual patches, configuration changes, signature switches, and verification scripts, etc.

[0056] Two images are built based on the same source image. The first image serves as the baseline image, and the second image serves as the verification image. Only the minimum set of changes related to the factors to be verified is retained between the two images; the rest of the runtime environment remains consistent. The minimum set of changes can include component version switching, configuration file modification, patch loading, security rule insertion, feature switching, code snippet changes, and enabling or disabling vulnerability triggering conditions. Preferably, the two images maintain consistency in system version, dependent components, network environment, middleware configuration, business data, account system, cache status, and time baseline to form a dual-image verification environment with strictly controlled variables.

[0057] After the dual-image construction is completed, state seeding data is synchronously injected into both images. State seeding data includes test accounts, business data, session tickets, token information, cached data, environment variables, traffic replay seeds, time offset parameters, and keys and certificates. Preferably, state seeding is performed in an idempotent manner, and a unique verification identifier is generated for each round of verification for the association and alignment of subsequent running evidence, ensuring that the dual images are in an alignable initial state before executing verification tasks.

[0058] Subsequently, a unified orchestration verification task is performed on both images. Unified orchestration means that both images maintain consistency in terms of task parameters, execution order, time windows, concurrency strategies, retry rules, and convergence conditions. Verification tasks may include vulnerability triggering tasks, PoC execution tasks, detection rule verification tasks, patch validity verification tasks, virtual patch verification tasks, and security policy verification tasks. This unified orchestration approach reduces environmental noise introduced by differences in execution paths and improves the comparability of the results from both sides.

[0059] During the verification task execution, multi-dimensional operational evidence generated during the dual-mirror operation is continuously collected. This operational evidence includes network request and response behavior, process tree changes, system call traces, file access behavior, log events, API call chains, memory changes, database access behavior, middleware state changes, and alarm events. The system correlates and aligns the operational evidence from both sides based on verification identifiers, timestamps, and task types.

[0060] After completing the collection of operational evidence, event normalization, time alignment, noise removal, feature extraction, differential analysis, and weight calculation are performed on the bilateral operational evidence, and differential feature vectors and differential confidence scores are further generated. When the verification mirror triggers the target behavior while the baseline mirror does not, the factor to be verified can be determined to be valid; when both sides trigger, environmental noise, rule false alarms, or baseline contamination can be determined; when neither side triggers, the verification object can be determined to be invalid or the sample is insufficient; when only the baseline mirror triggers and the verification mirror does not, the patch or virtual patch can be determined to be valid.

[0061] After each round of verification, a snapshot rollback is performed on the dual mirrors, and parameter perturbations are reapplied for re-verification. Parameter perturbations include changes in concurrency level, input load, latency, data path, session order, and traffic replay segments. If the results of multiple rounds of re-verification remain consistent, the confidence level of the final verification conclusion is increased, thereby enhancing the stability and reproducibility of the verification results.

[0062] In some examples, the confidence level is output along with the validation conclusion.

[0063] Furthermore, the verification results can be compiled into reusable verification templates. These templates include source image identifiers, differential construction methods, state seeding packages, task orchestration rules, differential thresholds, evidence collection strategies, and re-verification parameters, enabling automated reuse and verification for similar vulnerabilities, rules, PoCs, or patch scenarios.

[0064] Based on the above security verification methods, the following application examples are provided.

[0065] Application Example 1: Web Vulnerability Detection Rule Validation HTTP security detection rules are used as the factors to be verified. The system first exports a source runtime image from the business test environment and builds a dual-image environment based on the same source image. The first image does not load the rules to be verified and serves as the baseline image; the second image loads the rules to be verified and serves as the verification image. Except for the differences in the rules to be verified, the rest of the runtime environment remains consistent.

[0066] Subsequently, the system synchronously injects the same test account, business data, session state, and cached data into both mirrors, and executes the same HTTP requests on both sides under a unified task orchestration strategy. During the verification process, the system continuously collects operational evidence generated during the operation of both sides, such as request logs, WAF logs, plugin logs, response behavior, process behavior, and rule hit records, and correlates and aligns the evidence from both sides based on timestamps and verification identifiers.

[0067] Furthermore, differential analysis is performed on the evidence from both sides. If the second mirror trigger rule is triggered but the first mirror does not, the detection rule is considered valid; if both sides are triggered, the rule is considered to have issues such as overly broad matching, business baseline contamination, or environmental noise; if neither side is triggered, the verification sample is considered insufficient or the rule is ineffective.

[0068] The above methods enable automated and reliable verification of detection rules with reduced human intervention.

[0069] Application Example 2: PoC Harmlessness Verification The Proof-of-Concept (PoC) is used as the object to be verified. The system first builds a dual-image environment by running images from the same source. The first image maintains a normal control state, while the second image introduces vulnerability triggering conditions. The system executes the same PoC on both sides, but replaces the original destructive payload with a harmless labeled payload, and only observes whether preset intermediate evidence appears during the verification process.

[0070] Intermediate evidence includes, but is not limited to, specific anomaly information, echo markers, changes in call trajectories, memory markers, changes in resource access paths, and changes in file access. During the verification process, the system simultaneously collects evidence from both sides and performs differential analysis.

[0071] If only the second mirror shows controlled intermediate evidence, while the first mirror does not show the corresponding behavior, the vulnerability logic corresponding to the PoC is considered valid; if the corresponding behavior appears on both sides, it is determined that there may be environmental noise or verification condition contamination; if no intermediate evidence appears on either side, it is determined that the PoC was not successfully triggered or the verification samples are insufficient.

[0072] The above method enables the verification of PoC logic validity without performing actual destructive actions, thereby reducing security risks during the verification process.

[0073] Application Example 3: Patch or Virtual Patch Validity Verification Patches or virtual patches are used as verification factors. The system sets the unpatched state as the first image and the state with loaded patches or virtual patch policies as the second image. Except for patch-related differences, the rest of the runtime environment remains consistent.

[0074] The system synchronously injects the same business status and test data into both mirrors and performs the same verification tasks on both sides. During the verification process, the system continuously collects operational evidence such as vulnerability triggering behavior, blocking logs, rejection responses, system call traces, process behavior, and network behavior.

[0075] If the first image exhibits vulnerability triggering behavior, while the second image only exhibits blocking logs, denial of response, or policy hit behavior, and no vulnerability execution chain is formed, then the patch or virtual patch is deemed effective; if vulnerability triggering behavior occurs on both sides, then the patch is deemed ineffective; if vulnerability triggering behavior does not occur on either side, then the verification conditions are deemed insufficient or the sample is inadequate.

[0076] The system can also combine the results of multiple rounds of snapshot rollback verification to further output fine-grained verification conclusions on the patch effect, such as "effective blocking", "partial blocking", "policy too lenient" or "policy not effective".

[0077] Application Example 4: Vulnerability Authenticity Verification The target scenario is vulnerability verification. The system first generates a source runtime image based on the business operating environment, and then constructs a dual-image environment around the vulnerability triggering conditions. The first image maintains the normal business state, while the second image introduces the vulnerability triggering conditions.

[0078] After injecting business data, test accounts, and session states into both mirrors synchronously, the system performs a unified vulnerability verification task on both sides. During the verification process, the system continuously collects operational evidence such as network behavior, system calls, process tree changes, database access behavior, and log events, and performs differential analysis.

[0079] If only the second image exhibits the preset vulnerability trigger behavior, while the first image does not, the vulnerability is considered to actually exist. If the vulnerability behavior occurs on both sides, it is determined that there is noise in the verification environment or abnormal behavior in the business itself. If neither side triggers the vulnerability, it is determined that the vulnerability does not exist or the verification conditions are insufficient.

[0080] By using a dual-mirror minimum difference control variable approach, the problem of misjudgment caused by environmental differences in the traditional vulnerability verification process can be effectively reduced, thereby improving the credibility of vulnerability authenticity verification.

[0081] Example 3: Another embodiment of this application relates to a security verification device. The implementation details of the security verification device in this embodiment are described below. The following implementation details are provided for ease of understanding and are not essential for implementing this solution. A schematic diagram of the security verification device in this embodiment can be seen as follows: Figure 3 As shown, it includes an acquisition module 310, a construction module 320, an injection module 330, an orchestration module 340, a collection module 350, an analysis module 360, and an output module 370.

[0082] The acquisition module 310 is used to acquire the source running image corresponding to the target object and the factors to be verified.

[0083] Specifically, the source runtime image includes virtual machine images, container images, host snapshot images, cloud runtime environment images, or a combination of virtual machine images, container images, host snapshot images, and cloud runtime environment images. Factors to be verified include one or more of the following: vulnerability triggering conditions, PoC scripts, detection rules, security policies, patches, virtual patches, configuration changes, signature switches, and verification scripts.

[0084] Module 320 is used to build a baseline image and a verification image based on the same source running image; the baseline image and the verification image retain only the minimum set of differences related to the factors to be verified.

[0085] In practice, the system builds a first image and a second image based on the same source runtime image. The first image serves as the baseline image, and the second image serves as the verification image. Only the minimum set of changes related to the factors to be verified is retained between the two images; the rest of the runtime environment remains consistent. The minimum set of changes includes component version switching, configuration file modification, patch loading, security rule insertion, feature switch activation / deactivation, code snippet changes, and enabling or disabling of vulnerability triggering conditions.

[0086] In some cases, the two mirrors maintain consistency in dimensions such as system version, dependent components, network environment, middleware configuration, business data, account system, cache status, and time baseline to form a dual-mirror verification environment with strict control over variables.

[0087] The injection module 330 is used to synchronously inject state seeding data into the baseline image and the verification image.

[0088] After completing the dual-mirror construction, state seeding data is synchronously injected into both mirrors.

[0089] In its implementation, state seeding is performed in an idempotent manner, and a unique verification identifier is generated for each round of verification. State seeding data includes test accounts, business data, session tickets, token information, cached data, environment variables, traffic replay seeds, time offset parameters, as well as keys and certificates.

[0090] In some examples, state seeding is performed in an idempotent manner, and a unique verification identifier is generated for each round of verification for the association and alignment of evidence in subsequent runs, so as to ensure that the two mirrors are in an alignable initial state before the verification task is performed.

[0091] The orchestration module 340 is used to perform unified orchestration verification tasks on the baseline image and the verification image.

[0092] Specifically, unified orchestration means that the task parameters, execution order, time windows, concurrency strategies, retry rules, and convergence conditions of the baseline image and the verification image are kept consistent. Verification tasks include vulnerability triggering tasks, PoC execution tasks, detection rule verification tasks, patch validity verification tasks, virtual patch verification tasks, and security policy verification tasks. By using unified orchestration, environmental noise introduced by differences in execution paths can be reduced, and the comparability of the results from both sides can be improved.

[0093] The acquisition module 350 is used to continuously acquire multi-dimensional operational evidence generated by the benchmark image and the verification image during the execution of the verification task.

[0094] During the verification task execution, multi-dimensional operational evidence generated during the dual-mirror operation is continuously collected. Specifically, operational evidence includes network request and response behavior, process tree changes, system call traces, file access behavior, log events, API call chains, memory changes, database access behavior, middleware state changes, and alarm events. Furthermore, the operational evidence from both sides is correlated and aligned based on verification identifiers, timestamps, and task types.

[0095] Analysis module 360 ​​is used for differential analysis based on operational evidence from the baseline and validation images.

[0096] Output module 370 is used to output verification conclusions based on the differential analysis results.

[0097] Specifically, when the differential analysis results indicate that the verification image triggers the target behavior while the baseline image does not, the factor to be verified is deemed valid; when both the verification image and the baseline image trigger the target behavior, environmental noise, rule false alarms, or baseline contamination are identified; when neither the verification image nor the baseline image triggers the target behavior, the verification object is deemed invalid or the sample is insufficient; when only the baseline image triggers the target behavior while the verification image does not, the patch or virtual patch is deemed valid.

[0098] In some examples, after completing the collection of operational evidence, event normalization, time alignment, noise removal, feature extraction, differential analysis, and weight calculation are performed on the bilateral operational evidence. Furthermore, differential feature vectors and differential confidence scores are generated to achieve differential analysis. When the verification mirror triggers the target behavior while the baseline mirror does not, the factor to be verified is determined to be valid; when both sides trigger, environmental noise, rule false alarms, or baseline contamination are determined to exist; when neither side triggers, the verification object is determined to be invalid or the sample is insufficient; when only the baseline mirror triggers and the verification mirror does not, the patch or virtual patch is determined to be valid. Verification conclusions are output based on the above differential analysis results.

[0099] The device in this embodiment achieves security verification based on minimum difference dual-images. It constructs a dual-image running environment with only minimum difference changes around the same source image, executes a uniformly orchestrated verification task in both environments, and performs automatic differential analysis by combining multi-dimensional running evidence, thereby achieving automated and trusted verification of vulnerabilities, PoCs, detection rules, patches, and virtual patches.

[0100] In some embodiments, the security verification device described above further includes: a verification module, used for: After each round of verification, a snapshot rollback is performed on the baseline image and the verification image, and parameter perturbations are reapplied to perform a re-verification; if the results of multiple rounds of re-verification are consistent, the confidence of the final verification conclusion is increased.

[0101] In practice, after each round of verification, a snapshot rollback is performed on the dual mirrors, and parameter perturbations are reapplied for re-verification. Specifically, parameter perturbations include changes in concurrency level, input load, latency, data path, session order, and traffic replay segments. If the results of multiple rounds of re-verification remain consistent, the confidence of the final verification conclusion is increased, thereby enhancing the stability and reproducibility of the verification results.

[0102] In some embodiments, the security verification device described above further includes: a generation module, configured to: generate a reusable verification template based on the verification result.

[0103] Specifically, the verification template includes at least some of the information from the source mirror identifier, difference construction method, state seeding package, task orchestration rules, differential threshold, evidence collection strategy, and re-verification parameters.

[0104] By condensing the verification results into reusable verification templates that include source image identifiers, differential construction methods, state seeding packages, task orchestration rules, differential thresholds, evidence collection strategies, and re-verification parameters, it is easy to automate the reuse of verification for similar vulnerabilities, rules, PoCs, or patch scenarios in the future.

[0105] The device in this embodiment achieves security verification based on minimum difference dual-images. It constructs a dual-image running environment with only minimum difference changes based on the same source running image, and combines state synchronization seeding, unified task orchestration, multi-dimensional running evidence collection, differential feature analysis, and snapshot rollback verification mechanism to achieve automated and reliable verification of vulnerabilities, PoCs, detection rules, patches, and virtual patches, thereby improving the accuracy, stability, reproducibility, and interpretability of security verification results.

[0106] It is worth mentioning that all modules involved in this embodiment are logical modules. In practical applications, a logical unit can be a physical unit, a part of a physical unit, or a combination of multiple physical units. Furthermore, to highlight the innovative aspects of this application, this embodiment does not introduce units that are not closely related to solving the technical problems proposed in this application; however, this does not mean that other units are absent in this embodiment.

[0107] In some optional embodiments, the security verification device described above can implement the security verification method in any of the above embodiments.

[0108] Example 4: Another embodiment of this application relates to an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the security verification methods described in the above embodiments.

[0109] In this embodiment, the memory and processor are connected via a bus, which can include any number of interconnected buses and bridges, connecting various circuits of one or more processors and the memory together. The bus can also connect various other circuits, such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be further described in this embodiment. A bus interface provides an interface between the bus and the transceiver. The transceiver can be a single element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices over a transmission medium. Data processed by the processor is transmitted over the wireless medium via an antenna, which further receives data and transmits it to the processor.

[0110] The processor manages the bus and general processing, and also provides various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. Memory is used to store data used by the processor during operation.

[0111] Example 5: Another embodiment of this application relates to a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the security verification method embodiment described above.

[0112] That is, those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, 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 USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0113] Those skilled in the art will understand that the above embodiments are specific embodiments for implementing this application, and in practical applications, various changes can be made to them in form and detail without departing from the spirit and scope of this application.

Claims

1. A security verification method, characterized in that, include: Obtain the source runtime image corresponding to the target object and the factors to be verified; Build a baseline image and a verification image based on the same source running image; Only the minimum set of differences related to the factor to be verified is retained between the baseline image and the verification image; State seeding data is synchronously injected into the baseline image and the verification image; Perform a unified set of verification tasks on the baseline image and the verification image; During the execution of the verification task, multi-dimensional operational evidence generated by the benchmark image and the verification image during operation is continuously collected; Differential analysis is performed based on the operational evidence of the benchmark image and the verification image; The verification conclusions are output based on the results of the difference analysis.

2. The security verification method according to claim 1, characterized in that, The source runtime image includes virtual machine images, container images, host snapshot images, cloud runtime environment images, or a combination runtime image composed of virtual machine images, container images, host snapshot images, and cloud runtime environment images; The factors to be verified include one or more of the following: vulnerability triggering conditions, PoC scripts, detection rules, security policies, patches, virtual patches, configuration changes, feature switches, and verification scripts. The minimum change set includes component version switching, configuration file modification, patch loading, security rule insertion, feature switch activation / deactivation, code snippet modification, and enabling or disabling vulnerability triggering conditions.

3. The security verification method according to claim 1, characterized in that, The state seeding data includes test accounts, business data, session tickets, token information, cached data, environment variables, traffic replay seeds, time offset parameters, and keys and certificates.

4. The security verification method according to claim 1, characterized in that, Based on the results of the difference analysis, the verification conclusions are output, including: When the differential analysis results indicate that the verification mirror triggers the target behavior while the baseline mirror does not, the factor to be verified is deemed valid. When both the verification mirror and the baseline mirror trigger the target behavior, environmental noise, rule false alarms, or baseline contamination are identified. When neither the verification mirror nor the baseline mirror triggers the target behavior, the verification object is deemed invalid or the sample is insufficient. When only the baseline mirror triggers the target behavior while the verification mirror does not, the patch or virtual patch is deemed valid.

5. The security verification method according to claim 1, characterized in that, The unified orchestration refers to the consistency of task parameters, execution order, time window, concurrency strategy, retry rules, and convergence conditions between the baseline image and the verification image; the verification tasks include vulnerability triggering tasks, PoC execution tasks, detection rule verification tasks, patch validity verification tasks, virtual patch verification tasks, and security policy verification tasks.

6. The security verification method according to claim 1, characterized in that, The operational evidence includes network request and response behavior, process tree changes, system call traces, file access behavior, log events, API call chains, memory changes, database access behavior, middleware state changes, and alarm events.

7. The security verification method according to claim 1, characterized in that, After each round of verification, the following is also included: Perform a snapshot rollback on the baseline image and the verification image, and reapply parameter perturbations to perform a re-verification; the parameter perturbations include changes in concurrency level, input load, latency, data path, session order, and traffic replay segments. If the results of multiple rounds of retesting are consistent, the confidence level of the final verification conclusion will be increased.

8. The security verification method according to claim 1, characterized in that, Also includes: Generate reusable verification templates based on the verification results; The verification template includes at least some of the information from the source mirror identifier, difference construction method, state seeding package, task orchestration rules, difference threshold, evidence collection strategy, and re-verification parameters.

9. An electronic device, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the security verification method as described in any one of claims 1 to 8.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the security verification method according to any one of claims 1 to 8.

Images