Intelligent vulnerability detection method based on large model

Abstract

The application discloses a vulnerability risk intelligent detection method based on a large model, which firstly performs global static analysis on a source code set, constructs a complete calling graph and a data flow graph of a program, and forms a structured code knowledge graph; then, for the identified candidate vulnerability slices, accurate context retrieval and enhancement are performed based on the graph, key information such as a strong correlation chain and a data trace path of the vulnerability slice are converted into natural language descriptions understandable by a large language model, and prompt words are injected, so that the model is provided with missing global context information, and the deficiency of the model in complex code analysis capability is made up. In this way, the problem that the attention mechanism is invalid in long-distance code association is solved, and the accuracy and reliability of vulnerability detection are significantly improved.

Description

Technical Field

[0001] This application relates to the field of intelligent detection, and more specifically, to an intelligent detection method for vulnerabilities and potential risks based on a large model. Background Technology

[0002] In the current software development field, with the increasing complexity of systems and the continuous evolution of network attack methods, software vulnerabilities have become a serious challenge to network security. These vulnerabilities can lead to data leaks, system damage, and even severe economic losses and reputational damage. Traditional vulnerability detection methods, such as manual code auditing and rule-based static analysis, are often ineffective in dealing with modern large-scale, highly complex codebases, and generally suffer from low detection efficiency, high false positive rates, or, more critically, false negatives. Therefore, building an efficient and intelligent vulnerability detection solution to accurately identify and fix potential security flaws in the early stages of the software lifecycle is of paramount importance for improving software security resilience.

[0003] However, existing intelligent vulnerability detection solutions, especially those combined with Large Language Models (LLMs), still face significant technical bottlenecks. A core issue lies in the inherent input length (Token) limitation of LLMs, which forces the physical splitting of large project code. This splitting severely disrupts global context information such as cross-file data flow paths and function call chains, which are crucial for accurately identifying complex vulnerabilities. Furthermore, the "distance decay" effect of the self-attention mechanism in the Transformer model is a significant weakness. Although theoretically this mechanism can associate any two Tokens, in practice, the association strength between code segments that are far apart weakens significantly, causing the model to fail to effectively capture security vulnerabilities arising from long-distance code associations, resulting in false negatives. Moreover, LLMs typically treat code as a text sequence, leading to a flattened understanding of complex structured relationships such as inheritance and polymorphism in object-oriented programming, as well as logic such as higher-order function calls. This approach struggles to accurately construct and parse the control and data flow during program execution, unlike traditional static analysis tools. This limits the model's ability to accurately trace data and control flow paths within complex program structures. These technical challenges collectively constrain the accuracy and reliability of current intelligent vulnerability detection solutions, necessitating a new method to overcome these limitations.

[0004] Therefore, we look forward to an optimized intelligent detection method for vulnerabilities and potential risks based on large models. Summary of the Invention

[0005] To address the aforementioned technical problems, this application is proposed. Embodiments of this application provide an intelligent vulnerability detection method based on a large model. First, a global static analysis is performed on the source code set to construct a complete call graph and data flow graph, forming a structured code knowledge graph. Then, for identified candidate vulnerability slices, precise context retrieval and enhancement are performed based on these graphs. Key information such as call chains and data tracing paths strongly related to the vulnerability slices are transformed into natural language descriptions understandable by the large language model and injected into prompt words. This provides the model with missing global context information, compensating for its shortcomings in complex code analysis capabilities. In this way, the problem of attention mechanisms failing in long-distance code association is solved, significantly improving the accuracy and reliability of vulnerability detection.

[0006] According to one aspect of this application, an intelligent vulnerability detection method based on a large model is provided, comprising:

[0007] Get a collection of source code files;

[0008] Perform global static analysis on a collection of source code files to obtain call graphs and data flow graphs;

[0009] Candidate vulnerability slices are identified in the first source code file of the collection of source code files to obtain a list of candidate vulnerability slices;

[0010] Based on the call graph and data flow graph, the first candidate vulnerability slice in the candidate vulnerability slice list is subjected to graph-based context retrieval and enhancement to obtain the first enhanced vulnerability slice;

[0011] Deep context-aware vulnerability adjudication was performed on the first enhanced vulnerability slice to obtain the adjudication result.

[0012] Compared with existing technologies, this application provides an intelligent vulnerability detection method based on a large model. First, it performs a global static analysis of the source code set to construct a complete call graph and data flow graph, forming a structured code knowledge graph. Then, for identified candidate vulnerability slices, it performs precise context retrieval and enhancement based on these graphs. Key information such as call chains and data tracing paths strongly related to the vulnerability slices are transformed into natural language descriptions understandable by the large language model and injected into the prompt words. This provides the model with missing global context information, compensating for its shortcomings in complex code analysis. In this way, it solves the problem of attention mechanisms failing in long-distance code association, significantly improving the accuracy and reliability of vulnerability detection. Attached Figure Description

[0013] The above and other objects, features, and advantages of this application will become more apparent from the more detailed description of the embodiments of this application in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the embodiments of this application to explain this application and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0014] Figure 1 This is a flowchart of an intelligent vulnerability detection method based on a large model according to an embodiment of this application;

[0015] Figure 2 This is a schematic diagram of data flow for an intelligent vulnerability detection method based on a large model according to an embodiment of this application. Detailed Implementation

[0016] Hereinafter, exemplary embodiments according to this application will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments of this application. It should be understood that this application is not limited to the exemplary embodiments described herein.

[0017] As indicated in this application and claims, unless the context clearly indicates otherwise, the words "a," "an," "an," and / or "the" are not specifically singular and may include plural forms. Generally speaking, the terms "comprising" and "including" only indicate the inclusion of explicitly identified steps and elements, which do not constitute an exclusive list, and the method or apparatus may also include other steps or elements.

[0018] While this application makes various references to certain modules of the systems according to embodiments of this application, any number of different modules can be used and run on user terminals and / or servers. The modules described are merely illustrative, and different aspects of the systems and methods may use different modules.

[0019] Flowcharts are used in this application to illustrate the operations performed by the system according to embodiments of this application. It should be understood that the preceding or following operations are not necessarily performed in exact order. Instead, various steps can be processed in reverse order or simultaneously as needed. Furthermore, other operations can be added to these processes, or one or more steps can be removed from them.

[0020] Hereinafter, exemplary embodiments according to this application will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments of this application. It should be understood that this application is not limited to the exemplary embodiments described herein.

[0021] The technical solution of this application proposes an intelligent vulnerability detection method based on a large model. Figure 1 This is a flowchart of an intelligent vulnerability detection method based on a large model according to an embodiment of this application. Figure 2 This is a system architecture diagram of an intelligent vulnerability detection method based on a large model according to an embodiment of this application. Figure 1 and Figure 2 As shown, the intelligent vulnerability detection method based on a large model according to an embodiment of this application includes the following steps: S1, obtaining a set of source code files; S2, performing global static analysis on the set of source code files to obtain a call graph and a data flow graph; S3, identifying candidate vulnerability slices in a first source code file in the set of source code files to obtain a candidate vulnerability slice list; S4, based on the call graph and data flow graph, performing graph-based context retrieval and enhancement on the first candidate vulnerability slice in the candidate vulnerability slice list to obtain a first enhanced vulnerability slice; S5, performing deep context-aware vulnerability adjudication on the first enhanced vulnerability slice to obtain an adjudication result.

[0022] Specifically, S1 involves acquiring a set of source code files. It should be understood that source code files refer to text files written in a programming language (such as C, C++, Java, Python, JavaScript, etc.), capable of being read and understood by humans, and ultimately converted into executable programs or intermediate code by a compiler or interpreter. These files contain all the program's logic, algorithms, data structures, and business rules. They are the original form of the software and the direct object of static security analysis. The set of source code files is the only source of information for building a program semantic model, understanding program behavior, and tracing data and control flows. Without this foundation, the system cannot effectively identify potential vulnerabilities and security risks. Therefore, in the technical solution of this application, acquiring a set of source code files provides comprehensive and accurate input data for subsequent intelligent detection.

[0023] In practice, the first step is to identify and define the target scope. This is typically done through project configuration files, build system definitions, or manual specification. For example, a large software project may contain multiple sub-modules, and it is necessary to determine whether to analyze the entire project or focus only on specific high-risk modules.

[0024] Secondly, the source code is retrieved and copied. Once the target scope is determined, the system or operator will retrieve and copy the source code files using one or more of the following methods:

[0025] Pulling from a Version Control System (VCS): In modern software development, source code is typically stored in version control systems such as Git and SVN. The system can use VCS client commands to completely pull the latest version or a specified historical version of the target project's source code into the local analysis environment.

[0026] Copy from local file system or network share: If the source code is located in a specific directory on the local disk, or can be accessed via a network file system (NFS, SMB / CIFS), the system will copy all source code files and their directory structure to the specified analysis workspace using the file copy command.

[0027] Unzipping from an archive: Source code may be provided as a compressed file (such as .zip, .tar.gz). In this case, the system will first unzip the archive to restore the original source code files and directory structure;

[0028] Integration via automated scripts or APIs: In the continuous integration / continuous deployment (CI / CD) process, source code retrieval is often triggered by automated scripts, which may interact with code repository services (such as GitHub, GitLab, Bitbucket) via APIs to programmatically obtain source code;

[0029] Finally, the acquired content is verified and organized. After the source code files are copied to the local analysis environment, preliminary verification is typically performed, such as checking the number and size of files, or scanning known file types to ensure no critical files are missed. These files are then organized into a unified, easily accessible directory structure, forming the final collection of source code files, ready for subsequent global static analysis. This collection usually includes all relevant source files, header files, configuration files, and other resource files that may be referenced during compilation or interpretation.

[0030] Specifically, in step S2, a global static analysis is performed on the collection of source code files to obtain a call graph and a data flow graph. The call graph displays all possible function or method call relationships in the program, which is crucial for identifying vulnerability patterns across function calls, such as insecure API usage or privilege escalation paths. The data flow graph depicts how data propagates, transforms, and is used between program variables. This is invaluable for tracking the sources of contamination, propagation paths, and final sinks of sensitive data (such as user input and credential information), and is fundamental for detecting injection vulnerabilities (such as SQL injection and command injection) and information leaks. Without this global graph information, vulnerability detection would be limited to local code snippets, making it difficult to discover deep-seated vulnerabilities that span multiple functions or files and rely on complex data flows, resulting in severely insufficient accuracy and coverage. Therefore, in the technical solution of this application, a global static analysis is performed on the collection of source code files to reveal the mutual call relationships between functions and the flow paths of data within the program.

[0031] In practice, firstly, lexical / syntactic parsing is performed on each source code file in the set of source code files to obtain a set of abstract syntax trees. During this process, the source code files are first input into a lexer to obtain a stream of source code tokens. At this stage, the lexer (or scanner) reads the character sequences in the source code files and breaks them down into a series of meaningful minimum units, i.e., tokens. Each token has a type (such as keyword, identifier, operator, literal) and a value. For example, a line of code " "The code might be broken down by a lexical analyzer into tokens such as int (keyword), x (identifier), = (operator), 10 (integer constant). Then, the source code token stream is input into a syntactic analyzer to obtain an abstract syntax tree (AST). The syntactic analyzer analyzes the token stream according to the grammatical rules of the target programming language (usually defined by a context-free grammar), checking whether it conforms to the language's grammatical structure, and constructing the program's AST in the process. An AST is a hierarchical tree structure that represents the grammatical structure of the source code in an abstract way. Each node represents a construct in the source code, such as an expression, statement, declaration, or function definition, while child nodes represent the components of that construct. For example, for..." An AST may contain a variable declaration node whose child nodes include type (int), variable name (x), and initialization expression (10). By performing this process on each file in the collection of source code files, a collection of abstract syntax trees will eventually be obtained.

[0032] Next, intra-procedural analysis and local graph construction are performed on each abstract syntax tree (AST) in the set of ASTs to obtain the function node set, variable node set, and function local graph set. That is, after obtaining the AST set, the system performs a detailed analysis within each function or method's respective AST; this process is called intra-procedural analysis. At this stage, the analyzer traverses the AST, identifying key elements such as function definitions, function calls, variable declarations, assignment statements, and control flow statements (such as if, for, and while). Based on this information, the system constructs its local graph for each function. These local graphs typically include:

[0033] Function node set: Represents all identified functions or methods in the program;

[0034] Variable node set: Represents all variables declared and used within each function scope;

[0035] A collection of local graphs: These graphs may include control flow graphs (CFGs) and local data flow graphs. Control flow graphs depict the possible paths of statement execution within a function; local data flow graphs track the definition and use relationships of data between variables within a function. These local graphs provide refined foundational data for subsequent global analysis.

[0036] Furthermore, inter-function analysis and global relationship linking are performed on the function node sets, variable node sets, and function local graph sets of each abstract syntax tree to obtain the call edge set and data flow edge set. That is, after completing the internal analysis of all functions and constructing the local graph, inter-procedural analysis is performed. The focus of this stage is to analyze the interactions between functions and establish call and data transfer relationships across function boundaries. In this process, firstly, by analyzing function call statements, the call of one function to another is identified, thus establishing the call edge set. These edges connect the caller function nodes and the callee function nodes, together forming the preliminary structure of the program's call graph; simultaneously, by tracing parameter passing, return values, and the use of global variables, the flow of data from the output of one function to the input of another, or how data shared among multiple functions is modified and used, is identified, thus establishing the data flow edge set. These edges represent the paths of data transfer and transformation between functions and are a key component in constructing the global data flow graph;

[0037] Subsequently, a global graph aggregation is performed on the function node set, variable node set, call edge set, and data flow edge set to obtain the call graph and data flow graph. That is, the discrete information obtained from all previous analysis stages is integrated to form a complete global graph. In this process, firstly, all identified function node sets and the call edge set obtained from function analysis are aggregated to form a complete directed graph. In this graph, nodes represent functions in the program, and edges represent the call relationships between functions. This graph helps to understand the overall control flow of the program. Simultaneously, a data flow graph is constructed: the function node set, variable node set, and data flow edge set obtained from function analysis are aggregated to form a comprehensive data flow graph. In this graph, nodes can represent variables, expressions, or statements, and edges represent the process of data flowing from one point to another, including data definition, use, propagation, and transformation. It is worth noting that the call graph is a directed graph used to represent the call relationships between functions (or methods) in a program. The nodes in the graph represent each function in the program, and the directed edges represent the relationship of one function calling another. Analyzing call graphs can identify function call chains, recursive calls, and potential execution paths, which is crucial for understanding program control flow and discovering call stack-related vulnerabilities (such as resource exhaustion and incorrect privilege propagation). A data flow graph is a directed graph used to represent how data is defined, used, propagated, and transformed between variables in a program. Nodes in the graph can represent variables, expressions, basic blocks, or statements, while directed edges represent data flowing from one operation or location to another. Data flow graphs are a key tool for tracing sensitive data sources (Sources), propagating through program logic (Propagation), and ultimately reaching sensitive operations (Sinks), and are essential for detecting injection vulnerabilities, information leaks, and insecure data processing.

[0038] Specifically, in step S3, candidate vulnerability slice identification is performed on the first source code file in the set of source code files to obtain a candidate vulnerability slice list. It should be understood that in large software projects, the number and complexity of source code files are often enormous. To avoid wasting computational resources on vulnerability-free code regions while ensuring that no critical potential vulnerabilities are overlooked, an effective pre-screening mechanism is needed. Therefore, in the technical solution of this application, candidate vulnerability slice identification is performed on the first source code file in the set of source code files to initially identify code regions that exhibit structural or semantic characteristics similar to known vulnerability patterns. In this way, subsequent more time-consuming and complex graph-based context retrieval and enhancement, as well as deep context-aware vulnerability adjudication, can be focused on these screened candidate vulnerability slices with high risk potential, thereby greatly improving the efficiency and targeting of the overall detection process. Furthermore, by introducing a large language model, this step can capture more subtle semantic-level vulnerability clues that are difficult to discover through traditional pattern matching, providing high-quality input for subsequent refined analysis.

[0039] In practice, the first step is to match the first source code file against each pattern rule in the dangerous ingress point pattern library to obtain a list of raw candidate slices. During this process, the system loads a pre-built dangerous ingress point pattern library containing dangerous function calls, specific syntax structures, or API usage patterns related to known vulnerability types in various programming languages. These patterns typically point to functions, API calls, or language structures that could lead to security issues when receiving untrusted data. For example, in web applications, common dangerous ingress points might include: directly executing user-inputted system commands, unverified SQL queries, insecure reflection operations, or file path manipulation. The analyzer then traverses the entire contents of the first source code file, matching against each pattern rule in the pattern library. This matching can be based on regular expressions, AST traversal, or more complex graph pattern matching techniques. When a code snippet successfully matches a rule in the pattern library, that code snippet and its related information (such as file paths and precise line number ranges) are extracted as raw candidate slices. This process can broadly capture all possible risk points, and even if some matches are false alarms, they need to be included so that more refined screening can be carried out later.

[0040] Next, the code snippets, file paths, and line numbers of each original candidate slice in the original candidate slice list are input into a predefined prompt word template to obtain an analysis prompt list. After obtaining the initial original candidate slice list, in order to utilize the semantic understanding capabilities of the Large Language Model (LLM), this structured code information needs to be transformed into natural language input that the LLM can process. Specifically, in this process, the system prepares an input for each original candidate slice in the original candidate slice list. This input contains the code snippet of the slice (i.e., the specific code matched by the pattern), the file path to which the slice belongs, and the line number information of the slice in the file. This information is then embedded into a predefined prompt word template. This template is designed to provide the Large Language Model with sufficient contextual information and guide it to conduct a preliminary assessment of the potential security risks of the code snippet. For example, the prompt word template might be designed as: "Please evaluate whether the following code snippet has any vulnerabilities. File path: [file path], line number: [line number], code: [code snippet]". By filling the information of each original candidate slice into this template, the system will generate a corresponding analysis prompt to obtain an analysis prompt list;

[0041] Furthermore, the analysis hints and original candidate slices corresponding to each group in the analysis hint list and the original candidate slice list are input into the API interface of the large language model to obtain the candidate vulnerability slice list. It should be understood that the vulnerability characteristics of code are often not isolated syntactic structures, but involve complex logic, data flow, and specific contexts. Relying solely on pattern libraries for matching can easily generate a large number of false positives or false negatives. Therefore, in the technical solution of this application, the analysis hints and original candidate slices corresponding to each group in the analysis hint list and the original candidate slice list are input into the API interface of the large language model to perform a semantic-level in-depth evaluation of the original candidate slices through the large language model, determining whether they truly constitute a vulnerability risk. In this process, the large language model can go beyond simple keyword or syntactic matching, understanding the intent, function, and potential impact of the code segment in the entire program, thus providing a more accurate initial score and required context type. In addition, the score is adjusted by combining the risk of dangerous ingress points and local clarity, ensuring the comprehensiveness and reliability of the evaluation results and providing a more guiding basis for subsequent refined analysis.

[0042] Specifically, firstly, the analysis hints and original candidate slices are input into the API interface of the Large Language Model (LLM) to obtain an initial score and the required context type. During this process, the system iterates through each corresponding element in the list of analysis hints and the list of original candidate slices. For each pair, the system sends the analysis hints (a natural language description containing information such as code snippets, file paths, and line numbers) and the metadata of the corresponding original candidate slice (such as the code itself, file paths, and line numbers) as input through a pre-defined API interface to the LLM. Upon receiving this input, the LLM leverages its powerful code understanding capabilities and vulnerability knowledge acquired during training to perform deep semantic analysis on the input code snippets. It not only focuses on the surface structure of the code but also attempts to understand the code's intent, data flow, control logic, and potential security implications. Based on this analysis, the LLM returns two key pieces of information:

[0043] Initial Score: This is a quantified numerical value representing the initial confidence level or severity of the vulnerability risk of the original candidate slice by the large language model. This score is typically between 0 and 1, with a higher score indicating a greater likelihood that the model considers the slice to be a real vulnerability.

[0044] Required Context Type: This refers to the type of additional context information that the large language model deems necessary for more accurate determination of whether a code snippet is a vulnerability in subsequent in-depth analysis, based on its current understanding of the code. For example, if the code involves data manipulation, the model might suggest needing a data flow context to track the source and destination of data; if it involves function calls, it might suggest needing a call graph context to understand the function call chain; and if it involves branching logic, it might require a control flow context.

[0045] Next, the initial score is adjusted to obtain a preliminary score. To improve the accuracy and usability of the initial score returned by the large language model and make it more consistent with actual security risk assessments, the system will further calculate and correct the initial score according to a preset adjustment strategy, thereby obtaining a preliminary score. This adjustment process makes full use of prior knowledge extracted from the dangerous ingress point pattern library and local features of code snippets. Specifically, the initial score is adjusted using the following formula:

[0046]

[0047] in, This value quantifies the degree of security risk inherent in a specific hazardous function or operation, extracted from the hazardous entry point pattern library. For example, a function that directly executes system commands... The value may be high. For local clarity, this metric is used to evaluate the code readability, complexity, and ambiguity of the current original candidate slice. For example, the more concise and clear the logic, the better. A higher value indicates a clearer semantic meaning; conversely, a lower value indicates that the code is too complex and difficult to understand. Low value; introduction It can, to some extent, correct the biases that large language models may produce when processing complex or ambiguous codes. This is the initial score. Using this formula, the system can combine the intelligent judgment of a large language model with traditional, rule-based risk knowledge and local quality factors of the code itself, thereby obtaining a more comprehensive and accurate risk assessment result;

[0048] Then, the preliminary score, the required context type, and the metadata of the original candidate slice are merged to obtain the candidate vulnerability slice. That is, after obtaining the adjusted preliminary score and the required context type indicated by the large language model, the system organically integrates and encapsulates this newly generated information with the original metadata contained in the original candidate slice itself (e.g., the text content of the code snippet, the file path where the code snippet is located, the specific line number range, and any other structured information collected in the initial matching stage) to obtain a complete, structured data unit, namely the candidate vulnerability slice. This candidate vulnerability slice is a highly information-rich entity in the entire vulnerability detection process; it not only contains the original code context but also integrates the large language model's initial risk assessment (preliminary score) and the guiding information (required context type) needed for subsequent in-depth analysis.

[0049] Specifically, in step S4, based on the call graph and data flow graph, the first candidate vulnerability slice in the candidate vulnerability slice list is subjected to graph-based context retrieval and enhancement to obtain the first enhanced vulnerability slice. It should be understood that many vulnerabilities do not exist in isolation at a single line of code, but involve data transfer and control flow across functions and files. For example, the real risk of an SQL injection vulnerability lies in the fact that user input (source) reaches the database query (injection point) without sufficient purification. Simply seeing the code snippet at the injection point, without knowing the source of the data and the intermediate transformation process, makes it impossible to accurately determine whether a vulnerability exists or its severity. Therefore, in the technical solution of this application, by utilizing the global call graph and data flow graph generated in the preceding steps, the system can trace the source of the data flow, the intermediate purification or contamination process, and how the control flow leads to the execution of the slice. In this way, a complete attack path can be formed from the insecure data source to the dangerous injection point.

[0050] In practice, firstly, based on the file path and line number of the first candidate vulnerability slice, slice location and graph anchor mapping are performed in the data flow graph to obtain anchor nodes. During this process, the system extracts the file path and line number information contained in the first candidate vulnerability slice. Using this information, the analyzer searches for the node that precisely corresponds to the code snippet in the previously constructed data flow graph. This node typically represents a key operation point or variable definition / usage point in the candidate vulnerability slice, such as a call point of a dangerous function or an assignment point of a sensitive variable. Once found, this specific graph node is identified as the anchor node. The anchor node is the starting point for subsequent graph traversal, anchoring the context retrieval work to the specific risk location in the code.

[0051] Next, the required context type of the first candidate vulnerability slice is parsed to obtain traversal instructions. That is, after obtaining the anchor node, the system further analyzes the required context type (RequiredContextType) provided by the large language model in the first candidate vulnerability slice. This type specifies the context information needed to evaluate the first candidate slice (e.g., ...). or Based on the required context type obtained from the parsing, the system generates corresponding traversal instructions. These instructions define the strategy for graph traversal in the call graph and data flow graph; for example, if it is... The instruction might be "reverse trace data definition"; if it is The instruction might be "reverse traverse the caller chain"; if it is The instruction might be "proceed along the control flow path." Traversal instructions are crucial for guiding subsequent graph traversal operations, ensuring that only the contextual information most relevant to the current vulnerability assessment is extracted.

[0052] Then, based on anchor nodes and traversal instructions, reverse graph traversal and path collection are performed in the call graph and data flow graph to obtain the original path set. That is, starting from the anchor node and following the traversal instructions generated in the second sub-step, reverse graph traversal is performed in the global call graph and data flow graph. The purpose of reverse traversal is to trace back from potential danger points (inflow points) to their source to understand the complete lifecycle of data or the complete call chain of a function. During the traversal, the system collects all paths that meet the conditions of the traversal instructions. These paths include:

[0053] Data flow path: Tracing the definition point of the data backward from the anchor node, through the intermediate variable assignments, function parameter passing, return values, etc., until the initial source of the data;

[0054] Control flow path: Tracing back the control flow conditions and decision points that lead to the execution of anchor nodes;

[0055] Call chain path: Tracing the caller chain of the function containing the anchor node in the call graph in reverse;

[0056] All these collected paths together constitute the original path set, which contains all possible program execution or data flow paths traced back from the risk point, and serves as the basis for subsequent refinement and screening.

[0057] Subsequently, path pruning and key evidence chain filtering are performed on the original path set to obtain the critical path. It should be understood that in complex code environments, simple graph traversal may generate a large number of paths, including many redundant, irrelevant, or even sanitized paths. Existing data flow path risk assessment mechanisms treat the data channel as a static process where risk can only decay when calculating path scores. Their scoring models primarily rely on the initial risk at the source and perform simple linear reduction through path length and sanitization functions. This model has a fundamental flaw: it ignores the non-linear transformation or amplification effect of specific code operations within the path, i.e., risk transformation operators. In real-world code security scenarios, some intermediate code operations are not vulnerability injection points themselves, but rather key catalysts for risk escalation. For example, formatting external input with SQL query templates can drastically amplify the risk of injection vulnerabilities. The original mechanism cannot effectively distinguish between such risk-amplifying paths and paths flowing through benign operations (such as integer conversions) because it lacks a mathematical model that can dynamically measure the risk evolution of data as it flows through different code structures. This approach of limiting scoring to a "dot-product" model rather than a "path-dependent" continuous model may result in under-scoring of attack paths that consist of a series of clever, not inherently vulnerable, but dangerous cumulative effects, leading to missed detections.

[0058] To address the aforementioned shortcomings, a risk potential field model based on path integrals is introduced. Specifically, by constructing a dynamic risk potential field model, calculating cumulative risk using path integrals, and performing risk density normalization and Softmax decision-making, the model accurately captures the cumulative risk at each step of the path. Finally, it filters out the evidence chains that best reflect the nature of the vulnerability and have the greatest attack potential from the original path set, thereby significantly reducing false positives and providing security analysts with richer and more accurate decision-making information.

[0059] In this process, firstly, a risk potential field is constructed based on the data flow graph and the operational risk knowledge base. To quantify the risk correlation and environmental impact of each operational node in the codebase, a mathematical model reflecting the global risk distribution needs to be built. Assessing the risk of a single operation in isolation is insufficient, as a high-risk operation significantly increases the potential threat to its neighboring code regions. Specifically, firstly, based on an operational risk knowledge base storing the inherent risk coefficients of various code operations, a basic potential value is assigned to each node in the data flow graph. This knowledge base predefines the inherent risk levels of different types of code operations (such as system calls, file read / write, database operations, string concatenation, cleansing functions, etc.). For example, an API call that directly executes an external command may have a high basic potential, while a simple mathematical operation may have a low basic potential. Next, to simulate the transmission and mutual influence of risks in the code structure, a method inspired by the Laplace operator is used to iteratively update the final risk potential of each node; the final potential of a node is the weighted sum of its basic potential and the differences in potential between it and all its neighboring nodes. This process continues until the entire risk potential field converges and stabilizes. The calculation process can be expressed by the formula as follows:

[0060]

[0061] in, Representative node The final risk potential value; It is a node The fundamental potential energy comes from the operational risk knowledge base; It is a coefficient that controls the impact of risk propagation among neighboring nodes; It is a node The set consisting of all adjacent nodes; Adjacent nodes The risk potential value. In this way, a global, interconnected risk view is established. After execution, the data flow graph is no longer a collection of discrete nodes, but a continuous, differentiable risk potential field. Thus, high-risk code (such as eval calls) will act like a high-potential energy source, naturally raising the risk potential of its surrounding code nodes, so that any data path flowing through this area will be given higher initial attention.

[0062] Next, based on the risk potential field, risk accumulation calculations based on path integrals are performed on each original path in the original path set to obtain a path score set. It should be understood that, in order to accurately capture the risk amplification or reduction effect brought about by intermediate risk transformation operators as data flows through a path, a computational paradigm capable of accumulating risk changes at each step along the path is needed to replace the static, decay-only risk model in the original mechanism. Specifically, the system analyzes each path in the original path set. The final score of a data flow path is defined as the sum of two parts: the initial risk potential energy at the path's starting point, and the risk work accumulated as data flows along this path. This work is obtained by calculating the line integral of the gradient field of the risk potential field along the path. The gradient field indicates the direction and rate of the fastest risk growth. The process can be expressed by the formula:

[0063]

[0064] in, It is a path The final cumulative risk score; It is the starting point of the path. The initial risk potential energy; Indicates along the path The line integral; It is a risk field The gradient of represents the vector field of the rate of change of risk; This is the differential displacement vector along the path. According to the gradient theorem, this integral value equals the potential energy difference between the path's endpoint and starting point. This achieves a dynamic and continuous assessment of path risk. After execution, the path scoring model evolves from a static dot-product model to a dynamic path-dependent model. Correspondingly, when data flows to a node with higher risk potential energy (e.g., from variable assignment to unsafe string concatenation), its path direction aligns with the risk gradient direction, the integral term is positive, and the risk score increases accordingly, thus successfully quantifying the amplification effect of risk. Conversely, when data flows through a cleansing function (a low potential energy point), the integral term is negative, and the risk score decreases. This process perfectly solves the core flaw of the original mechanism.

[0065] Subsequently, risk density normalization and critical path decision-making are performed on each original path in the path score set to obtain the critical path. It should be understood that directly comparing the cumulative risk scores of paths of different lengths may be biased, as longer paths have a greater chance of accumulating risk. Furthermore, in complex attack scenarios, multiple equally dangerous paths may exist, and using a simple maximum value method would lose important information. Therefore, to achieve fair comparison, the concept of risk density is introduced, which is the cumulative risk score of a path divided by its length, representing the average risk per unit path length. Then, instead of using a rigid maximum value selection, the Softmax function from probability theory is used to calculate the probability that each path will become a critical path. The Softmax function can transform a set of risk density values ​​into a probability distribution, highlighting paths with high risk density while retaining information about other suboptimal paths. This process can be expressed by the formula:

[0066]

[0067] in, It is a path The probability of being selected as the critical path; It is a path Risk density; It is the cumulative risk score of the path; It is the length of the path; This is a temperature parameter used to adjust the sharpness of the probability distribution. Ultimately, the path with the highest probability is selected as the critical path, or a candidate list sorted by probability is provided.

[0068] In this way, the evaluation criterion shifts from total risk to risk efficiency, avoiding bias towards long paths. The effect is that, through the Softmax function, this mechanism can not only identify the most dangerous paths but also reveal other potential, secondary attack paths in probabilistic terms. This provides security analysts with richer decision-making information, enabling them to better address complex security scenarios that may involve multiple parallel attack vectors.

[0069] Furthermore, the first candidate vulnerability slice is enhanced based on the critical path to obtain the first enhanced vulnerability slice. That is, after determining the critical path, the system aggregates information from the most representative risk evidence chains (or chains of evidence) along this path into the first candidate vulnerability slice. This information may include code snippets along the critical path, involved variable values, function call sequences, and related control flow conditions. In this way, the first candidate vulnerability slice is enhanced, ultimately resulting in the first enhanced vulnerability slice. This enhanced slice not only contains the original potentially risky code snippets but also carries the most convincing contextual evidence chains traced from the global call graph and data flow graph. This enhanced slice contains all the information needed for the final deep decision and forms the basis for subsequent accurate vulnerability assessment by the large language model.

[0070] Specifically, in step S5, a deep context-aware vulnerability assessment is performed on the first enhanced vulnerability slice to obtain the assessment result. Although the preceding steps have identified candidate vulnerability slices, provided preliminary scores, and enhanced the contextual information through graphing, the final vulnerability judgment still requires a mechanism capable of integrating all information and performing advanced reasoning. In the technical solution of this application, the superior natural language understanding and code semantic reasoning capabilities of a large language model are utilized, combined with the rich contextual information already obtained, to perform a comprehensive, deep-aware evaluation of the first enhanced vulnerability slice. In this way, the large language model can more accurately identify the specific type of vulnerability (such as SQL injection, XSS, command injection, etc.) and its potential severity based on contextual information.

[0071] In practice, the first step is to embed the code snippet and context description of the first enhanced vulnerability slice into a prompt word template for in-depth adjudication to obtain the final prompt word. During this process, the system fully utilizes all the information contained in the first enhanced vulnerability slice. This enhanced slice not only contains the original code snippet, file path, and line number, but more importantly, it includes a detailed context description of the critical paths selected through graph analysis. These context descriptions may include the source of the data flow, intermediate variable transformations, function call sequences, and related control flow conditions, all in structured or natural language form. The system then embeds this key information into a prompt word template for in-depth adjudication. This template is specifically designed to guide the large language model in making the final vulnerability judgment, explicitly requiring the model to synthesize all provided information and provide a conclusion regarding the existence, type, severity, and possible exploitation methods of the vulnerability. For example, the template might be designed as follows: "Based on the following code snippet and its complete contextual data flow and control flow information, determine whether a security vulnerability exists, and provide the vulnerability type, severity, and explanation. Code: [Code snippet]. Contextual description: [Detailed contextual evidence chain]. By filling this template with the content of the first enhanced vulnerability slice, the system will generate a final prompt word, which is highly customized and contains all the semantic information required for deep adjudication by a large language model;

[0072] Next, the final vulnerability warning is input into the Large Language Model (LLM) to obtain the raw LLM response. In other words, after generating a highly detailed and structured final vulnerability warning, the system sends it to the powerful Large Language Model (LLM) via a pre-defined API interface. Upon receiving the final vulnerability warning, the LLM leverages its advanced reasoning capabilities, trained on massive amounts of code and security knowledge, to perform a comprehensive analysis of the code snippet and its detailed context. Unlike the initial assessment, the model now possesses a complete chain of vulnerability evidence, enabling deeper semantic understanding and logical judgment. Based on its analysis results, the LLM generates a raw LLM response, typically in natural language text format, which may include a description of the vulnerability, possible vulnerability types, risk assessment, explanatory statements, and even suggested remediation solutions.

[0073] Then, the original LLM response and preliminary score are subjected to structured adjudication parsing and credibility fusion to obtain the adjudication result. To transform the natural language response returned by the large language model into a standardized vulnerability report format that the system can process, and to improve the overall credibility of the adjudication result, the system performs structured parsing and multi-source information fusion. In this process, firstly, the system performs natural language processing and information extraction on the original LLM response. This typically involves techniques such as pattern matching, entity recognition, and sentiment analysis, aiming to identify key information from unstructured text, such as vulnerability type (e.g., SQLInjection, XSS), vulnerability description, affected code location, and suggested remediation measures. The goal of parsing is to convert it into a standardized, machine-readable format; while parsing the original LLM response, the system fuses the preliminary score obtained in the previous steps with the confidence level or evaluation result implicit in the current adjudication by the large language model. The preliminary score represents a comprehensive consideration of traditional pattern matching and the first LLM evaluation, while the original LLM response represents a deep evaluation based on enhanced context. Fusion strategies may include weighted averaging, Bayesian fusion, or other multi-sensor information fusion algorithms. For example, if the initial score is high, and the LLM's in-depth decision also leans towards a vulnerability, the final confidence level will be higher. Conversely, if the initial score is high but the LLM, after in-depth analysis, deems it not a vulnerability (e.g., finding cleanup), the confidence level of the decision may be lowered, or even classified as not a vulnerability. Through structured decision parsing and confidence fusion, the system ultimately obtains a unified, high-confidence decision result. This decision result is typically presented in a structured data format (such as JSON or XML), containing information such as the explicit vulnerability type, risk level, detailed description, affected code location, remediation recommendations, and decision confidence level. This result is the final output of the entire vulnerability detection process and can be directly used for vulnerability reporting or security remediation workflows.

[0074] In summary, the intelligent vulnerability detection method based on a large model, according to the embodiments of this application, is explained. First, a global static analysis is performed on the source code set to construct a complete call graph and data flow graph, forming a structured code knowledge graph. Then, for the identified candidate vulnerability slices, precise context retrieval and enhancement are performed based on these graphs. Key information such as call chains and data tracing paths strongly related to the vulnerability slices are transformed into natural language descriptions understandable by the large language model and injected into the prompt words. This provides the model with missing global context information, compensating for its shortcomings in complex code analysis. In this way, the problem of attention mechanisms failing in long-distance code association is solved, significantly improving the accuracy and reliability of vulnerability detection.

[0075] The various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for intelligent detection of vulnerabilities and potential risks based on a large model, characterized in that, include: Get a collection of source code files; Perform global static analysis on a collection of source code files to obtain call graphs and data flow graphs; Candidate vulnerability slices are identified in the first source code file of the collection of source code files to obtain a list of candidate vulnerability slices; Based on the call graph and data flow graph, the first candidate vulnerability slice in the candidate vulnerability slice list is subjected to graph-based context retrieval and enhancement to obtain the first enhanced vulnerability slice; Deep context-aware vulnerability adjudication is performed on the first enhanced vulnerability slice to obtain the adjudication result; Candidate vulnerability slices are identified in the first source code file of the collection of source code files to obtain a list of candidate vulnerability slices, including: Based on each pattern rule in the dangerous ingress point pattern library, the first source code file is matched to obtain the original candidate slice list; Input the code snippet, file path and line number of each original candidate slice in the original candidate slice list into a predefined prompt word template to obtain an analysis prompt list; Input the corresponding analysis hints and original candidate slices for each group from the analysis hint list and the original candidate slice list into the API interface of the large language model to obtain the candidate vulnerability slice list; Based on the call graph and data flow graph, the first candidate vulnerability slice in the candidate vulnerability slice list is subjected to graph-based context retrieval and enhancement to obtain the first enhanced vulnerability slice, including: Based on the file path and line number of the first candidate vulnerability slice, slice location and graph anchor point mapping are performed in the data flow graph to obtain anchor point nodes; The required context type of the first candidate vulnerability slice is parsed to obtain the traversal instructions; Based on anchor nodes and traversal instructions, reverse graph traversal and path collection are performed on the call graph and data flow graph to obtain the original path set; The original path set is pruned and key evidence chains are filtered to obtain the critical path; The first candidate vulnerability slice is enhanced by performing slice enhancement based on the critical path to obtain the first enhanced vulnerability slice.

2. The intelligent vulnerability detection method based on a large model according to claim 1, characterized in that, A global static analysis of the collection of source code files is performed to obtain the call graph and data flow graph, including: Perform source code lexical / syntactic parsing on each source code file in the set of source code files to obtain a set of abstract syntax trees; Functional intra-function analysis and local graph construction are performed on each abstract syntax tree in the set of abstract syntax trees to obtain the function node set, variable node set, and function local graph set; We perform inter-function analysis and global relation linking on the function node set, variable node set, and function local graph set of each abstract syntax tree to obtain the call edge set and data flow edge set; Global graph aggregation is performed on the function node set, variable node set, call edge set, and data flow edge set to obtain the call graph and data flow graph.

3. The intelligent vulnerability detection method based on a large model according to claim 2, characterized in that, Perform source code lexical / syntactic parsing on each source code file in the set of source code files to obtain a set of abstract syntax trees, including: Input the source code file into the lexical analyzer to obtain the source code lexical stream; The source code lexical stream is input into the parser to obtain an abstract syntax tree.

4. The intelligent vulnerability detection method based on a large model according to claim 3, characterized in that, Input the corresponding analysis hints and original candidate slices from the analysis hint list and the original candidate slice list into the API interface of the large language model to obtain the candidate vulnerability slice list, including: Input the analysis tips and raw candidate slices into the API interface of the large language model to obtain the initial score and the desired context type; Adjust the initial score to obtain a preliminary score; The initial score, required context type, and metadata of the original candidate slice are combined to obtain the candidate vulnerability slice.

5. The intelligent vulnerability detection method based on a large model according to claim 4, characterized in that, Adjusting the initial score to obtain a preliminary score includes: adjusting the initial score using the following formula, wherein the formula is: in, To extract hazardous inflow point risks from the hazardous inflow point pattern library, For local clarity, The initial score.

6. The intelligent vulnerability detection method based on a large model according to claim 5, characterized in that, The original path set is pruned and key evidence chains are filtered to obtain the critical path, including: Construct a risk potential field based on data flow diagrams and operational risk knowledge base; Based on the risk potential field, risk accumulation calculation based on path integral is performed on each original path in the original path set to obtain the path score set. The critical path is obtained by performing risk density normalization and critical path decision on each original path in the path score set.

7. The intelligent vulnerability detection method based on a large model according to claim 4, characterized in that, Deep context-aware vulnerability adjudication is performed on the first enhanced vulnerability slice to obtain the adjudication results, including: The code snippet and context description of the first enhanced vulnerability slice are embedded into the prompt word template for in-depth adjudication to obtain the final prompt word; The final prompt word is input into the large language model to obtain the original LLM response; The original LLM response and preliminary score are subjected to structured adjudication parsing and credibility fusion to obtain the adjudication result.

Images