An AI-based interactive application security testing vulnerability research and judgment method and system

Abstract

The application relates to an AI-based interactive application security test vulnerability judgment method and system, and relates to the field of electric digital data processing.The method comprises the following steps: inserting a plug into a key function of a target system, and collecting execution environment information; identifying user input from HTTP request data in the execution environment information, tracking the propagation path to obtain a pollution data propagation chain with a vulnerability type mark; encapsulating the execution environment information, the pollution data propagation chain, the vulnerability type mark and the related function call stack into a to-be-analyzed vulnerability information package; combining a system specification document with the vulnerability information package and sending the same to a large language model to obtain a document summary; combining the document summary and pollution data initial entry point information and sending the same to the model to obtain a context supplement request; combining the supplement request and a preset vulnerability bypass case and sending the same to the model to obtain a judgment result; and finally updating the judgment result to vulnerability detail information. By implementing the method, the verification cost of security test vulnerability judgment can be reduced.

Description

Technical Field

[0001] This application relates to the field of electronic digital data processing, and in particular to an AI-based method and system for assessing security vulnerabilities in interactive applications. Background Technology

[0002] With the rapid development of information technology and the widespread use of the Internet, application system security testing is playing an increasingly important role in network security protection. This is especially true in critical sectors such as finance, where higher requirements are being placed on the security of application systems.

[0003] Currently, the industry widely uses Interactive Application Security Testing (IAST) technology for vulnerability detection. IAST systems monitor critical functions during application runtime, combining the advantages of static and dynamic analysis to detect potential security vulnerabilities in applications in real time. In practical applications, IAST systems collect data such as function call context and execution environment information, and analyze this data according to pre-defined detection rules to discover potential security vulnerabilities.

[0004] However, existing IAST systems have some limitations in vulnerability detection. Due to the increasing complexity of application systems and the massive number of detected vulnerabilities, the workload for verification and analysis has increased significantly. The verification process requires analyzing a large amount of technical details and contextual information, resulting in high verification costs. Summary of the Invention

[0005] This application provides an AI-based interactive application security testing vulnerability assessment method and system to reduce the verification cost of security testing vulnerability assessment.

[0006] Firstly, this application provides an AI-based method for assessing vulnerabilities in interactive application security testing, applied to an interactive application security testing vulnerability assessment system. The method includes: instrumenting key functions of the target system under test to collect execution environment information; identifying user input data in the Hypertext Transfer Protocol (HTTP) request data within the execution environment information based on pre-defined rules, and tracing the propagation path of the user input data within the execution environment information to obtain a contaminated data propagation chain, which includes vulnerability type markers; and encapsulating the execution environment information, the contaminated data propagation chain, the vulnerability type markers, and the function call stack affected by the contaminated data to obtain... The vulnerability information packet to be analyzed is used as follows: The application system documentation and the vulnerability information packet are combined to construct a first dialogue context, which is then sent to the large language model to obtain a summary of the documentation; the summary of the documentation is combined with the initial entry point information of the polluted data in the vulnerability information packet to construct a second dialogue context, which is then sent to the large language model to obtain a context supplementation request; the context supplementation request and pre-set vulnerability bypass cases are combined to construct a third dialogue context, which is then sent to the large language model for analysis to obtain the large model's judgment result; the large model's judgment result is then updated in the vulnerability details information.

[0007] In the above embodiments, instrumentation is performed on key functions of the target system to collect execution environment information, and technical details such as the contaminated data propagation chain and execution environment information are encapsulated in a structured manner. By submitting information packets to a large language model in stages and obtaining analysis results, the model can automatically establish system cognition, analyze the contaminated data propagation process, and assess vulnerability risks. This enables the verification process of a large number of vulnerabilities to be completed efficiently without the need to analyze complex technical details one by one, thus reducing the cost of vulnerability verification.

[0008] In conjunction with some embodiments of the first aspect, in some embodiments, the method of identifying user input data in the Hypertext Transfer Protocol request data in the execution environment information based on preset rules, and tracing the propagation path of the user input data in the execution environment information to obtain a contaminated data propagation chain, which includes a step of vulnerability type marking, specifically includes: extracting request parameters, request header information, and cookie information from the Hypertext Transfer Protocol request data as contaminated source data, wherein the contaminated data includes contaminated source data; tracing the propagation process of the contaminated source data in the target tested system to obtain the function call stack through which the contaminated source data passes; collecting the input parameter data, return value data, and class information of each function in the function call stack to construct function context information; matching the function context information with preset vulnerability feature rules to obtain risky functions and marking the vulnerability type according to the risky functions; and assembling the contaminated source data, function context information, and risky functions in the order of call to form a contaminated data propagation chain.

[0009] In the above embodiments, contamination source data is extracted from HTTP requests, its propagation process in the system is traced, and context information from function call stacks is collected. Risky functions are identified by matching them against preset rules, and the contamination chain is assembled according to the call order. This layered data collection and analysis method makes the propagation path of contamination data clearly visible, the identification of risky functions more accurate, provides a complete data foundation for subsequent vulnerability analysis, and improves the accuracy of vulnerability detection.

[0010] In conjunction with some embodiments of the first aspect, in some embodiments, the step of constructing a third dialogue context from the context supplementation request and the pre-set vulnerability bypass cases, and sending the third dialogue context to a large language model for analysis to obtain the large model's judgment result, specifically includes: constructing a first dialogue template containing instruction tags, code context tags, vulnerability bypass case tags, and analysis result tags; filling the analysis result of the second dialogue context into the analysis result tags to obtain a second dialogue template; extracting the context information of the target function from the contaminated data propagation chain based on the context supplementation request and filling it into the code context tag; when relevant vulnerability bypass cases are retrieved from the pre-set vulnerability database according to the vulnerability type label, filling the relevant vulnerability bypass cases into the vulnerability bypass case tags; sending the second dialogue template to the large language model to obtain a first analysis result; extracting supplementary context information from the contaminated data propagation chain based on the newly added context supplementation request in the first analysis result, updating the code context tag, and sending it to the large language model to obtain a second analysis result; continuously updating the code context tag according to the context supplementation request in each round of analysis results and sending it to the large language model until the large language model returns an analysis result that does not contain a context supplementation request as the large model's judgment result.

[0011] In the above embodiments, a dialogue template containing multiple functional tags is constructed, and contextual information is extracted iteratively based on the model's supplementary requests. Each round of analysis is optimized based on the results of the previous round until a complete analysis conclusion is obtained. Through this multi-round interactive analysis process, the model can gradually gain a deeper understanding of the code logic, supplement necessary contextual information, and ultimately obtain accurate vulnerability assessment results, improving the depth and accuracy of vulnerability analysis.

[0012] In conjunction with some embodiments of the first aspect, in some embodiments, after updating the vulnerability details information with the large model assessment results, the method further includes: extracting the function call sequence mentioned in the large model assessment results; retrieving the actual execution path of the function call sequence in the contaminated data propagation chain; when it is detected that the function call sequence in the large model assessment results does not exist in the contaminated data propagation chain, marking the function call sequence as AI hallucination content; performing secondary analysis on the AI ​​hallucination content, and submitting the code fragments related to the AI ​​hallucination content to the large language model for confirmation.

[0013] In the above embodiments, function call sequences are extracted from the large model's analysis results, and the actual execution paths are retrieved in the contaminated data propagation chain. When a mismatch is found, it is marked as AI hallucination content. The hallucination content is then subjected to secondary analysis and submitted to the large language model for confirmation. This establishes a verification mechanism between the model's output results and the actual code, eliminating deviations in the model's reasoning process and ensuring the accuracy and reliability of the vulnerability assessment results.

[0014] In conjunction with some embodiments of the first aspect, in some embodiments, after updating the vulnerability details information with the large model assessment results, the method further includes: constructing a confidence score model based on statistical features of AI illusion content, including function call depth, code coverage, and context matching degree; calculating a confidence score for AI illusion content when AI illusion content is detected; adjusting the third dialogue context according to the confidence score, increasing the sampling range of the code context when the confidence score is low, and adding a confidence constraint instruction to the dialogue template; and resubmitting the adjusted third dialogue context to the large language model.

[0015] In the above embodiments, a confidence scoring model is constructed based on function call depth, code coverage, and context matching to quantitatively evaluate AI-generated illusions. The code context sampling range is dynamically adjusted according to the confidence score, and confidence constraint instructions are added. Through score-driven context optimization and constraint enhancement, the model output more strictly follows the actual code logic, improving the accuracy of vulnerability analysis results.

[0016] In conjunction with some embodiments of the first aspect, in some embodiments, after updating the large model assessment results to the vulnerability details information, the method further includes: detecting data nodes in the contaminated data propagation chain that have undergone encoding conversion and encryption transformation; extracting the conversion functions and parameter configurations of the data nodes, and constructing a conversion mapping table based on the conversion functions and parameter configurations; using the conversion mapping table to restore the data in the contaminated data propagation chain to obtain the restored data propagation chain; constructing a third problem description based on the restored data propagation chain; merging the analysis results obtained based on the third problem description with the original analysis results, and updating them to the vulnerability details information.

[0017] In the above embodiments, encoding and encryption transformation nodes in the contaminated data propagation chain are detected, and transformation functions and parameter configurations are extracted to construct a mapping table. The mapping table is used to restore the data, obtaining the original data propagation chain. Re-analysis based on the restored propagation chain resolves the analytical obstacles caused by transformations and encryption during data flow, improving the accuracy of vulnerability assessment.

[0018] In conjunction with some embodiments of the first aspect, in some embodiments, after updating the large model assessment results to the vulnerability details information, the method further includes: generating vulnerability verification test cases based on the large model assessment results; executing the vulnerability verification test cases in the test environment of the target system under test and obtaining the execution results of the vulnerability verification test cases; and updating the execution results of the vulnerability verification test cases to the vulnerability details information.

[0019] In the above embodiments, targeted vulnerability verification test cases are automatically generated based on the large-scale model analysis results. These test cases are then executed in a testing environment to obtain the results. The verification results are updated in the vulnerability details, forming a closed-loop processing flow from analysis to verification. This automated verification execution mechanism directly verifies the accuracy of the model analysis results, accumulates real vulnerability verification data, establishes a complete vulnerability evidence chain, and improves the reliability of vulnerability assessment.

[0020] Secondly, embodiments of this application provide an interactive application security testing vulnerability assessment system, which includes: one or more processors and a memory; the memory is coupled to the one or more processors, and the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the interactive application security testing vulnerability assessment system to perform the method described in the first aspect and any possible implementation thereof.

[0021] Thirdly, embodiments of this application provide a computer program product containing instructions that, when the computer program product is run on an interactive application security testing vulnerability assessment system, cause the interactive application security testing vulnerability assessment system to execute the method described in the first aspect and any possible implementation thereof.

[0022] Fourthly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on an interactive application security testing vulnerability assessment system, cause the interactive application security testing vulnerability assessment system to perform the method described in the first aspect and any possible implementation thereof.

[0023] Understandably, the interactive application security testing vulnerability assessment system provided in the second aspect, the computer program product provided in the third aspect, and the computer storage medium provided in the fourth aspect are all used to execute the methods provided in the embodiments of this application. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here.

[0024] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages:

[0025] 1. This application collects execution environment information by instrumenting key functions of the target system, and encapsulates technical details such as the contaminated data propagation chain and execution environment information in a structured manner. By submitting information packets to a large language model in stages and obtaining analysis results, the model can automatically establish system cognition, analyze the contaminated data propagation process, and assess vulnerability risks. This enables the verification process of a large number of vulnerabilities to be completed efficiently without the need to analyze complex technical details one by one, thus reducing the cost of vulnerability verification.

[0026] 2. This application extracts contamination source data from HTTP requests, traces its propagation process within the system, and collects context information from function call stacks. Risky functions are identified by matching them against predefined rules, and the contamination chain is assembled according to the call order. This layered data collection and analysis method makes the propagation path of contamination data clearly visible, improves the accuracy of risky function identification, provides a complete data foundation for subsequent vulnerability analysis, and enhances the accuracy of vulnerability detection.

[0027] 3. This application constructs a dialogue template containing multiple functional tags and iteratively extracts contextual information based on model-based supplementary requests. Each round of analysis is optimized based on the results of the previous round until a complete analysis conclusion is obtained. Through this multi-round interactive analysis process, the model can gradually gain a deeper understanding of the code logic, supplement necessary contextual information, and ultimately obtain accurate vulnerability assessment results, improving the depth and accuracy of vulnerability analysis. Attached Figure Description

[0028] Figure 1 This is a flowchart illustrating an AI-based interactive application security testing vulnerability assessment method in an embodiment of this application.

[0029] Figure 2 This is another flowchart illustrating the AI-based interactive application security testing vulnerability assessment method in this application embodiment;

[0030] Figure 3 This is a schematic diagram of the physical device structure of an interactive application security testing vulnerability assessment system in this application embodiment. Detailed Implementation

[0031] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification of this application, the singular expressions “a,” “an,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to any or all possible combinations including one or more of the listed items.

[0032] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0033] To facilitate understanding, the application scenarios of the embodiments of this application are described below.

[0034] A large e-commerce platform's payment system comprises hundreds of microservices, processing over 1 million transactions daily. The system uses IAST technology for security testing, identifying approximately 200-300 potential vulnerabilities daily. Due to the system's complex architecture, a simple payment process may involve a call chain of over 20 service nodes. When IAST detects a suspicious SQL injection vulnerability, the polluted data may have passed through multiple services, undergoing multiple encoding conversions (such as Base64 and URL encoding) and encryption processes. The security team needs to manually trace the entire data flow to verify the existence of a real risk. For example, in one typical case, IAST reported an SQL injection risk in the payment interface. The pollution chain of this vulnerability spanned 5 microservices, involving 3 encoding conversions and 2 encryption processes. Manual analysis took 4 hours to ultimately confirm it was a false alarm. Such a large amount of manual verification work severely overloaded the security team, and due to the varying skill levels of the personnel, the accuracy of the verification results was difficult to guarantee.

[0035] Currently, a common industry practice is to improve the accuracy of IAST through rule engines. For example, one system uses a regular expression-based rule library to filter obvious false positives and scores vulnerabilities based on the characteristics of the pollution chain (such as length and function call depth). A tiered verification mechanism is also employed, with high-scoring vulnerabilities handled by senior security engineers and low-scoring vulnerabilities by junior personnel. However, this approach has significant drawbacks: 1) the rule library struggles to cover all scenarios, especially those involving complex business logic; 2) static rules cannot understand code semantics, leading to numerous boundary cases requiring manual judgment; 3) the scoring mechanism is too mechanical and cannot accurately reflect the actual risk of vulnerabilities; 4) manual tiered verification still relies on experience and incurs high communication costs. In practical applications, even with hundreds of rules configured, the false positive rate of this approach remains above 30%, and frequent rule updates are necessary to adapt to new scenarios.

[0036] The IAST system employing this invention achieves vulnerability assessment by constructing a multi-round AI dialogue mechanism. Taking the vulnerability detection of a business system as an example, when IAST discovers a suspected SQL injection vulnerability, the system first converts the application's README document into a structured XML format as input for the first round of dialogue, enabling the AI ​​to establish a basic understanding of the system architecture. Subsequently, the system extracts the source information of the pollution chain (such as user parameters in HTTP requests) and combines it with the analysis results of the previous round to form the content of the second round of dialogue. If the AI ​​analysis finds that it needs to understand the implementation details of a certain encryption function, it will explicitly indicate the required context in the returned XML tags. Based on this, the system extracts relevant code segments from the pollution chain, along with pre-set vulnerability bypass cases, and enters the third round of dialogue. Through this iterative context supplementation mechanism, the AI ​​can gradually build a complete analysis chain. In particular, the system will detect whether the function call sequence mentioned in the AI ​​output exists in the actual code, identify possible AI illusions, and correct them by adjusting the sampling range and adding constraint instructions. Finally, the system transforms the analysis results verified through multiple rounds into a structured vulnerability report, realizing an automated conversion process from the original pollution chain to the final assessment result.

[0037] To facilitate understanding, the method provided in this implementation will be described in detail below, using the above scenario as an example. Please refer to [link / reference]. Figure 1 This is a flowchart illustrating an AI-based interactive application security testing vulnerability assessment method in this application embodiment.

[0038] S101. Instrument the key functions of the target system under test and collect the execution environment information.

[0039] Among them, the target system under test refers to the application system that needs to be security tested; the critical function refers to the method in the system that handles important functions such as processing user input, performing database operations, and performing file operations; instrumentation refers to adding monitoring code before and after function execution through bytecode enhancement and other techniques without modifying the original code; execution environment information includes runtime data such as function call stack, parameter values, return values, and class loading information.

[0040] Specifically, when the application system starts, the IAST Agent uses Java Agent technology to enhance the bytecode of the target system, injecting monitoring code before and after the execution of all predefined sensitive functions (such as SQL execution functions, file operation functions, etc.). When these functions are called, the injected monitoring code collects information about the current execution environment, including the complete call stack, function parameters, return values, current thread information, class loader information, etc., and encapsulates this information before reporting it to the IAST platform.

[0041] In some embodiments, instrumentation and environment information collection for critical functions can be achieved in several ways: Optionally, the ASM bytecode manipulation framework can be used to directly modify the class file, inserting monitoring code before and after the method, storing context information through ThreadLocal, and collecting and reporting it uniformly after the method execution is complete; alternatively, AOP frameworks such as AspectJ can be used to define aspects, collecting execution information through around advice before and after the target method execution, supporting finer-grained instrumentation control. It is understood that other bytecode enhancement techniques can also be used to implement function monitoring, which is not limited here.

[0042] S102. Based on preset rules, identify user input data in the Hypertext Transfer Protocol Request data in the execution environment information, and trace the propagation path of user input data in the execution environment information to obtain the contaminated data propagation chain, which contains vulnerability type markers.

[0043] Among them, the predefined rules refer to the set of predefined rules used to identify user input points and track data flow; the Hypertext Transfer Protocol request data includes information such as HTTP request parameters, cookies, and headers; user input data refers to all untrusted data from external sources; the contaminated data propagation chain represents the complete call path from user input entering the system to triggering the vulnerability; and the vulnerability type tag is used to identify the types of security risks that may exist.

[0044] Specifically, after obtaining the execution environment information, the system first extracts all possible user input points from the HTTP request, including URL parameters, POST data, and cookie values. Then, based on pre-defined data flow tracing rules, it analyzes the propagation process of this input data within the application. The system records all function calls the data passes through, including parameter passing, return value passing, and object property assignment. During the tracing process, if the data flow is found to pass through predefined dangerous functions (such as SQL execution functions), the corresponding vulnerability type is marked according to the rules.

[0045] In some embodiments, data flow tracing can be implemented in several ways: Optionally, taint analysis techniques can be used to establish a data dependency graph between variables, and forward analysis can be used to identify all variables affected by tainted data to achieve accurate data flow tracing; alternatively, symbolic execution techniques can be used to simulate the program execution process, track the propagation path of input data, and support complex data transformation scenarios. It is understood that other dynamic or static analysis techniques can also be used to implement data flow tracing, and this is not limited here.

[0046] In some embodiments, this step specifically includes the following steps:

[0047] Request parameters, request header information, and cookie information are extracted from the Hypertext Transfer Protocol request data as contamination source data, which includes contamination source data.

[0048] Request parameters refer to query parameters in the HTTP request URL and form data in the POST request body; request header information includes various header fields in the HTTP request, such as User-Agent, Referer, etc.; Cookie information is session identifiers and user data stored on the client; contamination source data refers to external input data that may introduce security risks. The system parses the received HTTP request, first extracting the query string from the URL and using regular expressions to separate parameter names and values. Then, it parses the POST request body, supporting various formats such as application / x-www-form-urlencoded, multipart / form-data, etc. It iterates through the request headers, extracting the names and values ​​of all header fields. Finally, it parses the Cookie string, resolving each Cookie item into name-value pairs. All extracted data is marked as contamination sources, recording their origin and data type.

[0049] By tracing the propagation process of pollution source data in the target system under test, the function call stack through which the pollution source data passes is obtained.

[0050] The function call stack is the sequence of function calls during program execution; the propagation of polluted data refers to the flow of user input within the system. Data flow tracing is achieved through bytecode instrumentation, inserting monitoring code before and after each method call. The monitoring code records basic information such as the method name, call time, and thread ID. When polluted data is detected as a parameter passed to a method, it is marked as polluted data, and its propagation path is recorded. If polluted data is returned as a method return value or passed through an object property, the corresponding data is also marked as polluted. The system maintains a call chain tracer to record the complete function call sequence and data flow process.

[0051] Collect the input parameter data, return value data, and class information of each function in the function call stack to construct function context information.

[0052] Input parameter data refers to the values ​​of the parameters passed during function calls; return value data is the output result after function execution; class information includes the class name, package name, etc., to which the function belongs. The system captures the values ​​and types of all input parameters before the function call, and records their complete attribute information for object type parameters. Upon function return, the system captures the return value, similarly recording its data content and type information. Complete information about the class to which the function belongs is obtained through reflection, including the fully qualified class name, inheritance relationship, and implemented interfaces. This information is organized into a structured context object for subsequent vulnerability analysis.

[0053] The function context information is matched with the preset vulnerability feature rules to obtain the risk function, and the vulnerability type is marked according to the risk function.

[0054] Vulnerability signature rules are predefined sets of patterns used to identify security risks; risky functions refer to function calls that may lead to security vulnerabilities; vulnerability type tags are used to classify different security risks. The system maintains a vulnerability signature rule base, containing feature descriptions of various vulnerabilities, such as signature functions for SQL injection and output points for XSS attacks. The collected function context information is matched against the rules to check whether the function name, parameter types, and call chain characteristics match the vulnerability signatures. Functions that successfully match are marked as risky functions, and the corresponding vulnerability type is recorded.

[0055] The pollution source data, function context information, and risk functions are assembled in the order of their calls to form a pollution data propagation chain.

[0056] The contaminated data propagation chain is a data structure describing the complete flow of external input data within the system. Based on the timing of function calls, the system organizes contaminated source data, function call information, and risk functions into a directed graph structure. Nodes in the graph represent function calls and contain complete context information; edges represent data flow relationships, recording the method and content of data transmission. For risk function nodes, vulnerability type tags and risk level assessments are added. The final propagation chain is stored serially in a standard format for easy subsequent analysis and processing.

[0057] S103. Encapsulate the execution environment information, the contaminated data propagation chain, the vulnerability type marker, and the function call stack affected by the contaminated data to obtain the vulnerability information package to be analyzed.

[0058] Among them, execution environment information refers to the context data of the application runtime, including memory state, system configuration, runtime parameters, etc.; polluted data propagation chain represents the complete propagation path of user input data in the system; vulnerability type tag is used to identify the type of potential security risk; function call stack refers to the sequence of method calls during program execution; and vulnerability information packet to be analyzed represents a set of vulnerability-related data that has been structured.

[0059] Specifically, after the IAST system completes data flow tracing, all collected information needs to be integrated into a unified format for subsequent analysis. First, the execution environment information is converted to JSON format, including key information such as system configuration and runtime parameters. Then, the contaminated data propagation chain is serialized into a directed graph structure, recording all nodes and edges during the data flow. Next, vulnerability type tags and complete function call stack information are added to the data packet. Finally, this information is encapsulated into a standard-format vulnerability information packet using a unified serialization interface.

[0060] In some embodiments, information encapsulation can be implemented in several ways: Optionally, Protocol Buffers can be used as the serialization format. First, a message structure is defined to describe the format of various types of information. Then, the execution environment information is serialized into binary data. Next, the pollution chain is converted into a graph structure and serialized. Finally, all serialized data is merged and compressed. Optionally, a custom XML template can be used for encapsulation. First, a basic document structure is built to define the information hierarchy. Then, the environment information is converted into XML nodes and inserted into the document. Next, specific tags are used to describe the pollution chain and stack information. Finally, format verification and optimization are performed. It is understood that other serialization formats and encapsulation methods can also be used to achieve information integration, which is not limited here.

[0061] S104. Combine the application system documentation and the vulnerability information packet to be analyzed to construct the first dialogue context, and send the first dialogue context to the large language model to obtain the documentation summary.

[0062] Among them, the application system specification document refers to the technical document describing the system architecture, functions and implementation details; the first dialogue context represents the basic information set for the AI ​​model to understand the system; the large language model refers to the AI ​​model used for natural language processing; and the specification document summary refers to the structured extraction results of the key information of the system.

[0063] Specifically, to enable the AI ​​model to better understand the target system's business scenarios and technical architecture, the system documentation needs to be processed first. The system converts documentation such as README files into structured XML format, extracting information such as the system's functional descriptions, architecture design, and technology stack. This information is then combined with the vulnerability information package to be analyzed to construct the input content for the first round of dialogue. The dialogue template contains prompts to guide the AI ​​model in understanding the key points of the document and identifying crucial information. Through interaction with the large language model, a structured understanding of the overall system architecture is obtained.

[0064] In some embodiments, the construction of the dialogue context can be achieved in several ways: Optionally, the documentation is first preprocessed to extract paragraph structure and keywords, the document is converted to XML format and semantic tags are added, then the system information in the vulnerability information package is associated with the document content to construct a hierarchical dialogue template, and finally, prompts are generated to guide the AI ​​model to understand the system architecture; Optionally, natural language processing technology is used to analyze the document content, identify the system's functional modules and technical components, establish a knowledge graph representation, map the vulnerability information to knowledge graph nodes, and generate a multi-turn dialogue prompt strategy. It is understood that other text analysis methods can also be used to construct the dialogue, and this is not limited here.

[0065] S105. Combine the summary of the documentation with the initial entry point information of the polluted data in the vulnerability information packet to be analyzed to construct a second dialogue context, and send the second dialogue context to the large language model to obtain a context supplementation request.

[0066] Among them, the documentation summary refers to the system function and architecture overview obtained after processing by the large language model; the initial entry point information of contaminated data indicates the location and context where user input data first enters the system; the second dialogue context refers to the structured prompt information used to guide the model to understand the vulnerability generation process; and the context supplement request refers to the additional information requirements proposed by the large language model for in-depth vulnerability analysis.

[0067] Specifically, after obtaining a structured summary of the system documentation, the system needs to guide the AI ​​model to understand specific vulnerability scenarios. The system first extracts the initial entry point of the contaminated data from the vulnerability information packet, including specific HTTP request parameters, interface paths, and request methods. Then, it correlates this information with relevant functional descriptions in the documentation summary to construct a vulnerability analysis context with a business scenario. During this construction process, the system adds specific prompts to guide the model in understanding the starting point of data flow and potential security risks. The final generated dialogue context will contain complete information on the overall system architecture, specific interface functions, and the initial contamination point.

[0068] In some embodiments, the second-round dialogue context can be constructed in several ways: Optionally, firstly, functional descriptions and technical implementation information related to the target interface are extracted from the documentation summary; then, the entry point information of the contaminated data is structured and semantically annotated; next, the two parts of information are combined according to a predefined template format to finally generate a dialogue prompt guiding the model to analyze vulnerabilities; Optionally, a knowledge graph is constructed to represent the relationships between system functional modules, mapping the contaminated data entry points to corresponding functional nodes, generating a complete business scenario description based on the graph path, and finally converting it into dialogue content conforming to the input format of a large language model. It is understood that other context construction methods can also be used to achieve dialogue generation, and this is not limited here.

[0069] S106. Construct the context supplementation request and the pre-set vulnerability bypass case into a third dialogue context, and send the third dialogue context to the large language model for analysis to obtain the large model's judgment result.

[0070] Among them, context supplementation request refers to the additional code or business information required by the model; pre-built vulnerability bypass cases refer to various vulnerability exploitation methods collected in advance by the system; third dialogue context refers to the complete set of information used for in-depth vulnerability analysis; and large model judgment result represents the final analysis conclusion of the AI ​​model on the vulnerability.

[0071] Specifically, upon receiving a request for supplementary context from the model, the system needs to provide more detailed vulnerability analysis information. The system first extracts the requested context information from the contaminated data propagation chain, such as the implementation code of specific functions and data transformation logic. Then, it retrieves bypass cases related to the current vulnerability type from a pre-built vulnerability database, including attack vectors and bypass techniques in different scenarios. The system integrates this information into a predefined dialogue template to construct a new round of analysis context. The template contains explicit instruction labels, requiring the model to perform vulnerability assessment based on the complete context and provide detailed analytical justification and possible verification methods.

[0072] In some embodiments, the final vulnerability assessment process can be implemented in several ways: Optionally, the context information requested by the model is first extracted from the code and formatted, then relevant attack cases are searched from the vulnerability database, followed by the construction of a dialogue template containing complete analysis instructions, and finally, detailed analysis results from the model are obtained through multiple rounds of interaction; Optionally, a dynamic template engine is used to handle context supplementation requests, relevant implementation details are obtained from the code repository, and a complete analysis scenario is generated by combining it with a pre-built vulnerability knowledge base. A structured prompting strategy guides the model to output standardized assessment conclusions. It is understood that other analysis methods can also be used to implement vulnerability assessment, and this is not limited here.

[0073] In some embodiments, this step specifically includes the following steps:

[0074] Build a first dialogue template that includes instruction tags, code context tags, vulnerability bypass case tags, and analysis result tags.

[0075] The instruction tag standardizes the output format and analysis requirements of the large language model; the code context tag stores the code snippet to be analyzed and related information; the vulnerability bypass case tag contains historical vulnerability exploitation methods; and the analysis result tag records the model's analysis output. The dialogue template is organized in XML format, with the root tag being...<dialogue_context> . <instruction>Tags define the analysis task and output requirements, including instructions such as vulnerability type, analysis depth, and output format.<code_context> Tags store the code to be analyzed, including information such as function implementation and call relationships.<bypass_case> Tag storage-related vulnerability cases, including attack methods and bypass techniques.<analysis_result> The tag storage analysis results include information such as vulnerability assessment and risk level.

[0076] The analysis results of the second dialogue context are populated into the analysis result tags to obtain the second dialogue template; the context information of the target function is extracted from the contaminated data propagation chain based on the context supplementation request and populated into the code context tag; if relevant vulnerability bypass cases are retrieved from the preset vulnerability library according to the vulnerability type label, the relevant vulnerability bypass cases are populated into the vulnerability bypass case tag; the second dialogue template is sent to the large language model to obtain the first analysis result; based on the newly added context supplementation request in the first analysis result, supplementary context information is extracted from the contaminated data propagation chain, the code context tag is updated and sent to the large language model to obtain the second analysis result; the code context tag is continuously updated according to the context supplementation request in each round of analysis results and sent to the large language model until the large language model returns an analysis result that does not contain a context supplementation request as the large model judgment result.

[0077] The first round of analysis begins with basic vulnerability information. The system then writes the results of the previous round of analysis into...<analysis_result> Tags include preliminary vulnerability identification and risk assessment. The implementation code, calling environment, and parameter information of the target function are extracted from the contaminated data propagation chain and populated into...<code_context> Tags. Relevant cases are retrieved from a pre-built database based on vulnerability type and populated into...<bypass_case> Tags. This information is sent to the large language model via an API interface.

[0078] The second round of analysis is based on the model's supplementation requests. The system parses the context supplementation requests returned by the model, identifying the functions or code snippets that need supplementation. These functions are located from the contaminated data propagation chain, and their complete implementation code and call information are extracted. The extracted information is then used to update...<code_context> Set the tags, keeping other tags unchanged. Send the updated template back to the model.

[0079] Subsequent rounds follow the same process. The system continuously parses the model's supplementary requests, extracts relevant information from the propagation chain, and updates the dialogue template. The results of each round of analysis are recorded.<analysis_result> The analysis is complete when the model returns a result that no longer contains supplementary requests, and this result is taken as the final assessment. The entire process forms a complete analysis chain, with each round deepening the understanding of the vulnerabilities based on the previous round.

[0080] This iterative analysis ensures that the model acquires sufficient contextual information to make accurate vulnerability determinations. Simultaneously, standardized XML templates guarantee the standardization and traceability of the analysis process. The final assessment includes a complete analytical reasoning process and ample code evidence.

[0081] S107. Update the large model analysis results to the vulnerability details information.

[0082] Among them, the large model analysis results refer to the analysis conclusions of the AI ​​model on vulnerabilities, including complete information such as vulnerability existence determination, risk level assessment, exploitation condition analysis, and remediation suggestions; vulnerability details information refers to the complete vulnerability record stored in the IAST platform, including basic vulnerability information, pollution links, environmental information, and other data; update operation refers to the process of merging and associating the AI ​​analysis results with existing vulnerability information; and the analysis evidence chain refers to the complete reasoning process and related code evidence that support the analysis conclusions.

[0083] Specifically, once the system obtains the final assessment results from the large model, these analytical conclusions need to be integrated into the IAST platform's vulnerability management system. The system first parses the structured results output by the large model, extracting key conclusions and analytical basis. Then, this information is converted into a platform-supported data structure according to a predefined format, including fields such as vulnerability status, risk level, verification method, and remediation suggestions. Simultaneously, the system saves the complete analysis process, including key reasoning steps and relevant code snippets from multi-turn dialogues. This information is linked to the original vulnerability record, forming a complete vulnerability profile. For cases where the model determines a false positive, the system updates the vulnerability status accordingly and records the judgment basis, facilitating subsequent manual review and rule optimization.

[0084] In some embodiments, the updating of the assessment results can be achieved in several ways: Optionally, firstly, the XML-formatted assessment results output by the large model are parsed to extract key information such as vulnerability conclusions, risk levels, and analysis basis. Then, this information is standardized and mapped to database fields. Next, the status and details of the vulnerability records are updated. Finally, an assessment report containing the complete analysis process is generated and associated with the vulnerability records. Optionally, an event-driven approach is used to process the assessment results. The model output is received through a message queue, the results are structured and validated, the validated conclusions are updated to the distributed storage system, and a complete index of the analysis process is established in the search engine. It is understood that other data processing methods can also be used to store and associate the assessment results, which are not limited here.

[0085] The following provides a more detailed description of the process of the method provided in this implementation. Please refer to [link / reference]. Figure 2 This is another flowchart illustrating the AI-based interactive application security testing vulnerability assessment method in this application embodiment.

[0086] S201. Extract the function call sequence mentioned in the large model analysis results.

[0087] A function call sequence refers to the call chain of functions during program execution, including information such as function names, call order, and parameter passing. The large-scale model analysis results refer to the AI ​​model's analysis output of vulnerabilities, presented in a structured XML format. The extraction operation involves identifying and parsing complete function call information from the analysis result text. From the large-scale model's XML output, a parser is used to locate...<function_call> The parser extracts function call information from the tag blocks. Each function call record includes attributes such as function name, class name, parameter types, and return type. The parser constructs a complete call sequence according to the call order, while preserving the call relationships between functions. For example, in SQL injection vulnerability analysis, it might extract a call sequence like "parseRequest -> getParameter -> prepareStatement -> executeQuery".

[0088] S202. Retrieve the actual execution path of the function call sequence in the contaminated data propagation chain.

[0089] The contaminated data propagation chain stores the complete propagation process of user input data within the application, recording all involved function calls, data flows, and context information. The system first converts the extracted function call sequence into query expressions, including function names and call order. Then, path matching is performed in the contaminated chain database to find the actual execution paths containing these function calls. The matching process uses a graph traversal algorithm, starting from the contamination source node and searching forward along the data flow, checking each possible execution path. For each matched function call, the system verifies its context information, including class name, method signature, and call parameters, to ensure they match the sequence description. Finally, the complete matching path is returned, including runtime information such as execution time, thread ID, and parameter values.

[0090] S203. When a function call sequence in the large model analysis result is detected to be absent in the contaminated data propagation chain, the function call sequence is marked as AI illusion content.

[0091] AI illusions refer to function call descriptions in the output of a large model that do not match the actual code execution. When the search results indicate that a certain function call sequence does not exist in the actual execution, the system will mark the sequence as an AI illusion. The marking process includes: recording the name and location of the non-existent function call, marking the correct function call at the corresponding location in the actual code, and calculating the sequence matching degree (number of matched functions / total number of functions). For the marked content, the system generates a detailed mismatch description, including: the call sequence described by the model, the actual executed call sequence, the specific location of the mismatch, and the reason. This information is added to the original judgment results and identified using specific XML tags to facilitate subsequent analysis and processing. For example, if the model describes a non-existent database query function "executeSqlQuery", the system will mark it as an illusion and indicate that the "executeQuery" method was actually used.

[0092] S204. Perform a secondary analysis on the AI ​​hallucination content and submit the code snippets related to the AI ​​hallucination content to the large language model for confirmation.

[0093] AI illusion content refers to function call descriptions in the output of the large model that do not match the actual code execution; code snippets represent source code areas related to the illusion content, including function definitions, call contexts, and related business logic; secondary analysis refers to the process of comparing and verifying the illusion content with the actual code; large language model verification refers to having the model re-examine and evaluate the illusion content in a structured way. The system extracts the complete code context related to the illusion content from the contaminated data propagation chain, including function implementations, calling methods, and dependencies. This code is encapsulated using predefined XML templates, with explicit analysis instructions and constraints added. For example, for a misjudged SQL query function, a complete code snippet containing the actual query method, SQL construction process, and parameter processing is extracted. The encapsulated content is submitted to the large language model, requiring the model to re-analyze the function call relationships based on the specific code and point out the errors in the previous judgment.

[0094] S205. Construct a confidence scoring model based on the statistical features of AI illusion content. These statistical features include function call depth, code coverage, and context matching.

[0095] Function call depth refers to the number of levels in the function call chain; code coverage represents the proportion of code analyzed by the model to the actual executed code; context similarity measures the similarity between the model description and the actual code. The confidence scoring model calculates these features to obtain the final score. Function call depth is obtained by calculating the number of levels in the call stack, with deeper levels having greater weight. Code coverage is calculated by comparing the number of lines of code analyzed by the model with the number of lines of code actually executed. Context similarity uses a string similarity algorithm to calculate the degree of matching between the model description and the actual code. The weights of the three features are 0.3, 0.3, and 0.4, respectively, with the final score ranging from 0 to 1. The scoring model uses a linear weighting method: Score = 0.3 * (depth / maxDepth) + 0.3 * coverage + 0.4 * contextSimilarity. Where depth is the current call depth, maxDepth is the maximum call depth, coverage is the coverage rate, and contextSimilarity is the context similarity.

[0096] S206. When AI illusion content is detected, calculate the confidence score of the AI ​​illusion content.

[0097] The confidence score is a quantitative measure of the credibility of AI-generated hallucination content. For each function call sequence labeled as a hallucination, its statistical feature value is calculated. First, the function call depth is calculated by traversing the call stack to obtain the actual number of call levels. Then, the statistical model analyzes the number of lines of code involved and compares it with the actual number of lines of code executed to obtain the coverage. For context matching, the cosine similarity algorithm is used to calculate the similarity between the function call sequence described by the model and the function call sequence in the actual code. Substituting the three feature values ​​into the scoring formula: Score = 0.3 * (currentDepth / maxCallDepth) + 0.3 * (analyzedLines / totalLines) + 0.4 * cosineSimilarity(modelSequence, actualSequence). The closer the calculated score is to 1, the higher the credibility of the hallucination content. This score is recorded in the attributes of the hallucination content for subsequent processing decisions.

[0098] S207. Adjust the third dialogue context according to the confidence score, increase the sampling range of the code context when the confidence score is low, and add confidence constraint instructions to the dialogue template.

[0099] The confidence score is a numerical metric measuring the credibility of the AI ​​output, ranging from 0 to 1. The third dialogue context refers to the complete input information used for vulnerability analysis. The code context sampling range represents the range of extracted code snippets, including function definitions, call relationships, and related business logic. Confidence constraint instructions are specific XML tags that limit the range of model output. When the confidence score falls below the threshold of 0.6, the system expands the code sampling range. The original sampling only includes directly related function implementations; the expanded range also includes the context code that calls the function, the dependent functions that are called, and related configuration information. Simultaneously, additional information is added to the dialogue template.<confidence_constraint> The tag specifies that output must be based on actual code evidence, prohibiting the speculation of non-existent function calls. For example, for vulnerability analysis related to database operations, expanding the sampling scope would include the complete SQL construction process, parameter processing logic, and database configuration information.

[0100] S208. Resubmit the adjusted third dialogue context to the large language model.

[0101] The dialogue context is organized using a predefined XML structure, containing instruction, code context, and constraint sections. The adjusted dialogue context includes broader code samples and stricter output constraints. The system first annotates the extended code context according to a unified format, marking key function definitions, call relationships, and data flow processes. This information is then encapsulated into the dialogue template.<code_context> Within the tag. Constraint directives are added. <instruction>The label explicitly requires the model to analyze based on actual code. The complete dialogue context is submitted to the large language model via an API interface, including a complete chain of code evidence and output format requirements. The new analysis process verifies each function call to ensure the output matches the actual code.

[0102] S209. Detect data nodes that have undergone encoding conversion and encryption transformation in the data propagation chain of contamination data.

[0103] Encoding conversion refers to operations that convert data formats, such as Base64 encoding and URL encoding; encryption conversion refers to operations that encrypt data, such as MD5 encryption and AES encryption; data nodes represent processing positions in the process of corrupted data propagation. The system detects these conversion nodes through feature recognition. First, it maintains a predefined feature library of conversion functions, containing method signatures for common encoding functions (such as base64Encode and urlEncode) and encryption functions (such as MD5 and SHA1). Then, it traverses each node in the corrupted data propagation chain, checking whether the function corresponding to the node matches these features. For matching nodes, its function name, parameter configuration, and conversion type are recorded. For example, when the "Base64.encode(input)" method call is detected, the node is marked as a Base64 encoding conversion, and the encoding parameters are recorded. This conversion node information is used for subsequent data restoration analysis.

[0104] S210. Extract the transformation function and its parameter configuration of the data node, and construct a transformation mapping table based on the transformation function and its parameter configuration.

[0105] A transformation function refers to the specific method implemented to encode, encrypt, or otherwise process data. Parameter configuration includes the input parameters, configuration options, and execution environment information when the function is called. The transformation mapping table is a structured data structure that records the correspondence between the data transformation type, method, and parameters. The system extracts information from each identified transformation node, recording the complete function signature, calling method, and parameter values. For example, for a Base64 encoded node, parameters such as the encoding character set and padding method are extracted; for an AES encrypted node, configurations such as the key, encryption mode, and padding method are extracted. This information is organized into a key-value pair mapping table, where the key is the transformation type and function identifier, and the value is the parameter configuration object. The mapping table is stored in JSON format and contains fields such as `transform_type` (transformation type), `function_name` (function name), `parameters` (parameter list), `input_type` (input type), and `output_type` (output type).

[0106] S211. Use a transformation mapping table to restore the data in the contaminated data propagation chain to obtain the restored data propagation chain.

[0107] Based on the function information recorded in the transformation mapping table, the system reverse-engineers the data in the contaminated data propagation chain. First, it constructs a reverse processing function library containing decoding and decryption implementations for various encoding and encryption operations. Starting from the end of the contaminated chain, it traverses each transformation node in reverse. At each node, it looks up the corresponding transformation type and parameter configuration according to the mapping table and calls the appropriate reverse processing function. For encoding transformations, such as Base64 encoded nodes, it uses a Base64 decoding function for restoration; for encryption transformations, such as AES encrypted nodes, it uses the same key and configuration for decryption. The integrity of the data stream is maintained during processing, and the restoration result at each step is recorded. Finally, a new data propagation chain is generated, containing data in its original form for easy and intuitive analysis. For example, if the data at a certain node has undergone both Base64 encoding and URL encoding, the restoration process first performs URL decoding and then Base64 decoding.

[0108] S212. Construct a third problem description based on the restored data propagation chain.

[0109] The third problem description is a complete vulnerability analysis task description based on the restored data. The system uses a predefined template to construct the analysis problem, including the following elements: the source and content of the original input data, the data propagation path within the system, the specific operations of each processing node, and the execution point that ultimately leads to the vulnerability. The problem description uses a structured XML format.<input_data> The label describes the original input.<propagation_path> Tags describe the propagation path,<risk_point> The system also adds business scenario information about the data flow process to help understand the purpose and context of data processing. For example, for an SQL injection vulnerability, the problem description includes: the original parameter value input by the user, all processing steps the parameter goes through, the final SQL statement constructed, and the complete execution context. This problem description is used for subsequent in-depth analysis.

[0110] S213. Merge the analysis results obtained based on the third problem description with the original analysis results and update them in the vulnerability details information.

[0111] The analysis results refer to the vulnerability assessment output of the large language model, including vulnerability determination, risk level, and exploitation conditions. The original analysis results refer to the output of the initial model analysis. Vulnerability details are the complete vulnerability records stored in the IAST platform. The two analysis results are structurally merged. The system first extracts key fields from both results, including vulnerability type determination, risk level assessment, exploitation condition analysis, and remediation suggestions. A field-level merging strategy is adopted: for identical fields, results with higher confidence are retained; for complementary fields, the analysis content of both is retained. The merged results are formatted according to a unified data structure, containing complete content such as basic vulnerability information, detailed analysis process, verification methods, and remediation suggestions. For example, the original analysis might identify an SQL injection vulnerability, while the third analysis supplements the specific injection point and data processing details, forming a complete vulnerability profile after merging.

[0112] S214. Generate vulnerability verification test cases based on the large model analysis results.

[0113] Vulnerability verification test cases are test code or request sequences used to verify the existence of vulnerabilities. Based on the analysis results of the large model, the system extracts key characteristics of the vulnerability, including triggering conditions, injection points, and payload construction methods. The verification test case generation process includes the following steps: constructing HTTP request parameters, setting necessary header information and cookie values, and generating test data that conforms to the vulnerability characteristics. For different types of vulnerabilities, the system uses different templates to generate verification code. For example, for SQL injection vulnerabilities, it generates test statements containing special characters; for XSS vulnerabilities, it generates test input containing JavaScript code. Verification test cases contain complete request information, expected results, and verification logic, and are stored in a standard test case format for easy automated execution.

[0114] S215. Execute vulnerability verification test cases in the test environment of the target system under test, and obtain the execution results of the vulnerability verification test cases.

[0115] The testing environment refers to an independent system environment isolated from the production environment used for vulnerability verification. Execution results include runtime data such as request / response logs and exception information. The system first prepares the testing environment, including deploying the target application and configuring necessary services and data. Then, it executes verification test cases via an HTTP client or testing framework, sending constructed request data. The system captures the complete execution process, recording request / response status codes, response content, execution time, and other information. For database operation vulnerabilities, SQL execution logs are also recorded; for file operation vulnerabilities, file system changes are recorded. The system monitors the target application's runtime status in real time, including exception stack traces and error logs. All execution data is formatted and stored, containing complete information such as request details, response results, and runtime logs. This data is used to verify the existence and severity of the vulnerability.

[0116] S216. Update the vulnerability verification test results to the vulnerability details information.

[0117] The execution result of a vulnerability verification test case refers to all relevant data generated during the testing process, including HTTP request and response information, system operation logs, exception stack traces, database operation records, etc. Vulnerability details are complete vulnerability records stored in the IAST platform, including basic vulnerability attributes, pollution chain information, analysis results, etc. The update operation refers to the process of integrating the verification results into existing vulnerability records according to a predetermined format. Verification results contain data from multiple dimensions: HTTP-level request methods, URLs, parameters, response status codes, and response content; application-level exception information, system logs, and performance metrics; and data-level SQL execution records and file operation logs, etc.

[0118] For updating the verification execution results, the system first performs structured processing on the raw execution data. HTTP-related data is converted into standard request-response objects, containing complete request headers, request bodies, response headers, and response bodies. System logs and exception information are parsed into standardized log objects, including fields such as timestamp, log level, message content, and stack trace. Database operation records are formatted into SQL execution records, containing information such as the executed statement, the number of rows affected, and the execution time. This structured data is integrated into the vulnerability details record according to a predefined template and stored in XML format.<verification_result> Under the tag, use<http_data> Store HTTP-related information.<system_log> Store system logs,<exception_info> Store exception information.<database_operation> Store database operation records. For vulnerabilities that have been successfully verified, add additional...<vulnerability_confirmed> Tags are used to record the specific characteristics and conditions of successful verification. For example, for a verified SQL injection vulnerability, the tags record the successfully executed injection statement, the database response, and the scope of impact. This structured approach links the verification results with existing vulnerability analysis information, forming a complete chain of vulnerability evidence.

[0119] The interactive application security testing vulnerability assessment system in the embodiments of this invention is described below from the perspective of hardware processing. Please refer to [link / reference]. Figure 3 This is a schematic diagram of the physical device structure of an interactive application security testing vulnerability assessment system in this application embodiment.

[0120] It should be noted that, Figure 3 The structure of the interactive application security testing vulnerability assessment system shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0121] like Figure 3 As shown, the interactive application security testing vulnerability assessment system includes a Central Processing Unit (CPU) 301, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 302 or programs loaded from storage section 308 into Random Access Memory (RAM) 303, such as executing the methods described in the above embodiments. The RAM 303 also stores various programs and data required for system operation. The CPU 301, ROM 302, and RAM 303 are interconnected via a bus 304. An Input / Output (I / O) interface 305 is also connected to the bus 304.

[0122] The following components are connected to I / O interface 305: input section 306 including audio input devices, push-button switches, etc.; output section 307 including a liquid crystal display (LCD) and audio output devices, indicator lights, etc.; storage section 308 including a hard disk, etc.; and communication section 309 including a network interface card such as a LAN (Local Area Network) card, modem, etc. Communication section 309 performs communication processing via a network such as the Internet. Drive 310 is also connected to I / O interface 305 as needed. Removable media 311, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 310 as needed so that computer programs read from them can be installed into storage section 308 as needed.

[0123] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 309, and / or installed from removable medium 311. When the computer program is executed by central processing unit (CPU) 301, it performs the various functions defined in the present invention.

[0124] It should be noted that specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0125] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, program segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those shown in the drawings.

[0126] Specifically, the interactive application security testing vulnerability assessment system of this embodiment includes a processor and a memory. The memory stores a computer program. When the computer program is executed by the processor, it implements the AI-based interactive application security testing vulnerability assessment method provided in the above embodiment.

[0127] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the interactive application security testing vulnerability assessment system described in the above embodiments; or it may exist independently and not assembled into the interactive application security testing vulnerability assessment system. The storage medium carries one or more computer programs, which, when executed by a processor of the interactive application security testing vulnerability assessment system, cause the interactive application security testing vulnerability assessment system to implement the AI-based interactive application security testing vulnerability assessment method provided in the above embodiments.

[0128] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0129] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as meaning "if..." or "after..." or "in response to determining..." or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as meaning "if determining..." or "in response to determining..." or "when (the stated condition or event) is detected" or "in response to detecting (the stated condition or event)".

[0130] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.< / instruction> < / instruction>

Claims

1. A method for vulnerability assessment in AI-based interactive application security testing, characterized in that, The method, applied to an interactive application security testing vulnerability assessment system, includes: Instrument the key functions of the target system under test and collect execution environment information; Based on preset rules, user input data is identified in the Hypertext Transfer Protocol Request data in the execution environment information, and the propagation path of the user input data in the execution environment information is traced to obtain the contaminated data propagation chain, which includes vulnerability type markers. The execution environment information, the contaminated data propagation chain, the vulnerability type marker, and the function call stack affected by the contaminated data are encapsulated to obtain the vulnerability information package to be analyzed. The application system documentation and the vulnerability information packet to be analyzed are combined to construct a first dialogue context, and the first dialogue context is sent to the large language model to obtain the documentation summary. The description document summary is combined with the initial entry point information of the polluted data in the vulnerability information package to be analyzed to construct a second dialogue context, and the second dialogue context is sent to the large language model to obtain a context supplementation request; The context supplementation request and the pre-set vulnerability bypass case are constructed into a third dialogue context, and the third dialogue context is sent to the large language model for analysis to obtain the large model's judgment result; The results of the large model analysis will be updated in the vulnerability details information.

2. The method according to claim 1, characterized in that, The step of identifying user input data from the Hypertext Transfer Protocol Request data in the execution environment information based on preset rules, and tracing the propagation path of the user input data in the execution environment information to obtain a contaminated data propagation chain, wherein the contaminated data propagation chain includes a vulnerability type label, specifically including: The request parameters, request header information, and cookie information are extracted from the Hypertext Transfer Protocol request data as contamination source data, wherein the contamination data includes the contamination source data. By tracing the propagation process of the pollution source data in the target system under test, the function call stack through which the pollution source data passes is obtained; Collect the input parameter data, return value data, and class information of each function in the function call stack to construct function context information; The function context information is matched with preset vulnerability feature rules to obtain a risk function, and the vulnerability type is marked according to the risk function. The pollution source data, the function context information, and the risk function are assembled in the order of their calls to form the pollution data propagation chain.

3. The method according to claim 1, characterized in that, The step of constructing a third dialogue context from the context supplementation request and the pre-set vulnerability bypass case, and sending the third dialogue context to the large language model for analysis to obtain the large model's judgment result, specifically includes: Construct a first dialogue template that includes instruction tags, code context tags, vulnerability bypass case tags, and analysis result tags; The analysis results of the second dialogue context are filled into the analysis result tags to obtain the second dialogue template; Based on the context supplementation request, the context information of the target function is extracted from the contaminated data propagation chain and populated into the code context label; If relevant vulnerability bypass cases are retrieved from the preset vulnerability database based on the vulnerability type tag, the relevant vulnerability bypass cases are populated into the vulnerability bypass case tag; The second dialogue template is sent to the large language model to obtain the first analysis result; Based on the new context supplementation request in the first analysis result, supplementary context information is extracted from the contaminated data propagation chain, the code context label is updated, and then sent to the large language model to obtain the second analysis result; The code context labels are continuously updated based on the context supplementation requests in each round of analysis results and sent to the large language model until the large language model returns an analysis result that does not contain context supplementation requests, which is taken as the large model's judgment result.

4. The method according to claim 1, characterized in that, After the step of updating the vulnerability details information with the large model assessment results, the method further includes: Extract the function call sequence mentioned in the large model analysis results; Retrieve the actual execution path of the function call sequence in the contaminated data propagation chain; When it is detected that the function call sequence in the large model analysis result does not exist in the contaminated data propagation chain... The function call sequence is marked as AI hallucination content; The AI ​​hallucination content is analyzed a second time, and the code snippets related to the AI ​​hallucination content are submitted to the large language model for confirmation.

5. The method according to claim 4, characterized in that, After the step of updating the vulnerability details information with the large model assessment results, the method further includes: A confidence scoring model is constructed based on the statistical features of the AI ​​hallucination content, including function call depth, code coverage, and context matching degree. When the AI ​​hallucination content is detected, a confidence score for the AI ​​hallucination content is calculated; The third dialogue context is adjusted based on the confidence score. When the confidence score is low, the sampling range of the code context is increased, and a confidence constraint instruction is added to the dialogue template. The adjusted third dialogue context is then resubmitted to the large language model.

6. The method according to claim 1, characterized in that, After the step of updating the vulnerability details information with the large model assessment results, the method further includes: Detect data nodes in the contaminated data propagation chain that have undergone encoding conversion and encryption transformation; Extract the transformation function and its parameter configuration of the data node, and construct a transformation mapping table based on the transformation function and its parameter configuration; The data in the contaminated data propagation chain is restored using the transformation mapping table to obtain the restored data propagation chain. A third problem description is constructed based on the restored data propagation chain; The analysis results obtained based on the third problem description are merged with the original analysis results and updated in the vulnerability details information.

7. The method according to claim 6, characterized in that, After the step of updating the vulnerability details information with the large model assessment results, the method further includes: Vulnerability verification test cases are generated based on the analysis results of the large model. The vulnerability verification test case is executed in the test environment of the target system under test, and the execution result of the vulnerability verification test case is obtained; The execution result of the vulnerability verification test case is updated in the vulnerability details information.

8. An interactive application security testing vulnerability assessment system, characterized in that, The interactive application security testing vulnerability assessment system includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code includes computer instructions, and the one or more processors call the computer instructions to cause the interactive application security testing vulnerability assessment system to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that, When the instruction is executed on the interactive application security testing vulnerability assessment system, the interactive application security testing vulnerability assessment system performs the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, When the computer program product is run on the interactive application security testing vulnerability assessment system, the interactive application security testing vulnerability assessment system performs the method as described in any one of claims 1-7.

Images