An incremental security code review method based on code change history and large model prediction

Abstract

This invention belongs to the field of computer technology, specifically an incremental security code review method based on code change history and large-scale model prediction. The method includes parsing code change commit records in a version control system, extracting semantic-level features of code changes based on an abstract syntax tree, and constructing a multi-dimensional feature vector containing code change scale, file path, code semantics, change type, and review history. A gradient-boosting decision tree classifier is used to predict the security relevance probability of code changes, triggering incremental large-scale model review for changes determined to be security-related. A hierarchical progressive retrieval strategy is used to obtain historical context information of code changes, constructing review prompts containing complete context and sending them to the large-scale model for security assessment. This method can compress the number of large-scale model calls, improving review efficiency and controlling review costs.

Description

Technical Field

[0001] This invention belongs to the field of computer technology, specifically an incremental security code review method based on code change history and large model prediction. Background Technology

[0002] With the continuous expansion of software development scale and the accelerating pace of iteration, code security review has become a key link in ensuring the security of software systems, and incremental security review is a core technical means to adapt to the rapid iterative development model and improve the efficiency of security management. Existing technologies typically employ code security review methods based on large models, which detect potential security vulnerabilities by performing semantic understanding and pattern recognition on the code. Conventional incremental review schemes, on the other hand, conduct independent analysis based on currently changed code snippets, enabling basic incremental code security detection.

[0003] However, such incremental review schemes fail to fully explore the contextual information and evolution patterns contained in the code change history, and lack effective modeling of historical change patterns. As a result, the large model has difficulty in accurately identifying the dependencies and security associations between the changed code and the historical code, and the review results have a high false positive rate and false negative rate. To this end, the present invention provides an incremental security code review method based on code change history and large model prediction. Summary of the Invention

[0004] In order to overcome the shortcomings of the prior art, at least one technical problem raised in the background art is solved.

[0005] The technical solution adopted by this invention to solve its technical problem is: an incremental security code review method based on code change history and large model prediction, comprising the following steps: Step 1: Perform multi-dimensional feature extraction and analysis of code change history. Receive code change commit records from the version control system, parse the list of changed files, differences in change content, and change metadata in the commit records, and extract semantic-level features of code changes based on abstract syntax tree parsing technology. These features include function signature change identifiers, key function call change identifiers, input / output boundary change identifiers, and sensitive operation change identifiers. Simultaneously, calculate change scale statistics, including the number of newly added lines of code, the number of deleted lines of code, and the number of modified lines of code, as well as their distribution ratio in the changed files. Construct a multi-dimensional feature vector of code changes from three dimensions: code type distribution, changed file path characteristics, and change operation type characteristics. The dimensional structure of this multi-dimensional feature vector is as follows: the code change scale feature dimension includes six scalar components: the number of newly added lines, the number of deleted lines, the number of modified lines, the number of newly added files, the number of deleted files, and the number of modified files. The file path feature dimension includes a security-sensitive path marker component and a changed file type distribution component; The code semantic feature dimension includes function signature change marker components and key function change marker components; The change type feature dimension includes sensitive operation change marker components and input / output boundary change marker components; The historical feature dimension includes a historical vulnerability density component and a historical risk level distribution component. This multi-dimensional feature vector serves as the standard input format for subsequent security relevance prediction models.

[0006] Step 2: Intelligent determination of the security relevance of code changes. Based on the multi-dimensional feature vector, a pre-trained security relevance classifier model is used to predict whether the current code change involves security-related logic. The security relevance classifier model is trained using the gradient boosting decision tree algorithm. The training samples are derived from code change records and their security standard results in the historical review database. The model output is the predicted probability value of whether the code change involves security-related logic. When the predicted probability value is greater than a preset high threshold, the current change is determined to involve security-related logic. When the predicted probability value is less than a preset low threshold, the current change is determined not to involve security-related logic. When the predicted probability value is between the high and low thresholds, it is marked as pending manual review. This determination result is used to decide whether to trigger the incremental large-scale model review process.

[0007] Step 3: Obtain the security-related context of the code change. If the determination result of Step 2 is that the current change involves security-related logic, retrieve historical code versions and historical change records associated with the current change from the version control system, specifically including: The system retrieves the historical version sequence of files involved in the current change, a list of related files that depend on the currently changed file, and the historical definition version of the functions or methods modified by the current change. It also retrieves past review records for the same file or function from the historical review database, including the distribution of historically discovered vulnerability types, historical risk levels, and historical remediation status. This contextual information is used to provide a complete code evolution background for subsequent large-scale model reviews, avoiding the omission of security issues caused by isolated analysis of large-scale models based solely on the current change fragments.

[0008] Step 4: Conduct incremental security code review based on the large model. When Step 2 determines that the current change involves security-related logic, construct review prompts containing code change fragments, historical code fragments, code context, and review history. Send the review prompts to the large model for security review and obtain the incremental code security assessment results output by the large model. The review prompts include a system role setting module, a code change context module, a security review requirements module, and an output format module. The system role setting module clarifies the role positioning and review capability boundaries of the large model as a security review expert. The code change context module contains the complete context information obtained in step three. The security review requirements module defines the scope of the security review, the types of vulnerabilities to focus on, and the level of review depth. The output format module specifies the structured output requirements for the review results, including risk level labels, vulnerability location information, vulnerability type descriptions, and remediation suggestions.

[0009] Step 5: Store and provide feedback learning for the review results. Write the large model security assessment results obtained in Step 4 into the historical review database, and update the code change record table, security standard result table, large model review result table, and repair confirmation status table in the historical review database. Based on the accumulated data in the historical review database, clustering analysis algorithms are used to identify recurring vulnerability patterns, establish a vulnerability knowledge graph for specific code repositories or projects, extract key security recommendations and remediation solutions from the large model review results, and generate reusable review knowledge entries. These review knowledge entries can be referenced in subsequent incremental reviews to improve the relevance and consistency of the review.

[0010] Preferably, the training data for the security relevance classifier model comes from a historical review database. The specific training process includes: extracting historical code change records and their corresponding security standard results from the historical review database as a set of positive and negative samples, where the security standard results are the judgment labels of human security experts on whether code changes involve security-related logic. Positive samples are defined as code changes involving security-related logic, and negative samples are defined as code changes not involving security-related logic. The multi-dimensional feature vector of each code change record is extracted as the model input feature. The gradient boosting decision tree algorithm is used to perform multiple rounds of iterative training on the positive and negative sample sets. The hyperparameters and feature weights of the model are adjusted by the prediction performance index on the validation set, and finally the trained security relevance classifier model is obtained.

[0011] Preferably, the threshold setting mechanism for the predicted probability value of the security relevance classifier model adopts an adaptive adjustment strategy. In the initial stage, a preset fixed threshold is used for judgment. During system operation, the threshold parameter is continuously optimized based on feedback data of actual review results. The specific adjustment rules are as follows: When a false positive occurs with a high probability of prediction but no actual security issue, the decision boundary of the high threshold is appropriately increased. When a false negative occurs with a low probability of prediction but an actual security issue, the decision boundary of the low threshold is appropriately decreased. The magnitude of the threshold adjustment is determined based on the statistical results of the false positive rate and the false negative rate. The threshold adjustment cycle is set to a global evaluation and adjustment once a week. This adaptive threshold adjustment mechanism ensures that the classifier model can adapt to the change characteristics and review requirements of different code repositories.

[0012] Preferably, the context acquisition strategy for the code change adopts a hierarchical and progressive retrieval method. The first layer retrieves the most recent N historical versions of the files involved in the current change. The second layer retrieves the historical versions of the related files identified in the first layer's retrieval results. The third layer retrieves historical changes and their retrieval results in the historical review database that have path similarity to the current change. The value of N is set to be between 5 and 10. This hierarchical and progressive retrieval method ensures the integrity of the context information while avoiding the problem of a surge in the number of large model input tokens due to an excessively large retrieval scope, ensuring that the review cost is controlled within a reasonable range.

[0013] Preferably, the large model plays the specific role of a security vulnerability detection expert in incremental security reviews, and its system prompts include the following core instructions: the large model should focus on potential security vulnerabilities introduced by code changes rather than code quality or style issues; the large model should identify whether there is a recurrence or evolution of historical vulnerabilities in combination with the historical context of code changes; the large model should identify security interface risks between modified code and unmodified code that has dependencies on it; the large model should adjust the focus of vulnerability detection according to the business type of the system to which the code belongs, focusing on data leakage risks for systems involving user data processing and injection attack risks for systems involving network communication.

[0014] The beneficial effects of this invention are as follows: The incremental security code review method described in this invention, based on code change history and large model prediction, intelligently determines the security relevance of code changes and concentrates limited review resources on changes that truly involve security logic, thereby improving the throughput of incremental security reviews and enabling limited computing resources to prioritize the review quality of high-risk changes.

[0015] By using a security-related initial screening mechanism, a large number of trivial changes that do not require in-depth review are filtered out. Only for changes that pass the security-related judgment, a complete prompt word containing historical context is constructed. The review cost exhibits a piecewise linear characteristic as the number of code changes increases, rather than the linear increase under the full review mode.

[0016] The review process incorporates complete code change context information, including the historical version sequence of changed files, changes in associated files, and vulnerability distribution patterns in historical review records. This context information enables the large model to understand the position and significance of the current change in the code evolution process, identify the evolution of the same vulnerability pattern in different versions, and, combined with the vulnerability knowledge graph accumulated in the historical review database, the large model can develop stronger sensitivity to recurring vulnerability patterns, thereby significantly reducing the false positive and false negative rates of the review results.

[0017] By building and continuously updating a historical review database, the system fully records code changes, security standard results, large model evaluation results, and remediation confirmation status generated during each review process. Based on this database, a vulnerability knowledge graph and review knowledge base are established for specific code repositories. In subsequent reviews, the large model can reference relevant entries in this knowledge base and provide more targeted security recommendations based on the specific context of the current changes. This mechanism enables the review system to gradually learn and adapt to the unique code security characteristics of the enterprise, forming a continuously improving review capability. Attached Figure Description

[0018] The invention will now be further described with reference to the accompanying drawings.

[0019] Figure 1 This is a flowchart of an incremental security code review method based on code change history and large model prediction in this invention; Figure 2 This is a complete flowchart of the incremental security review process in this invention, from code change submission to the storage of review results. Detailed Implementation

[0020] To make the technical means, creative features, objectives and effects of this invention easier to understand, the invention will be further described below in conjunction with specific embodiments.

[0021] Example 1: like Figure 1 and Figure 2 As shown, this invention provides an incremental security code review method based on code change history and large model prediction. This method achieves efficient allocation of review resources by intelligently determining the security relevance of code changes. In the daily development process of software projects, each code submission may involve multiple types of changes, some of which involve security-sensitive logic, while others are only non-security-related operations such as code formatting, adding comments, or renaming variables. This invention constructs a complete technical process to assess the security relevance of each code change and triggers in-depth large model review only for changes that truly involve security logic, thereby improving review efficiency and reducing review costs while ensuring review quality.

[0022] Step 1: Extract and analyze multi-dimensional features of code change history. This step is the starting point of incremental security code review. It is responsible for receiving code change submission records from the version control system and extracting multi-dimensional feature vectors for subsequent analysis. The specific process includes the following key steps.

[0023] Receive code change commit records from version control systems. Version control systems are the core infrastructure for software project code management, recording the time, committer, list of changed files, and specific code differences for each code commit. Common version control systems include Git, SVN, and Mercurial. Through the Webhook mechanism or scheduled synchronization mechanism provided by the version control system, code commit records are pushed or pulled to the data receiving module of the review system. The data receiving module performs preliminary parsing and standardization processing on the received raw data, extracting three core data units: a list of changed files, differences in changed content, and changed metadata. The list of changed files records all files involved in this commit in a standardized path format; the differences in changed content records the code changes of each file in a unified diff format. Change metadata includes additional information such as a unique identifier for the commit, commit timestamp, committer information, and commit message. In practical applications, the data receiving module supports standard integration with mainstream code hosting platforms such as GitHub, GitLab, and Gitee, and can obtain code change data in real time through the platform's API interface or Webhook callback mechanism.

[0024] The process of parsing the list of changed files and the differences in the content of the changes in the commit record begins by extracting all file paths involved in this commit from the commit metadata, and then distinguishing between newly added files, modified files, and deleted files based on the type of change in the file paths. For each changed file, the change scale statistics in this commit are calculated, including the number of newly added lines of code, the number of modified lines of code, and the number of deleted lines of code. The number of functions involved in the changes and their distribution within the file are also counted. The results of the change scale statistics are used as the code change scale feature dimension in subsequent feature vector construction. For parsing the differences in change content, the review system obtains complete diff information for each changed file from the version control system. This diff information follows a unified diff format or a side diff format, including the range of line numbers involved in the changes and the specific code content. The review system parses the newly added, deleted, and modified line identifiers in the diff information, extracting the content of the newly added lines, the content of the deleted lines, and the line content before and after the modifications. These parsing results will be used for subsequent abstract syntax tree analysis and semantic-level feature extraction.

[0025] Parse the change metadata in the commit record. The change metadata contains rich contextual information, which is of great reference value for assessing the security relevance of code changes. The specific parsing content includes extracting the unique identifier of the commit, which can be the Git commit hash, SVN revision number or other unique identifier corresponding to the version control system. Extract the submission timestamp information, including the submission creation time and the submitter's work time distribution characteristics; Extract the submitter's identity information and historical commit statistics, including the submitter's code change patterns and the proportion of security-related changes; Extract the commit message text and parse the task identifier, scope of impact description, and change intent description contained in the commit message; extract the branch and tag information involved in the commit, and determine whether this commit involves the main branch, release branch, or feature branch. The parsing results of the change metadata will serve as supplementary information for the multi-dimensional feature vector and will be used in the subsequent security relevance determination process.

[0026] The abstract syntax tree (AST) parsing technology is used to extract semantic features of code changes. AST is a standard form of structured code representation that can accurately describe the syntactic structure and semantic relationships of code. For each changed file, the review system constructs ASTs based on the code content before and after the change. By comparing and analyzing the two ASTs, semantic features of code changes are extracted. The semantic features that AST parsing technology can identify include the following four key features.

[0027] The first category of semantic-level features is the function signature change identifier. The function signature is the interface specification exposed by the function, and its changes may affect the caller of the function and other code that depends on the function. The review system identifies the following changes to the function signature by comparing the function definition nodes in the abstract syntax tree before and after the change: When a function signature change is detected, such as a change in the function name, the number and types of function parameters, the function return type, or the function modifier, the review system marks the change as a high-priority security-related feature. This is because changes to the function signature may lead to incompatibility with the caller's code or potential security interface risks.

[0028] The second type of semantic-level feature is the key function call change identifier. Key functions refer to function calls that involve security-sensitive operations, including but not limited to system command execution functions, network communication functions, database operation functions, file read and write functions, encryption and decryption functions, identity authentication functions, and permission check functions. The review system analyzes a predefined list of key functions and an abstract syntax tree to identify the key function calls that have been added, deleted, or modified in the changed code, and records the specific type and usage context of each key function call. When code changes involve critical function calls, the review system flags them as important security-related features because improper use of these functions is a common source of security vulnerabilities.

[0029] The third type of semantic-level feature is the input / output boundary change identifier. Input validation and output encoding are key security mechanisms to prevent injection attacks. The review system uses abstract syntax tree analysis to identify the following boundary processing changes involved in the modified code: Changes to the user input receiving point include function parameters, configuration file reading, environment variable reading, etc. Changes to input validation logic, including null value checking, type checking, format validation, range checking, etc.; changes to output encoding logic, including HTML encoding, URL encoding, JavaScript encoding, SQL escaping, etc. Changes in access to external data sources, including database queries, file reads, and network requests, as well as the identification of changes in input / output boundaries, are crucial for assessing the code's resilience against attacks.

[0030] The fourth category of semantic-level features is the sensitive operation change identifier. Sensitive operations refer to those operations involving security-sensitive data or security-sensitive processes. The review system identifies the following sensitive operation changes involved in the modified code through abstract syntax tree analysis and data flow analysis: Changes to identity authentication-related operations include login verification, password modification, and session management; changes to access control-related operations include access control checks, role assignment, and permission verification; changes to sensitive data processing-related operations include password storage, key management, personal information processing, and log recording; and changes to encryption-related operations include encryption algorithm selection, key generation, key storage, and random number generation. Identifying changes to sensitive operations helps in discovering potential security vulnerabilities.

[0031] Calculate change scale statistics, which are important indicators for assessing the scope of impact of code changes. The specific calculation includes counting the number of new lines of code added in this commit, which is obtained by counting the number of all new lines in the diff information; and counting the number of deleted lines of code in this commit, which is obtained by counting the number of all deleted lines in the diff information. The number of lines of modified code in this submission is counted, which is obtained by counting the number of lines with content changes in the diff information; The system calculates the number of newly added, deleted, and modified files submitted this time, and also calculates the distribution ratio of change scale among the changed files, including the proportion of the number of changed lines in each changed file to the total number of changed lines, the identification of files with the highest change density, and the marking of high change density files as key review targets. The calculation results of the change scale statistics will be used as input to the code change scale feature dimension of the multidimensional feature vector.

[0032] To construct a multidimensional feature vector of code changes, based on the various features extracted in the aforementioned analysis, this invention adopts a multidimensional feature vector as a unified representation of code changes. The multidimensional feature vector adopts a fixed-length floating-point array structure, with each position in the array corresponding to a predefined feature dimension. All feature values ​​fall within the numerical range of 0 to 1 after normalization. The dimensional structure of the multidimensional feature vector is organized according to the following five dimensions.

[0033] The code change scale characteristic dimension includes six scalar components: Number of lines added (normalized value); Number of lines deleted (normalized value); Number of lines modified (normalized value); Number of files added (normalized value); Number of files deleted (normalized value); and Number of files modified (normalized value).

[0034] The file path feature dimension comprises two key components: a security-sensitive path label component, which determines the security sensitivity of a changed file based on its path characteristics. Predefined high-security-sensitive paths include directories such as src / security, src / auth, src / payment, and src / encryption; medium-security-sensitive paths include directories such as src / api, src / controller, and src / service; and low-security-sensitive paths include directories such as src / test, src / docs, and src / scripts. The value of the security-sensitive path label component is determined based on the security-sensitive path category to which the changed file belongs. The change file type distribution component records the proportion of files in various programming languages ​​among the changed files. Common programming language types include Java, Python, JavaScript, TypeScript, Go, C, C++, and CSharp. Different types of programming language files have different security vulnerability characteristics and review focuses.

[0035] The code semantic feature dimension includes two key components: the function signature change marker component, which is marked as 1 when a function signature change is detected, and marked as 0 when no function signature change is detected. Function signature changes include changes in function name, parameter type, number of parameters, and return value type. The critical function change flag component is marked as 1 when a change in a critical function call is detected, and marked as 0 when no change in a critical function is detected. The definition of critical functions is based on a predefined list of critical functions, which includes identification patterns of security-sensitive functions such as system command execution functions, network communication functions, and database operation functions.

[0036] The change type feature dimension contains two key components: a sensitive operation change flag component, which is marked as 1 when a change to a sensitive operation is detected. Sensitive operations include authentication operations, access control operations, sensitive data processing operations, and encryption operations. The input / output boundary change flag component is marked as 1 when a change in the input validation logic or output encoding logic is detected.

[0037] The historical feature dimension includes two key components: the historical vulnerability density component, which is calculated based on the frequency of vulnerability discovery in the historical review of the changed file. This component is calculated by dividing the total number of security vulnerabilities discovered in the file's history by the total number of changes to the file in history, thus obtaining the average vulnerability density per change of the file. The historical risk level distribution component is calculated based on the risk level distribution of the changed document during historical reviews. This component is a multi-dimensional vector that records the number of high-risk vulnerabilities, medium-risk vulnerabilities, low-risk vulnerabilities, and warning-level issues discovered in the document's history. After normalization, it is used as the value of this component.

[0038] This multidimensional feature vector serves as the standard input format for subsequent security relevance prediction models. Its data structure and numerical range have been standardized and defined to ensure that code changes from different sources can be input into the security relevance classifier model in a unified format. The extraction process of the multidimensional feature vector covers five dimensions of code change: scale features, path features, semantic features, type features, and historical features, which can comprehensively characterize the security relevance features of code changes.

[0039] Step 2: Intelligent determination of the security relevance of code changes. Based on the multi-dimensional feature vector extracted in Step 1, this step uses a pre-trained security relevance classifier model to predict whether the current code change involves security-related logic, and determines the subsequent review process triggering strategy based on the prediction results.

[0040] The safety relevance classifier model is trained using the gradient boosting decision tree algorithm, which is an ensemble learning method. It trains multiple decision tree base learners sequentially, with each base learner focusing on fitting the cumulative prediction residuals of all previous learners. Finally, the prediction results of all base learners are weighted and summed to obtain the final prediction. The gradient boosting decision tree algorithm has advantages in processing structured feature data, and its decision tree structure can automatically perform feature selection and feature interaction learning. It exhibits good adaptability to the multidimensionality and heterogeneity of input features. The training samples for the security relevance classifier model come from the historical review database, which stores manually annotated historical code change records and their corresponding security standard results. The data table structure of the historical review database includes four core data tables: code change record table, security standard result table, large model review result table, and repair confirmation status table. The code change record table stores the multidimensional feature vectors of historical code changes and their original change data; the security standard result table stores the judgment labels of human security experts on whether the code changes involve security-related logic.

[0041] The training process of the security relevance classifier model includes the following specific steps: extract historical code change records and their corresponding security standard results from the historical review database as the training dataset. The source of the security standard results is the judgment label of human security experts on whether the code change involves security-related logic. Positive samples are defined as code changes involving security-related logic, and negative samples are defined as code changes not involving security-related logic. The ratio of positive to negative samples in the training dataset should be kept in a reasonable distribution to avoid the negative impact of sample imbalance on model training. When extracting positive and negative samples, the multi-dimensional feature vector of each code change record is extracted as the model input feature. The extracted positive and negative sample set is divided into training set, validation set and test set according to a preset ratio. The training set is used for model parameter learning, the validation set is used for hyperparameter tuning and early stopping judgment, and the test set is used for final model performance evaluation. The gradient boosting decision tree algorithm is used to perform multiple rounds of iterative training on the training set. The specific iterative training process involves constructing a new decision tree-based learner in each iteration based on the difference between the current model's prediction and the true label. This decision tree progressively classifies samples into different leaf nodes through feature space partitioning. The prediction value of each leaf node is the class mean or class label of the training samples within that node. The learning rate parameter controls the contribution weight of each tree's prediction to the final prediction. Prediction performance metrics on the validation set are used to determine whether to continue training or stop early to avoid overfitting. The test set is used to evaluate the generalization ability of the final model, with key evaluation metrics including precision, recall, F1 score, and area under the ROC curve. The model's hyperparameters and feature weights are adjusted using the prediction performance metrics on the validation set. Hyperparameters include the number of trees, the maximum tree depth, the minimum number of samples per leaf node, the learning rate, and the feature sampling ratio. Finally, a trained security relevance classifier model is obtained, which can predict the security relevance of newly submitted code changes.

[0042] The threshold setting mechanism for the prediction probability value of the security relevance classifier model adopts an adaptive adjustment strategy. In the initial stage, a preset fixed threshold is used for judgment. The initial setting value of the high threshold is 0.75, and the initial setting value of the low threshold is 0.30. During the system operation, the threshold parameters are continuously optimized based on the feedback data of the actual review results. The specific adjustment rule is that when a false alarm occurs with a high probability of prediction but no actual security problem, the judgment boundary of the high threshold is appropriately increased. When a low-probability prediction of a security issue is missed, the threshold for judgment is appropriately lowered. The magnitude of the threshold adjustment is determined based on the statistical results of the false positive rate and the false negative rate. Specifically, the false positive rate is calculated as the proportion of code changes with high probability predictions that actually have security issues within the past week, and the false negative rate is calculated as the proportion of code changes with low probability predictions that actually have security issues. When the false positive rate exceeds the preset upper limit, the high threshold is increased by 0.05, and when the false negative rate exceeds the preset upper limit, the low threshold is decreased by 0.05. The threshold adjustment cycle is set to a global evaluation and adjustment once a week. This adaptive threshold adjustment mechanism ensures that the classifier model can adapt to the change characteristics and review requirements of different code repositories.

[0043] The model output is a predicted probability value for code changes involving security-related logic. This probability value represents the model's confidence level in believing that the current code change involves security-related logic. When the predicted probability value is greater than the high threshold of 0.75, the current change is determined to involve security-related logic, directly triggering the subsequent large-scale model review process. When the predicted probability value is less than the low threshold of 0.30, the current change is determined not to involve security-related logic, and only a classification judgment is performed on the change without triggering the large-scale model review process. When the predicted probability value is between the high and low thresholds, it is marked as pending manual review, and the change is added to the manual review queue. Human security experts confirm whether the change involves security-related logic. The results of the manual review are fed back to the historical review database as training samples for subsequent model updates. This judgment result is used to determine whether to trigger the incremental large-scale model review process, achieving efficient allocation of review resources.

[0044] Step 3: Obtain the security-related context of the code change. When the determination result of Step 2 is that the current change involves security-related logic, this step retrieves the historical code versions and historical change records associated with the current change from the version control system to provide complete code evolution background information for subsequent large model review.

[0045] To obtain the historical version sequence of the files involved in the current change, the specific retrieval process involves obtaining the complete commit history of all files involved in the current change from the version control system. For each file, snapshot data and metadata information of the file in the most recent N historical versions are extracted. Obtaining the historical version sequence also includes obtaining the commit timestamp, committer information, commit message, and changes for each historical version. This historical version sequence is used to analyze the evolution and change patterns of files over time. The value of N is set to the range of 5 to 10, and the specific value is determined according to the change frequency of the file and the characteristics of the project. For files with high change frequency, the value is biased towards 5 to control the amount of context information, and for files with low change frequency, the value is biased towards 10 to ensure that sufficient context information is obtained.

[0046] The system retrieves a list of related files that depend on the currently modified file. The identification of related files utilizes static dependency analysis, specifically analyzing the import statements and dependency declarations of the modified file based on an abstract syntax tree. This identifies other files and modules that the file depends on. The specific implementation of dependency identification varies depending on the programming language: Java uses import statements and Maven or Gradle dependency configurations; Python uses import statements and requirements.txt or pyproject.toml dependency configurations; and JavaScript uses import statements, require statements, and package.json dependency configurations. Related file identification also includes cross-language dependency identification, such as when a Java file calls a C file via JNI. The identification results are verified and filtered to exclude test files and documentation files that are less relevant to security audits. Finally, a filtered list of related files is obtained. The historical versions of the related files identified in the first-level search results are retrieved, and the scope of historical version retrieval is consistent with the version retrieval scope of the current modified file.

[0047] Obtain the historical definition version of the function or method modified by the current change. For each function or method involved in the current change, obtain a snapshot of the definition of the function or method in each historical version from the version control system. Obtaining the historical definition version of the function includes extracting the changes in the function signature, the changes in the function body code, and the changes in other functions called within the function. Obtaining the historical definition version of the function also includes obtaining the historical version of the test code related to the function, and analyzing the coverage of the test code to the function and the evolution of test cases.

[0048] The system retrieves past review records for the same file or function from the historical review database. Specifically, the retrieval includes obtaining all review records of the file affected by the current change in the historical review database, including the timestamps of past reviews, review results, and security issues discovered during the reviews; obtaining the distribution information of historically discovered vulnerability types, categorized by vulnerability type, including common vulnerability types such as SQL injection vulnerabilities, XSS vulnerabilities, CSRF vulnerabilities, sensitive information disclosure vulnerabilities, access control vulnerabilities, encryption algorithm vulnerabilities, serialization vulnerabilities, command injection vulnerabilities, and path traversal vulnerabilities; obtaining the distribution information of historical risk levels, categorized by risk level, including the number of high-risk vulnerabilities, medium-risk vulnerabilities, low-risk vulnerabilities, and warning-level issues; obtaining historical remediation status information, recording whether historically discovered vulnerabilities have been remediated, the remediation timestamp, and the remediation plan; and obtaining historical changes with similar paths to the current change and their review results. Path similarity is determined based on file path prefix and suffix matching rules to identify changes and review status of other files in the same directory or related files within the same module.

[0049] This contextual information is used to provide complete background information on code evolution for subsequent large model reviews. The introduction of contextual information avoids the omission of security issues caused by large models performing isolated analysis based only on the current change fragments. After receiving review prompts containing complete contextual information, large models can understand the position and significance of the current change in the code evolution process, identify the evolution of the same vulnerability pattern in different versions, and thus provide more accurate and targeted security review recommendations.

[0050] Step 4: Conduct incremental security code review based on the large model. When Step 2 determines that the current change involves security-related logic, this step constructs review prompts containing complete contextual information, sends them to the large model for security review, and obtains the incremental code security assessment results output by the large model. The review prompts are the core input that guides the large model in conducting security reviews. Their quality directly affects the accuracy and completeness of the review results. The review prompts include the following four functional modules.

[0051] The system role setting module clearly defines the role and review capabilities of the large model as a security review expert. This module includes role definitions, clarifying the large model's identity as a code security review expert focused on identifying security vulnerabilities introduced by code changes. It also includes the scope of security knowledge the large model should possess, specifying common vulnerability types and security hardening measures, specifically including SQL injection, command injection, cross-site scripting attacks, cross-site request forgery, sensitive information leakage, access control flaws, encryption algorithm flaws, deserialization vulnerabilities, path traversal vulnerabilities, and race condition vulnerabilities. Finally, it includes capability constraints, specifying that the large model should avoid evaluating code style issues, naming conventions, and code performance. The issue includes review principles, clearly stating that the review principles for the large model prioritize finding security issues over providing optimization suggestions, finding high-risk vulnerabilities over finding low-risk vulnerabilities, and making comprehensive judgments based on historical context over isolated analysis of current changes. The system role setting module content is expressed through the following system prompts: "You are a professional code security review expert, responsible for analyzing whether code changes contain security vulnerabilities. You should focus on security issues and not evaluate code style, naming conventions, or performance issues. The types of vulnerabilities you need to focus on include, but are not limited to: SQL injection, command injection, XSS, CSRF, sensitive information disclosure, access control vulnerabilities, encryption algorithm defects, serialization vulnerabilities, and race condition vulnerabilities."

[0052] The code change context module contains the complete context information obtained in step three. It includes snippets of the current change content, clearly indicating the file names, file change types, and specific code differences involved. For newly added files, it displays the complete code content; for modified files, it displays the specific changes; and for deleted files, it explains the reason for deletion and the scope of the code involved. It also includes snippets of historical versions, showing the code content of the changed file in historical versions, displaying key code snippets from the last 5 to 10 versions. Furthermore, it includes dependency information for related files, showing a list of related files that depend on the currently changed file and their change summaries. Finally, it includes review history information, showing vulnerabilities discovered in historical reviews of the currently changed file and their remediation status, displaying the type, location, risk level, and remediation status of historical vulnerabilities to identify potential patterned issues. The code change context module uses structured text descriptions, with clear headings and separators distinguishing different types of context information.

[0053] The security review requirements module defines the scope of the security review, the key vulnerability types to focus on, and the level of review depth. This module includes a scope definition, clearly specifying the scope of the security review, including whether input validation is sufficient, output encoding is correct, identity authentication is secure, authorization checks are complete, data protection is adequate, error handling is appropriate, and logging is compliant. It also includes vulnerability type priority information, clearly stating that the focus of vulnerability detection should be adjusted according to the business type of the system to which the code belongs. For systems involving user data processing, the focus should be on data leakage risks; for systems involving network communication, the focus should be on injection attack risks; and for systems involving financial transactions, the focus should be on... The review focuses on transaction security and financial risks, including content at different levels of review depth. There are three levels of review depth: Basic review only examines the changed code itself; Standard review examines the changed code and its direct call relationships; and Deep review examines the changed code and its complete call chain. This includes requirements for historical context analysis, explicitly requiring analysis of whether the current change reflects a recurrence of historical vulnerabilities, the repeated occurrence of the same vulnerability pattern in different locations, and the evolution and escalation of historical vulnerabilities. It also includes requirements for security interface risk analysis, explicitly requiring analysis of security interface risks between the changed code and unmodified code that has dependencies on it. The content of the security review requirements module is expressed in the following structured form: "Please conduct a security review of this code change, focusing on the following aspects:" Please ensure that input validation is sufficient, output encoding is correct, identity authentication is secure, and authorization checks are comprehensive. Additionally, analyze whether this change results in a recurrence of historical vulnerabilities and whether there are any security interface risks. The output format module specifies the structured output requirements for review results. It includes output format specifications, explicitly requiring review results to be output in a structured format for easier subsequent analysis and processing. It also includes risk level labels, clearly defining four risk levels: CRITICAL indicates high-risk vulnerabilities that require immediate attention; HIGH indicates medium-risk vulnerabilities that require priority attention; MEDIUM indicates low-risk vulnerabilities that require follow-up attention; and LOW indicates warning-level vulnerabilities that can be handled selectively. The vulnerability information includes location information, specifying the file and line number where each vulnerability is located; a vulnerability type description, specifying the type, cause, and potential impact of each vulnerability; and remediation recommendations, specifying a detailed remediation plan for each vulnerability, including code examples and relevant security specification references. The output format module uses the following JSON format specification: "Please output the review results in JSON format, as follows:" {risks:{level:"CRITICAL|HIGH|MEDIUM|LOW",file:"file path",line:line number,type:"vulnerability type",description:"vulnerability description",fix:"remediation suggestion"}}. The review prompt is sent to the large model for security review. The sending process uses the standard API interface provided by the large model service provider. The API request parameters include the model identifier parameter to specify the specific model version number to be called, the prompt content parameter to pass in the completed review prompt, the maximum token quantity parameter to control the maximum length of the large model output, and the temperature parameter to control the randomness of the output. After the review request is sent, the system waits for the large model to return the review result. After the large model responds, the system performs format verification on the response content to ensure that the response content meets the specification requirements of the output format module. If the response format does not meet the specification, the system will handle it according to the preset degradation strategy, including retrying the request, returning error information, or marking it as an abnormal state.

[0054] The system retrieves the incremental code security assessment results output by the large model. After parsing, the following key information is extracted from the large model's output review results: a list of discovered vulnerabilities, each including risk level, vulnerability location, vulnerability type, vulnerability description, and remediation recommendations; an overall risk assessment level, which is the highest risk level among all discovered vulnerabilities; and review notes, including the large model's overall evaluation of the security of the changes and analysis of key risk points. The retrieval of review results also includes a confidence assessment of the large model's output. For review results with low confidence, the system marks the result as requiring manual review or supplementary review.

[0055] Step 5: Store and learn from the review results. This step writes the large-scale security assessment results obtained in Step 4 into the historical review database, and builds a vulnerability knowledge graph and review knowledge entries based on the accumulated data, so as to realize the reuse of review experience and continuous improvement of review capabilities.

[0056] Write the large-scale security assessment results into the historical review database. The write operation involves updating four types of core data tables in the historical review database, updating the code change record table, inserting or updating the record information of the current code change, including the change identifier field storing the unique identifier generated by the version control system, the repository identifier field storing the code repository identifier to which the code change belongs, the commit hash field storing the Git commit hash value or equivalent version control identifier, the commit time field storing the commit timestamp of the code change, the changed file list field storing the list of file paths involved in this change, and the change scale statistics field storing the scale statistics such as the number of new lines, the number of deleted lines, and the number of modified lines. Update the security standard result table and insert or update the security standard result corresponding to the current code change. This includes fields for labeling, change label association, and label tag to store security relevance judgment results from manual confirmation or model prediction; label time to store the timestamp of the labeling; and label description to store the basis for the labeling. It also updates the large model review result table, inserting or updating the large model review result corresponding to the current code change, including fields for review label, change label association, and review output to store the complete review result output by the large model; a list of discovered vulnerabilities to store a structured list of vulnerabilities; and an overall risk level to store the assessed overall risk level. Finally, it updates the remediation confirmation status table, inserting or updating the remediation status corresponding to the current code change, including fields for remediation label, review label association, and vulnerability number to store the vulnerability's number in the vulnerability list; a vulnerability type to store the vulnerability type classification; a risk level to store the vulnerability's risk level; and a remediation status to store the current remediation status, including pending, remediated, ignored, and requiring manual intervention.

[0057] Based on accumulated data in the historical review database, clustering analysis algorithms are used to identify recurring vulnerability patterns. The specific implementation process of clustering analysis involves extracting historical review records and the vulnerability information they discover from the historical review database, representing the extracted vulnerability information as feature vectors, and including vulnerability type, file path pattern of vulnerability location, code pattern of vulnerability location in file, context code pattern of vulnerability, and remediation scheme pattern. Hierarchical clustering or K-means clustering algorithms are used to perform clustering analysis on the vulnerability feature vectors to identify vulnerability clusters with similar features. Each cluster is analyzed to extract common feature patterns and typical remediation schemes of vulnerabilities within the cluster.

[0058] A vulnerability knowledge graph is established for specific code repositories or projects. The construction of the vulnerability knowledge graph is organized on a code repository basis. The node types in the graph include file nodes, function nodes, vulnerability type nodes, and vulnerability instance nodes. File nodes record attributes such as file path, name, module, and change frequency. Function nodes record attributes such as function signature, file, line number range in the file, and call relationship. Vulnerability type nodes record attributes such as vulnerability type classification, vulnerability classification system (e.g., OWASP Top 10, CVSS rating level), and common remediation strategies. Vulnerability instance nodes record attributes such as vulnerability location, discovery time, remediation status, and remediation plan. The edge types in the graph include definition relationship edges (representing the definition relationship between files and functions), call relationship edges (representing the call relationship between functions), discovery relationship edges (representing the discovery relationship between functions and vulnerability types), containment relationship edges (representing the containment relationship between files and vulnerability types), and evolution relationship edges (representing the version evolution relationship between vulnerability instances). The vulnerability knowledge graph is stored using a graph database or relational database combined with adjacency list storage, supporting graph traversal-based query and analysis operations.

[0059] Key security recommendations and remediation solutions are extracted from the large-scale model review results to generate reusable review knowledge entries. The extraction process involves parsing the large-scale model's output review results, extracting remediation recommendations, remediation code examples, and relevant security specification references. The extracted content is then structured, including extracting problem description text, problem cause analysis, remediation solution code, relevant security specification clauses, and risk level assessments. The structured content is then standardized, including unifying vulnerability type terminology, risk level terminology, and remediation solution format. Review knowledge entries are stored using a key-value pair structure. The key consists of a hash value generated by combining file path, function signature, and vulnerability type, while the value consists of structured review knowledge content. The review knowledge entries are indexed using an inverted index structure, supporting fast retrieval based on file path, function signature, and vulnerability type.

[0060] In the subsequent incremental review process, when step two determines that a code change involves security-related logic, the system automatically retrieves historical knowledge related to the current change from the vulnerability knowledge graph and review knowledge entries. The retrieval process includes searching for relevant historical changes and review results based on the file path of the current change, searching for relevant historical review records and known vulnerability patterns based on the functions involved in the current change, and searching for relevant remediation suggestions and review knowledge entries based on the vulnerability type of the current change. The retrieved historical knowledge is integrated into the review prompts in step four, providing a reference historical context for the larger model. The historical knowledge is referenced in various ways, including displaying relevant historical changes and review results in the code change context module and referencing relevant information in the security review requirements module. The system collects known vulnerability patterns and remediation suggestions, and performs consistency checks with historical knowledge when outputting review results from the large model. The large model combines historical knowledge with the specific context of current changes to provide more targeted security recommendations. The generation and updating process of review knowledge entries also includes regular quality assessments of existing knowledge entries. The assessments include: accuracy assessment based on confirmation of subsequent actual remediation results; effectiveness assessment based on the frequency of reference of knowledge entries in subsequent reviews; and timeliness assessment based on changes in related code or vulnerability types. Based on the assessment results, knowledge entries are optimized, adjusted, or replaced. This mechanism enables the review system to gradually learn and adapt to the unique code security characteristics of the enterprise, forming a continuously improving review capability.

[0061] The following detailed explanation of the operation process of the method of the present invention is based on a specific application example. In a web application development project of an internet company, the security team used the incremental security code review method provided by the present invention to conduct security reviews of code changes.

[0062] A code change was submitted, which involved modifications to three files: The first file is src / service / UserService.java, which modifies the function signature and internal logic of the user login verification method; The second file is src / util / PasswordUtil.java, which modifies the implementation of the password encryption method; The third file is src / config / SecurityConfig.java, which modifies the relevant parameters of the security configuration. After the version control system receives this commit, it pushes the commit record to the data receiving module of the review system through the Webhook mechanism, and the review system begins to execute the processing flow of step one.

[0063] During the execution of step one, the review system first parses the list of changed files and the differences in the changed content in the submission record. For the UserService.java file, the review system calculates the scale of changes to this file, finding that 45 lines of code were added, 120 lines of code were modified, and 30 lines of code were deleted. For the PasswordUtil.java file, the review system calculates the scale of changes to this file, finding that 20 lines of code were added, 35 lines of code were modified, and 10 lines of code were deleted. For the SecurityConfig.java file, the review system calculates the scale of changes to this file, finding that 15 lines of code were added, 40 lines of code were modified, and 5 lines of code were deleted. The review system extracts semantic-level features based on abstract syntax tree parsing technology. For the UserService.java file, it identifies a change in the function signature of the login verification method, which involves changing the parameter type from String to a UserCredential object. Meanwhile, the internal logic has added code for third-party authentication integration. For the PasswordUtil.java file, it has been found that the password encryption method calls a new encryption function and added password strength verification logic. For the SecurityConfig.java file, changes to security configuration parameters were detected, including session timeout, password policy parameters, and two-factor authentication switch parameters. The review system constructed a multi-dimensional feature vector based on the extracted features. The values ​​of each dimension of the vector are as follows: the components of the code change scale feature dimension are normalized according to the actual statistical values; the security sensitive path marking component of the file path feature dimension is marked as medium security sensitive based on the three files being located in the service directory, util directory, and config directory respectively; the function signature change marking component of the code semantic feature dimension is marked as 1 based on the detection results; the critical function change marking component is marked as 1 based on the detection results; the sensitive operation change marking component of the change type feature dimension is marked as 1 based on the detection results; and the input / output boundary change marking component is marked as 1 based on the detection results. The components of the review history feature dimension are calculated based on the historical records of the three files in the historical review database. After step one is completed, the multi-dimensional feature vector is constructed.

[0064] When step two is executed, the review system inputs the multi-dimensional feature vector into the pre-trained security-related classifier model. The model outputs a predicted probability value of 0.87, which is greater than the high threshold of 0.75. The review system determines that the code change involves security-related logic and directly triggers the subsequent large model review process.

[0065] When step three is executed, the review system obtains context information related to the current change. For the UserService.java file, the review system obtains snapshot data of the file's 8 most recent historical versions from the version control system. For the PasswordUtil.java file, the review system obtains snapshot data of the file's 6 most recent historical versions. For the SecurityConfig.java file, the review system obtains snapshot data of the file's 5 most recent historical versions. The review system identifies associated files of the UserService.java file through static dependency analysis, including UserController.java, AuthenticationFilter.java, and PasswordUtil.java. The system obtains historical versions of these three associated files and retrieves historical review records for these three changed files from the historical review database. The UserService.java file was found to have a high-risk vulnerability (sensitive information disclosure), which has been fixed. The PasswordUtil.java file was found to have a medium-risk vulnerability (weak encryption algorithm), which has been fixed. The SecurityConfig.java file was found to have a low-risk vulnerability (configuration default value issue), which has been fixed. Step three is now complete, and the complete context information has been obtained.

[0066] In step four, the review system constructs review prompts containing complete contextual information. The system role setting module for the prompts clarifies the role of the large model as a security review expert. The code change context module includes the currently changed code differences, historical version fragments of the three files, dependencies of related files, and historical review records. The security review requirements module defines the review scope, including identity authentication security, data protection security, and configuration security. The output format module specifies that the review results are output in JSON format, including risk level, vulnerability location, vulnerability type, vulnerability description, and remediation suggestions. The review system sends the prompts to the large model for security review, and the large model returns the review results. One high-risk vulnerability was found on line 156 of the UserService.java file. This vulnerability is a hard-coded sensitive information vulnerability. The overall model recommends removing the hard-coded sensitive information and using a configuration center for management. One medium-risk vulnerability was found on line 42 of the PasswordUtil.java file. This vulnerability is a weak password hash algorithm vulnerability. The overall model recommends using a more secure hash algorithm such as Argon2 or bcrypt. One low-risk vulnerability was found on line 28 of the SecurityConfig.java file. This vulnerability is an excessively long session timeout configuration vulnerability. The overall model recommends shortening the session timeout. Step four is now complete, and the overall model review results are obtained.

[0067] During step five, the review system writes the large model review results into the historical review database, updates the code change record table, security standard result table, large model review result table, and remediation confirmation status table. The review system uses clustering analysis algorithms to identify vulnerability patterns and finds that the sensitive information hard-coded vulnerability discovered this time has similar characteristics to other hard-coded issues discovered in the past. This vulnerability pattern is added to the vulnerability knowledge graph. The review system extracts remediation suggestions from the large model review results, generates three review knowledge entries, and stores them in the review knowledge entry table. The developers remediate the discovered vulnerabilities based on the review results. The review system updates the remediation status field of the remediation confirmation status table to "remediated." Step five is then completed, and the review process is finished.

[0068] As can be seen from the above specific application examples, the incremental security code review method of the present invention can intelligently determine the security relevance of code changes, trigger in-depth review of large models for changes that truly involve security logic, improve review quality by introducing contextual information, and achieve continuous improvement of review capabilities through learning from review results.

[0069] Example 2: The developers submitted a code change involving modifications to files in the core payment module, including the PaymentProcessor.java file. This file modified the core logic of payment processing and added new payment channel integration code. After the version control system received the submission, the review system began executing an incremental security review process.

[0070] During the execution of step one, the review system parses the submission records; For the PaymentProcessor.java file, the review system statistically analyzed the scale of changes, finding 200 newly added lines of code, 350 modified lines of code, and 80 deleted lines of code. Based on abstract syntax tree analysis, it was identified that significant changes had occurred in the payment processing method, involving multiple key functions such as payment interface calls, amount calculation, transaction processing, and asynchronous callback processing. The review system constructed a multi-dimensional feature vector, and the security-sensitive path marking component of the file path feature dimension was marked as high security sensitive based on the fact that PaymentProcessor.java is located in the payment directory.

[0071] During step two, the classifier model outputs a predicted probability of 0.92, which is higher than the high threshold. The review system determines that the change involves security-related logic, triggering the large model review process. During step three, the review system obtains context information, retrieves snapshot data of the 10 most recent historical versions of the PaymentProcessor.java file, identifies 12 related files including PaymentValidator.java, TransactionManager.java, and PaymentGateway.java, and searches the historical review database for the PaymentProcessor.java file's history. It is found that the file has two high-risk vulnerabilities: an amount calculation overflow vulnerability and a transaction processing improper vulnerability.

[0072] During step four, the review system constructs security review prompts for the financial system, focusing on transaction security, fund security, and compliance requirements. After reviewing the large model, several security issues were discovered, including one high-risk vulnerability where payment amounts were not processed with precision, which could lead to incorrect amount calculations; two medium-risk vulnerabilities where transaction boundaries were unclear and asynchronous callback processing logic had race conditions; and one low-risk vulnerability where log records contained sensitive transaction information.

[0073] When step five is executed, the review system stores the review results in the historical review database, updates the vulnerability knowledge graph, and generates review knowledge entries for the payment system.

[0074] As can be seen from this embodiment, the method of the present invention can adapt to the security review requirements of different business systems, and effectively discover security vulnerabilities in financial payment systems by obtaining contextual information and conducting professional review of large models.

[0075] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of the present invention is defined by the appended claims and their equivalents.

Claims

1. An incremental security code review method based on code change history and large model prediction, comprising the following steps: Step 1: Receive code change commit records from the version control system, and parse the list of changed files, differences in the changed content, and change metadata; Step 2: Extract multi-dimensional feature vectors of code changes based on abstract syntax tree parsing technology; Step 3: Use a pre-trained security relevance classifier model to predict the security relevance of the current code change based on the multi-dimensional feature vector. The model outputs a predicted probability value. When the predicted probability value is greater than a high threshold, it is determined that the current change involves security-related logic and the subsequent review process is triggered. Step 4: When it is determined that the current change involves security-related logic, obtain the historical version sequence of the changed file and the list of associated files from the version control system, and retrieve past review records from the historical review database; Step 5: Based on the big model, perform incremental security code review on changes involving security-related logic, construct review prompts containing code change fragments, historical code fragments, code context, and review history, and send them to the big model to obtain security assessment results; Step Six: Write the large-scale model security assessment results into the historical review database, use clustering analysis algorithms to identify recurring vulnerability patterns, build a vulnerability knowledge graph, and generate reusable review knowledge entries.

2. The incremental security code review method based on code change history and large model prediction as described in claim 1, characterized in that, When extracting multidimensional feature vectors of code changes, abstract syntax tree parsing technology is used to extract function signature change identifiers, key function call change identifiers, input / output boundary change identifiers, and sensitive operation change identifiers of the changed code. Calculate change scale statistics, including the number of new lines of code, the number of deleted lines of code, and the number of modified lines of code, as well as their distribution ratio in the change files.

3. The incremental security code review method based on code change history and large model prediction as described in claim 1, characterized in that, The security relevance classifier model is trained using the gradient boosting decision tree algorithm, and the training samples are derived from historical code change records and their security standard results in the historical review database. Positive samples are defined as code changes involving security-related logic, while negative samples are defined as code changes not involving security-related logic. The multi-dimensional feature vector of each code change record is extracted as the input feature of the model. The gradient boosting decision tree algorithm is used to perform multiple rounds of iterative training on the positive and negative sample sets. The hyperparameters and feature weights of the model are adjusted by the prediction performance index on the validation set.

4. The incremental security code review method based on code change history and large model prediction as described in claim 1, characterized in that, When using a classifier model to predict the security relevance of code changes, when the predicted probability value is between a high threshold and a low threshold, the change is added to the manual review queue. Human security experts confirm whether the change involves security-related logic, and the manual review results are fed back to the historical review database for subsequent model updates. An adaptive adjustment strategy is adopted to continuously optimize the threshold parameters. When a false alarm occurs with a high probability of prediction but no actual security problem, the high threshold boundary is appropriately increased. When a false alarm occurs with a low probability of prediction but actual security problem, the low threshold boundary is appropriately decreased. The threshold adjustment range is determined based on the statistical results of the false alarm rate and the false alarm rate.

5. The incremental security code review method based on code change history and large model prediction as described in claim 1, characterized in that, When obtaining context information about code changes, a hierarchical and progressive retrieval method is adopted; The first layer retrieves the most recent N historical versions of the files involved in the current change; the second layer retrieves historical versions of related files; and the third layer retrieves historical changes and their review results that have similar paths to the current change from the historical review database. At the same time, it obtains snapshots of the definitions of the functions or methods modified by the current change in each historical version.

6. The incremental security code review method based on code change history and large model prediction as described in claim 1, characterized in that, When constructing the review prompts, the review prompts include a system role setting module, a code change context module, a security review requirements module, and an output format module; The system role setting module clearly defines the role and review capability boundaries of the large model as a security review expert. The code change context module includes the current change fragment, historical code fragments, code context, and review history; The security review requirements module defines the scope of the security review, the types of vulnerabilities to focus on, and the level of review depth; The output format module specifies the structured output requirements for the review results, including risk level labels, vulnerability location information, vulnerability type descriptions, and remediation recommendations.

7. The incremental security code review method based on code change history and large model prediction as described in claim 1, characterized in that, When conducting incremental security code reviews based on large models, the historical context of code changes should be combined to identify whether there is a recurrence or evolution of historical vulnerabilities. Identify security interface risks between modified code and unmodified code that has dependencies on it; Adjust the focus of vulnerability detection based on the business type of the system to which the code belongs.

8. The incremental security code review method based on code change history and large model prediction as described in claim 1, characterized in that, When writing the large-scale model security assessment results into the historical review database, the code change record table, security standard result table, large-scale model review result table, and remediation confirmation status table are updated. At the same time, based on the accumulated data in the historical review database, clustering analysis algorithms are used to identify recurring vulnerability patterns and establish a vulnerability knowledge graph for specific code repositories or projects.

9. The incremental security code review method based on code change history and large model prediction as described in claim 1, characterized in that, When generating reusable review knowledge entries, key security recommendations and remediation solutions are extracted from the large model review results. The extracted content is then structured and standardized to generate review knowledge entries. In subsequent incremental reviews, the system automatically retrieves historical knowledge related to the current changes from the vulnerability knowledge graph and review knowledge entries and integrates it into the review prompts for the large model to reference.

10. The incremental security code review method based on code change history and large model prediction according to claim 1, characterized in that, When using clustering analysis algorithms to identify recurring vulnerability patterns, historical review records and their discovered vulnerability information are extracted from the historical review database. The vulnerability information is represented by feature vectors, and hierarchical clustering or K-means clustering algorithms are used to perform cluster analysis on the vulnerability feature vectors to identify vulnerability clusters with similar characteristics. For each cluster, common feature patterns and typical remediation solutions are extracted. The existing knowledge entries are regularly evaluated for quality and optimized or updated based on the evaluation results.

Images