Method, program product and device for vulnerability analysis based on large models and SAST

Abstract

Embodiments of the present application provide a vulnerability analysis method, program product and device based on a large model and SAST. The vulnerability analysis method based on a large model and SAST includes: generating a life cycle graph of any vulnerability in a vulnerability information library according to vulnerability information of the vulnerability; obtaining a code context where the vulnerability is located from a project code based on the life cycle graph; analyzing the code context by using a large model to obtain a vulnerability cause and an execution function of the vulnerability; backtracking to find an entry function of the vulnerability from the execution function in a global call graph; wherein the global call graph is generated by analyzing the project code by using a SAST tool; and outputting an analysis result of the vulnerability; wherein the analysis result includes the vulnerability cause, the execution function and the entry function. Embodiments of the present application can stably and accurately provide vulnerability exploitability information of various vulnerabilities in an open source project.

Description

Technical Field

[0001] This application relates to the field of software security technology, and more specifically, to a vulnerability analysis method, program product, and device based on large models and SAST. Background Technology

[0002] In recent years, an increasing number of enterprise development teams have adopted various open-source components to develop software. While this can reduce a lot of basic work and improve development efficiency, the widespread use of open-source software also exposes open-source projects, such as those that haven't been updated to patched versions, have private branches, or use vulnerabilities, to the risks posed by these vulnerabilities.

[0003] Traditional vulnerability analysis methods primarily involve matching the version numbers of open-source components in an open-source project with the version numbers of the open-source components containing each vulnerability as reported in vulnerability intelligence sources to determine if any vulnerabilities exist in the project. This vulnerability analysis method is not only prone to failure when the code snippets of open-source components are trimmed, renamed, obfuscated, or have their syntax modified, but it also lacks the ability to analyze complete taint propagation chains, making it difficult to further analyze the exploitability of vulnerabilities. Summary of the Invention

[0004] The purpose of this application is to provide a vulnerability analysis method, program product, and device based on large models and SAST, so as to achieve the technical effect of providing stable and accurate vulnerability exploitability information of various vulnerabilities in open source projects.

[0005] In a first aspect, embodiments of this application provide a vulnerability analysis method based on large models and SAST, including:

[0006] Generate a lifecycle diagram of the vulnerability based on the vulnerability information of any vulnerability in the vulnerability information database;

[0007] Based on the lifecycle diagram, the code context in which the vulnerability is located is obtained from the project code;

[0008] The code context is analyzed using a large model to determine the cause of the vulnerability and the function to be executed.

[0009] The entry function of the vulnerability is found by tracing back from the executed function in the global call graph; wherein, the global call graph is generated by analyzing the project code using the SAST tool;

[0010] Output the analysis results of the vulnerability; wherein the analysis results include the cause of the vulnerability, the execution function, and the entry function.

[0011] In the above implementation process, a lifecycle graph of a vulnerability is generated based on the vulnerability information of any vulnerability in the vulnerability information database. Based on the lifecycle graph, the code context in which the vulnerability is located is obtained from the project code. The code context is analyzed using a large model to obtain the vulnerability cause and execution function. In the global call graph generated by analyzing the project code using the SAST tool, the entry function of the vulnerability is traced back from the execution function. The vulnerability cause, execution function, and entry function are organized into the vulnerability analysis results output. It can analyze the vulnerability cause and execution function of the vulnerability by using the natural language understanding, processing, and learning capabilities of the large model to analyze the code context covering the vulnerability lifecycle in the project code. This ensures that the vulnerability cause and execution function of the vulnerability in the project code can be analyzed stably and accurately even if the project code is modified. In addition, for the global call graph generated by the SAST tool, the entry function of the vulnerability is traced back from the execution function as the taint convergence point. This ensures that the entry function that the vulnerability can reach externally in the project code is found in the complete and accurate global call graph. Thus, it can stably and accurately provide vulnerability exploitability information for various vulnerabilities in open source projects.

[0012] Furthermore, the vulnerability information includes multiple code change records related to the vulnerability;

[0013] The step of generating a lifecycle diagram of a vulnerability based on vulnerability information from any vulnerability database includes:

[0014] Filter the code change records used to fix the vulnerability from the multiple code change records;

[0015] From the multiple code change records, trace back from the fix code change records to find the code change records that introduced the vulnerability;

[0016] Using the repair code change record as the repair node and the import code change record as the import node, a connection edge is added between the import node and the repair node to generate the lifecycle graph.

[0017] In the above implementation process, by filtering the code change records used to fix the vulnerability from multiple code change records for the vulnerability, and by backtracking from the code change records used to introduce the vulnerability from the code change records used to fix the vulnerability, the code change records used to fix the vulnerability are used as the fix nodes and the code change records used to introduce the vulnerability are used as the introduction nodes, and connecting edges are added between the introduction nodes and the fix nodes to generate a vulnerability lifecycle graph. This can accurately generate a graph covering the vulnerability lifecycle based on the code change records used to introduce the vulnerability and the code change records used to fix the vulnerability.

[0018] Furthermore, the code change records meet one or more of the following filtering criteria:

[0019] The description information of the fix code change record or the associated pull request includes the vulnerability number of the vulnerability.

[0020] The code change information in the code fix change log includes the issue number associated with the vulnerability report.

[0021] The semantic category of the code change content is "repair"; wherein, the semantic category of the code change content is determined using the large model.

[0022] In the above implementation process, by considering various aspects such as the description information of the code change record, the associated pull request, the code change content, and the semantic category of the code change content, the code change record to be repaired can be selected from multiple code change records, which can ensure that the code change record to be repaired can be selected completely and accurately from multiple code change records.

[0023] Furthermore, after generating the lifecycle diagram of the vulnerability based on the vulnerability information of any vulnerability in the vulnerability information database, the method further includes:

[0024] If the credibility index of the lifecycle diagram fails to meet the standard, the lifecycle diagram will be updated in response to the user's update request.

[0025] In the above implementation process, by responding to the user's update request for the lifecycle graph when the credibility index of the vulnerability lifecycle graph is not up to standard, the lifecycle graph can be updated, which can ensure accurate acquisition of the code context in the project code that covers the vulnerability lifecycle.

[0026] Furthermore, the lifecycle graph includes an introduction node and a fix node, wherein the introduction node indicates the introduction code change record used to introduce the vulnerability, and the fix node indicates the fix code change record used to fix the vulnerability;

[0027] The step of obtaining the code context where the vulnerability resides from the project code based on the lifecycle diagram includes:

[0028] Based on the lifecycle diagram, the introduced code change record and the repair code change record are determined;

[0029] The version of the project code that includes the introduced code change record is determined as the baseline version, and the version of the project code that includes the repair code change record is determined as the target version;

[0030] The code context is constructed based on the code changes between the baseline version and the target version, as well as the risky code segments in the project code affected by the code changes.

[0031] In the above implementation process, by using the introduction and repair nodes based on the lifecycle graph, the introduction code change records and repair code change records are identified. The version of the project code that includes the introduction code change records is identified as the baseline version, and the version of the project code that includes the repair code change records is identified as the target version. Based on the code changes between the baseline version and the target version, as well as the risky code segments in the project code affected by the code changes, a code context is constructed. This can take into account the code changes between the baseline version and the target version, as well as the risky code segments in the project code affected by the code changes, and comprehensively and accurately obtain the code context where the vulnerability is located from the project code.

[0032] Furthermore, before analyzing the code context using a large model to obtain the cause of the vulnerability and the execution function, the method further includes:

[0033] Based on the code change files targeting the aforementioned vulnerability, generate a partial call graph;

[0034] The large model is used to determine whether the code context is missing a target code fragment based on the local call graph; if so, the target code fragment is added to the code context and the code context is updated.

[0035] In the above implementation process, a local call graph is generated based on the code change file targeting the vulnerability. A large model is used to determine whether the code context is missing the target code fragment based on the local call graph. If so, the target code fragment is added to the code context and the code context is updated. This can effectively avoid the code context from missing its dependent functions or methods, and ensure that the code context where the vulnerability is located is completely obtained from the project code.

[0036] Furthermore, the step of generating a local call graph based on the code change file targeting the vulnerability includes:

[0037] Obtain the project code snippet corresponding to the code change file from the project code;

[0038] Based on the code structure of the project code snippet, determine the calling relationships between the various calling objects in the project code snippet;

[0039] The local call graph is generated based on the call relationships between the various calling objects.

[0040] In the above implementation process, by obtaining the project code fragment corresponding to the code change file from the project code, and based on the code structure of the project code fragment, the calling relationship between each calling object in the project code fragment is determined. Based on the calling relationship between each calling object, a local call graph is generated. By analyzing the source code structure of the code change file, the calling relationship between each calling object in the code change file can be accurately identified, ensuring the accurate generation of the local call graph of the code change file.

[0041] Furthermore, the step of using a large model to analyze the code context to obtain the vulnerability's cause and execution function includes:

[0042] Using the large model, the code context is matched with pre-configured vulnerability and defect patterns, and the cause of the vulnerability is determined based on the matching results;

[0043] Using the aforementioned large model, the execution function is located within the code context based on the cause of the vulnerability.

[0044] In the above implementation process, by pre-configuring vulnerability and defect patterns, a large model is used to match the code context with each pre-configured vulnerability and defect pattern, and the cause of the vulnerability is determined based on the matching results. Then, based on the cause of the vulnerability, the execution function is located in the code context. This can ensure that even if the project code is modified, the cause of the vulnerability and the execution function in the project code can be analyzed stably and accurately, while improving the analysis speed of the cause of the vulnerability and the execution function.

[0045] Furthermore, the method also includes:

[0046] The execution function is formatted using the large model.

[0047] In the above implementation process, by using a large model to format the execution function of the vulnerability, it is convenient to directly reference the execution function in the subsequent patch generation stage.

[0048] Secondly, embodiments of this application provide a vulnerability analysis apparatus based on large models and SAST, comprising:

[0049] The lifecycle diagram generation module is used to generate a lifecycle diagram of any vulnerability in the vulnerability information database.

[0050] The code context acquisition module is used to obtain the code context where the vulnerability is located from the project code based on the lifecycle graph.

[0051] The first vulnerability analysis module is used to analyze the code context using a large model to obtain the vulnerability cause and the execution function;

[0052] The second vulnerability analysis module is used to trace back from the execution function in the global call graph to find the entry function of the vulnerability; wherein, the global call graph is generated by analyzing the project code using the SAST tool;

[0053] The analysis result output module is used to output the analysis results of the vulnerability; wherein, the analysis results include the cause of the vulnerability, the execution function, and the entry function.

[0054] Thirdly, embodiments of this application provide a computer program product, the computer program product including instructions, which, when executed by a computer, cause the computer to perform the method described above.

[0055] Fourthly, embodiments of this application provide an electronic device, including a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor; when the processor executes the computer program, it implements the method described above.

[0056] Fifthly, embodiments of this application provide a computer-readable storage medium, the computer-readable storage medium including a stored computer program; wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to perform the method described above. Attached Figure Description

[0057] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0058] Figure 1 A flowchart illustrating a vulnerability analysis method based on a large model and SAST provided in the first embodiment of this application;

[0059] Figure 2 This is a schematic diagram illustrating a process for establishing a vulnerability information database, as exemplified by the first embodiment of this application.

[0060] Figure 3 A schematic diagram of a vulnerability analysis device based on a large model and SAST provided for the second embodiment of this application;

[0061] Figure 4 This is a schematic diagram of the structure of an electronic device provided in the third embodiment of this application. Detailed Implementation

[0062] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0063] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0064] In recent years, an increasing number of enterprise development teams have adopted various open-source components to develop software. While this can reduce a lot of basic work and improve development efficiency, the widespread use of open-source software also exposes open-source projects, such as those that haven't been updated to patched versions, have private branches, or use vulnerabilities, to the risks posed by these vulnerabilities.

[0065] In related technologies, vulnerability analysis methods primarily involve matching the version numbers of open-source components in an open-source project with the version numbers of the open-source components containing each vulnerability as reported in vulnerability intelligence sources to determine if any vulnerabilities exist in the project. This vulnerability analysis method is not only prone to failure when the code snippets of open-source components are trimmed, renamed, obfuscated, or have their syntax modified, but it also lacks the ability to analyze complete taint propagation chains, making it difficult to further analyze vulnerability exploitability.

[0066] To address this, this application proposes a vulnerability analysis method based on a large model and SAST. It generates a vulnerability lifecycle graph from the vulnerability information in a vulnerability database. Based on the lifecycle graph, it obtains the code context where the vulnerability resides from the project code. The large model is then used to analyze the code context to obtain the vulnerability's cause and execution function. In the global call graph generated by analyzing the project code using the SAST tool, the entry function of the vulnerability is traced back from the execution function. The vulnerability cause, execution function, and entry function are then compiled into the vulnerability analysis results. This method can analyze the vulnerability cause and execution function from the code context covering the vulnerability lifecycle within the project code, utilizing the natural language understanding, processing, and learning capabilities of the large model. This ensures stable and accurate analysis of vulnerability causes and execution functions even after project code modifications. Furthermore, for the global call graph generated by the SAST tool, the entry function of the vulnerability is traced back from the execution function as the taint convergence point, ensuring that the entry function reaching the external system of the vulnerability in the project code is found in a complete and accurate global call graph. This provides stable and accurate information on the exploitability of various vulnerabilities in open-source projects.

[0067] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0068] The following is combined Figure 1 This application describes a vulnerability analysis method based on a large model and SAST. The method provided in this application can be executed by relevant terminal devices; the following description uses a user terminal as the execution subject.

[0069] Please refer to Figure 1 , Figure 1 This is a flowchart illustrating a vulnerability analysis method based on a large model and SAST, provided in the first embodiment of this application. The first embodiment of this application provides a vulnerability analysis method based on a large model and SAST, including steps S101-S105:

[0070] S101. Generate a lifecycle diagram of any vulnerability based on the vulnerability information in the vulnerability information database.

[0071] As an example, based on actual application needs, vulnerability information of multiple vulnerabilities is collected in advance to establish a vulnerability information database.

[0072] In practical applications, the vulnerability database stores vulnerability information for multiple vulnerabilities. The vulnerability information for each vulnerability includes the vulnerability number, the vulnerability PoC (Proof of Concept, code or method used to verify the existence of the vulnerability), the vulnerability report, multiple code change records (commits, which are snapshots containing code changes), the description information of each code change record in the multiple code change records, and the pull requests (PRs) associated with each code change record, etc.

[0073] For each vulnerability in the vulnerability database, a lifecycle diagram for that vulnerability is generated based on its vulnerability information.

[0074] It should be noted that a vulnerability lifecycle diagram is a map that indicates the entire process from the emergence of a vulnerability to its resolution, which is equivalent to a timeline covering the entire lifecycle of a vulnerability.

[0075] S102. Based on the lifecycle diagram, obtain the code context where the vulnerability is located from the project code.

[0076] As an example, after obtaining the lifecycle graph of the vulnerability, the code context in which the vulnerability resides is obtained from the project code of the open source project.

[0077] S103. Use a large model to analyze the code context to obtain the cause of the vulnerability and the execution function.

[0078] As an example, after obtaining the code context in which the vulnerability exists, a pre-established large model is used to analyze the code context to obtain the cause of the vulnerability and the function to be executed.

[0079] Large models refer to large-scale artificial intelligence models. In practical applications, Large Language Models (LLMs) can be chosen as large models. Large language models are deep learning models trained on large amounts of text data, enabling them to generate natural language text or understand the meaning of language text. These models can perform various language tasks by being trained on massive datasets.

[0080] By employing large models to analyze code context and obtain the vulnerability causes and execution functions, the natural language understanding, processing, and learning capabilities of large models can be leveraged to ensure that even if the project code is modified, the vulnerability causes and execution functions can still be stably and accurately analyzed and deduced from the code context.

[0081] S104. Tracing back from the executed function in the global call graph to find the entry function of the vulnerability; the global call graph is generated by analyzing the project code using the SAST tool.

[0082] As an example, after determining the project code of an open-source project, the SAST tool is used to analyze the project code and generate a global call graph.

[0083] It should be noted that a global call graph is a map showing the call relationships between various calling objects, such as functions and / or methods, throughout the entire project code.

[0084] SAST (Static Application Security Testing), also known as white-box testing, is a tool used to detect potential security vulnerabilities in applications. SAST tools do not require actually running the application; they only need to perform syntax and semantic checks, structural analysis, and logical reasoning on the application's source code or compiled binary files to discover potential security vulnerabilities.

[0085] By using the SAST tool to analyze project code and generate a global call graph, the SAST tool's ability to check the syntax and semantics of the code, analyze its structure, and perform logical reasoning can be leveraged to ensure the accurate generation of the project code's global call graph.

[0086] After obtaining the global call graph of the project code and the execution function of the vulnerability, the execution function of the vulnerability is used as the sink of the taint. The global call graph is traced backward from the execution function of the vulnerability to find all the entry functions that the vulnerability can reach. The entry function of the vulnerability is then obtained. At this point, the entry function of the vulnerability is also the source of the taint. Based on the execution function and the entry function of the vulnerability, the taint propagation chain of the vulnerability "source→sink" can be preliminarily determined.

[0087] S105. Output the analysis results of the vulnerability; the analysis results include the cause of the vulnerability, the executed function, and the entry function.

[0088] As an example, after obtaining the vulnerability cause, execution function, and entry function, the vulnerability analysis results are generated and output, which include the vulnerability cause, execution function, and entry function.

[0089] In practical applications, the vulnerability's cause, execution function, and entry point function can be compiled into SARIF (SARIF-compliant JSON text) format for analysis results output.

[0090] By compiling the vulnerability's cause, execution function, and entry point function into the vulnerability analysis results, the system can simultaneously provide users with information reflecting the vulnerability's exploitability, such as its cause, execution function, and entry point function. This allows users to easily analyze the vulnerability's exploitability based on its cause and taint propagation chain.

[0091] This application's embodiments generate a vulnerability lifecycle graph based on vulnerability information from a vulnerability database. Based on this lifecycle graph, the code context containing the vulnerability is obtained from the project code. A large model is used to analyze the code context, yielding the vulnerability's cause and execution function. In the global call graph generated by analyzing the project code using the SAST tool, the entry function of the vulnerability is traced back from the execution function. The vulnerability cause, execution function, and entry function are then compiled into the vulnerability analysis results. This approach can analyze the vulnerability cause and execution function from the code context covering the vulnerability lifecycle within the project code, utilizing the natural language understanding, processing, and learning capabilities of the large model. This ensures stable and accurate analysis of vulnerability causes and execution functions even after project code modifications. Furthermore, for the global call graph generated by the SAST tool, the entry function of the vulnerability is traced back from the execution function as the taint convergence point, ensuring the complete and accurate search for the entry function that the vulnerability can reach externally within the project code within the global call graph. This provides stable and accurate information on the exploitability of various vulnerabilities in open-source projects.

[0092] In an optional embodiment, the method further includes steps S106-S107:

[0093] S106. Extract vulnerability information for each vulnerability from multiple vulnerability intelligence sources.

[0094] As an example, multiple vulnerability intelligence sources can be selected based on actual application requirements, such as... Figure 2 As shown, the following options are selected: CNNVD (China National Vulnerability Database of Information Security, a national information security vulnerability database built and maintained by the China Information Security Evaluation Center), NVD (National Vulnerability Database, a comprehensive vulnerability database maintained by the National Institute of Standards and Technology in the United States), CVE.org (the official website of the Common Vulnerabilities and Exposures (CVE) project, used to publicly disclose vulnerabilities and provide a unique number (CVE number) for all publicly disclosed vulnerabilities), GitHub Advisory (a security bulletin service platform provided by GitHub), and Snyk (a service platform specifically for security assessment of open source components).

[0095] We used web crawling tools to extract vulnerability information for each vulnerability from multiple vulnerability intelligence sources.

[0096] For example, an Airflow-based timed crawler scheduler can be built to perform 24-hour incremental synchronization of vulnerability intelligence sources such as CNNVD, NVD, CVE.org, GitHubAdvisory, and Snyk. The vulnerability information of each crawled vulnerability is stored in databases in JSON, XML, and RSS formats as objects, with timestamps recorded to achieve traceable snapshot versions. The crawler can use ETag / Last-Modified headers to avoid duplicate crawling and a Bloom filter for fast deduplication to prevent the crawling of duplicate information.

[0097] S107. Preprocess the vulnerability information of each vulnerability, and store the preprocessed vulnerability information of each vulnerability in the database to obtain the vulnerability information database.

[0098] As an example, after obtaining the vulnerability information of each vulnerability, the vulnerability information of each vulnerability is preprocessed such as deduplication and normalization to obtain the preprocessed vulnerability information of each vulnerability, and the preprocessed vulnerability information of each vulnerability is stored in the database to obtain the vulnerability information database.

[0099] If new vulnerability information is subsequently captured from multiple vulnerability intelligence sources, and this new vulnerability information is preprocessed to obtain preprocessed vulnerability information, then the preprocessed vulnerability information can be directly stored in the vulnerability information database to update the vulnerability information database.

[0100] In practical applications, vulnerability information after preprocessing can be converted into structured data and stored in a database.

[0101] This application embodiment captures vulnerability information of various vulnerabilities from multiple vulnerability intelligence sources, preprocesses the vulnerability information of each vulnerability, and stores the preprocessed vulnerability information of each vulnerability in a database to obtain a vulnerability information database. It can gather vulnerability information of multiple vulnerabilities from multiple vulnerability intelligence sources, which is beneficial to increasing the data volume of the vulnerability information database.

[0102] In an optional embodiment, the vulnerability information includes multiple code change records for the vulnerability; generating a vulnerability lifecycle graph based on the vulnerability information of any vulnerability in the vulnerability information database includes: filtering code change records for fixing the vulnerability from multiple code change records; tracing back from the code change records for fixing the vulnerability to find the code change records for introducing the vulnerability; using the code change records for fixing as fix nodes and the code change records for introducing as introduction nodes, and adding connecting edges between the introduction nodes and the fix nodes to generate a lifecycle graph.

[0103] As an example, for each vulnerability in the vulnerability information database, the vulnerability information typically includes multiple code change records for the vulnerability, such as code change records submitted to fix the vulnerability, code change records submitted to upgrade the functionality of the module containing the vulnerability, and code change records submitted to restructure the structure of the module containing the vulnerability.

[0104] Multiple code change records may not all be code change records submitted to fix the vulnerability. That is, code change records used to fix the vulnerability. After obtaining multiple code change records for the vulnerability, the code change records used to fix the vulnerability are selected from the multiple code change records.

[0105] After obtaining the code change log for fixing the vulnerability, backtrack from the code change log for introducing the vulnerability.

[0106] In practical applications, the SZZ algorithm can be run, and git blame can be used to backtrack from fixing code change records to import code change records across multiple code change records.

[0107] In multi-branch scenarios, it is necessary to construct a DAG (Directed Acyclic Graph) to maintain topological consistency across project code versions.

[0108] After obtaining the code change records for fixing and importing, the code change records for fixing are used as the fix nodes, and the code change records for importing are used as the import nodes. Connecting edges are added between the import nodes and the fix nodes to generate a lifecycle graph of the vulnerability.

[0109] In practical applications, the creation time of the vulnerability report can be used as the discovery time of the vulnerability to create a discovery node. The time when the patch code change record is merged into the project code trunk can be determined based on the pull request associated with the vulnerability to create a merge node. The release node can be created based on the time when the patch code change record is first released with the project code. Connecting edges are added between the introduction node, discovery node, patch node, merge node, and release node to generate a vulnerability lifecycle graph, such as "introduction node → discovery node → patch node → merge node → release node". The attribute information of each node includes fingerprint information commit-hash, committer, commit time, and associated pull request or issue.

[0110] This application embodiment filters code change records used to fix vulnerabilities from multiple code change records targeting vulnerabilities, and backtracks from the code change records used to introduce vulnerabilities to find the code change records used to introduce vulnerabilities. The code change records used to fix vulnerabilities are used as fix nodes, and the code change records used to introduce vulnerabilities are used as introduction nodes. Connecting edges are added between the introduction nodes and fix nodes to generate a vulnerability lifecycle graph. This can accurately generate a graph covering the vulnerability lifecycle based on the code change records used to introduce vulnerabilities and the code change records used to fix vulnerabilities.

[0111] In an optional embodiment, the code change record for fixing the vulnerability satisfies one or more of the following filtering conditions: the description information of the code change record or the associated pull request includes the vulnerability number of the vulnerability; the code change content of the code change record includes the issue number associated with the vulnerability report; the semantic category of the code change content is a fix; wherein, the semantic category of the code change content is determined using a large model.

[0112] As an example, after obtaining multiple code change records for the vulnerability, one or more of the following methods can be used to filter the code change records used to fix the vulnerability from the multiple code change records:

[0113] 1. When submitting a code change log to fix a vulnerability, the vulnerability ID is usually added to the description of the code change log or the associated pull request. Search among multiple code change logs for those with the vulnerability ID in their descriptions or associated pull requests, and identify the found code change logs as the code change logs for fixing the vulnerability. For example, the vulnerability ID (CVE_ID) may be present in the commit message of the code change log or the PR title of the associated pull request.

[0114] 2. When submitting a code change log to fix a vulnerability, an issue number associated with the vulnerability report is usually added to the code change content of the code change log. For each code change log among multiple code change logs, it is determined whether the code change content of the code change log contains an issue number associated with the vulnerability report for that vulnerability. If it does, the code change log is considered to be used to fix the vulnerability and is identified as a code change log for fixing the vulnerability; otherwise, the code change log is determined not to be a code change log for fixing the vulnerability.

[0115] 3. When submitting a code change log for patching, it's possible that the relevant information in the code change log will not be modified. For each code change log among multiple code change logs, a large model is used to determine the semantic category of the code change content. If the semantic category of the code change content is patching, then the code change log is considered to be used to patch the vulnerability and is identified as a patch code change log. If the semantic category of the code change content is upgrade, refactoring, or other categories, then the code change log is considered not to be used to patch the vulnerability and is identified as a patch code change log.

[0116] This application embodiment considers various aspects such as the description information of the code change record, the associated pull request, the code change content, and the semantic category of the code change content to filter and repair code change records from multiple code change records, which can ensure that the code change records to be filtered and repaired are completely and accurately selected from multiple code change records.

[0117] In an optional embodiment, after generating a lifecycle diagram of a vulnerability based on the vulnerability information of any vulnerability in the vulnerability information database, the method further includes: updating the lifecycle diagram in response to a user's update request if the credibility index of the lifecycle diagram does not meet the standard.

[0118] As an example, after obtaining the lifecycle graph of the vulnerability, the credibility index of the lifecycle graph is evaluated to determine whether the credibility index meets the standard.

[0119] In practical applications, credibility metrics can be assessed by comprehensively considering factors such as the "Owner / Contributor" identity of each code change record involved in the lifecycle diagram, the discussion popularity of related issues, and the semantic relevance between the code change record that fixes the vulnerability and the vulnerability's Proof-of-Concept (PoC). Specific assessment rules can be pre-set according to actual business needs.

[0120] After obtaining the credibility index of the lifecycle map, determine whether the credibility index meets the standard.

[0121] In practical applications, a credibility index threshold can be preset. The value of the credibility index is compared with the preset credibility index threshold. If the value of the credibility index is less than the credibility index threshold, such as 0.4, it is determined that the credibility index does not meet the standard. At this time, the lifecycle diagram is considered untrustworthy, and subsequent operations can only be performed after responding to the user's update request for the lifecycle diagram. If the value of the credibility index is greater than or equal to the credibility index threshold, it is determined that the credibility index meets the standard, and subsequent operations can be performed.

[0122] In practical applications, in order to promptly remind users to update the lifecycle diagram when the credibility index fails to meet the standard, a re-examination mark can be added to the lifecycle diagram, or a re-examination reminder message for the lifecycle diagram can be generated and sent, so that users can view and update the lifecycle diagram in a timely manner.

[0123] This application embodiment updates the lifecycle diagram in response to user requests for updates when the credibility index of the vulnerability's lifecycle diagram fails to meet the standards, thereby ensuring accurate acquisition of the code context covering the vulnerability's lifecycle in the project code.

[0124] In an optional embodiment, the lifecycle diagram includes introduction nodes and remediation nodes. Introduction nodes indicate introduction code change records used to introduce vulnerabilities, and remediation nodes indicate remediation code change records used to fix vulnerabilities. The step of obtaining the code context of the vulnerability from the project code based on the lifecycle diagram includes: determining introduction code change records and remediation code change records based on the lifecycle diagram; determining the version of the project code that includes introduction code change records as the baseline version, and determining the version of the project code that includes remediation code change records as the target version; and constructing the code context based on the code changes between the baseline version and the target version, and the risky code segments in the project code affected by the code changes.

[0125] As an example, the lifecycle diagram of this vulnerability includes an introduction node and a fix node. The introduction node indicates the record of code changes used to introduce the vulnerability, and the fix node indicates the record of code changes used to fix the vulnerability. Based on the vulnerability's lifecycle diagram, the introduction code change records and the fix code change records can be identified.

[0126] The version of the project code that includes the introduced code change history is identified as the baseline version, and the version of the project code that includes the fixed code change history is identified as the target version.

[0127] Obtain the code changes between the baseline and target versions, as well as the risky code segments in the project code affected by these changes, such as functions or classes that have been added, deleted, or modified due to these changes. Based on the code changes between the baseline and target versions, and the risky code segments in the project code affected by these changes, construct a code context.

[0128] In practical applications, a bidirectional comparison between the baseline and target versions can be performed to identify the code changes between them, as well as the risky code segments in the project code affected by these changes. The specific execution process is as follows:

[0129] 1. Obtain the code changes diff between the baseline version {base} and the target version {head}: First, call the GitHub API (Application Programming Interface), such as the API at the address " / compare / {base}...{head}", to obtain the diff. If the diff fails, return to the local bare repository and run the command "git diff --unified=0 --no-color" to obtain the diff.

[0130] 2. Identify risky code segments in the project code affected by code changes: Use the Tree-Sitter tool to parse the diff into an AST (Abstract Syntax Tree) to obtain the code structure of the diff. Based on the code structure of the diff, identify function or class-level add, delete, and modify operations. For C / C++ code, call the GumTree tool to further obtain code movement and renaming information, thereby identifying risky code segments in the project code affected by the diff.

[0131] In practical applications, another major model can also be used, such as the Llama-3-70B “patch-summarizer” fine-tuning model, which performs natural language interpretation on the diff code structure and outputs a three-part summary: “affected interfaces, fixes, and potential bypass points”.

[0132] This application embodiment determines the introduced code change record and the repair code change record based on the introduced and repair nodes of the lifecycle graph. The version of the project code that includes the introduced code change record is determined as the baseline version, and the version of the project code that includes the repair code change record is determined as the target version. Based on the code changes between the baseline version and the target version, as well as the risky code segments in the project code affected by the code changes, a code context is constructed. This can take into account the code changes between the baseline version and the target version, as well as the risky code segments in the project code affected by the code changes, and comprehensively and accurately obtain the code context where the vulnerability is located from the project code.

[0133] In an optional embodiment, before using a large model to analyze the code context and obtain the cause of the vulnerability and the function to be executed, the method further includes: generating a local call graph based on the code change file for the vulnerability; using a large model to determine whether the code context is missing a target code segment based on the local call graph; if so, adding the target code segment to the code context and updating the code context.

[0134] As an example, in the process of obtaining the code context in which the vulnerability resides from the project code, the code change files for the vulnerability can also be obtained, that is, the code files modified for the vulnerability, such as the FixContext.files_changed list.

[0135] Based on the code change files targeting the vulnerability, determine the call relationships between various calling objects in the code change files, and generate a local call graph, such as ImportCallGraph.

[0136] It should be noted that a local call graph is a map showing the call relationships between various calling objects, such as functions and / or methods, in a code change file.

[0137] After obtaining the local call graph, the large model is used to determine whether the code context is missing a target code segment based on the local call graph. If so, the target code segment is added to the code context and the code context is updated; otherwise, the code context remains unchanged.

[0138] In practical applications, the ImportCallGraph and the code context are input into the large model. The large model uses the ImportCallGraph to determine whether the code context is missing a target code fragment, that is, a code fragment containing the calling object. If so, it is considered that the target code fragment needs to be supplemented in order to accurately analyze the vulnerability. At this time, the GitHub API can be called to automatically pull the corresponding target code fragment and add it to the code context until the large model reports "code context complete" and outputs the updated code context.

[0139] This application embodiment generates a local call graph based on the code change file targeting the vulnerability. A large model is used to determine whether the code context is missing a target code fragment based on the local call graph. If so, the target code fragment is added to the code context and the code context is updated. This can effectively avoid the code context from missing its dependent functions or methods, and ensure that the code context where the vulnerability is located is completely obtained from the project code.

[0140] In an optional embodiment, generating a local call graph based on the code change file for the vulnerability includes: obtaining the project code segment corresponding to the code change file from the project code; determining the call relationship between each call object in the project code segment based on the code structure of the project code segment; and generating a local call graph based on the call relationship between each call object.

[0141] As an example, after obtaining the code change file for the vulnerability, the corresponding project code segment is obtained from the project code, the code structure of the project code segment is determined, and based on the code structure of the project code segment, each calling object in the project code segment and the calling relationship between each calling object are identified. Based on the calling relationship between each calling object, a local call graph is generated.

[0142] In practical applications, the GitHub Raw API can be called to pull the complete source code of the code change file. The Tree-Sitter tool can be used to parse the source code into an AST to obtain the code structure of the source code. Based on the code structure of the source code, all import / include statements and function definitions can be identified. Based on all import / include statements and function definitions, a local call graph ImportCallGraph can be generated.

[0143] This application embodiment obtains the project code segment corresponding to the code change file from the project code, determines the call relationship between each calling object in the project code segment based on the code structure of the project code segment, and generates a local call graph based on the call relationship between each calling object. It can accurately identify the call relationship between each calling object in the code change file by analyzing the source code structure of the code change file, and ensure the accurate generation of the local call graph of the code change file.

[0144] In an optional embodiment, the step of using a large model to analyze the code context to obtain the vulnerability cause and execution function includes: using a large model to match the code context with pre-configured vulnerability defect patterns and determining the vulnerability cause based on the matching results; and using a large model to locate the execution function in the code context based on the vulnerability cause.

[0145] As an example, after obtaining the code context in which the vulnerability resides from the project code, a large model is used to match the code context with various pre-configured vulnerability defect patterns, and the cause of the vulnerability is determined based on the matching results. For example, if the code context matches a pre-configured vulnerability defect pattern, it is considered that the cause of the vulnerability is related to that vulnerability defect pattern. At this time, it can be determined that the cause of the vulnerability is the vulnerability cause corresponding to that vulnerability defect pattern. Then, the large model is used to locate the execution function in the code context based on the cause of the vulnerability, thereby obtaining the cause of the vulnerability and the execution function.

[0146] In practical applications, prompt templates can be used to configure vulnerability defect patterns for large models, such as missing input validation, sensitive API calls, and race conditions. The large model can output the vulnerability cause as a structured object; for example, the vulnerability cause could be a RootCause object, which includes the vulnerability defect pattern, the code location where the vulnerability is located, and a description. Based on the RootCause object, the large model can locate the specific function or method containing the vulnerability within the code context, i.e., the executed function VulnFunc. The output executed function includes the file path, function name, start and end line numbers, and call signature.

[0147] In practical applications, SAST tools, such as CodeQL CFG, can be used to perform static data flow analysis on the project code to generate a global call graph. Using VulnFunc as the sink, the source can be traced back to find all entry functions that the vulnerability can reach, such as Controller / API / CLI, to obtain the entry function EntryFuncs of the vulnerability.

[0148] This application embodiment pre-configures vulnerability defect patterns, uses a large model to match the code context with each pre-configured vulnerability defect pattern, and determines the cause of the vulnerability based on the matching results. Then, based on the cause of the vulnerability, it locates the execution function in the code context. This can ensure that even when the project code is modified, the cause of the vulnerability and the execution function in the project code can be analyzed stably and accurately, while improving the analysis speed of the cause of the vulnerability and the execution function.

[0149] In an optional embodiment, the method further includes step S106:

[0150] S106. Use a large model to format the execution function.

[0151] As an example, considering that the vulnerability's execution function needs to be referenced in the subsequent patch generation stage, after obtaining the vulnerability's execution function, the large model is used to format the execution function.

[0152] In practical applications, a large model can be used to retain the function definition of the executed function and other key code, and return it in the form of Markdown code blocks, while attaching information such as parameters, return values ​​and exception descriptions, so as to facilitate the generation of references for subsequent patches.

[0153] This application's embodiments format the vulnerability's execution function using a large model, making it convenient for the subsequent patch generation stage to directly reference the execution function.

[0154] Please refer to Figure 3 , Figure 3 This is a schematic diagram of a vulnerability analysis device based on a large model and SAST, provided in the second embodiment of this application. The second embodiment of this application provides a vulnerability analysis device based on a large model and SAST, comprising: a lifecycle graph generation module 201, used to generate a lifecycle graph of a vulnerability based on vulnerability information of any vulnerability in a vulnerability database; a code context acquisition module 202, used to obtain the code context where the vulnerability is located from the project code based on the lifecycle graph; a first vulnerability analysis module 203, used to analyze the code context using a large model to obtain the vulnerability cause and execution function; a second vulnerability analysis module 204, used to trace back from the execution function in the global call graph to find the entry function of the vulnerability; wherein, the global call graph is generated by analyzing the project code using the SAST tool; and an analysis result output module 205, used to output the vulnerability analysis results; wherein, the analysis results include the vulnerability cause, execution function, and entry function.

[0155] In an optional embodiment, the vulnerability information includes multiple code change records for the vulnerability; generating a vulnerability lifecycle graph based on the vulnerability information of any vulnerability in the vulnerability information database includes: filtering code change records for fixing the vulnerability from multiple code change records; tracing back from the code change records for fixing the vulnerability to find the code change records for introducing the vulnerability; using the code change records for fixing as fix nodes and the code change records for introducing as introduction nodes, and adding connecting edges between the introduction nodes and the fix nodes to generate a lifecycle graph.

[0156] In an optional embodiment, the code change record for fixing the vulnerability satisfies one or more of the following filtering conditions: the description information of the code change record or the associated pull request includes the vulnerability number of the vulnerability; the code change content of the code change record includes the issue number associated with the vulnerability report; the semantic category of the code change content is a fix; wherein, the semantic category of the code change content is determined using a large model.

[0157] In an optional embodiment, the lifecycle diagram generation module 201 is further configured to, after generating a lifecycle diagram of a vulnerability based on the vulnerability information of any vulnerability in the vulnerability information database, update the lifecycle diagram in response to a user's update request if the credibility index of the lifecycle diagram does not meet the standard.

[0158] In an optional embodiment, the lifecycle diagram includes introduction nodes and remediation nodes. Introduction nodes indicate introduction code change records used to introduce vulnerabilities, and remediation nodes indicate remediation code change records used to fix vulnerabilities. The step of obtaining the code context of the vulnerability from the project code based on the lifecycle diagram includes: determining introduction code change records and remediation code change records based on the lifecycle diagram; determining the version of the project code that includes introduction code change records as the baseline version, and determining the version of the project code that includes remediation code change records as the target version; and constructing the code context based on the code changes between the baseline version and the target version, and the risky code segments in the project code affected by the code changes.

[0159] In an optional embodiment, the first vulnerability analysis module 203 is used to generate a local call graph based on the code change file for the vulnerability before the large model is used to analyze the code context to obtain the vulnerability cause and the execution function; the large model is used to determine whether the code context is missing a target code segment based on the local call graph; if so, the target code segment is added to the code context and the code context is updated.

[0160] In an optional embodiment, generating a local call graph based on the code change file for the vulnerability includes: obtaining the project code segment corresponding to the code change file from the project code; determining the call relationship between each call object in the project code segment based on the code structure of the project code segment; and generating a local call graph based on the call relationship between each call object.

[0161] In an optional embodiment, the step of using a large model to analyze the code context to obtain the vulnerability cause and execution function includes: using a large model to match the code context with pre-configured vulnerability defect patterns and determining the vulnerability cause based on the matching results; and using a large model to locate the execution function in the code context based on the vulnerability cause.

[0162] In an optional embodiment, the first vulnerability analysis module 203 is also used to format the execution function using a large model.

[0163] The specific implementation process of the functions and roles of each module in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0164] The third embodiment of this application provides a computer program product, which includes instructions that, when executed by a computer, cause the computer to perform the method described in the first embodiment of this application and achieve the same beneficial effects.

[0165] The methods described in the first embodiment of this application can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. When implemented in software, they can be implemented, in whole or in part, in the form of a computer program product. A computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed on a computer, the processes or functions described in the various embodiments of this application are performed, in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user equipment, a core network device, an OAM (Open Application Model), or other programmable devices.

[0166] Computer programs or instructions can be stored in or transferred from one computer-readable storage medium to another. For example, a computer program or instructions can be transferred from one website, computer, server, or data center to another via wired or wireless means. A computer-readable storage medium can be any usable medium that a computer can access, or a data storage device such as a server or data center that integrates one or more usable media. Usable media can be magnetic media, such as floppy disks, hard disks, and magnetic tapes; optical media, such as digital video discs; or semiconductor media, such as solid-state drives. The computer-readable storage medium can be volatile or non-volatile, or may include both types.

[0167] Please refer to Figure 4 , Figure 4 This is a schematic diagram of the structure of an electronic device provided in the fourth embodiment of this application. The fourth embodiment of this application provides an electronic device 30, including a processor 301, a memory 302, and a computer program stored in the memory 302 and configured to be executed by the processor 301; when the processor 301 executes the computer program, it implements the method described in the first embodiment of this application and can achieve the same beneficial effects.

[0168] When the processor 301 reads a computer program from the memory 302 via the bus 303 and executes the computer program, it can implement the method described in the first embodiment of this application.

[0169] Processor 301 can process digital signals and may include various computing architectures. For example, it may be a complex instruction set computer architecture, a reduced instruction set computer architecture, or an architecture that implements multiple instruction set combinations. In some examples, processor 301 may be a microprocessor.

[0170] The memory 302 can be used to store instructions executed by the processor 301 or data related to the execution of instructions. These instructions and / or data may include code used to implement some or all of the functions of one or more modules described in the embodiments of this application. The processor 301 of this embodiment can be used to execute the instructions in the memory 302 to implement the method described in the first embodiment of this application. The memory 302 includes dynamic random access memory, static random access memory, flash memory, optical memory, or other memories well known to those skilled in the art.

[0171] The fifth embodiment of this application provides a computer-readable storage medium, which includes a stored computer program; wherein, when the computer program is running, it controls the device where the computer-readable storage medium is located to perform the method described in the first embodiment of this application, and can achieve the same beneficial effects.

[0172] In summary, this application provides a vulnerability analysis method, program product, and device based on a large model and SAST. The vulnerability analysis method based on the large model and SAST includes: generating a vulnerability lifecycle diagram based on the vulnerability information of any vulnerability in a vulnerability information database; obtaining the code context where the vulnerability is located from the project code based on the lifecycle diagram; analyzing the code context using a large model to obtain the vulnerability cause and execution function; tracing back from the execution function in the global call graph to find the entry function of the vulnerability; wherein the global call graph is generated by analyzing the project code using the SAST tool; and outputting the vulnerability analysis results; wherein the analysis results include the vulnerability cause, execution function, and entry function. This application's embodiments generate a vulnerability lifecycle graph based on vulnerability information from a vulnerability database. Based on this lifecycle graph, the code context containing the vulnerability is obtained from the project code. A large model is used to analyze the code context, yielding the vulnerability's cause and execution function. In the global call graph generated by analyzing the project code using the SAST tool, the entry function of the vulnerability is traced back from the execution function. The vulnerability cause, execution function, and entry function are then compiled into the vulnerability analysis results. This approach can analyze the vulnerability cause and execution function from the code context covering the vulnerability lifecycle within the project code, utilizing the natural language understanding, processing, and learning capabilities of the large model. This ensures stable and accurate analysis of vulnerability causes and execution functions even after project code modifications. Furthermore, for the global call graph generated by the SAST tool, the entry function of the vulnerability is traced back from the execution function as the taint convergence point, ensuring the complete and accurate search for the entry function that the vulnerability can reach externally within the project code within the global call graph. This provides stable and accurate information on the exploitability of various vulnerabilities in open-source projects.

[0173] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0174] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0175] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they 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 a portion 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 USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0176] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application. It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0177] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0178] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A vulnerability analysis method based on a large model and SAST, characterized in that, The method comprises the following steps: generating a life cycle graph of any vulnerability in a vulnerability information library according to vulnerability information of the vulnerability; wherein the vulnerability information of the vulnerability comprises a plurality of code change records for the vulnerability; the life cycle graph of the vulnerability is generated in the following manner: filtering a repair code change record for repairing the vulnerability from the plurality of code change records; backtracking in the plurality of code change records to find an introduction code change record for introducing the vulnerability from the repair code change record; generating the life cycle graph by taking the repair code change record as a repair node, taking the introduction code change record as an introduction node, and adding a connection edge between the introduction node and the repair node; obtaining a code context in which the vulnerability is located in the project code based on the life cycle graph; wherein the code context in which the vulnerability is located is obtained in the following manner: determining the introduction code change record and the repair code change record based on the life cycle graph; determining a version including the introduction code change record in the project code as a baseline version, and determining a version including the repair code change record in the project code as a target version; constructing the code context according to code change content between the baseline version and the target version, and a risk code segment affected by the code change content in the project code; analyzing the code context by using a large model to obtain a vulnerability cause and an execution function of the vulnerability; wherein, before the code context is analyzed by using the large model to obtain the vulnerability cause and the execution function of the vulnerability, the method further comprises: generating a local call graph according to a code change file for the vulnerability; determining whether the code context is missing a target code segment by using the large model according to the local call graph; if so, adding the target code segment to the code context and updating the code context; backtracking from the execution function to find an entry function of the vulnerability in a global call graph; wherein the global call graph is generated by analyzing the project code by using a SAST tool; outputting an analysis result of the vulnerability; wherein the analysis result comprises the vulnerability cause, the execution function and the entry function.

2. The method of claim 1, wherein, The repair code change record satisfies one or more of the following screening conditions: The description information or the associated pull request of the repair code change record comprises a vulnerability number of the vulnerability; The code change content of the repair code change record comprises a problem number associated with a vulnerability report of the vulnerability; The semantic category of the code change content is a repair category; wherein the semantic category of the code change content is determined by using the large model.

3. The method of claim 1, wherein, After the life cycle graph of the vulnerability is generated according to the vulnerability information of any vulnerability in the vulnerability information library, the method further comprises: in the case that the reliability index of the life cycle graph is not up to standard, updating the life cycle graph in response to a user's update request for the life cycle graph.

4. The method of claim 1, wherein, The method of generating a local call graph according to a code change file for the vulnerability comprises: obtaining a project code segment corresponding to the code change file from the project code; determining a calling relationship between each calling object in the project code segment based on a code structure of the project code segment; generating the local calling graph according to the calling relationship between each calling object.

5. The method of claim 1, wherein, The adopting a large model to analyze the code context includes: adopting the large model to match the code context with each vulnerability defect pattern pre-configured, and determining the vulnerability cause according to a matching result; adopting the large model to locate the execution function in the code context according to the vulnerability cause.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: adopting the large model to format the execution function.

7. A computer program product, characterised in that, The computer program product includes instructions which, when executed by a computer, cause the computer to implement the method according to any one of claims 1 to 6.

8. An electronic device, comprising: The computer program product includes instructions which, when executed by a computer, cause the computer to implement the method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer program product includes instructions which, when executed by a computer, cause the computer to implement the method according to any one of claims 1 to 6.

Images