Incremental security code review method and system based on code change history

Abstract

The application belongs to the technical field of data analysis, and discloses an incremental security code review method and system based on code change history, which comprises the following steps: determining a change influence subgraph in a pre-established code dependency graph according to a changed code entity; extracting path security constraint feature sequences of each dependency path based on the code before and after the change respectively; inputting the feature sequences before and after the change into a constraint sufficiency evaluation model to obtain constraint completeness scores, and calculating a difference value to obtain a constraint attenuation value; calibrating the constraint attenuation value by using a path mode partition structure based on the path feature representation generated by the model to obtain a calibrated constraint attenuation value; and summarizing the calibrated constraint attenuation values of each dependency path to obtain a change risk score of the code entity and outputting the same. The application tracks the security influence range of the change by means of dependency relationship propagation, avoids omission of the weakening effect of cross-entity security constraints, and realizes differentiated reliability discrimination of the evaluation results by means of partition calibration.

Description

Technical Field

[0001] The present invention relates to the field of data analysis technology, and more specifically, to an incremental security code review method and system based on code change history. Background Art

[0002] With the continuous growth of the scale of software systems and the acceleration of iteration frequency, the risk of security vulnerabilities introduced by code changes has become increasingly prominent, and security code review has become a key quality assurance link in the software development process. Since the cost of manually reviewing each code change one by one is unaffordable, automated security code review methods have been widely researched and applied.

[0003] Existing automated security code review methods mainly include rule-based static analysis methods and model-based vulnerability detection methods. The rule-based static analysis method identifies potential security problems by matching code with predefined vulnerability patterns (such as SQL injection patterns, buffer overflow patterns, etc.). The model-based vulnerability detection method uses a machine learning or deep learning model trained on historical vulnerability data to predict vulnerabilities in code fragments. In incremental review scenarios, the above methods usually take the code fragments changed in the current submission as the analysis object, and independently perform security assessment on each changed code fragment. However, in actual software systems, code entities form a complex dependency network through calling relationships, data flow transmission and inheritance relationships, and the security impact of a code change often propagates downstream along the dependency relationship. For example, when a function modifies its parameter verification logic, all downstream functions that rely on this verification as a security constraint may be affected. Only performing isolated analysis on the changed code fragment itself cannot capture this weakening effect of cross-entity security constraints, resulting in the omission of security risks on the dependency chain. In addition, for model-based methods, when evaluating different code patterns, there are significant differences in prediction reliability—for code patterns that are less covered in the training phase, the model may give an assessment result with high confidence but is actually inaccurate, and existing methods lack the ability to discriminatively evaluate the reliability of model assessment results according to code patterns, which makes credible and incredible assessments mixed in the final review conclusion, making it difficult to effectively screen and utilize them.

[0004] In summary, how to track the security impact range of changes along code dependencies and perform reliability-discriminable assessment on security constraint changes on the impact path is an urgent problem to be solved in the field of incremental security code review. Summary of the Invention

[0005] In order to overcome the above problems of the prior art, the present invention provides an incremental security code review method and system based on code change history, which is used to solve the above problems.

[0006] This invention provides the following technical solution: Incremental security code review methods based on code change history include: Based on the changed code entities, determine the change impact subgraph in the pre-established code dependency graph; Extract each dependent path from the change impact subgraph, and extract path security constraint feature sequences based on the code before and after the change, respectively, to obtain the feature sequence before and after the change; The feature sequences before and after the change are input into the pre-trained constraint adequacy evaluation model to obtain the constraint completeness score before and after the change. The difference between the two is calculated to obtain the constraint decay value. Based on the path feature representation generated by the constraint sufficiency evaluation model for the modified feature sequence, the constraint attenuation value is calibrated using a pre-constructed path pattern partitioning structure to obtain the calibrated constraint attenuation value. For each code entity, the calibrated constraint decay values ​​of each dependency path passing through that code entity are summarized to obtain and output the change risk score of that code entity.

[0007] Preferably, the method for establishing the code dependency graph includes: Static analysis is performed on the code repository, and the code dependency graph is constructed using code entities as nodes and the dependencies between code entities as edges; the dependencies include call relationships, data flow transmission relationships, and inheritance relationships.

[0008] Preferably, the method for determining the subgraph affected by the change includes: Starting with each changed code entity, a finite-depth propagation traversal is performed along the dependency edges in the code dependency graph. Collect all nodes passed through during the propagation process and the edges between them into a subgraph of change effects.

[0009] Preferably, the path safety constraint feature sequence is formed by organizing the data flow features, constraint operation features, and change disturbance features of each code entity on the change impact subgraph in the path order; The data flow characteristics include the source type of the input data received by the code entity and the destination type of the output data; the source type includes external input, internal transmission, and constants; the destination type includes security-sensitive operations, normal operations, and external outputs; The constraint operation features include the type of constraint operation present in the code entity and the positional relationship of the constraint operation relative to the data usage point; the type of constraint operation includes at least one of input validation, type checking, range restriction, encoding conversion, and permission verification; the positional relationship includes pre-position, post-position, and missing; The change disturbance characteristics include whether the code entity has changed in this code commit, and the structure type of the change when it occurs; the structure type includes parameter changes, control flow changes, data flow changes, and constraint changes.

[0010] Preferably, the training method for the constraint sufficiency assessment model includes: Retrieve vulnerability records from the known vulnerability database, trace back the dependency path of each vulnerability record in the code dependency graph, extract the path security constraint feature sequence of the dependency path, and mark it as a sample with insufficient constraints; Extract dependency paths from confirmed secure code versions, extract the corresponding path security constraint feature sequences, and label them as sufficiently constrained samples. Based on the insufficiently constrained samples and the sufficiently constrained samples, the constraint sufficiency evaluation model is trained with constraint sufficiency as the classification objective; The constraint completeness score is the predicted probability value of the constraint sufficiency assessment model for the input path safety constraint feature sequence belonging to the constraint sufficiency category.

[0011] Preferably, the method for constructing the path pattern partitioning structure includes: The path feature representations generated when the constraint adequacy assessment model infers from the training data are collected, and the path feature representations are clustered using a Gaussian mixture model to obtain multiple path pattern partitions. Each path pattern partition records the mean vector, covariance matrix, mixture weights, and the historical evaluation accuracy of the constraint adequacy assessment model in that partition. The multiple path pattern partitions constitute a path pattern partition structure.

[0012] Preferably, the step of calibrating the constraint attenuation value using a pre-constructed path pattern partitioning structure to obtain the calibrated constraint attenuation value includes: Based on the path feature representation and the mean vector and covariance matrix of each path pattern partition, the posterior probability of the path feature representation belonging to each path pattern partition is calculated as the partition assignment probability. The log-likelihood value of the path feature representation under the Gaussian mixture model is calculated, and the log-likelihood value is mapped to the numerical range of 0 to 1 through a mapping function to obtain the in-distribution coefficient; Using the partition attribution probability as a weight, the historical evaluation accuracy of each path pattern partition is weighted and summed to obtain the expected accuracy. The first component is obtained by multiplying the in-distribution coefficient, the expected accuracy, and the constraint attenuation value. The second component is obtained by multiplying the difference between 1 and the in-distribution coefficient and the preset conservative default attenuation value. The first component and the second component are added together to obtain the calibrated constraint attenuation value.

[0013] Preferably, the summary of the calibrated constraint decay values ​​of each dependency path of the code entity to obtain the change risk score of the code entity and output it includes: For each code entity, the corresponding calibrated constraint decay values ​​are weighted and summed using the path depth of each dependent path passing through the code entity as the weight, to obtain and output the change risk score of the code entity.

[0014] This invention also provides an incremental security code review system based on code change history, used to implement an incremental security code review method based on code change history, including: The change impact analysis module is used to determine the change impact subgraph in the pre-established code dependency graph based on the changed code entities; The constraint feature extraction module is used to extract each dependent path in the change impact subgraph, and extract path safety constraint feature sequences based on the code before and after the change, respectively, to obtain the feature sequence before and the feature sequence after the change; The constraint decay assessment module is used to input the feature sequence before the change and the feature sequence after the change into the pre-trained constraint sufficiency assessment model, respectively, to obtain the constraint completeness score before the change and the constraint completeness score after the change, and calculate the difference between the two to obtain the constraint decay value. The attenuation calibration module is used to calibrate the constraint attenuation value based on the path feature representation generated by the constraint adequacy evaluation model for the modified feature sequence, using a pre-built path pattern partitioning structure, to obtain the calibrated constraint attenuation value. The risk score aggregation module is used to aggregate the calibrated constraint decay values ​​of each dependency path passing through the code entity for each code entity, obtain the change risk score of the code entity, and output it.

[0015] This invention provides an incremental security code review method and system based on code change history, which has the following beneficial effects: This invention constructs a code dependency graph and determines the subgraph of changes' impact by propagating along dependencies from the changed code entities. This expands the scope of security impact analysis from the changed code itself to related code entities in the dependency chain. In this way, when a change to a code entity weakens the security constraints on its downstream dependency path, even if the downstream code entity itself has not changed, the security impact can be captured through constraint decay analysis on the dependency path. This avoids the omission of cross-entity security constraint weakening effects when existing methods only perform isolated analysis on changed code fragments, and improves the coverage of indirect security risks caused by changes in incremental security code review.

[0016] This invention calibrates the evaluation results of the constraint adequacy assessment model by partitioning them using a path pattern partitioning structure. It obtains the expected accuracy based on the probability weighting of the path feature representation within each path pattern partition, and combines this with in-distribution coefficients to differentiate the reliability of the model's evaluation of different path patterns. This ensures that the model's evaluation results on familiar path patterns are fully trusted, while for unfamiliar path patterns, it automatically regresses to a conservative default decay value. This achieves differentiated reliability screening of model evaluation results according to path patterns, avoiding the problem in existing methods where reliable and unreliable evaluations are mixed and difficult to distinguish effectively, thus improving the reliability of the final output change risk score. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating the incremental security code review method based on code change history of the present invention. Figure 2 This is a schematic diagram of the modules of the incremental security code review system based on code change history of the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] Example 1

[0020] Please see Figure 1 In this embodiment, the incremental security code review method based on code change history includes: Step S1: Based on the changed code entities, determine the change impact subgraph in the pre-established code dependency graph; In this embodiment, when the code repository receives a code commit, it identifies the code entities that have changed in this commit through code version difference analysis. The code entities include functions, classes, modules, etc.

[0021] The methods for establishing the code dependency graph include: Static analysis is performed on the code repository, and the code dependency graph is constructed using code entities as nodes and the dependencies between code entities as edges; the dependencies include call relationships, data flow transmission relationships, and inheritance relationships.

[0022] It should be noted that the code dependency graph is pre-built during the initial system deployment and incrementally updated after each code commit to maintain consistency with the code repository. A call relationship refers to one code entity calling another code entity during its execution; a data flow relationship refers to one code entity's output data serving as input data for another code entity; and an inheritance relationship refers to one class inheriting the attributes and methods of another class.

[0023] The method for determining the subgraph of changes affecting the subgraph includes: Starting with each changed code entity, a finite-depth propagation traversal is performed along the dependency edges in the code dependency graph. Collect all nodes passed through during the propagation process and the edges between them into a subgraph of change effects.

[0024] In this embodiment, the upper limit of the propagation traversal depth can be set to 3 to 5 layers to achieve a balance between covering a sufficient range of influence and controlling computational overhead. For example, when function A changes, starting from function A, propagation proceeds along the dependency edges to find functions B and C that directly depend on function A, and then finds function D that depends on function B. Functions A, B, C, and D, and the dependency edges between them, are collected into a change impact subgraph.

[0025] Step S2: Extract each dependent path in the change impact subgraph, and extract the path security constraint feature sequence based on the code before and after the change, respectively, to obtain the feature sequence before and after the change; In this embodiment, dependency paths from the starting node to each reachable node are extracted from the change impact subgraph, forming a set of dependency paths to be analyzed. The dependency path extraction employs a depth-first traversal approach, starting from each changed code entity and traversing downstream along the dependency edges, recording the sequence of nodes visited during the traversal as dependency paths. Visited nodes are marked during the traversal to avoid repeated traversals caused by loops. When multiple different dependency paths exist between the same pair of starting and ending nodes, each path is included as an independent dependency path in the set to be analyzed.

[0026] For each dependency path, traverse each code entity on the path, extract the features of each code entity, and organize them into a path security constraint feature sequence according to the path order.

[0027] The path safety constraint feature sequence is composed of the data flow features, constraint operation features, and change disturbance features of each code entity on the change impact subgraph, organized in path order. The data flow characteristics include the source type of the input data received by the code entity and the destination type of the output data; the source type includes external input, internal transmission, and constants; the destination type includes security-sensitive operations, normal operations, and external outputs; The constraint operation features include the type of constraint operation present in the code entity and the positional relationship of the constraint operation relative to the data usage point; the type of constraint operation includes at least one of input validation, type checking, range restriction, encoding conversion, and permission verification; the positional relationship includes pre-position, post-position, and missing; The change disturbance characteristics include whether the code entity has changed in this code commit, and the structure type of the change when it occurs; the structure type includes parameter changes, control flow changes, data flow changes, and constraint changes.

[0028] It should be noted that data flow feature extraction is achieved through static data flow analysis, tracing the definition and usage relationships of variables in code entities to determine the source type of input data and the destination type of output data. External input refers to data from outside the system boundary, including network request parameters, user interface input, external file reading, and environment variable acquisition; internal transmission refers to return values ​​or member variables from other code entities; constants refer to hard-coded literal values. Security-sensitive operations in the destination type are identified by matching a predefined list of sensitive operations, including database query operations, file system read / write operations, command line execution operations, network request sending operations, and authentication operations; ordinary operations refer to internal calculations or logical processing that do not involve security-sensitive resources; external output refers to data returned outside the system boundary, including network response output, log writing, and message sending.

[0029] Constraint operation features are extracted through abstract syntax tree analysis of code entities to identify constraint operations such as conditional statements, type conversions, and regular expression matching. Data usage points refer to the locations within a code entity where data flows into security-sensitive operations. Determining positional relationships is achieved by analyzing the control flow graph of the code entity: if a constraint operation is located on the predecessor node of all reachable paths from the data usage point in the control flow graph, the positional relationship is considered "preceding"; if the constraint operation is located on the successor node of the data usage point, the positional relationship is considered "following"; if there are no constraint operations related to this data flow in the code entity, the positional relationship is considered "missing".

[0030] Change disturbance characteristics are obtained by comparing the differences in the abstract syntax tree of the code entities before and after the change. Parameter changes refer to changes in the number, type, or default value of parameters in the function signature; control flow changes refer to the addition, deletion, or modification of conditional branch statements, loop statements, or exception handling statements; data flow changes refer to the addition, deletion, or modification of variable assignment statements, data transfer statements, or return value statements; constraint changes refer to the modification of conditional expressions, addition, or deletion of constraint operations such as input validation, type checking, and range limiting. When a change involves multiple structure types simultaneously, all structure types are recorded in the change disturbance characteristics.

[0031] For categorical fields in each feature, one-hot encoding is used to convert them into numerical vectors. For example, the source type includes three values: external input, internal transmission, and constant, which are encoded as three-dimensional one-hot vectors. The one-hot vectors of each field of each code entity are concatenated to form the feature vector of that code entity. The feature vectors of each code entity on the path are arranged sequentially according to the order of the dependency path to form the path safety constraint feature sequence. For example, for a dependency path containing code entities A to B to C, its path safety constraint feature sequence is [feature vector A, feature vector B, feature vector C].

[0032] Furthermore, for the same dependency path, the above feature extraction process is performed using both the pre-change and post-change versions of the code to obtain the pre-change and post-change feature sequences. For code entities on the path that have not changed, their data flow features and constraint operation features are the same in both versions, and the change disturbance features are marked as unchanged.

[0033] Step S3: Input the feature sequence before the change and the feature sequence after the change into the pre-trained constraint sufficiency evaluation model to obtain the constraint completeness score before the change and the constraint completeness score after the change. Calculate the difference between the two to obtain the constraint decay value. In this embodiment, the constraint sufficiency assessment model is a pre-trained sequence classification model, which can be implemented using a sequence classification model based on a recurrent neural network or a Transformer architecture. The constraint sufficiency assessment model receives a sequence of path safety constraint features as input, encodes the feature vectors at each position in the sequence to generate an overall path feature representation of the path, and then outputs the predicted probability of belonging to the two categories of sufficient and insufficient constraints through a classification layer.

[0034] The training method for the constraint adequacy assessment model includes: Retrieve vulnerability records from the known vulnerability database, trace back the dependency path of each vulnerability record in the code dependency graph, extract the path security constraint feature sequence of the dependency path, and mark it as a sample with insufficient constraints; Extract dependency paths from confirmed secure code versions, extract the corresponding path security constraint feature sequences, and label them as sufficiently constrained samples. Based on the insufficiently constrained samples and the sufficiently constrained samples, the constraint sufficiency evaluation model is trained with constraint sufficiency as the classification objective; The constraint completeness score is the predicted probability value of the constraint sufficiency assessment model for the input path safety constraint feature sequence belonging to the constraint sufficiency category.

[0035] It should be noted that known vulnerability databases can utilize publicly available vulnerability datasets such as CNVD (China National Information Security Vulnerability Sharing Platform) and CNNVD (China National Information Security Vulnerability Database) to obtain the code location information corresponding to the vulnerability, and then trace back the dependency path of that location in the code dependency graph. A confirmed secure code version refers to a code version that has undergone complete security testing and manual review and has not been found to contain vulnerabilities.

[0036] Understandably, the constraint completeness score is the predicted probability value output by the model that belongs to the category of sufficient constraints, ranging from 0 to 1. The closer the value is to 1, the more sufficient the safety constraints on the path; the closer the value is to 0, the less sufficient the safety constraints. Subtracting the constraint completeness score after the change from the constraint completeness score before the change yields the constraint decay value. A positive constraint decay value indicates that the change weakens the safety constraints of the dependent path; a negative constraint decay value indicates that the change strengthens the safety constraints of the dependent path; and a constraint decay value close to zero indicates that the change has no significant impact on the safety constraints of the path.

[0037] Step S4: Based on the path feature representation generated by the constraint sufficiency evaluation model for the changed feature sequence, the constraint attenuation value is calibrated using a pre-constructed path pattern partitioning structure to obtain the calibrated constraint attenuation value. In this embodiment, the path feature is represented as the feature vector output by the penultimate layer of the constraint adequacy assessment model when processing the changed feature sequence. This feature vector encodes the safety constraint mode information of the path.

[0038] The method for constructing the path pattern partitioning structure includes: The path feature representations generated when the constraint adequacy assessment model infers from the training data are collected, and the path feature representations are clustered using a Gaussian mixture model to obtain multiple path pattern partitions. Each path pattern partition records the mean vector, covariance matrix, mixture weights, and the historical evaluation accuracy of the constraint adequacy assessment model in that partition. The multiple path pattern partitions constitute a path pattern partition structure.

[0039] It should be noted that the number of clusters in the Gaussian mixture model can be selected using the Bayesian Information Criterion (BIC). Each path pattern partition represents a set of dependency paths with similar constraint characteristics. For example, a partition might cluster path patterns that use external input as the data source and, after input validation, flow to the database. Historical evaluation accuracy is obtained by statistically analyzing the proportion of training samples falling into that partition that were correctly predicted by the constraint adequacy evaluation model out of the total number of samples in that partition.

[0040] The constraint attenuation value is calibrated using a pre-built path pattern partitioning structure, resulting in calibrated constraint attenuation values ​​including: Based on the path feature representation and the mean vector and covariance matrix of each path pattern partition, the posterior probability of the path feature representation belonging to each path pattern partition is calculated as the partition assignment probability. The log-likelihood value of the path feature representation under the Gaussian mixture model is calculated, and the log-likelihood value is mapped to the numerical range of 0 to 1 through a mapping function to obtain the in-distribution coefficient; Using the partition attribution probability as a weight, the historical evaluation accuracy of each path pattern partition is weighted and summed to obtain the expected accuracy. The first component is obtained by multiplying the in-distribution coefficient, the expected accuracy, and the constraint attenuation value. The second component is obtained by multiplying the difference between 1 and the in-distribution coefficient and the preset conservative default attenuation value. The first component and the second component are added together to obtain the calibrated constraint attenuation value.

[0041] It should be noted that the calculation principle of partition assignment probability is as follows: Substitute the path feature representation into the Gaussian probability density function of each path pattern partition to obtain the probability density value of that feature representation under each partition. Then, normalize it according to the mixture weights of each partition to obtain the posterior probability of the path feature representation belonging to each partition. The higher the assignment probability, the more similar the constraint feature pattern of the path is to the feature pattern of historical paths in that partition. The mapping function can be implemented using the sigmoid function, which maps the log-likelihood value to a numerical range of 0 to 1 to obtain the in-distribution coefficient.

[0042] Understandably, the core logic of the above calibration process is as follows: when the path feature representation falls within a region familiar to the model, the coefficients within the distribution are close to 1, and the constraint decay value after calibration is mainly determined by the constraint decay value actually calculated by the model and the expected accuracy of that region; when the path feature representation falls within a region unfamiliar to the model, the coefficients within the distribution are close to 0, and the constraint decay value after calibration tends towards a conservative default decay value, that is, a conservative assumption of safety risks for path patterns not seen by the model. The conservative default decay value can be set according to the safety requirements of the actual application scenario.

[0043] Step S5: For each code entity, summarize the calibrated constraint decay values ​​of each dependency path passing through the code entity to obtain the change risk score of the code entity and output it.

[0044] In this embodiment, it should be noted that the path depth refers to the number of code entities contained in the dependency path. The design consideration for weighted summation with path depth as the weight is that the deeper the dependency path, the farther the impact of the change propagates. This long-distance propagation of security impact is more likely to be overlooked in manual review, so it is given a higher weight to increase its contribution to risk scoring.

[0045] As shown above, this embodiment determines the scope of change impact by constructing a code dependency graph and propagating along dependencies, extracts security constraint feature sequences on dependency paths, and evaluates the constraint state before and after the change using a constraint sufficiency assessment model. It then uses a path pattern partitioning structure to differentiate and calibrate the evaluation results, and finally obtains the change risk score for each code entity by weighting the sum of path depths. This method can track the security impact propagation of code changes along dependencies, identify code entities on the dependency chain whose security constraints have been weakened, and improve the coverage and reliability of incremental security code review through a partitioning calibration mechanism.

[0046] Example 2

[0047] Please see Figure 2 This invention provides an incremental security code review system based on code change history, used to implement an incremental security code review method based on code change history, including: The change impact analysis module is used to determine the change impact subgraph in the pre-established code dependency graph based on the changed code entities; The constraint feature extraction module is used to extract each dependent path in the change impact subgraph, and extract path safety constraint feature sequences based on the code before and after the change, respectively, to obtain the feature sequence before and the feature sequence after the change; The constraint decay assessment module is used to input the feature sequence before the change and the feature sequence after the change into the pre-trained constraint sufficiency assessment model, respectively, to obtain the constraint completeness score before the change and the constraint completeness score after the change, and calculate the difference between the two to obtain the constraint decay value. The attenuation calibration module is used to calibrate the constraint attenuation value based on the path feature representation generated by the constraint adequacy evaluation model for the modified feature sequence, using a pre-built path pattern partitioning structure, to obtain the calibrated constraint attenuation value. The risk score aggregation module is used to aggregate the calibrated constraint decay values ​​of each dependency path passing through the code entity for each code entity, obtain the change risk score of the code entity, and output it.

[0048] In the several embodiments provided by this invention, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only one method, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0049] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

[0050] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. An incremental security code review method based on code change history, characterized in that, include: Based on the changed code entities, determine the change impact subgraph in the pre-established code dependency graph; Extract each dependent path from the change impact subgraph, and extract path security constraint feature sequences based on the code before and after the change, respectively, to obtain the feature sequence before and after the change; The feature sequences before and after the change are input into the pre-trained constraint adequacy evaluation model to obtain the constraint completeness score before and after the change. The difference between the two is calculated to obtain the constraint decay value. Based on the path feature representation generated by the constraint sufficiency evaluation model for the modified feature sequence, the constraint attenuation value is calibrated using a pre-constructed path pattern partitioning structure to obtain the calibrated constraint attenuation value. For each code entity, the calibrated constraint decay values ​​of each dependency path passing through that code entity are summarized to obtain and output the change risk score of that code entity; The training method for the constraint adequacy assessment model includes: Retrieve vulnerability records from the known vulnerability database, trace back the dependency path of each vulnerability record in the code dependency graph, extract the path security constraint feature sequence of the dependency path, and mark it as a sample with insufficient constraints; Extract dependency paths from confirmed secure code versions, extract the corresponding path security constraint feature sequences, and label them as sufficiently constrained samples. Based on the insufficiently constrained samples and the sufficiently constrained samples, the constraint sufficiency evaluation model is trained with constraint sufficiency as the classification objective; The constraint completeness score is the predicted probability value of the constraint sufficiency assessment model for the input path safety constraint feature sequence belonging to the constraint sufficiency category. The constraint attenuation value is calibrated using a pre-built path pattern partitioning structure, resulting in calibrated constraint attenuation values ​​including: Based on the path feature representation and the mean vector and covariance matrix of each path pattern partition, the posterior probability of the path feature representation belonging to each path pattern partition is calculated as the partition assignment probability. The log-likelihood value of the path feature representation under the Gaussian mixture model is calculated, and the log-likelihood value is mapped to the numerical range of 0 to 1 through a mapping function to obtain the in-distribution coefficient; Using the partition attribution probability as a weight, the historical evaluation accuracy of each path pattern partition is weighted and summed to obtain the expected accuracy. The first component is obtained by multiplying the in-distribution coefficient, the expected accuracy, and the constraint attenuation value. The second component is obtained by multiplying the difference between 1 and the in-distribution coefficient and the preset conservative default attenuation value. The first component and the second component are added together to obtain the calibrated constraint attenuation value.

2. The incremental security code review method based on code change history according to claim 1, characterized in that, The methods for establishing the code dependency graph include: Static analysis is performed on the code repository, and the code dependency graph is constructed using code entities as nodes and the dependencies between code entities as edges; the dependencies include call relationships, data flow transmission relationships, and inheritance relationships.

3. The incremental security code review method based on code change history according to claim 2, characterized in that, The method for determining the subgraph of changes affecting the subgraph includes: Starting with each changed code entity, a finite-depth propagation traversal is performed along the dependency edges in the code dependency graph. Collect all nodes passed through during the propagation process and the edges between them into a subgraph of change effects.

4. The incremental security code review method based on code change history according to claim 3, characterized in that, The path safety constraint feature sequence is composed of the data flow features, constraint operation features, and change disturbance features of each code entity on the change impact subgraph, organized in path order. The data flow characteristics include the source type of the input data received by the code entity and the destination type of the output data; the source type includes external input, internal transmission, and constants; the destination type includes security-sensitive operations, normal operations, and external outputs; The constraint operation features include the type of constraint operation present in the code entity and the positional relationship of the constraint operation relative to the data usage point; the type of constraint operation includes at least one of input validation, type checking, range restriction, encoding conversion, and permission verification; the positional relationship includes pre-position, post-position, and missing; The change disturbance characteristics include whether the code entity has changed in this code commit, and the structural type of the change when it occurs; The structure types include parameter changes, control flow changes, data flow changes, and constraint changes.

5. The incremental security code review method based on code change history according to claim 4, characterized in that, The method for constructing the path pattern partitioning structure includes: The path feature representations generated when the constraint adequacy assessment model infers from the training data are collected, and the path feature representations are clustered using a Gaussian mixture model to obtain multiple path pattern partitions. Each path pattern partition records the mean vector, covariance matrix, mixture weights, and the historical evaluation accuracy of the constraint adequacy assessment model in that partition. The multiple path pattern partitions constitute a path pattern partition structure.

6. The incremental security code review method based on code change history according to claim 5, characterized in that, The summation of the calibrated constraint decay values ​​of each dependency path of the code entity yields a change risk score for the code entity, which is then output as follows: For each code entity, the corresponding calibrated constraint decay values ​​are weighted and summed using the path depth of each dependent path passing through the code entity as the weight, to obtain and output the change risk score of the code entity.

7. An incremental security code review system based on code change history, used to implement the incremental security code review method based on code change history as described in any one of claims 1-6, characterized in that, include: The change impact analysis module is used to determine the change impact subgraph in the pre-established code dependency graph based on the changed code entities; The constraint feature extraction module is used to extract each dependent path in the change impact subgraph, and extract path safety constraint feature sequences based on the code before and after the change, respectively, to obtain the feature sequence before and the feature sequence after the change; The constraint decay assessment module is used to input the feature sequence before the change and the feature sequence after the change into the pre-trained constraint sufficiency assessment model, respectively, to obtain the constraint completeness score before the change and the constraint completeness score after the change, and calculate the difference between the two to obtain the constraint decay value. The attenuation calibration module is used to calibrate the constraint attenuation value based on the path feature representation generated by the constraint adequacy evaluation model for the modified feature sequence, using a pre-built path pattern partitioning structure, to obtain the calibrated constraint attenuation value. The risk score aggregation module is used to aggregate the calibrated constraint decay values ​​of each dependency path passing through the code entity for each code entity, obtain the change risk score of the code entity, and output it.

Images