Program vulnerability analysis method, device and equipment

Abstract

The invention provides a program vulnerability analysis method, device and equipment. The scheme comprises the following steps: identifying a first type of risk instruction with an execution risk in a to-be-analyzed program; then, a risk calling sequence is extracted from the to-be-analyzed program according to the data dependency relationship of the input parameters of the first type of risk instructions in the to-be-analyzed program, and an end code unit in the risk calling sequence comprises the first type of risk instructions; the next code unit in the adjacent code unit combinations in the risk calling sequence is called by the previous code unit; then, for the risk calling sequence, session prompt information used for being input into the large model is generated, and the session prompt information is used for indicating the large model to check program vulnerabilities in the risk calling sequence; then, session prompt information is input into the large model, and a vulnerability analysis result, output by the large model, of the to-be-analyzed program is obtained.

Description

Technical Field

[0001] The present application relates to the technical field of software vulnerability analysis, and in particular to a program vulnerability analysis method. The present application also relates to a program vulnerability analysis device and a program vulnerability analysis equipment. Background Art

[0002] With the rapid development of information technology, software has been widely used in all walks of life and has become an indispensable part of modern society. However, software vulnerabilities are key factors affecting software security and reliability. Their existence may not only lead to serious consequences such as data leakage and system crashes, but also provide opportunities for hacker attacks, posing a huge threat to national security, corporate operations and personal privacy. Therefore, software vulnerability inspection, as an important link in ensuring software quality and security, is becoming increasingly important.

[0003] At present, there are many software vulnerability detection methods on the market. For example, source code or binary code can be scanned and analyzed by using software vulnerability detection tools to find potential programming errors and security vulnerabilities. Existing rule-based vulnerability detection tools need to rely on experts with a lot of vulnerability analysis-related knowledge to develop, which makes it difficult and costly to develop accurate and comprehensive vulnerability analysis plans. At present, people try to use deep learning methods to discover vulnerabilities in software, for example, using large models to perform program vulnerability analysis. However, since software is often large in scale and complex in logic, when using large models to analyze software program vulnerabilities, it is difficult for large models to understand program logic, which leads to poor accuracy of vulnerability detection. Summary of the invention

[0004] In view of this, the embodiments of the present application provide a software vulnerability analysis method, apparatus and device to at least partially solve the problem that the large model is difficult to understand the program logic when performing program vulnerability analysis, which leads to poor vulnerability checking accuracy.

[0005] According to a first aspect of an embodiment of the present application, a program vulnerability analysis method is provided, comprising: identifying a first type of risk instruction with execution risk in a program to be analyzed; extracting a risk call sequence from the program to be analyzed according to data dependencies of input parameters of the first type of risk instruction in the program to be analyzed; the last code unit in the risk call sequence contains the first type of risk instruction; a latter code unit in a combination of adjacent code units in the risk call sequence is called by a former code unit; generating, for the risk call sequence, session prompt information for input into a large model; the session prompt information is used to instruct the large model to check program vulnerabilities in the risk call sequence; and inputting the session prompt information into the large model to obtain a vulnerability analysis result for the program to be analyzed output by the large model.

[0006] According to a second aspect of an embodiment of the present application, a program vulnerability analysis device is provided, comprising: a risk instruction identification module, used to identify a first type of risk instruction with execution risk in a program to be analyzed; a risk call sequence extraction module, used to extract a risk call sequence from the program to be analyzed according to the data dependency relationship of the input parameters of the first type of risk instruction in the program to be analyzed; the last code unit in the risk call sequence contains the first type of risk instruction; the latter code unit in the combination of adjacent code units in the risk call sequence is called by the previous code unit; a session prompt information generation module, used to generate session prompt information for input to a large model for the risk call sequence; the session prompt information is used to instruct the large model to check the program vulnerabilities in the risk call sequence; and a vulnerability analysis module, used to input the session prompt information into the large model to obtain the vulnerability analysis result of the program to be analyzed output by the large model.

[0007] According to a third aspect of an embodiment of the present application, a program vulnerability analysis device is provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can: identify a first type of risk instruction with execution risk in a program to be analyzed; extract a risk call sequence from the program to be analyzed based on the data dependency of input parameters of the first type of risk instruction in the program to be analyzed; the last code unit in the risk call sequence contains the first type of risk instruction; the latter code unit in the combination of adjacent code units in the risk call sequence is called by the previous code unit; for the risk call sequence, generate session prompt information for input to a large model; the session prompt information is used to instruct the large model to check program vulnerabilities in the risk call sequence; input the session prompt information into the large model to obtain a vulnerability analysis result for the program to be analyzed output by the large model.

[0008] One embodiment of the present specification can achieve at least the following beneficial effects: after identifying the first type of risk instructions with execution risks from the program to be analyzed, a risk call sequence containing the first type of risk instructions is extracted based on the data dependency relationship, and then the risk call sequence is provided to the big model for analysis and the vulnerability analysis results are obtained. Therefore, there is no need to pass the entire program to be analyzed to the big model, but only the risk call sequence related to the vulnerability in the program to be analyzed is passed to the big model. On the one hand, it avoids passing code unrelated to the vulnerability to the big model, reduces interference with the big model analysis, helps the big model understand the code logic, and improves the accuracy of the big model analysis results; on the other hand, since the amount of code analysis of the big model is reduced, the analysis efficiency is improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0010] Figure 1 A schematic diagram of an application scenario of a program vulnerability analysis method provided in an embodiment of this specification; Figure 2 A flowchart of a program vulnerability analysis method provided in an embodiment of this specification; Figure 3 A schematic diagram of a method for determining a risk call sequence based on a data dependency relationship in a program example to be analyzed provided in an embodiment of this specification; Figure 4 The embodiments of this specification provide corresponding to Figure 2 A schematic diagram of the structure of a program vulnerability analysis device; Figure 5 The embodiments of this specification provide corresponding to Figure 2 A structural diagram of a program vulnerability analysis device. DETAILED DESCRIPTION

[0011] Many specific details are described in the following description to facilitate a full understanding of the present application. However, the present application can be implemented in many other ways than those described herein, and those skilled in the art can make similar generalizations without violating the connotation of the present application, so the present application is not limited by the specific implementation disclosed below.

[0012] The terms used in one or more embodiments of the present application are only for the purpose of describing specific embodiments, and are not intended to limit one or more embodiments of the present application. The singular forms of "a", "said" and "the" used in one or more embodiments of the present application and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings. It should also be understood that the term "and / or" used in one or more embodiments of the present application refers to and includes any or all possible combinations of one or more associated listed items.

[0013] It should be understood that, although the terms first, second, etc. may be used to describe various information in one or more embodiments of the present application, these information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of the present application, the first may also be referred to as the second, and similarly, the second may also be referred to as the first. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0014] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards in the relevant regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0015] In one or more embodiments of this specification, a large model refers to a deep learning model with large-scale model parameters, which usually contains hundreds of millions, tens of billions, hundreds of billions, trillions, or even more than 10 trillion model parameters. A large model can also be called a foundation model / foundation model. The large model is pre-trained with large-scale unlabeled corpus to produce a pre-trained model with more than 100 million parameters. This model can adapt to a wide range of downstream tasks, and the model has good generalization ability, such as a large-scale language model (LLM, Large Language Model), a multi-modal pre-training model, etc.

[0016] When the big model is used in practice, only a small number of samples are needed to fine-tune the pre-trained model and it can be applied to different tasks. The big model can be widely used in natural language processing (NLP), computer vision and other fields. Specifically, it can be applied to computer vision tasks such as visual question answering (VQA), image description (IC, Image Caption), image generation, as well as natural language processing tasks such as text-based sentiment classification, text summary generation, and machine translation. The main application scenarios of the big model include digital assistants, intelligent robots, search, online education, office software, e-commerce, intelligent design, etc.

[0017] In the embodiments of the present specification, the large model used for program vulnerability analysis may specifically include a large language model that can be used for natural language processing. When a large model is used for program vulnerability analysis, programs exceeding a certain size cannot be checked due to the maximum number of tokens input by the large model. Moreover, even when analyzing smaller programs, the logical complexity of the program itself compared to natural language will make it difficult for the large model to understand the program, and a large amount of code in the program that is not related to the vulnerability will also interfere with the analysis of the large model, affecting the accuracy of the large model analysis results.

[0018] In order to address the defects in the prior art, in an embodiment of the present specification, a first type of risky instructions with execution risks are first identified from the program to be analyzed, and then a risky call sequence containing the first type of risky instructions is extracted based on data dependencies, and then the risky call sequence is provided to the big model for analysis to obtain vulnerability analysis results. Thus, on the one hand, after extracting the risky call sequence from the program to be analyzed, the risky call sequence is input into the big model for analysis, instead of passing the entire program to be analyzed to the big model for analysis, thereby reducing the risk of being unable to perform analysis due to the program to be analyzed not meeting the maximum token number limit of the big model input; on the other hand, by analyzing data dependencies to extract the risky call sequence, irrelevant context is input into the big model, so that there is no need to pay attention to code that is not related to potential vulnerability points during the big model analysis, reducing the difficulty of the big model in understanding the code, thereby improving the accuracy of the vulnerability analysis results of the big model.

[0019] Figure 1 A schematic diagram of an application scenario of a program vulnerability analysis method provided in an embodiment of this specification.

[0020] like Figure 1As shown, the implementation environment of the program vulnerability analysis method provided in the embodiment of this specification may include a user terminal 100 and a server 200. Specifically, the program analyst may send a code analysis request to the server 200 through the user terminal 100, and the server 200 may respond to the code analysis request, execute the program vulnerability analysis method, and feed back the obtained vulnerability analysis results to the user terminal 100.

[0021] Furthermore, during the execution of the program vulnerability analysis method, the server 200 can identify a first type of risk instruction from the program to be analyzed, and then extract a risk call sequence from the program to be analyzed based on the first type of risk instruction. Then, session prompt information about the risk call sequence can be generated, and the session prompt information can be provided to the large model to obtain the vulnerability analysis result of the program to be analyzed output by the large model.

[0022] In such Figure 1 In the application scenario shown, the server 200 may be connected to one or more user terminals 100 via a local area network connection, a wide area network connection, an Internet connection or other types of data networks. Figure 1 The server 200 may include but is not limited to any device, equipment, platform, device cluster, etc. with computing and processing capabilities. Figure 1 The user terminal 100 may include but is not limited to a smart phone, a tablet computer, a laptop computer, a PDA, a personal computer, etc.

[0023] although Figure 1 It is shown that the implementation environment includes a user terminal 100 and a server 200, but in actual application, the implementation scenario may not include the user terminal 100, or may not include the server 200.

[0024] In an optional embodiment, the program vulnerability analysis method can be executed by the user terminal 100. In this case, the implementation scenario of the embodiment of this specification may not include the server 100. In another optional embodiment, the triggering condition for the execution of the program vulnerability analysis method may be pre-set and stored in the server 200, that is, it does not need to be triggered after receiving the code analysis request of the user terminal 100. In this case, the implementation scenario of the embodiment of this specification may not include the user terminal 100.

[0025] Furthermore, the large model called in the process of executing the program vulnerability analysis method can, optionally, be deployed on a device that executes the program vulnerability analysis method of the embodiment of this specification, or, optionally, can be deployed on a device different from the device that executes the program vulnerability analysis method of the embodiment of this specification.

[0026] For example, if the program vulnerability analysis method is executed by the user terminal 100, the user terminal 100 can call the big model deployed on another device to perform a specific vulnerability analysis, that is, after generating the session prompt information, the user terminal 100 can provide the session prompt information to the big model by calling the interface of the device deployed with the big model, and obtain the vulnerability analysis result fed back by the device deployed with the big model; alternatively, when the running resources of the user terminal 100 can meet the running conditions of the big model, the big model can also be deployed on the user terminal 100, then the user terminal device 100 can obtain the vulnerability analysis result by executing the complete process of the program vulnerability analysis method.

[0027] For another example, if the program vulnerability analysis method is executed by server 200, then the big model can be deployed on the server 200 or on another device connected to the server 200. In actual application, after generating the session prompt information, server 200 can input the session prompt information into the big model deployed on the server 200 or on another device connected to the server 200, thereby obtaining the vulnerability analysis result fed back by the big model.

[0028] In the present application, a program vulnerability analysis method is provided. The present application also relates to a program vulnerability analysis apparatus, a program vulnerability analysis device, which is described in detail one by one in the following embodiments.

[0029] Figure 2 A flowchart of a program vulnerability analysis method provided in an embodiment of this specification. From the program perspective, the execution subject of the process can be a program installed on a server or a user terminal. It can be understood that the method can be executed by any device, equipment, platform, or device cluster with computing and processing capabilities.

[0030] like Figure 2 As shown, the process may include the following steps.

[0031] Step 202: Identify the first type of risky instructions with execution risks in the program to be analyzed.

[0032] The program to be analyzed may include a set of ordered instructions for achieving a specific goal or task, and is composed of code (including multiple code snippets). In actual application, the program to be analyzed may include simple scripts or complex software. Instructions are basic operations that can be understood and executed by computers, and are the basic components of code. In step 202, it is necessary to identify the specified instructions from the program to be analyzed, that is, to identify the first type of risk instructions, which are specifically instructions with execution risks.

[0033] In the embodiments of this specification, instructions with execution risks may be instructions that may trigger program vulnerabilities. Generally, program vulnerabilities may include, but are not limited to, buffer overflow vulnerabilities, format string vulnerabilities, input validation vulnerabilities, cross-site scripting vulnerabilities (XSS), SQL injection vulnerabilities, and other vulnerability types. In actual applications, instructions that may trigger one or more vulnerabilities of these vulnerability types may be determined as first-class risk instructions with execution risks. In practice, first-class risk instructions with execution risks may trigger various program vulnerabilities if data is not properly processed.

[0034] As an example, instructions with execution risk may include instructions involving memory operations, instructions involving data operations, instructions that affect the control flow of the program, etc., but are not limited thereto. Further, instructions involving memory operations may include instructions for assigning values ​​to memory space, instructions for outputting memory, instructions for executing memory, etc., but are not limited thereto.

[0035] In actual application, the first type of risk instructions are identified, which may specifically include identifying the location of the first type of risk instructions, identifying the name of the first type of risk instructions, and identifying the input parameters of the first type of risk instructions. Among them, the location of the first type of risk instructions can also be called code address, code line number, source code location, etc., which is used to indicate the location of a specific instruction or code fragment in the memory space or source code of the program. In the embodiment of the present specification, after the first type of risk instructions are identified, the related information identified with the first type of risk instructions can be stored for use in subsequent analysis.

[0036] Assuming that the relevant information of each identified first-category risk instruction is defined as a risk address and recorded as VD, then it can be further expressed as VD = (code address Loc; risk point name Sink; risk parameter Arg), where the code address Loc can specifically represent the code line number where the current first-category risk instruction is located, the risk point name Sink can specifically represent the function name called by the current first-category risk instruction, and the risk parameter Arg can specifically represent the input parameters of the function called by the current first-category risk instruction.

[0037] Step 204: extracting a risk call sequence from the program to be analyzed according to the data dependency of the input parameters of the first type of risk instructions in the program to be analyzed; the last code unit in the risk call sequence contains the first type of risk instructions; and the latter code unit in the combination of adjacent code units in the risk call sequence is called by the previous code unit.

[0038] In software engineering, a dependency refers to the fact that changes in one element (e.g., module, class, function, etc.) may affect another element, and the latter requires the former to provide some information or service in order to work properly. Furthermore, a data dependency refers to the fact that one element needs to use the data generated by another element. For example, parameters need to be passed when a function is called, or a module needs to read the output data of another module. In actual applications, static code analysis tools (e.g., SonarQube, PMD, etc.) can be used to scan source code or binary code to identify the calling relationship, data flow, and dependencies between functions, thereby obtaining the data dependency between parameters.

[0039] In an embodiment of the present specification, based on the first type of risk instructions identified from the program to be analyzed in step 202, combined with the data dependency of the program to be analyzed, a data processing technology such as program slicing can be applied to extract a risk call sequence having a specific relationship with the first type of risk instructions from the program to be analyzed. The call sequence can also be called a call chain.

[0040] In the field of programming, program slicing is a very efficient means of data access, which can be used to extract a subset from a larger data structure and create a new view without copying the original data. Through program slicing, it is possible to read and write some elements of the data structure without copying the entire data structure, greatly improving the execution efficiency and memory utilization of the code. In program slicing, the slicing criterion refers to the specific program point or variable of interest for calculating the slice. The slicing criterion defines the starting point of the slicing analysis in the program and is used to determine which statements are included in the generated slice. In an embodiment of the present specification, the first type of risky instructions identified in step 202 can be used as the slicing criterion for program slicing analysis.

[0041] Typically, program slicing may include forward slicing or reverse slicing. Among them, forward slicing can be a forward search starting from a certain position in the program (usually a program point or variable specified by the slicing standard) to determine which code will be affected to some extent by the instructions and variables in the selected slicing standard. This means that the result of forward slicing can include all statements that are directly or indirectly affected by the program points in the slicing standard. In simple terms, forward slicing can focus on the dependencies traced back from the starting point. Reverse slicing can be a backward search starting from a certain position in the program (usually a program point or variable specified by the slicing standard) to determine which code will affect the execution of the selected slicing standard. This means that reverse slicing can include all statements that directly or indirectly affect the program points in the slicing standard. In simple terms, reverse slicing can focus on the dependencies traced back from the starting point. In an embodiment of the present specification, through the reverse slicing analysis method, statements that directly or indirectly affect the input parameters of the first type of risk instructions can be obtained, and a risk call sequence extracted from the original program to be analyzed can be obtained.

[0042] In an embodiment of the present specification, the risk call sequence may be a sequence composed of code units extracted from the program to be analyzed, and the latter code unit of any two adjacent code units in the risk call sequence is called by the former code unit. That is, in the risk call sequence, the code units may be arranged in the order of the caller first and the callee later. Moreover, the last code unit in the risk call sequence may correspond to the first type of risk instruction identified by step 202 as the slicing standard.

[0043] In an optional embodiment of the present specification, the code unit may include at least one of a code line, a function, or a code block.

[0044] Optionally, the risk call sequence determined in step 204 may be a function call chain consisting of functions extracted from the program to be analyzed, and the latter function of any two adjacent functions in the function call chain is called by the former function. Furthermore, the last function in the function call chain may be the function to which the first type of risk instruction identified in step 202 belongs.

[0045] Optionally, the risk call sequence determined in step 204 may be a code line call chain consisting of code lines extracted from the sequence to be analyzed, and the parameters of the instructions in the latter code line of any two adjacent code lines in the code line call chain depend on the parameters of the instructions in the previous code line. Furthermore, the last code line in the code line call chain may be the code line where the first type of risk instruction identified in step 202 is located.

[0046] Optionally, the risk call sequence determined in step 204 may be a code block call chain consisting of code blocks extracted from the program to be analyzed, and the latter code block of any two adjacent code blocks in the code block call chain is called by the former code block. Furthermore, the last code block in the code block call chain may be the code block to which the first type of risk instruction identified in step 202 belongs.

[0047] Taking the case where the code unit is a function as an example, in the embodiments of this specification, a function call chain can be recorded as CC=[f1, f2, ..., fn], where fn contains the first type of risk instructions, and for any i∈[1, n), fi calls f(i+1). The case where the code unit is a code line or a code block is similar and will not be described in detail here.

[0048] Step 206: Generate session prompt information for input into the big model for the risk call sequence; the session prompt information is used to instruct the big model to check for program vulnerabilities in the risk call sequence.

[0049] In the embodiment of the present specification, corresponding session prompt information may be generated for each risk call sequence. For example, if the risk call sequence determined in step 204 includes DF1=[fun2, fun1] and DF2=[fun6, fun4, fun3, fun1], then in step 206, session prompt information M1 may be generated for DF1, and session prompt information M2 may be generated for DF2.

[0050] In actual application, a prompt information template for generating session prompt information may be pre-set. In step 206, the specific code corresponding to the risk call sequence may be combined with the prompt information template to obtain session prompt information for input into the large model.

[0051] Specifically, in order to instruct the large model to check for program vulnerabilities in the risk call sequence, the prompt information template and the session prompt information generated based on the prompt information template may include prompt information such as specifying the analysis role, specifying the analysis requirements, explaining the analysis background, indicating the type of vulnerability to be checked, and specifying the expected output format, etc. The specific content of the prompt information may be set according to actual business needs.

[0052] Step 208: Input the session prompt information into the large model to obtain the vulnerability analysis result of the program to be analyzed output by the large model.

[0053] Specifically, the conversation prompt information carrying the risk call sequence can be provided to the big model, and the big model is called to analyze the risk call sequence to obtain the vulnerability analysis result for the risk call sequence. Since the risk call sequence is extracted from the program to be analyzed, the vulnerability analysis result for the risk call sequence can be used as the vulnerability analysis result of the program to be analyzed.

[0054] When multiple risk call sequences are included, there may be a considerable number of multiple session prompt information. In this case, the multiple session prompt information may be provided to the large model respectively, and the large model may be called to analyze the multiple risk call sequences respectively to obtain vulnerability analysis results for each risk call sequence. Since the multiple risk call sequences are extracted from the program to be analyzed, the combination of the vulnerability analysis results for the multiple risk call sequences may be used as the vulnerability analysis result of the program to be analyzed.

[0055] In the embodiments of the present specification, since different risk call sequences are analyzed independently of each other, the overall analysis of the program to be analyzed is achieved by analyzing multiple risk call sequences. The advantages of this include at least: by extracting the risk call sequence, the number of tokens corresponding to each extracted risk call sequence is necessarily less than the number of tokens of the entire program to be analyzed, thereby reducing the problem of being unable to implement program vulnerability analysis due to exceeding the maximum token number limit of the large model; in addition, sending the risk call sequence to the large model for analysis reduces the analysis difficulty of the model compared to sending the entire program to be analyzed to the large model for analysis, which is conducive to improving the analysis quality.

[0056] It should be understood that in the methods described in one or more embodiments of this specification, the order of some steps can be adjusted according to actual needs, or some steps can be omitted.

[0057] Figure 2 The method in the embodiment of the present invention identifies the first type of risk instructions with execution risk from the program to be analyzed, and then extracts the risk call sequence containing the first type of risk instructions according to the data dependency relationship, and then provides the risk call sequence to the big model for analysis and obtains the vulnerability analysis result. Therefore, on the one hand, by extracting the risk call sequence from the program to be analyzed and inputting it into the big model for analysis, instead of passing the entire program to be analyzed to the big model for analysis, the risk of failing to implement program vulnerability analysis due to the program to be analyzed not meeting the maximum token number limit of the big model input is reduced; on the other hand, by analyzing the data dependency relationship for risk call sequence extraction, irrelevant context is reduced from being input into the big model, so that when the big model is analyzing, there is no need to pay attention to the code irrelevant to the potential vulnerability point, which reduces the difficulty of the big model in understanding the code, thereby improving the accuracy of the vulnerability analysis result of the big model.

[0058] based on Figure 2 The present specification also provides some improved implementation methods of the method, which are described below.

[0059] In one or more embodiments of the present specification, a specific method for identifying first-category risk instructions from the program to be analyzed is further provided, which is described in detail below.

[0060] Optionally, a blacklist containing specified function names may be pre-set. The blacklist includes a series of specified function names that may cause program vulnerabilities if data is improperly processed during execution. The specified function may be a function that may cause various risks such as data overflow risk, data consistency and integrity risk, resource exhaustion risk, input verification risk, etc. during execution.

[0061] Therefore, in step 202, the identification of first-category risk instructions with execution risks in the program to be analyzed may specifically include: detecting keywords matching the specified function name in the program to be analyzed; and determining the instructions containing the detected keywords matching the specified function name as first-category risk instructions.

[0062] In actual applications, keyword (eg, library function name) matching can be used to identify library functions that have the risk of causing program vulnerabilities.

[0063] Furthermore, the designated function may include at least one of a data copy function lacking a boundary check mechanism, a command execution function lacking a security check mechanism, or a formatted string output function lacking a parameter matching check. This is merely an example of a typical function type that is prone to causing program vulnerabilities, and may not be limited thereto in actual application.

[0064] For example, data copy functions that lack a boundary check mechanism may include strcpy function, memcpy function, etc., but are not limited to this. For another example, formatted string output functions that lack parameter matching checks may include printf function, sprintf function, etc. For another example, command execution functions that lack a security check mechanism may include system function, execv function, etc. The examples given here are only specific examples of common risk functions that are prone to cause program vulnerabilities. In actual applications, they may not be limited to this. For example, the blacklist used for keyword matching may be adjusted according to actual business experience or needs.

[0065] In addition, among the first category of risky instructions, the instructions that are likely to cause program vulnerabilities due to their impact on the control flow of the program are usually loop judgment statements in actual applications, and when the judgment criteria that the loop judgment relies on are not constants, it is easy to cause resource exhaustion vulnerabilities.

[0066] Therefore, in step 202, identifying the first type of risk instructions with execution risks in the program to be analyzed may specifically include: identifying the loop judgment statements in the program to be analyzed; determining whether the judgment criteria in the loop conditions of the loop judgment statements are constants; if the judgment criteria in the loop conditions of the loop judgment statements are not constants, then determining the loop judgment statements as the first type of risk instructions.

[0067] In practical applications, all loop judgment statements can be found through code parsing, and from the found loop judgment statements, the loop judgment statements whose judgment criteria in the loop conditions are not constants are filtered out. Furthermore, the loop judgment statements whose judgment criteria in the loop conditions are not constants and are filtered out are determined as risky loop judgment statements, that is, determined as the first type of risk instructions with execution risks.

[0068] For example, in the loop judgment statement for (i = 1; i < variable; i++), the judgment criteria for the loop condition is the variable variable, rather than a constant. It can be considered that the loop judgment statement for (i = 1; i < variable; i++) is likely to cause a resource exhaustion vulnerability. Therefore, the loop judgment statement for (i = 1; i < variable; i++) can be determined as the first type of risk instructions with execution risks.

[0069] In one or more embodiments of this specification, a specific method for extracting a risk call sequence from the program to be analyzed is further provided, which is introduced in detail below.

[0070] In practical applications, starting from the first type of risk instructions identified in step 202, first, the calling functions of the functions where the first type of risk instructions are located can be analyzed, and the dependent parameters of the input parameters of the first type of risk instructions can be analyzed. Then, the calling functions of the previously determined calling functions and the dependent parameters of the previously determined dependent parameters can be analyzed, and recursive analysis is performed until there are no further calling functions and dependent parameters, and a function call sequence can be obtained.

[0071] For ease of understanding, Figure 3 FIG. is a schematic diagram of a method for determining a risk call sequence based on data dependency relationships in an example program to be analyzed provided by an embodiment of this specification.

[0072] As Figure 3 shown, assuming that the system library function is used as the specified function with execution risks, then, it can be determined from the program to be analyzed as Figure 3The risk addresses corresponding to the first type of risk instructions are shown as (Loc1; system; Arg1), (10; system; a), (Loc2; system; Arg2), etc. Among them, the risk address (10; system; a) can indicate that the code line number of the current first type of risk instruction is 10, the name of the called function is system, and the input parameter of the called function is a.

[0073] Then the risk call sequence can be determined. Taking the risk address (10; system; a) as an example, Figure 3 In the program shown, the parameter a in the risk address (10; system; a) has a dependency relationship with para2 of its calling function fun1. Therefore, we continue to track the calling function of fun1 and analyze the data dependency of para2. We recursively analyze until there is no data dependency and calling function. Therefore, we can get the set of function call chains corresponding to the risk address (10; system; a) as {[fun2, fun1], […, fun3, fun1], …}.

[0074] exist Figure 3 In the example, the input parameter of the function system called by the first type of risk instruction only includes a, so data dependency analysis can be performed based on the parameter a to determine the function call chain. It can be understood that when the function called by the first type of risk instruction contains multiple input parameters, it is necessary to perform data dependency analysis on each input parameter in the function to determine the function call chain.

[0075] In an optional embodiment of the present specification, the code unit calling sequence determined by combining the first type of risk instructions identified in step 202 with the data dependency relationship can be provided to the large model for analysis. As a result, the amount of code provided to the large model for identification can be reduced to a certain extent, and the risk of being unable to perform analysis due to the program to be analyzed not meeting the maximum token number limit of the large model input can be reduced; and the input of irrelevant context to the large model can also be reduced to a certain extent, so that when the large model is analyzing, there is no need to pay attention to code that is not related to potential vulnerability points, thereby reducing the difficulty of the large model in understanding the code, thereby improving the accuracy of the vulnerability analysis results of the large model.

[0076] Furthermore, in actual applications, the first type of risky instructions with execution risks do not necessarily lead to program vulnerabilities, and large models are not necessarily always reliable. For example, large model hallucinations may lead to errors in the analysis results, and situations that do not necessarily lead to program vulnerabilities may be mistakenly reported as program vulnerabilities. In view of this, in order to further improve the accuracy of program vulnerability analysis using large models, the code unit call sequences determined based on data dependencies can be further screened, and the disadvantages that may be caused by large model hallucinations can be reduced to a certain extent by increasing the high risk level of the data input to the large model. Among them, the "hallucination" of the large model refers to the fact that the generative AI model (such as GPT, BERT, etc.) generates content that does not exist or does not conform to the facts when answering questions or generating text. These contents may seem reasonable and logical, but are actually not based on real data or reliable information sources.

[0077] Specifically, in an optional embodiment of the present specification, based on the code unit calling sequence determined based on the data dependency relationship, the taint analysis concept of the program can be borrowed to identify the taint source in the code unit calling sequence, and the risk calling sequence provided to the large model can be intercepted from the code unit calling sequence related to the taint source.

[0078] Taint analysis is a technique for tracking and analyzing the flow of taint information in a program. In vulnerability analysis, taint analysis technology can be used to mark the data of interest (usually from the external input of the program) as tainted data, and then by tracking the flow of information related to the tainted data, it can be known whether the tainted data will affect certain key program operations, thereby mining program vulnerabilities. In taint analysis, taint sources (Sources) represent the direct introduction of untrusted data or confidential data into the system; taint sinks (Sinks) represent the direct generation of security-sensitive operations or the leakage of privacy data to the outside world. In an embodiment of the present specification, the first type of risk instructions with execution risks identified in step 202 can be regarded as taint sinks (Sinks), and on this basis, it is further identified whether there are taint sources (Sources) from the code unit call sequence with the first type of risk instructions as the last unit, and in the case of taint sources (Sources), the sequence between the taint sources (Sources) and the taint sinks (Sinks) is determined as a risk call sequence for input into the large model for analysis.

[0079] Further, in step 204, extracting a risk call sequence from the program to be analyzed according to the data dependency relationship of the input parameters of the first type of risk instructions in the program to be analyzed may specifically include: extracting a code unit call sequence from the program to be analyzed according to the data dependency relationship of the input parameters of the first type of risk instructions in the program to be analyzed, the last code unit in the code unit call sequence contains the first type of risk instruction, and the next code unit in the adjacent code unit combination in the code unit call sequence is called by the previous code unit; identifying the second type of risk instruction in the code unit call sequence that can introduce external controllable input; intercepting a risk call sequence from the code unit call sequence according to the second type of risk instruction; the first code unit in the risk call sequence contains the second type of risk instruction; the last code unit in the risk call sequence contains the first type of risk instruction; the next code unit in the adjacent code unit combination in the risk call sequence is called by the previous code unit. The next code unit in the adjacent code unit combination in the risk call sequence is called by the previous code unit. In addition, the arrangement order of each code unit in the risk call sequence is consistent with the arrangement order of these code units in the code unit call sequence.

[0080] In a program, external controllable input refers to input operations such as user input, file reading, and network data. These inputs may be used in other parts of the program without verification, causing security issues. In the embodiments of this specification, functions that directly introduce untrusted data or confidential data into the system can be identified as the second type of risk instructions.

[0081] Taking the code unit as a function as an example, in the embodiments of this specification, a risk call chain can be recorded as DF=[f1, f2, ..., fn], where f1 contains the second type of risk instructions, fn contains the first type of risk instructions, fj (1 < j ≤ n) contains or does not contain the second type of risk instructions, and for any i∈[1, n), fi calls f(i+1). The case where the code unit is a code line or a code block is similar and will not be repeated here.

[0082] As mentioned above, in the optional embodiments of the present specification, the code unit call sequence can be directly determined as a risk call sequence. That is to say, in some optional embodiments, the risk call sequence may only satisfy that the last code unit contains the first type of risk instruction, without satisfying that the first code unit contains the second type of risk instruction. In other optional embodiments, the risk call sequence may not only satisfy that the last code unit contains the first type of risk instruction, but also satisfy that the first code unit contains the second type of risk instruction. Compared with the situation where the first code unit does not need to contain the second type of risk instruction, if the risk call sequence satisfies that the first code unit contains the second type of risk instruction, false positives can be reduced, further improving the accuracy of the program vulnerability analysis results.

[0083] It should also be noted that if we completely follow the taint analysis process, first determine the taint sources (Sources) from the program to be analyzed, and then perform forward slicing based on the taint sources (Sources), we will face the problem that the data propagation path is too complicated, which is easy to cause path explosion. In actual application, for a program to be analyzed, too many code unit call chains will be obtained, and even the code unit call chain cannot be analyzed completely due to excessive analysis overhead, which will lead to the problem that program vulnerability analysis cannot be realized due to excessive data analysis.

[0084] refer to Figure 3 For example, for the function call chain [fun2, fun1], the second-class risk instruction (source function) fgets is called in fun2, and the first parameter a of the source function fgets has a data dependency with the parameter b of func1 (snprintf in line 18 stores a in b). Therefore, [fun2, fun1] is a risky call chain.

[0085] Assume that the function call chain […, fun3, fun1] is formed into [fun5, fun4, fun3, fun1] after recursive analysis, and fun4 calls the second type of risky instructions, then the risky call chain extracted from the function call chain [fun5, fun4, fun3, fun1] can be [fun4, fun3, fun1].

[0086] In an optional embodiment of the present specification, the second type of risk instruction that can introduce external controllable input identified from the code unit call sequence may include one, two or more risk instructions. If the second type of risk instruction specifically includes the first risk instruction and the second risk instruction; then, the interception of the risk call sequence from the code unit call sequence according to the second type of risk instruction may specifically include: on the one hand, intercepting a first candidate sequence from the code unit call sequence according to the first risk instruction, the first code unit in the first candidate sequence includes the first risk instruction, and the last code unit in the first candidate sequence includes the first type of risk instruction; on the other hand, intercepting a second candidate sequence from the code unit call sequence according to the second risk instruction, the first code unit in the second candidate sequence includes the second risk instruction, and the last code unit in the second candidate sequence includes the first type of risk instruction; then, the longer sequence of the first candidate sequence and the second candidate sequence may be determined as the risk call sequence. In view of this, the risk call sequence obtained for subsequent analysis satisfies: the first risk instruction among the two or more risk instructions is contained in the first code unit of the risk call sequence; the risk instructions other than the first risk instruction among the two or more risk instructions are contained in code units other than the first code unit of the risk call sequence.

[0087] In actual application, when the second type of risk instructions identified for a code unit call sequence specifically include two or more risk instructions, there may be only one risk call sequence determined. In other words, for a code unit call sequence, only no more than one risk call sequence can be determined in the end. This is because the candidate sequences corresponding to each other determined based on two or more risk instructions have a containment relationship with each other. In this case, there is no need to repeatedly analyze the contained subsequences, and redundant analysis can be avoided to save computing resources and improve analysis efficiency.

[0088] refer to Figure 3For example, suppose that the function call chain [……, fun3, fun1] is formed into [fun6, fun4, fun3, fun1] after recursive analysis, and both fun6 and fun4 call the second type of risky instructions, then the risky call chain extracted from the function call chain [fun6, fun4, fun3, fun1] may include [fun4, fun3, fun1] and [fun6, fun4, fun3, fun1]. Considering that [fun4, fun3, fun1] is a subsequence of [fun6, fun4, fun3, fun1], in actual application, in order to save computing resources and improve analysis efficiency, only [fun6, fun4, fun3, fun1] can be analyzed without analyzing [fun4, fun3, fun1].

[0089] In an optional embodiment of the present specification, the code unit call sequence identified from the sequence to be analyzed may include more than one, and then, based on these more than one code unit call sequences, more than one risk call sequence may be determined. In this case, the included subsequences can be further filtered out (i.e., not input into the large model for analysis) by further determining the inclusion relationship between each risk call sequence in the more than one risk call sequence, so as to avoid redundant analysis and improve analysis efficiency.

[0090] Specifically, the code unit call sequence may specifically include a first call sequence and a second call sequence; accordingly, the extracting the risk call sequence from the code unit call sequence according to the second type of risk instruction may specifically include: on the one hand, extracting a third candidate sequence from the first call sequence according to the second type of risk instruction, the first code unit in the third candidate sequence includes the second type of risk instruction, and the last code unit in the third candidate sequence includes the first type of risk instruction; on the other hand, extracting a fourth candidate sequence from the second call sequence according to the second type of risk instruction, the first code unit in the fourth candidate sequence includes the second type of risk instruction, and the last code unit in the fourth candidate sequence includes the first type of risk instruction; thereafter, it may be determined whether the third candidate sequence is a subsequence of the fourth candidate sequence to obtain a subsequence determination result; if the subsequence determination result indicates that the third candidate sequence is a subsequence of the fourth candidate sequence, only the fourth candidate sequence among the third candidate sequence and the fourth candidate sequence is determined as the risk call sequence.

[0091] Among them, the third candidate sequence is a subsequence of the fourth candidate sequence, and the specific situations may include: optionally, the third candidate sequence may be exactly the same as the fourth candidate sequence; or optionally, the third candidate sequence may be obtained by intercepting from the fourth candidate sequence, in which case, the calling relationship of the code units in the third candidate sequence may be completely contained in the fourth candidate sequence.

[0092] Continue to refer Figure 3 For example, suppose that the function call chain [……, fun3, fun1] not only forms [fun5, fun4, fun3, fun1] but also forms [fun6, fun4, fun3, fun1] after recursive analysis, and both fun6 and fun4 call the second type of risky instructions. Then, the candidate call chain extracted from the function call chain [fun5, fun4, fun3, fun1] can be [fun4, fun3, fun1], and the candidate call chain extracted from the function call chain [fun6, fun4, fun3, fun1] can include [fun6, fun4, fun3, fun1]. Furthermore, the candidate call chain [fun4, fun3, fun1] and the candidate call chain [fun6, fun4, fun3, fun1] can be compared and analyzed. Since [fun4, fun3, fun1] is a subsequence of [fun6, fun4, fun3, fun1], only [fun6, fun4, fun3, fun1] can be determined as the risk call chain for input into the large model for program vulnerability analysis. In this way, redundant analysis can be avoided and the analysis efficiency can be further improved.

[0093] Based on the above analysis, for the program to be analyzed, if the set of function call chains extracted from it includes {[fun2, fun1], [fun5, fun4, fun3, fun1], [fun6, fun4, fun3, fun1]}, and further analysis shows that fun2, fun6 and fun4 all call the second type of risk instructions, then the obtained set of risk call chains corresponding to the program to be analyzed can include {[fun2, fun1], [fun6, fun4, fun3, fun1]}.

[0094] The above is a set of risk call chains related to the risk address (10; system; a) in the program to be analyzed. In actual application, similar analysis can be performed for other risk addresses in the program to be analyzed, such as (Loc1; system; Arg1), (Loc1; system; Arg2), etc. In the embodiment of this specification, the set of risk call chains corresponding to the program to be analyzed can include all risk call chains obtained by analyzing multiple risk addresses respectively, and these risk call chains do not belong to the inclusion relationship with each other, so as to reduce the redundant analysis of the subsequent large model and improve the analysis efficiency.

[0095] In one or more embodiments of the present specification, a specific method is further provided for generating session prompt information for input into a large model for a risk call sequence and calling the large model for program vulnerability analysis based on the generated session prompt information, which is described in detail below.

[0096] In an optional embodiment, in step 206, the step of generating a session prompt information for inputting into the big model for the risk call sequence may specifically include: generating a piece of prompt information for inputting into the big model for the risk call sequence. Accordingly, in step 208, the step of inputting the session prompt information into the big model to obtain the vulnerability analysis result of the program to be analyzed output by the big model may specifically include: inputting the piece of prompt information into the big model to obtain the vulnerability analysis result of the program to be analyzed output by the big model.

[0097] Based on the scheme of at least some embodiments of the present specification, different risk call sequences can be processed through different sessions. For example, for the program to be analyzed, if n risk call sequences are extracted from it, n sessions with the big model can be opened, and the big model is called in these n sessions to process each of the n risk call sequences. Therefore, by extracting the risk call sequence, on the one hand, the interference of a large number of noise codes that do not have risks in the program to be analyzed is filtered out, which is conducive to improving the accuracy of the analysis results of the big model; on the other hand, only the risk call sequence with potential risks in the program to be analyzed is analyzed, which can actually reduce the workload of the big model for code analysis, which is conducive to improving the analysis efficiency and reducing the risk of exceeding the maximum token number limit of the big model; on the other hand, since there may be more than one risk call sequence extracted, after extracting more than one risk call sequence, the more than one risk call sequence can be processed in parallel, thereby improving the analysis efficiency of the program analysis of the program to be analyzed.

[0098] In the process of applying large models to program vulnerability analysis, large models usually have a maximum token number limit. If the number of tokens corresponding to the text input to the large model exceeds the maximum token number limit, the model may truncate the input text or return an error, resulting in failure to analyze normally; and the number of tokens input to the large model will affect the performance of the large model and the consumption of computing resources. For example, for the typical large model GPT-3, different versions have different configurations, and the common maximum token number limit is 4096, which means that the total number of tokens of the text input and output in one request cannot exceed 4096. For another example, for the typical large model GPT-4, different versions have different configurations, and the common maximum token number limit is 8192, 32768, etc., which means that the total number of tokens of the text input and output in one request cannot exceed the corresponding 8192, 32768.

[0099] Furthermore, considering that in a single request and response, the large model has a fixed maximum token number limit, which means that the total token number of the input text and the output text cannot exceed this limit, in the embodiments of the present specification, when analyzing each risk call sequence, it is proposed to set a prompt information sequence corresponding to the risk call sequence, that is, to generate multiple session prompt information, thereby, the analysis request can be sent to the model in batches.

[0100] Specifically, the step of generating session prompt information for inputting into the large model for the risk call sequence may specifically include: generating a prompt information sequence for inputting into the large model for the risk call sequence; the order of each prompt information in the prompt information sequence is consistent with the order of each code unit in the risk call sequence. Accordingly, the step of inputting the session prompt information into the large model to obtain the vulnerability analysis result of the program to be analyzed output by the large model may specifically include: inputting each prompt information in the prompt information sequence into the large model in sequence order to obtain the vulnerability analysis result output by the large model.

[0101] The order of arrangement of each prompt information corresponding to each code unit in the risk call sequence in the prompt information sequence is consistent with the order of arrangement of each prompt information in the risk call sequence. As an example, assuming that the risk call sequence contains fun4-fun3-fun1 in sequence order, then the corresponding prompt information contains m4-m3-m1 in sequence order, where m4 corresponds to fun4, m3 corresponds to fun3, and m1 corresponds to fun1.

[0102] Furthermore, the generation of a prompt information sequence for inputting into the large model for the risk call sequence may specifically include: obtaining a preset prompt information template; the prompt information template includes a starting prompt template, an intermediate prompt template and an ending prompt information; using the starting prompt template, generating starting prompt information for the first code unit in the risk call sequence; using the intermediate prompt template, generating intermediate prompt information for each code unit in the risk call sequence except the first code unit. Accordingly, the inputting of each prompt information in the prompt information sequence into the large model in sequence order to obtain the vulnerability analysis result output by the large model may specifically include: inputting the starting prompt information, the intermediate prompt information and the ending prompt information into the large model in sequence to obtain the vulnerability analysis result output by the large model.

[0103] Wherein, each prompt information in the intermediate prompt information may correspond to each code unit in the other code units in sequence one by one.

[0104] In actual application, for a certain risk call sequence, the starting prompt information generated based on the first code unit of the risk call sequence, at least one intermediate prompt information generated based on at least one other code unit of the risk call sequence, and the ending prompt information can be taken together as the prompt information sequence corresponding to the risk call sequence. That is, the prompt information sequence corresponding to the risk call sequence can include one starting prompt information, at least one intermediate prompt information, and one ending prompt information.

[0105] For example, for the risk call sequence [fun6, fun4, fun3, fun1], a prompt information template can be used to generate a starting prompt information m6 for the first code unit fun6 in the risk call sequence; and an intermediate prompt template can be used to generate intermediate prompt information m4, m3 and m1 respectively for each other code unit fun4, fun3 and fun1 in the risk call sequence; and, combined with the end prompt information m0, a prompt information sequence [m6, m4, m3, m1, m0] corresponding to the risk call sequence [fun6, fun4, fun3, fun1] can be obtained.

[0106] Optionally, the use of the starting prompt template to generate starting prompt information for the first code unit in the risk call sequence may specifically include: filling the second-category risk instructions contained in the first code unit, the input parameters of the second-category risk instructions, and the code of the first code unit into the starting prompt template to obtain starting prompt information; the starting prompt information is used to instruct the large model to use the second-category risk instructions as a pollution source and mark the input parameters of the second-category risk instructions as pollution labels to analyze the program vulnerabilities of the first code unit.

[0107] Optionally, the intermediate prompt template is used to generate intermediate prompt information for other code units in the risk call sequence except the first code unit, which may specifically include: for a target code unit in other code units in the risk call sequence except the first code unit, the code of the target code unit is filled into the intermediate prompt template to obtain target intermediate prompt information corresponding to the target code unit; the target intermediate prompt information is used to instruct the large model to continue analyzing the program vulnerabilities of the target code unit based on the analysis results of the previous step.

[0108] Optionally, the starting prompt information, the intermediate prompt information and the ending prompt information are sequentially input into the large model to obtain the vulnerability analysis result output by the large model, which may specifically include: inputting the starting prompt information into the large model to obtain the starting feedback information output by the large model; after receiving the starting feedback information, inputting each of the intermediate prompt information into the large model in sequence to obtain the intermediate feedback information output by the large model in response to each of the input intermediate prompt information; after receiving the intermediate feedback information corresponding to the last intermediate prompt information in each of the intermediate prompt information, inputting the ending prompt information into the large model to obtain the vulnerability analysis result for the risk call sequence output by the large model.

[0109] In actual application, the prompt information input into the large model may include statements for describing analysis requirements, statements for describing output formats, etc., but is not limited thereto, and may be set according to actual business needs. Further, in the case of applying a prompt information sequence, the starting prompt template may include statements for describing analysis requirements, such as the type of vulnerability to be checked, etc.; at least one of the starting prompt template, the intermediate prompt template, and the ending prompt information may include statements for describing output formats, but is not limited thereto.

[0110] For large models, the processing of a single request includes: receiving a request from the requester, processing the request, generating a response, and then feeding the response back to the requester. During the processing of a single request, the total number of input and output tokens cannot exceed the maximum number of tokens in the model.

[0111] In an embodiment of the present specification, each prompt information in the prompt information sequence can be input to the large model one by one in sequence order. Further, after receiving the first analysis result output by the large model in response to the first prompt information in the prompt information sequence, the second prompt information immediately following the first prompt information can be input to the large model. Continuing with the above example, if the prompt information sequence is [m6, m4, m3, m1, m0], then m6, m4, m3, m1 and m0 can be input to the large model in sequence. Further, m6 can be input to the large model first to obtain the starting analysis result n6 output by the large model, and then the intermediate prompt information m4 can be input to the large model to obtain the intermediate analysis result m4 output by the large model, and then the same can be done. After the end prompt information m0 is input to the large model, the overall vulnerability analysis result for the risk call sequence [fun6, fun4, fun3, fun1] output by the large model can be obtained.

[0112] Based on the scheme of at least some embodiments of the present specification, a prompt information template can be used to generate a prompt information sequence corresponding to the risk call sequence to be analyzed. Thus, by providing each prompt information in the prompt information sequence to the large model one by one, the large model can be made to analyze each code unit in the risk call sequence in sequence. Combined with the ability of the large model to analyze based on the context, the vulnerability analysis results for the entire risk call sequence can be obtained on the basis of the large model analyzing each code unit in sequence. The advantage of doing so is at least that the code of the entire risk call sequence does not need to be provided to the large model in its entirety at one time. Especially when the program to be analyzed is more complex and the risk call sequence is longer, the problem of exceeding the inherent token limit of the large model due to the code to be analyzed being too lengthy can be avoided, and the analysis difficulty of the model can be further reduced, which is conducive to further improving the analysis quality.

[0113] Based on the scheme of at least some embodiments of the present specification, a risk call sequence can be split into corresponding multiple prompt information. For example, multiple requests and responses can be made with code units (e.g., functions) as nodes. This allows large models to be analyzed within the capacity of the maximum token number limit. Although sending multiple requests in a session requires maintaining the previous historical messages, which consumes tokens, truncating earlier request content in the session to reduce token usage and ensure that the latest information is retained can enable the model to complete the analysis of the entire risk call sequence. In summary, if the input of the entire program to be analyzed exceeds the maximum token number limit of the model, making the model unable to analyze or reducing the analysis quality of the model, then splitting the program into independent risk call sequences for separate sessions, and using the code units (e.g., functions) in the risk call sequence as nodes to analyze step by step using the model context can largely solve the problem that the entire program to be analyzed exceeds the maximum token number limit of the model, making the model unable to analyze or reducing the analysis quality of the model.

[0114] In one or more embodiments of the present specification, it is also possible to determine whether to generate one prompt message or a prompt message sequence containing multiple prompt messages when generating prompt messages for the risk call sequence based on the amount of code contained in the risk call sequence to be analyzed.

[0115] In an optional embodiment, the amount of code contained in the risk call sequence can be determined; it is determined whether the amount of tokens corresponding to the amount of code exceeds a preset token amount threshold, and a code amount judgment result is obtained; if the code amount judgment result indicates that the amount of tokens corresponding to the amount of code exceeds (i.e., is greater than) the preset token amount threshold, a prompt information sequence for input into the large model can be generated; if the code amount judgment result indicates that the amount of tokens corresponding to the amount of code does not exceed (i.e., is less than or equal to) the preset token amount threshold, a prompt information for input into the large model can be generated.

[0116] Among them, the token amount threshold may correspond to the large model used. In actual application, different large models have different thresholds for the amount of information received once. For example, the GPT-3 large model, the common version has a 4096 token limit. For another example, the GPT-4 large model, the common version has an 8192 token limit, and some advanced versions have a 32768 token limit.

[0117] Based on the above method of this specification, by judging whether to use one prompt message to interact with the large model or to use a prompt message sequence containing multiple prompt messages to interact with the large model according to the amount of code contained in the risk call sequence, on the one hand, it can avoid the situation where the code amount of the risk call sequence to be analyzed is too large to be provided to the large model at one time, resulting in analysis failure; on the other hand, when the code amount of the risk call sequence is small, analysis can be achieved in a relatively simple way to improve analysis efficiency.

[0118] The various technical features in the above embodiments can be combined arbitrarily as long as there is no conflict or contradiction between the combinations of features. However, due to space limitations, they are not described one by one. Therefore, any combination of the various technical features in the above embodiments also falls within the scope of this specification.

[0119] Based on the same idea, the embodiments of this specification also provide a device corresponding to the above method.

[0120] Figure 4 The embodiments of this specification provide corresponding to Figure 2 A structural diagram of a program vulnerability analysis device.

[0121] like Figure 4 As shown, the device may include: A risk instruction identification module 402 is used to identify the first type of risk instructions with execution risks in the program to be analyzed; The risk call sequence extraction module 404 is used to extract a risk call sequence from the program to be analyzed according to the data dependency relationship of the input parameters of the first type of risk instructions in the program to be analyzed; the last code unit in the risk call sequence contains the first type of risk instructions; the latter code unit in the combination of adjacent code units in the risk call sequence is called by the previous code unit; A session prompt information generating module 406 is used to generate session prompt information for input into the large model according to the risk call sequence; the session prompt information is used to instruct the large model to check for program vulnerabilities in the risk call sequence; The vulnerability analysis module 408 is used to input the session prompt information into the large model to obtain the vulnerability analysis result of the program to be analyzed output by the large model.

[0122] based on Figure 4 The present specification also provides some specific implementation schemes of the method, which are described below.

[0123] Optionally, the risk instruction identification module 402 may be specifically used to: detect keywords matching a specified function name in the program to be analyzed; and determine the instructions containing the detected keywords matching the specified function name as first-category risk instructions.

[0124] Optionally, the designated function may include at least one of a data copy function lacking a boundary check mechanism, a command execution function lacking a security check mechanism, or a formatted string output function lacking a parameter matching check.

[0125] Optionally, the risk instruction identification module 402 can be specifically used to: identify the loop judgment statement in the program to be analyzed; determine whether the judgment criterion in the loop condition of the loop judgment statement is a constant; if the judgment criterion in the loop condition of the loop judgment statement is not a constant, then determine the loop judgment statement as a first-category risk instruction.

[0126] Optionally, the risk call sequence extraction module 404 can be specifically used to: extract a code unit call sequence from the program to be analyzed according to the data dependency relationship of the input parameters of the first type of risk instructions in the program to be analyzed; the last code unit in the code unit call sequence contains the first type of risk instruction; the latter code unit in the adjacent code unit combination in the code unit call sequence is called by the previous code unit; identify the second type of risk instructions in the code unit call sequence that can introduce external controllable input; according to the second type of risk instructions, intercept the risk call sequence from the code unit call sequence; the first code unit in the risk call sequence contains the second type of risk instruction.

[0127] Optionally, the second type of risk instruction may specifically include a first risk instruction and a second risk instruction; the extracting a risk calling sequence from the code unit calling sequence based on the second type of risk instruction may specifically include: extracting a first candidate sequence from the code unit calling sequence based on the first risk instruction; the first code unit in the first candidate sequence contains the first risk instruction; the last code unit in the first candidate sequence contains the first type of risk instruction; extracting a second candidate sequence from the code unit calling sequence based on the second risk instruction; the first code unit in the second candidate sequence contains the second risk instruction; the last code unit in the second candidate sequence contains the first type of risk instruction; and determining the longer sequence between the first candidate sequence and the second candidate sequence as the risk calling sequence.

[0128] Optionally, the code unit calling sequence may specifically include a first calling sequence and a second calling sequence; the extracting the risk calling sequence from the code unit calling sequence according to the second type of risk instruction may specifically include: extracting a third candidate sequence from the first calling sequence according to the second type of risk instruction; the first code unit in the third candidate sequence contains the second type of risk instruction; the last code unit in the third candidate sequence contains the first type of risk instruction; extracting a fourth candidate sequence from the second calling sequence according to the second type of risk instruction; the first code unit in the fourth candidate sequence contains the second type of risk instruction; the last code unit in the fourth candidate sequence contains the first type of risk instruction; judging whether the third candidate sequence is a subsequence of the fourth candidate sequence, and obtaining a subsequence judgment result; if the subsequence judgment result indicates that the third candidate sequence is a subsequence of the fourth candidate sequence, then determining only the fourth candidate sequence among the third candidate sequence and the fourth candidate sequence as the risk calling sequence.

[0129] Optionally, the session prompt information generation module 406 can be used to generate a prompt information sequence for input into the large model according to the risk call sequence; the order of each prompt information in the prompt information sequence is consistent with the order of each code unit in the risk call sequence. The vulnerability analysis module 408 can be used to input each prompt information in the prompt information sequence into the large model in sequence order to obtain the vulnerability analysis result output by the large model.

[0130] Optionally, the session prompt information generation module 406 can be specifically used to: obtain a preset prompt information template; the prompt information template includes a start prompt template, an intermediate prompt template and an end prompt information; use the start prompt template to generate the start prompt information for the first code unit in the risk call sequence; use the intermediate prompt template to generate intermediate prompt information for other code units in the risk call sequence except the first code unit. The vulnerability analysis module 408 can be specifically used to: input the start prompt information, the intermediate prompt information and the end prompt information into the large model in sequence to obtain the vulnerability analysis result output by the large model.

[0131] Optionally, the use of the starting prompt template to generate starting prompt information for the first code unit in the risk call sequence may specifically include: filling the second-category risk instructions contained in the first code unit, the input parameters of the second-category risk instructions, and the code of the first code unit into the starting prompt template to obtain starting prompt information; the starting prompt information is used to instruct the large model to use the second-category risk instructions as a pollution source and mark the input parameters of the second-category risk instructions as pollution labels to analyze the program vulnerabilities of the first code unit.

[0132] Optionally, the adopting of the intermediate prompt template to generate intermediate prompt information for other code units in the risk call sequence except the first code unit may specifically include: For the target code unit in the code units other than the first code unit in the risk call sequence, the code of the target code unit is filled into the intermediate prompt template to obtain the target intermediate prompt information corresponding to the target code unit; the target intermediate prompt information is used to instruct the large model to continue analyzing the program vulnerabilities of the target code unit based on the analysis results of the previous step.

[0133] Optionally, the starting prompt information, the intermediate prompt information and the ending prompt information are sequentially input into the large model to obtain the vulnerability analysis result output by the large model, which may specifically include: inputting the starting prompt information into the large model to obtain the starting feedback information output by the large model; after receiving the starting feedback information, inputting each of the intermediate prompt information into the large model in sequence to obtain the intermediate feedback information output by the large model in response to each of the input intermediate prompt information; after receiving the intermediate feedback information corresponding to the last intermediate prompt information in each of the intermediate prompt information, inputting the ending prompt information into the large model to obtain the vulnerability analysis result for the risk call sequence output by the large model.

[0134] Optionally, the session prompt information generation module 406 can be used to generate a prompt information for input into the big model for the risk call sequence. The vulnerability analysis module 408 can be used to input the prompt information into the big model to obtain the vulnerability analysis result of the program to be analyzed output by the big model.

[0135] Optionally, the code unit includes at least one of a code line, a function or a code block.

[0136] It is understood that the above modules refer to computer programs or program segments for executing one or more specific functions. In addition, the distinction between the above modules does not mean that the actual program codes must also be separated.

[0137] The above is a schematic scheme of a program vulnerability analysis device of this embodiment. It should be noted that the technical scheme of the program vulnerability analysis device and the technical scheme of the program vulnerability analysis method described above belong to the same concept, and the details not described in detail in the technical scheme of the program vulnerability analysis device can be found in the description of the technical scheme of the program vulnerability analysis method described above.

[0138] Based on the same idea, the embodiments of this specification also provide a device corresponding to the above method.

[0139] Figure 5 The embodiments of this specification provide corresponding to Figure 2 A schematic diagram of the structure of a program vulnerability analysis device. Figure 5 As shown, the device 500 may include: at least one processor 510; and, A memory 530 in communication with the at least one processor; wherein, The memory 530 stores instructions 520 that can be executed by the at least one processor 510, and the instructions are executed by the at least one processor 510 so that the at least one processor 510 can: identify a first type of risk instruction with execution risk in the program to be analyzed; extract a risk call sequence from the program to be analyzed based on the data dependency relationship of the input parameters of the first type of risk instruction in the program to be analyzed; the last code unit in the risk call sequence contains the first type of risk instruction; the latter code unit in the combination of adjacent code units in the risk call sequence is called by the previous code unit; for the risk call sequence, generate session prompt information for input to the large model; the session prompt information is used to instruct the large model to check the program vulnerabilities in the risk call sequence; input the session prompt information into the large model to obtain the vulnerability analysis result of the program to be analyzed output by the large model.

[0140] The above is a schematic scheme of a program vulnerability analysis device of this embodiment. It should be noted that the technical scheme of the computing device and the technical scheme of the program vulnerability analysis method described above are of the same concept, and the details not described in detail in the technical scheme of the computing device can be found in the description of the technical scheme of the program vulnerability analysis method described above.

[0141] An embodiment of the present application further provides a computer-readable storage medium storing computer instructions, which, when executed by a processor, implement the steps of the program vulnerability analysis method as described above.

[0142] The above is a schematic scheme of a computer-readable storage medium of this embodiment. It should be noted that the technical scheme of the storage medium and the technical scheme of the program vulnerability analysis method described above are of the same concept, and the details not described in detail in the technical scheme of the storage medium can be found in the description of the technical scheme of the program vulnerability analysis method described above.

[0143] An embodiment of the present specification also provides a computer program product, including a computer program / instruction, which implements the steps of the above-mentioned program vulnerability analysis method when executed by a processor.

[0144] The above is a schematic scheme of a computer program product of this embodiment. It should be noted that the technical scheme of the computer program product and the technical scheme of the program vulnerability analysis method described above are of the same concept, and the details not described in detail in the technical scheme of the computer program product can be found in the description of the technical scheme of the program vulnerability analysis method described above.

[0145] Each embodiment in this specification is described in a progressive manner, and the same and similar parts between the embodiments can be referred to each other. Each embodiment focuses on the differences from other embodiments. In particular, for the device and equipment embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiments. The devices, equipment and methods provided in the embodiments of this specification correspond to each other, so the devices and equipment also have beneficial technical effects similar to the corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the corresponding devices and equipment will not be repeated here.

[0146] The above describes specific embodiments of the present application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the accompanying drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0147] In the 1990s, it was very clear whether the improvement of a technology was hardware improvement (for example, improvement of the circuit structure of diodes, transistors, switches, etc.) or software improvement (improvement of the method flow). However, with the development of technology, many improvements of the method flow today can be regarded as direct improvements of the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that the improvement of a method flow cannot be implemented with a hardware entity module. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is such an integrated circuit whose logical function is determined by the user's programming of the device. Designers can "integrate" a digital system on a PLD by programming themselves, without having to ask chip manufacturers to design and make dedicated integrated circuit chips. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented by "logic compiler" software, which is similar to the software compiler used when developing and writing programs, and the original code before compilation must also be written in a specific programming language, which is called hardware description language (HDL). There is not only one kind of HDL, but many kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that it is only necessary to program the method flow slightly in the above-mentioned hardware description languages ​​and program it into the integrated circuit, and then it is easy to obtain the hardware circuit that implements the logic method flow.

[0148] The controller may be implemented in any suitable manner, for example, the controller may take the form of a microprocessor or processor and a computer-readable medium storing a computer-readable program code (e.g., software or firmware) executable by the (micro)processor, a logic gate, a switch, an application-specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, and the memory controller may also be implemented as part of the control logic of the memory. It is also known to those skilled in the art that, in addition to implementing the controller in a purely computer-readable program code manner, the controller may be implemented in the form of a logic gate, a switch, an application-specific integrated circuit, a programmable logic controller, and an embedded microcontroller by logically programming the method steps. Therefore, such a controller may be considered as a hardware component, and the devices for implementing various functions included therein may also be considered as structures within the hardware component. Or even, the devices for implementing various functions may be considered as both software modules for implementing the method and structures within the hardware component.

[0149] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0150] For the convenience of description, the above device is described in various units according to their functions. Of course, when implementing the present application, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0151] It will be appreciated by those skilled in the art that embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0152] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0153] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0154] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0155] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0156] Memory may include non-permanent memory in computer-readable media, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media. Computer-readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, modules of programs or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0157] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0158] The present application may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. The present application may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

[0159] The above is only an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. A program vulnerability analysis method, comprising: Identify the first type of risk instructions with execution risks in the program to be analyzed; Extracting a risk call sequence from the program to be analyzed according to the data dependency relationship of the input parameters of the first type of risk instructions in the program to be analyzed; The last code unit in the risk call sequence contains the first type of risk instruction; the latter code unit in the combination of adjacent code units in the risk call sequence is called by the previous code unit; For the risk call sequence, generating conversation prompt information for input into the big model; The session prompt information is used to instruct the large model to check program vulnerabilities in the risk call sequence; The session prompt information is input into the large model to obtain a vulnerability analysis result of the program to be analyzed output by the large model.

2. The method according to claim 1, wherein the step of identifying the first type of risk instructions with execution risk in the program to be analyzed comprises: Detecting keywords in the program to be analyzed that match the specified function name; The instructions containing the detected keywords matching the specified function name are determined as first-category risk instructions.

3. The method of claim 2, wherein: The designated function includes at least one of a data copy function lacking a boundary check mechanism, a command execution function lacking a security check mechanism, or a formatted string output function lacking a parameter matching check.

4. The method according to claim 1, wherein the step of identifying the first type of risk instructions with execution risks in the program to be analyzed specifically comprises: Identifying loop judgment statements in the program to be analyzed; Determine whether the judgment criterion in the loop condition of the loop judgment statement is a constant; If the judgment criterion in the loop condition of the loop judgment statement is not a constant, the loop judgment statement is determined to be a first-category risk instruction.

5. The method according to claim 1, wherein extracting the risk call sequence from the program to be analyzed according to the data dependency relationship of the input parameters of the first type of risk instructions in the program to be analyzed specifically comprises: Extracting a code unit calling sequence from the program to be analyzed according to a data dependency relationship of input parameters of the first-category risky instruction in the program to be analyzed; The last code unit in the code unit calling sequence contains the first type of risk instruction; the latter code unit in the combination of adjacent code units in the code unit calling sequence is called by the previous code unit; Identifying a second type of risky instruction in the code unit call sequence that can introduce external controllable input; According to the second-category risk instruction, a risk calling sequence is intercepted from the code unit calling sequence; the first code unit in the risk calling sequence contains the second-category risk instruction.

6. The method according to claim 5, wherein the second type of risk instructions specifically includes a first risk instruction and a second risk instruction; and the step of intercepting a risk call sequence from the code unit call sequence according to the second type of risk instruction specifically includes: According to the first risk instruction, a first candidate sequence is intercepted from the code unit call sequence; the first code unit in the first candidate sequence includes the first risk instruction; The last code unit in the first candidate sequence includes the first type of risk instruction; According to the second risk instruction, a second candidate sequence is intercepted from the code unit call sequence; the first code unit in the second candidate sequence contains the second risk instruction; the last code unit in the second candidate sequence contains the first type of risk instruction; A longer sequence between the first candidate sequence and the second candidate sequence is determined as a risk calling sequence.

7. The method according to claim 5, wherein the code unit call sequence specifically includes a first call sequence and a second call sequence; and the step of extracting a risk call sequence from the code unit call sequence according to the second type of risk instruction specifically includes: According to the second-class risk instruction, a third candidate sequence is intercepted from the first call sequence; the first code unit in the third candidate sequence includes the second-class risk instruction; the last code unit in the third candidate sequence includes the first-class risk instruction; According to the second risk instruction, a fourth candidate sequence is intercepted from the second call sequence; the first code unit in the fourth candidate sequence includes the second risk instruction; the last code unit in the fourth candidate sequence includes the first risk instruction; determining whether the third candidate sequence is a subsequence of the fourth candidate sequence, and obtaining a subsequence determination result; If the subsequence determination result indicates that the third candidate sequence is a subsequence of the fourth candidate sequence, only the fourth candidate sequence among the third candidate sequence and the fourth candidate sequence is determined as the risk calling sequence.

8. The method according to claim 1, wherein generating, for the risk call sequence, session prompt information for input into the big model, specifically comprises: For the risk call sequence, generating a prompt information sequence for input into the big model; The order of each prompt information in the prompt information sequence is consistent with the order of each code unit in the risk call sequence; The step of inputting the session prompt information into the large model to obtain the vulnerability analysis result of the program to be analyzed output by the large model specifically includes: Each prompt information in the prompt information sequence is input into the large model in sequence order to obtain the vulnerability analysis result output by the large model.

9. The method according to claim 8, wherein generating a prompt information sequence for inputting into a large model for the risk call sequence specifically comprises: Get the preset prompt information template; The prompt information template includes a start prompt template, a middle prompt template and an end prompt information; Using the start prompt template, generating start prompt information for the first code unit in the risk call sequence; Using the intermediate prompt template, respectively generate intermediate prompt information for other code units in the risk call sequence except the first code unit; The step of inputting each prompt information in the prompt information sequence into the large model in sequence order to obtain the vulnerability analysis result output by the large model specifically includes: The starting prompt information, the middle prompt information and the ending prompt information are sequentially input into the large model to obtain the vulnerability analysis result output by the large model.

10. The method according to claim 9, wherein the step of using the start prompt template to generate start prompt information for the first code unit in the risk call sequence comprises: Filling the second-type risk instruction contained in the first code unit, the input parameter of the second-type risk instruction and the code of the first code unit into the starting prompt template to obtain starting prompt information; The initial prompt information is used to instruct the large model to use the second-type risk instructions as a pollution source and mark the input parameters of the second-type risk instructions as pollution labels to analyze the program vulnerabilities of the first code unit.

11. The method according to claim 9, wherein the step of using the intermediate prompt template to generate intermediate prompt information for each of the code units other than the first code unit in the risk call sequence comprises: For a target code unit in other code units except the first code unit in the risk call sequence, fill the code of the target code unit into the intermediate prompt template to obtain target intermediate prompt information corresponding to the target code unit; The target intermediate prompt information is used to instruct the large model to continue analyzing the program vulnerabilities of the target code unit based on the analysis result of the previous step.

12. The method according to claim 9, wherein the starting prompt information, the intermediate prompt information, and the ending prompt information are sequentially input into the large model to obtain the vulnerability analysis result output by the large model, specifically comprising: Inputting the initial prompt information into the large model to obtain initial feedback information output by the large model; After receiving the initial feedback information, each of the intermediate prompt information is sequentially input into the large model to obtain intermediate feedback information output by the large model in response to each of the input intermediate prompt information; After receiving the intermediate feedback information corresponding to the last intermediate prompt information in each of the intermediate prompt information, the end prompt information is input into the large model to obtain the vulnerability analysis result for the risk call sequence output by the large model.

13. The method according to claim 1, wherein generating, for the risk call sequence, session prompt information for input into a large model comprises: For the risk call sequence, generating a prompt message for input into the big model; The step of inputting the session prompt information into the large model to obtain the vulnerability analysis result of the program to be analyzed output by the large model specifically includes: The prompt information is input into the large model to obtain the vulnerability analysis result of the program to be analyzed output by the large model.

14. The method according to any one of claims 1 to 13, wherein: The code unit includes at least one of a code line, a function or a code block.

15. A program vulnerability analysis device, comprising: A risk instruction identification module is used to identify the first type of risk instructions with execution risks in the program to be analyzed; A risk call sequence extraction module, used to extract a risk call sequence from the program to be analyzed according to the data dependency relationship of the input parameters of the first type of risk instructions in the program to be analyzed; The last code unit in the risk call sequence contains the first type of risk instruction; the latter code unit in the combination of adjacent code units in the risk call sequence is called by the previous code unit; A session prompt information generation module, used for generating session prompt information for input into the large model according to the risk call sequence; The session prompt information is used to instruct the large model to check program vulnerabilities in the risk call sequence; The vulnerability analysis module is used to input the session prompt information into the large model to obtain the vulnerability analysis result of the program to be analyzed output by the large model.

16. A program vulnerability analysis device, comprising: at least one processor; as well as, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to: Identify the first type of risk instructions with execution risks in the program to be analyzed; extracting a risk call sequence from the program to be analyzed according to the data dependency of the input parameters of the first-type risk instructions in the program to be analyzed; the last code unit in the risk call sequence contains the first-type risk instruction; the latter code unit in the combination of adjacent code units in the risk call sequence is called by the previous code unit; For the risk call sequence, generate session prompt information for input into the big model; the session prompt information is used to instruct the big model to check program vulnerabilities in the risk call sequence; The session prompt information is input into the large model to obtain a vulnerability analysis result of the program to be analyzed output by the large model.

Images