Unsupervised malicious code detection method and system for predicting cohesion change based on function name

Abstract

The invention provides an unsupervised malicious code detection method and an unsupervised malicious code detection system for predicting cohesion change based on a function name. The unsupervised malicious code detection method and the unsupervised malicious code detection system are used for solving the problems that existing malicious code detection depends on a large amount of labeled data and the detection capability is insufficient in the face of unknown variants. According to the method, function name prediction serves as an index for measuring function cohesion, a function name is predicted through a pre-training code language model under the condition that the function name is covered, the cohesion of name prediction is calculated, and changes of cohesion values before and after function updating are compared. And if the reduction of the cohesion exceeds a threshold value, judging that malicious code injection suspicion exists and giving an alarm. According to the method, unknown malicious code variants can be detected without depending on a malicious code feature library, so that the detection capability on novel threats is improved; and the used indexes can reflect the semantic consistency of the codes, have universality for different items and coding styles, and are not easily bypassed by code obfuscation means, so that abnormal modifications in the source codes can be found in time.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of software security, and specifically provides a function name prediction cohesion change-based unsupervised malicious code detection method and system, which identifies abnormal modifications in source code by predicting the cohesion change (Name-Prediction-based Cohesion, NPC) of function names. BACKGROUND

[0002] In today's software-driven world, ensuring the safety and reliability of software systems has become a key challenge. Traditional detection methods mainly rely on rule-based methods and machine learning-driven static or dynamic code analysis techniques, but these methods are heavily dependent on known malicious code features, behavior patterns, or supervised models that require labeled data sets. As attackers constantly adjust their strategies and use sophisticated anti-analysis techniques to evade detection, there is an urgent need for an unsupervised method that can identify subtle abnormalities without prior knowledge of malicious patterns.

[0003] Software code cohesion is a measure of the degree of cooperation among elements within a module to complete a certain function. High cohesion usually means that the module has a single responsibility and is easy to maintain, while low cohesion may indicate that the module contains unrelated or scattered functions. Malicious code injection often adds unrelated malicious logic to otherwise cohesive functions, disrupting the degree of cooperation among elements within the function around the naming purpose. Therefore, monitoring abnormal fluctuations in code cohesion can serve as a clue for unsupervised detection of malicious tampering. SUMMARY

[0004] To address the shortcomings of existing malicious code detection methods that generally rely on large amounts of labeled data and lack the ability to detect unknown malicious code variants, the present application proposes a function name prediction cohesion change-based unsupervised malicious code detection method and system. By using a pre-trained model to analyze function code name prediction, the function name prediction cohesion NPC indicator is extracted, and the NPC value changes between different versions of the function are compared to identify abnormal code injection behavior. This method can detect potential threats without the need for a malicious code feature library or sample training.

[0005] To achieve the above-mentioned purposes, the present application adopts the following technical solutions:

[0006] A function name prediction cohesion change-based unsupervised malicious code detection method, comprising the following steps:

[0007] Step 1: Obtain the source code and version evolution information of the target software, identify the function-level code changes therein, and extract the code of the original version and the updated version for each changed function to form a pair of function versions for analysis;

[0008] Step 2: Based on the version function information obtained in Step 1, use a pre-trained code language model to perform function name mask prediction analysis on each function code in the function version pair, and calculate the name prediction cohesion value and the corresponding optimal name length for each function version.

[0009] The aforementioned function name mask prediction analysis includes: replacing the name identifiers in the function definition with placeholders, retaining only the function's parameter list and function body as model input. The pre-trained code language model generates prediction results for the function name and probability values ​​for each predicted identifier based on the input function code.

[0010] The pre-trained code language model makes multiple predictions for different assumed function name lengths, outputting a series of name identifiers of length n (n is a preset positive integer range) and their corresponding probabilities. The name prediction confidence of the n identifier sequences is calculated, where the harmonic mean of the probabilities of each identifier is used as the confidence value. Specifically, this includes the following:

[0011] Given a function ƒ, the model receives the input and generates a prediction of the function name and its probability distribution. To quantify the accuracy of the model's prediction of function names, this invention employs a token fusion strategy: assuming the function name has a length of n, the model predicts the function name composed of n identifiers and obtains the probability of each predicted identifier. The confidence level for name prediction at this length is obtained by calculating the harmonic average of these probabilities, as shown in the following formula:

[0012]

[0013] in, This represents the probability of the i-th name identifier predicted by the model. The harmonic mean penalizes identifiers with low probabilities, assigning a greater weight to identifiers with even lower probabilities. Any mismatch in any candidate name significantly reduces the overall confidence, ensuring that this metric reflects a consistent confidence level across all predicted tokens.

[0014] Using the above method, a corresponding confidence score can be calculated for each possible function name length n=1,2,...,8 (covering the typical length range of function names in practical applications).

[0015] Next, for each function version, the name prediction confidence value under different name lengths is calculated, and the largest one is selected as the name prediction cohesion value for that function version. Simultaneously, the name length that maximizes the confidence value is determined as the optimal name length for that function version. Specifically, this includes the following:

[0016] The maximum value among these confidence scores is taken as the name of the function to predict the cohesion NPC value, as shown in the following formula:

[0017]

[0018] The maximum prediction confidence score for different name lengths is taken to obtain the name prediction cohesion (NPC) of the function. The NPC value ranges from 0 to 1; a higher value indicates that the model can more accurately generate names that conform to the function's logic, and the stronger the function's cohesion. Simultaneously, the name length that maximizes the confidence score is recorded as the optimal token number (OTC) for this function. The NPC value can be represented as:

[0019]

[0020] The difference between the NPC value of the function before and after the update is calculated using the pre-trained model, thereby quantifying the impact of code changes on the cohesion of the function.

[0021] Step 3: After obtaining the predicted cohesion value and optimal name length from Step 2, compare the predicted name cohesion values ​​of the updated version and the original version of the same function, calculate a quantitative indicator of cohesion change, and compare this indicator with a preset threshold to determine whether the cohesion change of the function is abnormal. Specifically, this invention defines two metrics to compare the cohesion differences between function versions: Cohension Difference (CD; defined as the predicted name cohesion value of the updated version minus the predicted name cohesion value of the corresponding original version) and Token Optimal Token Count Fifference (OTCD; defined as the difference obtained by calculating the name prediction confidence value of the updated function under the optimal name length of the original function version and subtracting the predicted name cohesion value of the original function). These two metrics reflect the degree of drift in the overall cohesion of the function and the degree of deviation from the original semantic intent, respectively, as shown in the following formula:

[0022]

[0023]

[0024] Among them, CD measures the difference in NPC (Non-Native Name Length) of the function before and after the update, reflecting the overall cohesion drift. OTCD measures the semantic deviation of the updated function from the optimal name length of the original function, highlighting the damage to the semantic intent of the original function caused by malicious modifications. When both metrics are positive, it indicates that the function's cohesion has decreased after the update, and there is a high possibility of anomalous injection; when both values ​​are negative, it indicates that the cohesion has increased after the update, and the function may have undergone normal refactoring or optimization to improve code quality. If the difference is close to zero, it means that the function's cohesion has been largely unaffected.

[0025] Step 4: Process the abnormal result values ​​obtained in Step 3. If the change exceeds a threshold, mark the function version as suspicious and generate a security alert; if it does not exceed the threshold, record the change as normal. Based on the quantified value of the cohesion change mentioned above, this invention pre-sets a threshold for judging cohesion changes. When the cohesion difference or the optimal name length confidence difference is greater than the preset threshold, it is determined that the cohesion of the function update is abnormally decreasing, indicating a suspicion of malicious code injection, triggering the generation of a security alert containing the function identifier, version information, and abnormal indicator values; when the difference does not exceed the threshold, it is considered a normal update and no alert is triggered, only the relevant information of the update is recorded in the system log. Specifically, this includes the following:

[0026] When the CD or OTCD of a function exceeds the threshold, the cohesion of the function is considered to have decreased beyond the normal evolution range, and there is suspicion of malicious code injection; otherwise, it is considered a normal change.

[0027] The threshold can be determined based on statistical data of historical normal function version evolution. By statistically analyzing the distribution characteristics of NPC differences between versions of a large number of functions during normal maintenance, a threshold higher than a certain confidence interval is selected. The threshold is often set by adding a preset multiple of the standard deviation of the distribution mean of cohesion changes under normal evolution, or by selecting a quantile threshold. This ensures that the threshold is higher than the fluctuation range of most normal changes, thereby reducing the false alarm rate.

[0028] The threshold is adaptively adjusted based on the initial cohesion level of different functions, including:

[0029] Strategy 1: Predict the cohesion of the original function in advance according to its name, divide the function into multiple intervals, and calculate the average and standard deviation of the cohesion difference of the normal function update and the confidence difference of the optimal name length in each interval;

[0030] Strategy 2: Subtract the mean of the interval to which a specific function updates the actual difference, and then divide by the standard deviation of that interval to obtain the standardized cohesion difference and the standardized optimal name length difference. Determine anomalies based on whether the standardized difference exceeds a preset threshold, thereby improving the consistency of threshold determination under different initial cohesion levels.

[0031] The malicious code detection method of the present invention is integrated into the continuous integration process of software version control, automatically performing the above operations for each code submission; and dynamically updating the threshold or model parameters based on the accumulated normal and abnormal detection samples to improve the adaptability and accuracy of detection.

[0032] In one embodiment, the average CD of normal function modifications is approximately 0.0005, while the minimum CD after malicious code injection is approximately 0.027. Therefore, a threshold of approximately 0.02 can be selected, between the two, so that normal changes rarely trigger alarms, while the significant decrease in cohesion caused by malicious injection can be detected.

[0033] If the detected change in the cohesion of a function exceeds the threshold, the method of the present invention will mark the function version as suspicious and output security alarm information through the alarm module, including detailed information such as the affected function identifier, the time of occurrence, and abnormal indicator values;

[0034] Function updates that do not exceed the threshold will not generate alerts or will be recorded as normal changes in the log. Security personnel will then conduct in-depth reviews of suspicious functions to confirm the presence of malicious code injection and take appropriate countermeasures.

[0035] Corresponding to the above method, this invention also provides a malicious code detection system, including: an input module, a function extraction module, a model inference module, a cohesion analysis module, and an alarm module. The input module is used to receive software source code and its version update information; the function extraction module is used to parse the source code and extract function definitions, pairing them to obtain the original and updated versions of the functions; the model inference module has a built-in pre-trained code language model, used to perform namemask prediction to calculate the NPC value of the function code; the cohesion analysis module is used to calculate the NPC difference (CD and OTCD) of the function version pairs and compare it with a preset threshold to determine whether it is abnormal; the alarm module is used to generate and output alarms when an anomaly is determined. The modules of this system work together to achieve the automatic execution of the above-mentioned unsupervised malicious code detection method.

[0036] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0037] This invention utilizes function name prediction cohesion as a detection metric, enabling the discovery of potential malicious code tampering without relying on malware sample libraries and feature rules. It offers the following advantages: Compared to traditional supervised learning methods that require manually labeled samples, this invention detects anomalies by autonomously measuring changes in code cohesion, enabling the detection of unknown malware variants and supply chain attacks, thus improving the ability to detect novel threats. The NPC (Performance-Negative) metric captures semantic consistency, essentially reflecting the quality and integrity of function code. Its changes are primarily caused by functional logic variations, thus possessing universality across different projects and coding styles, making it difficult for attackers to bypass through simple code obfuscation. Experimental analysis shows that the higher the initial cohesion of a function, the more significant the decrease in NPC caused by malicious injection, making it easier to detect. Attached Figure Description

[0038] Figure 1 This is a schematic diagram of the composition framework of the malicious code detection system of the present invention.

[0039] Figure 2 This is a flowchart illustrating the malicious code detection method of the present invention.

[0040] Figure 3 This diagram illustrates the distribution of confidence scores for function names across different token quantities.

[0041] Figure 4 A comparison of the confidence curves for predicting function names before and after malicious code injection.

[0042] Figure 5 Predict a histogram of the distribution of cohesion (NPC) scores on the function set for each function name.

[0043] Figure 6 Mean and standard deviation of name-predicted cohesion (NPC) under different function sizes. Detailed Implementation

[0044] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the described embodiments are only for explaining the present invention and do not constitute a limitation on the scope of the present invention. The processing flow of the method of the present invention includes the following steps:

[0045] The method of this invention can be integrated into a software configuration management system to automatically scan for each code change, such as... Figure 1 and 2 As shown, it includes:

[0046] Step S1: The input module obtains the source code and version information and transmits it to the function extraction module;

[0047] Step S2: The function extraction module parses the source code, extracts the functions and their different versions, and outputs the processing results to the model inference module;

[0048] Step S3: The model inference module loads the pre-trained code language model, performs name prediction analysis on each version of the function code, calculates the function name prediction cohesion NPC and the optimal number of tokens OTC, and transmits the results to the cohesion analysis module.

[0049] Step S4: The cohesion analysis module receives version pairs of the same function and their corresponding NPC and OTC values, calculates the quantitative index of cohesion change, and determines whether the function update is abnormal by combining it with a preset threshold. The determination result is then output to the alarm module.

[0050] Step S5: The alarm module outputs a security alarm or records a system log based on the anomaly determination result, thus completing the malicious code detection closed loop.

[0051] Before step S1, the system also includes system initialization and pre-configuration operations, and obtaining the latest commits or changesets of the source code from the version control system.

[0052] Step S2: When the function extraction module parses the source code, it extracts the functions and their different versions of code, and outputs the processing results to the model inference module. Specifically, this includes:

[0053] For each function, extract its current version code and the most recent version code before the change to form a function version pair for subsequent analysis.

[0054] In this way, you can obtain the code content of the function before and after the update, that is, the original function. and the updated function If the function is newly added and has no previous version, the detection can be skipped or the initial version of the function can be used as the baseline version. Compare them to assess their initial cohesion.

[0055] Step S3: The model inference module loads the pre-trained code language model, performs name prediction analysis on each version of the function code, calculates the function name prediction cohesion (NPC) and the optimal number of tokens (OTC), and transmits the results to the cohesion analysis module. Specifically, this includes:

[0056] The model inference module applies name prediction analytics to each function version to evaluate code cohesion. A pre-trained large-scale code language model is preferred for implementation. The specific steps are as follows:

[0057] Replace the name identifier in the function definition with a placeholder, keeping only the function's parameter list and function body code as model input. This forces the model to predict the function's name based on the function body content, thereby analyzing the fit between the function implementation and its name.

[0058] The masked function code is input into the pre-trained model, which generates predictions for the function name, including possible sequences of function nouns and the predicted probability of each word.

[0059] To measure the model's accuracy in naming the function, this invention predicts the possible lengths of names from 1 to 8. For each assumed name length n, the model outputs a name with n identifiers and their corresponding probabilities. Calculate the prediction confidence for the sequence of n identifiers. The harmonic mean probability formula described above is used for calculation:

[0060]

[0061] This metric comprehensively considers the probabilities of multiple predicted identifiers and imposes a greater penalty on any identifier with an extremely low probability, thus accurately reflecting the model's accuracy in predicting the entire name. For example, if the model predicts three identifiers with probabilities of 0.8, 0.7, and 0.9 when n=3, then... 0.79. Compared to a simple average, this definition means that even if one of the identifiers has a very low probability, the overall confidence level will drop significantly.

[0062] Calculations are different Confidence The maximum value is taken as the name of the function ƒ to predict cohesion. ,Right now:

[0063]

[0064] At the same time, let the maximum confidence level be reached. The optimal number of tokens for this function ,Right now:

[0065]

[0066] Step S4: The cohesion analysis module receives version pairs of the same function and their corresponding NPC and OTC values, calculates the cohesion change quantification index, and determines whether the function update is abnormal based on a preset threshold. The determination result is then output to the alarm module, specifically including:

[0067] For the original function version and the updated function version, the corresponding NPC values ​​can be obtained through step S3, and are denoted as follows: and The corresponding optimal number of tokens are OTC. and OTC .

[0068] Through the above process, each function version pair obtains a set of information reflecting its code cohesion:

[0069] (1) NPC values ​​and OTC in the original version (2) NPC values ​​and OTC in the updated version

[0070] The cohesion analysis module receives version pairs of the same function and their NPC measures, and further calculates quantitative indicators of cohesion changes to assess whether there are any anomalies in this code update. First, the cohesion difference CD is calculated: This is the difference between the NPC value of the function before and after the update. This difference directly reflects the degree of drift in the overall cohesion of the function after the update: the larger the value, the more significant the decrease in function cohesion. Further calculation is performed on the optimal token number difference (OTCD). Therefore, the optimal value of the original function is taken. number The name prediction confidence of the model is calculated on the updated function according to this name length. Then let in yes exist of The prediction confidence level is as follows; if ,express A decrease in confidence at the original optimal semantic length indicates a breach of semantic consistency; this metric measures the degree of deviation of the updated function from its original semantic name. Generally, CD directly reflects changes in overall cohesion, while OTCD can reveal the degree of anomaly in the updated function's original semantic name. Using both together can more comprehensively capture the structural and semantic cohesion changes caused by function updates.

[0071] The calculated CD and OTCD are compared with pre-set thresholds. To address the baseline bias issue where the CD or OTCD of high-cohesion functions evolve normally but is higher than that of low-cohesion functions, a standardized index is introduced:

[0072] Strategy 1: Divide all functions into multiple intervals based on their NPC values, and calculate the mean CD value for each interval. CD standard deviation OTCD mean OTCD standard deviation ;

[0073] Strategy 2: Perform standardized calculations:

[0074]

[0075]

[0076] By calculating the mean and variance of the NPC difference for historically unaltered function version pairs, the noise level of normal changes can be estimated.

[0077] If the CD or OTCD of a function update is significantly higher than the normal level, such as exceeding twice the standard deviation of the mean, then the update is considered to have caused an abnormal decrease in cohesion.

[0078] In practice, the CD (Cost-to-Die) of injected malicious code is often much higher than that of normal code evolution. Experimental statistics show that the average CD of naturally evolved function versions is approximately 0.0005, while the minimum CD of a function injected with malicious code reaches 0.027, significantly higher than the normal value.

[0079] Therefore, when selecting a threshold, it can be set slightly lower than the known minimum malicious CD to ensure that almost all malicious injections can be captured and normal changes do not trigger false positives. Similarly, the threshold for OTCD can also be selected based on the normally evolving OTCD distribution and the lowest OTCD after malicious injection. If the CD or OTCD exceeds the threshold, it is considered a positive result, and the function is considered to be... There is a possibility of malicious code injection; otherwise, it is considered a normal update.

[0080] Step S5: Based on the anomaly detection results, the alarm module outputs a security alarm or records a system log, completing the malicious code detection closed loop, specifically including:

[0081] When a function update anomaly is detected, the alarm module records and outputs alarm information, including the project name, function identifier, version information, timestamp, and the detected error. Values, etc.

[0082] Alerts can be sent to developers or security personnel via logs, console notifications, email notifications, etc. If an update is determined to be normal, no alert will be triggered; instead, the NPC changes associated with the update will be recorded in the system log for continuous learning of normal update thresholds or for future reference.

[0083] The system will be continuously integrated into the version control process of the code repository, automatically executing the above steps for each code commit to achieve continuous monitoring.

[0084] Over time, the system can adjust thresholds or model parameters based on collected normal and abnormal samples. For example, when it is found that some benign large-scale reconstruction operations also lead to high CD values, the threshold can be appropriately increased or more refined discrimination rules can be introduced to reduce the false alarm rate.

[0085] Conversely, if some malicious injections are detected but not detected by the threshold, the threshold can be lowered or auxiliary features can be added to improve sensitivity. This feedback mechanism can continuously optimize the detection strategy and enhance the system's adaptability.

[0086] To verify the effectiveness of the above method, this invention conducted extensive experimental evaluations using open-source code libraries. The detection process and performance of the method described below, based on key experimental results, are explained:

[0087] This invention first verifies that there generally exists an optimal name length for functions that maximizes the confidence of name prediction. For approximately 54,700 functions in the dataset, a pre-trained model was used to predict the confidence of name lengths from 1 to 8. The functions were then grouped according to their optimal number of tokens, and the average confidence curves for different groups were plotted as follows: Figure 3 As shown.

[0088] The results show that the confidence level peaks significantly at the number of tokens in each group, with both the average and quantile ranges reaching local maxima at the OTC level. This demonstrates that each function naturally tends towards names of a specific length to optimize its descriptiveness and predictability, supporting the hypothesis that an optimal name length exists for each function.

[0089] Next, malicious code is injected into each function to study the impact of malicious tampering on name prediction confidence. Specifically:

[0090] Insert an unrelated malicious code snippet into three typical locations within a function: the beginning of the function (immediately after the function declaration), the middle of the function (50% of the original code lines), and the end of the function (after all existing code). Ensure that the inserted code remains syntactically valid and does not affect the function's basic executability.

[0091] For each insertion location, the model is re-introduced to predict the name of the function after the malicious code is inserted, and the confidence curves for each name length are calculated. Figure 4 The comparison between the confidence scores of the original function code and those after malicious code injection is shown. It can be seen that after code injection, the overall prediction confidence of the model decreases, and the optimal name length for many functions tends to be one token, meaning that the model often can only confidently give a very short function name.

[0092] The introduction of malicious code disrupts the original logical consistency of a function, making it difficult for the model to match the initially meaningful, longer name, and forcing it to predict a more general, shorter name instead. This phenomenon demonstrates that malicious code injection alters the optimal name length of a function and reduces its cohesion.

[0093] To further quantitatively evaluate the impact of malicious code insertion on function cohesion, this invention uses the NPC difference index CD and OTCD defined above to compare and analyze the changes in cohesion of functions before and after injection. In the experiment, malicious code was injected into each function at the beginning, middle, and end, and the difference in NPC values ​​before and after injection was calculated. Then, the results at the three insertion positions were averaged.

[0094] Meanwhile, to establish a benchmark, the NPC changes of the same function across consecutive versions under normal maintenance were also statistically analyzed, i.e., under the condition of no malicious tampering. Table 1 summarizes the changes of the two indicators when malicious code is injected in different locations, as well as the changes between normal consecutive versions for comparison.

[0095] Table 1

[0096]

[0097] High cohesion function refers to a function with an original NPC > 0.5; "normal baseline" in the table refers to the index of adjacent versions of the same function, used to compare the magnitude of change under natural evolution; * indicates that the difference is statistically significant (P < 0.05) compared with the normal baseline.

[0098] As shown in Table 1, malicious code injection, whether occurring at the beginning, middle, or end of a function, leads to a significant decrease in cohesion across all functions: the average CD is between 0.027 and 0.040, the average OTCD is between 0.083 and 0.105, while the average CD of normal function version evolution is only about 0.0005, and the average OTCD is about 0.029, the latter being more than an order of magnitude lower than the former.

[0099] Statistical tests showed that the mean CD and OTCD after malicious injection were significantly higher than the normal baseline (P < 0.05), verifying the sensitivity of the indicators of this invention to abnormal modifications. Notably, for functions with high initial cohesion (NPC > 0.5), the impact of malicious code was more severe: their OTCD values ​​increased to 0.074–0.081, approximately twice that of normal functions, and their OTCD values ​​increased to 0.106–0.142, about 35% higher than normal functions. Especially when malicious code was inserted at the beginning of the function, the CD of high-cohesion functions reached 0.081, about 200% higher than the overall average, and the OTCD reached 0.142, about 35% higher than the overall average. This indicates that well-structured, highly cohesive code is more sensitive to malicious tampering, and injections performed in such functions are more easily identified by the method of this invention.

[0100] In summary, the results in Table 1 fully support the conclusion that malicious code insertion significantly reduces function cohesion, far exceeding the fluctuation range caused by normal maintenance and updates. Therefore, potential malicious tampering can be effectively detected by monitoring the abnormal increase of the two indicators, CD and OTCD.

[0101] Based on the quantitative analysis above, detection thresholds can be selected with greater confidence. For example, as shown in Table 1, for general functions, a CD threshold of around 0.02 is sufficient to distinguish normal evolution from the slightest malicious injection; while for high-cohesion functions, a slightly lower threshold can be considered to more sensitively capture small abnormal decreases. Combining the OTCD indicator can further reduce the false negative rate, because in some cases, malicious modifications may not significantly reduce the overall NPC, but they may deviate from the original naming pattern, i.e., OTC changes, and confidence decreases. Such OTCD will indicate abnormal deviations, even if CD may not exceed the threshold. Therefore, this invention preferably considers both CD and OTCD comprehensively, triggering an alarm once either indicator exceeds the threshold, to achieve more comprehensive and reliable detection.

[0102] This invention also examines the impact of function code size on the NPC index and its variation to verify the applicability of the method to functions of different complexities. Specifically, it includes:

[0103] Step 1: The NPC score distribution for all functions under the normal evolution condition was statistically analyzed. For example... Figure 5 As shown, the vast majority of functions maintain a high level of cohesion: approximately 63% of functions have an NPC greater than 0.5. This aligns with software engineering practices, where public open-source projects typically undergo code review and refactoring, resulting in most functions having a single responsibility and appropriate naming, thus leading to higher cohesion scores.

[0104] Step 2: Group the functions by length and calculate the mean NPC and standard deviation for each group. The results show that the mean NPC of functions of different sizes is very close, around 0.608, and the standard deviation is about 0.212, with very small differences between groups.

[0105] Statistical tests revealed no significant correlation between function length and NPC value (Pearson correlation coefficient r≈-0.03, p=0.186). This indicates that the number of lines of code in a function does not significantly affect the cohesion measure of this invention, and the NPC index is applicable to functions of different sizes and maintains stable reliability.

[0106] To further verify the impact of function length on the effectiveness of malicious injection detection, we also compared the changes in cohesion caused by malicious injection under different code sizes.

[0107] All functions were divided into intervals based on the number of rows. The same proportion of malicious code was injected into the functions within each interval. Then, the average CD and average OTCD of each group of functions were calculated. The results showed that the average CD of each group fluctuated between 0.028 and 0.051, and the average OTCD was around 0.08 to 0.11. Furthermore, the standard deviation did not show a significant pattern with the function size (range: 0.167 to 0.198).

[0108] Correlation analysis showed that there was no statistically significant correlation between the number of function rows and CD and OTCD (CD: p = 0.134, OTCD: p = 0.562). Figure 6 The distribution of average CD and OTCD caused by malicious injection and their standard deviation is displayed intuitively in different code line number ranges, and the groups are basically the same.

[0109] These results demonstrate that the cohesion difference index of this invention is robust to function size: regardless of whether the function is short and concise or long and complex, as long as its cohesion abnormally decreases by more than a threshold, it can be effectively detected by this method. In other words, function length does not weaken the model's ability to capture changes in cohesion, thereby ensuring that the detection range of this invention covers functions of various sizes without bias.

[0110] In real-world scenarios, supply chain attacks are typically extremely rare, meaning that only a very small number of malicious modifications are mixed in with massive amounts of normal updates. To address this scarcity of malicious samples, this invention further evaluates the detection performance under different ratios of benign to malicious samples, focusing on the monitoring value of high cohesion functions and the optimization effect of the standardized difference index on detection performance.

[0111] Three scenarios with malicious code injection ratios were simulated: 1:100, 1:1000, and 1:10000 (i.e., one function out of every 100, 1000, and 10000 function updates randomly contains malicious code). In each case, functions with the corresponding ratio were randomly selected for malicious code insertion (the insertion location could be at the beginning, middle, or end, randomly distributed), while the remaining functions continued to update normally. The CD and OTCD scores of all these functions before and after the update were calculated, and the functions were sorted from highest to lowest score. The accuracy metric, P@100, was calculated for the top 100 functions.

[0112] P@100 represents the proportion of malicious functions among the top 100 functions, and is an important indicator of the effectiveness of detection algorithms under highly imbalanced data. If the total number of malicious functions is less than 100 under certain circumstances, the hit rate is normalized. For example, if there are 30 malicious functions and 15 of them are detected, it is recorded as a 100% hit rate.

[0113] Furthermore, since the aforementioned analysis shows that the initial cohesion level of a function affects the magnitude of the difference, functions with high initial cohesion may produce slightly larger differences even with normal modifications. Secondly, in natural evolution, functions with higher NPC values ​​have greater potential for reduction, thus their CD values ​​may be slightly larger. Therefore, we introduce the standardized cohesion difference CDz and the standardized optimal token difference OTCDz as improvement indicators.

[0114] The standardized method is as follows: Divide the function into 20 intervals (each interval width 0.05) based on the NPC before the function update, and calculate the average CD and OTCD of a large number of normal function version pairs within each interval. and standard deviation Then, for any specific function update, its standardized difference is defined as: the difference minus the mean of the NPC interval, divided by the standard deviation of that interval. For example, if a function's original cohesion is 0.73, and it decreases to 0.62 after the update, then... Suppose the NPC interval to which this function belongs is [0.70, 0.75]. Statistically, under normal circumstances, the average CD of this interval is 0.057, and the standard deviation is 0.054. Then, what is the standardized cohesion difference updated by this function? .

[0115] This value indicates that the decrease in cohesion is approximately one standard deviation higher than that of functions with similar cohesion levels. Similarly, OTCDz can be calculated. This standardization mitigates the imbalance in the distribution of differences between different initial cohesion functions, allowing the magnitudes of change between high and low cohesion functions to be compared on the same scale, thus improving the consistency and rationality of detection threshold division. The average P@100 results from 1000 simulations at each malicious proportion are summarized in Table 2 below.

[0116] Table 2

[0117]

[0118] Among them, high cohesive functions refer to functions with an original NPC score higher than 0.5; the number of malicious functions represents the total number of functions injected with malicious code in each simulation (for example, in a 1:100 scenario, about 1% of the functions are malicious, and 4799 corresponds to a total of about 479,900 functions in the simulation, which is consistent with the size of the dataset).

[0119] As can be seen from Table 2, across all functions, when malicious code is extremely rare, the detection accuracy drops sharply as the proportion of malicious code decreases: for example, using the CD index, when the proportion of malicious code is 1:100, P@100 is about 1.41%, while when it drops to 1:10,000, it is almost 0 (only 0.04%).

[0120] This reflects the severity of false positives under extreme imbalances. When the vast majority of Top 100 alerts are benign functions, security personnel can hardly glean any valuable information from the alerts. However, if only high-cohesion functions are monitored (i.e., functions with an initial NPC > 0.5 are evaluated separately), the detection performance is significantly improved: in a 1:100 scenario, the P@100 of the CD metric in the high-cohesion subset reaches 82.21%, far exceeding the overall 1.41%; in particular, the standardized CDz and OTCDz metrics even reach 100% P@100 in this scenario, meaning that all malicious tampering functions are within the top 100 alerts. Even when the malicious ratio is as low as 1:10,000, CDz on the high-cohesion set still achieves approximately 12.47% P@100, an improvement of two orders of magnitude compared to the 0.06% in the unclassified scenario.

[0121] Meanwhile, it can be seen that the standardized difference metrics (CDz, OTCDz) exhibit higher detection accuracy at all scales compared to the unstandardized CD. For example, in the high-cohesion scenario of 1:1000, the P@100 of CDz is 36.41%, significantly higher than the 8.29% of the unstandardized CD; in the 1:10,000 scenario, CDz is about 4 times better than CD. This fully demonstrates the importance of normalizing the difference based on the baseline cohesion level of the function itself: after standardization, the differences between different functions are more comparable, and the discriminative power of anomaly scoring is significantly enhanced.

[0122] Furthermore, it was found that CD-type indicators generally outperformed OTCD-type indicators in detection performance, with the P@100 of CD / CDz being higher than that of the corresponding OTCD / OTCDz in all scenarios. This phenomenon is consistent with the previous analysis: CD directly measures overall cohesion drift and tends to highlight anomalies more strongly, while OTCD, although providing a semantic deviation perspective, has a relatively lower signal-to-noise ratio when used alone. However, OTCD can detect changes missed by CD in certain situations, so the combination of the two can provide the most comprehensive detection basis.

[0123] The experimental results above demonstrate that the unsupervised malware detection method based on function name prediction of cohesion changes proposed in this invention exhibits effectiveness and robustness under various challenging conditions. During normal software maintenance, the cohesion of most functions remains stable, and this method generally produces few false positives. However, once malicious code is inserted, causing an abnormal decrease in function cohesion, the CD and OTCD indices can sensitively detect this change and identify it as suspicious by setting reasonable thresholds. In particular, the detection effect of this method is more prominent for well-structured, originally highly cohesive critical functions, making them key targets for supply chain attack monitoring. Even with extremely imbalanced data, by standardizing the cohesion difference and focusing on high-cohesion targets, the method of this invention can still achieve meaningful detection accuracy, effectively reducing the scope of code that security personnel need to investigate.

[0124] The above are merely embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention are included within the scope of the claims of the present invention pending approval.

Claims

1. An unsupervised malicious code detection method based on predicting cohesion changes using function names, characterized in that, Includes the following steps: Step 1: Obtain the source code and version evolution information of the target software, identify the function-level code changes, and extract the original and updated versions of the code for each changed function to form a function version pair to be analyzed; Step 2: Based on the version function information obtained in Step 1, use a pre-trained code language model to perform function name mask prediction analysis on each function code in the function version pair, and calculate the name prediction cohesion value and the corresponding optimal name length for each function version. Step 3: After obtaining the predicted cohesion value and optimal name length in Step 2, compare the predicted name cohesion value of the updated version and the original version of the same function, calculate the quantitative index of cohesion change, and compare the index with a preset threshold to determine whether the cohesion change of the function is abnormal. Step 4: Process the abnormal result values ​​obtained in Step 3. If the change exceeds the threshold, mark the function version as suspicious and generate a security alarm. If it does not exceed the threshold, record the change as normal.

2. The method according to claim 1, characterized in that, The function name mask prediction analysis includes: replacing the name identifier in the function definition with a placeholder, retaining only the function's parameter list and function body as model input, and the pre-trained code language model generating prediction results of the function name and probability values ​​of each prediction identifier for the input function code.

3. The method according to claim 2, characterized in that: The pre-trained code language model makes multiple predictions for different assumed function name lengths, outputting a series of name identifiers of length n and their corresponding probabilities, and calculates the name prediction confidence of the n identifier sequences, wherein the harmonic mean of the probabilities of each identifier is used as the confidence value.

4. The method according to claim 3, characterized in that: For each function version, calculate the name prediction confidence value under different name lengths, and select the largest one as the name prediction cohesion value of that function version; at the same time, determine the name length that makes the confidence value reach the maximum value as the optimal name length of that function version.

5. The method according to claim 4, characterized in that, The quantitative indicators of cohesion change include: cohesion difference, defined as the name prediction cohesion value of the updated function version minus the name prediction cohesion value of the corresponding original version; and optimal name length confidence difference, defined as the difference obtained by calculating the name prediction confidence value of the updated function under the optimal name length of the original function version and subtracting the name prediction cohesion value of the original function.

6. The method according to claim 5, characterized in that: When the cohesion difference or the confidence difference of the optimal name length is greater than a preset threshold, it is determined that the cohesion of the function update is abnormally reduced, and there is a suspicion of malicious code injection. This triggers the generation of a security alert containing the function identifier, version information and abnormal indicator values. When the difference does not exceed the threshold, it is considered a normal update and no alarm is triggered. Only the relevant information of the update is recorded in the system log.

7. The method according to claim 6, characterized in that: The threshold is determined statistically based on the cohesion difference of historical normal function version evolution. The threshold is set by adding the standard deviation of a preset multiple to the distribution mean of cohesion change under normal evolution or by selecting a quantile threshold, so as to ensure that the threshold is higher than the fluctuation range of most normal changes and reduce the false alarm rate.

8. The method according to claim 6, characterized in that: The threshold is adaptively adjusted based on the initial cohesion level of different functions, including: Strategy 1: Predict the cohesion of the original function in advance according to its name, divide the function into multiple intervals, and calculate the average and standard deviation of the cohesion difference of the normal function update and the confidence difference of the optimal name length in each interval; Strategy 2: Subtract the mean of the interval to which the specific function updates the actual difference, and then divide by the standard deviation of the interval to obtain the standardized cohesion difference and the standardized optimal name length difference. Determine whether the standardized difference exceeds a preset threshold to identify an anomaly, thereby improving the consistency of threshold determination under different initial cohesion levels.

9. The method according to claim 6, characterized in that: The malicious code detection method is integrated into the continuous integration process of software version control, automatically performing the above operations for each code submission; and dynamically updating the threshold or model parameters based on the accumulated normal and abnormal detection samples to improve the adaptability and accuracy of detection.

10. An unsupervised malware detection system based on function name prediction of cohesion changes, characterized in that, To implement the method of any one of claims 1-9, comprising: The input module is used to receive software source code and its version update information; The function extraction module is used to parse the source code and extract the function definitions, and pair them to obtain the original version and the updated version of the function; The model inference module has a built-in pre-trained code language model, which is used to perform name mask prediction on function code and calculate the name prediction cohesion value. The cohesion analysis module is used to calculate the difference in the predicted cohesion value between the name versions of the function and compare it with a preset threshold to determine whether it is abnormal. The alarm module is used to generate and output alarms when an anomaly is detected.

Images