Software vulnerability analysis report generation method and device

Abstract

The invention discloses a method and a device for generating a software vulnerability analysis report, and relates to the field of information security. The method comprises the following steps: acquiring auditing information of software vulnerabilities; a code feature matching rule for the software vulnerability is generated according to the auditing information through the large language model, and the code feature matching rule is used for matching a code calling mode related to the software vulnerability in the target software project; constructing a calling graph of the target software project; according to the code feature matching rule and the call graph, the correlation degree between each code snippet of the target software project and the software vulnerability is detected, and the correlation degree is used for evaluating the risk level of each code snippet of the target software project; and generating a software vulnerability analysis report of the target software project according to the association degree between each code snippet of the target software project and the software vulnerability. The technical problem that in the prior art, an open source software vulnerability detection tool cannot accurately evaluate the real influence of vulnerabilities in specific project contexts is solved.

Description

Technical Field

[0001] This application relates to the field of information security, and more specifically, to a method and apparatus for generating software vulnerability analysis reports. Background Technology

[0002] In the field of financial software development and operation, open-source software components are widely used due to their rich functionality and community support. However, the security issues of open-source software cannot be ignored, especially as the software supply chain becomes more complex, and vulnerabilities hidden in open-source components pose an increasingly serious threat to the security of the entire system. Currently, software vulnerability detection technologies mainly rely on tools such as software component analysis, static application security testing, and dynamic application security testing, but existing methods have significant shortcomings in assessing the true impact of vulnerabilities.

[0003] While software composition analysis, static application security testing, and dynamic application security testing each play important roles in vulnerability detection, none of these methods provide a comprehensive, context-sensitive, and dynamically call path analysis approach to accurately assess the exploitability and impact of vulnerabilities in a specific project. This often results in security teams needing to invest significant human resources in manually verifying each vulnerability report to determine which vulnerabilities require priority handling—a time-consuming and inefficient process.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This application provides a method and apparatus for generating software vulnerability analysis reports, which at least solves the technical problem that existing open-source software vulnerability detection tools cannot accurately assess the real impact of vulnerabilities in a specific project context.

[0006] According to one aspect of the embodiments of this application, a method for generating a software vulnerability analysis report is provided, comprising: obtaining audit information of a software vulnerability, wherein the audit information includes vulnerability description information, remediation suggestions, and code examples; generating code feature matching rules for the software vulnerability based on the audit information using a large language model, wherein the code feature matching rules are used to match code call patterns related to the software vulnerability in a target software project; constructing a call graph of the target software project, wherein the call graph is used to represent the call relationships between various software functions in the target software project; detecting the correlation between each code segment of the target software project and the software vulnerability based on the code feature matching rules and the call graph, wherein the correlation is used to assess the risk level of each code segment of the target software project; and generating a software vulnerability analysis report of the target software project based on the correlation between each code segment of the target software project and the software vulnerability.

[0007] Optionally, a large language model is used to generate code feature matching rules for software vulnerabilities based on audit information. This includes: constructing a composite prompt consisting of vulnerability description information, remediation suggestions, and code examples; interacting the composite prompt with the large language model, which outputs initial feature matching rules; performing target processing on the initial feature matching rules, including semantic parsing and format standardization; using known vulnerability code samples to detect the sample detection recall and sample detection accuracy of the initial feature matching rules; and generating code feature matching rules for software vulnerabilities based on the sample detection recall and sample detection accuracy.

[0008] Optionally, based on the sample detection recall and sample detection accuracy, code feature matching rules for software vulnerabilities are generated, including: if the sample detection recall is lower than a preset recall or the sample detection accuracy is lower than a preset accuracy, the initial feature matching rule is adjusted at least once until the sample detection recall of the adjusted initial feature matching rule is not lower than the preset recall and the sample detection accuracy is not lower than the preset accuracy, and then the adjustment of the initial feature matching rule is stopped; the final adjusted initial feature matching rule is used as the code feature matching rule.

[0009] Optionally, a composite prompt consisting of vulnerability description information, remediation suggestions, and code examples is constructed, including: setting a list of heuristic questions, outputting text instructions, and providing contextual information. The list of heuristic questions is used to guide the large language model to focus on key features in the code, the outputting text instructions are used to constrain the format of the code feature matching rules generated by the large language model, and the contextual information is used to construct the application context of the code feature matching rules. Based on the list of heuristic questions, the outputting text instructions, and the contextual information, a composite prompt consisting of vulnerability description information, remediation suggestions, and code examples is constructed.

[0010] Optionally, constructing a call graph for the target software project includes: converting the source code of the target software project into multiple lexical units; constructing an abstract syntax tree based on the multiple lexical units; performing control flow analysis based on the abstract syntax tree to obtain function call statements in the source code; constructing a control flow graph based on the function call statements, wherein the control flow graph is used to describe the execution order of code blocks and the transfer path of control flow in the program, the control flow graph represents code segments through nodes and transfer paths of control flow through edges; and generating a call graph based on the control flow graph.

[0011] Optionally, generating a call graph based on the control flow graph includes: determining parameter passing paths and code execution flow based on the control flow graph; creating nodes representing code functions based on the parameter passing paths and code execution flow; determining the connection relationships between nodes based on the call relationships between code functions; and generating a call graph based on the nodes representing code functions and the connection relationships between nodes.

[0012] Optionally, the correlation between each code segment of the target software project and the software vulnerability is detected based on code feature matching rules and call graphs. This includes: applying code feature matching rules to perform static analysis on the source code of the target software project, wherein the static analysis is used to detect code features related to the software vulnerability in the source code and record the positions of the code features in the call graph; performing a search operation on the call graph based on the positions of the code features in the call graph, wherein the search operation is used to trace the information transmission path from external input information to potentially vulnerable code; detecting whether the information transmission path meets the software vulnerability triggering conditions; and, if the information transmission path meets the software vulnerability triggering conditions, determining the correlation between the code segment and the software vulnerability based on the number of code features related to the software vulnerability and the feature weight value of each code segment.

[0013] According to another aspect of the embodiments of this application, a software vulnerability analysis report generation apparatus is also provided, comprising: an acquisition unit, configured to acquire audit information of a software vulnerability, wherein the audit information includes vulnerability description information, remediation suggestions, and code examples; a generation unit, configured to generate code feature matching rules for the software vulnerability based on the audit information using a large language model, wherein the code feature matching rules are used to match code call patterns related to the software vulnerability in a target software project; a construction unit, configured to construct a call graph of the target software project, wherein the call graph is used to represent the call relationships between various software functions in the target software project; a detection unit, configured to detect the correlation between each code segment of the target software project and the software vulnerability based on the code feature matching rules and the call graph, wherein the correlation is used to assess the risk level of each code segment of the target software project; and a processing unit, configured to generate a software vulnerability analysis report for the target software project based on the correlation between each code segment of the target software project and the software vulnerability.

[0014] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, which stores a computer program, wherein when the computer program is executed, the device where the computer-readable storage medium is located executes the above-described method for generating a software vulnerability analysis report.

[0015] According to another aspect of the embodiments of this application, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by one or more processors, the one or more processors cause the one or more processors to execute the above-described method for generating a software vulnerability analysis report.

[0016] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program or instructions, which, when executed by a processor, implement the above-described method for generating a software vulnerability analysis report.

[0017] In this application, the method for generating a software vulnerability analysis report first obtains audit information of the software vulnerability, including vulnerability description information, remediation suggestions, and code examples; then, using a large language model, it generates code feature matching rules for the software vulnerability based on the audit information, wherein the code feature matching rules are used to match the code call patterns related to the software vulnerability in the target software project; it constructs a call graph of the target software project, wherein the call graph is used to represent the call relationships between various software functions in the target software project; it detects the correlation between each code segment of the target software project and the software vulnerability based on the code feature matching rules and the call graph, wherein the correlation is used to assess the risk level of each code segment of the target software project; and finally, it generates a software vulnerability analysis report for the target software project based on the correlation between each code segment of the target software project and the software vulnerability.

[0018] As described above, the method for generating the software vulnerability analysis report in this application first obtains detailed audit information about a specific software vulnerability, including the vulnerability description, remediation suggestions, and code examples containing the vulnerability. Compared to traditional software component analysis tools that rely solely on matching component lists with vulnerability databases, this application's method introduces a richer vulnerability context, enabling the system to conduct more in-depth analysis based on actual vulnerability scenarios. The subsequent large language model can automatically generate matching rules for specific vulnerabilities, not only covering a wider range but also adapting to more complex call scenarios, improving detection accuracy and efficiency. The construction of the call graph provides a clear code structure view for subsequent correlation analysis, allowing the system to trace the path of specific function calls and determine whether a vulnerability can be triggered in a specific context. Then, combining code feature matching rules and the call graph, intelligent correlation calculation automatically identifies truly exploitable vulnerabilities in the code, avoiding the arduous task of manual review and reducing the risk of misjudgment. Finally, based on the correlation between each code segment and the software vulnerability, the system generates a detailed software vulnerability analysis report, solving the technical problem that existing open-source software vulnerability detection tools cannot accurately assess the true impact of vulnerabilities in specific project contexts. Attached Figure Description

[0019] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0020] Figure 1 This is a flowchart of a method for generating a software vulnerability analysis report according to an embodiment of this application;

[0021] Figure 2 This is a schematic diagram of a context association analysis function call according to an embodiment of this application;

[0022] Figure 3 This is a schematic diagram of the complete technical solution of the method for generating a software vulnerability analysis report according to an embodiment of this application;

[0023] Figure 4 This is a schematic diagram of a software vulnerability analysis report generation apparatus according to an embodiment of this application. Detailed Implementation

[0024] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0025] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0026] According to the embodiments of this application, a software vulnerability analysis report generation system (hereinafter referred to as the system) can be used as the execution subject of the software vulnerability analysis report generation method of this application embodiment. The software vulnerability analysis report generation system can be a software system or an embedded system combining software and hardware. Of course, the method execution subject in the embodiments of this application can also be other forms of execution subject, such as devices or equipment. Those skilled in the art should know that this application does not particularly limit the specific form of the method execution subject.

[0027] Figure 1 This is a flowchart of a method for generating a software vulnerability analysis report according to an embodiment of this application, such as... Figure 1 As shown, the method includes the following steps:

[0028] Step S101: Obtain audit information for the software vulnerability, including vulnerability description information, remediation suggestions, and code examples.

[0029] Audit information comprises a series of data used to assess the details of software vulnerabilities, including vulnerability descriptions, remediation recommendations, and code examples. The vulnerability descriptions cover the nature, scope, and triggering conditions of the vulnerability; the remediation recommendations provide specific steps to fix the vulnerability; and the code examples visually demonstrate how the vulnerability manifests in actual code, helping to understand how the vulnerability is presented.

[0030] Optionally, vulnerability information related to components in the project can be collected by calling interface functions of authoritative vulnerability databases or using software composition analysis tools from open-source projects to parse the project's dependency files. Simultaneously, existing vulnerability reports are analyzed using a large language model to extract vulnerability descriptions, remediation suggestions, and sample code, which are then stored in a structured format to provide input for subsequent steps. These steps ensure that the starting point for vulnerability analysis is accurate, reducing the possibility of false positives and false negatives, and providing a favorable foundation for subsequent intelligent analysis and code feature matching rule generation.

[0031] Step S102: Using a large language model, code feature matching rules are generated based on audit information to target software vulnerabilities. The code feature matching rules are used to match code call patterns related to software vulnerabilities in the target software project.

[0032] Optionally, the large language model is an artificial intelligence model with deep learning capabilities, capable of understanding and generating complex natural language text, including but not limited to human language and programming languages. In the embodiments of this application, the large language model is trained to learn the characteristics of vulnerabilities from vulnerability description information and transform the characteristics into detectable code patterns or regular expressions.

[0033] Optionally, the audit information includes a comprehensive description of the software vulnerability, including a detailed description of the vulnerability (such as how the vulnerability is triggered, its scope of impact, and potential harm), official or community-provided remediation suggestions (such as version updates and code modification suggestions), and actual code examples of the vulnerability. The audit information forms the basis for generating code feature matching rules for the large model, ensuring the accuracy and applicability of the rules.

[0034] Optionally, code feature matching rules are rules used to identify specific code patterns. These rules can be regular expressions, code snippet templates, or specific syntax structures. They can help detect code call patterns related to known vulnerabilities in a target software project, thereby determining whether the project has potential security risks.

[0035] Optionally, firstly, the system formats the collected software vulnerability audit information into an input format that the large language model can understand. This may involve preprocessing the text data, such as removing irrelevant information, standardizing terminology, and ensuring the structure of the input data. Then, the system inputs the preprocessed audit information into a pre-trained large language model. The model learns the characteristics of the vulnerability by analyzing keywords in the vulnerability description, code modification instructions in the remediation suggestions, and specific implementations in the code examples, and generates code feature matching rules. The generated code feature matching rules need to be tested and validated to improve the accuracy of software vulnerability detection. The testing process includes testing the recall and precision of the code feature matching rules on code samples with known vulnerabilities, and adjusting and optimizing the rules as necessary to improve their detection efficiency. Validated code feature matching rules can be integrated into software security analysis tools for subsequent vulnerability scanning of target software projects. The system applies the rules to the code in the target software project to identify potential vulnerability call patterns.

[0036] Optionally, code feature matching rules automatically generated by a large language model can more accurately capture vulnerability features in the code, avoiding false positives common in traditional software component analysis tools. It can also detect vulnerabilities in specific contexts, improving detection coverage and accuracy. Based on the learning capabilities of the large model, rules are automatically generated and quickly adapted to emerging vulnerability types and triggering mechanisms without requiring manual updates to the rule base, thus improving the flexibility and response speed of vulnerability detection.

[0037] Alternatively, in this application, an optional large-model interaction engine is designed as follows:

[0038] Input construction:

[0039] Combine vulnerability description, remediation suggestions, and code examples into a warning message:

[0040] "Description of known vulnerability X: An attacker can..." {jndi:ldap: / / } enables remote code execution.

[0041] Please generate a regular expression for the code signature to detect this vulnerability, which should match the relevant dangerous patterns in Java.

[0042] Output processing:

[0043] Receive large model output: Regular expression 1;

[0044] Verify the validity of the regular expression: Verify that the test recall rate of regular expression 1 in the historical sample set related to vulnerability X is >95%.

[0045] For example, the target software project uses a version of a target plugin that contains vulnerability X. Audit information indicates that vulnerability X can be exploited... The specific code pattern {jndi:ldap: / / } enables remote code execution. Based on this information, the large language model generates code feature matching rules. These rules can precisely match code segments in Java code that contain the vulnerability signature of vulnerability X. Subsequently, applying these rules to search the project code allows for rapid location of all potentially vulnerable code positions, which can then be further combined with the call graph for risk assessment.

[0046] Step S103: Construct a call graph for the target software project, wherein the call graph is used to represent the call relationships between various software functions in the target software project.

[0047] Optionally, a call graph is a graphical representation used to show the call relationships between functions, methods, or modules in a software project. Call graphs not only reveal direct calls but also reflect indirect calls and the data and control flow between functions, providing an intuitive view for analyzing code behavior and vulnerability triggering conditions. Through call graphs, it's possible to track how specific vulnerability characteristics propagate in the code, identify which code segments are in the potential vulnerability impact chain, and help to better assess vulnerability risks.

[0048] Step S104: Detect the correlation between each code segment of the target software project and the software vulnerability based on code feature matching rules and call graphs, wherein the correlation is used to assess the risk level of each code segment of the target software project.

[0049] Optionally, correlation refers to the strength of the connection between a code snippet and a specific software vulnerability, and the correlation determines the risk level of the code snippet. By combining code feature matching rules and call graphs, it is possible to assess whether a code snippet contains vulnerability features and in what context they can be triggered.

[0050] Optionally, the generated code feature matching rules are applied to the call graph. By deeply analyzing whether each code snippet matches the rules and whether it is on a specific call path, its correlation with software vulnerabilities is determined. For example, through abstract syntax tree analysis, data flow tracing is simulated to check whether function calls in code snippets meet vulnerability triggering conditions, thereby determining their risk level. By intelligently determining which code snippets truly contain exploitable vulnerabilities and the potential threat level of these vulnerabilities, the excessive false positives or false negatives of traditional tools are avoided. At the same time, more specific vulnerability location and contextual information are provided, facilitating rapid response and remediation.

[0051] Figure 2 This diagram illustrates the context-based analysis function call process. First, the vulnerability function is called to identify potential entry points for vulnerabilities in the software supply chain. Following this, function A is executed. Function A can be any functional module in the project, and its role may include data processing, business logic execution, etc. After function A completes execution, its output can be used as input for function B. Function B may be responsible for network communication, data storage, or user interface updates. Next, UserController.login() is executed. UserController.login() is the crucial user authentication or login processing function. The execution of UserController.login() may involve user input, authentication, and permission checks. Finally, the result is sent as input to an HTTP request parameter.

[0052] Step S105: Generate a software vulnerability analysis report for the target software project based on the correlation between each code snippet and the software vulnerability.

[0053] Optionally, the software vulnerability analysis report is the final output based on the above analysis process. It includes information on the discovered vulnerabilities, the risk level of each code snippet, and remediation suggestions to guide the software development team in vulnerability identification and remediation.

[0054] Optionally, based on the correlation between the detected code snippets and software vulnerabilities, relevant information, including the vulnerability ID, description, component information, call path, risk level, and remediation recommendations, is integrated to generate a structured vulnerability analysis report. The report records each discovered issue, facilitating understanding and action. The generated report simplifies the manual auditing process, significantly reduces auditing costs, and provides remediation guidelines, helping to improve the security of the software supply chain and the overall quality of software projects, thereby increasing the efficiency and speed of response to and remediation of software security vulnerabilities. Through vulnerability localization and prioritization, the risk of misjudgment that may arise from automated tool scoring is reduced, contributing to the targeted and effective remediation of vulnerabilities.

[0055] Figure 3 This paper illustrates the workflow for generating a software vulnerability analysis report. The process begins with a detailed examination of the target project's codebase, then branches into two complementary analysis paths, both dedicated to assessing the impact of vulnerabilities in open-source software components. The first path enters the software bill of materials (BOM) generation module, which parses project dependencies and constructs the BOM, listing every software component used in the project and its corresponding version, providing a component perspective for subsequent in-depth analysis. Next, the component vulnerability list module compares the BOM with a vulnerability database to filter out known vulnerabilities related to project components, forming a targeted vulnerability list ready for use by the large model interaction engine. The engine dynamically generates code feature matching rules—i.e., regular expressions—for specific vulnerabilities using complex natural language and code understanding mechanisms. These regular expressions are then sent to a regular expression matching scanner, which quickly searches the project's source code for code segments that match the rules, accurately marking the locations where potential vulnerabilities may exist.

[0056] Meanwhile, the second branch focuses on the internal structure and behavioral patterns of the code, starting directly from the target project's codebase and entering the abstract syntax tree parser. The parser transforms the source code into an abstract syntax tree, allowing for a deeper understanding of the code's syntactic structure and semantics. Once the abstract syntax tree is generated, the function call graph is constructed, depicting the call relationships between various functions in the project, encompassing both direct and indirect calls, forming a visual representation of the code execution path. Subsequently, with the assistance of the call chain tracer, the context of each function call can be deeply analyzed, identifying how data and control flow are passed and changed between different calls, thereby revealing potential vulnerability triggering conditions and propagation paths.

[0057] Ultimately, the rich information from the two branches converges at the audit report generator. The generator integrates the software bill of materials, component vulnerability list, code signature matching results, and call chain tracing information to weave a detailed software vulnerability analysis report. The report not only lists suspicious code snippets and their vulnerability correlations but also includes call graphs to visually demonstrate the potential impact of vulnerabilities on the project. This report, along with the initial automated analysis results, is submitted to the human audit stage. Security experts conduct in-depth reviews, refining the report until it is confirmed to be error-free. The entire process is interconnected, leveraging the efficiency and accuracy of artificial intelligence while retaining the professional judgment and meticulous attention of human auditors. This achieves a combination of intelligent and professional software security auditing, improving both the quality and efficiency of the audit.

[0058] In one optional embodiment, a large language model is used to generate code feature matching rules for software vulnerabilities based on audit information. This includes: constructing a composite prompt consisting of vulnerability description information, remediation suggestions, and code examples; interacting the composite prompt with the large language model, which outputs initial feature matching rules; performing target processing on the initial feature matching rules, including semantic parsing and format standardization; using known vulnerability code samples to detect the sample detection recall and sample detection accuracy of the initial feature matching rules; and generating code feature matching rules for software vulnerabilities based on the sample detection recall and sample detection accuracy.

[0059] Optionally, composite prompts are carefully designed instructions that combine vulnerability descriptions, remediation suggestions, and code examples. Their purpose is to guide the large language model to understand the nature of the vulnerability from multiple perspectives, thereby generating more accurate feature-matching rules. The vulnerability description includes key details such as the vulnerability type, triggering conditions, and scope of impact; the remediation suggestions indicate the steps and methods for vulnerability remediation; and the code examples visually demonstrate how the vulnerability manifests in actual code. By integrating these three information types, composite prompts provide a clear guiding framework for the large model, helping to improve the quality of rule generation.

[0060] Optionally, upon receiving a complex warning message, the large language model can attempt to interpret the vulnerability characteristics within it and output preliminary feature matching rules. These preliminary feature matching rules are typically expressed in the form of regular expressions, code patterns, etc., and are used for subsequent code scanning and vulnerability detection. The interaction with the large language model is the core innovation of the entire process. Utilizing AI technology to automatically generate code feature matching rules alleviates the problems of incomplete rule base coverage and high false positive rates in traditional software component analysis tools.

[0061] Optionally, target processing refers to the optimization activities performed on the rules after the large model output, including semantic parsing and format standardization. Semantic parsing ensures that the rules can correctly understand the intent of the code, rather than simply matching text patterns; format standardization ensures the uniformity and compatibility of the rules, facilitating subsequent application and maintenance.

[0062] Optionally, known vulnerable code samples are selected from authoritative vulnerability databases, including vulnerability databases, and are code snippets confirmed to contain vulnerabilities. These samples are used to test the effectiveness of the feature matching rules. Sample detection recall reflects the rule's ability to capture truly vulnerable code, while sample detection accuracy measures the probability of false positives in code without vulnerabilities. By testing known vulnerable code samples, the detection performance of the rules, including accuracy and reliability, can be objectively evaluated. Continuous iteration and optimization help the rules accurately locate vulnerabilities in real-world software projects.

[0063] Optionally, after building, interacting, and optimizing, the final generated code feature matching rule is a customized, validated code detection rule used to match code call patterns related to specific vulnerabilities in the target software project. The generated rule can not only accurately identify vulnerable code in the project but also reduce false positives and false negatives, improving the efficiency and accuracy of software security auditing.

[0064] In one optional embodiment, code feature matching rules for software vulnerabilities are generated based on sample detection recall and sample detection accuracy, including: adjusting the initial feature matching rules at least once when the sample detection recall is detected to be lower than a preset recall or the sample detection accuracy is detected to be lower than a preset accuracy, until the adjustment of the initial feature matching rules is stopped after the sample detection recall of the adjusted initial feature matching rules is detected to be no lower than a preset recall and no lower than a preset accuracy; and using the last adjusted initial feature matching rules as code feature matching rules.

[0065] Optionally, the sample detection recall measures the proportion of truly positive samples among all positive samples identified by the model; the sample detection precision measures the proportion of items identified as positive samples that are actually positive samples. Sample detection recall and precision comprehensively reflect the rule's detection capability and false positive rate. By setting preset recall and precision, the initial feature matching rules are repeatedly tested and adjusted. This iterative optimization process ensures that the final generated rules can comprehensively cover truly vulnerable code (high recall) and accurately distinguish between vulnerable code and normal code, avoiding false positives (high precision). The adjustment process ends when the detection results meet these two preset standards.

[0066] Optionally, adjusting the initial feature matching rules involves intelligent iteration at the algorithm level, which may include fine-tuning regular expressions, adding or removing specific code features. This adjustment gradually improves performance through subtle changes while maintaining the basic framework of the rules. Each adjustment is an attempt to optimize rule performance, aiming to achieve higher recall and accuracy in sample detection callbacks. The adjustment process may require multiple iterations until the rules' performance stabilizes and meets preset standards. Through intelligent iteration, the range of false positives can be gradually narrowed, while increasing the ability to detect genuine vulnerabilities.

[0067] Optionally, the stopping criterion is a pre-defined threshold that specifies when to terminate the adjustment of the initial feature matching rule. The stopping criterion is typically based on sample detection recall and sample detection accuracy; the adjustment process stops when both metrics meet the preset requirements. The stopping criterion not only reduces endless iterations and over-optimization but also ensures that the rule's detection performance meets expectations.

[0068] Optionally, the final adjusted initial feature matching rule is the version that passes all tests and meets the stopping criteria after the iterative optimization process is completed. This final rule serves as the final code feature matching rule and will be effective in actual vulnerability detection. Determining a final, optimally performing code feature matching rule for a comprehensive scan of the project code not only allows for the rapid and accurate identification of potentially vulnerable code snippets but also improves the speed and accuracy of software security analysis, reduces manual intervention, and accelerates the vulnerability remediation process.

[0069] In one optional embodiment, a composite prompt consisting of vulnerability description information, remediation suggestions, and code examples is constructed, including: setting a heuristic question list, output text instructions, and context information, wherein the heuristic question list is used to guide the large language model to focus on key features in the code, the output text instructions are used to constrain the format of the code feature matching rules generated by the large language model, and the context information is used to construct the application context of the code feature matching rules; based on the heuristic question list, output text instructions, and context information, a composite prompt consisting of vulnerability description information, remediation suggestions, and code examples is constructed.

[0070] Optionally, a heuristic question list is used to guide the large language model to focus on specific code features related to the vulnerability. The question list focuses on the vulnerability's triggering conditions, the key syntactic structures of the vulnerable code, and the code modifications involved in the vulnerability remediation, ensuring that the model can cover the multidimensional features of the vulnerability when generating matching rules. By setting a heuristic question list, the large language model can be effectively guided to pay more detailed attention to key features directly related to the vulnerability when processing vulnerability information, thereby generating more accurate code feature matching rules.

[0071] Optionally, the output text instructions define the format requirements for the code feature matching rules generated by the large language model. Output text instructions may include, but are not limited to, specific structures of regular expressions, the use of syntax templates, or the output context of the matching rules. Setting these instructions contributes to the consistency and readability of rule generation, facilitating subsequent rule validation and application.

[0072] Optionally, contextual information supplements the vulnerability description, remediation suggestions, and code examples with background information. It is used to construct the application context for code feature matching rules, including but not limited to the specific environmental conditions of the vulnerability, the runtime state of the code, and the logical flow of vulnerability triggering. The richness of the contextual information affects the applicability of the rules and the detection accuracy. The construction of contextual information ensures that the generated code feature matching rules can accurately identify vulnerabilities in specific software environments without generating excessive false positives or false negatives.

[0073] Optionally, the composite prompt combines vulnerability descriptions, remediation suggestions, code examples, a list of heuristic questions, output text instructions, and contextual information to form a command that guides the large language model in generating code feature matching rules. The composite prompt is the starting point of the entire analysis process and the cornerstone for ensuring the quality of rule generation. By constructing composite prompts, the large language model can be guided to consider multiple aspects of vulnerability characteristics, applicable contextual environments, and rule format requirements when generating code feature matching rules.

[0074] In one optional embodiment, constructing a call graph for the target software project includes: converting the source code of the target software project into multiple lexical units; constructing an abstract syntax tree based on the multiple lexical units; performing control flow analysis based on the abstract syntax tree to obtain function call statements in the source code; constructing a control flow graph based on the function call statements, wherein the control flow graph is used to describe the execution order of code blocks and the transfer path of control flow in the program, the control flow graph represents code segments through nodes and transfer paths of control flow through edges; and generating a call graph based on the control flow graph.

[0075] Optionally, lexical units are the basic components of source code, including keywords, identifiers, numbers, strings, and operators. A lexical analyzer breaks down the source code into meaningful language elements, laying the foundation for subsequent syntax analysis and call graph construction. Lexical analysis is the first stage of the compiler and parser, ensuring the accuracy of subsequent abstract syntax tree construction.

[0076] Alternatively, an Abstract Syntax Tree (AST) is a tree-like structure of source code. ASTs ignore the surface format of the source code, focusing only on its syntactic and structural meaning. AST nodes represent code elements, and edges represent the syntactic relationships between elements, such as function calls and conditional branches. Constructing an AST clearly shows the control structure and data flow of the code, providing a clear framework for subsequent control flow analysis and call graph construction. Through an AST, it is possible to identify which code segments constitute function calls and the call relationships between them.

[0077] Optionally, control flow analysis is a program analysis technique used to understand and predict the execution path of source code under different conditions and inputs. By performing a depth-first traversal of the nodes and edges in the abstract syntax tree, function call statements and the control flow relationships between them can be identified. Control flow analysis can accurately capture the dynamic characteristics of function calls in the source code, including the preconditions of the call, the call path, and the control flow direction after the call, providing information for further construction of the call graph.

[0078] Alternatively, a control flow graph is a graphical representation of the order of code blocks and the jump paths of control flow during program execution. Nodes in a control flow graph represent code segments, while edges represent paths through which control flow moves from one code segment to another. Constructing a control flow graph provides a more intuitive representation of function calls and their contextual relationships during program execution. Control flow graphs not only show the order of calls but also reflect the complexity of code execution paths caused by conditional statements (such as if, switch-case), loops, and other control structures.

[0079] Optionally, a call graph is a specialized form of control flow graph, focusing specifically on function call relationships. A call graph uses nodes to represent functions or methods and edges to represent calls from one function to another, displaying the call chain of all functions in a project. The purpose of generating a call graph is to create a comprehensive function call network to facilitate subsequent detection of context-sensitive vulnerabilities.

[0080] In one optional embodiment, generating a call graph based on a control flow graph includes: determining parameter passing paths and code execution flow based on the control flow graph; creating nodes representing code functions based on the parameter passing paths and code execution flow; determining connection relationships between nodes based on the call relationships between code functions; and generating a call graph based on the nodes representing code functions and the connection relationships between nodes.

[0081] Optionally, the parameter passing path is the path of a data variable or parameter from its definition point to its usage point in the control flow graph, especially when function calls are involved, where parameters are passed from one code segment to the next. The code execution flow refers to the path of control flow during program execution. Determining the parameter passing path and code execution flow allows for a better understanding of the context of each function call, including the state before the call, the flow of parameters during the call, and the direction of control flow after the call. Determining the parameter passing path and code execution flow is fundamental to creating a call graph and helps identify which function calls may affect or be affected by other functions.

[0082] Optionally, nodes representing code functions are used in the call graph to represent graphical elements of functions or methods. Each node contains the function's name, version information, and its position in the call graph. Representing code functions is not only the basic building block of the call graph but also a reference point in subsequent analysis. By using nodes representing code functions, the abstract code execution units in the control flow graph are visualized as graphical elements, facilitating the observation and analysis of function call structures.

[0083] Optionally, the connections between nodes reflect the dependencies and calling order of functions in the function call graph. Each connection edge not only indicates the direction of the call but may also carry information about the calling conditions, parameter passing, etc., making it an important component of the call graph.

[0084] Optionally, a call graph illustrates the call structure of all code functions in the project, including direct and indirect calls, as well as parameter passing and control flow transitions between function calls. The call graph demonstrates the call relationships between functions in the project, which helps identify and assess the potential harm and propagation paths of software vulnerabilities.

[0085] In one optional embodiment, detecting the correlation between each code segment of the target software project and a software vulnerability based on code feature matching rules and a call graph includes: applying code feature matching rules to perform static analysis on the source code of the target software project, wherein the static analysis is used to detect code features in the source code related to the software vulnerability and record the position of the code features in the call graph; performing a search operation on the call graph based on the position of the code features in the call graph, wherein the search operation is used to trace the information transmission path from external input information to potentially vulnerable code; detecting whether the information transmission path meets the software vulnerability triggering conditions; and, if the information transmission path is detected to meet the software vulnerability triggering conditions, determining the correlation between the code segment and the software vulnerability based on the number of code features related to the software vulnerability and the feature weight value of each code segment.

[0086] Optionally, static analysis is a software analysis method that does not require actual program execution. It primarily discovers potential defects or vulnerabilities by examining source code, bytecode, or binary code. Code feature matching rules are the core technology in static analysis, which can identify and mark specific patterns or structures in the code. The identified patterns or structures may indicate the existence of known software vulnerabilities. Through static analysis, the location of each code feature can be recorded, preparing data for subsequent call graph analysis.

[0087] Optionally, the information transmission path is the data flow path in the call graph, starting from external input and ending at the potentially vulnerable code. Based on the code feature locations recorded in static analysis, a search operation is performed on the call graph to trace all information transmission paths, especially those that might allow external input to reach the potentially vulnerable code. This not only identifies direct call relationships but also takes into account more complex indirect calls and conditional branches, thereby assessing the likelihood of vulnerability triggering.

[0088] Optionally, the triggering condition for a software vulnerability is a specific environment or input condition required to exploit the vulnerability. For example, an SQL injection vulnerability might require an uncontrolled input parameter to be directly appended to an SQL query. By analyzing the location of code features and the path in the call graph, it can be determined whether the path meets the triggering condition, thereby assessing the actual threat of the vulnerability.

[0089] Optionally, the correlation between a code snippet and a software vulnerability is an indicator that measures the number of code features related to the vulnerability within the snippet and their potential harm. It is typically calculated by combining the number of features and their weight values, where the weight values ​​reflect the degree to which a specific code feature contributes to the vulnerability triggering. After confirming that the information transmission path meets the vulnerability triggering conditions, calculating the correlation of each code snippet quantifies the extent to which the code snippet is affected by the vulnerability. This helps prioritize high-risk code and provides direction for subsequent vulnerability remediation.

[0090] Figure 4 This is a schematic diagram of an optional software vulnerability analysis report generation apparatus according to an embodiment of this application. According to another aspect of an embodiment of this application, a software vulnerability analysis report generation apparatus is also provided, including: an acquisition unit 401, a generation unit 402, a construction unit 403, a detection unit 404, and a processing unit 405.

[0091] The system comprises the following components: an acquisition unit 401, used to acquire audit information of software vulnerabilities, including vulnerability descriptions, remediation suggestions, and code examples; a generation unit 402, used to generate code feature matching rules for software vulnerabilities based on the audit information using a large language model, wherein the code feature matching rules are used to match code call patterns related to software vulnerabilities in the target software project; a construction unit 403, used to construct a call graph of the target software project, wherein the call graph represents the call relationships between various software functions in the target software project; a detection unit 404, used to detect the correlation between each code segment of the target software project and the software vulnerability based on the code feature matching rules and the call graph, wherein the correlation is used to assess the risk level of each code segment of the target software project; and a processing unit 405, used to generate a software vulnerability analysis report for the target software project based on the correlation between each code segment of the target software project and the software vulnerability.

[0092] Optionally, the generation unit 402 includes: a composite prompt generation subunit, used to construct a composite prompt consisting of vulnerability description information, remediation suggestions, and code examples; an interaction subunit, used to interact the composite prompt with a large language model, which outputs initial feature matching rules; a target processing subunit, used to perform target processing on the initial feature matching rules, wherein the target processing includes: semantic parsing and format standardization; a detection unit, used to detect the sample detection recall and sample detection accuracy of the initial feature matching rules using known vulnerability code samples; and a generation subunit, used to generate code feature matching rules for software vulnerabilities based on the sample detection recall and sample detection accuracy.

[0093] Optionally, the generation subunit further includes: an adjustment module, used to adjust the initial feature matching rule at least once when the sample detection recall rate is detected to be lower than the preset recall rate or the sample detection accuracy is detected to be lower than the preset accuracy, until the adjustment of the initial feature matching rule is stopped after the sample detection recall rate of the adjusted initial feature matching rule is detected to be no lower than the preset recall rate and the sample detection accuracy is no lower than the preset accuracy; and a feature matching module, used to use the last adjusted initial feature matching rule as the code feature matching rule.

[0094] Optionally, the composite prompt generation subunit further includes: a first generation module, used to set a list of heuristic questions, output text instructions, and context information, wherein the list of heuristic questions is used to guide the large language model to focus on key features in the code, the output text instructions are used to constrain the format of the code feature matching rules generated by the large language model, and the context information is used to construct the application context of the code feature matching rules; and a second generation module, used to construct a composite prompt consisting of vulnerability description information, remediation suggestions, and code examples based on the list of heuristic questions, output text instructions, and context information.

[0095] Optionally, the construction unit 403 includes: a source code conversion subunit for converting the source code of the target software project into multiple lexical units; an abstract syntax tree construction subunit for constructing an abstract syntax tree based on the multiple lexical units; a control flow analysis unit for performing control flow analysis based on the abstract syntax tree to obtain function call statements in the source code; a control flow graph construction subunit for constructing a control flow graph based on the function call statements, wherein the control flow graph describes the execution order of code blocks and the transfer path of control flow in the program, and the control flow graph represents code segments through nodes and transfer paths of control flow through edges; and a call graph generation subunit for generating a call graph based on the control flow graph.

[0096] Optionally, the call graph generation subunit includes: a first determining module, used to determine the parameter passing path and code execution flow based on the control flow graph; a creation module, used to create nodes representing code functions based on the parameter passing path and code execution flow; a second determining module, used to determine the connection relationship between nodes based on the call relationship between each code function; and a call graph generation module, used to generate a call graph based on the nodes representing code functions and the connection relationship between each node.

[0097] Optionally, the detection unit 404 includes: a static analysis subunit, used to perform static analysis on the source code of the target software project using code feature matching rules, wherein the static analysis is used to detect code features related to software vulnerabilities in the source code and record the position of the code features in the call graph; a search subunit, used to perform a search operation on the call graph based on the position of the code features in the call graph, wherein the search operation is used to trace the information transmission path from external input information to potentially vulnerable code; a detection subunit, used to detect whether the information transmission path meets the software vulnerability triggering conditions; and a correlation determination subunit, used to determine the correlation between the code segment and the software vulnerability based on the number of code features related to the software vulnerability and the feature weight value of each code segment when the information transmission path is detected to meet the software vulnerability triggering conditions.

[0098] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, which stores a computer program, wherein when the computer program is executed, the device where the computer-readable storage medium is located executes the above-described method for generating a software vulnerability analysis report.

[0099] According to another aspect of the embodiments of this application, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by one or more processors, the one or more processors cause the one or more processors to execute the above-described method for generating a software vulnerability analysis report.

[0100] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program or instructions, which, when executed by a processor, implement the above-described method for generating a software vulnerability analysis report.

[0101] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0102] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0103] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0104] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0105] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0106] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0107] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for generating a software vulnerability analysis report, characterized in that, include: Obtain audit information for software vulnerabilities, wherein the audit information includes vulnerability description information, remediation suggestions, and code examples; Using a large language model, code feature matching rules are generated based on the audit information to target the software vulnerability. The code feature matching rules are used to match the code call patterns related to the software vulnerability in the target software project. Construct a call graph for the target software project, wherein the call graph is used to represent the call relationships between various software functions in the target software project; The correlation between each code segment of the target software project and the software vulnerability is detected based on the code feature matching rules and the call graph, wherein the correlation is used to assess the risk level of each code segment of the target software project; A software vulnerability analysis report for the target software project is generated based on the correlation between each code snippet of the target software project and the software vulnerability.

2. The method for generating a software vulnerability analysis report according to claim 1, characterized in that, Using a large language model, code feature matching rules are generated based on the audit information to target the software vulnerability, including: Construct a composite message consisting of the vulnerability description information, the remediation suggestions, and the code example; The composite prompt is interacted with the large language model, and the large language model outputs the initial feature matching rules; The initial feature matching rules are subjected to target processing, wherein the target processing includes: semantic parsing and format standardization; Using known vulnerable code samples, the sample detection recall and sample detection accuracy of the initial feature matching rule are tested; Based on the sample detection recall rate and the sample detection accuracy, code feature matching rules are generated for the software vulnerability.

3. The method for generating a software vulnerability analysis report according to claim 2, characterized in that, Based on the sample detection recall and the sample detection accuracy, code feature matching rules are generated for the software vulnerability, including: If the sample detection recall rate is lower than the preset recall rate or the sample detection accuracy is lower than the preset accuracy, the initial feature matching rule is adjusted at least once until the sample detection recall rate of the adjusted initial feature matching rule is not lower than the preset recall rate and the sample detection accuracy is not lower than the preset accuracy, then the adjustment of the initial feature matching rule is stopped. The initial feature matching rule after the last adjustment is used as the code feature matching rule.

4. The method for generating a software vulnerability analysis report according to claim 2, characterized in that, Construct a composite message consisting of the vulnerability description information, the remediation suggestions, and the code example, including: The system sets up a list of heuristic questions, output text instructions, and context information. The list of heuristic questions is used to guide the large language model to focus on key features in the code. The output text instructions are used to constrain the format of the code feature matching rules generated by the large language model. The context information is used to construct the application context of the code feature matching rules. Based on the heuristic question list, output text instructions, and context information, a composite prompt is constructed, consisting of the vulnerability description information, the remediation suggestions, and the code example.

5. The method for generating a software vulnerability analysis report according to claim 1, characterized in that, Constructing the call graph of the target software project includes: The source code of the target software project is converted into multiple lexical units; Construct an abstract syntax tree based on the multiple lexical units; Based on the abstract syntax tree, control flow analysis is performed to obtain the function call statements in the source code; A control flow graph is constructed based on the function call statements. The control flow graph is used to describe the execution order of code blocks in the program and the transfer path of control flow. The control flow graph represents code segments through nodes and transfer paths of control flow through edges. The call graph is generated based on the control flow graph.

6. The method for generating a software vulnerability analysis report according to claim 5, characterized in that, Generating the call graph based on the control flow graph includes: The parameter passing path and code execution flow are determined based on the control flow graph. Nodes representing code functions are created based on the parameter passing path and code execution flow; The connection relationships between each node are determined based on the calling relationships between each of the code functions. The call graph is generated based on the nodes that represent the code functions and the connections between the nodes.

7. The method for generating a software vulnerability analysis report according to claim 1, characterized in that, Based on the code feature matching rules and the call graph, the correlation between each code segment of the target software project and the software vulnerability is detected, including: The code feature matching rules are applied to perform static analysis on the source code of the target software project, wherein the static analysis is used to detect code features in the source code related to the software vulnerability and record the position of the code features in the call graph; Based on the location of the code features in the call graph, a search operation is performed on the call graph, wherein the search operation is used to trace the information transmission path from external input information to potentially vulnerable code; Detect whether the information transmission path meets the software vulnerability triggering conditions; If the information transmission path is found to meet the software vulnerability triggering conditions, the correlation between the code segment and the software vulnerability is determined based on the number of code features related to the software vulnerability and the feature weight value of each code segment.

8. A device for generating software vulnerability analysis reports, characterized in that, include: The acquisition unit is used to acquire audit information of software vulnerabilities, wherein the audit information includes vulnerability description information, remediation suggestions, and code examples; The generation unit is used to generate code feature matching rules for the software vulnerability based on the audit information using a large language model, wherein the code feature matching rules are used to match the code call patterns related to the software vulnerability in the target software project; A construction unit is used to construct a call graph of the target software project, wherein the call graph is used to represent the call relationships between various software functions in the target software project; The detection unit is configured to detect the correlation between each code segment of the target software project and the software vulnerability based on the code feature matching rules and the call graph, wherein the correlation is used to assess the risk level of each code segment of the target software project; The processing unit is configured to generate a software vulnerability analysis report for the target software project based on the correlation between each code segment of the target software project and the software vulnerability.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed, the device on which the computer-readable storage medium is located performs the method for generating a software vulnerability analysis report as described in any one of claims 1 to 7.

10. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to perform the method for generating a software vulnerability analysis report as described in any one of claims 1 to 7.

11. A computer program product, characterized in that, It includes a computer program or instructions that, when executed by a processor, implement the method for generating a software vulnerability analysis report as described in any one of claims 1 to 7.

Images