Automatic vulnerability detection rule generation method based on LLM and static code analysis

Abstract

The invention provides an automatic vulnerability detection rule generation method based on LLM and static code analysis, and relates to the technical field of network security and software engineering. The method comprises the following steps of: constructing unified structured representation of project code semantics and vulnerability features, classifying taint'source 'and'sink' based on a heuristic rule and LLM (Logical Language Model), and constructing a taint propagation path assisted by a large language model and performing risk assessment; automatically generating a rule based on a'generation-verification-repair 'closed loop mechanism; according to the method, uniform structured representation of code side information and vulnerability side information is constructed, accurate identification of specific project taint sources and sinks and effective paths in multiple environments is achieved, a path risk sorting mechanism is introduced to achieve priority detection of high-risk paths, an automatic rule of error feedback circulation aiming at correction is established, and the accuracy of detection is improved. And the correctness and the performability of the rule grammar are greatly improved, and logic vulnerabilities are reduced, so that the manual debugging and maintenance cost is reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of network security and software engineering, and particularly relates to an automatic vulnerability detection rule generation method based on a large language model (LLM) and static code analysis technology. BACKGROUND

[0002] Vulnerability detection is a necessary engineering practice to ensure software security. However, with the continuous growth of open source software and enterprise-level systems in terms of scale, complexity and technology stack diversity, multi-language mixed development, micro-service architecture and cross-end data interaction have become mainstream modes, making the source code structure present the characteristics of high dynamicity, cross-language coupling and multi-dimensional dependence. Under this background, the traditional code detection mode mainly relying on manual review has been difficult to meet the urgent needs of current software security detection due to its limited coverage, low efficiency and insufficient consistency. Intelligent vulnerability detection technology must be introduced to break through the cognitive and capacity bottlenecks of traditional methods, thereby effectively addressing the analysis challenges brought by massive code while ensuring detection depth.

[0003] Although existing static application security testing tools and static analysis frameworks based on taint analysis can automatically detect source code, their rule systems mainly rely on preset general patterns. Such general patterns are obviously insufficient when facing cross-function, cross-component and even cross-language data flow semantics. Especially in handling complex control flow, project-specific business logic and multi-language calling scenarios, such tools are prone to false positives and false negatives, making it difficult to accurately identify key risk points.

[0004] To improve detection capability, existing technologies attempt to use large language models to assist static analysis tools in understanding or generating query statements. However, there are still significant limitations: First, there is a lack of project-level customization capability. Generative rules often rely on general samples and lack detection rules tailored to specific project architectures, resulting in rules that are not suitable for the local conditions.

[0005] Second, the precision of taint specification identification is low. Existing methods usually use coarse-grained regular matching or single-model judgment to identify taint "source" and "sink", lacking mechanisms for context semantic support, taint propagation path screening and priority determination, making it difficult to ensure the accuracy and reliability of effective propagation paths.

[0006] Third, the rule engineering usability is poor. Static analysis tools usually have strict domain-specific language (DSL) syntax (such as the QL language of CodeQL). In the absence of automated constraints and compilation feedback mechanisms, the rule code generated by large language models often has syntax errors or logical vulnerabilities, cannot be directly compiled and run, and requires a lot of manual correction, seriously affecting engineering landing.

[0007] In summary, there is an urgent need for an automated vulnerability detection method that can build high-quality code semantic representations at the project level, automatically parse valid "source" and "sink" paths, and implement a rule generation and verification closed loop under the constraints of tool syntax to solve the above problems. SUMMARY

[0008] The purpose of the present application is to overcome the problems in the prior art such as weak pertinence of static analysis rule library, difficulty in customized generation for specific projects, low precision of taint identification, low rule syntax correctness rate of large language model generated rules, and poor engineering usability, and to provide an automated vulnerability detection rule generation method integrating large language model and static code analysis, thereby constructing a full-automatic, high-precision, and high-reliability vulnerability detection rule for specific projects.

[0009] The present application constructs a strict logical closed loop, i.e., "semantic modeling - taint identification - path verification - rule generation", to ensure that the output of each step is an effective input for the next step, thereby constructing a high-precision and executable vulnerability detection rule for specific projects.

[0010] The technical solution adopted by the present application includes the following steps: Step S1: Constructing a unified structured representation of project code semantics and vulnerability characteristics: using a static analysis tool to statically analyze and extract code semantic information from the target project source code; combining the code semantic information with the known vulnerability characteristics in the public vulnerability database to organize a structured representation.

[0011] Step S2: Taint "source" and "sink" classification based on heuristic rules and LLM: The pre-defined heuristic rules are used to preliminarily screen the potential taint "source" and "sink" of the structured representation, obtain a candidate set, and construct a structured Prompt; then the large language model is used to reason and judge whether the structured Prompt has "source" or "sink" properties, output the final effective "source" set and taint "sink" set, and give a confidence score.

[0012] Step S3: Taint propagation path construction and risk assessment assisted by large language model: The static analysis engine is used to search for data flow reachable paths from the determined "source" to the "sink" on the control flow graph; semantic summaries and path node information are generated for each path, and the large language model is used to evaluate the semantic summaries and path node information to eliminate invalid paths, thereby obtaining an effective "source" to "sink" path set; in addition, the large language model is used to evaluate the risk level of the effective "source" to "sink" path, and detection rules are generated for high-risk "source" and "sink" paths in priority.

[0013] Step S4: Automatic rule generation based on the "generation-verification-repair" closed-loop mechanism: Based on the effective source-to-sink path and the domain-specific language syntax constraints of static analysis tools, an initial detection script is generated using a large language model. The initial detection script is then compiled using a compiler tool and run in a test environment. If compilation fails or no results are obtained, error logs and feedback information are collected and sent back to the large language model for targeted code correction until the rules are verified, ultimately resulting in a project-level customized vulnerability detection rule that can be directly executed.

[0014] The above steps can be executed sequentially on the same computing node, or they can be deployed independently and run collaboratively in a distributed environment.

[0015] This invention, through the synergistic integration of a static analysis toolchain and a large-scale language model, offers the following advantages compared to existing technologies: (1) Construct a unified structured representation of project-level code semantics and vulnerability features, which can provide a complete semantic context for the identification of "source" and "sink" and the analysis of data flow paths in a multi-language and microservice environment, thereby improving the coverage and granularity of project-level analysis.

[0016] (2) A “source” and “sink” classification mechanism is proposed that combines heuristic rules, static analysis of structural features and reasoning ability of large language models, which can effectively improve the accuracy and robustness of “source” and “sink” classification while reducing analysis overhead.

[0017] (3) Based on static data flow analysis, a large language model is introduced to determine the feasibility of the path and rank the risks. Rules are generated only for high-risk propagation paths that have been semantically verified, thereby improving the pertinence, interpretability and engineering value of the rule base.

[0018] (4) Through the closed-loop process of “generation-verification-repair” for domain-specific languages, large language models are transformed from general code generation tools into automated rule correctors with error feedback, which significantly improves the accuracy and executability of rule syntax and reduces manual debugging and maintenance costs. Attached Figure Description

[0019] Figure 1 This is a schematic diagram of the overall process of the present invention. Detailed Implementation

[0020] The present invention will now be described in further detail with reference to the accompanying drawings and preferred embodiments.

[0021] This embodiment uses CodeQL as the static analysis engine and Java as the target language, but those skilled in the art will understand that the present invention is also applicable to other static analysis tools and programming languages ​​that support taint analysis.

[0022] like Figure 1 As shown, the method provided by this invention includes four sequentially executed steps: This step aims to standardize the representation of the target project's source code and vulnerability characteristics.

[0023] Step S1: Construct a unified structured representation of project code semantic information and vulnerability features. S101, Parsing the source code: First, the static analysis tool CodeQL Extractor is used to parse the source code of the target project and generate an abstract syntax tree (AST).

[0024] S102, Semantic Information Extraction: Extract code semantic information from the AST, including functions, interfaces, call relationships, data flow relationships, etc., and construct function call graphs and control flow graphs.

[0025] S103, Feature Fusion: This method combines code semantic information with known vulnerability features from a publicly available vulnerability database. These features include target language, framework-related vulnerability types, dangerous call patterns, and typical exploitation methods (such as the execute method commonly used in SQL injection and the writer output commonly used in XSS). By combining code-side and vulnerability-side information, a structured representation containing code entities, semantic attributes, and potential risk labels is obtained, providing a unified semantic context and feature support for subsequent source and sink identification and path analysis.

[0026] Step S2: Taint "Source" and "Sink" Classification Based on Heuristic Rules and LLM This step aims to accurately identify the "source" of attacks and the "sink" of sensitive operation points in the system.

[0027] S201, Heuristic Preliminary Screening: Based on predefined heuristic rules (such as regular expressions), potential taint "sources" and "sinks" in the structured representation are initially screened to obtain a set of candidate "sources" and "sinks". For example, methods containing "getParameter" are marked as candidate "sources"; methods containing "execute" are marked as candidate "sinks".

[0028] S202, Context Construction: For each entity in the candidate "source" and "sink" sets, extract its class annotation, parameter type definition, and the five lines of code above and below it to construct a structured Prompt.

[0029] S203, Model Discrimination and Fusion: The structured Prompt is input into the large language model. The model infers and discriminates based on the code semantics of the interface name, parameter type, call context, and business semantics to determine whether the function truly has "source" or "sink" attributes, determines the final set of valid "sources" and valid "sinks," and provides a confidence score.

[0030] Step S3: Construction and Risk Assessment of the Impurity Propagation Path Assisted by a Large Language Model This step aims to identify which "sources" and "sinks" have actual dangerous data flows.

[0031] S301, Static Path Mining: Starting from the set of valid "sources" determined in step S2 and ending at the set of valid "sinks", the static analysis engine is used to search for reachable data flow paths from "sources" to "sinks" on the control flow graph. The path search considers cross-function calls and cross-file data transfer.

[0032] S302, Semantic Summarization and Evaluation: Generate a semantic summary and path node information for each searched reachable path (e.g., "Source: HTTP request parameters -> string concatenation -> Sink: SQL execution"). Submit the semantic summary and path node information to the large language model to evaluate whether there are valid sanitizers or blocking logic in the path, and remove invalid paths to generate a set of valid "source" to "sink" paths.

[0033] S303, Priority Ranking: In addition, the risk level of the effective source-to-sink path set is evaluated by using a large language model to assess the semantic rationality and attack feasibility. The source and sink paths are ranked according to the risk level and confidence level assessed by the model, and detection rules are generated for high-risk source-to-sink paths first.

[0034] Step S4: Automatic rule generation based on the "generation-verification-repair" closed-loop mechanism This step is the core of achieving automation, ensuring the quality of the detection rules through iterative optimization.

[0035] S401, Contextual Retrieval and Initial Generation: Combining the QL language syntax constraints of CodeQL, a large language model is used to generate an initial .ql detection script from the valid "source" to "sink" path output in step S3.

[0036] S402, Automatic Compilation and Verification: The CodeQL compiler tool is used to compile the initial detection script. If compilation is successful, it is run directly on the test database.

[0037] S403, a feedback-driven remediation loop: If compilation fails (e.g., syntax errors) or execution yields no results (logical errors), compiler error logs and feedback information are automatically collected and fed back to the large language model. The large language model then makes targeted corrections to the initial detection script based on the feedback. This process is repeated until successful compilation and execution on the test database, ultimately generating directly executable automated vulnerability detection rules for specific projects.

[0038] Through the above implementation methods, the present invention can automatically generate high-quality, executable project-level vulnerability detection rules, effectively filling the blind spots of general scanning tools in specific project detection.

[0039] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. An automated vulnerability detection rule generation method based on LLM and static code analysis, characterized in that, Includes the following steps: Step S1: Construct a unified structured representation of the project code semantic information and vulnerability characteristics: Static analysis tools are used to statically analyze the source code of the target project to extract semantic information; the semantic information is then combined with known vulnerability features in the public vulnerability database and organized into a structured representation. Step S2: Taint "Source" and "Sink" Classification Based on Heuristic Rules and LLM: Predefined heuristic rules are used to initially screen potential taint "sources" and "sinks" in the structured representation to obtain a candidate set and construct a structured Prompt; then, a large language model is used to reason and judge whether the structured Prompt truly has "source" or "sink" attributes, outputting the final valid "source" set and taint "sink" set and giving a confidence score; Step S3: Construction and risk assessment of taint propagation path assisted by large language model: Use a static analysis engine to search for reachable data flow paths from "source" to "sink" on the control flow graph; For each path, a semantic summary is generated. The semantic summary and path node information are evaluated using a large language model to eliminate invalid paths and obtain a set of valid source-to-sink paths. In addition, the risk level of the valid source-to-sink paths is assessed using a large language model, and detection rules are generated for high-risk source and sink paths first. Step S4: Automatic rule generation based on the "generate-verify-repair" closed-loop mechanism: Based on the effective "source" to "sink" path and the domain-specific language syntax constraints of static analysis tools, an initial detection script is generated using a large language model. The initial detection script is then compiled using a compiler tool and run in a test environment. If compilation fails or no results are obtained, feedback is sent to the large language model for targeted code correction until the rule passes verification, ultimately resulting in a project-level customized vulnerability detection rule that can be directly executed.

2. The method according to claim 1, characterized in that: The extraction of code semantic information in step S1 specifically refers to using static analysis tools to parse the target source code, generate an abstract syntax tree, and then extract code semantic information from the abstract syntax tree; the code semantic information includes functions, interfaces, call relationships, and data flow relationships.

3. The method according to claim 1, characterized in that: The known vulnerability characteristics mentioned in step S1 include target language, framework-related vulnerability types, dangerous call patterns, and typical exploitation methods; the structured representation specifically refers to the unified organization of information from the code side and the vulnerability side.

4. The method according to claim 1, characterized in that: In step S2, the construction of the structured Prompt specifically involves extracting the class annotation, parameter type definition, and five lines of code above and below each entity in the candidate "source" and "sink" sets to construct the structured Prompt. The reasoning and discrimination specifically refer to the large language model performing reasoning and discrimination on the interface name, parameter type, calling context, and business semantics based on code semantics to determine whether the function truly has the "source" or "sink" attribute.

5. The method according to claim 1, characterized in that: The data flow reachable path in step S3 specifically refers to the path that starts from the set of valid "sources" determined in step S2 and ends at the set of valid "sinks"; the evaluation specifically evaluates whether there is a valid cleanup function or blocking logic in the path; the high-risk "source" to "sink" path is obtained by ranking the evaluated risk level and confidence level.

6. The method according to claim 1, characterized in that: The feedback mentioned in step S4 specifically involves automatically collecting compiler error logs and feedback information and feeding them back to the large language model.

Images