Deep learning based cross-file call vulnerability mining method

Abstract

The application discloses a cross-file calling vulnerability mining method based on deep learning, and the method comprises the following steps: 1) converting the source code of a current file to be detected into a program dependency graph; 2) traversing the graph nodes on the basis of the program dependency graph, observing the function calling relationship through the graph node information, and fusing the graph features of the current file and the called file into PDGcross features; 3) processing the PDGcross features into a feature matrix, labeling each matrix with a vulnerability label, and generating training samples; and 4) training a classification model on a dataset containing labels by using a neural network, and performing vulnerability detection and vulnerability category prediction. The method has excellent recognition rate and accuracy in detecting unknown vulnerabilities and in detecting multi-file calling vulnerabilities.

Description

Technical Field

[0001] The present invention relates to information security technology, and in particular to a cross-file call vulnerability mining method based on deep learning. Background Art

[0002] As software complexity continues to increase, vulnerability forms become more diverse, and the demand for software vulnerability detection technology continues to grow. To achieve high accuracy and low false positive rates in vulnerability detection, a wide range of deep learning methods have been explored for detecting source code vulnerabilities, aiming to automate and intelligently detect vulnerabilities. Current vulnerability detection focuses on detecting vulnerabilities within individual files. However, in real-world project development, code is large, often consisting of function calls and parameter passing between files. The detection process often overlooks the potential calling relationships between files and the vulnerabilities that may arise from such calling relationships. Vulnerabilities arising from function calls between multiple files pose a higher risk, but receive less attention and are more difficult to detect. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to provide a cross-file call vulnerability mining method based on deep learning to address the defects in the existing technology.

[0004] The technical solution adopted by the present invention to solve the technical problem is: a cross-file call vulnerability mining method based on deep learning, comprising the following steps:

[0005] 1) Convert the source code of the current file to be tested into a program dependency graph using the open source tool Sourcedg;

[0006] The program dependency graph includes a control dependency graph (CDG) and a data dependency graph (DDG).

[0007] 2) Based on the program dependency graph, we traverse the graph nodes, observe the function call relationship through the graph node information, and fuse the graph features of the current file and the called file into the PDGcross feature;

[0008] The details are as follows:

[0009] 2.1) Based on the program dependency graph, the graph nodes are traversed to determine whether there are any cross-file function call events in the current file code. If not, no action is taken. If there is a function call event, the called file is determined and the called file is classified into the code group of the current file.

[0010] 2.2) Within the code group of the current file, through data flow analysis and control flow analysis, the nodes of the called files are integrated, and edge information is added based on the data dependency and control dependency relationships between the nodes to form a new cross-file graph representation for the current file;

[0011] The edge information is: when building a code group, the node addresses of methods and method declarations in any single file are stored in a dictionary format, i.e., the dictionary name is {method name: node address}. After the call relationship is generated, the node address of the method in the called file is searched and finally stored in the format of {calling node address: called address}, which is the edge information required for graph fusion.

[0012] 3) Use the Node2Vec graph embedding algorithm to process the PDGcross features into a feature matrix, and label each matrix with a vulnerability label to generate training samples;

[0013] After obtaining the feature matrix through graph embedding based on the PDGcross feature, when only distinguishing whether there is a vulnerability or not, corresponding labels can be added to the feature matrix corresponding to the file according to whether the file contains a vulnerability, 1 for a vulnerability and 0 for no vulnerability; when vulnerabilities need to be classified, corresponding labels can be added to the feature matrix corresponding to the file according to the type of vulnerability contained in the file.

[0014] 4) Use neural networks to train classification models on labeled datasets to perform vulnerability detection and vulnerability category prediction.

[0015] According to the above scheme, step 1) also includes the step of processing the source code dataset of the current file, and the processing includes cleaning, integrating, and reducing the dataset; then parsing the software program dataset into a program dependency graph to facilitate subsequent model training.

[0016] According to the above scheme, in step 1), when Sourcedg generates a program dependency graph (PDG) from JAVA source code, the nodes and edges of the program dependency graph are divided into multiple types, and the graph is drawn based on the relationships between different types, and nodes and edges are selectively retained;

[0017] Among them, the types of retained nodes include class declarations, input and output of actual parameters, input and output of formal parameters, method entries and assignments; the relationships of retained edges are actual control edges represented by solid edges and non-actual control edges represented by dotted edges.

[0018] The beneficial effects produced by the present invention are:

[0019] This method detects vulnerabilities arising from calls between multiple files. It determines the scope of the files being called and integrates multiple files using the program dependency graph, a graph representation technique. It employs an LSTM neural network and batch normalization to learn and train a corresponding vulnerability classification model. Experiments achieved 91% precision and 90% recall on a small dataset of three vulnerabilities: CWE15, CWE89, and CWE90. This method outperforms existing tools in detecting vulnerabilities in multiple file calls. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The present invention will be further described below with reference to the accompanying drawings and embodiments, in which:

[0021] Figure 1 is a flow chart of a method according to an embodiment of the present invention;

[0022] Figure 2 This is an example diagram of calling vulnerability code according to an embodiment of the present invention. DETAILED DESCRIPTION

[0023] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0024] like Figure 1 As shown in FIG, a cross-file call vulnerability mining method based on deep learning includes the following steps:

[0025] 1) Convert the source code of the current file to be tested into a program dependency graph using the open source tool Sourcedg;

[0026] The program dependency graph includes a control dependency graph (CDG) and a data dependency graph (DDG).

[0027] 2) Based on the program dependency graph, we traverse the graph nodes, observe the function call relationship through the graph node information, and fuse the graph features of the current file and the called file into the PDGcross feature;

[0028] The details are as follows:

[0029] 2.1) Based on the program dependency graph, the graph nodes are traversed to determine whether there are any cross-file function call events in the current file code. If not, no action is taken. If there is a function call event, the called file is determined and the called file is classified into the code group of the current file.

[0030] 2.2) Within the code group of the current file, through data flow analysis and control flow analysis, the nodes of the called files are integrated, and edge information is added based on the data dependency and control dependency relationships between the nodes to form a new cross-file graph representation for the current file;

[0031] The edge information is: when building a code group, the node addresses of methods and method declarations in any single file are stored in a dictionary format, i.e., the dictionary name is {method name: node address}. After the call relationship is generated, the node address of the method in the called file is searched and finally stored in the format of {calling node address: called address}, which is the edge information required for graph fusion.

[0032] For cross-file function calls, Sourcedg cannot discover the relationship between files and functions. Relying solely on PDG's characterization method to detect vulnerabilities caused by multi-file function calls is inefficient.

[0033] by Figure 2 Taking the code shown as an example, source file A calls source file BC. There is no vulnerability in the ABC source file when it is detected individually, but because A calls BC, a relatively typical SQL injection vulnerability statement is formed in A after the parameter is passed. In common vulnerability detection methods, detection is generally performed at the file granularity, that is, ABC is detected separately. The data flow and control flow generated by the call statement in A will not be paid too much attention, and it is only detected as an ordinary statement. For a single file, that is, the code vulnerability caused by the call parameter passing between files such as ABC is ignored to a certain extent, and may become a weak point for vulnerability attacks. Therefore, the main research purpose of this application is to capture the calling relationship between the ABC code blocks, and further perform vulnerability detection by observing the data flow and control flow generated by the calling relationship.

[0034] This application traverses the nodes based on PDG to determine whether the current file calls other files. If there is a call, the called file is divided into the code group of the current file and stored in a sequence. In the process of building the code group, the node addresses of the methods and declared methods in any single file are stored in the form of a dictionary, that is, the dictionary name {method name: node address}. After the calling relationship is generated, the node address of the method in the called file is searched, and finally stored in the format of {calling node address: called address}, which is the edge information that needs to be added in the graph fusion. When a method is called repeatedly in multiple files, it is not necessary to repeatedly add the method-related nodes. It is only necessary to add the corresponding edges to express the calling relationship between them.

[0035] 3) Use the Node2Vec graph embedding algorithm to process the PDGcross features into a feature matrix, and label each matrix with a vulnerability label to generate training samples;

[0036] After obtaining the feature matrix through graph embedding based on the PDGcross feature, when only distinguishing whether there is a vulnerability or not, corresponding labels can be added to the feature matrix corresponding to the file according to whether the file contains a vulnerability, 1 for a vulnerability and 0 for no vulnerability; when vulnerabilities need to be classified, corresponding labels can be added to the feature matrix corresponding to the file according to the type of vulnerability contained in the file.

[0037] On the basis of PDGcross graph representation, this application uses a graph embedding algorithm to represent the graph as a low-dimensional, real-valued, dense vector form, to express the information in the graph in a numerical way, and to provide it for direct use by the learning model. The graph embedding methods are mainly divided into matrix decomposition, random walk and deep learning. The classic vertex embedding algorithms based on random walk technology include DeepWalk, Node2Vec, SDNE, etc. Since the Node2Vec algorithm improves the random walk generation method based on DeepWalk, it uses a biased random walk method to obtain the neighbor sequence of vertices, so that the generated random walk can reflect the characteristics of depth-first and breadth-first sampling. Then, word2vec is used to learn the embedding vector of the vertex, and finally a 45*64 feature matrix is ​​obtained. Therefore, the Node2Vec graph embedding algorithm is selected to process the PDGcross features into a feature matrix, and a vulnerability label is attached to each matrix to generate training samples.

[0038] 4) Use neural networks to train classification models on labeled datasets to perform vulnerability detection and vulnerability category prediction. Specific embodiment:

[0040] In the experiment of the embodiment of the present application, the model is first trained with the CWE89 vulnerability. The negative sample of the training set of the model selects the data set in the CWE89 category of the Juliet data set, which is a single file that constitutes a vulnerability, and contains 352 samples; the positive sample randomly selects 350 samples without vulnerabilities in the benchmark data set. The feature matrix label of the file with a vulnerability is 1, and that of the file without a vulnerability is 0. 90% of the data set is divided into a training set and 10% is divided into a test set. Based on the LSTM neural network, batch normalization is performed for normalization, and the learning rate is adaptively adjusted to obtain the optimal model quickly and accurately. The learning effect of the final model is very good, and the precision and recall rates on the test set have good performance. The accuracy rate can reach 100% at the best. On the other hand, it can also be proved that graph representation has a good effect in model detection.

[0041] Experimental results and analysis

[0042] To verify the effectiveness of the feature extraction method proposed in this application, a comparative experiment was conducted with the original PDG graph representation and the results of existing open source tool detection. The datasets used in this example are from the Juliet test dataset (JAVA language version) in the NIST reference dataset SARD and the dataset from the OWASP Benchmark project under the OWASP organization. The Juliet dataset contains hundreds of CWE-related vulnerability codes, and the Benchmark dataset contains 11 types of vulnerabilities and non-vulnerability data. This example selected three subsets of the Juliet dataset and the Benchmark dataset as the experimental data source.

[0043] 4.1) Dataset

[0044] In the experiment of this embodiment, three types of vulnerability codes, CWE15 (External_Control_of_System_or_Configuration_Setting), CWE89 (SQL_Injection), and CWE 90 (LDAP_Injection), were selected from the Juliet dataset, and 680 vulnerability-free files were randomly selected from the benchmark dataset.

[0045] Table 1 Dataset composition

[0046]

[0047] In the Juliet dataset, files named "****a.java" and "****b.java" are grouped together. The entry file calls other files, creating a vulnerability and giving them a vulnerability label. This group is called a multi-file example. In a multi-file example in the Juliet dataset, the file named "****a.java" is the entry point for the group and is therefore called the entry file.

[0048] This example further subdivides the entry files of Juliet's multi-file examples into two categories: AGS and G2BS. The AGS category refers to files within the entire set of examples that are vulnerability-free but may have vulnerabilities due to subsequent calls. The G2BS category refers to files within the entry file that are vulnerability-free but may have vulnerabilities in the called files. This example's experiments focus on vulnerability detection in the AGS dataset; data from the G2BS category can be used as a security risk indicator. Using the CWE89 multi-file example as an example, the data distribution is shown in Table 2.

[0049] Table 2 Composition of multi-file samples

[0050]

[0051] After manual inspection, it can be verified that this type of multi-file sample does contain the corresponding vulnerability. However, after scanning with third-party detection tools Fortify and CodeSec, it was found that this type of vulnerability was not found when scanning this type of code in the detection tools. Therefore, cross-file vulnerability detection is very necessary.

[0052] In the experiment of this embodiment, precision, recall and F1 value were selected as the measurement indicators of the results.

[0053] First, we trained a binary classification model using CWE89 vulnerability data and benchmark vulnerability-free data. After training the binary classification model for CWE89 vulnerabilities, we extracted 119 entry files for AGS-classified instances and 92 entry files for G2BS-classified instances from the CWE89 dataset, along with single-file instances, as a test set for vulnerability classification. During the experiment, we used the Fortify detection tool in the feature extraction phase, comparing it with PDG and PDGcross representations. The results are shown in Table 3.

[0054] Table 3 Model detection results

[0055]

[0056] Experiments show that the Fortify and PDG features currently only have good effects on single-file vulnerabilities, but have a high false negative rate in the detection of samples of combined vulnerabilities generated by multiple files. The features proposed by the present invention have relatively good effects in detecting single-file vulnerabilities, situations where vulnerabilities are generated due to calls to non-vulnerable files (AGS class), and warning of the risk of a non-vulnerable file calling a vulnerable file (G2BS class). Therefore, this embodiment further added two types of vulnerabilities, CWE15 and CWE90, to the experiment, trained a four-classification model, and performed multi-file sample detection, achieving a precision rate of 91% and a recall rate of 90%, which is better than the existing open source tool detection method. The results are shown in Table 4.

[0057] Table 4. Detection results of four-classification model

[0058]

[0059] Different types of software vulnerabilities have different vulnerability signatures. To improve model recognition accuracy, multiple single models are used to learn the signatures of different vulnerability types. For each vulnerability type, different deep neural networks are used to learn its signatures, identifying the binary classification model with the best detection performance. Multiple vulnerability detection models are then integrated to create a multi-model architecture.

[0060] It should be understood that those skilled in the art can make improvements or changes based on the above description, and all such improvements and changes should fall within the scope of protection of the appended claims of the present invention.

Claims

1. A cross-file call vulnerability mining method based on deep learning, characterized in that: The following steps are involved: 1) Convert the source code of the current file to be detected into a program dependency graph; The program dependency graph includes a control dependency graph and a data dependency graph; 2) Based on the program dependency graph, we traverse the graph nodes, observe the function call relationship through the graph node information, and fuse the graph features of the current file and the called file into the PDGcross feature; The details are as follows: 2.1) Based on the program dependency graph, the graph nodes are traversed to determine whether there are any cross-file function call events in the current file code. If not, no action is taken. If there is a function call event, the called file is determined and the called file is classified into the code group of the current file. 2.2) Within the code group of the current file, through data flow analysis and control flow analysis, the nodes of the called files are integrated, and edge information is added based on the data dependency and control dependency relationships between the nodes to form a new cross-file graph representation for the current file; The edge information is: when building a code group, the node addresses of methods and method declarations in any single file are stored in a dictionary format, i.e., the dictionary name is {method name: node address}. After the call relationship is generated, the node address of the method in the called file is searched and finally stored in the format of {calling node address: called address}, which is the edge information required for graph fusion. 3) Process the PDGcross features into feature matrices, label each matrix with a vulnerability label, and generate training samples; The vulnerability label adds a corresponding label to the feature matrix corresponding to the file according to whether the file contains a vulnerability, 1 means there is a vulnerability and 0 means there is no vulnerability; 4) Use neural networks to train classification models on labeled datasets to perform vulnerability detection and vulnerability category prediction.

2. The cross-file call vulnerability mining method based on deep learning according to claim 1 is characterized in that: The step 1) also includes a step of processing the source code dataset of the current file, wherein the processing includes cleaning, integrating, and reducing the dataset; and then parsing the software program dataset into a program dependency graph to facilitate subsequent model training.

3. The cross-file call vulnerability mining method based on deep learning according to claim 1 is characterized in that: In the step 1), when Sourcedg generates a program dependency graph using JAVA source code, the nodes and edges of the program dependency graph are divided into multiple types, the graph is drawn based on the relationships between different types, and nodes and edges are selectively retained; Among them, the types of retained nodes include class declarations, input and output of actual parameters, input and output of formal parameters, method entries and assignments; the relationships of retained edges are actual control edges represented by solid edges and non-actual control edges represented by dotted edges.

4. The cross-file call vulnerability mining method based on deep learning according to claim 1 is characterized in that: In step 3), the Node2Vec graph embedding algorithm is used to process the PDGcross features into a feature matrix.

Images