Application risk defense method and system

Abstract

Disclosed in the present disclosure are an application risk defense method and system. The method is applied to a defense engine and comprises: monitoring operation data generated by an application in the operation process; in a verification strategy set of a defense engine, calling a verification strategy matched with the operation data, wherein the verification strategy is used for representing rule information for verifying the operation data; performing at least one verification on the operation data according to the verification strategy to obtain at least one verification result; and performing defense processing on the application on the basis of the risk level determined on the basis of the at least one verification result, wherein the risk level is used for representing the risk degree brought by the operation data to the operation of the application.

Description

[0001] Cross-Reference to Application Risk Defense Method and System This disclosure claims priority to Chinese patent application number 202410051624.X, filed with the Patent Office of the People's Republic of China on January 12, 2024, entitled "Application Risk Defense Method and System," the entire contents of which are incorporated herein by reference. Technical Field This disclosure relates to the field of cloud computing, and more specifically, to a method and system for application risk defense. Background: Currently, application risk defense typically involves simple screening of runtime data, for example, by setting keywords to filter out illegal runtime data to prevent its distribution. However, this method lacks in-depth exploration and suffers from the technical problem of being unable to effectively defend against application risks. Currently, no effective solution has been proposed to address this issue. SUMMARY OF THE INVENTION Embodiments of the present disclosure provide an application risk defense method and system to at least address the technical problem of being unable to effectively defend against application risks. According to one aspect of an embodiment of the present disclosure, a method for defending against application risks is provided. This method, which can be applied to a defense engine, may include: monitoring operational data generated by an application during operation; invoking a verification policy from a verification policy set within the defense engine that matches the operational data, wherein the verification policy represents rule information for verifying the operational data; performing at least one verification on the operational data according to the verification policy to obtain at least one verification result; and performing defense processing on the application based on a risk level determined based on the at least one verification result, wherein the risk level represents the degree of risk posed by the operational data to the application. According to another aspect of an embodiment of the present disclosure, another application risk defense method is also provided. This method can be applied to a defense engine in a cloud-native scenario and may include: monitoring operational data reported by a cloud-native application platform, where the operational data is generated during the application's operation in the cloud-native scenario; invoking a verification policy from the defense engine's verification policy set that matches the operational data, where the verification policy represents rule information for verifying the operational data; performing at least one verification on the operational data according to the verification policy to obtain at least one verification result; performing defense processing on the application based on a risk level determined from the at least one verification result to obtain a defense result, where the risk level indicates the degree of risk posed by the operational data to the application's operation; and returning the defense result to the cloud-native application platform. According to another aspect of an embodiment of the present disclosure, another application risk defense method is provided.This method can be applied to a defense engine and may include: monitoring the operational data generated by an application during operation by calling a first interface, wherein the first interface includes a first parameter whose parameter value is the operational data; calling a verification policy from the defense engine's verification policy set that matches the operational data, wherein the verification policy represents rule information for verifying the operational data; verifying the operational data at least once according to the verification policy to obtain at least one verification result; performing defense processing on the application based on a risk level determined from the at least one verification result to obtain a defense result, wherein the risk level represents the degree of risk posed by the operational data to the application; and outputting the defense result by calling a second interface, wherein the second interface includes a second parameter whose parameter value is the defense result. According to another aspect of an embodiment of the present disclosure, a risk defense system for an application is also provided. The system may include: a platform device configured to respond to defense requests from applications, obtain operational data generated by the applications during operation, and report the operational data to a defense engine; a defense engine configured to invoke a verification policy from a verification policy set that matches the operational data, wherein the verification policy represents rule information for verifying the operational data; perform at least one verification on the operational data according to the verification policy, and obtain at least one verification result; and perform defense processing on the application based on a risk level determined based on the at least one verification result, wherein the risk level represents the degree of risk posed by the operational data to the application operation. According to another embodiment of the present disclosure, an electronic device is provided. The electronic device may include a memory and a processor: the memory is configured to store computer-executable instructions, and the processor is configured to execute the computer-executable instructions. When executed by the processor, the computer-executable instructions implement any of the aforementioned application risk defense methods. According to another embodiment of the present disclosure, a processor is configured to run a program, wherein any of the aforementioned application risk defense methods is executed when the program is running. According to another aspect of an embodiment of the present disclosure, a computer-readable storage medium is provided. The computer-readable storage medium includes a stored program, wherein when the program is running, the device where the storage medium is located is controlled to execute any of the above-mentioned application risk prevention methods.In the embodiments of the present disclosure, operational data generated during the operation of an application is monitored. A verification policy matching the operational data is invoked from a verification policy set within a defense engine. The verification policy represents the rules for verifying the operational data. The operational data is verified at least once according to the verification policy, resulting in at least one verification result. Based on the risk level determined from the at least one verification result, defense processing is performed on the application. The risk level represents the degree of risk posed by the operational data to the application. Specifically, in the embodiments of the present disclosure, the defense engine verifies the operational data of the application using the corresponding correction policy within the correction policy set. Based on the risk level determined from the verification result, defense processing is performed on the application based on the risk level. This improves operational efficiency, prevents unknown stability and security risks to the application, and achieves the technical effect of effectively defending against application risks, resolving the technical issue of ineffective application risk defense. It should be noted that the general description above and the detailed description that follow are merely examples and explanations of the present disclosure and do not constitute limitations of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS The drawings described herein are used to provide a further understanding of the present disclosure and constitute a part of the present disclosure. The illustrative embodiments of the present disclosure and their descriptions are used to explain the present disclosure and do not constitute an improper limitation on the present disclosure. In the accompanying drawings: Figure 1 is a schematic diagram of an application scenario of a risk defense method for an application according to an embodiment of the present disclosure; Figure 2 is a structural block diagram of a computing environment of a risk defense method for an application according to an embodiment of the present disclosure; Figure 3 is a flow chart of a risk defense method for an application according to an embodiment of the present disclosure; Figure 4 is a flow chart of a risk defense method for another application according to an embodiment of the present disclosure; Figure 5 is a flow chart of a risk defense method for another application according to an embodiment of the present disclosure; Figure 6 is a schematic diagram of a risk defense system for an application according to an embodiment of the present disclosure; Figure 7 is a schematic diagram of intelligent active defense according to an embodiment of the present disclosure; Figure 8 is a hardware structural block diagram of a computer terminal (or mobile device) for implementing the risk defense method for an application according to an embodiment of the present disclosure; Figure 9 is a structural block diagram of a service grid according to an embodiment of the present disclosure; Figure 10 is a schematic diagram of a risk defense device for an application according to an embodiment of the present disclosure; Figure 11 is a schematic diagram of a risk defense device for another application according to an embodiment of the present disclosure; Figure 12 is a schematic diagram of a risk defense device for another application according to an embodiment of the present disclosure; Figure 13 is a structural block diagram of a computer terminal according to an embodiment of the present disclosure; Figure 14 is a block diagram of an electronic device for the risk defense method for an application according to an embodiment of the present disclosure.DETAILED DESCRIPTION To help those skilled in the art better understand the present disclosure, the following will provide a clear and complete description of the technical solutions in the embodiments of the present disclosure, in conjunction with the accompanying drawings. It should be noted that the described embodiments represent only a portion of the embodiments of the present disclosure, and are not exhaustive. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of the present disclosure without inventive effort should fall within the scope of protection of the present disclosure. It should be noted that the terms "first," "second," and so on, in the specification and claims of the present disclosure, and in the accompanying drawings, are used to distinguish similar objects and are not necessarily used to describe a specific order or precedence. It should be understood that such terms are interchangeable where appropriate, so that the embodiments of the present disclosure described herein can be implemented in an order other than that illustrated or described herein. Furthermore, the terms "including," "having," and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or components is not necessarily limited to the steps or components expressly listed, but may include other steps or components not expressly listed or inherent to such process, method, product, or apparatus. First, some nouns or terms that appear in the description of the embodiments of the present disclosure are subject to the following explanations: Container orchestration (Kubernetes) refers to the process of automatically deploying, scaling, and operating application containers, and can be a platform for orchestrating and managing containers; Active defense refers to the process of timely discovering and responding to security threats in the field of network security through proactive technical means and strategies to prevent passive attacks and damage, which can include predicting and preventing risks, and real-time detection and response to threats; Risk prediction and blocking refers to the process of using technical means to predict possible security risks in the field of network security and taking corresponding blocking measures to prevent the risks from causing actual damage; Security Operations (SecOps) refers to the behavior of combining security operations with information technology operations to improve security through automation and collaboration; Artificial Intelligence for IT Operations (AIOps) refers to the application of artificial intelligence and machine learning to the fields of information technology operations and security, used to use automation and intelligent technologies to Improve the efficiency and accuracy of operation and maintenance and security. According to a method of an embodiment of the present disclosure, a risk prevention method for an application is provided.As an optional implementation, the aforementioned application risk prevention method may include, but is not limited to, application scenarios as shown in FIG1 . FIG1 is a schematic diagram of an application risk prevention method according to an embodiment of the present disclosure. As shown in FIG1 , in the application scenario, a terminal device 12 may, but is not limited to, communicate with a server 16 via a network 14. The server 16 may, but is not limited to, perform operations on a database 18, such as write or read data operations. The aforementioned terminal device 12 may, but is not limited to, include a human-computer interaction screen, a processor, and memory. The aforementioned human-computer interaction screen may, but is not limited to, be used to display information such as risk levels on the terminal device 12. The aforementioned processor may, but is not limited to, be used to respond to the aforementioned human-computer interaction operations, execute corresponding operations, or generate corresponding instructions and send the generated instructions to the server 16. The aforementioned memory is used to store relevant processing data, such as operational data, verification strategies, and risk levels. As an optional approach, the following steps in the application risk defense method can be performed on server 16: Step S102: Monitoring the operational data generated by the application during operation; Step S104: Invoking a verification policy from the defense engine's verification policy set that matches the operational data; Step S106: Verifying the operational data at least once according to the verification policy, obtaining at least one verification result; Step S108: Determining the risk level based on the at least one verification result and performing defense processing on the application. Using the above approach, operational data generated by the application during operation is monitored; Verification policies from the defense engine's verification policy set that match the operational data are invoked, where the verification policy represents the rule information for verifying the operational data; Verifying the operational data at least once according to the verification policy, obtaining at least one verification result; and Determining the risk level based on the at least one verification result and performing defense processing on the application. The risk level indicates the degree of risk posed by the operational data to the application. That is, in the embodiment of the present disclosure, for the defense engine, the operating data of the application is verified using the corresponding correction strategy in the correction strategy set, and the application is defensively processed based on the risk level determined based on the verification result, thereby improving operation and maintenance efficiency, preventing unknown stability and security risks of the application, and achieving the technical effect of effectively defending against risks in the application, solving the technical problem of being unable to effectively defend against risks in the application.The application scenario diagram shown in FIG1 can serve not only as an exemplary block diagram of a computer terminal (or mobile device), but also as an exemplary block diagram of the aforementioned server 16. In an alternative embodiment, FIG2 illustrates, as a block diagram, an embodiment using the server 16 shown in FIG1 as a computing node in a computing environment 201. FIG2 is a structural block diagram of a computing environment for a method for risk prevention of an application program according to an embodiment of the present disclosure. As shown in FIG2 , computing environment 201 includes multiple computing nodes (e.g., servers) (illustrated as 21-1 and 21-2 in the figure) running on a distributed network. Each computing node includes local processing and memory resources. End users 202 can remotely run applications or store data in computing environment 201. Applications can be provided as multiple services 220-1, 220-2, 220-3, and 220-4 in computing environment 201, representing services "A," "D," "E," and "H," respectively. End users 202 can provision and access services through a web browser or other software application on a client. In some embodiments, end users 202's offers and / or requests can be provided to ingress gateway 230. Ingress gateway 230 can include a corresponding agent to handle offers and / or requests for services (one or more services provided in computing environment 201). Services are provided or deployed based on various virtualization technologies supported by computing environment 201. In some embodiments, services can be provided using virtual machine (VM)-based virtualization, container-based virtualization, and / or similar approaches. VM-based virtualization can simulate a real computer by initializing a virtual machine, executing programs and applications without directly accessing any actual hardware resources. While VMs virtualize machines, container-based virtualization can launch containers to virtualize an entire operating system (OS), allowing multiple workloads to run on a single OS instance. In one embodiment based on container virtualization, several service containers can be assembled into a pod (e.g., a Kubernetes pod). For example, as shown in Figure 2, Pod 240-1, 240-2, 240-N (collectively referred to as Pod). A Pod may include an agent 245 and one or more containers.

[0002] 242-1, 242-2, and 242-M (collectively referred to as containers). One or more containers in a pod process requests related to one or more corresponding functions of a service. Proxy 245 typically controls network functions related to the service, such as routing and load balancing. During operation, executing a user request from end user 202 may require invoking one or more services in computing environment 201. Executing one or more functions of one service may require invoking one or more functions of another service. As shown in Figure 2, service "A" 220-1 receives a user request from end user 202 from ingress gateway 230. Service "A" 220-1 may invoke service "D" 220-2, and service "D" 220-2 may request service "E" 220-3 to execute one or more functions. The computing environment described above may be a cloud computing environment, where resource allocation is managed by the cloud service provider, allowing for feature development without having to consider implementing, adjusting, or scaling servers. This computing environment allows developers to execute code in response to events without building or maintaining complex infrastructure. Instead of expanding a single hardware device to handle potential load, services can be segmented to complete a set of functions that can be automatically and independently scaled. In the aforementioned operating environment, the present disclosure provides an application risk prevention method as shown in Figure 3. It should be noted that the application risk prevention method of this embodiment can be applied to a defense engine. The defense engine can be a component within a defense service that protects application security by executing specific defense policies and rules. It can be a defense engine in a cloud-native scenario. The defense service can be a user- or system-oriented security service that can include various security measures and defense mechanisms, such as a security firewall system, an intrusion detection system, and anti-virus software. Figure 3 is a flow chart of an application risk prevention method according to an embodiment of the present disclosure. As shown in Figure 3, the method may include the following steps: Step S302: Monitoring operational data generated by the application during operation. In the technical solution provided in step S302 of the present disclosure, operational data generated by the application during operation is monitored. The application can be an application in a cloud-native scenario, such as a containerized application or a microservices architecture. This is for illustrative purposes only and does not impose any specific limitations on the application type. Operational data may include traffic, data, actions, and the like. It may include rendered operational data and final executed operational data. It may be user data or rendered data, for example, configuration data. Optionally, this embodiment may monitor operational data generated during the operation of an application in a cloud-native scenario.Cloud-native scenarios can include deploying applications on cloud platforms and building and managing them using technologies such as containers and microservices. Examples include cloud-native application development, cloud-native data analysis, and cloud-native security monitoring. This is merely an example and does not limit the types of cloud-native scenarios. It should be noted that in addition to monitoring operational data in cloud-native scenarios, operational data in other scenarios can also be monitored. This does not impose specific limitations on the scenarios for acquiring operational data. Optionally, an agent can be added to the cloud-native application platform. oNew agents in cloud-native application platforms can be used to collect data, actions, traffic, and other information during application operation to generate operational data. An agent can be a program or software component that can run and execute tasks autonomously. It can be used to monitor application status, collect, and transmit operational data. It should be noted that the methods for monitoring operational data described here are merely illustrative and are not intended to be limiting. For example, suppose a company deploys its online shopping application on a cloud platform and uses container technology to manage application deployment and operation. In this cloud-native scenario, application operational data can be monitored, such as performance metrics, user access logs, error logs, response time, throughput, and so on. This collected operational data can be used to determine the application's performance during operation. For another example, an application sends a request to the cloud-native application platform to submit traffic, data, and actions to the cloud-native application platform. The cloud-native application platform performs multiple rounds of rendering on the user-submitted request, obtaining runtime data from one rendering round, two rendering rounds, and N rendering rounds. The defense engine can obtain the runtime data generated during the rendering process. In step S304, the defense engine calls a verification policy that matches the runtime data from its verification policy set. A verification policy represents rule information for verifying the runtime data. In the technical solution provided in step S304 of the present disclosure, after monitoring the application's runtime data, the defense engine calls a verification policy that matches the runtime data from its verification policy set. The verification policy set can be a pre-defined rule set that includes multiple verification policies. A verification policy can be a set of rule information or verification rules that describe the rules and logic for verifying operational data. For example, it can be a risky content determination policy, a rendering content setting policy, or a defense mode setting policy. This is merely an example and does not limit the types of verification policies. Optionally, after monitoring operational data, a verification policy can be selected. The operational data is further verified using the selected verification data. The verification policy matching the operational data can be invoked from the defense engine's verification policy set. Verification policies can help the defense engine promptly detect and prevent various unsafe behaviors, such as network attacks. For example, assume a network security firewall system (i.e., a defense service) has a verification policy set. The verification policy set can include multiple verification policies for detecting and preventing malicious behavior in network traffic.Among them, one verification policy set includes rules for Structured Query Language (SQL) injection attacks. This policy examines data packets in network traffic to identify whether they contain signs of SQL injection attacks. Another verification policy includes rules for cross-site scripting attacks, which examine data transmitted by web pages to identify whether they contain malicious scripts. When the network security firewall system monitors operational data, the defense engine in the defense service can invoke a matching verification policy from the verification policy set based on the characteristics of the actual operational data to perform an inspection. Step S306: The operational data is verified at least once according to the verification policy to obtain at least one verification result. In the technical solution provided in step S306 of the present disclosure, after the verification policy is retrieved, the operational data can be verified at least once according to the verification policy to obtain at least one verification result. The verification result can be the output obtained after verifying the operational data according to the verification policy, and can be used to indicate relevant information such as whether the verification passed, and can be used to determine the security of the operational data. The content of the verification result is not specifically limited herein. Optionally, a routine check is first performed on the operational data according to a verification policy, and then a secondary check is performed on the operational data that passes the routine check according to the verification policy, thereby achieving the technical problem of effectively defending against application risks. For example, assume that in a network security defense system, there is a verification policy for detecting malware in network traffic. When the network traffic in the operational data passes through the defense engine, the operational data can be verified according to the verification policy to obtain a verification result. The verification result may include: whether the verification passes, that is, whether the verification policy determines that the operational data contains malware, and / or the type of malware detected, the engine's processing measures, etc. Optionally, during the at least one verification of the operational data, the operational data can be verified once or multiple times using verification data of the same type as the operational data, or the operational data can be verified multiple times using different verification policies. This embodiment verifies the operational data using multiple verification methods, thereby achieving the purpose of improving the accuracy of the operational data verification. Step S308: Based on the risk level determined from the at least one verification result, defense processing is performed on the application. The risk level indicates the degree of risk posed by the operating data to the application. In the technical solution provided in step S308 of the present disclosure, after obtaining at least one verification result, the risk level can be determined based on the at least one verification result. The risk level can be used to identify the degree of risk posed by the operating data to the application.Defense processing is associated with defense levels. If only simple keywords are used to filter the delivery of illegal operational data (e.g., configuration data), it will be unable to adaptively monitor non-safe operational data that has not yet been entered into the platform, resulting in an inability to effectively defend against application risks. To address this issue, in this embodiment, after monitoring operational data, a verification policy matching the operational data is called from a verification policy set. The called verification policy is then used to perform at least one verification on the operational data, thereby obtaining at least one verification result. Based on the at least one verification result, a final risk level for the operational data is determined, and the operational data is processed using defense processing that matches the risk level. The verification policies in the verification policy set can be updated in real time based on actual usage, thereby avoiding the problem of ineffective application risk defense. Optionally, the risk level is determined based on the at least one verification result. The risk level can be used to indicate the degree of risk posed by the operational data to the application. Depending on the risk level, different defense measures can be taken for proactive risk defense to protect the application's security, thereby improving the stability and security of the application's functions. For example, suppose a network security defense system verifies incoming operational data, such as data traffic, at least once, obtaining at least one verification result. The system then determines a risk level based on this verification result. If the verification result for a piece of operational data indicates a low risk level, it may indicate that the operational data poses a low risk to the application. The defense engine can then take a more relaxed approach, such as logging or performing simple monitoring. On the other hand, if the verification result for a piece of operational data indicates a high risk level, it may indicate that the operational data poses a significant risk to the application. The defense engine may then immediately take stricter defensive measures, such as blocking data transmission or automatically isolating the affected application or system. Through steps S302 to S308 of the present disclosure, the operational data generated during the operation of the application in the cloud-native scenario is monitored; a verification policy matching the operational data is called from the verification policy set of the defense engine, where the verification policy is used to represent rule information for verifying the operational data; the operational data is verified at least once according to the verification policy to obtain at least one verification result; and defense processing is performed on the application based on a risk level determined based on the at least one verification result, where the risk level is used to represent the degree of risk posed by the operational data to the operation of the application.That is, in the disclosed embodiment, the defense engine verifies the application's operational data using the corresponding correction policy in the correction policy set. Based on the risk level determined by the verification results, defense processing is performed on the application. This improves operation and maintenance efficiency, prevents unknown stability and security risks in the application, and achieves the technical effect of effectively defending against application risks, resolving the technical problem of being unable to effectively defend against application risks. The above-mentioned method of this embodiment is further described below. As an optional implementation, step S308, defending the application based on the risk level determined by at least one verification result, includes: if the risk level is less than a first risk level threshold, inputting the operational data into a large model for secondary verification to obtain a secondary verification result; updating the risk level based on the secondary verification result; and performing defense processing on the application based on the updated risk level. In this embodiment, after determining the risk level based on the at least one verification result, a determination is made as to whether the risk level is less than a first risk level threshold. If the risk level is less than the first risk level threshold, the operational data is input into the large model for secondary verification to obtain a secondary verification result. The risk level can be updated based on the secondary verification results, and defense processing can be performed on the application based on the updated risk level. The first risk level threshold is a pre-set value. The big model can be a customized cloud-native application big model based on an existing big model. It can be a cloud-native big model, an operations and maintenance big model, a large-scale machine learning model, an artificial intelligence (AI) big model, etc. This is merely an example and does not impose any specific restrictions on the type of big model. Optionally, after retrieving the verification policy, a routine check is performed on the operating data according to the verification policy to obtain a verification result. Based on the verification result, a risk level is determined, and further determination is made as to whether the risk level is less than a first risk level threshold. If the risk level is less than the first risk level threshold, the operating data passes the routine check. To improve the accuracy of the security assessment of the operating data, the operating data can be input into the cloud-native big model for secondary verification to obtain a secondary verification result. The risk level obtained from the primary verification result can be updated based on the secondary verification result, and defense processing can be performed on the application based on the updated risk level. Optionally, the cloud-native big model can be used to perform secondary verification on the incoming operational data.The defense engine determines the risk level based on the preliminary verification results. If the risk level is less than the first risk level threshold, it performs a secondary verification using the cloud native big model within the defense engine. Based on the secondary verification results, the risk level is updated and defense measures are taken for the application according to the updated risk level. For example, assuming the first risk level threshold is level 3, a preliminary verification of the monitored operational data reveals a risk level of 2, which is less than the first risk level threshold of 3. The operational data can then be passed to the cloud native big model for secondary verification. The results indicate that the data presents a specific security threat, and the updated risk level is determined to be 5. Based on the updated risk level, the system will take appropriate defense measures, such as isolating the operational data or conducting a detailed review. In this embodiment, to improve the assessment of operational data security, secondary verification is performed using the cloud native big model, and the risk level is updated based on the secondary verification results. Appropriate defense measures are then taken based on the updated risk level, thereby achieving a more comprehensive assessment and treatment of operational data security risks, thereby protecting system security. As an optional implementation, when the risk level is less than a first risk level threshold, the operating data is input into the large model for secondary verification to obtain a secondary verification result. This includes: determining, in the large model, a sub-model that matches the performance indicator to be verified of the operating data, where the performance indicator to be verified represents the performance of the application under the operating data; and inputting the operating data into the sub-model to verify the performance indicator to be verified, thereby obtaining a secondary verification result. In this embodiment, after determining the risk level based on at least one verification result, a determination is made as to whether the risk level is less than the first risk level threshold. If the risk level is less than the first risk level threshold, a sub-model that matches the performance indicator to be verified of the operating data can be determined in the cloud-native large model, and the operating data can be input into the sub-model to verify the performance indicator to be verified of the operating data, thereby obtaining a secondary verification result. The sub-model can be a dynamic security model or a dynamic stability model. This is for illustrative purposes only and does not impose any specific limitation on the type of sub-model. The performance indicator to be verified can be data generated during the operation of the running data, which can be used to express the performance of the application under the running data and can be used to evaluate the running status and performance of the application. For example, it can be information such as memory usage, CPU usage, latency, network bandwidth, response time, etc. This is only an example, and there is no specific limitation on the type of performance indicator to be verified.In this embodiment, different sub-models are trained. When the cloud-native large model is used to perform secondary verification on the operational data, a sub-model that matches the performance indicators to be verified can be identified. The sub-model is then used to perform secondary verification on the verified performance indicators of the operational data, obtaining secondary verification results. Optionally, the monitored operational data is verified according to the verification strategy to obtain verification results, and a risk level is determined based on the verification results. When the risk level is below a first risk level threshold, a sub-model that matches the performance indicators to be verified is identified and the operational data is transferred to the sub-model. The sub-model then performs secondary verification on the operational data based on the performance indicators to be verified, obtaining secondary verification results. For example, suppose an online retail application is running on a container orchestration cluster and its performance needs to be monitored and verified. The application's operational data can be obtained during execution to determine performance indicators such as response time, memory usage, and CPU utilization. The sub-model that matches the performance metric to be verified can be determined to be a dynamic stability model. This dynamic stability model can be used to analyze whether the application's response time is within normal ranges, whether the system's memory and CPU usage are reasonable, and whether there are any abnormal performance fluctuations. The sub-model is then used to perform a secondary verification of the running data, generating a secondary verification result. Based on this secondary verification result, the application's performance can be further evaluated and appropriate defensive measures can be taken. For example, if the secondary verification result indicates normal application performance, the application can continue to run in the cluster. If an anomaly is detected, the system can automatically scale the application up or down, restart it, block it, or isolate it to ensure cluster stability and performance. In an optional implementation, the submodels include a first-type submodel that matches the safety performance indicator to be verified for the operating data, and a second-type submodel that matches the stability performance indicator to be verified for the operating data. The safety performance indicator is used to represent the safety performance of the application under the operating data, and the stability performance indicator is used to represent the stability performance of the application under the operating data. Inputting the operating data into the submodels to verify the performance indicator to be verified and obtain a secondary verification result includes: inputting the operating data into the first-type submodel to verify the safety performance indicator of the operating data to obtain a safety verification result; and / or inputting the operating data into the second-type submodel to verify the stability performance indicator of the operating data to obtain a stability verification result. In this embodiment, the submodels may include the first-type submodel that matches the safety performance indicator to be verified for the operating data, and the second-type submodel that matches the stability performance to be verified for the operating data.When performing secondary verification on the operating data, the performance indicator to be verified for the operating data is determined. If the performance indicator to be verified is the security performance of the application under the operating data, the sub-model matching the operating data can be determined to be a first-type sub-model. The operating data is input into the first-type sub-model, and secondary verification is performed on the security performance indicator of the operating data to obtain a security verification result. If the performance indicator to be verified represents the stability performance of the application under the operating data, the sub-model matching the operating data can be determined to be a second-type sub-model. The operating data can be input into the second-type sub-model, and secondary verification is performed on the stability performance indicator of the operating data to obtain a stability verification result. The first-type sub-model can be a dynamic security model, which can be used to verify the security performance under the operating data to determine the built-in security of the application. The second-type sub-model can be a dynamic stability model, which can be used to verify the stability performance of the application under the operating data. Optionally, if the verification is performed on performance indicators such as plaintext keys, insecure configurations, or known scenario vulnerabilities in the industry, the first-type sub-model can be used to perform secondary verification on the operating data. If performance metrics such as abnormal query per second (QPS) rates or unusual batch deletions are being verified, the second sub-model can be invoked to perform secondary verification on the operational data. For example, traditional operations and maintenance platforms do not perform security and compliance verification on user operational data (e.g., configuration data). If a user sets insecure content, such as displaying the storage of keys or high-risk configuration items, then once the configuration data is released, it could lead to key leaks at best and data leaks at worst, threatening enterprise security. To prevent these issues, when performing secondary verification on operational data, the first sub-model can be invoked to proactively identify risks in the configuration data from a security and compliance perspective, providing timely feedback to the user to prompt improvement. If the secondary verification results indicate a high-risk pre-check set by the security administrator, the release of the operational data can be effectively and quickly blocked, avoiding the need for post-event remediation. As an optional implementation, performing defense processing on an application based on an updated risk level includes: in response to the updated risk level being less than a second risk level threshold, feeding back the updated risk level to a terminal device corresponding to the application, wherein the updated risk level is used to cause the terminal device to adjust the application. In this embodiment, operating data is input into a sub-model verification to obtain a secondary verification result. Based on the secondary verification result, the risk level after the primary verification is updated, and a determination is made as to whether the updated risk level is less than the second risk level threshold.If the updated risk level is less than the second risk level threshold, the updated risk level can be fed back to the terminal device corresponding to the application. The terminal device adjusts the application based on the risk level. The terminal device can be the implementer. Optionally, after the defense engine performs a secondary verification of the operational data, the risk level obtained from the primary verification is updated to determine whether the updated risk level is less than the second risk level threshold. If the updated risk level is less than the second risk level threshold, indicating that the application now poses a low risk, only the updated risk level can be fed back to the terminal device corresponding to the application. The terminal device can adjust the application based on the updated risk level. Optionally, if the updated risk level is less than the second risk level threshold, it can be determined that the cloud native big model verification identified only a routine issue with the operational data, meaning that the issue does not impact production but is merely a security or stability risk. The updated risk level can then be fed back to the implementer corresponding to the application through the cloud native big model, notifying the implementer to address the issue. Risk levels can be fed back to the application's implementer in various ways, such as by sending them to the device via SMS or email, allowing them to make further assessments. For example, if the updated risk level of a social media application in a Kubernetes container increases from Level 1 to Level 2, but does not reach the Level 2 risk threshold, the risk level of the running data during the update process can be determined to be low. The updated risk level can then be fed back to the application's corresponding device. For example, the updated risk level can be fed back to all user devices associated with the social media application, alerting users to potential security risks. Based on the updated risk level, the implementer on the device can make necessary adjustments to the application on the device, such as adding security verification measures or restricting sensitive operations, to improve security. It should be noted that this is merely an example and does not impose specific restrictions on the methods for adjusting applications on the device. In this embodiment, when the cloud-native big model verifies operational data and identifies application security issues based on security specifications, it proactively and promptly reports these issues to the implementer and prompts them to make improvements, thereby effectively mitigating application risks and resolving the issue of ineffective application risk mitigation. As an optional implementation, operational data is adjusted based on the adjusted application and fed back to the platform device corresponding to the application.In this embodiment, after the terminal device adjusts the application, the defense engine can adjust the runtime data based on the adjusted application and feed the adjusted runtime data back to the platform device corresponding to the application. The platform device can be a cloud-native application platform or a platform running the application, such as a Kubernetes platform that orchestrates and manages containers. It should be noted that this is merely an example and does not limit the application platform device. Optionally, the runtime data can be secondary verified, and the risk level can be updated based on the secondary verification result. If the updated risk level is less than a second risk threshold, the updated risk level can be fed back to the device terminal corresponding to the application. The device terminal then modifies the application and feeds the modified runtime data back to the platform device corresponding to the application. The platform device can render the adjusted runtime data to execute the runtime data. For example, after the application is adjusted using the device terminal, the runtime data is adjusted based on the adjusted application and fed back to the platform device corresponding to the application. The platform device then performs multi-layer platform instance rendering to obtain final execution data, where the execution data includes the content or action ultimately executed. During online operation, an instance is configured based on the execution data. As an optional implementation, defensive processing is performed on the application based on the updated risk level, including: in response to the updated risk level being greater than or equal to a second risk level threshold, feeding the updated risk level back to the terminal device and / or platform device corresponding to the application, wherein the updated risk level is verified by the terminal device and / or platform device to obtain a verification result; and based on the verification result, defensive processing is performed on the application. In this embodiment, if the updated risk level is greater than or equal to the second risk level threshold, the updated risk level may be fed back to the device terminal and / or platform device corresponding to the application. The device terminal and / or platform device verifies the updated level to obtain a verification result. Based on the verification result, defensive processing may be performed on the application. The second risk level threshold may be a preset value. Optionally, if the updated risk level threshold is greater than or equal to the second risk level threshold, it may be determined that the operation data may cause a serious failure or pose a serious risk during operation. After determining that operational data presents a high-risk issue, the updated risk level can be fed back to the application's corresponding terminal device and / or platform device, proactively requesting secondary confirmation from platform operations and / or implementation personnel to obtain a verification result. Based on the verification result, defensive measures can be taken against the application.During application runtime, sensitive and risky configurations entered by users can lead to data leaks and other issues. However, common security and risk issues, such as those described above, cannot be promptly updated to the platform instance, impacting the stability and security of the application during runtime. To address this issue, when the defense engine detects a risk, the updated risk level can be fed back to the terminal device and / or platform device corresponding to the application. The terminal device and / or platform device can then perform a secondary confirmation of the runtime data, thereby achieving the goal of timely updating the risk issues to the platform instance, effectively implementing risk mitigation for the application and resolving the technical issue of ineffective application risk mitigation. For example, if the updated risk level exceeds the risk level threshold, it can be determined that the runtime data may cause serious failures during runtime, such as platform rendering deletion of content during configuration differentiation, abnormal batch deletion, or serious configuration format errors. At this point, the defense engine can temporarily change the process and provide the updated risk level to the terminal device and / or platform device corresponding to the application, proactively requesting secondary confirmation from the platform's operations and maintenance personnel and the implementation party. The defense engine obtains the verification results obtained after the secondary confirmation by the platform's operations and maintenance personnel and the implementation party, and based on the verification results, performs defense processing on the application. As an optional implementation, performing defense processing on the application based on the verification results includes: In response to the verification result indicating that the updated risk level is less than a second risk level threshold, outputting a notification message for the application and allowing access to the application, wherein the notification message indicates that the application is risky. In this embodiment, the terminal device and / or platform device verifies the updated risk level, obtains the verification result, and based on the verification result, determines whether the running data is risky. Specifically, if the verification result indicates that the updated risk level is less than the second risk level threshold, it can be determined that the running data is not risky and can continue to be executed or accessed. In this case, a notification message for the application can be output, and access to the running data can be allowed. The notification message may include text, logos, images, and other content, and may be used to indicate that an application presents a risk. This is merely an example and does not impose any specific limitation on the type of notification message. Optionally, after performing a secondary verification on the operating data, an updated risk level is obtained based on the secondary verification result. If the updated risk level is greater than or equal to a second risk level threshold, it can be determined that the operating data presents a risk if it is run.In this embodiment, to improve the accuracy of risk assessment, the updated risk level can be fed back to the terminal device and / or platform device corresponding to the application, allowing a secondary assessment. If the terminal device and / or platform device determines that the application is normal, the verification result can be determined to be less than the second risk level threshold. A notification message indicating that the application is at risk can be output, but operational data will not be blocked, and access to the application will be allowed. For example, the QPS of an application is generally stable or regular. If there is a sudden and significant increase in traffic, there are two possibilities: normal or indicating an attack on the application. If not promptly intervened in the case of a significant increase in traffic, it could lead to a complete system failure. To prevent a complete system failure caused by a significant increase in traffic, the defense engine's built-in dynamic flow control function can be leveraged, combined with a cloud-native big model for further verification. This can quickly detect such anomalies and proactively notify platform operations and maintenance personnel for further assessment. If this is normal, access can be allowed. As an optional implementation, in response to a verification result indicating that the updated risk level is less than a second risk level threshold, the performance indicator of the operating data is marked as a basic performance indicator. The basic performance indicator represents the basic performance of the application under the operating data. Based on the marked operating data and the application's defense results, the verification policy in the verification policy set is updated. The defense results at least indicate that access to the application is permitted. In this embodiment, if the verification result indicates that the updated risk level is less than the second risk level threshold, the performance indicator of the operating data may be marked as a basic performance indicator. Based on the marked operating data and the application's defense results, the verification policy in the verification policy set is updated. The basic performance indicator represents the basic performance of the application under the operating data and may be used for routine check notification type anomalies. The marked operating data and the application's defense results at least indicate that access to the application is permitted. Optionally, if the cloud-native big model performs a secondary verification on the operating data and determines the risk level corresponding to the second verification result, if the risk level after the secondary verification is greater than or equal to the second risk threshold, the device terminal and / or platform device may re-verify the corresponding operating data to obtain a verification result. If the verification result is that the updated risk level is less than the second risk level threshold, that is, the implementation personnel in the device terminal and / or the operation and maintenance personnel in the platform device believe that there is no security risk in the operating data at present.To prevent the cloud-native big model from misidentifying the same performance indicator in the future, performance indicators in the operational data can be marked as basic performance indicators. Based on the marked operational data and the application's defense results, the verification policies in the verification policy set can be updated. For example, after secondary confirmation by platform operations and maintenance personnel and the implementer as normal, these identified abnormal actions can be marked as routine check notification anomalies. These anomalies are automatically updated to the policy center, and the verification policy is updated. This type of action will notify the user of the risk but will not be blocked. When such an action is identified again, it will not be blocked, thereby improving the defense engine's accuracy in identifying anomalies. As an optional implementation, defense processing is performed on the application based on the verification results, including: blocking the application in response to the verification result indicating that the updated risk level is greater than or equal to a second risk level threshold. In this embodiment, if the verification result indicates that the updated risk level is greater than or equal to the second risk level, it indicates a secondary confirmation failure, and the action can be set as a blocking content to block the application. Optionally, if the cloud-native big model verifies the operational data and determines that the operational data contains an anomaly, it may be sent to the device terminal and / or platform device for further verification. If the device terminal and / or platform device also determines that the operation is abnormal, the application may be blocked to prevent its release, thereby effectively preventing application security and stability issues caused by abnormal user operations, content configuration errors, program attacks, platform vulnerabilities, and other issues. As an optional implementation, the method may further include: in response to the verification result indicating that the updated risk level is greater than or equal to a second risk level threshold, updating the verification policy in the verification policy set based on the operational data and the application's defense result, wherein the defense result is used to at least indicate that the application is blocked. In this embodiment, if the verification result indicates that the updated risk level is greater than or equal to the second risk level threshold, the verification policy in the verification policy set may be updated based on the operational data and the application's defense result. The defense result may at least indicate that the application is blocked. Optionally, if the verification result indicates that the updated risk level is greater than or equal to the second risk level threshold, the information can be automatically included in the policy center and set as blocked content, thereby implementing a dynamic security and stable defense mechanism to prevent the current release. In this embodiment, the verification policies in the verification policy set can be dynamically adjusted during use, continuously revised and proofread. By intelligently optimizing the verification policy set, the accuracy of defense can be improved and losses caused by misidentification can be reduced.As an optional implementation, the method may further include updating the big model based on the verification results. In this embodiment, the big model can be updated or revised based on the verification results. For example, the big model can be updated based on the risk level obtained from operations and maintenance processing to improve the accuracy of the big model in identifying anomalies. If policies are only configured for known issues, intelligent dynamic policy updates will not be possible, leading to technical issues such as operational security issues and poor stability. To address these issues, in this embodiment, the cloud-native big model and / or verification policy set can be updated based on the verification results. By adjusting the cloud-native big model and / or verification policy set, the accuracy of risk assessment of operational data can be improved, thereby achieving the technical effect of effectively defending against application risks and resolving the technical issue of ineffective application risk prevention. As an optional implementation, step S304, invoking a verification policy that matches the runtime data from the defense engine's verification policy set, includes: identifying the runtime data to obtain the application's original runtime data and revised runtime data; and invoking a verification policy that matches both the original runtime data and the revised runtime data from the defense engine's verification policy set. In this embodiment, the runtime data can be identified to obtain the application's original runtime data and revised runtime data. Invoking a verification policy that matches both the original runtime data and the revised runtime data from the defense engine's verification policy set. The original runtime data can be the original content of the runtime data, initial data generated during the application's operation, including user input, system responses, sensor data, and other basic data for the application's operation. The revised runtime data can be revised content of the runtime data, data that has been modified, updated, or revised from the original runtime data. For example, it can be new data generated through application processing or manipulation, or user operation. It should be noted that this is merely an example and does not impose any specific limitation on the types of original and revised runtime data. Optionally, the defense engine can identify the content of the operational data and determine the application's original operational data and revised operational data. When verifying the operational data, a verification policy matching the original operational data can be invoked to verify the original data, while a verification policy matching the revised operational data can also be invoked to verify the revised data. For example, suppose a banking application generates transaction data during operation, including both original and revised operational data.The bank's defense engine identifies and analyzes this data, then invokes the corresponding verification policy based on the verification policy set to verify the original and revised operational data. In this embodiment, the operational data consists of multiple types of data, and different verification policies are invoked for each type of data, thereby improving the accuracy of the verification results and resolving the technical issue of low verification accuracy. As an optional implementation, invoking verification policies that match both the original and revised operational data from the defense engine's verification policy set includes: invoking at least one first verification policy that matches the original operational data and at least one second verification policy that matches the revised operational data from the defense engine's verification policy set, wherein the first verification policy represents rule information for verifying the original operational data, and the second verification policy represents rule information for verifying the revised operational data; and determining the first and second verification policies as verification policies. In this embodiment, the operational data generated by an application during operation is monitored. From the defense engine's verification policy set, at least one first verification policy matching the original operational data and at least one second verification policy matching the revised operational data can be invoked. These at least one first verification policy and at least one second verification policy can be determined as verification policies. The operational data can be verified according to the verification policies to obtain verification results. The first verification policy can represent the rules for verifying the original operational data, while the second verification policy can represent the rules for verifying the revised operational data. However, simply setting simple keywords in the operation and maintenance platform to filter illegal configurations can lead to an ineffective risk mitigation for the application. To address this technical issue, in this embodiment, at least one first verification policy matching the original operational data and at least one second verification policy matching the revised operational data are invoked. The operational data is verified according to the policies, and the verification results are used to automatically identify potential application risks. Based on these risks, proactive risk mitigation is then performed for the application. This resolves the technical issue of ineffective application risk mitigation and achieves the technical effect of effectively mitigating application risks. As an optional implementation, step S306, performing at least one verification on the operating data according to the verification strategy to obtain at least one verification result, includes: determining at least one basic performance indicator of the operating data based on the verification strategy, wherein the at least one basic performance indicator corresponds to the verification strategy and is used to represent the basic performance of the application under the operating data; and verifying the basic performance indicator according to the verification strategy to obtain a verification result.In this embodiment, after monitoring the operational data, a verification strategy matching the operational data can be retrieved. Based on the verification strategy, at least one basic performance indicator of the operational data can be determined. The basic performance indicator is verified according to the verification strategy, thereby obtaining a primary verification result. The at least one basic performance indicator corresponds to the verification strategy and can be used to represent the basic performance of the application under the operational data. For example, it can be data read speed, data write speed, data processing speed, abnormal batch deletion actions, etc. It should be noted that this is merely an example and does not impose any specific limitation on the type of the at least one basic performance indicator. Optionally, based on the verification strategy, a routine check can be performed on the at least one basic performance indicator of the operational data to obtain a primary verification result. If the primary verification result indicates that the at least one performance indicator of the operational data passes the routine check, the operational data can be transmitted to the cloud-native big model for further verification, thereby achieving the technical effect of improving the accuracy of risk prevention for the application and resolving the technical problem of low accuracy in risk prevention for the application. As an optional implementation, the method further includes: if the risk level is greater than or equal to a first risk level threshold, sending a blocking request to the platform device corresponding to the application, wherein the blocking request is used to request the platform device to block the application. In this embodiment, a routine check is performed on at least one basic performance indicator of the operating data based on a verification policy to obtain a primary verification result. The risk level is determined based on the primary verification result. If the determined risk level is greater than or equal to the first risk level threshold, it can be determined that executing the operating data will pose a risk, and a blocking request can be sent to the platform device corresponding to the application to block the application. Optionally, if the routine check passes, the operating data enters the cloud native big model for further verification. If the routine check fails, a request can be directly sent to the corresponding platform device to request the platform device to block the application. Manual verification of operational data can lead to missed detections and failure to detect unusual issues in operational data. To address these issues, this embodiment uses defense policies to verify operational data. Furthermore, a cloud-native big model performs a secondary verification on operational data that passes routine checks. This resolves the technical issue of being unable to effectively defend against application risks and achieves the technical effect of effectively defending against application risks.In this embodiment, the defense engine verifies the application's operational data using the corresponding correction policy in the correction policy set. Based on the risk level determined by the verification results, the application is then defense-processed. This improves operation and maintenance efficiency and prevents unknown stability and security risks in the application, achieving the technical effect of effectively defending against application risks and resolving the technical problem of ineffective application risk defense. This embodiment of the present disclosure also provides another application risk defense method, which can be applied to a defense engine in a cloud-native scenario. Figure 4 is a flowchart of another application risk defense method according to an embodiment of the present disclosure. As shown in Figure 4, this embodiment may include the following steps: Step S402: Monitoring operational data reported by a cloud-native application platform. This operational data is generated during the application's operation in a cloud-native scenario. In the technical solution provided in step S402 of the present disclosure, the cloud-native application platform (hereinafter referred to as the platform) collects requests sent by device terminals and renders the requests layer by layer to obtain operational data of the application during its operation. The cloud-native application platform can upload this operational data to the defense engine by adding a new agent. The defense engine can monitor operational data reported by the cloud-native application platform. Optionally, a device terminal submits operational data to the cloud-native application platform via a request, which then performs layered rendering on the data. A newly added agent in the cloud-native application platform can collect operational data during the rendering process and submit it to the defense engine. The agent can be used for content reporting, checkpoint blocking, and risk prevention. Optionally, the unrendered data can be raw operational data, while the rendered data can be revised operational data. For example, a user can send a request to the platform to submit operational data such as traffic, data, and actions. The platform then performs multiple rounds of rendering on the content or actions, generating data for the first, second, and Nth rounds of rendering. The newly added agent can collect data from each rendering round and upload it to the defense engine. Note that this is merely an example and does not impose any specific restrictions on the operational data collection method. In step S404, the defense engine's verification policy set is used to call a verification policy that matches the running data. A verification policy represents information about rules for verifying the running data. In the technical solution provided in step S404 of the present disclosure, upon monitoring the running data generated by an application running in a cloud-native scenario, the defense engine's verification policy set is used to call a verification policy that matches the running data.The verification policy set may be a pre-defined rule set, including multiple verification policies. A verification policy may be a set of rule information or verification rules that describe the rules and logic for verifying runtime data. For example, it may be a risky content determination policy, a rendering content setting policy, or a defense mode setting policy. This is merely an example and does not impose any specific restrictions on the types of verification policies. Step S406: Verify the runtime data at least once according to the verification policy to obtain at least one verification result. In this embodiment, the runtime data may be verified at least once according to the verification policy to obtain at least one verification result. The verification result may be the output obtained after verifying the runtime data according to the verification policy. It may be used to indicate relevant information such as whether the verification passed and to determine the security of the runtime data. The content of the verification result is not specifically limited here. Step S408: Based on the risk level determined by the at least one verification result, defense processing is performed on the application to obtain a defense result. The risk level indicates the degree of risk posed by the runtime data to the application. Step S410: Return the defense result to the cloud-native application platform. In the technical solution provided in step S410 of the present disclosure, based on the risk level determined by at least one verification result, defense processing is performed on the application, obtaining a defense result, which can be returned to the cloud-native application platform. Through steps S402 to S410 of the present disclosure, operational data on the cloud-native application platform is monitored, where the operational data is generated during the application's operation in a cloud-native scenario. A verification policy matching the operational data is invoked from the defense engine's verification policy set, where the verification policy represents rule information for verifying the operational data. The operational data is verified at least once according to the verification policy, obtaining at least one verification result. Based on the risk level determined by the at least one verification result, defense processing is performed on the application, obtaining a defense result, where the risk level represents the degree of risk posed by the operational data to the application. The defense result is returned to the cloud-native application platform, thereby achieving the technical effect of effectively defending against application risks and resolving the technical problem of ineffective application risk defense. According to embodiments of the present disclosure, another application risk defense method is also provided, which can be applied to defense engines in cloud-native scenarios. FIG5 is a flowchart of another application risk prevention method according to an embodiment of the present disclosure. As shown in FIG5 , this embodiment may include the following steps: Step S502: Monitoring operation data generated by the application during operation by calling a first interface, wherein the first interface includes a first parameter whose parameter value is the operation data.In the technical solution provided in step S502 above, operating data can be obtained by calling a first interface. The first interface may include a first parameter, whose value may be operating data. The operating data may be generated during the operation of an application in a cloud-native scenario. For example, a terminal device (i.e., a user's device) may pass the operating data as the value of the first parameter through the Application Programming Interface (API) of a Software as a Service (SAAS) service provider to verify the security of the operating data. The SAAS service provider's system receives and processes the operating data. The first interface may be an API endpoint provided by a SAAS platform. Users can call this interface to send operating data, and the first parameter is used to transmit the operating data. In this way, users can utilize the functions provided by the SAAS platform to perform customized information query and processing. The SAAS platform may be a platform that has deployed anti-uninstallation services. This is merely an example and does not impose any specific limitation on the type of SAAS platform. In step S504, the verification strategy matching the operational data is invoked from the defense engine's verification strategy set. The verification strategy represents the rule information for verifying the operational data. In step S506, the operational data is verified at least once according to the verification strategy, obtaining at least one verification result. In step S508, based on the risk level determined from the at least one verification result, defense processing is performed on the application to obtain a defense result. The risk level represents the degree of risk posed by the operational data to the application. In step S510, the defense result is output by invoking a second interface. The second interface includes a second parameter, the parameter value of which is the defense result. In the technical solution provided in step S510 of the present disclosure, the defense result can be output by invoking the second interface. The second interface may include the second parameter, the parameter value of which may be a predicted result. Optionally, the defense result can be output to the cloud-native application platform by invoking the second interface. For example, the defense result can be transmitted as the parameter value of the second parameter via an application programming interface, thereby providing the defense result of the operational data to the terminal device. The SAAS service provider's system transmits the processed defense results to the terminal device and / or platform device via an interface. The second interface may be an API endpoint provided by the SAAS platform. This interface may be called to send a second parameter, which is used to transmit the defense results.In an embodiment of the present disclosure, a first interface is called to monitor the operational data generated by an application during operation. The first interface includes a first parameter whose parameter value is the operational data. A verification policy matching the operational data is called from a verification policy set of a defense engine. The verification policy represents rule information for verifying the operational data. The operational data is verified at least once according to the verification policy to obtain at least one verification result. Based on the risk level determined by the at least one verification result, defense processing is performed on the application to obtain a defense result. The risk level indicates the degree of risk posed by the operational data to the application. The defense result is output by calling a second interface. The second interface includes a second parameter whose parameter value is the defense result. This achieves the technical effect of effectively defending against application risks and solves the technical problem of being unable to effectively defend against application risks. According to an embodiment of the present disclosure, an embodiment of an application risk defense system is also provided. Figure 6 is a schematic diagram of an application risk defense system according to an embodiment of the present disclosure. As shown in Figure 6, application risk defense system 600 may include a platform device 602 and a defense engine 604. Platform device 602 is configured to respond to defense requests from applications, obtain operational data generated during the application's operation, and report the operational data to the defense engine. In this embodiment, platform device 602 can receive defense requests from applications. In response to these defense requests, platform device 602 can obtain operational data generated during the application's operation in a cloud-native scenario and report the operational data to the defense engine. The platform device may be a cloud-native application platform. Optionally, platform device 602 can obtain operational data generated during the application's operation through a proxy and transmit the acquired operational data to defense engine 604. Defense engine 604 is configured to invoke a verification policy from a verification policy set that matches the operational data. A verification policy represents rule information for verifying the operational data. The verification policy performs at least one verification on the operational data according to the verification policy, obtaining at least one verification result. Defense processing is then performed on the application based on a risk level determined based on the at least one verification result. The risk level represents the degree of risk posed by the operational data to the application's operation. In this embodiment, the defense engine 604 obtains the operating data and invokes a verification strategy from a verification strategy set that matches the operating data. The operating data may be verified at least once according to the verification strategy, thereby obtaining at least one verification result.A risk level is determined based on at least one verification result, and defense processing is performed on the application based on the risk level. The risk level can be used to indicate the degree of risk posed by the running data to the application's operation. Optionally, the defense engine 604 performs defense processing on the application, obtains a defense result, and returns the defense result to the cloud-native application platform. In this embodiment, the platform device responds to the application's defense request, obtains the running data generated by the application during operation, and reports the running data to the defense engine. The defense engine then invokes a verification policy from a verification policy set that matches the running data. The verification policy represents the rule information for verifying the running data. The running data is verified at least once according to the verification policy, obtaining at least one verification result. Defense processing is then performed on the application based on the risk level determined from the at least one verification result. The risk level indicates the degree of risk posed by the running data to the application's operation. This effectively achieves the technical effect of risk prevention for the application and resolves the technical problem of ineffective application risk prevention. Currently, when releasing and operating applications on cloud-native application platforms, user operational data is manipulated through layers of rendering, potentially being modified intentionally or unintentionally. This can lead to application failures or traffic disruptions, posing significant security risks. Furthermore, some users may introduce sensitive and risky configurations that go undetected, potentially leading to data leaks and other issues. Furthermore, common security and risk issues are not updated to the platform in a timely manner, leading to stability and security issues. Related technologies typically filter out the delivery of illegal operational data by setting simple keywords. However, this approach cannot adaptively monitor non-secure operational data that has not yet been entered into the platform, resulting in an ineffective defense against application risks. Furthermore, this approach ignores the possibility of user data being modified due to inherent program vulnerabilities (bugs). It also fails to effectively monitor operational data tampering caused by changes to platform or component rules, leading to various security and stability issues. As can be seen from the above, the relevant technologies are unable to effectively monitor the behavior of users, platform developers, and developers of various underlying components, resulting in technical problems such as poor stability and security of applications due to problems of users and developers themselves.To address the aforementioned issues, this embodiment proposes an intelligent active defense method for cloud-native application operation and maintenance scenarios. This embodiment combines a large AI model with deep content and action verification. This allows the AI ​​model to predict high-risk issues in operational data and unconventional issues discovered by the defense engine. The defense results are then used to perform secondary model verification and verification policy verification on the cloud-native model, thereby dynamically updating the model and blocking risks. Optionally, the intelligent active defense method can be integrated into different systems based on actual needs to monitor and defend against application risks. The following further describes the intelligent active defense method for cloud-native application operation and maintenance scenarios. As an optional embodiment, operational data is collected. In this embodiment, a user submits a request to submit operational data such as traffic, data, and actions to the cloud-native application platform (hereinafter referred to as the platform). The data is rendered layer by layer through multiple layers of platform instances within the platform to obtain execution content or actions. A newly added agent collects the content or actions after each rendering round and submits the collected content or actions to the defense service. For example, Figure 7 is a schematic diagram of an intelligent active defense system according to an embodiment of the present disclosure. As shown in Figure 7, a user sends a request to a cloud-native application platform 71 to submit operational data 701, such as traffic, data, and actions, to the cloud-native application platform 71. The cloud-native application platform 71 then performs multiple rounds of rendering on the operational data 701, obtaining operational data 702 from a first rendering round, operational data 703 from a second rendering round, and operational data 70N from an Nth rendering round, ultimately yielding executed operational data 704. The rendered operational data can be rendered content or actions, while the executed operational data can be executed content or actions. In this embodiment, a newly added agent can collect the content or actions after each rendering round and submit the collected content or actions to the defense service 72. The rendered content or actions can also be referred to as data or actions. Optionally, operation data 702 is collected by agent 708 and transmitted to defense service 72; operation data 703 is collected by agent 709 and transmitted to defense service 72; operation data 70N is collected by agent 710 and transmitted to defense service 72; and operation data 704 is collected by agent 711 and transmitted to defense service 72. As an optional embodiment, the collected data and actions are verified. In this embodiment, key data in the operation data is identified to determine the original content and revised content of the operation data.At the same time, a policy is selected from the verification policy set 74 of the defense engine 73, and a verification policy that matches the original and revised content can be invoked. The runtime data is then verified according to the verification policy, obtaining at least one verification result. Verification policy set 74 may include policies for determining risky content, rendering content setting policies, and defense model setting policies. This is for illustrative purposes only and is not intended to be limiting. The obtained runtime data is verified using the verification policies in the defense service 72. These verification policies may include a risky content determination policy 705, a rendering content setting policy 706, and a defense model setting policy 707. It should be noted that this is for illustrative purposes only and does not impose any specific limitations on the types of verification policies. Verification of the runtime data may include routine checks of the runtime data. Optionally, the original and revised content in the obtained user data is verified using the selected verification policy. Optionally, the collected operational data is extracted for routine checks. If the routine checks pass, the data is further verified in the cloud native big model 75. If the routine checks fail, a request is directly sent to the corresponding platform instance to block changes. The cloud native big model can be built based on an existing big model. Change blocking can include security risk blocking, configuration differentiation risk blocking, abnormal traffic prevention, and high-risk action blocking. This is merely an example and does not limit the content of change blocking. For example, when a user sends operational data, since the underlying cloud native scenario uses a self-descriptive format (YAM description), it is generally provided to users in this format. Simultaneously, the platform instance will also add some content to facilitate further filtering, analysis, and management within the Kubernetes system. If the operational data entered by the user is tampered with by a bug in the platform or other components, it will cause serious failures in the application during operation. In this case, the above method can dynamically verify the application's operational data during operation. If the selected verification strategy determines that deletion issues are high risk, a request can be directly sent to the corresponding platform to block the modified operational data. This allows for control over published operational data and improves risk prevention for the application. As an optional embodiment, a cloud-native big model can be used to further verify the collected operational data.In this embodiment, if the routine check of the operational data passes, the cloud-native big model can be used to further verify the collected operational data for built-in security issues and other risk content 714. For example, the collected operational data can be further verified for plaintext keys, insecure configurations, and known scenario vulnerabilities. Alternatively, traffic flow can be further verified, for example, for risk content 715 such as abnormally high query rates per second and abnormal batch deletions. Optionally, if the cloud-native big model verifies that the operational data is a routine issue, meaning that the issue does not impact production but is merely a security or stability risk, the cloud-native big model can output the verification results and notify the implementer to address the issue. If the cloud-native big model identifies an issue that could cause serious runtime failures, such as platform rendering deletion of content during configuration differentiation, abnormal batch deletions, or serious configuration format errors, the change process can be suspended and a second confirmation request can be made from the platform's operations and maintenance personnel and the implementer. Optionally, as shown in Figure 7, the defense engine can notify platform operations personnel and implementers via email, SMS, or other means for secondary confirmation and processing. Optionally, the cloud-native big model 75 can include a dynamic security model 712 and a dynamic stability model 713. Models matching the performance indicators to be verified for the operational data can be determined within the native big model to improve the accuracy and efficiency of judging the operational data. For example, traditional operations platforms do not perform security and compliance verification on user operational data. If a user account sets some non-secure content, such as indicating the storage of keys or some high-risk configuration items, once the configuration data is distributed, it could lead to key leakage at best and data leakage at worst, threatening enterprise security. To avoid these issues, based on preliminary verification of operational data using verification strategies, further verification of the configuration data can be performed using a customized cloud-native application big model based on the existing big model. This proactively identifies risks in operational data from a security and compliance perspective and provides timely feedback to users to prompt improvements. If the verification results indicate a high-risk pre-check set by the security administrator, the release will be quickly and effectively blocked upon discovery, avoiding remediation efforts. For example, a typical application's QPS is relatively stable or regular. If there is a sudden surge in traffic, there are two possible scenarios: normal or an attack. If timely intervention is not taken in the case of a significant traffic surge, it could lead to a complete failure of the entire application.To prevent a significant increase in traffic from causing complete application failures, the dynamic flow control capabilities built into the defense engine 73 can be leveraged, combined with the cloud native big model 75, to further verify operational data. This allows for rapid detection of these anomalies and proactively notifies operations personnel for further assessment. If these anomalies are normal, access is allowed, and the cloud native big model will then correct the operational data. If these anomalies are flagged, proactive defenses will be implemented to mitigate losses. As an optional embodiment, secondary confirmation model optimization and intelligent optimization strategies are implemented. In this embodiment, actions that have been secondary confirmed as normal by the platform's operations personnel and / or implementers will be marked as routine inspection notification anomalies and automatically updated to the policy center for verification policy updates. This data will notify users of the risk but will not be blocked. However, actions that fail secondary confirmation by the platform's operations personnel and / or implementers will be automatically included in the policy center and blocked, implementing dynamic security and stability defenses and preventing the release. The finalized content can be used to revise the large model, thereby improving the accuracy of the model's next risk mitigation. This approach effectively prevents security and stability issues caused by abnormal user operations, content configuration errors, attacks, platform vulnerabilities, and the like. This embodiment addresses security issues related to platform introduction, normal burst traffic, and manual introduction by effectively identifying application risks through a deep big data model and action verification mechanism. By integrating a self-developed cloud-native large model, routine operation and maintenance content and actions can be effectively identified. Furthermore, based on a secondary confirmation model and dynamic policy update mechanism, operation and maintenance efficiency is effectively improved, and unknown stability and security risks are prevented. This achieves the technical effect of enabling effective process prediction, resolving the technical issue of ineffective process prediction. The method embodiments provided in this disclosure can be executed on mobile terminals, computer terminals, or similar computing devices. FIG8 is a block diagram of the hardware structure of a computer terminal (or mobile device) for implementing a method for risk prevention of an application program according to an embodiment of the present disclosure. As shown in FIG8 , a computer terminal 80 (or mobile device) may include one or more processors (illustrated in the figure as 802 a, 802 b, ..., 802 n). A processor 802 may include, but is not limited to, a processing device such as a microprocessor (MCU) or a programmable logic device (FPGA), a memory 804 for storing data, and a transmission device 806 for communication functions.In addition, the electronic device may also include: a display, an input / output interface (I / O interface), a Universal Serial Bus (USB) port (which may be included as one of the ports of a BUS), a network interface, a power supply, and / or a camera. Those skilled in the art will appreciate that the structure shown in FIG8 is merely illustrative and does not limit the structure of the electronic device. For example, the computer terminal 80 may include more or fewer components than shown in FIG8 , or have a configuration different from that shown in FIG8 . The hardware structure block diagram shown in FIG8 can serve not only as an exemplary block diagram of the computer terminal 80 (or mobile device) described above, but also as an exemplary block diagram of the server described above. In an alternative embodiment, FIG2 shows a block diagram of an embodiment using the computer terminal 80 (or mobile device) shown in FIG8 as a computing node in the computing environment 201. Memory 804 can be used to store software programs and components of application software, such as the program instructions / data storage device corresponding to the application risk prevention method in the embodiments of the present disclosure. The processor executes the software programs and components stored in memory 804 to execute various functional applications and data processing, thereby implementing the aforementioned application risk prevention method. Memory 804 may include high-speed random access memory (RAM) and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, memory 804 may further include memory remote from the processor, which can be connected to computer terminal 80 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. Transmission device 806 is used to receive or transmit data via a network. Specific examples of such networks may include wireless networks provided by the communications provider of computer terminal 80. In one example, transmission device 806 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In one example, the transmission device 806 may be a radio frequency (RF) component for wirelessly communicating with the Internet. The display may be, for example, a touch-screen liquid crystal display (LCD), which enables a user to interact with a user interface of the computer terminal 80 (or mobile device).In another alternative embodiment, FIG9 shows a block diagram of an embodiment using the computer terminal 80 (or mobile device) shown in FIG8 as a service grid. FIG9 is a structural block diagram of a service grid according to an embodiment of the present disclosure. As shown in FIG9 , the service grid 900 is primarily used to facilitate secure and reliable communication between multiple microservices. Microservices refer to the decomposition of an application into multiple smaller services or instances, which are distributed and run on different clusters / machines. As shown in FIG9 , microservices may include application service instance A and application service instance B, which form the functional application layer of service grid 900. In one embodiment, application service instance A runs as a container / process 908 on a machine / workload container group 914 (POD), and application service instance B runs as a container / process 910 on a machine / workload container group 916 (POD). In one embodiment, application service instance A may be a data copy service, and application service instance B may be a data transfer service. As shown in Figure 9, application service instance A and grid proxy (sidecar) 903 coexist in machine workload container group 914, while application service instance B and grid proxy 905 coexist in machine workload container 914. Grid proxy 903 and grid proxy 905 form the data plane layer of service grid 900. Grid proxy 903 and grid proxy 905 run as container / process 904, which can receive requests 912 for product query services, and grid proxy 906, respectively. Grid proxy 903 and application service instance A can communicate bidirectionally, while grid proxy 905 and application service instance B can communicate bidirectionally. Furthermore, grid proxy 903 and grid proxy 905 can also communicate bidirectionally with each other. In one embodiment, all traffic for application service instance A is routed to the appropriate destination through grid proxy 903, and all network traffic for application service instance B is routed to the appropriate destination through grid proxy 905.It should be noted that the network traffic mentioned herein includes, but is not limited to, Hypertext Transfer Protocol (HTTP), Representational State Transfer (REST), the high-performance, general-purpose open source framework (Google Remote Procedure Call (gRPC)), and the open source in-memory data structure storage system (Redis). In one embodiment, the functionality of the extended data plane layer can be implemented by writing custom filters for the proxy (Envoy) in service grid 900. Service grid proxy configuration can be used to enable the service grid to correctly proxy service traffic, thereby achieving service interoperability and service governance. Grid proxy 903 and grid proxy 905 can be configured to perform at least one of the following functions: service discovery, health checking, routing, load balancing, authentication and authorization, and observability. oAs shown in FIG9 , service grid 900 also includes a control plane layer. The control plane layer can be comprised of a set of services running in a dedicated namespace, hosted by a managed control plane component 901 within a machine / workload container group (machine / pod) 902. As shown in FIG9 , managed control plane component 901 communicates bidirectionally with grid agent 903 and grid agent 905. Managed control plane component 901 is configured to perform certain control and management functions. For example, managed control plane component 901 receives telemetry data transmitted by grid agent 903 and grid agent 905 and can further aggregate this telemetry data. For these services, managed control plane component 901 can also provide user-oriented application programming interfaces (APIs) to facilitate manipulation of network behavior and provide configuration data to grid agent 903 and grid agent 905. It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, storage, and display, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties. The collection, use, and processing of the relevant data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or reject. It should be noted that for the sake of simplicity, the aforementioned method embodiments are described as a series of actions. However, those skilled in the art should understand that this disclosure is not limited by the order of the actions described, as certain steps can be performed in a different order or simultaneously according to this disclosure. Secondly, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and components involved are not necessarily required by this disclosure. Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented using software and a necessary general-purpose hardware platform, or of course, hardware. Based on this understanding, the technical solution of the present disclosure, or the portion that contributes to the prior art, can essentially be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, a magnetic disk, or an optical disk) and includes a number of instructions for enabling a terminal device (which can be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods of various embodiments of the present disclosure.According to an embodiment of the present disclosure, an application risk defense device for implementing the application risk defense method shown in FIG. 3 is also provided. This device can be used in a defense engine. FIG. 10 is a schematic diagram of an application risk defense device according to an embodiment of the present disclosure. As shown in FIG. 10 , the application risk defense device 1000 may include a first monitoring component 1002, a first calling component 1004, a first verification component 1006, and a first processing component 1008. The first monitoring component 1002 is configured to monitor the operational data generated by the application during operation. The first calling component 1004 is configured to call a verification policy from the defense engine's verification policy set that matches the operational data. The verification policy represents rule information for verifying the operational data. The first verification component 1006 is configured to verify the operational data at least once according to the verification policy and obtain at least one verification result. The first processing component 1008 is configured to perform defense processing on the application based on a risk level determined based on the at least one verification result. The risk level represents the degree of risk posed by the operational data to the application. Here, the first monitoring component 1002, first calling component 1004, first verification component 1006, and first processing component 1008 correspond to steps S302 to S308 in FIG. The examples and application scenarios implemented by these four components and the corresponding steps are the same, but are not limited to the content disclosed above. It should be noted that the above-mentioned components can be hardware components or software components stored in a memory (e.g., memory 804) and processed by one or more processors (e.g., processors 802a, 802b, ..., 802n). The above-mentioned components can also be part of an apparatus and run on the provided computer terminal 80. According to an embodiment of the present disclosure, an application risk defense device for implementing the application risk defense method shown in FIG. 4 is also provided. This device can be applied to a defense engine in a cloud-native scenario. FIG11 is a schematic diagram of another application risk prevention device according to an embodiment of the present disclosure. As shown in FIG11 , the application risk prevention device 1100 may include a second monitoring component 1102, a second calling component 1104, a second verification component 1106, a second processing component 1108, and a return component 1110. The second monitoring component 1102 is configured to monitor operational data reported by a cloud-native application platform, where the operational data is generated during the application's execution in a cloud-native scenario.The second calling component 1104 is configured to call a verification policy from the defense engine's verification policy set that matches the running data. The verification policy represents the rule information for verifying the running data. The second verification component 1106 is configured to verify the running data at least once according to the verification policy and obtain at least one verification result. The second processing component 1108 is configured to perform defense processing on the application based on the risk level determined by the at least one verification result and obtain a defense result. The risk level represents the degree of risk posed by the running data to the application. The return component 1110 is configured to return the defense result to the cloud-native application platform. It should be noted that the second monitoring component 1102, second calling component 1104, second verification component 1106, second processing component 1108, and return component 1110 described above correspond to steps S402 to S410 in the preceding text. The examples and application scenarios implemented by these five components and corresponding steps are the same, but are not limited to the content disclosed above. It should be noted that the above-mentioned components may be hardware components or software components stored in a memory (e.g., memory 804) and processed by one or more processors (e.g., processors 802a, 802b, ..., 802n). The above-mentioned components may also be executed as part of a device in the provided computer terminal 80. According to an embodiment of the present disclosure, a device for application risk prevention is also provided for implementing the application risk prevention method shown in FIG. 5 . This device may be applied to a defense engine. FIG. 12 is a schematic diagram of another application risk prevention device according to an embodiment of the present disclosure. As shown in FIG. 12 , the application risk prevention device 1200 may include: a third monitoring component 1202, a third calling component 1204, a third verification component 1206, a third processing component 1208, and an output component 1210. The third monitoring component 1202 is configured to monitor the operation data generated during the operation of the application by calling a first interface, wherein the first interface includes a first parameter whose parameter value is the operation data. A third calling component 1204 is configured to call a verification policy from the defense engine's verification policy set that matches the running data, where the verification policy represents rule information for verifying the running data. A third verification component 1206 is configured to verify the running data at least once according to the verification policy and obtain at least one verification result.The third processing component 1208 is configured to perform defense processing on the application based on the risk level determined by at least one verification result, thereby obtaining a defense result. The risk level indicates the degree of risk posed by the running data to the application. The output component 1210 is configured to output the defense result by calling a second interface, wherein the second interface includes a second parameter whose parameter value is the defense result. It should be noted that the third monitoring component 1202, the third calling component 1204, the third verification component 1206, the third processing component 1208, and the output component 1210 correspond to steps S502 to S510 in the above description. The examples and application scenarios implemented by these five components and the corresponding steps are the same, but are not limited to the above disclosure. It should be noted that the above components can be hardware components or software components stored in a memory (e.g., memory 804) and processed by one or more processors (e.g., processors 802a, 802b, ..., 802n). The above components can also be executed as part of an apparatus on the provided computer terminal 80. In the application risk prevention device, the application's operational data is verified using the corresponding correction policy in the correction policy set. Based on the risk level determined by the verification results, the application is then protected. This improves operation and maintenance efficiency and prevents unknown stability and security risks in the application, thereby achieving the technical effect of effectively protecting against application risks and resolving the technical problem of being unable to effectively protect against application risks. Embodiments of the present disclosure may provide a computer terminal, which may be any computer terminal device in a computer terminal group. Optionally, in this embodiment, the computer terminal may be replaced with a terminal device such as a mobile terminal. Optionally, in this embodiment, the computer terminal may be located on at least one of multiple network devices in a computer network. In this embodiment, the computer terminal may execute program code for the following steps in the application risk defense method: monitoring operational data generated during the operation of the application; invoking a verification policy from a verification policy set of a defense engine that matches the operational data, wherein the verification policy represents rule information for verifying the operational data; verifying the operational data at least once according to the verification policy to obtain at least one verification result; and performing defense processing on the application based on a risk level determined based on the at least one verification result, wherein the risk level represents the degree of risk posed by the operational data to the operation of the application.Alternatively, Figure 13 is a block diagram of a computer terminal according to an embodiment of the present disclosure. As shown in Figure 13 , the computer terminal A may include one or more (only one is shown) processors 1302, a memory 1304, and a transmission device 1306. The memory may be used to store software programs and components, such as the program instructions / components corresponding to the application risk prevention method and apparatus according to the embodiments of the present disclosure. The processor executes the software programs and components stored in the memory to execute various functional applications and process data, thereby implementing the aforementioned application risk prevention method. The memory may include high-speed random access memory (RAM) and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory located remotely from the processor, which may be connected to the terminal A via a network. Examples of such networks include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof. The processor can access information and applications stored in the memory through a transmission device to perform the following steps: monitor operational data generated by the application during operation; invoke a verification policy from a verification policy set of the defense engine that matches the operational data, wherein the verification policy represents rule information for verifying the operational data; verify the operational data at least once according to the verification policy, obtaining at least one verification result; and perform defense processing on the application based on a risk level determined based on the at least one verification result, wherein the risk level represents the degree of risk posed by the operational data to the application. Optionally, the processor can further execute program code for the following steps: if the risk level is less than a first risk level threshold, input the operational data into a cloud-native big model for secondary verification, obtaining a secondary verification result; update the risk level based on the secondary verification result; and perform defense processing on the application based on the updated risk level. Optionally, the processor may further execute program code for the following steps: if the risk level is less than a first risk level threshold, determining a sub-model within the large model that matches the performance indicator to be verified of the operating data, where the performance indicator to be verified represents the performance of the application under the operating data; inputting the operating data into the sub-model to verify the performance indicator to be verified, and obtaining a secondary verification result. Optionally, the processor may further execute program code for the following steps: inputting the operating data into the first-type sub-model to verify the safety performance indicator of the operating data and obtain a safety verification result; and / or inputting the operating data into the second-type sub-model to verify the stability performance indicator of the operating data and obtain a stability verification result.Optionally, the processor may further execute program code for the following steps: in response to the updated risk level being less than a second risk level threshold, feeding back the updated risk level to the terminal device corresponding to the application, wherein the updated risk level is used to cause the terminal device to adjust the application. Optionally, the processor may further execute program code for the following steps: adjusting operating data based on the adjusted application; feeding back the adjusted operating data to the platform device corresponding to the application. Optionally, the processor may further execute program code for the following steps: in response to the updated risk level threshold being greater than or equal to a second risk level threshold, feeding back the updated risk level to the terminal device and / or platform device corresponding to the application, wherein the updated risk level is verified by the terminal device and / or platform device to obtain a verification result; and performing defense processing on the application based on the verification result. Optionally, the processor may further execute program code for the following steps: in response to the verification result being that the updated risk level is less than the second risk level threshold, outputting a notification message for the application and allowing access to the application, wherein the notification message indicates that the application presents a risk. Optionally, the processor may further execute program code for the following steps: in response to a verification result indicating that the updated risk level is less than a second risk level threshold, marking a performance indicator of the operating data as a basic performance indicator, wherein the basic performance indicator represents the basic performance of the application under the operating data; and updating a verification policy in a verification policy set based on the marked operating data and the defense result of the application, wherein the defense result at least indicates that access to the application is permitted. Optionally, the processor may further execute program code for the following steps: in response to a verification result indicating that the updated risk level is greater than or equal to the second risk level threshold, blocking the application. Optionally, the processor may further execute program code for the following steps: in response to a verification result indicating that the updated risk level is greater than or equal to the second risk level threshold, updating a verification policy in a verification policy set based on the operating data and the defense result of the application, wherein the defense result at least indicates that the application is blocked. Optionally, the processor may further execute program code for the following steps: updating the large model based on the verification result. Optionally, the processor may further execute program code of the following steps: identifying the running data to obtain the original running data and the revised running data of the application; and calling a verification policy that matches the original running data and the revised running data in the verification policy set of the defense engine.Optionally, the processor may further execute program code for the following steps: determining at least one basic performance indicator of the operating data based on a verification policy, wherein the at least one basic performance indicator corresponds to the verification policy and represents the basic performance of the application under the operating data; and verifying the basic performance indicator according to the verification policy to obtain a verification result. Optionally, the processor may further execute program code for the following steps: sending a blocking request to the platform device corresponding to the application if the risk level is greater than or equal to a first risk level threshold, wherein the blocking request is used to request the platform device to block the application. The processor can call the information and application stored in the memory through the transmission device to perform the following steps: monitor the operation data reported by the cloud-native application platform, wherein the operation data is generated during the operation of the application in the cloud-native scenario; call the verification strategy that matches the operation data in the verification strategy set of the defense engine, wherein the verification strategy is used to represent the rule information for verifying the operation data; verify the operation data at least once according to the verification strategy to obtain at least one verification result; based on the risk level determined by the at least one verification result, perform defense processing on the application to obtain a defense result, wherein the risk level is used to represent the degree of risk brought by the operation data to the operation of the application; and return the defense result to the cloud-native application platform. The processor can access information and applications stored in the memory through a transmission device to perform the following steps: monitor operational data generated by the application during operation by calling a first interface, wherein the first interface includes a first parameter, the parameter value of the first parameter being the operational data; call a verification policy from a verification policy set of a defense engine that matches the operational data, wherein the verification policy represents rule information for verifying the operational data; verify the operational data at least once according to the verification policy, and obtain at least one verification result; perform defense processing on the application based on a risk level determined based on the at least one verification result, and obtain a defense result, wherein the risk level represents the degree of risk posed by the operational data to the application; and output the defense result by calling a second interface, wherein the second interface includes a second parameter, the parameter value of the second parameter being the defense result. According to the embodiments of the present disclosure, the operational data of the application is verified using a corresponding correction policy in the correction policy set, and defense processing is performed on the application based on the risk level determined based on the verification result, thereby improving operation and maintenance efficiency, preventing unknown stability and security risks of the application, and achieving the technical effect of effectively defending against application risks, thereby resolving the technical problem of being unable to effectively defend against application risks.Those skilled in the art will appreciate that the structure shown in FIG13 is merely illustrative. Computer terminal A may also be a smartphone (such as an Android phone, an iOS phone, etc.), a tablet computer, a PDA, a mobile internet device (MID), a PAD, or other terminal device. FIG13 does not limit the structure of the computer terminal A. For example, computer terminal A may include more or fewer components (such as a network interface, a display device, etc.) than those shown in FIG13 , or have a configuration different from that shown in FIG13 . Those skilled in the art will appreciate that all or part of the steps in the various methods of the above embodiments can be completed by a program instructing the hardware associated with the terminal device. The program may be stored in a computer-readable storage medium, which may include a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk. Embodiments of the present disclosure also provide a computer-readable storage medium. Optionally, in this embodiment, the computer-readable storage medium may be used to store program code executed by the application risk prevention method provided in the above embodiments. Optionally, in this embodiment, the computer-readable storage medium may be located in any computer terminal in a computer terminal group in a computer network, or in any mobile terminal in a mobile terminal group. Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: monitoring operational data generated by an application during operation; invoking a verification policy from a defense engine's verification policy set that matches the operational data, wherein the verification policy represents rule information for verifying the operational data; performing at least one verification on the operational data according to the verification policy to obtain at least one verification result; performing defense processing on the application based on a risk level determined based on the at least one verification result, wherein the risk level represents the degree of risk posed by the operational data to the application. Optionally, the computer-readable storage medium may further store program code for executing the following steps: if the risk level is less than a first risk level threshold, inputting the operational data into a large model for secondary verification to obtain a secondary verification result; updating the risk level based on the secondary verification result; and performing defense processing on the application based on the updated risk level.Optionally, the computer-readable storage medium may further execute program code for the following steps: when the risk level is less than a first risk level threshold, determining a sub-model in the cloud-native large model that matches the performance indicator to be verified of the operating data, wherein the performance indicator to be verified represents the performance of the application under the operating data; inputting the operating data into the sub-model to verify the performance indicator to be verified, and obtaining a secondary verification result. Optionally, the computer-readable storage medium may further execute program code for the following steps: inputting the operating data into the first-type sub-model to verify the security performance indicator of the operating data to obtain a security verification result; and / or inputting the operating data into the second-type sub-model to verify the stability performance indicator of the operating data to obtain a stability verification result. Optionally, the computer-readable storage medium may further execute program code for the following steps: in response to the updated risk level being less than a second risk level threshold, feeding back the updated risk level to a terminal device corresponding to the application, wherein the updated risk level is used to cause the terminal device to adjust the application. Optionally, the computer-readable storage medium may further include program code for executing the following steps: adjusting operating data based on the adjusted application; and feeding back the adjusted operating data to the platform device corresponding to the application. Optionally, the computer-readable storage medium may further include program code for executing the following steps: in response to an updated risk level threshold being greater than or equal to a second risk level threshold, feeding back the updated risk level to the terminal device and / or platform device corresponding to the application, wherein the updated risk level is verified by the terminal device and / or platform device to obtain a verification result; and performing defense processing on the application based on the verification result. Optionally, the computer-readable storage medium may further include program code for executing the following steps: in response to a verification result indicating that the updated risk level is less than the second risk level threshold, outputting a notification message for the application and allowing access to the application, wherein the notification message indicates that the application presents a risk. Optionally, the computer-readable storage medium may further include program code for executing the following steps: in response to a verification result indicating that the updated risk level is less than a second risk level threshold, marking a performance indicator of the operating data as a basic performance indicator, wherein the basic performance indicator represents the basic performance of the application under the operating data; and updating a verification policy in a verification policy set based on the marked operating data and the defense result of the application, wherein the defense result at least indicates that access to the application is permitted. Optionally, the computer-readable storage medium may further include program code for executing the following steps: in response to a verification result indicating that the updated risk level is greater than or equal to the second risk level threshold, blocking the application.Optionally, the computer-readable storage medium may further execute program code for executing the following steps: in response to a verification result indicating that the updated risk level is greater than or equal to a second risk level threshold, updating a verification policy in a verification policy set based on the operating data and the defense result of the application, wherein the defense result indicates at least blocking the application. Optionally, the computer-readable storage medium may further execute program code for executing the following steps: updating a large model based on the verification result. Optionally, the computer-readable storage medium may further execute program code for executing the following steps: identifying the operating data to obtain original and revised operating data of the application; invoking a verification policy from the verification policy set of the defense engine that matches both the original and revised operating data. Optionally, the computer-readable storage medium may further execute program code for executing the following steps: determining at least one basic performance indicator of the operating data based on the verification policy, wherein the at least one basic performance indicator corresponds to the verification policy and represents the basic performance of the application under the operating data; and verifying the basic performance indicator according to the verification policy to obtain a verification result. Optionally, the computer-readable storage medium may further include program code for executing the following steps: when the risk level is greater than or equal to a first risk level threshold, sending a blocking request to a platform device corresponding to the application, wherein the blocking request is used to request the platform device to block the application. As an optional example, the computer-readable storage medium is configured to store program code for executing the following steps: monitoring operational data reported by a cloud-native application platform, wherein the operational data is generated during the operation of the application in a cloud-native scenario; invoking a verification policy from a verification policy set of a defense engine that matches the operational data, wherein the verification policy represents rule information for verifying the operational data; performing at least one verification on the operational data according to the verification policy to obtain at least one verification result; performing defense processing on the application based on a risk level determined from the at least one verification result to obtain a defense result, wherein the risk level represents the degree of risk posed by the operational data to the application; and returning the defense result to the cloud-native application platform.As an optional example, a computer-readable storage medium is configured to store program code for performing the following steps: monitoring operational data generated by an application during operation by calling a first interface, wherein the first interface includes a first parameter whose parameter value is the operational data; calling a verification policy from a verification policy set of a defense engine that matches the operational data, wherein the verification policy represents rule information for verifying the operational data; verifying the operational data at least once according to the verification policy to obtain at least one verification result; performing defense processing on the application based on a risk level determined based on the at least one verification result to obtain a defense result, wherein the risk level represents the degree of risk posed by the operational data to the application; and outputting the defense result by calling a second interface, wherein the second interface includes a second parameter whose parameter value is the defense result. In the disclosed embodiment, the operational data of the application is verified using a corresponding correction policy from the correction policy set, and defense processing is performed on the application based on the risk level determined based on the verification result, thereby improving operation and maintenance efficiency, preventing unknown stability and security risks of the application, and thereby achieving the technical effect of effectively defending against application risks, thereby resolving the technical problem of being unable to effectively defend against application risks. Embodiments of the present disclosure may provide an electronic device that may include a memory and a processor. Figure 14 is a block diagram of an electronic device that implements a risk prevention method for an application according to an embodiment of the present disclosure. The electronic device is intended to represent various forms of digital computers, such as laptops, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components, their connections and relationships, and their functions shown herein are merely examples and are not intended to limit the implementation of the present disclosure described and / or claimed herein. As shown in Figure 14, device 1400 includes a computing component 1401 that can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 1402 or a computer program loaded from a storage component 1408 into a random access memory (RAM) 1403. In the RAM 1403 , various programs and data required for the operation of the device 1400 may also be stored.Computing component 1401, ROM 1402, and RAM 1403 are interconnected via bus 1404. Input / output (I / O) interface 1405 is also connected to bus 1404. Multiple components within device 1400 are connected to I / O interface 1405, including: input component 1406, such as a keyboard and mouse; output component 1404, such as various types of displays and speakers; storage component 1408, such as a magnetic disk and optical disk; and communication component 1409, such as a network card, modem, or wireless communication transceiver. Communication component 1409 allows device 1400 to exchange information / data with other devices via computer networks such as the Internet and / or various telecommunication networks. Computing component 1401 can be any general-purpose or specialized processing component with processing and computing capabilities. Some examples of computing component 1401 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computing chips, various computing components that run machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. Computing component 1401 performs the various methods and processes described above, such as the data verification method. For example, in some embodiments, the data verification method can be implemented as a computer software program tangibly embodied in a machine-readable medium, such as storage component 1408. In some embodiments, part or all of the computer program can be loaded and / or installed on device 1400 via ROM 1402 and / or communication component 1409. When the computer program is loaded into RAM 1403 and executed by computing component 1401, one or more steps of the data verification method described above may be performed. Alternatively, in other embodiments, computing component 1401 may be configured to perform the data verification method in any other appropriate manner (e.g., via firmware). According to embodiments of the present disclosure, a method for preventing application risks is provided. It should be noted that the steps shown in the flowcharts of the accompanying drawings may be executed in a computer system, such as a set of computer-executable instructions. Furthermore, although the flowcharts illustrate a logical order, in some cases, the steps shown or described may be executed in a different order than that illustrated or described.Various implementations of the systems and techniques described herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), system-on-a-chip (SOCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include implementation in one or more computer programs that are executable and / or interpreted on a programmable system including at least one programmable processor, which can be a special-purpose or general-purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device. The program code used to implement the methods of the present disclosure can be written in any combination of one or more programming languages. This program code can be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device, so that when executed by the processor or controller, the program code implements the functions / operations specified in the flowcharts and / or block diagrams. The program code can be executed entirely on the machine, partially on the machine, as a stand-alone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server. In the context of the present disclosure, a machine-readable medium can be a tangible medium that can contain or store a program for use by, or in conjunction with, an instruction execution system, device, or apparatus. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or equipment, or any suitable combination of the foregoing.More specific examples of machine-readable storage media would include electrical connections based on one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. To provide for user interaction, the systems and techniques described herein can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display, monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other types of devices can also be used to provide for user interaction; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic input, voice input, or tactile input). The systems and techniques described herein can be implemented in a computing system that includes backend components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an embodiment of the systems and techniques described herein), or a computing system that includes any combination of such backend components, middleware components, or front-end components. The components of the system can be interconnected through any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (LAN), a wide area network (WAN), and the Internet. A computer system can include a client and a server. The client and server are generally remote from each other and typically interact via a communication network. The client-server relationship is established by computer programs running on the respective computers and establishing a client-server relationship. The server can be a cloud server, a server in a distributed system, or a server integrated with a blockchain. It should be noted that the serial numbers of the above-mentioned embodiments of the present disclosure are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments. In the above-mentioned embodiments of the present disclosure, the descriptions of each embodiment are given with emphasis. For details not described in detail in one embodiment, reference can be made to the relevant descriptions of other embodiments.In the several embodiments provided in this disclosure, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of components represents only one logical functional division. In actual implementation, other divisions may be employed. For example, multiple components or components may be combined or integrated into another system, or some features may be omitted or not implemented. Furthermore, the couplings or direct couplings or communication connections shown or discussed may be through interfaces, or indirect couplings or communication connections between components or components, and may be electrical or other forms. Components described as separate components may or may not be physically separate, and components shown as components may or may not be physical components, i.e., they may be located in one location or distributed across multiple network components. Some or all of these components may be selected to achieve the objectives of the present embodiments as needed. Furthermore, the functional components in the various embodiments of this disclosure may be integrated into a single processing component, each component may exist physically separately, or two or more components may be integrated into a single component. The aforementioned integrated components can be implemented in either hardware or software functional components. If the integrated components are implemented as software functional components and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present disclosure, or the portion that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product, stored in a storage medium, includes instructions for enabling a computer device (such as a personal computer, server, or network device) to perform all or part of the steps of the various embodiments of the present disclosure. The aforementioned storage media include various media capable of storing program code, such as USB flash drives, read-only memories (ROMs), random access memories (RAMs), removable hard drives, magnetic disks, or optical disks. The above are merely preferred embodiments of the present disclosure. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present disclosure, and such improvements and modifications should also be considered within the scope of protection of the present disclosure.Industrial Applicability: The solution provided by the embodiments of the present disclosure can be applied during the operation of an application to monitor the operational data generated by the application during operation; call a verification policy from the verification policy set of the defense engine that matches the operational data, where the verification policy is used to represent rule information for verifying the operational data; verify the operational data at least once according to the verification policy to obtain at least one verification result; and perform defense processing on the application based on the risk level determined based on the at least one verification result, where the risk level is used to represent the degree of risk posed by the operational data to the application operation, thereby resolving the technical problem of being unable to effectively defend against risks in the application.

Claims

Claims 1. A risk defense method for an application program, applied to a defense engine, the method comprising: Monitor the running data generated during the operation of the monitoring application; In the verification policy set of the defense engine, call the verification policy that matches the running data, where the verification policy is used to represent the rule information for verifying the running data; perform at least one verification on the running data according to the verification policy to obtain at least one verification result; perform a defense process on the application based on the risk level determined based on at least the one verification result, where the risk level is used to represent the risk degree brought by the running data to the operation of the application.

2. The method according to claim 1, wherein Performing a defense process on the application based on the risk level determined based on at least the one verification result includes: in the case where the risk level is less than the first risk level threshold, input the running data into a large model for secondary verification to obtain a secondary verification result; update the risk level based on the secondary verification result; perform a defense process on the application based on the updated risk level.

3. The method according to claim 2, wherein, In the case where the risk level is less than the first risk level threshold, input the running data into a large model for secondary verification to obtain a secondary verification result, including: in the case where the risk level is less than the first risk level threshold, determine in the large model a sub-model that matches the performance index to be verified of the running data, where the performance index to be verified is used to represent the performance of the application under the running data; input the running data into the sub-model to verify the performance index to be verified to obtain the secondary verification result.

4. The method according to claim 3, wherein, The sub-model includes a first type of sub-model that matches the security performance index to be verified of the running data, and a second type of sub-model that matches the stability performance index to be verified of the running data. The security performance index is used to represent the security performance of the application under the running data, and the stability performance index is used to represent the stability performance of the application under the running data. Wherein, inputting the running data into the sub-model to verify the performance index to be verified to obtain the secondary verification result includes: inputting the running data into the first type of sub-model to verify the security performance index of the running data to obtain a security verification result; and / or inputting the running data into the second type of sub-model to verify the stability performance index of the running data to obtain a stability verification result. 38 5. The method according to claim 2, wherein Performing a defense process on the application based on the updated risk level includes: in response to the updated risk level being less than the second risk level threshold, feedback the updated risk level to the terminal device corresponding to the application, where the updated risk level is used to enable the terminal device to adjust the application.

6. The method according to claim 5, wherein, The method further includes: adjusting the operation data based on the adjusted application program; and feeding back the adjusted operation data to the platform device corresponding to the application program.

7. The method according to claim 2, wherein Based on the updated risk level, perform defense processing on the application program, including: in response to the updated risk level being greater than or equal to a second risk level threshold, feeding back the updated risk level to the terminal device and / or platform device corresponding to the application program, where the updated risk level is verified by the terminal device and / or the platform device to obtain a verification result; and performing defense processing on the application program based on the verification result.

8. The method according to claim 7, wherein Based on the verification result, perform defense processing on the application program, including: in response to the verification result indicating that the updated risk level is less than the second risk level threshold, outputting a notification message for the application program and allowing access to the application program, where the notification message is used to indicate that there is a risk with the application program.

9. The method according to claim 7, wherein The method further includes: in response to the verification result indicating that the updated risk level is less than the second risk level threshold, marking the performance metric of the operation data as a basic performance metric, where the basic performance metric is used to represent the basic performance of the application program under the operation data.

10. The method according to claim 9, wherein, The method further includes: updating the verification policies in the verification policy set based on the marked operation data and the defense result of the application program, where the defense result is used to at least indicate that access to the application program is allowed.

11. The method according to claim 7, wherein Based on the verification result, perform defense processing on the application program, including: in response to the verification result indicating that the updated risk level is greater than or equal to the second risk level threshold, blocking the application program.

12. The method according to claim 11, wherein The method further includes: in response to the verification result indicating that the updated risk level is greater than or equal to the second risk level threshold, updating the verification policies in the verification policy set based on the operation data and the defense result of the application program. 39 where the defense result is used to at least indicate that the application program is blocked.

13. The method according to claim 1, wherein In the verification policy set of the defense engine, call the verification policy that matches the operation data, including: identifying the operation data to obtain the original operation data and the revised operation data of the application program; and in the verification policy set of the defense engine, calling the verification policy that matches both the original operation data and the revised operation data.

14. The method according to claim 13, wherein In the verification policy set of the defense engine, invoking the verification policy that matches both the original running data and the revised running data includes: in the verification policy set of the defense engine, invoking at least one first verification policy that matches the original running data, and at least one second verification policy that matches the revised running data, where the first verification policy is used to represent the rule information for verifying the original running data, and the second verification policy is used to represent the rule information for verifying the revised running data; determining the first verification policy and the second verification policy as the verification policy.

15. The method according to claim 1, wherein Performing at least one verification on the running data according to the verification policy to obtain at least one verification result, including: based on the verification policy, determining at least one basic performance index of the running data, where the at least one basic performance index corresponds to the verification policy, and the basic performance index is used to represent the basic performance of the application program under the running data; performing verification on the basic performance index according to the verification policy to obtain the one verification result.

16. A risk defense method for an application program, applied to a defense engine in a cloud-native scenario, the method comprising: Monitoring the running data reported by the cloud-native application platform, where the running data is generated during the running of the application program in the cloud-native scenario; in the verification policy set of the defense engine, invoking the verification policy that matches the running data, where the verification policy is used to represent the rule information for verifying the running data; performing at least one verification on the running data according to the verification policy to obtain at least one verification result; based on the risk level determined by at least the one verification result, performing defense processing on the application program to obtain a defense result, where the risk level is used to represent the degree of risk brought by the running data to the running of the application program; returning the defense result to the cloud-native application platform.

17. A risk defense system for an application program, comprising: The platform device is set to respond to the defense request of the application program, obtain the running data generated during the running of the application program, and report the running data to the defense engine; 40 The defense engine is set to, in the verification policy set, invoke the verification policy that matches the running data, where the verification policy is used to represent the rule information for verifying the running data; perform at least one verification on the running data according to the verification policy to obtain at least one verification result; based on the risk level determined by at least the one verification result, perform defense processing on the application program, where the risk level is used to represent the degree of risk brought by the running data to the running of the application program.

18. An electronic device, comprising: A memory and a processor; The memory is set to store computer-executable instructions, and the processor is set to execute the computer-executable instructions. When the computer-executable instructions are executed by the processor, the steps of the method described in any one of claims 1 to 16 are implemented.

19. A computer program product, comprising a non-volatile computer-readable storage medium storing a computer program, which when executed by a processor implements the method according to any one of claims 1 to 16.

20. A computer-readable storage medium, comprising a stored executable program, wherein when the executable program runs, it controls the device where the storage medium is located to execute the method according to any one of claims 1 to 16.

Images