AI-based saas system vulnerability automatic repair method and system
By using an AI-based automated vulnerability remediation method for SaaS systems and leveraging an LLM model for vulnerability identification and patch generation, the method achieves automated remediation and continuous learning of SaaS system vulnerabilities. This solves the problem that existing technologies cannot automatically identify and remediate vulnerabilities in complex business logic, and improves remediation efficiency and self-learning capabilities.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- KANGFU ZHUSHOU
- Filing Date
- 2026-01-27
- Publication Date
- 2026-05-29
AI Technical Summary
Existing technologies cannot effectively and automatically identify and repair complex business logic vulnerabilities in SaaS systems, lack trusted verification and rollback guarantees, and lack a learning loop.
An AI-based approach is adopted, which uses an LLM model to perform semantic analysis on system data, generate patches, and conduct canary deployment and verification. Combined with an automatic rollback strategy, it enables automatic identification, repair, and continuous learning of vulnerabilities.
It improves vulnerability detection coverage and remediation success rate, reduces remediation response time and manpower costs, and has continuous self-learning and compliance auditing capabilities.
Smart Images
Figure CN121579265B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of SaaS system technology, and in particular to an AI-based method and system for automated vulnerability repair of SaaS systems. Background Technology
[0002] SaaS, or Software as a Service, is a service model that delivers software applications over the internet. Users do not need to install and maintain software locally; instead, they subscribe to use cloud-hosted applications on demand. Data is stored in the service provider's data center and supports access from multiple devices. As enterprise businesses migrate to cloud-based SaaS, continuous software integration and frequent releases have become the norm. At the same time, the attack surface and complexity are rapidly increasing, leading to a growing number of vulnerabilities in the system.
[0003] Currently, the industry mainly uses the following methods to handle vulnerabilities: manual response, rule detection, CI / CD scanning, and gray-scale rollback. Although the above methods can identify and fix vulnerabilities in SaaS systems, they share common problems, including: inability to perform semantic-level repair of vulnerabilities in complex business logic, lack of trusted verification and rollback guarantees for automated repair, and lack of a learning loop. Therefore, the fundamental problem that this invention aims to solve is how to realize a system that can automatically identify vulnerabilities, generate and verify patches, automatically deploy rollbacks, and has continuous learning capabilities. Summary of the Invention
[0004] To achieve a system that can automatically identify vulnerabilities, generate and verify patches, automatically deploy rollbacks, and has continuous learning capabilities, this application provides an AI-based method and system for automated vulnerability remediation in SaaS systems.
[0005] Firstly, this application provides an AI-based method for automated vulnerability remediation in SaaS systems, employing the following technical solution:
[0006] AI-based automated vulnerability remediation methods for SaaS systems include:
[0007] Step 1: Collect system data, including source code, logs, business descriptions, and operational monitoring data;
[0008] Step 2: Obtain the abstract syntax tree and call chain from the source code; perform LLM semantic analysis on the logs, abstract syntax tree, call chain, and business description to identify system logic vulnerabilities; perform trend analysis on the operation monitoring data and identify system operation vulnerabilities based on the trend analysis results.
[0009] Step 3: Using the LLM model, generate several sets of patches based on the template, system logic vulnerabilities, and system operation vulnerabilities, and score and filter the patches;
[0010] Step 4: Deploy the selected patches in a gray-scale manner and verify them using shadow traffic. If the verification fails, roll back automatically; if the verification passes, repair automatically. Optimize the LLM model based on the verification results.
[0011] Optionally, the LLM semantic analysis process includes:
[0012] The business logic of each business is determined by using the LLM model, logs, and business descriptions.
[0013] The syntax structure chain of each business is obtained based on the call chain and abstract syntax tree. The actual business logic of each business is determined by the LLM model, call chain, and syntax structure chain. The business logic of each business is compared with the actual business logic to determine whether there are any system logic vulnerabilities.
[0014] Optionally, the trend analysis process includes:
[0015] Divide the monitoring dimensions, obtain the monitoring indicators for each dimension, and make judgments on each monitoring indicator:
[0016] When a monitoring indicator exceeds its corresponding threshold range, the monitoring indicator is judged to be abnormal. The abnormal score is determined according to the proportion of the monitoring indicator exceeding its corresponding threshold range. The monitoring indicators under each dimension are arranged in a preset order to obtain the abnormal score feature sequence of each dimension. System operation vulnerabilities are identified based on the abnormal score feature sequence of each dimension.
[0017] When no monitoring indicator exceeds its corresponding threshold range, the system operation vulnerability is determined based on the changing trend of the monitoring indicators under all dimensions. When a system operation vulnerability exists, it is identified.
[0018] Optionally, the monitoring dimensions are divided into user experience dimension, application performance dimension, and resource consumption dimension;
[0019] The monitoring metrics for the user experience dimension include page load time, transaction success rate, and API response time.
[0020] The monitoring metrics for application performance include application response time, error rate, throughput, and database query performance score.
[0021] The monitoring metrics for resource usage include CPU utilization, memory utilization, disk I / O performance, and network latency.
[0022] Optionally, when a monitoring indicator exceeds its corresponding threshold range, the system operation vulnerability identification process includes:
[0023] Obtain the typical characteristic sequence of historical operational vulnerabilities for each monitoring dimension, compare the abnormal score feature sequence with the typical characteristic sequence of the corresponding monitoring dimension, and obtain the matching value under that monitoring dimension.
[0024] The matching values under each monitoring dimension are weighted and summed to obtain the final matching value. The historical operational vulnerabilities corresponding to the final matching value are used as system operational vulnerabilities.
[0025] Optionally, when no monitoring indicator exceeds its corresponding threshold range, the process of determining whether a system operational vulnerability exists includes:
[0026] Risk scores are calculated based on the proximity and slope of the monitoring indicators to the threshold range under each monitoring dimension. The average risk score of the monitoring indicators under each monitoring dimension is calculated. If the average risk score of a monitoring dimension is greater than the preset threshold, it is determined that there is a system operation vulnerability.
[0027] Optionally, when system vulnerabilities exist, the process of identifying system vulnerabilities includes:
[0028] The monitoring indicators under each dimension are arranged in a preset order to obtain the risk score feature sequence of each dimension;
[0029] Obtain the typical characteristic sequence of historical operational vulnerabilities for each monitoring dimension, compare the risk scoring feature sequence with the typical characteristic sequence of the corresponding monitoring dimension, and obtain the risk matching value under that monitoring dimension.
[0030] The risk matching values under each monitoring dimension are weighted and summed to obtain the final risk matching value. The historical operational vulnerabilities corresponding to the final risk matching value are then used as system operational vulnerabilities.
[0031] Secondly, this application provides an AI-based automated vulnerability repair system for SaaS systems, employing the following technical solution:
[0032] An AI-based automated vulnerability remediation system for SaaS systems, wherein the system employs any one of the aforementioned AI-based automated vulnerability remediation methods for SaaS systems, comprising:
[0033] The perception layer is used to collect system data, which includes source code, logs, business descriptions, and operational monitoring data.
[0034] The identification layer is used to obtain the abstract syntax tree and call chain from the source code, perform LLM semantic analysis on logs, abstract syntax trees, call chains and business descriptions to identify system logic vulnerabilities, and perform trend analysis on operation monitoring data to identify system operation vulnerabilities based on the trend analysis results.
[0035] The patch generation layer is used to generate several sets of patches based on templates, system logic vulnerabilities, and system operation vulnerabilities using the LLM model, and to score and filter the patches.
[0036] The execution and verification learning layer is used to perform canary deployment and shadow traffic verification of the selected patches. It automatically rolls back when the verification fails and automatically repairs when the verification passes. It also provides feedback optimization to the LLM model based on the verification results.
[0037] In summary, this application includes at least one of the following beneficial technical effects:
[0038] This invention, based on the LLM model and the process of identifying system logic vulnerabilities and system operation vulnerabilities, automates the process of handling vulnerabilities in SaaS systems. By combining patch candidate generation and automatic screening mechanisms with secure canary release and rollback strategies, it can improve vulnerability detection coverage and repair success rate, greatly reduce repair response time, reduce labor costs, and has continuous self-learning and compliance auditing capabilities. Attached Figure Description
[0039] Figure 1 This is a flowchart of an AI-based automated vulnerability remediation method for SaaS systems.
[0040] Figure 2 This is a framework diagram of an AI-based SaaS system for automated vulnerability repair. Detailed Implementation
[0041] The embodiments of this application are described in detail below, and examples of the embodiments are shown in the accompanying drawings.
[0042] In the description of this specification, the references to "certain embodiments," "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples" refer to specific features, structures, materials, or characteristics described in connection with the described embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.
[0043] This application discloses an AI-based automated vulnerability repair method and system for SaaS systems, referring to... Figure 2 The system includes a perception layer, a recognition layer, a repair and generation layer, and an execution and verification learning layer, as shown in the reference. Figure 1The perception layer completes the task of collecting system data in step one, which includes source code, logs, business descriptions, and operational monitoring data. The recognition layer completes the perception task in step two, obtaining the Abstract Syntax Tree (AST) and call chain from the source code. This process is achieved using official or mature third-party tools, such as the Python standard library, which can directly parse Python code to generate an AST. The AST node can be returned using `ast.parse(source_code)`. In Java, the AST node can be obtained through Eclipse JDT or JavaParser. Afterwards, LLM semantic analysis is performed on the logs, AST, call chain, and business description to obtain the system data. System logic vulnerabilities are identified through a process that first assesses the business logic of each service using an LLM model, logs, and business descriptions. Then, the syntactic structure chain of each service is obtained based on the call chain and abstract syntax tree. The actual business logic of each service is then determined using the LLM model, call chain, and syntactic structure chain. Finally, the actual business logic of each service is compared with the actual business logic to determine if system logic vulnerabilities exist. This process relies on an LLM model, which has been trained on a large amount of data and is capable of understanding and generating natural language and other types of content. Therefore, by comparing the actual business logic of the requirements with the actual business logic reflected in the code using the LLM model, system logic vulnerabilities can be identified, thus enabling the detection of system logic vulnerabilities.
[0044] In addition, the identification layer in this embodiment also performs trend analysis on the operation monitoring data and obtains system operation vulnerabilities based on the trend analysis results. The trend analysis process includes: dividing the monitoring dimensions and obtaining the monitoring indicators under each dimension. In this embodiment, the monitoring dimensions include user experience dimension, application performance dimension, and resource consumption dimension. Among them, the monitoring indicators of the user experience dimension include page load time, transaction success rate, and API response time; the monitoring indicators of the application performance dimension include application response time, error rate, throughput, and database query performance score; and the monitoring indicators of the resource consumption dimension include CPU utilization, memory utilization, disk I / O performance, and network latency.
[0045] Next, each monitoring indicator is evaluated by comparing it with its corresponding threshold range. The threshold range is set based on empirical data. When a monitoring indicator exceeds its corresponding threshold range, it is considered abnormal. Since the degree to which monitoring indicators exceed the threshold range varies, this embodiment determines the abnormality score based on the proportion of the monitoring indicator exceeding its corresponding threshold range. In this embodiment, the abnormality score ranges from 0 to 9. A score of 0 indicates that the monitoring indicator has not exceeded its corresponding threshold range. It should be noted that the correspondence between the excess proportion of different monitoring indicators and the abnormality score is set separately based on empirical data. The monitoring indicators under each dimension are arranged in a preset order to obtain the abnormality score feature sequence for each dimension. Therefore, the abnormality score feature sequence reflects the operational anomalies present during system operation, and system operational vulnerabilities can be identified based on the abnormality score feature sequences of each dimension. The process of identifying system operational vulnerabilities includes: firstly, obtaining the typical characteristic sequences of historical operational vulnerabilities for each monitoring dimension. This process is based on fitting settings to the operational data corresponding to different operational vulnerabilities in historical data, comparing the abnormal score feature sequences with the typical characteristic sequences of the corresponding monitoring dimensions, and obtaining the matching value under that monitoring dimension. In this embodiment, the matching value is calculated by obtaining the absolute value of the difference between the corresponding orders of the two sequences, and then obtaining the sum of the absolute values of the differences. The matching value is negatively correlated with the sum of the absolute values of the differences. Therefore, the smaller the sum of the absolute values of the differences, the larger the matching value, indicating that the two sequences are more similar. Then, the matching values under each monitoring dimension are weighted and summed. The corresponding weights are set according to empirical data to obtain the final matching value. The historical operational vulnerability corresponding to the final matching value is taken as the system operational vulnerability. Therefore, through the above process, the identification process of system operational vulnerabilities can be realized based on the monitoring indicators of each dimension.
[0046] Furthermore, when no monitoring indicator exceeds its corresponding threshold range, the existence of system operation vulnerabilities is determined based on the changing trends of monitoring indicators across all dimensions. This determination process includes: risk scoring based on the proximity and slope of the monitoring indicators to their corresponding threshold ranges under each monitoring dimension. The risk scoring logic is the same for different monitoring indicators: the closer the value of a monitoring indicator is to the threshold range and the higher the slope of its change, the higher the risk score. The parameters of the risk scoring models differ for different monitoring indicators. After obtaining the risk scores for different monitoring indicators, the average risk score for each monitoring dimension is calculated. If the average risk score for a monitoring dimension is greater than a preset threshold, a system operation vulnerability is identified. The process of identifying system operation vulnerabilities includes: assigning each dimension... The monitoring indicators under each dimension are arranged in a preset order to obtain the risk score feature sequence for each dimension. Therefore, the risk score feature sequence reflects the abnormal operation risk characteristics existing in the system operation process. The typical characteristic sequence of historical operation vulnerabilities in each monitoring dimension is obtained. The risk score feature sequence is compared with the typical characteristic sequence of the corresponding monitoring dimension to obtain the risk matching value under that monitoring dimension. The calculation method of the risk matching value in this embodiment is the same as the above matching value calculation method, and will not be described in detail here. The risk matching value under each monitoring dimension is weighted and summed. The corresponding weight is set according to empirical data to obtain the final risk matching value. The historical operation vulnerability corresponding to the final risk matching value is taken as the system operation vulnerability. Therefore, through the above analysis of the numerical range and changing trend of the monitoring indicators, potential system operation vulnerabilities can be identified in a timely manner to ensure the stability of the system operation process.
[0047] Next, step three is completed through the repair generation layer. The LLM model generates several sets of patches based on templates, system logic vulnerabilities, and system operational vulnerabilities. These patches are then scored and selected. Templates ensure the consistency of the generated content, while the LLM model, leveraging AI technology, automatically generates patches based on system logic and operational vulnerabilities. The LLM model scores the generated patches; higher scores indicate better quality, and these are selected for execution and verification. Step four is then completed through the execution and verification learning layer, where the selected patches undergo canary deployment and shadow traffic verification. Automatic rollback occurs if verification fails. This process does not affect the normal operation of the SaaS system. It automatically repairs vulnerabilities upon successful verification, and optimizes the LLM model based on the verification results, enabling continuous learning of the LLM model. Through the above technologies, based on the LLM model and the process of identifying system logic and operational vulnerabilities, the process of automating the handling of SaaS system vulnerabilities can be achieved. In addition, by combining patch candidate generation and automatic screening mechanisms, and security canary release and rollback strategies, the vulnerability detection coverage and repair success rate can be improved, the repair response time can be greatly reduced, and the labor costs can be reduced. It also has continuous self-learning and compliance auditing capabilities.
[0048] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.
Claims
1. An AI-based automated vulnerability remediation method for SaaS systems, characterized in that, include: Step 1: Collect system data, including source code, logs, business descriptions, and operational monitoring data; Step 2: Obtain the abstract syntax tree and call chain from the source code, and perform LLM semantic analysis on the logs, abstract syntax tree, call chain and business description to identify system logic vulnerabilities; Perform trend analysis on operational monitoring data, and identify system operational vulnerabilities based on the trend analysis results; Step 3: Using the LLM model, generate several sets of patches based on the template, system logic vulnerabilities, and system operation vulnerabilities, and score and filter the patches; Step 4: Deploy the selected patches in a canary manner and verify them using shadow traffic. If the verification fails, roll back automatically; if the verification passes, fix automatically. Optimize the LLM model based on the verification results. The trend analysis process includes: Divide the monitoring dimensions, obtain the monitoring indicators for each dimension, and make judgments on each monitoring indicator: When a monitoring indicator exceeds its corresponding threshold range, the monitoring indicator is judged to be abnormal. The abnormal score is determined according to the proportion of the monitoring indicator exceeding its corresponding threshold range. The monitoring indicators under each dimension are arranged in a preset order to obtain the abnormal score feature sequence of each dimension. System operation vulnerabilities are identified based on the abnormal score feature sequence of each dimension. When no monitoring indicator exceeds its corresponding threshold range, determine whether there is a system operation vulnerability based on the changing trend of the monitoring indicators under all dimensions, and identify the system operation vulnerability when it exists. When a monitored indicator exceeds its corresponding threshold range, the process of identifying system operational vulnerabilities includes: Obtain the typical characteristic sequence of historical operational vulnerabilities for each monitoring dimension, compare the abnormal score feature sequence with the typical characteristic sequence of the corresponding monitoring dimension, and obtain the similarity value under that monitoring dimension. The similarity values under each monitoring dimension are weighted and summed to obtain the final similarity value. The historical operational vulnerabilities corresponding to the final similarity value are used as system operational vulnerabilities.
2. The AI-based automated vulnerability repair method for SaaS systems according to claim 1, characterized in that, The LLM semantic analysis process includes: The business logic of each business is determined by using the LLM model, logs, and business descriptions. The syntax structure chain of each business is obtained based on the call chain and abstract syntax tree. The actual business logic of each business is determined by the LLM model, call chain, and syntax structure chain. The business logic of each business is compared with the actual business logic to determine whether there are any system logic vulnerabilities.
3. The AI-based automated vulnerability repair method for SaaS systems according to claim 1, characterized in that, The monitoring dimensions are divided into user experience dimension, application performance dimension, and resource consumption dimension; The monitoring metrics for the user experience dimension include page load time, transaction success rate, and API response time. The monitoring metrics for application performance include application response time, error rate, throughput, and database query performance score. The monitoring metrics for resource usage include CPU utilization, memory utilization, disk I / O performance, and network latency.
4. The AI-based automated vulnerability repair method for SaaS systems according to claim 1, characterized in that, When no monitoring indicator exceeds its corresponding threshold range, the process of determining whether a system vulnerability exists includes: Risk scores are calculated based on the proximity and slope of the monitoring indicators to the threshold range under each monitoring dimension. The average risk score of the monitoring indicators under each monitoring dimension is calculated. If the average risk score of a monitoring dimension is greater than the preset threshold, it is determined that there is a system operation vulnerability.
5. The AI-based automated vulnerability repair method for SaaS systems according to claim 4, characterized in that, When system vulnerabilities exist, the process of identifying these vulnerabilities includes: The monitoring indicators under each dimension are arranged in a preset order to obtain the risk score feature sequence of each dimension; Obtain the typical characteristic sequence of historical operational vulnerabilities for each monitoring dimension, compare the risk scoring feature sequence with the typical characteristic sequence of the corresponding monitoring dimension, and obtain the risk similarity value under that monitoring dimension. The risk similarity values under each monitoring dimension are weighted and summed to obtain the final risk similarity value. The historical operational vulnerabilities corresponding to the final risk similarity value are taken as system operational vulnerabilities.
6. An AI-based automated vulnerability repair system for SaaS systems, characterized in that: The system includes an AI-based automated vulnerability remediation method for SaaS systems as described in any one of claims 1-5, comprising: The perception layer is used to collect system data, which includes source code, logs, business descriptions, and operational monitoring data. The identification layer is used to obtain the abstract syntax tree and call chain from the source code, perform LLM semantic analysis on logs, abstract syntax trees, call chains and business descriptions to identify system logic vulnerabilities, and perform trend analysis on operation monitoring data to identify system operation vulnerabilities based on the trend analysis results. The patch generation layer is used to generate several sets of patches based on templates, system logic vulnerabilities, and system operation vulnerabilities using the LLM model, and to score and filter the patches. The execution and verification learning layer is used to perform canary deployment and shadow traffic verification of the selected patches. It automatically rolls back when the verification fails and automatically repairs when the verification passes. It also provides feedback optimization to the LLM model based on the verification results.