Source code security defect prediction method and system based on machine learning

Abstract

The invention relates to the technical field of code security detection, in particular to a source code security defect prediction method and system based on machine learning, and the method comprises the steps: generating an alarm data set, carrying out the feature extraction of each alarm in the alarm data set, and obtaining the alarm fingerprint of each alarm; performing multi-level matching on the alarm fingerprint of each alarm and a preset repair context fingerprint database to obtain a matching result and a matching certainty degree of each alarm; on the basis of a preset classification rule, automatically classifying newly generated alarms according to the matching result and the matching certainty degree to obtain a classification result; and outputting a classification result and a corresponding matching evidence, and carrying out adaptive optimization. According to the method, the efficiency and accuracy of processing source code security defects by security engineers can be remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of code security detection technology, and in particular to a method and system for predicting source code security defects based on machine learning. Background Technology

[0002] In the field of source code security defect detection technology, vulnerability management tools mainly rely on rule matching or static analysis models to independently judge newly generated alerts, lacking effective utilization of the project's own remediation history. Numerous duplicate alerts, variations of historical false alarms, and recurrences of patched vulnerabilities consume a significant amount of security engineers' analysis time.

[0003] In existing technologies, methods for deduplication of alerts based on code similarity are common, but they still have shortcomings. For example, in the patent application CN202511114793.4, the comparison logic based on code slice similarity is too simplistic. It essentially equates vulnerability detection with code clone detection, failing to distinguish between the actual reproduction of dangerous patterns and harmless similar code structures. This approach heavily relies on syntactic similarity while ignoring the semantic information of remediation actions and the influence of environmental context, leading to a high false positive rate in real-world, noisy codebases.

[0004] For example, patent application CN202411473710.6 uses an unverified historical alert database as a comparison benchmark. This benchmark itself is riddled with false alarms and unconfirmed items, causing its similarity aggregation to actually repeat and amplify historical noise, rather than making judgments based on deterministic repair knowledge. This method fails to answer a crucial question: are similar historical alerts themselves correct? Therefore, its output lacks authority and operability, and cannot provide security engineers with reliable decision-making support.

[0005] Based on the above analysis, the existing technology has two major drawbacks. First, matching based on grammatical similarity cannot incorporate security semantics, which can easily lead to misjudgment (e.g., CN202511114793.4). Second, comparison based on noisy historical alarms lacks authoritative knowledge sources, and the conclusions are unreliable (e.g., CN202411473710.6).

[0006] Therefore, there is an urgent need for a new solution that can extract authoritative knowledge from proven remediation experience and perform multi-dimensional, semantic reasoning to overcome the problems existing in the two patented solutions mentioned above, and provide a more efficient and complete solution for deduplication of alerts in vulnerability management tools, thereby improving the work efficiency of security engineers. Summary of the Invention

[0007] This invention addresses the problems in existing technologies, such as the inability of matching based on grammatical similarity to incorporate security semantics, which easily leads to misjudgments, and the lack of authoritative knowledge sources and unreliable conclusions in comparisons based on noisy historical alerts. It provides a source code security defect prediction method and system based on machine learning to solve these problems.

[0008] The technical solution of the present invention to solve the above-mentioned technical problems is as follows: In a first aspect, the present invention provides a source code security defect prediction method based on machine learning, comprising: Newly generated alerts are acquired, and alert association data is extracted to generate an alert dataset containing vulnerability type, location information, and code context. Based on preset feature extraction rules, features are extracted from each alert in the alert dataset to obtain an alert fingerprint for each alert. The alert fingerprint includes at least code pattern features, remediation features, and environmental features. The alert fingerprint of each alert is matched at multiple levels with a preset remediation context fingerprint database to obtain a matching result and matching confidence level for each alert. The remediation context fingerprint database contains multiple confirmed and remediated historical vulnerability instances. Based on preset classification rules, the newly generated alerts are automatically classified according to the matching results and matching confidence levels to obtain classification results. The classification results include at least remediated-recurring, remediated-similar patterns, historical false alarm patterns, and entirely new alerts. The classification results and corresponding matching evidence are output, and the remediation context fingerprint database and matching rules are adaptively optimized based on the confirmation feedback from security engineers regarding the classification results.

[0009] Optionally, acquiring newly generated alerts, extracting alert-related data, and generating an alert dataset includes: receiving a raw alert stream from a static application security testing tool and / or a software composition analysis tool; parsing the raw alert stream and extracting structured data for each alert, wherein the structured data includes at least an alert identifier, a vulnerability type identifier, and location information, wherein the location information includes a trigger file path and a line number; based on the trigger file path and line number, extracting the corresponding code fragment and adjacent code within a preset line number range from the version control system to form code context data; and merging the structured data with the code context data to generate the alert dataset.

[0010] Optionally, based on preset feature extraction rules, feature extraction is performed on each alarm in the alarm dataset to obtain an alarm fingerprint for each alarm. This includes: analyzing the code context data, identifying key code patterns related to security vulnerabilities, and abstracting the key code patterns into standardized pattern codes as the code pattern features; the key code patterns at least include unverified data flows, dangerous function call sequences, and missing security checks; based on the vulnerability type identifier and the code context data, inferring possible remediation scheme types for the vulnerability type as the remediation features; the remediation scheme types at least include adding parameter verification, replacing with secure functions, and adjusting security configurations; capturing environmental state information at the time the alarm is generated as the environmental features, the environmental state information at least includes the name and version of the reporting tool, the code commit hash of the project at the time of the alarm, and the version number of key dependent libraries; and combining the extracted code pattern features, remediation features, and environmental features according to preset weights to form the alarm fingerprint.

[0011] Optionally, the alarm fingerprint of each alarm is matched with a preset remediation context fingerprint database at multiple levels, including: performing a first-level precise match: calculating the similarity between the code pattern features in the alarm fingerprint and the code pattern features of any record in the remediation context fingerprint database. If the similarity is higher than a first preset threshold and the location information is less than a preset distance from the historical vulnerability location associated with the record, it is determined to be a precise match, and a first-level match confidence score is assigned; performing a second-level similar match: if a precise match is not achieved, the similarity is extracted. If the similarity is between a second preset threshold and a first preset threshold, it is determined to be a similar match, and a second-level match confidence score is calculated based on the similarity value; performing a third-level tool historical match: if the first two levels fail to match, the remediation context fingerprint database is queried to see if there are any records reported by the same reporting tool on the same trigger file path with the same vulnerability type identifier. If such records exist and are marked as historical false alarms, they are determined to be tool historical matches, and a third-level match confidence score is calculated based on the number of times such historical false alarms have been confirmed.

[0012] Optionally, the method for constructing the preset repair context fingerprint database includes: monitoring the commit history of the version control system, identifying repair commits whose description information contains preset security keywords, the security keywords including at least repair, vulnerability, CVE, and security; extracting code change differences from the repair commits; performing feature extraction on the code change differences to generate a repair context fingerprint, the repair context fingerprint including vulnerability code pattern characteristics before repair, implemented repair characteristics, and environmental characteristics at the time of submission; and storing the repair context fingerprint together with the corresponding commit hash, vulnerability type, and repair time as historical vulnerability instances to form the initial record of the repair context fingerprint database.

[0013] Optionally, based on preset classification rules, newly generated alerts are automatically classified according to the matching results and matching confidence levels to obtain classification results, including: preset classification rules, wherein the classification rules set corresponding matching confidence thresholds for each matching type; if the matching result is an exact match and its first-level matching confidence level reaches or exceeds the recurrence confidence threshold, the current alert is classified as fixed-recurrence; if the matching result is a similar match and its second-level matching confidence level reaches or exceeds the similar pattern confidence threshold, the current alert is classified as fixed-similar pattern; if the matching result is a tool historical match and its third-level matching confidence level reaches or exceeds the false alarm pattern confidence threshold, the current alert is classified as historical false alarm pattern; if no matching result is generated, or although there is a matching result, its matching confidence level does not reach the corresponding threshold, the current alert is classified as a new alert.

[0014] Optionally, based on the security engineer's confirmation feedback on the classification results, adaptive optimization is performed on the repair context fingerprint database and matching rules, including: receiving confirmation feedback from the security engineer on the system's automatic classification results, the feedback including at least confirmation of correctness, correction of classification, marking as a false alarm, and associated repair submission; binding the feedback with the corresponding alarm data, the alarm fingerprint generated by the system, the matching results, and the matching confidence level to form labeled feedback samples and establish a feedback sample pool; calculating the model perplexity value of each feedback sample; periodically selecting the K samples with the highest model perplexity values ​​from the feedback sample pool to form a high-value training sample set; using the high-value training sample set, training a parameter configurator based on machine learning, and in subsequent alarm processing, for each new alarm, calling the parameter configurator to generate a set of dynamically optimized parameters in real time based on the alarm fingerprint features of the new alarm, and using the dynamically optimized parameters to replace the preset fixed parameters, and performing multi-level matching and classification decisions for the new alarm; repeating the above optimization process to form a continuously self-evolving active learning closed loop.

[0015] Optionally, the model perplexity value for each feedback sample is calculated, including: the model perplexity value is calculated based on the degree of dispersion between the matching confidence of each level within the system during the previous matching and classification process, and the model perplexity value is positively correlated with the degree of dispersion.

[0016] Optionally, a parameter configurator is trained based on machine learning, including: for each high-value training sample, based on the corresponding security engineer's confirmation feedback, a set of system parameters that enable the system to output a classification result consistent with the corresponding feedback in the state corresponding to the high-value training sample, and using the system parameters as the target parameter label for the high-value training sample; using the alarm fingerprint features and system historical state features of the high-value training sample as input features, and pairing them with the target parameter label to form a supervised learning training sample; using the supervised learning training sample, training a regression model through a supervised learning algorithm to obtain the parameter configurator.

[0017] Secondly, this invention provides a source code security flaw prediction method based on machine learning, including: The system comprises the following modules: an alarm data acquisition module, which acquires newly generated alarms, extracts alarm-related data, and generates an alarm dataset containing vulnerability type, location information, and code context; an alarm fingerprint extraction module, which extracts features from each alarm in the alarm dataset based on preset feature extraction rules to obtain an alarm fingerprint for each alarm, wherein the alarm fingerprint includes at least code pattern features, remediation features, and environmental features; a multi-level matching module, which performs multi-level matching of each alarm fingerprint with a preset remediation context fingerprint database to obtain a matching result and matching confidence level for each alarm, wherein the remediation context fingerprint database contains multiple confirmed and remediated historical vulnerability instances; an automatic alarm classification module, which automatically classifies newly generated alarms based on preset classification rules and the matching results and matching confidence levels to obtain classification results, wherein the classification results include at least remediated-recurring, remediated-similar patterns, historical false alarm patterns, and entirely new alarms; and an adaptive optimization module, which outputs the classification results and corresponding matching evidence, and adaptively optimizes the remediation context fingerprint database and matching rules based on the confirmation feedback from security engineers regarding the classification results.

[0018] Beneficial effects: 1. This invention acquires newly generated alerts, extracts alert-related data, and generates an alert dataset. The alert dataset includes vulnerability type, location information, and code context. This provides a standardized and structured data foundation for subsequent feature extraction and matching, ensuring comprehensive data sources and uniform format, and avoiding the impact of data clutter on subsequent processing accuracy.

[0019] 2. This invention extracts features from each alarm in the alarm dataset based on preset feature extraction rules to obtain an alarm fingerprint for each alarm. The alarm fingerprint includes at least code pattern features, repair features, and environmental features. The multidimensional information of the alarm is condensed into a standardized fingerprint, breaking the limitations of features at the purely syntactic level, and incorporating repair semantics and environmental context to improve the recognizability and relevance of features.

[0020] 3. This invention performs multi-level matching of the alarm fingerprint of each alarm with a preset repair context fingerprint database to obtain the matching result and matching confidence level of each alarm. The repair context fingerprint database contains multiple confirmed and repaired historical vulnerability instances. Relying on the confirmed and repaired historical vulnerability instances as authoritative benchmarks, multi-level matching is used to achieve accurate judgment of different similarity scenarios, reducing the interference of false alarms and duplicate alarms.

[0021] 4. Based on preset classification rules, this invention automatically classifies newly generated alerts according to the matching results and matching confidence levels to obtain classification results. The classification results include at least fixed-recurrence, fixed-similar patterns, historical false alarm patterns, and brand new alerts. This achieves automated classification of alerts, allowing security engineers to quickly distinguish alert priorities, focus on brand new alerts and high-risk recurrence alerts, and improve vulnerability handling efficiency.

[0022] 5. This invention outputs the classification results and corresponding matching evidence, and adaptively optimizes the repair context fingerprint database and matching rules based on the confirmation feedback from security engineers. This forms a continuously evolving active learning closed loop, enabling the system to continuously improve matching accuracy and classification accuracy as it is used over time. It adapts to the code characteristics of different projects, effectively integrates the semantic information and environmental context of the project's repair history, significantly reduces the false positive rate and duplicate alert ratio of vulnerability detection, and significantly improves the efficiency and accuracy of security engineers in handling source code security defects. Attached Figure Description

[0023] Figure 1 A flowchart illustrating the machine learning-based source code security defect prediction method provided by this invention; Figure 2 A schematic diagram of the structure of the machine learning-based source code security defect prediction system provided by the present invention.

[0024] In the attached diagram, the components represented by each number are as follows: Alarm data acquisition module 11, alarm fingerprint extraction module 12, multi-level matching module 13, alarm automatic classification module 14, and adaptive optimization module 15. Detailed Implementation

[0025] Example 1, as Figure 1 As shown, this embodiment of the invention provides a source code security flaw prediction method based on machine learning, including: S100: Obtain newly generated alerts, extract alert-related data, and generate an alert dataset, which includes vulnerability type, location information, and code context; S200: Based on preset feature extraction rules, perform feature extraction on each alarm in the alarm dataset to obtain an alarm fingerprint for each alarm, wherein the alarm fingerprint includes at least code pattern features, repair features and environmental features; S300: Perform multi-level matching of the alarm fingerprint of each alarm with the preset repair context fingerprint database to obtain the matching result and matching confidence level of each alarm, wherein the repair context fingerprint database contains multiple confirmed and repaired historical vulnerability instances. S400: Based on preset classification rules, according to the matching results and matching confidence level, the newly generated alarms are automatically classified to obtain classification results, wherein the classification results include at least fixed-recurrence, fixed-similar pattern, historical false alarm pattern and new alarm; S500: Output the classification results and corresponding matching evidence, and adaptively optimize the repair context fingerprint database and matching rules based on the security engineer's confirmation feedback on the classification results.

[0026] In step S100 of this application embodiment, obtaining newly generated alarms, extracting alarm-related data, and generating an alarm dataset includes: Receive raw alert streams from static application security testing tools and / or software composition analysis tools; The original alert stream is parsed, and the structured data of each alert is extracted. The structured data includes at least an alert identifier, a vulnerability type identifier, and location information, wherein the location information includes the trigger file path and the line number of the code. Based on the trigger file path and line number, the corresponding code fragment and adjacent code within a preset line number range are extracted from the version control system to form code context data; The structured data and the code context data are merged to generate the alert dataset.

[0027] The purpose of step S100 in this embodiment is to provide standardized, structured basic data containing complete code environment information for subsequent alarm fingerprint extraction, multi-level matching, and automatic classification. It solves the problems of high false positive rates and insufficient authority caused by relying solely on single grammatical features or noisy historical alarm comparisons in existing technologies. By integrating alarm basic attributes with code context, subsequent machine learning analysis can have more comprehensive judgment criteria, thereby improving the accuracy and reliability of source code security defect prediction.

[0028] To achieve the above objectives, it is first necessary to receive raw alert streams from static application security testing tools and / or software composition analysis tools; This involves interfacing with two mainstream source code security testing tools to collect their raw alert data. These two types of tools are static application security testing tools and software composition analysis tools.

[0029] Examples of key tools: For static application security testing, SonarQube and Fortify can be used; for software composition analysis, BlackDuck and Snyk can be used. These tools generate raw alert streams containing security flaw warnings in real time during code scanning.

[0030] This step ensures the comprehensiveness of the original alert data, covering both code-specific vulnerabilities and third-party dependency vulnerabilities.

[0031] Then, the original alert stream is parsed to extract the structured data of each alert. The structured data includes at least an alert identifier, a vulnerability type identifier, and location information, wherein the location information includes the trigger file path and the line number of the code. This involves parsing and formatting the collected unstructured raw alarm streams to extract core information with unified field specifications.

[0032] After parsing, three types of core structured data need to be extracted: alarm identifier, vulnerability type identifier, and location information.

[0033] The alarm identifier is used to uniquely distinguish the number of each alarm, such as ALERT-20250520-001.

[0034] The vulnerability type identifier is used to mark the security flaw category corresponding to the alert. For example, CWE-89 corresponds to an SQL injection vulnerability, and CWE-79 corresponds to a cross-site scripting vulnerability.

[0035] The location information includes two key sub-parameters: the trigger file path and the line number. For example, the trigger file path could be / src / main / java / com / example / project / UserAuth.java, and the line number could be line 36.

[0036] This step transforms the messy raw alerts into structured data that can be recognized by machines, laying the foundation for subsequent data processing and matching.

[0037] Next, based on the trigger file path and line number, the corresponding code snippet and adjacent code within a preset line number range are extracted from the version control system to form code context data; Based on the parsed trigger file path and line number, the system connects to version control systems such as Git and SVN to retrieve the corresponding code snippet. Simultaneously, it extracts adjacent code within a preset line range from this snippet, collectively forming the code context data.

[0038] The version control system, taking Git as an example, can locate the code version at the time the alert was generated by committing hash values.

[0039] The preset line range can be set according to the complexity of the project code, for example, 15 lines before and after the target line. If the target line is line 36, then the code range to be retrieved is lines 21 to 51.

[0040] This step involves obtaining the specific code environment in which the vulnerable code resides, avoiding the limitations of relying solely on isolated lines of code for judgment. For example, a dangerous function call in a certain line of code might have security checks in adjacent code; in such cases, the context is needed for accurate judgment.

[0041] Finally, the structured data and the code context data are merged to generate the alert dataset.

[0042] The structured data and code context data obtained in the previous steps are integrated to form an alert record containing complete information. Multiple such records are aggregated to form the final alert dataset.

[0043] For example, a complete alert dataset record contains the alert identifier: ALERT-20250520-001, vulnerability type identifier: CWE-89, trigger file path: / src / main / java / com / example / project / UserAuth.java, line number: 36, and code context: a code snippet from lines 21 to 51.

[0044] This step associates alert attributes with the code environment, allowing subsequent feature extraction to take into account vulnerability type, location information, and code context simultaneously, thus improving the accuracy of subsequent analysis.

[0045] In step S200 of this embodiment, based on preset feature extraction rules, feature extraction is performed on each alarm in the alarm dataset to obtain an alarm fingerprint for each alarm, including: The code context data is analyzed to identify key code patterns related to security vulnerabilities, and these key code patterns are abstracted into standardized pattern codes as the code pattern features. The key code patterns include at least unverified data flows, dangerous function call sequences, and missing security checks. Based on the vulnerability type identifier and the code context data, possible remediation schemes for the vulnerability type are inferred as the remediation features; the remediation scheme types include at least adding parameter validation, replacing with secure functions, and adjusting security configurations. Capture environmental state information when an alert is generated, which is the environmental feature. The environmental state information includes at least the name and version of the reporting tool, the code commit hash of the project at the time of the alert, and the version number of the key dependency library. The extracted code pattern features, repair features, and environmental features are combined according to preset weights to form the alarm fingerprint.

[0046] In this embodiment, the purpose of step S200 is to extract an alarm fingerprint from a standardized alarm dataset that uniquely represents the core features of the alarm. This overcomes the limitations of existing technologies that rely solely on syntactic similarity. By using semantic analysis to mine the security semantics of code patterns, and then fusing two types of semantic information—remediation plans and environmental states—it provides accurate and comparable feature data for subsequent multi-level matching, thereby reducing the false positive rate.

[0047] To achieve the above objectives, it is first necessary to analyze the code context data, identify key code patterns related to security vulnerabilities, and abstract these key code patterns into standardized pattern codes as the characteristics of the code patterns. The key code patterns include at least unverified data flows, dangerous function call sequences, and missing security checks. That is, by analyzing the code context data, using semantic analysis techniques such as taint tracking, data dependency analysis, and control flow analysis, key code patterns related to security vulnerabilities are identified, and the key code patterns are abstracted into standardized pattern codes as the code pattern features; the key code patterns include at least unverified data flows, dangerous function call sequences, and missing security checks.

[0048] Specifically, when identifying unverified data streams, taint tracking technology is used to trace the entire flow of user input parameters from input to dangerous operations to determine whether the parameters have been cleaned up; when identifying dangerous function call sequences, control flow analysis is combined to determine whether there is security logic such as permission verification and condition filtering before and after the function call; when identifying missing security checks, data dependency analysis is used to clarify the relationship between dangerous operations and pre-verification steps, thereby distinguishing code structures that are syntactically similar but semantically different.

[0049] Critical code patterns include unverified data streams, dangerous function call sequences, and missing security checks. For example, code that directly receives the `user_input` parameter from the frontend and passes it to a database query function without filtering it constitutes an unverified data stream. Another example is a series of consecutive calls to functions like `exec` and `eval`, which constitute a dangerous function call sequence. Standardized pattern encoding maps these patterns to fixed strings; for example, unverified data streams correspond to the code `CODE-PATTERN-001`, and dangerous function call sequences correspond to the code `CODE-PATTERN-002`.

[0050] This step transforms complex code logic into standardized features that can be recognized by machines, solving the matching problem of different syntactic expressions but consistent defect patterns.

[0051] Next, based on the vulnerability type identifier and the code context data, it is necessary to infer the possible remediation scheme types for this vulnerability type, which will serve as the remediation features; the remediation scheme types include at least adding parameter validation, replacing with a secure function, and adjusting security configuration; That is, by combining the vulnerability type identifier of the alert with code context data, we can infer the most likely type of remediation solution for that type of vulnerability and use it as a remediation feature.

[0052] The remediation solutions include adding parameter validation, replacing with secure functions, and adjusting security configurations. For example, if the vulnerability type is identified as CWE-89 SQL injection vulnerability, and the code context reveals that it is caused by unvalidated parameters, the corresponding remediation solution is to add parameter validation. Similarly, if the vulnerability type is identified as CWE-78 command injection vulnerability, the corresponding remediation solution is to replace with a secure function, specifically replacing `os.system` with the more secure `subprocess.run` and enabling parameterized calls.

[0053] This step incorporates semantic information from repair experience, allowing subsequent matching to compare not only code similarity but also the relevance of repair solutions.

[0054] Then, it is necessary to capture the environmental state information when the alarm is generated. As the environmental characteristics, the environmental state information includes at least the name and version of the reporting tool, the code commit hash of the project at the time of the alarm, and the version number of the key dependency library. This involves capturing the system environment and project status information at the moment the alarm is generated, using this as an environmental characteristic.

[0055] The environment status information includes the name and version of the reporting tool, the code commit hash of the project at the time of the alert, and the version numbers of critical dependency libraries. For example, the name and version of the reporting tool could be SonarQube 9.9, the code commit hash could be a1b2c3d4e5f67890abcdef1234567890abcdefab, and the version number of critical dependency libraries could be Spring-Boot 2.7.5.

[0056] The environmental features obtained in this step can distinguish the same defect patterns under different detection tools and different code versions, thus improving the accuracy of matching.

[0057] Furthermore, the extracted code pattern features, repair features, and environmental features need to be combined according to preset weights to form the alarm fingerprint.

[0058] This involves assigning preset weights to code pattern features, repair features, and environment features. The three types of features are then combined according to their weight ratios to generate a unique alert fingerprint.

[0059] The preset weights can be set according to the importance of features in defect judgment. For example, the weight of code pattern features can be set to 60%, the weight of repair features to 25%, and the weight of environmental features to 15%. CODE-PATTERN-001|FIX-TYPE-001|SONARQUBE-9.9-a1b2c3d-SPRINGBOOT-2.7.5|60-25-15 is a complete alarm fingerprint example.

[0060] This step can form a feature set containing multi-dimensional information, so that subsequent multi-level matching has a comprehensive and accurate comparison benchmark.

[0061] In step S300 of this embodiment, the alarm fingerprint of each alarm is matched with a preset repair context fingerprint database at multiple levels, including: Perform first-level exact match: Calculate the similarity between the code pattern features in the alarm fingerprint and the code pattern features of any record in the repair context fingerprint database. If the similarity is higher than a first preset threshold and the location information is less than a preset distance from the historical vulnerability location associated with the record, it is determined to be an exact match, and a first-level match confidence score is assigned. Perform second-level similarity matching: If no exact match is achieved, extract the similarity. If the similarity is between the second preset threshold and the first preset threshold, it is determined to be a similar match, and the second-level matching confidence level is calculated based on the similarity value. Perform third-level tool history matching: If the first two levels fail to match, query the repair context fingerprint database to see if there is a record reported by the same reporting tool on the same trigger file path and with the same vulnerability type identifier. If it exists and the record is marked as a historical false alarm, it is determined to be a tool history match, and the third-level matching confidence is calculated based on the number of times the historical false alarm is confirmed.

[0062] In this embodiment, the purpose of step S300 is to accurately compare the new alarm fingerprint with historical vulnerability instances in the repair context fingerprint database through a three-level progressive matching logic. This achieves both high-confidence accurate matching and coverage of similar patterns and historical false alarm scenarios, providing hierarchical matching results and confidence levels for subsequent alarm classification, thus solving the problems of single matching dimensions and high false alarm rates in existing technologies.

[0063] To achieve the above objectives, it is first necessary to obtain a preset repair context fingerprint database.

[0064] In step S300 of this application embodiment, the method for constructing the preset repair context fingerprint database includes: Monitor the commit history of the version control system and identify fix commits whose description information contains preset security keywords, which include at least fix, vulnerability, CVE, and security; Extract the code change differences from the fix submission; Feature extraction is performed on the code change differences to generate a repair context fingerprint, which includes the vulnerability code pattern characteristics before repair, the repair characteristics implemented, and the environmental characteristics at the time of submission. The repair context fingerprint, along with the corresponding submission hash, vulnerability type, and repair time, is stored together as a historical vulnerability instance to form the initial record of the repair context fingerprint database.

[0065] In step S300 of this application embodiment, the preset repair context fingerprint library can extract standardized features from the actual repair submissions of the project, providing a reliable historical benchmark for multi-level matching of new alerts, and solving the problem that the conclusions are unreliable due to the reliance on noisy historical alert libraries in the prior art.

[0066] To obtain the repair context fingerprint database, the first step is to monitor the commit history of the version control system and identify repair commits whose description information contains preset security keywords. The security keywords include at least repair, vulnerability, CVE, and security. This involves integrating with version control systems such as Git and SVN to monitor code commit history in real time. Commit records containing preset security keywords in their descriptions are then identified as fix commits.

[0067] For example, the preset security keywords include fix, vulnerability, CVE, and security. For instance, if the submission description is "Fix the SQL injection vulnerability CVE-2025-1234 in the user login interface", this record will be recognized as a fix submission.

[0068] This step ensures that all records entered into the database come from genuine security repair operations, guaranteeing the authority of the fingerprint database.

[0069] The second step is to extract the code change differences in the fix submission; This involves extracting the corresponding code changes from the version control system for each identified fix commit. Specifically, it compares the code files before and after the fix to obtain information on added, deleted, and modified lines of code.

[0070] For example, fixing the code change differences in the submissions involves removing the dangerous function call exec(user_input) and adding parameterized query code using preparedStatement.

[0071] This step obtains the specific code changes corresponding to the repair action, providing raw materials for subsequent feature extraction.

[0072] The third step is to extract features from the code change differences to generate a repair context fingerprint. The repair context fingerprint includes the vulnerability code pattern features before the repair, the repair features implemented, and the environmental features at the time of submission. Based on the extracted code change differences, three core features are extracted: the vulnerability code pattern characteristics before the fix, the fix characteristics implemented, and the environmental characteristics at the time of submission. These three features are then integrated to generate a fix context fingerprint.

[0073] For example, a fix context fingerprint includes the vulnerability code pattern characteristics before the fix, the implemented fix characteristics, and the environment characteristics at the time of submission. The vulnerability code pattern characteristics before the fix could be the encoding of an unverified data stream, such as CODE-PATTERN-001. The implemented fix characteristics could be adding parameter validation. The environment characteristics at the time of submission could be the reporting tool Fortify 2023, the code submission hash f7g8h9i0j1k2l3m4n5o6p7, and the dependency library version MyBatis 3.5.13.

[0074] This step transforms code changes into a standardized, comparable feature format, adapting it to subsequent matching logic.

[0075] The fourth step is to store the repair context fingerprint along with the corresponding submission hash, vulnerability type, and repair time as historical vulnerability instances to form the initial record of the repair context fingerprint database.

[0076] The generated remediation context fingerprint will be bound to the corresponding commit hash, vulnerability type, and remediation time. This fingerprint will be stored in the database as a historical vulnerability instance, and multiple instances will be aggregated to form the initial record of the remediation context fingerprint database.

[0077] Key parameters and examples: A complete initial record includes: Repair context fingerprint CODE-PATTERN-001|FIX-TYPE-001|FORTIFY-2023-f7g8h9-MYBATIS-3.5.13, Submission hash f7g8h9i0j1k2l3m4n5o6p7, Vulnerability type CWE-89 SQL injection, Repair time 2025-05-20 14:30:00.

[0078] This step establishes the final structured fingerprint database, providing a traceable historical basis for matching new alerts.

[0079] Furthermore, it is necessary to perform multi-level matching between the alarm fingerprint of each alarm and the preset repair context fingerprint database.

[0080] First, perform a first-level precise match: calculate the similarity between the code pattern features in the alarm fingerprint and the code pattern features of any record in the repair context fingerprint database. If the similarity is higher than a first preset threshold and the location information is less than a preset distance from the historical vulnerability location associated with the record, it is determined to be a precise match, and a first-level match confidence score is assigned. This involves extracting code pattern features from the new alert fingerprint and calculating the similarity between these features and the code pattern features of all historical vulnerabilities in the repair context fingerprint database. Simultaneously, the distance between the new alert location information and the historical vulnerability location is verified. Only when both conditions are met is it considered an exact match, and a first-level match confidence score is assigned.

[0081] For example, the first preset threshold can be set to 95%. The preset distance can be set to a range of 50 lines of code within the same file. For instance, the code pattern characteristic of a new alert is the dangerous function call sequence code CODE-PATTERN-002, which has a 99% similarity to a historical record in the fingerprint database. The new alert is located at line 120 of PayController.java, and the historical record is located at line 115 of the same file, with a line spacing of 5 lines (less than 50 lines). In this case, it is determined to be an exact match, and the first-level match confidence level can be assigned a value of 99.

[0082] The assignment of the first-level matching confidence score is based on the specific numerical value of the code pattern feature similarity. During operation, the similarity of the code pattern features between the new alert and the historical records is first calculated. Once it is confirmed that this value is higher than a first preset threshold and the positional distance is less than a preset distance, this similarity value is directly assigned to the first-level matching confidence score. For example, if the first preset threshold is set to 95% and the preset distance is set to 50 lines, and the new alert's code pattern similarity is 98% with a positional distance of 6 lines, then the first-level matching confidence score is assigned a value of 98.

[0083] This step accurately identifies recurring scenarios of patched vulnerabilities, where the vulnerability patterns and locations highly overlap with historical records.

[0084] Next, perform the second level of similarity matching: if no exact match is achieved, extract the similarity; if the similarity is between the second preset threshold and the first preset threshold, it is determined to be a similar match, and calculate the second level of matching confidence based on the similarity value. If the new alert does not meet the exact matching criteria, the code pattern feature similarity value calculated in the previous step is extracted. It is then determined whether this value falls between the second preset threshold and the first preset threshold. If the condition is met, it is considered a similar match, and the second-level matching confidence level is calculated based on the specific similarity value.

[0085] For example, the second preset threshold can be set to 70%. The first preset threshold remains at 95%. For instance, if the similarity between the new alarm code pattern and historical records is 82%, it falls within the 70% to 95% range. In this case, it is determined to be a similar match, and the second-level matching confidence level can be directly assigned a value of 82. The assignment principle for the second-level matching confidence level is the same as that for the first-level matching confidence level.

[0086] This step identifies scenarios that are similar to historical vulnerability patterns but have subtle differences; these scenarios are variants of the same type of vulnerability.

[0087] Then, perform the third-level tool history matching: if the first two levels fail to match, query the repair context fingerprint database to see if there is a record reported by the same reporting tool on the same trigger file path and with the same vulnerability type identifier. If there is, and the record is marked as a historical false alarm, it is determined to be a tool history matching, and the third-level matching confidence is calculated based on the number of times the historical false alarm is confirmed.

[0088] If the first two levels of matching fail, the three core query conditions are the reporting tool, the trigger file path, and the vulnerability type identifier. The system searches the remediation context fingerprint database for corresponding historical records. Records marked as historical false alarms are considered historical tool matches, and the third-level matching confidence level is calculated based on the number of confirmed historical false alarms.

[0089] Key parameters and examples: The query conditions must simultaneously meet all three dimensions. The reporting tool is Fortify 2023, the trigger file path is / src / main / java / com / example / project / PayController.java, and the vulnerability type identifier is CWE-78. Assume that the fingerprint database contains a historical record of this combination, and that this record has been confirmed as a false positive by a security engineer 8 times. The third-level matching confidence score can be assigned a value based on the number of historical false positives confirmed, for example, adding 10 points for each confirmed false positive, resulting in a final confidence score of 80.

[0090] This step filters out recurring false alarms generated by specific tools on fixed paths, reducing unnecessary analysis work for security engineers.

[0091] In step S400 of this embodiment, based on preset classification rules, the newly generated alarms are automatically classified according to the matching results and matching confidence levels to obtain classification results, including: A preset classification rule is provided, which sets a corresponding matching confidence threshold for each matching type. If the matching result is an exact match, and its first-level match confidence reaches or exceeds the recurrence confidence threshold, then the current alert will be classified as fixed-recurrence. If the matching result is a similar match, and its second-level match confidence reaches or exceeds the similar pattern confidence threshold, then the current alarm will be classified as fixed-similar pattern. If the matching result is a historical match of the tool, and its third-level matching confidence reaches or exceeds the false alarm pattern confidence threshold, then the current alarm will be classified as a historical false alarm pattern. If no matching results are generated, or if there are matching results but their matching confidence does not reach the corresponding threshold, the current alarm will be classified as a new alarm.

[0092] In this embodiment, the purpose of step S400 is to automatically categorize new alerts based on the matching results and matching confidence levels obtained from multi-level matching, combined with preset classification rules. It achieves accurate classification through quantitative threshold judgment, outputting clear alert categories to help security engineers quickly distinguish between vulnerability recurrence, similar patterns, historical false alarms, and entirely new alerts, thereby improving vulnerability handling efficiency.

[0093] To achieve the above objectives, it is first necessary to preset classification rules, which set a corresponding matching confidence threshold for each matching type. This involves setting a corresponding matching confidence threshold for each type of matching result, which serves as the criterion for alarm classification.

[0094] For example, the recurrence confidence threshold can be set to 90, the similarity pattern confidence threshold can be set to 70, and the false alarm pattern confidence threshold can be set to 80. This establishes quantifiable classification criteria and avoids classification bias caused by subjective judgment.

[0095] If the matching result is an exact match, and its first-level match confidence reaches or exceeds the recurrence confidence threshold, then the current alert will be classified as fixed-recurrence. This involves checking whether the matching result is an exact match. Simultaneously, it confirms whether the confidence level of the first-level match reaches or exceeds the relapse confidence threshold. If both conditions are met, the classification is "repaired-relapsed".

[0096] For example, the first-level match confidence level for exact matches is 98%, and the recurrence confidence threshold is 90. If 98 ≥ 90, the alert is classified as "fixed-recurring." This enables accurate identification of recurring fixed vulnerabilities.

[0097] If the matching result is a similar match, and its second-level match confidence reaches or exceeds the similar pattern confidence threshold, then the current alarm will be classified as fixed-similar pattern. This involves checking whether the matching result is a similar match. Simultaneously, it confirms whether the confidence level of the second-level match reaches or exceeds the similarity pattern confidence threshold. If both conditions are met, the pattern is classified as "repaired - similar pattern".

[0098] For example, if the confidence level of a second-level similar match is 82 and the confidence threshold for a similar pattern is 70, and 82 ≥ 70, the alert is classified as "Patched - Similar Pattern". This is to identify new variant vulnerabilities that are similar to historical vulnerability patterns.

[0099] If the matching result is a historical match of the tool, and its third-level matching confidence reaches or exceeds the false alarm pattern confidence threshold, then the current alarm will be classified as a historical false alarm pattern. This involves checking whether the matching result is a historical match from the tool's past data. Simultaneously, it confirms whether the confidence level of the third-level match reaches or exceeds the false alarm pattern confidence threshold. If both conditions are met, the match is classified as a historical false alarm pattern.

[0100] For example, if the confidence level of a third-level match in the tool's historical matching is 85 and the confidence threshold for a false alarm pattern is 80, and 85 ≥ 80, the alert is classified as a historical false alarm pattern. This allows for rapid filtering of recurring tool false alarms, reducing unnecessary analysis work.

[0101] If no matching results are generated, or if there are matching results but their matching confidence does not reach the corresponding threshold, the current alarm will be classified as a new alarm.

[0102] For example, if the confidence level of a second-level similarity match is 65 and the confidence threshold for a similar pattern is 70, and 65 < 70, the alert is classified as a brand new alert. This is to identify new types of vulnerabilities that have never appeared before, prompting security engineers to pay close attention.

[0103] In step S500 of this embodiment, based on the security engineer's confirmation feedback on the classification results, adaptive optimization is performed on the repair context fingerprint database and matching rules, including: Receive confirmation feedback from security engineers regarding the system's automatic classification results. The feedback includes at least confirmation of correctness, correction of classification, marking as a false alarm, and submission of associated repairs. The feedback is bound to the corresponding alarm data, the alarm fingerprint generated by the system, the matching result and the matching confidence level to form a tagged feedback sample and establish a feedback sample pool; Calculate the model perplexity value for each feedback sample; Periodically select the K samples with the highest model perplexity values ​​from the feedback sample pool to form a high-value training sample set; Using the high-value training sample set, a parameter configurator is trained based on machine learning. In subsequent alarm processing, for each new alarm, the parameter configurator is called to generate a set of dynamically optimized parameters in real time based on the alarm fingerprint features of the new alarm. The dynamically optimized parameters are used to replace the preset fixed parameters, and multi-level matching and classification decisions for the new alarm are performed. Repeat the above optimization process to form a continuously self-evolving, proactive learning loop.

[0104] In this embodiment, the purpose of step S500 is to construct a continuously self-evolving active learning closed loop based on human feedback from security engineers. It integrates manually verified knowledge into the system, dynamically optimizes and repairs the parameters of the context fingerprint database and matching rules, and improves the accuracy and adaptability of the model's subsequent alarm classification.

[0105] To achieve the above objectives, it is first necessary to receive confirmation feedback from security engineers regarding the system's automatic classification results. This feedback should include at least confirmation of correctness, correction of classification, marking as a false alarm, and submission of associated repairs. This involves collecting manual verification feedback from security engineers regarding the system's automatic classification results. Feedback includes various types to meet different optimization needs. These feedback types include at least confirmation of correctness, classification correction, marking as a false alarm, and associated remediation submission. For example, if an engineer determines that a recurring alarm classified as fixed is actually a brand new alarm, this feedback falls under the category of classification correction. This aims to provide authoritative, manually labeled data for system optimization.

[0106] Next, the feedback is bound to the corresponding alarm data, the alarm fingerprint generated by the system, the matching result and the matching confidence level to form a tagged feedback sample and establish a feedback sample pool; The engineer's feedback information is then linked to corresponding alarm data, system-generated alarm fingerprints, matching results, and matching confidence levels. This creates tagged feedback samples, and all samples are aggregated to build a feedback sample pool.

[0107] For example, a feedback sample contains the following information: feedback type is corrected classification, ALERT-20250521-003 CWE-79 is alarm data, alarm fingerprint is CODE-PATTERN-003|FIX-TYPE-002|SONARQUBE-9.9, matching result is exact match, and matching confidence is 92%. This is to accumulate labeled data that can be used for model learning.

[0108] Furthermore, it is necessary to calculate the model perplexity value for each feedback sample. In step S500 of this embodiment, calculating the model perplexity value for each feedback sample includes: the calculation of the model perplexity value is based on the degree of dispersion between the matching confidence levels of each level within the system during the previous matching and classification process, and the model perplexity value is positively correlated with the degree of dispersion.

[0109] This involves calculating the model perplexity value for each sample based on the degree of dispersion among the matching confidence levels within the system during the previous matching and classification process. The degree of dispersion is positively correlated with the perplexity value.

[0110] For example, a sample might have a first-level matching confidence score of 92 and a second-level score of 45, showing a high degree of dispersion between the two levels. This corresponds to a high model perplexity value, indicating significant uncertainty in the system's judgment of that sample. This allows for the selection of samples with high value for model optimization.

[0111] In practice, the process begins by extracting all confidence scores from the first, second, and third levels of matching for each sample. Then, the standard deviation or range of these scores is calculated to quantify their dispersion, thus measuring the degree of dispersion. For example, one sample might have confidence scores of 90, 10, and 5 for the three levels of matching, with a range of 85, indicating high dispersion. Another sample might have confidence scores of 85, 80, and 75 for the three levels of matching, with a range of 10, indicating low dispersion.

[0112] Furthermore, using the aforementioned high-value training sample set, a parameter configurator is trained based on machine learning. Specifically, this includes: For each high-value training sample, based on the confirmation feedback from the corresponding security engineer, a set of system parameters that enable the system to output a classification result consistent with the corresponding feedback under the corresponding state of the high-value training sample are derived in reverse. These system parameters are then used as the target parameter label for the high-value training sample. The alarm fingerprint features and system historical state features of the high-value training samples are used as input features and paired with the target parameter labels to form supervised learning training samples. Using the supervised learning training samples, a regression model is trained through a supervised learning algorithm to obtain the parameter configurator.

[0113] In this embodiment, the purpose of training the parameter configurator is to enable the system to learn to automatically adjust the matching rule parameters according to new alarm features, replacing fixed parameters and improving the accuracy and adaptability of subsequent classification decisions.

[0114] Specifically, the first step is to reverse-engineer a set of system parameters for each high-value training sample, based on the feedback confirmed by the corresponding security engineer. These system parameters will enable the system to output a classification result consistent with the corresponding feedback under the corresponding state of the high-value training sample. The system parameters will then be used as the target parameter label for that high-value training sample. For each high-value training sample, a set of system parameters is calculated backwards based on confirmation feedback from security engineers. These parameters should ensure that the system outputs a classification result consistent with human feedback under the corresponding state of the sample. This set of parameters is then used as the target parameter label for that sample.

[0115] For example, an engineer reported that a sample was misclassified as "repaired-relapsed," when it should actually be classified as a "new" alert. The original system's first preset threshold was 95%. Reverse engineering showed that adjusting the first preset threshold to 98% would result in correct classification. The adjusted first preset threshold of 98% is one of the target parameter labels for that sample, thus providing a precise parameter optimization target for model training.

[0116] The second step is to use the alarm fingerprint features and system historical state features of the high-value training samples as input features, and pair them with the target parameter labels to form supervised learning training samples. This involves extracting alarm fingerprint features and system historical state features from high-value training samples and using them as input features. These input features are then paired with corresponding target parameter labels to form supervised learning training samples.

[0117] For example, input features include the code pattern feature CODE-PATTERN-001 for alarm fingerprints, repair features with added parameter verification, and system historical state features detected by SonarQube 9.9. The target parameter labels are a first preset threshold of 98% and a second preset threshold of 72%. Pairing these labels together constitutes a complete supervised learning training sample, providing labeled, structured data for model training.

[0118] The third step involves using the supervised learning training samples to train a regression model using a supervised learning algorithm, thereby obtaining the parameter configurator.

[0119] The newly constructed supervised learning training samples are input into the supervised learning algorithm to train a regression model. The resulting model after training is the parameter configurator.

[0120] For example, supervised learning algorithms such as linear regression or gradient boosting trees can be selected as the regression model. The regression model uses input features as independent variables and target parameter labels as dependent variables. After iterative training, the parameter configurator can output the optimal matching parameters based on the features of the new alarm.

[0121] The specific training methods for similar regression models are existing technologies, and the implementation methods are not unique, so they will not be elaborated here.

[0122] In subsequent alarm processing, for each new alarm, the parameter configurator is invoked to generate a set of dynamically optimized parameters in real time based on the alarm fingerprint characteristics of the new alarm, and the dynamically optimized parameters are used to replace the preset fixed parameters, and multi-level matching and classification decisions for the new alarm are performed. When processing a new alarm, the alarm fingerprint features are first extracted. These features are then input into a parameter configurator, which generates a set of dynamically optimized parameters in real time. These dynamically optimized parameters replace the original preset fixed parameters, and then multi-level matching and classification decisions are performed.

[0123] For example, preset fixed parameters are: a first preset threshold of 95%, a second preset threshold of 70%, and a preset distance of 50 rows. A new alert fingerprint indicates it belongs to a vulnerability type with low false alarm risk. Based on this, the parameter configurator generates dynamically optimized parameters: the first preset threshold is adjusted to 90%, the second preset threshold to 65%, and the preset distance to 80 rows. The system uses these dynamically optimized parameters to complete the matching and classification.

[0124] Furthermore, the above optimization process is repeated to form a continuously self-evolving active learning closed loop.

[0125] After classifying a new alert, confirmation feedback from security engineers is collected. This feedback is then linked to relevant data, the model's perplexity value is calculated, and high-value samples are selected to train the parameter configurator. When processing new alerts subsequently, the updated parameter configurator is invoked again to generate dynamic parameters. This entire process is repeated, forming a continuously evolving, proactive learning loop.

[0126] For example, each optimization selects the K=200 samples with the highest perplexity values. Through multiple iterations, the parameter configurator continuously improves the accuracy of parameter adjustments for specific vulnerability types. This enables long-term iterative optimization of system capabilities without the need for manual rule adjustments.

[0127] Example 2, as Figure 2 As shown, based on the same inventive concept as the machine learning-based source code security defect prediction method provided in Embodiment 1, this embodiment of the invention also provides a machine learning-based source code security defect prediction system, including: The alarm data acquisition module 11 is used to acquire newly generated alarms, extract alarm-related data, and generate an alarm dataset, which includes vulnerability type, location information, and code context. The alarm fingerprint extraction module 12 is used to extract features from each alarm in the alarm dataset based on preset feature extraction rules to obtain the alarm fingerprint of each alarm, wherein the alarm fingerprint includes at least code pattern features, repair features and environmental features; The multi-level matching module 13 is used to perform multi-level matching of the alarm fingerprint of each alarm with the preset repair context fingerprint library to obtain the matching result and matching confidence of each alarm, wherein the repair context fingerprint library contains multiple confirmed and repaired historical vulnerability instances. The alarm automatic classification module 14 is used to automatically classify newly generated alarms based on preset classification rules, according to the matching results and matching confidence, and obtain classification results, wherein the classification results include at least fixed-recurrence, fixed-similar pattern, historical false alarm pattern and new alarm; The adaptive optimization module 15 is used to output the classification results and corresponding matching evidence, and to adaptively optimize the repair context fingerprint database and matching rules based on the security engineer's confirmation feedback on the classification results.

[0128] Furthermore, the alarm data acquisition module 11 includes the following execution steps: Receive raw alert streams from static application security testing tools and / or software composition analysis tools; The original alert stream is parsed, and the structured data of each alert is extracted. The structured data includes at least an alert identifier, a vulnerability type identifier, and location information, wherein the location information includes the trigger file path and the line number of the code. Based on the trigger file path and line number, the corresponding code fragment and adjacent code within a preset line number range are extracted from the version control system to form code context data; The structured data and the code context data are merged to generate the alert dataset.

[0129] Furthermore, the alarm fingerprint extraction module 12 includes the following execution steps: The code context data is analyzed to identify key code patterns related to security vulnerabilities, and these key code patterns are abstracted into standardized pattern codes as the code pattern features. The key code patterns include at least unverified data flows, dangerous function call sequences, and missing security checks. Based on the vulnerability type identifier and the code context data, possible remediation schemes for the vulnerability type are inferred as the remediation features; the remediation scheme types include at least adding parameter validation, replacing with secure functions, and adjusting security configurations. Capture environmental state information when an alert is generated, which is the environmental feature. The environmental state information includes at least the name and version of the reporting tool, the code commit hash of the project at the time of the alert, and the version number of the key dependency library. The extracted code pattern features, repair features, and environmental features are combined according to preset weights to form the alarm fingerprint.

[0130] Furthermore, the multi-level matching module 13 includes the following execution steps: Perform first-level exact match: Calculate the similarity between the code pattern features in the alarm fingerprint and the code pattern features of any record in the repair context fingerprint database. If the similarity is higher than a first preset threshold and the location information is less than a preset distance from the historical vulnerability location associated with the record, it is determined to be an exact match, and a first-level match confidence score is assigned. Perform second-level similarity matching: If no exact match is achieved, extract the similarity. If the similarity is between the second preset threshold and the first preset threshold, it is determined to be a similar match, and the second-level matching confidence level is calculated based on the similarity value. Perform third-level tool history matching: If the first two levels fail to match, query the repair context fingerprint database to see if there is a record reported by the same reporting tool on the same trigger file path and with the same vulnerability type identifier. If it exists and the record is marked as a historical false alarm, it is determined to be a tool history match, and the third-level matching confidence is calculated based on the number of times the historical false alarm is confirmed.

[0131] The steps for constructing the preset repair context fingerprint database include: Monitor the commit history of the version control system and identify fix commits whose description information contains preset security keywords, which include at least fix, vulnerability, CVE, and security; Extract the code change differences from the fix submission; Feature extraction is performed on the code change differences to generate a repair context fingerprint, which includes the vulnerability code pattern characteristics before repair, the repair characteristics implemented, and the environmental characteristics at the time of submission. The repair context fingerprint, along with the corresponding submission hash, vulnerability type, and repair time, is stored together as a historical vulnerability instance to form the initial record of the repair context fingerprint database.

[0132] Furthermore, the alarm automatic classification module 14 includes the following execution steps: A preset classification rule is provided, which sets a corresponding matching confidence threshold for each matching type. If the matching result is an exact match, and its first-level match confidence reaches or exceeds the recurrence confidence threshold, then the current alert will be classified as fixed-recurrence. If the matching result is a similar match, and its second-level match confidence reaches or exceeds the similar pattern confidence threshold, then the current alarm will be classified as fixed-similar pattern. If the matching result is a historical match of the tool, and its third-level matching confidence reaches or exceeds the false alarm pattern confidence threshold, then the current alarm will be classified as a historical false alarm pattern. If no matching results are generated, or if there are matching results but their matching confidence does not reach the corresponding threshold, the current alarm will be classified as a new alarm.

[0133] Furthermore, the adaptive optimization module 15 includes the following execution steps: Receive confirmation feedback from security engineers regarding the system's automatic classification results. The feedback includes at least confirmation of correctness, correction of classification, marking as a false alarm, and submission of associated repairs. The feedback is bound to the corresponding alarm data, the alarm fingerprint generated by the system, the matching result and the matching confidence level to form a tagged feedback sample and establish a feedback sample pool; Calculate the model perplexity value for each feedback sample; Periodically select the K samples with the highest model perplexity values ​​from the feedback sample pool to form a high-value training sample set; Using the aforementioned high-value training sample set, a parameter configurator is trained based on machine learning. In subsequent alarm processing, for each new alarm, the parameter configurator is invoked to generate a set of dynamically optimized parameters in real time based on the alarm fingerprint characteristics of the new alarm, and the dynamically optimized parameters are used to replace the preset fixed parameters, and multi-level matching and classification decisions for the new alarm are performed. Repeat the above optimization process to form a continuously self-evolving, proactive learning loop.

[0134] The calculation of the model perplexity value for each feedback sample includes: the calculation of the model perplexity value is based on the degree of dispersion between the matching confidence of each level within the system during the previous matching and classification process of the feedback sample, and the model perplexity value is positively correlated with the degree of dispersion.

[0135] Among them, a parameter configurator is trained based on machine learning, including: For each high-value training sample, based on the confirmation feedback from the corresponding security engineer, a set of system parameters that enable the system to output a classification result consistent with the corresponding feedback under the corresponding state of the high-value training sample are derived in reverse. These system parameters are then used as the target parameter label for the high-value training sample. The alarm fingerprint features and system historical state features of the high-value training samples are used as input features and paired with the target parameter labels to form supervised learning training samples. Using the supervised learning training samples, a regression model is trained through a supervised learning algorithm to obtain the parameter configurator.

[0136] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A source code security defect prediction method based on machine learning, characterized in that, include: Acquire newly generated alerts, extract alert-related data, and generate an alert dataset, which includes vulnerability type, location information, and code context; Based on preset feature extraction rules, feature extraction is performed on each alarm in the alarm dataset to obtain an alarm fingerprint for each alarm, wherein the alarm fingerprint includes at least code pattern features, repair features and environmental features; The alarm fingerprint of each alarm is matched with a preset repair context fingerprint database at multiple levels to obtain the matching result and matching confidence level of each alarm. The repair context fingerprint database contains multiple historical vulnerability instances that have been confirmed and repaired. Based on preset classification rules, the newly generated alarms are automatically classified according to the matching results and matching confidence level to obtain classification results, wherein the classification results include at least fixed-recurrence, fixed-similar pattern, historical false alarm pattern and new alarm; The classification results and corresponding matching evidence are output, and the repair context fingerprint database and matching rules are adaptively optimized based on the security engineer's confirmation feedback on the classification results.

2. The source code security defect prediction method based on machine learning according to claim 1, characterized in that, Retrieve newly generated alerts, extract alert correlation data, and generate an alert dataset, including: Receive raw alert streams from static application security testing tools and / or software composition analysis tools; The original alert stream is parsed, and the structured data of each alert is extracted. The structured data includes at least an alert identifier, a vulnerability type identifier, and location information, wherein the location information includes the trigger file path and the line number of the code. Based on the trigger file path and line number, the corresponding code fragment and adjacent code within a preset line number range are extracted from the version control system to form code context data; The structured data and the code context data are merged to generate the alert dataset.

3. The source code security defect prediction method based on machine learning according to claim 2, characterized in that, Based on preset feature extraction rules, feature extraction is performed on each alarm in the alarm dataset to obtain an alarm fingerprint for each alarm, including: The code context data is analyzed to identify key code patterns related to security vulnerabilities, and these key code patterns are abstracted into standardized pattern codes as the code pattern features. The key code patterns include at least unverified data flows, dangerous function call sequences, and missing security checks. Based on the vulnerability type identifier and the code context data, possible remediation schemes for the vulnerability type are inferred as the remediation features; the remediation scheme types include at least adding parameter validation, replacing with secure functions, and adjusting security configurations. Capture environmental state information when an alert is generated, which is the environmental feature. The environmental state information includes at least the name and version of the reporting tool, the code commit hash of the project at the time of the alert, and the version number of the key dependency library. The extracted code pattern features, repair features, and environmental features are combined according to preset weights to form the alarm fingerprint.

4. The source code security defect prediction method based on machine learning according to claim 3, characterized in that, The alarm fingerprint of each alarm is matched against a pre-defined repair context fingerprint database at multiple levels, including: Perform first-level exact match: Calculate the similarity between the code pattern features in the alarm fingerprint and the code pattern features of any record in the repair context fingerprint database. If the similarity is higher than a first preset threshold and the location information is less than a preset distance from the historical vulnerability location associated with the record, it is determined to be an exact match, and a first-level match confidence score is assigned. Perform second-level similarity matching: If no exact match is achieved, extract the similarity. If the similarity is between the second preset threshold and the first preset threshold, it is determined to be a similar match, and the second-level matching confidence level is calculated based on the similarity value. Perform third-level tool history matching: If the first two levels fail to match, query the repair context fingerprint database to see if there is a record reported by the same reporting tool on the same trigger file path and with the same vulnerability type identifier. If it exists and the record is marked as a historical false alarm, it is determined to be a tool history match, and the third-level matching confidence is calculated based on the number of times the historical false alarm is confirmed.

5. The source code security defect prediction method based on machine learning according to claim 1, characterized in that, The method for constructing the preset repair context fingerprint database includes: Monitor the commit history of the version control system and identify fix commits whose description information contains preset security keywords, which include at least fix, vulnerability, CVE, and security; Extract the code change differences from the fix submission; Feature extraction is performed on the code change differences to generate a repair context fingerprint, which includes the vulnerability code pattern characteristics before repair, the repair characteristics implemented, and the environmental characteristics at the time of submission. The repair context fingerprint, along with the corresponding submission hash, vulnerability type, and repair time, is stored together as a historical vulnerability instance to form the initial record of the repair context fingerprint database.

6. The source code security defect prediction method based on machine learning according to claim 1, characterized in that, Based on preset classification rules, and according to the matching results and matching confidence levels, newly generated alarms are automatically classified to obtain classification results, including: A preset classification rule is provided, which sets a corresponding matching confidence threshold for each matching type. If the matching result is an exact match, and its first-level match confidence reaches or exceeds the recurrence confidence threshold, then the current alert will be classified as fixed-recurrence. If the matching result is a similar match, and its second-level match confidence reaches or exceeds the similar pattern confidence threshold, then the current alarm will be classified as fixed-similar pattern. If the matching result is a historical match of the tool, and its third-level matching confidence reaches or exceeds the false alarm pattern confidence threshold, then the current alarm will be classified as a historical false alarm pattern. If no matching results are generated, or if there are matching results but their matching confidence does not reach the corresponding threshold, the current alarm will be classified as a new alarm.

7. The source code security defect prediction method based on machine learning according to claim 1, characterized in that, Based on the security engineers' confirmation of the classification results, the remediation context fingerprint database and matching rules are adaptively optimized, including: Receive confirmation feedback from security engineers regarding the system's automatic classification results. The feedback includes at least confirmation of correctness, correction of classification, marking as a false alarm, and submission of associated repairs. The feedback is bound to the corresponding alarm data, the alarm fingerprint generated by the system, the matching result and the matching confidence level to form a tagged feedback sample and establish a feedback sample pool; Calculate the model perplexity value for each feedback sample; Periodically select the K samples with the highest model perplexity values ​​from the feedback sample pool to form a high-value training sample set; Using the high-value training sample set, a parameter configurator is trained based on machine learning. In subsequent alarm processing, for each new alarm, the parameter configurator is called to generate a set of dynamically optimized parameters in real time based on the alarm fingerprint features of the new alarm. The dynamically optimized parameters are used to replace the preset fixed parameters, and multi-level matching and classification decisions for the new alarm are performed. Repeat the above optimization process to form a continuously self-evolving, proactive learning loop.

8. The source code security defect prediction method based on machine learning according to claim 7, characterized in that, Calculating the model perplexity value for each feedback sample includes: the model perplexity value is calculated based on the degree of dispersion between the matching confidence levels of each level within the system during the previous matching and classification process of the feedback sample, and the model perplexity value is positively correlated with the degree of dispersion.

9. The source code security defect prediction method based on machine learning according to claim 7, characterized in that, Train a parameter configurator based on machine learning, including: For each high-value training sample, based on the confirmation feedback from the corresponding security engineer, a set of system parameters that enable the system to output a classification result consistent with the corresponding feedback under the corresponding state of the high-value training sample are derived in reverse. These system parameters are then used as the target parameter label for the high-value training sample. The alarm fingerprint features and system historical state features of the high-value training samples are used as input features and paired with the target parameter labels to form supervised learning training samples. Using the supervised learning training samples, a regression model is trained through a supervised learning algorithm to obtain the parameter configurator.

10. A source code security defect prediction system based on machine learning, characterized in that, The system is used to implement the machine learning-based source code security defect prediction method as described in any one of claims 1-9, including: The alarm data acquisition module is used to acquire newly generated alarms, extract alarm-related data, and generate an alarm dataset, which includes vulnerability type, location information, and code context. The alarm fingerprint extraction module is used to extract features from each alarm in the alarm dataset based on preset feature extraction rules to obtain the alarm fingerprint of each alarm, wherein the alarm fingerprint includes at least code pattern features, repair features and environmental features; The multi-level matching module is used to perform multi-level matching of the alarm fingerprint of each alarm with the preset repair context fingerprint library to obtain the matching result and matching confidence of each alarm. The repair context fingerprint library contains multiple historical vulnerability instances that have been confirmed and repaired. An automatic alarm classification module is used to automatically classify newly generated alarms based on preset classification rules, according to the matching results and matching confidence, and obtain classification results, wherein the classification results include at least fixed-recurrence, fixed-similar patterns, historical false alarm patterns and new alarms; The adaptive optimization module is used to output the classification results and corresponding matching evidence, and to adaptively optimize the repair context fingerprint database and matching rules based on the security engineer's confirmation feedback on the classification results.

Images