Vulnerability hidden danger intelligent detection method based on large model

Abstract

The invention discloses a vulnerability hidden danger intelligent detection method based on a large model, and the method comprises the steps: firstly carrying out the global static analysis of a source code set, constructing a complete call graph and a complete data flow graph of a program, and forming a structured code knowledge graph; and then, aiming at the identified candidate vulnerability slices, based on the maps, carrying out accurate context retrieval and enhancement, converting key information such as a call chain and a data traceability path which are strongly related to the vulnerability slices into natural language description which can be understood by a large language model, and injecting the natural language description into cue words, so that missing global context information is provided for the model. And the defect of complex code analysis capability is overcome. In this way, the problem that an attention mechanism loses efficacy in remote code association is solved, and the accuracy and reliability of vulnerability detection are remarkably improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of intelligent detection, and more specifically, to a vulnerability and hidden danger intelligent detection method based on a large model. BACKGROUND

[0002] In the current field of software development, 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 breaches, system destruction, and even serious economic losses and reputation damage. Traditional vulnerability detection methods, such as manual code auditing and rule-based static analysis, often struggle to effectively deal with modern large-scale and highly complex code bases, with widespread low detection efficiency, high false positive rate, or more critical false negative risks. Therefore, building an efficient and intelligent vulnerability detection scheme to accurately identify and repair potential security defects in the early stages of the software life cycle is of great significance to improving software security resilience.

[0003] However, some existing intelligent vulnerability detection schemes, especially those combined with large language models (LLM), still face significant technical bottlenecks. One core problem lies in the inherent input length (Token) limitation of large language models, which forces physical splitting of large project codes when processing them. This splitting behavior severely damages global context information such as cross-file data flow paths and function call chains, which are crucial for accurately judging complex vulnerabilities. In addition, the "distance decay" effect of the self-attention mechanism in the Transformer model is also a weakness that cannot be ignored. Although this mechanism can theoretically link any two Tokens, in practical applications, the association strength between code fragments that are far apart will significantly weaken, causing the model to miss potential security risks due to long-distance code associations, resulting in false negatives. Furthermore, large language models typically treat code as a sequence of text for processing, which makes it difficult to accurately understand structured relationships such as inheritance, polymorphism, and high-order function calls in object-oriented programming. This processing approach limits the model's ability to accurately track data and control flow transmission paths in complex program structures, as traditional static analysis tools can do. The above technical difficulties collectively constrain the accuracy and reliability of current intelligent vulnerability detection schemes, necessitating a new method that can overcome these limitations.

[0004] Therefore, an optimized vulnerability and hidden danger intelligent detection method based on a large model is expected. SUMMARY

[0005] To solve the above technical problems, the present application is proposed. Embodiments of the present application provide a large model-based vulnerability risk intelligent detection method, which first performs global static analysis on a source code set, constructs a complete call graph and 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 strong correlation call chain and data tracing path of the vulnerability slice is converted into natural language description understandable by a large language model, and prompt words are injected, so as to provide missing global context information for the model and make up for the deficiency of the model in complex code analysis capability. In this way, the problem of invalid attention mechanism in long-distance code association is solved, and the accuracy and reliability of vulnerability detection are significantly improved.

[0006] According to an aspect of the present application, a large model-based vulnerability risk intelligent detection method is provided, which includes: obtaining a set of source code files; performing global static analysis on the set of source code files to obtain a call graph and a data flow graph; performing candidate vulnerability slice identification on a first source code file in the set of source code files to obtain a candidate vulnerability slice list; based on the call graph and the data flow graph, performing graph-based context retrieval and enhancement on a first candidate vulnerability slice in the candidate vulnerability slice list to obtain a first enhanced vulnerability slice; performing deep context-aware vulnerability adjudication on the first enhanced vulnerability slice to obtain an adjudication result.

[0007] Compared with the prior art, the large model-based vulnerability risk intelligent detection method provided by the present application first performs global static analysis on a source code set, constructs a complete call graph and 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 strong correlation call chain and data tracing path of the vulnerability slice is converted into natural language description understandable by a large language model, and prompt words are injected, so as to provide missing global context information for the model and make up for the deficiency of the model in complex code analysis capability. In this way, the problem of invalid attention mechanism in long-distance code association is solved, and the accuracy and reliability of vulnerability detection are significantly improved. BRIEF DESCRIPTION OF DRAWINGS

[0008] The above and other objects, features and advantages of the present application will become more apparent from the following detailed description when taken in conjunction with the accompanying drawings in which:

[0009] Figure 1 A flow chart of a large model-based vulnerability risk intelligent detection method according to an embodiment of the present application; Figure 2 A data flow schematic diagram of a large model-based vulnerability risk intelligent detection method according to an embodiment of the present application. DETAILED DESCRIPTION

[0010] Hereinafter, example embodiments according to the present application will be described in detail with reference to the accompanying drawings. It should be understood that the exemplary embodiments described herein are only a part of the embodiments of the present application, and are not the whole embodiments of the present application, and it should be understood that the present application is not limited by the example embodiments described herein.

[0011] As shown in the present application and claims, unless the context clearly indicates otherwise, the words "one", "an", "a", and / or "the" do not mean to specify a single number, but can include a plurality or a whole. Generally, the terms "comprise" and "include" only indicate the inclusion of the steps and elements explicitly identified, and these steps and elements do not constitute an exclusive list, and the method or device can also include other steps or elements.

[0012] Although the present application makes various references to certain modules in the system according to the embodiments of the present application, however, any number of different modules can be used and run on the user terminal and / or server. The modules are only illustrative, and different aspects of the system and method can use different modules.

[0013] Flowcharts are used in the present application to illustrate the operations performed by the system according to the embodiments of the present application. It should be understood that the preceding or following operations are not necessarily performed in sequence. On the contrary, various steps can be processed in reverse order or simultaneously, as needed. Meanwhile, other operations can be added to these processes, or one or more steps of operations can be removed from these processes.

[0014] Hereinafter, example embodiments according to the present application will be described in detail with reference to the accompanying drawings. It should be understood that the exemplary embodiments described herein are only a part of the embodiments of the present application, and are not the whole embodiments of the present application, and it should be understood that the present application is not limited by the example embodiments described herein.

[0015] In the technical solution of the present application, an intelligent vulnerability detection method based on a large model is proposed. Figure 1 A flowchart of the intelligent vulnerability detection method based on a large model according to the embodiment of the present application. Figure 2 A system architecture diagram of the intelligent vulnerability detection method based on a large model according to the embodiment of the present application. As shown in Figure 1 and Figure 2 The intelligent vulnerability detection method based on a large model according to the embodiment of the present 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, performing candidate vulnerability slice identification on 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 the data flow graph, performing graph-based context retrieval and enhancement on a 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.

[0016] In particular, the S1, obtaining a set of source code files. It should be understood that the source code file refers to a text file written in a certain programming language (such as C, C++, Java, Python, JavaScript, etc.), which can be read and understood by humans, and ultimately converted into an executable program or intermediate code by a compiler or interpreter. These files contain all the logic, algorithms, data structures, and business rules of the program. They are the original form of software and the direct object of static security analysis. The source code file set is the only source of information for building program semantic models, understanding program behavior, and tracking data flow and control flow. Without this foundation, the system cannot effectively identify potential vulnerabilities and security risks. Therefore, in the technical solution of the present application, a set of source code files is obtained to provide comprehensive and accurate input data for subsequent intelligent detection.

[0017] In specific implementation, first, the target range is identified and defined. This is usually done through project configuration files, build system definitions, or manual specification. For example, a large software project may contain multiple sub-modules, and it needs to be determined whether to analyze the entire project or only focus on specific high-risk modules; Second, retrieve and copy the source code. Once the target range is determined, the system or the operator will retrieve and copy the source code files through one or more of the following ways: Pull from version control system (VCS): For modern software development, source code is usually stored in Git, SVN, etc. Version control system. The system can pull the source code of the latest version or the specified historical version of the target project into the local analysis environment by calling the VCS client command; Copy from local filesystem or network share: If the source code is located in a specific directory on the local disk, or is accessible through a network file system (NFS, SMB / CIFS), the system will copy all source code files and their directory structure to the designated analysis workspace via file copy commands; Unarchive from compressed files: The source code might be provided in compressed packages (e.g.,.zip,.tar.gz). In this case, the system will first unarchive the compressed files to restore the original source code files and directory structure; Through automated scripts or API integration: In continuous integration / continuous deployment (CI / CD) processes, the acquisition of source code is often triggered by automated scripts that interact with code repository services (e.g., GitHub, GitLab, Bitbucket) through APIs to programmatically acquire the source code; Finally, verification and organization of the acquired content. After the source code files are copied to the local analysis environment, preliminary verification is usually performed, such as checking the number and size of files, or scanning for known file types, to ensure that no critical files are missed. Subsequently, these files are organized into a unified and easily accessible directory structure, forming the final source code file collection, which is ready for subsequent global static analysis. This collection typically includes all relevant source files, header files, configuration files, and other resource files that may be referenced during compilation or interpretation.

[0018] In particular, S2, global static analysis is performed on the collection of source code files to obtain call graphs and data flow graphs. The call graph (CallGraph) can reveal all possible function or method call relationships in the program, which is crucial for identifying cross-function call vulnerability patterns, such as unsafe API usage or privilege escalation paths. The data flow graph (DataFlowGraph) depicts how data propagates, transforms, and uses between program variables, which is invaluable for tracking the source, propagation path, and final sink of sensitive data (such as user input, credential information), and is the basis for detecting injection-type vulnerabilities (such as SQL injection, command injection) and information leakage issues. Without these global graph information, vulnerability detection will be limited to local code fragments, making it difficult to discover deep-level vulnerabilities that span multiple functions or files and rely on complex data flows, resulting in serious deficiencies in detection accuracy and coverage. Therefore, in the technical solution of the present application, global static analysis is performed on the collection of source code files to reveal the mutual call relationship between functions and the data flow path in the program.

[0019] In implementation, firstly, each source code file in the set of source code files is subjected to source code lexical / syntactic analysis to obtain a set of abstract syntax trees. In this process, firstly, the source code file is input into a lexical analyzer to obtain a source code token stream. In this stage, the lexical analyzer (Lexer or Scanner) reads the character sequence in the source code file and decomposes it 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 "int x = 10;" "may be decomposed by the lexical analyzer into tokens int (keyword), x (identifier), = (operator), 10 (integer constant), etc. Then, the source code token stream is input into a syntactic analyzer to obtain an abstract syntax tree. In this process, the syntactic analyzer analyzes the token stream according to the syntax rules (usually defined by a context-free grammar) of the target programming language, checks whether it conforms to the syntax structure of the language, and constructs an abstract syntax tree (AST) of the program in the process. AST is a hierarchical tree structure that represents the syntax structure of the source code in an abstract way. Each node represents a construct in the source code, such as expression, statement, declaration, function definition, etc., and the child nodes represent the components of the construct. For example, for "int x = 10;" ", the AST may contain a variable declaration node whose child nodes include the type (int), variable name (x), and initialization expression (10). By performing this process on each file in the set of source code files, a set of abstract syntax trees is finally obtained; Then, each abstract syntax tree in the set of abstract syntax trees is subjected to intra-procedural analysis and local graph construction to obtain a function node set, a variable node set, and a function local graph set. That is, after obtaining the set of abstract syntax trees, the system will perform detailed analysis within each AST for each function or method, which is called intra-procedural analysis. In this stage, the analyzer traverses the AST to identify function definitions, function calls, variable declarations, assignment statements, control flow statements (such as if, for, while), etc. Based on this information, the system will construct a local graph for each function. These local graphs usually include: Function node set: represents all identified functions or methods in the program; Variable node set: represents all variables declared and used within the scope of each function; Function local graph set: These graphs can include Control Flow Graph (CFG) and local data flow graph. Control flow graph depicts the possible paths of statement execution within a function; local data flow graph traces the definition (Def) and use (Use) relationship of data among variables within a function. These local graphs provide refined basic data for subsequent global analysis; Further, the function inter-analysis and global relationship linkage are performed on the function node set, the variable node set and the function local graph set of each abstract syntax tree to obtain a call edge set and a data flow edge set. That is, after the internal analysis of all functions is completed and the local graphs are constructed, the inter-procedural analysis is performed. The focus of this stage is to analyze the interaction between functions and establish the call and data transfer relationship across the function boundary. In this process, first, by analyzing the function call statement, the call of one function to another function is identified, thereby establishing the call edge set. These edges connect the caller function node and the callee function node, and together constitute the preliminary structure of the call graph of the program; at the same time, by tracing the parameter passing, return value and use of global variables, the data flow from the output of one function to the input of another function or how the data shared among multiple functions is modified and used is identified, thereby establishing the data flow edge set. These edges represent the path of data transfer and conversion between functions and are the key component for constructing the global data flow graph; Subsequently, the function node set, the variable node set, the call edge set, and the data flow edge set are globally graph aggregated to obtain a call graph and a data flow graph. That is, the discrete information obtained in the previous analysis stages is integrated to form a complete global graph. In this process, first, all identified function node sets and inter-function analysis call edge sets are aggregated to form a complete directed graph. In this graph, nodes represent functions in the program, and edges represent the calling relationship between functions. This graph can help understand the overall control flow of the program; at the same time, a data flow graph is constructed: the function node set, the variable node set, and the inter-function analysis data flow edge set 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 conversion. It is worth mentioning that the call graph is a directed graph that represents the calling relationship 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 that one function calls another function. By analyzing the call graph, the calling chain of the function, the recursive call, and the potential execution path can be identified, which is crucial for understanding the control flow of the program and discovering vulnerabilities related to the call stack (such as resource exhaustion, incorrect permission propagation). The data flow graph is a directed graph that represents how data is defined, used, propagated, and converted between variables in a program. The nodes in the graph can represent variables, expressions, basic blocks, or statements, and the directed edges represent the flow of data from one operation or location to another. The data flow graph is a key tool for tracing sensitive data sources (Source), propagating through program logic (Propagation), and reaching sensitive operations (Sink), and is crucial for detecting injection vulnerabilities, information leakage, unsafe data processing, and other issues.

[0020] In particular, the S3 performs candidate vulnerability slice identification 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 a large software project, the number and complexity of source code files are often very large, in order to avoid wasting computing resources on code areas without vulnerabilities, while ensuring that key potential vulnerability points are not missed, an effective pre-screening mechanism is needed. Therefore, in the technical solution of the present application, candidate vulnerability slice identification is performed on the first source code file in the set of source code files to preliminarily identify code areas that exhibit similar features to known vulnerability patterns in structure or semantics. In this way, the subsequent more time-consuming and complex graph-based context retrieval and enhancement and deep context-aware vulnerability adjudication can be focused on these screened candidate vulnerability slices with higher risk potential, thereby greatly improving the efficiency and relevance of the overall detection process. In addition, through the introduction of a large language model, this step can capture more hidden semantic-level vulnerability clues that are difficult to find by traditional pattern matching, providing high-quality input for subsequent refined analysis.

[0021] In implementation, first, based on each pattern rule in the dangerous sink pattern rule library, the first source code file is matched to obtain an original candidate slice list. In this process, the system loads a pre-constructed dangerous sink pattern rule library, which contains various programming language-related dangerous function calls, specific syntax structures or API usage patterns related to known vulnerability types. These patterns usually point to functions, API calls or language structures that may cause security problems when receiving untrusted data. For example, in a web application, common dangerous sinks may include: directly executing system commands with user input, unverified spliced SQL queries, unsafe reflection operations or file path operations, etc. The analyzer traverses the entire content of the first source code file and matches 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 certain fragment of code successfully matches a certain rule in the pattern library, the code fragment and its related information (such as file path and exact line number range) will be extracted as an original candidate slice. This process can broadly capture all possible risk points, even if some matches may be false positives, they need to be included for subsequent more refined screening; Next, the code snippet, file path, and line number of each original candidate slice in the original candidate slice list are input into a predefined prompt template to obtain an analysis prompt list. After obtaining the preliminary original candidate slice list, in order to utilize the semantic understanding ability of the large language model (LLM), it is necessary to convert these structured code information into natural language input that the LLM can process. Specifically, in this process, the system will prepare an input for each original candidate slice in the original candidate slice list. The 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. These information will then be embedded into a predefined prompt template. This template aims to provide sufficient context information for the large language model and guide it to preliminarily evaluate the potential security risks of the code snippet. For example, the prompt template may be designed as: "Please evaluate whether the following code snippet has vulnerability risks. File path: [file path], line number: [line number], code: [code snippet]". By filling in the information of each original candidate slice into this template, the system will generate a corresponding analysis prompt to obtain an analysis prompt list. Further, each set of corresponding analysis prompt and original candidate slice in the analysis prompt list and the original candidate slice list is input into the API interface of the large language model to obtain a candidate vulnerability slice list. It can be understood that the vulnerability features of the code are often not isolated syntax structures, but involve complex logic, data flow, and specific context. Relying solely on pattern library matching is easy to produce a large number of false positives (False Positives) or false negatives (False Negatives). Therefore, in the technical solution of the present application, each set of corresponding analysis prompt and original candidate slice in the analysis prompt list and the original candidate slice list is input into the API interface of the large language model to perform semantic-level in-depth evaluation of the original candidate slice by the large language model to determine whether it truly constitutes a vulnerability risk. In this process, the large language model can go beyond simple keyword or syntax matching, understand the intent, function of the code snippet, and its potential impact in the entire program, thereby giving more accurate initial scores and required context types. In addition, the score is adjusted in combination with the dangerous sink risk and local clarity to ensure the comprehensiveness and reliability of the evaluation results, providing more instructive basis for subsequent refined analysis.

[0022] In particular, first, the analysis hints and the original candidate slices are input into the API interface of the large language model to obtain an initial score and the required context type. In this process, the system will traverse each corresponding element in the analysis hint list and the original candidate slice list. For each group, it will analyze the hints (natural language descriptions containing code snippets, file paths, and line numbers, etc.) and the metadata of the corresponding original candidate slices (such as the code itself, file path, line number, etc.) as input, and send them to the large language model (LLM) through the preset API interface; after receiving these inputs, the large language model will use its powerful code understanding ability and the vulnerability knowledge obtained through training to perform in-depth semantic analysis on the input code snippets. It will not only focus on the surface structure of the code, but also try to understand the intent, data flow, control logic, and potential security implications of the code. Based on this analysis, the large language model returns two key pieces of information: Initial score: This is a quantitative numerical value representing the large language model's preliminary confidence or severity assessment of the vulnerability risk of the original candidate slice. This score is usually between 0 and 1, with a higher score indicating that the model considers the slice to be a real vulnerability with a higher probability; Required context type: This is the additional context information type that the large language model believes is necessary for subsequent in-depth analysis to more accurately determine whether it is a vulnerability based on its current understanding of the code snippet. For example, if the code involves data operations, the model may suggest that the data flow context is needed to track the source and destination of the data; if it involves function calls, it may suggest that the call graph context is needed to understand the function call chain; if it involves branching logic, it may need a control flow context; Next, the initial score is adjusted to obtain a preliminary score. To improve the accuracy and practicality of the initial score returned by the large language model and make it more consistent with actual security risk assessment, the system will further calculate and correct the initial score according to the preset adjustment strategy, thereby obtaining the preliminary score. This adjustment process fully utilizes the prior knowledge extracted from the dangerous sink pattern library and the local features of the code snippet. Specifically, the initial score is adjusted as follows: wherein, is the dangerous sink risk extracted from the dangerous sink pattern library, which quantifies the inherent security risk of a specific dangerous function or operation. For example, a function that directly executes system commands may have a higher value, is the local clarity, which is used to evaluate the readability, complexity, and ambiguity of the current original candidate slice. For example, the more concise and logical the code is, the The higher the value, the more explicit the semantics; on the contrary, if the code is too complex and obscure, the value is lower introducing can correct the bias that the large language model may produce when dealing with complex or ambiguous code to some extent, is the initial score. Through this formula, the system can combine the intelligent judgment of the large language model with traditional, rule-based risk knowledge and the local quality factors of the code itself, so as to obtain a more comprehensive and accurate risk assessment result; 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 will organically integrate and encapsulate these newly generated information, combined with the original metadata contained in the original candidate slice (for example, the text content of the code fragment, the file path where the code fragment is located, the specific line number range, and any other structured information collected in the preliminary matching stage), to obtain a complete and structured data unit, that is, the candidate vulnerability slice. This candidate vulnerability slice is a highly informationized entity in the entire vulnerability detection process, which not only contains the original code context, but also integrates the preliminary assessment of risk (preliminary score) by the large language model and the guidance information required for subsequent in-depth analysis (required context type).

[0023] In particular, the S4 performs graph-based context retrieval and enhancement on the first candidate vulnerability slice in the candidate vulnerability slice list based on the call graph and the data flow graph to obtain the first enhanced vulnerability slice. It should be understood that many vulnerabilities do not exist in isolation in a certain code line, but involve data transfer and control flow across functions and files. For example, the real risk of a SQL injection vulnerability lies in that the user input (source) reaches the database query (sink) without sufficient purification. Without knowing the source of the data and the conversion process in between, it is impossible to accurately determine whether the vulnerability exists or its severity, therefore, in the technical solution of the present application, by using the global call graph and data flow graph generated in the previous steps, the system can trace back the source of the data flow, the purification or pollution process in the middle, and how the control flow leads to the execution of the slice. In this way, from the unsafe data source to the dangerous sink, a complete attack path can be formed.

[0024] 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. 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. 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: 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; Control flow path: Tracing back the control flow conditions and decision points that lead to the execution of anchor nodes; Call chain path: Tracing the caller chain of the function containing the anchor node in the call graph in reverse; All these collected paths together form the original path set, which contains all possible program execution or data flow paths traced back from the risk point and is the basis for subsequent refinement and screening; Subsequently, path pruning and key evidence chain screening are performed on the original path set to obtain the key path. It should be understood that in a complex code environment, simple graph traversal may generate a large number of paths, including a large number of redundant, irrelevant or even purified paths. The existing data flow path risk assessment mechanism regards the data channel as a static process in which risk can only decay when calculating the path score. Its scoring model mainly relies on the initial risk of the source and performs simple linear weakening through path length and purification function. This model has a fundamental defect. Specifically, it ignores the nonlinear conversion or amplification effect of specific code operations, i.e., risk conversion operators, on risk in the path. In a real code security scenario, some intermediate code operations are not vulnerability entry points, but key catalysts for risk escalation. For example, the operation of string formatting external input with a SQL query template can sharply amplify the risk of injection vulnerabilities. The original mechanism cannot effectively distinguish between such risk amplification paths and paths that flow through benign operations (such as integer conversion), because it lacks a mathematical model that can dynamically measure the risk evolution of data as it flows through different code structures. This practice of limiting scoring to a "point-product" model rather than a "path-dependent" continuous model can result in underestimating the score of attack paths that consist of a series of clever, non-vulnerable but cumulatively dangerous operations, leading to false negatives.

[0025] To solve the above-mentioned defects, a risk potential field model based on path integration is introduced. Specifically, by constructing a dynamic risk potential field model, using path integration to calculate cumulative risk, and performing risk density normalization and Softmax decision, the cumulative amount of risk at each step on the path is accurately captured, and ultimately those evidence chains that best reflect the nature of the vulnerability and have the most attack potential are screened from the original path set, thereby significantly reducing false positives and providing security analysts with more rich and accurate decision-making information.

[0026] In this process, first, based on the data flow graph and the operation risk knowledge base, the risk potential field is constructed. In order to quantify the risk correlation and environmental impact of each operation node in the code library, a mathematical model reflecting the global risk distribution needs to be constructed. It is not enough to assess the risk of a single operation in isolation, because a high-risk operation will significantly increase the potential threat of its adjacent code region. Specifically, first, based on an operation risk knowledge base that stores the inherent risk coefficients of various types of code operations, a basic potential energy 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 reading and writing, database operations, string concatenation, and sanitization functions). For example, an API call that directly executes external commands may have a high basic potential energy, while a simple mathematical operation may have a lower basic potential energy; then, to simulate the transmission and mutual influence of risk in the code structure, a method inspired by the Laplace operator is used to update the final risk potential energy of each node through iterative calculation; the final potential energy of a node is the weighted sum of the differences in potential energy of all adjacent nodes. The process continues until the entire risk potential field converges and stabilizes. The calculation process can be represented by the formula: wherein, represents the final risk potential energy value of node ; is the basic potential energy of node , derived from the operation risk knowledge base; is the coefficient of the influence of the control risk on the transmission between adjacent nodes; is the set of all adjacent nodes of node ; is the risk potential energy value of adjacent node . In this way, a global and interconnected risk view is established. After execution, the data flow graph is no longer a collection of discrete nodes, but a continuous and differentiable risk potential field, so that high-risk code (such as eval call) will naturally raise the risk potential energy of its surrounding code nodes, making any data path passing through this area be assigned a higher initial attention level; 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: 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. 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: 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.

[0027] 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. 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.

[0028] In particular, the S5 performs deep context-aware vulnerability adjudication on the first enhanced vulnerability slice to obtain an adjudication result. Although the previous steps have identified candidate vulnerability slices, provided preliminary scores, and enhanced contextual information through the graph, the final vulnerability judgment still requires a mechanism that can integrate all information and perform advanced reasoning. In the technical solution of the present application, the excellent natural language understanding and code semantic reasoning capabilities of the large language model are utilized, combined with the rich contextual information obtained, to perform a comprehensive and deep perception evaluation on 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 the context information.

[0029] In specific implementation, first, the code segment and context description of the first enhanced vulnerability slice are embedded into a prompt word template for in-depth adjudication to obtain a final prompt word. In this process, the system will make full use of all the information contained in the first enhanced vulnerability slice. This enhanced slice not only has the original code segment, file path, and line number, but more importantly, it contains detailed context descriptions composed of key paths filtered through graph analysis. These context descriptions may include the source of data flow, intermediate variable conversion, function call sequence, and related control flow conditions, which exist in structured or natural language form. The system will embed these key information into a prompt word template for in-depth adjudication, which is specifically designed to guide the large language model to make the final vulnerability judgment, and will explicitly require the model to integrate all the provided information to give conclusions about the existence of vulnerabilities, types, severity, and possible exploitation methods. For example, the template may be designed as: "Please judge whether there is a security vulnerability based on the following code segment and its complete context data flow and control flow information, and provide the vulnerability type, severity, and explanation. Code: [code segment]. Context description: [detailed context evidence chain]. By filling the content of the first enhanced vulnerability slice into this template, the system will generate a final prompt word, which is highly customized and contains all the semantic information required for the large language model to perform deep adjudication; Next, the final prompt is input into the large language model to obtain an original LLM response. That is, after generating a highly detailed and structured final prompt, the system sends it to a powerful large language model (LLM) through a pre-set API interface. After receiving this final prompt, the large language model uses its advanced reasoning capabilities trained on vast amounts of code and security knowledge to conduct a comprehensive analysis of the code snippet and its detailed context. Unlike the previous preliminary assessment, the model now has a complete vulnerability evidence chain and can perform deeper semantic understanding and logical judgment. Based on its analysis, the large language model generates an original LLM response, usually in the form of natural language text, which may include descriptions of vulnerabilities, possible vulnerability types, risk assessments, explanatory statements, and even possible repair solutions; Further, the original LLM response and the preliminary score are structured to obtain the final decision result. In order to convert the natural language response returned by the large language model into a system processable, standardized vulnerability report format, and improve the overall credibility of the decision result, the system will perform structured analysis and multi-source information fusion. In this process, first, the system will perform natural language processing and information extraction on the original LLM response. This usually involves pattern matching, entity recognition, sentiment analysis and other techniques aimed at identifying key information from unstructured text, such as: vulnerability type (e.g., SQL Injection, XSS), vulnerability description, affected code location, recommended repair measures, etc. The goal of analysis is to convert it into a standardized, machine-readable format; while analyzing the original LLM response, the system will fuse the preliminary score obtained in the previous step with the confidence or evaluation results implied by the large language model in the current decision. The preliminary score represents the comprehensive consideration of traditional pattern matching and the first LLM evaluation, while the original LLM response represents the in-depth evaluation based on enhanced context. The fusion strategy may include weighted averaging, Bayesian fusion or other multi-sensor information fusion algorithms. For example, if the preliminary score is high and the LLM's in-depth decision also tends to exist a vulnerability, the final confidence will be higher. Conversely, if the preliminary score is high but the LLM believes it is not a vulnerability after in-depth analysis (e.g., finding that there is a purification), the confidence of the decision result may be adjusted lower, or even determined as non-vulnerability. Through structured decision analysis and credibility fusion, the system finally obtains a unified, high-confidence decision result. This decision result is usually presented in a structured data format (such as JSON, XML), containing clear vulnerability type, risk level, detailed description, affected code location, repair suggestion and decision confidence, etc. The result is the final output of the entire vulnerability detection process and can be directly used for vulnerability reporting or security repair workflow.

[0030] In summary, the vulnerability and hidden danger intelligent detection method based on a large model according to the embodiments of the present application is illustrated, which firstly performs global static analysis on the source code set, constructs a complete call graph and data flow graph of the 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 the call chain and data trace path strongly related to the vulnerability slice is converted into natural language description understandable by the large language model, and the prompt word is injected, so as to provide the model with the missing global context information and make up for the deficiency of the model in the complex code analysis capability. In this way, the problem of invalidation of the attention mechanism in long-distance code association is solved, and the accuracy and reliability of the vulnerability detection are significantly improved.

[0031] Embodiments of the disclosure have been described above, the above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and changes are obvious to those skilled in the art without departing from the scope and spirit of the described embodiments. The selection of the terms used herein is intended to best explain the principles, practical application or improvement of the technology in the market of the embodiments, or to enable other ordinary skilled persons in the art to understand the embodiments disclosed herein.

Claims

1. A large model-based vulnerability risk intelligent detection method, characterized in that, The method comprises the following steps: obtaining a set of source code files; performing global static analysis on the set of source code files to obtain a call graph and a data flow graph; performing candidate vulnerability slice identification on a first source code file in the set of source code files to obtain a candidate vulnerability slice list; based on the call graph and the data flow graph, performing graph-based context retrieval and enhancement on a first candidate vulnerability slice in the candidate vulnerability slice list to obtain a first enhanced vulnerability slice; performing deep context-aware vulnerability adjudication on the first enhanced vulnerability slice to obtain an adjudication result.

2. The large model-based vulnerability risk intelligent detection method according to claim 1, characterized in that, The global static analysis on the set of source code files to obtain a call graph and a data flow graph comprises: performing source code lexical / syntactic analysis on each source code file in the set of source code files to obtain a set of abstract syntax trees; performing intra-function analysis and local graph construction on each abstract syntax tree in the set of abstract syntax trees to obtain a function node set, a variable node set and a function local graph set; performing inter-function analysis and global relationship linking on the function node set, the variable node set, and the function local graph set of each abstract syntax tree to obtain a call edge set and a data flow edge set; performing global graph aggregation on the function node set, the variable node set, the call edge set and the data flow edge set to obtain a call graph and a data flow graph.

3. The large model-based vulnerability risk intelligent detection method according to claim 2, characterized in that, The global static analysis on the set of source code files to obtain a call graph and a data flow graph comprises: inputting the source code file into a lexical analyzer to obtain a source code token stream; inputting the source code token stream into a syntactic analyzer to obtain an abstract syntax tree.

4. The large model-based vulnerability risk intelligent detection method according to claim 1, characterized in that, The candidate vulnerability slice identification on a first source code file in the set of source code files to obtain a candidate vulnerability slice list comprises: based on each pattern rule in the dangerous sink point pattern library, matching the first source code file to obtain an original candidate slice list; inputting the code segment, 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; inputting each group of corresponding analysis prompts and original candidate slices in the analysis prompt list and the original candidate slice list into an API interface of a large language model to obtain a candidate vulnerability slice list.

5. The large model-based vulnerability risk intelligent detection method according to claim 4, characterized in that, The candidate vulnerability slice identification on a first source code file in the set of source code files to obtain a candidate vulnerability slice list comprises: inputting the analysis prompt and the original candidate slice into the API interface of the large language model to obtain an initial score and a required context type; adjusting the initial score to obtain a preliminary score; combining the preliminary score, the required context type and the metadata of the original candidate slice to obtain a candidate vulnerability slice.

6. The large model-based vulnerability risk intelligent detection method according to claim 5, characterized in that, The adjustment of the initial score to obtain a preliminary score comprises adjusting the initial score according to the following formula: wherein, is a hazardous merge point risk extracted from a library of hazardous merge point patterns, is a local sharpness, is an initial score.

7. The large model-based vulnerability risk intelligent detection method according to claim 1, characterized in that, The graph-based context retrieval and enhancement on a first candidate vulnerability slice in the candidate vulnerability slice list based on the call graph and the data flow graph to obtain a first enhanced vulnerability slice comprises: based on the file path and the line number of the first candidate vulnerability slice, performing slice positioning and graph anchor mapping in the data flow graph to obtain an anchor node; parsing a required context type of the first candidate vulnerability slice to obtain a traversal instruction; performing reverse graph traversal and path collection on the call graph and the data flow graph based on the anchor node and the traversal instruction to obtain an original path set; performing path pruning and key evidence chain screening on the original path set to obtain a key path; performing slice enhancement on the first candidate vulnerability slice based on the key path to obtain a first enhanced vulnerability slice.

8. The large model-based vulnerability risk intelligent detection method according to claim 7, characterized in that, performing path pruning and key evidence chain screening on the original path set to obtain a key path, comprising: constructing a risk potential field based on the data flow graph and the operational risk knowledge base; performing risk accumulation calculation based on path integral on each original path in the original path set based on the risk potential field to obtain a path score set; performing risk density normalization and key path decision on each original path in the path score set to obtain the key path.

9. The large model-based vulnerability risk intelligent detection method according to claim 1, characterized in that, performing deep context-aware vulnerability adjudication on the first enhanced vulnerability slice to obtain an adjudication result, comprising: embedding a code snippet and a context description of the first enhanced vulnerability slice into a prompt word template for in-depth adjudication to obtain a final prompt word; inputting the final prompt word into a large language model to obtain an original LLM response; performing structured adjudication analysis and credibility fusion on the original LLM response and a preliminary score to obtain the adjudication result.

Images