Code detection method and device, electronic equipment and storage medium

Abstract

The invention provides a code detection method and device, electronic equipment and a storage medium. The method comprises the steps that a plurality of code snippets are determined according to a first code with vulnerabilities and a second code corresponding to the first code, and the second code is a code obtained after vulnerability repair is conducted on the first code; determining a first code snippet and a second code snippet according to the code snippets; clustering the first code snippets to obtain a first cluster; clustering the second code snippets to obtain a second cluster; and based on the first cluster and the second cluster, performing vulnerability detection on the third code to obtain a vulnerability detection result of the third code. Through the method and the device, the code detection accuracy can be effectively improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a code detection method, device, electronic device, and storage medium. Background Art

[0002] During software development, developers often encapsulate and reuse existing code snippets to improve coding efficiency. While this copy-and-paste approach can improve programming efficiency, it can also compromise software security because vulnerabilities can easily spread to newly developed systems through code cloning.

[0003] In related technologies, vulnerability detection for code is typically performed by calculating the hash value of the vulnerable code and the hash value of the code to be detected, and then comparing the hash values ​​of the vulnerable code and the code to be detected. This is done to detect vulnerabilities in the code to be detected. However, the comparison of hash values ​​can lead to hash collisions, resulting in low code detection accuracy. Summary of the Invention

[0004] The embodiments of the present application provide a code detection method, device, electronic device, computer-readable storage medium, and computer program product, which can effectively improve the accuracy of code detection.

[0005] The technical solution of the embodiment of the present application is implemented as follows:

[0006] The present invention provides a code detection method, including:

[0007] Determining a plurality of code segments based on a first code having a vulnerability and a second code corresponding to the first code, wherein the second code is a code obtained by fixing the vulnerability in the first code;

[0008] Determining a first code fragment and a second code fragment according to the code fragment; clustering the first code fragment to obtain a first cluster; clustering the second code fragment to obtain a second cluster;

[0009] Based on the first cluster and the second cluster, vulnerability detection is performed on the third code to obtain a vulnerability detection result of the third code.

[0010] The present invention provides a code detection device, including:

[0011] a partitioning module, configured to determine a plurality of code segments based on a first code having a vulnerability and a second code corresponding to the first code, wherein the second code is a code obtained by fixing the vulnerability in the first code;

[0012] a clustering module, configured to determine a first code segment and a second code segment based on the code segment; cluster the first code segment to obtain a first cluster; and cluster the second code segment to obtain a second cluster;

[0013] A detection module is configured to perform vulnerability detection on a third code based on the first cluster and the second cluster to obtain a vulnerability detection result of the third code.

[0014] An embodiment of the present application provides an electronic device, including:

[0015] a memory for storing computer-executable instructions or computer programs;

[0016] The processor is configured to implement the code detection method provided in the embodiment of the present application when executing the computer executable instructions or computer program stored in the memory.

[0017] An embodiment of the present application provides a computer-readable storage medium storing computer-executable instructions for causing a processor to execute and implement the code detection method provided in the embodiment of the present application.

[0018] An embodiment of the present application provides a computer program product, which includes a computer program or computer-executable instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer-executable instructions from the computer-readable storage medium and executes the computer-executable instructions, causing the electronic device to perform the code detection method described above in the embodiment of the present application.

[0019] The embodiments of the present application have the following beneficial effects:

[0020] By determining multiple code snippets based on a first code with a vulnerability and a second code corresponding to the first code, a first code snippet and a second code snippet are determined based on the code snippets; the first code snippets are clustered to obtain a first cluster; the second code snippets are clustered to obtain a second cluster. Since the first code snippet exists in the second code and the second code snippet exists in the first code, and since the second code is the code after the vulnerability of the first code is repaired, all code snippets in the second code do not have the vulnerability in the first code. Then, the first code snippet in the first cluster can be a code snippet newly added to the second code for repairing the fault, that is, the first code snippet will not have the vulnerability in the first code. The second code snippet in the second cluster can be a code snippet with a vulnerability in the first code. Vulnerability detection is performed on the third code through the first cluster and the second cluster to obtain a vulnerability detection result of the third code. Vulnerability detection of the third code is achieved through the division of the first cluster and the second cluster, so that hash calculation is not required during the detection process, thereby effectively avoiding the problem of hash collision, thereby effectively improving the accuracy of code detection. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 This is a schematic diagram of the architecture of the code detection system provided in an embodiment of the present application;

[0022] Figure 2 This is a schematic diagram of the structure of an electronic device for detecting codes provided in an embodiment of the present application;

[0023] Figure 3 Schematic diagram of the code detection method provided in the embodiment of the present application;

[0024] Figure 4 This is a schematic diagram of the architecture of the code detection method provided in the embodiment of the present application;

[0025] Figure 5 This is a schematic diagram of the principle of vulnerability discovery provided by an embodiment of the present application. DETAILED DESCRIPTION

[0026] In order to make the purpose, technical solutions and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limiting this application. All other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0027] In the following description, reference is made to “some embodiments”, which describes a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0028] In the following description, the terms "first\second\third" involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first\second\third" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0029] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application pertains. The terms used herein are for the purpose of describing the embodiments of this application only and are not intended to limit this application.

[0030] Before further describing the embodiments of the present application in detail, the nouns and terms involved in the embodiments of the present application are explained. The nouns and terms involved in the embodiments of the present application are subject to the following interpretations.

[0031] 1) Hash collision: This occurs when two or more different inputs (data) are mapped to the same hash value (hash) in a hash function. In other words, even if the input data is different, after being processed by the hash function, they produce the same output value. An ideal hash function should have a uniform distribution property, that is, each possible input should be mapped to a different hash value as much as possible. However, because the output space of a hash function (the set of possible hash values) is typically much smaller than the input space (the set of all possible inputs), collisions are theoretically inevitable due to the pigeonhole principle. Hash collisions can lead to security issues, especially when an attacker can intentionally create a collision to disrupt the normal operation of the system. For example, in some cryptographic systems, if an attacker can find two different inputs that have the same hash value, they may be able to impersonate or tamper with data without being detected.

[0032] 2) Code: In computer science and software development, it refers to a set of instructions written by a programmer or developer that tells a computer or computing device how to perform specific operations, process data, or perform other tasks.

[0033] 3) Code Vulnerability: Code vulnerabilities are flaws or weaknesses in software source code that can be exploited by attackers, leading to unauthorized data access, data leakage, system damage, or other security violations. Code vulnerabilities are often introduced due to programming errors, improper design, or disregard for security best practices.

[0034] 4) Code Clone Vulnerability: Code clone vulnerabilities are security flaws introduced by duplicate or similar code snippets (i.e., code clones) in software. These cloned code snippets may be caused by developers copying and pasting code to quickly implement functionality, without realizing that the copied code may contain vulnerabilities or not meet the security requirements of the current context.

[0035] During the implementation of the embodiments of this application, the applicant discovered that the related technology has the following problems:

[0036] In related technologies, vulnerability detection for code is typically performed by calculating the hash value of the vulnerable code and the hash value of the code to be detected, and then comparing the hash values ​​of the vulnerable code and the code to be detected. This is done to detect vulnerabilities in the code to be detected. However, the comparison of hash values ​​can lead to hash collisions, resulting in low code detection accuracy.

[0037] The embodiments of the present application provide a code detection method, apparatus, electronic device, computer-readable storage medium, and computer program product, which can effectively improve the accuracy of code detection. The following describes an exemplary application of the code detection system provided in the embodiments of the present application.

[0038] See also Figure 1 , Figure 1 1 is a schematic diagram of the architecture of the code detection system 100 provided in an embodiment of the present application. The terminal (terminal 400 is shown as an example) is connected to the server 200 via the network 300. The network 300 can be a wide area network or a local area network, or a combination of the two.

[0039] The terminal 400 is used for the user to use the client 410 and display the detection results on the graphical interface 410-1 (graphic interface 410-1 is shown as an example). The terminal 400 and the server 200 are connected to each other via a wired or wireless network.

[0040] In some embodiments, the server 200 can be an independent physical server, or a server cluster or business system composed of multiple physical servers, or a cloud server that provides cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDN), and basic cloud computing services such as big data and artificial intelligence platforms. The terminal 400 can be a smart phone, a tablet computer, a laptop computer, a desktop computer, a smart speaker, a smart TV, a smart watch, a car terminal, etc., but is not limited to this. The electronic device provided in the embodiment of the present application can be implemented as a terminal or as a server. The terminal and the server can be directly or indirectly connected via wired or wireless communication, which is not limited in the embodiment of the present application.

[0041] In some embodiments, the server 200 determines multiple code fragments for the first code with a vulnerability and the second code corresponding to the first code, clusters the multiple code fragments to obtain a first cluster and a second cluster, performs vulnerability detection on the third code based on the first cluster and the second cluster, obtains a detection result, and sends the detection result to the terminal 400.

[0042] In other embodiments, the terminal 400 determines multiple code fragments for the first code with a vulnerability and the second code corresponding to the first code, clusters the multiple code fragments to obtain a first cluster and a second cluster, performs vulnerability detection on the third code based on the first cluster and the second cluster, obtains the detection results, and sends the detection results to the server 200.

[0043] See also Figure 2 , Figure 2 is a schematic diagram of the structure of an electronic device 500 for detecting codes provided in an embodiment of the present application, wherein: Figure 2 The electronic device 500 shown may be Figure 1 The server 200 or the terminal 400 in Figure 2 The electronic device 500 shown includes: at least one processor 430, a memory 450, and at least one network interface 420. The various components in the electronic device 500 are coupled together via a bus system 440. It is understood that the bus system 440 is used to achieve connection and communication between these components. In addition to including a data bus, the bus system 440 also includes a power bus, a control bus, and a status signal bus. However, for the sake of clarity, the bus system 440 is not described in detail. Figure 2 Various buses are labeled as bus system 440 .

[0044] The processor 430 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc., where the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0045] The memory 450 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard drives, optical drives, etc. The memory 450 may optionally include one or more storage devices that are physically remote from the processor 430.

[0046] The memory 450 includes volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory may be a read-only memory (ROM), and the volatile memory may be a random access memory (RAM). The memory 450 described in the embodiments of the present application is intended to include any suitable type of memory.

[0047] In some embodiments, the memory 450 can store data to support various operations, examples of which include programs, modules, and data structures, or a subset or superset thereof, as exemplified below.

[0048] Operating system 451, including system programs for processing various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, and driver layer, which are used to implement various basic services and process hardware-based tasks;

[0049] The network communication module 452 is used to reach other electronic devices via one or more (wired or wireless) network interfaces 420. Exemplary network interfaces 420 include: Bluetooth, Wireless Fidelity (WiFi), and Universal Serial Bus (USB).

[0050] In some embodiments, the code detection device provided in the embodiments of the present application can be implemented in software. Figure 2 A code detection device 455 stored in memory 450 is shown. This device can be software in the form of a program or plug-in, and includes the following software modules: a partitioning module 4551, a clustering module 4552, and a detection module 4553. These modules are logical and can be arbitrarily combined or further separated according to the functions they implement. The functions of each module will be described below.

[0051] In other embodiments, the code detection device provided in the embodiments of the present application can be implemented in hardware. As an example, the code detection device provided in the embodiments of the present application can be a processor in the form of a hardware decoding processor, which is programmed to execute the code detection method provided in the embodiments of the present application. For example, the processor in the form of a hardware decoding processor can adopt one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field programmable gate arrays (FPGAs), or other electronic components.

[0052] In some embodiments, the terminal or server can implement the code detection method provided in the embodiment of the present application by running a computer program or a computer executable instruction. For example, the computer program can be a native program (e.g., a dedicated code detection program) or a software module in an operating system, for example, a code detection module that can be embedded in any program (such as an instant messaging client, an album program, an electronic map client, a navigation client); for example, it can be a local (Native) application (APP, Application), that is, a program that needs to be installed in the operating system to run. In short, the above-mentioned computer program can be an application, module or plug-in in any form.

[0053] The code detection method provided in the embodiment of the present application will be described in conjunction with the exemplary application and implementation of the server or terminal provided in the embodiment of the present application.

[0054] See also Figure 3 , Figure 3 This is a flow chart of the code detection method provided in the embodiment of the present application, which will be combined with Figure 3 Steps 101 to 103 are shown for illustration. The code detection method provided in the embodiment of the present application can be implemented by the server or the terminal alone, or by the server and the terminal in collaboration. The following description will be made using the server alone as an example.

[0055] In step 101, a plurality of code segments are determined based on a first code having a vulnerability and a second code corresponding to the first code.

[0056] In some embodiments, the second code is a code obtained by fixing vulnerabilities in the first code.

[0057] In some embodiments, the "first code" refers to the original, vulnerable version of the code. This version of the code may contain security vulnerabilities due to programming errors, design flaws, or disregard for security best practices. These vulnerabilities can be exploited by attackers, threatening the security of the software. The "first code" is an initial state during the software development process, which requires review and repair to improve its security.

[0058] In some embodiments, the second code is a version of the first code that has been patched for vulnerabilities. This is also called patched code because it contains fixes for known vulnerabilities. The second code eliminates security vulnerabilities by modifying, optimizing, or refactoring vulnerable parts of the first code, thereby improving the overall security and stability of the code.

[0059] In some embodiments, the above step 101 can be implemented as follows: perform the following processing on each line of code in the first code and the second code: perform semantic recognition on the code corresponding to the line to obtain the semantic recognition result of the code corresponding to the line; if the semantic recognition result indicates that the code corresponding to the line has control flow semantics, then standardize the code corresponding to the line to obtain the code snippet.

[0060] In some embodiments, semantic recognition is performed on each line of the first code and the second code, using static code analysis techniques, natural language processing (NLP) techniques, or other algorithms to parse the semantic content of each line of code. The purpose of semantic recognition is to understand the function and purpose of the code, not just its grammatical structure. A semantic recognition result is obtained for each line of code, which is structured data or a label describing the line of code.

[0061] In some embodiments, if the semantic recognition result indicates that a line of code has clear semantics (i.e., its behavior and purpose are clear), then this line of code will be selected for further processing. Standardization processing may involve converting the code into a format that is more standardized, easier to read, or more in line with a coding standard. This may include operations such as refactoring code, renaming variables, adjusting code structure, or eliminating redundant code. The standardized code snippets should be clearer, more robust, and easier to maintain.

[0062] In some embodiments, semantic recognition is the process of understanding the meaning of code. It goes beyond grammatical analysis and attempts to understand the behavior and purpose of the code. The following describes the process of performing semantic recognition on each line of code in the first and second codes: Each line of code is fed into a semantic recognition system as input. The semantic recognition system may use a lexical analyzer (tokenizer) to break the code into smaller units, such as keywords, variable names, operators, punctuation marks, etc. It then performs grammatical analysis (parsing) to construct an abstract syntax tree (AST) of the code, which helps understand the structure and grammatical relationships of the code. It then performs data flow analysis to track the flow of variables and data and understand how data is passed and processed in the code. It then performs control flow analysis to determine the execution path and possible branches of the code and understand how conditional statements and loop statements affect the code's behavior. Based on this analysis, semantic recognition is then performed on each line of code: predefined semantic patterns are used to match code structure, such as identifying loop patterns and conditional patterns. Key entities in the code, such as variables, functions, and classes, are identified, and their roles and relationships are understood. Inferring the intent of the code. For example, detecting loop structures may indicate repetitive processing, while conditional statements may indicate decision-making logic. Analyzing the context of the code to understand its role and impact within the overall program. Generating semantic recognition results for each line of code. This may include a description of the code's functionality, its intent, and data flow. If the semantic recognition results indicate that the line of code possesses clear semantics, the normalization process is executed. Control flow semantics refers to the rules governing the order and flow of instruction execution in a computer program. It describes how a program transitions from one operation to another and how these transitions are determined by constructs such as conditionals, loops, and function calls. Control flow semantics is fundamental to program design, determining the behavior and logical flow of a program. In programming, control flow semantics is typically implemented through a series of control flow constructs, such as sequential execution, conditionals (if-else statements), loops (for, while, do-while, etc.), jumps (break, continue, goto, etc.), and function calls and returns. These constructs enable programmers to control the execution flow of a program and implement complex logic and algorithms. Control flow semantics also play a key role in compiler design. Compilers need to understand the control flow of a program in order to perform optimizations, code generation, and error detection. For example, a compiler might analyze control flow to determine which variables are visible within a particular block of code, or which code paths might lead to errors.

[0063] In some embodiments, the above-mentioned semantic recognition is performed on the code corresponding to the line to obtain the semantic recognition result of the code corresponding to the line. The embodiment of the present application will not analyze all the line codes, but only consider the core line codes, such as the subtracted lines and the line codes with control flow semantics. Basically, a subtracted line in a patch is included in the vulnerability feature and not all context lines are included in the vulnerability feature. Because some line codes do not express any syntax or semantics, these line codes can be ignored and only those line codes that represent control flow semantics are retained, such as if or while statements. Similarly, an added line and core context lines in a patch will be included in the patch feature, that is, if the semantic recognition result indicates that the code corresponding to the line has semantics, the code corresponding to the line is standardized to obtain a code snippet.

[0064] This semantic recognition allows for a deep understanding of the code's actual functionality and intent, helping to identify potential security vulnerabilities, performance bottlenecks, and logical errors. Standardizing lines of code with clear semantics not only enhances code readability and consistency, but also improves robustness and maintainability. Standardized code snippets reduce the impact of individual coding styles, resulting in a cleaner codebase and facilitating the onboarding of new team members and inter-team collaboration. This improves code quality, shortens development cycles, and reduces maintenance costs.

[0065] In some embodiments, the above-mentioned standardization of the code corresponding to the row to obtain the code fragment can be achieved in the following manner: updating the variable characters in the code corresponding to the row to standard characters to obtain a third code fragment; identifying the characters in the third code fragment as function characters to obtain a recognition result; if the recognition result indicates that the function character does not exist in the third code fragment, determining the third code fragment as the code fragment; if the recognition result indicates that the function character exists in the third code fragment, updating the function character in the third code fragment to a standard function character to obtain the code fragment.

[0066] In some embodiments, variable names in the code are updated to standard characters or naming conventions to comply with coding standards or project naming conventions. This typically involves identifying all variables in the code and replacing them with predefined standard variable names. This may require maintaining a variable mapping table that maps original variable names to new standard variable names. A third code snippet is obtained, containing the updated standard variable names. The third code snippet is checked for the presence of specific function characters, which may refer to function names or specific code patterns. Static code analysis techniques, such as lexical analyzers or regular expressions, are used to identify function characters in the code. An identification result is obtained, indicating whether the specific function characters are present in the third code snippet. If the identification result indicates that the specific function characters are absent in the third code snippet, this means that the code already meets the expected standards, and the third code snippet can be directly determined as the final standard code snippet. If the identification result indicates that the specific function characters are present in the third code snippet, this means that some non-standard function usages are still present in the code and require further standardization. The function characters in the code snippet are updated to standard function characters to ensure code consistency and standardization. Based on the identification result, all non-standard function characters are found and replaced with standard function names or patterns. This may also require maintaining a function mapping table or using code templates to ensure consistency. The final result is a standard code snippet, which is the code that has undergone a complete standardization process.

[0067] In some embodiments, a function character refers to a specific character used to define, declare, call, or execute a function and implement the internal logic of the function.

[0068] As an example, this is achieved by abstracting the variable names, variable types, and call function names in the code snippet. For example, $VAR_NAME is used to uniformly represent variable names, $VAR_TYPE is used to uniformly represent variable types, and $FUNC_CALL is used to uniformly represent call function names. By doing so, even if the variable names, variable types, and function call names change, the characteristics of this code will not be changed because the embodiments of the present application abstract them. Specifically, all variable names are abstracted into $VAR_NAME. All function calls are abstracted into $FUNC_CALL, and all variable types are abstracted into $VAR_TYPE.

[0069] In this way, updating the variable characters in the code to standard characters helps to unify variable naming, making the code more standardized and consistent, and easier for developers to understand and maintain. This consistency also reduces confusion and errors caused by inconsistent variable naming. The function characters in the third code snippet are identified and standardized to ensure that the function names used in the code meet the predetermined standards, which helps to improve the readability of the code while also keeping the code style consistent. If the identification result shows that there are no non-standard function characters in the code snippet, it can be confident that the code has met the standardization requirements and no further modification is required. If there are non-standard function characters, then by updating them to standard function characters, the standardization and maintainability of the code are further improved, which not only optimizes the appearance of the code, but also improves the quality of the code and the efficiency of team collaboration, which is of great significance for ensuring the sustainable development of the code and reducing long-term maintenance costs.

[0070] In some embodiments, before executing step 101, the following processing may also be performed: sending code collection instructions to multiple data sources respectively, and receiving collection results returned by the data sources in response to the collection instructions; based on the collection results, extracting the first code containing the vulnerability and the second code corresponding to the first code from the data source.

[0071] In some embodiments, collection instructions are sent to multiple data sources. These data sources can be code repositories, version control systems, code review tools, vulnerability databases, or other systems that store code information. The collection instructions specify the type of information to be collected, such as a request for a specific code snippet, commit logs, code change history, or code associated with a specific vulnerability. Upon receiving the collection instructions, the data source collects the corresponding information as instructed and returns the collection results to the requester. The collection results may include code text, code diffs, commit logs, comments, and other metadata. After receiving the collection results, these data are processed and analyzed to identify the vulnerable first code. Static analysis of the code, including syntax analysis, data flow analysis, and control flow analysis, is performed to determine whether the code contains known vulnerability patterns or security flaws. Based on the collection results, the vulnerable first code is identified and extracted. The first code refers to the original, vulnerable version of the code. The second code corresponding to the first code is extracted, i.e., the vulnerability-fixed version of the code. The second code should include the fix for the known vulnerability.

[0072] In some embodiments, it is critical to select the right data source because different data sources may store different types of information. For example, a version control system may provide a history of code changes, while a vulnerability database may contain detailed descriptions of vulnerabilities and recommended fixes. The collection instructions need to be precise enough to ensure that the data source can return relevant information. This may involve specifying parameters such as code repositories, branches, commit hashes, time ranges, etc. Processing the collection results requires the use of automated tools and algorithms to analyze the code and identify vulnerabilities and related fixes. Determining the correspondence between the first code and the second code may require analyzing the submission history and code differences. This may involve matching the fix submission with the reported vulnerability and verifying the effectiveness of the fix. This needs to be done continuously to promptly detect new vulnerabilities and fixes. For active projects, real-time monitoring of data sources and rapid response are key to keeping the code secure.

[0073] As an example, data can be collected from the following data sources: Github repositories; Issue tracker; Q&A sites. For example, with direct links, the CVE information page usually contains a URL link to the CVE patch page. Given a CVE information page as input, this method checks the direct URL link to obtain the patch. First, look for URL links containing the keyword "comm it" or "git". Then, use the command "git clone repo_url" to download the corresponding code repository. Finally, use the "git show commit_id" command to obtain the patch file (diff file) corresponding to a CVE vulnerability.

[0074] In some embodiments, for with indirect links, the CVE information page usually does not contain a direct patch URL link, but instead indirectly provides some web pages through references. These web pages contain Bug IDs or commits to represent the CVE patch page. Then, the method looks for information that may be linked to the CVE patch page. For example, the Bug ID provided on the page. Finally, the method searches for the commits of the patch using the information extracted in the previous steps. For example, if the Bug ID is provided in the previous step, the method can extract the corresponding security patch by executing the command "git log-grep='Bug ID'". This command is used to find those commits related to this Bug ID, and these commits usually contain this Bug ID in the description information of the commit. For "with invisible links", although there is no visible connection between the CVE patch page and the CVE information page, the CVE patch page may contain the corresponding CVE ID.

[0075] In some embodiments, the core idea of ​​collecting patches for invisible patch links is to use user discussion information on web pages, such as Q&A sites, to search for unsafe code snippets.

[0076] In this way, by sending code-specific collection instructions to multiple data sources and receiving the returned collection results, not only can comprehensive and timely collection of detailed information about the code be ensured, thereby improving vulnerability detection coverage, but it also simplifies the vulnerability management process through a centralized approach. Based on these collection results, the first code containing the vulnerability and its corresponding second code after repair can be accurately identified. This accuracy greatly improves the efficiency of vulnerability response and helps track the lifecycle of vulnerabilities from discovery to repair, thereby reducing security risks, ensuring software stability and user trust, reducing potential attack surfaces, and laying a solid foundation for maintaining code quality and improving software security.

[0077] In step 102, a first code segment and a second code segment are determined based on the code segment, the first code segment is clustered to obtain a first cluster, and the second code segment is clustered to obtain a second cluster.

[0078] In some embodiments, the first code snippet does not exist in the first code but exists in the second code, and the second code snippet exists in the first code and is a code snippet in the first code used to be replaced by the first code snippet.

[0079] In some embodiments, the input of the clustering is a plurality of code snippets, which may come from different data sources, including a first code with a vulnerability and a second code that has been repaired. The first cluster includes first code snippets that do not exist in the original first code but exist in the repaired second code. This may mean that these snippets are newly added code used to fix vulnerabilities or improve functions. The second cluster includes second code snippets that exist in the original first code and are used to replace the corresponding first code snippets in the second code. This indicates that these snippets may be key parts of fixing vulnerabilities or optimized codes. The absence of the first code snippets in the first code indicates that they were added later, possibly to fix vulnerabilities or add new functions. The presence of the second code snippets in the first code and the replacement of the corresponding first code snippets in the second code indicate that they are direct parts of the vulnerability fix or direct improvements to the original code.

[0080] In some embodiments, the second code includes part of the first code and the first code fragment. The determination of the first code fragment and the second code fragment based on the code fragment in the above step 102 can be implemented as follows: the following processing is performed for each of the code fragments: if the code fragment does not exist in the first code and exists in the second code, the code fragment is determined to be the first code fragment; if the code fragment exists in the first code and does not exist in the second code, the code fragment is determined to be the second code fragment; if the code fragment exists in the first code and exists in the second code, the code fragment is determined to be the first code fragment and the second code fragment.

[0081] In some embodiments, each code segment in the first code and the second code needs to be compared to determine whether it exists in the two code versions. Based on the comparison results, each code segment will be classified into different clusters.

[0082] In some embodiments, if a code snippet does not exist in the first code but exists in the second code, this means that the snippet was added later, so it is added to the first cluster. This cluster represents the code that was newly added during the repair process. If a code snippet exists in the first code but not in the second code, this indicates that the snippet was deleted during the repair process, so it is added to the second cluster. This cluster represents the code that was removed during the repair process. If a code snippet exists in both the first code and the second code, this means that the snippet was retained during the repair process, and it will be added to both the first cluster and the second cluster. This indicates that the code snippet is part of the base code and has not been modified during the repair process.

[0083] As an example, assume that the first code contains three fragments: A, B, and C. After the vulnerability is fixed, the second code contains fragments A, B, C', and D. Among them, C' is a modified version of C used to fix the vulnerability, and D is a newly added code fragment. For fragment D: Because fragment D does not exist in the first code, but exists in the second code, fragment D is added to the first cluster, which represents the newly added code during the repair process. For fragment C: Because fragment C exists in the first code (as fragment C) and also exists in the second code (as modified C), fragment C is added to the first cluster and the second cluster, which indicates that fragment C was retained and modified during the repair process. For fragments A and B: Because fragments A and B exist in the first code and also exist in the second code, they are also added to the first cluster and the second cluster. This shows that these fragments have not been modified during the repair process. For the original fragment C: Since the original fragment C exists in the first code but not in the second code (because it is replaced by C'), fragment C is added to the second cluster. This cluster represents the code removed during the repair process.

[0084] Continuing with the above example, we get two clusters: the first cluster contains fragments D (newly added code), C' (modified code), A (unmodified code), and B (unmodified code). The second cluster contains the original fragment C (removed code).

[0085] This precise clustering of code snippets distinguishes between newly added code, removed code, and retained or modified code during the code repair process. This allows development teams to quickly identify hotspots of changes and gain a deeper understanding of the details and impact of the repair. This not only streamlines the code review process and improves code quality, but also enhances the effectiveness assessment of security repair measures. This provides a clear change history and reference for subsequent code maintenance and feature expansion, ensuring software security and reliability while reducing long-term maintenance costs.

[0086] In other embodiments, the second code includes the first code and the first code fragment, and the first code includes a second code fragment corresponding to the first code fragment one by one; determining the first code fragment and the second code fragment based on the code fragment in the above step 102 can also be implemented as follows: performing the following processing for each of the code fragments: if the code fragment does not exist in the first code and exists in the second code, then determining the code fragment as the first code fragment, and determining the code fragment corresponding to the code fragment in the first code as the second code fragment; if the code fragment exists in the first code and exists in the second code, and there is no first code fragment corresponding to the code fragment in the second code, then determining the code fragment as the first code fragment and the second code fragment.

[0087] In some embodiments, a first code snippet is a snippet that exists in the second code but not in the first code. This is typically newly added code to fix a vulnerability or add new functionality. A second code snippet is a snippet that exists in the first code but has been modified or replaced in the second code. A first code snippet that does not exist in the first code but exists in the second code indicates that it is newly added. A second code snippet that exists in the first code and replaces the corresponding first code snippet in the second code indicates that the original code snippet has been modified. If a code snippet does not exist in the first code but exists in the second code, this code snippet will be added to the first cluster, indicating that it is a newly added snippet. At the same time, the code snippet in the first code that corresponds to this new snippet (even if it may have been modified or no longer exists) will be added to the second cluster to maintain the corresponding code relationship. If a code snippet exists in both the first and second codes but has no corresponding original first code snippet in the second code, this means that the original code snippet has been modified. In this case, the code snippet will be added to the first cluster and the second cluster, representing the original and modified code, respectively.

[0088] In some embodiments, if a code snippet does not exist in the first code but exists in the second code, this code snippet will be added to the first cluster to indicate that it is a newly added snippet. At the same time, the code snippet in the first code that corresponds to this new snippet (even if it may have been modified or no longer exists) will be added to the second cluster to maintain the corresponding relationship of the codes.

[0089] In some embodiments, if a code snippet exists in both the first code and the second code, but there is no corresponding original first code snippet in the second code, this means that the original code snippet has been modified. In this case, the code snippet will be added to the first cluster and the second cluster, representing the original and modified code respectively.

[0090] As an example, assume there are two code files, Code A and Code B. A first code fragment (Code A Fragment) does not exist in Code A but exists in Code B. For example, the first code fragment is funcC(){...}, a function defined in Code B but not in Code A. A second code fragment (Code B Fragment) exists in Code A and is the code fragment in Code A that is replaced by the first code fragment. For example, the second code fragment is funcB(){...}, a function defined in Code A and used to replace funcC(){...} (i.e., the first code fragment) somewhere else.

[0091] Continuing with the above example, the second code (Code B) includes the first code (Code A) and the first code fragment (CodeAFragment), that is, Code B = Code A + funcC(){...}. The first code (Code A) includes a second code fragment that corresponds one-to-one with the first code fragment, that is, Code A contains funcB(){...}. For the first code fragment (funcC(){...}): it does not exist in the first code (Code A), but exists in the second code (Code B). Therefore, funcC(){...} is added to the first cluster (Cluster A). At the same time, the code fragment funcB(){...} corresponding to funcC(){...} in the first code (Code A) is added to the second cluster (Cluster B). For the second code fragment (funcB(){...}): it exists in the first code (Code A) and also in the second code (Code B). In the second code (Code B), there is no first code fragment corresponding to funcB(){...} (because funcB is the original function in the first code). Therefore, funcB(){...} needs to be added to the first cluster (Cluster A) and the second cluster (Cluster B).

[0092] In this way, it is possible to effectively identify and separate code snippets that are newly added based on the first code, as well as those that are replaced or modified in subsequent development, thereby helping developers quickly locate and understand the history and reasons for code changes, and maintain the integrity of the code structure because it also considers the correspondence between code snippets, ensuring that related code snippets can be accurately classified into corresponding clusters. This clustering strategy helps improve the efficiency of code analysis and maintenance because it automatically distinguishes different parts of the code.

[0093] In step 103, vulnerability detection is performed on the third code based on the first cluster and the second cluster to obtain a vulnerability detection result of the third code.

[0094] In some embodiments, vulnerability detection based on the first cluster and the second cluster refers to using the known code snippet clustering results to analyze the security of the third code (i.e., the code to be detected). The first cluster here refers to a set of code snippets that do not exist in the first code but are newly added in the second code, and the second cluster refers to a set of code snippets that exist in the first code and are used to replace the first code snippets.

[0095] In some embodiments, the above step 103 can be implemented as follows: deleting redundant code fragments in the first cluster to obtain a third cluster, and deleting redundant code fragments in the second cluster to obtain a fourth cluster, and the redundant code fragments do not have the vulnerability; based on the third cluster and the fourth cluster, performing vulnerability detection on the third code to obtain a detection result for characterizing whether the third code has a vulnerability.

[0096] In some embodiments, a redundant code snippet may be a code snippet with a keyword, and the code snippet with the keyword does not participate in the implementation of the logic and function of the code.

[0097] In some embodiments, a set of keywords is defined. These keywords may represent known, non-vulnerability-related code patterns, such as common library function calls, comments, or proven secure coding practices. Code snippets containing these keywords are removed from the first cluster (containing newly added code snippets in the second code), resulting in a third cluster. This operation assumes that the code snippets corresponding to these keywords do not contain vulnerabilities, perhaps because they are standard, widely used code patterns that have been verified to be secure. The same operation is applied to the second cluster (the code snippet that existed in the first code and was used to replace the first code snippet), removing the code snippets containing the keywords, resulting in a fourth cluster. The third and fourth clusters now contain code snippets without known secure code patterns, meaning they are more likely to contain potentially unsafe code that truly requires attention. Since code snippets containing keywords have been filtered out, these clusters are less likely to generate false positives in subsequent vulnerability detection, as false positives are often caused by security practices (such as code patterns represented by keywords) being mistakenly marked as vulnerabilities. By comparing the snippets in the third code with the code snippets in the third and fourth clusters, code snippets that do not follow security practices can be identified, thereby revealing potential vulnerabilities.

[0098] In some embodiments, keywords refer to a set of predefined identifiers or patterns that may represent known, widely accepted secure coding practices or verified secure function and library calls. For example, keywords may include specific secure function names, secure library calls, specific code comment tags, and so on. During code analysis, each code snippet is checked for the presence of these predefined keywords. It is assumed that code snippets containing keywords are written according to security best practices or are used to perform operations that are already considered secure. Therefore, these code snippets are considered vulnerability-free. Based on this assumption, code snippets containing keywords are excluded from vulnerability detection during vulnerability detection. That is, even if these code snippets somewhat resemble known vulnerability patterns, they are not flagged as potential vulnerabilities. For example, if a code snippet contains a secure keyword like fgets() (as opposed to the unsafe gets() function), it is typically used to read a string from standard input and limit the read length to prevent buffer overflows. Therefore, a code snippet containing fgets() is unlikely to be reported as a buffer overflow vulnerability.

[0099] In some embodiments, the above-mentioned vulnerability detection of the third code based on the third cluster and the fourth cluster to obtain a detection result for characterizing whether the third code has a vulnerability can be achieved as follows: performing rule extraction on the third cluster to obtain a third rule in the third cluster, and performing rule extraction on the fourth cluster to obtain a fourth rule in the fourth cluster; matching the third rule with the third code to obtain a third matching result for characterizing whether the third code contains the third rule; matching the fourth rule with the third code to obtain a fourth matching result for characterizing whether the third code contains the fourth rule; and determining the vulnerability detection result of the third code based on the third matching result and the fourth matching result.

[0100] In some embodiments, rule extraction is performed on the third cluster (the optimized cluster containing the newly added code snippets of the second code) to obtain a third rule. These rules are patterns summarized from the third cluster, which may include specific code structures, function calls, variable naming habits, etc., which are related to potential security vulnerabilities. Rule extraction is performed on the fourth cluster (the optimized cluster containing the replaced code snippets in the first code) to obtain a fourth rule. These rules also reflect code patterns, but they focus on those patterns that have been identified as safe or unsafe in a code. The third rule is matched with the third code to check whether there is a code pattern similar to that in the third cluster in the third code. This step is achieved through static code analysis and may involve pattern recognition, syntax analysis and other technologies. The fourth rule is matched with the third code to determine whether the third code contains the pattern in the fourth cluster. The third matching result obtained will characterize whether the third code contains the same rules as those in the third cluster, which may indicate the introduction of potential new vulnerabilities or security risks. The fourth matching result will characterize whether the third code contains the same rules as those in the fourth cluster, which may indicate whether the code maintains the security practices in the first code or whether new security measures have been introduced. Based on the third and fourth matching results, the security of the third code can be comprehensively evaluated. If the third code contains rules that match the third cluster, this may indicate a new security vulnerability. If it matches the rules of the fourth cluster, it may indicate that security practices have been maintained in the code or new security measures have been taken. Based on these matching results, a detection result can be determined to characterize whether the third code has a vulnerability. This result can be a simple yes or no or a detailed report including the type of vulnerability found, severity assessment, and recommended remediation measures.

[0101] In some embodiments, the above-mentioned determination of the vulnerability detection result of the third code based on the third matching result and the fourth matching result can be achieved as follows: if the third matching result indicates that the third code does not have the third rule, and the fourth matching result indicates that the third code has the fourth rule, then the vulnerability detection result is determined to be that the third code has the vulnerability; if the third matching result indicates that the third code has the third rule, or the fourth matching result indicates that the third code does not have the fourth rule, then the vulnerability detection result is determined to be that the third code does not have the vulnerability.

[0102] In some embodiments, if the third matching result indicates that the third code does not have the third rule, this means that no potentially unsafe code pattern identical to that in the third cluster is found in the third code. This may be a positive signal, indicating that the third code does not introduce new security risks. If the fourth matching result indicates that the third code has the fourth rule, this indicates that the third code retains the security practices in the fourth cluster or takes new security measures, which are consistent with the security pattern in the first code. If the third code does not have the third rule (i.e., no new potentially unsafe pattern is found) and at the same time has the fourth rule (i.e., known security practices are retained), in this case, the system will determine that the third code has vulnerabilities. This may be because the expected security practices are not followed, or new unsafe code patterns are introduced but not discovered. If the third code has the third rule (i.e., new potentially unsafe pattern is found) or does not have the fourth rule (i.e., known security practices are not retained), the system will determine that the third code does not have vulnerabilities.

[0103] By removing code snippets containing keywords from the first and second clusters, we formed more refined third and fourth clusters. This effectively eliminated code patterns widely considered safe, reduced false positives, and allowed development teams to focus on addressing truly potential vulnerabilities. This also improved detection efficiency, reduced unnecessary testing burden, and ultimately ensured the reliability of vulnerability detection results, strengthening software security and providing a more solid line of defense.

[0104] In some embodiments, the above-mentioned step 103 can also be implemented in the following manner: performing open source identification on the third code to obtain an open source identification result; if the open source identification result indicates that part of the third code is open source, based on the first cluster and the second cluster, vulnerability detection is performed on the open source part of the third code to obtain the vulnerability detection result.

[0105] In some embodiments, the third code is subjected to open source identification. This step aims to determine which portions of the code are open source. This may involve using specific tools or algorithms to scan the codebase and identify open source code fragments, such as by identifying license information, copyright notices, or known open source code patterns. If the open source identification results indicate that the third code contains portions of open source code, subsequent processing will focus on these open source code portions. Based on the first and second clusters, vulnerability detection is performed on the open source portions. The first and second clusters mentioned here may refer to certain sets of code features, such as code structure, code style, and dependencies, which can be used to assist in the vulnerability detection process. The detection process is performed only on open source code portions, based on the assumption that the code portions that are not open source are manually written by developers and are therefore less likely to be cloned due to copy-paste (i.e., security vulnerabilities that may result from code duplication). It is assumed that the code portions that are not open source are manually written and therefore less likely to contain vulnerabilities caused by copy-paste. Open source code portions, due to their widespread use and sharing, are more likely to be copied and pasted by developers into different projects, potentially causing vulnerabilities to spread across projects. Due to the public nature of open source code, it may be subject to more extensive scrutiny, but this also makes it easier for vulnerabilities to be discovered and exploited. Detection results will only reflect vulnerabilities in the open source code portion, which helps developers focus on those parts that may introduce security risks rather than searching for potential problems in the entire code base.

[0106] For example, see Figure 5 , for the third code ( Figure 5 The open source identification is performed on the tested program shown in the figure to obtain an open source identification result; if the open source identification result indicates that part of the code in the third code is open source, based on the first cluster and the second cluster, the open source part ( Figure 5 The open source part shown in the figure) is used to perform vulnerability detection to obtain the vulnerability detection result.

[0107] In this way, by implementing the open source identification process, the open source and closed source portions of the third code can be effectively distinguished. Once the open source portions of the third code are identified, the existing security review results of the open source community can be utilized to reduce vulnerability detection work for these portions, thereby optimizing resource allocation. Furthermore, based on the security rules and patterns provided by the first and second clusters, targeted vulnerability detection is performed on the open source portions of the third code, not only improving detection accuracy and efficiency, but also ensuring that the security of these portions of the code is fully assessed.

[0108] In some embodiments, the above-mentioned step 103 can be implemented as follows: performing rule extraction on the first cluster to obtain the first rule in the first cluster, and performing rule extraction on the second cluster to obtain the second rule in the second cluster; matching the first rule with the third code to obtain a first matching result for characterizing whether the third code contains the first rule; matching the second rule with the third code to obtain a second matching result for characterizing whether the third code contains the second rule; and determining the vulnerability detection result of the third code based on the first matching result and the second matching result.

[0109] In some embodiments, rule extraction is performed on the first cluster to obtain first rules. These rules are summarized based on the code snippets in the first cluster and may include safe coding practices, the use of specific functions, configuration settings, etc., which are used to define safe lines of code. Rule extraction is performed on the second cluster to obtain second rules. These rules may identify unsafe coding practices, known vulnerability patterns, or code patterns that have been identified as risks in other projects. The first rules are matched with the third code to check whether the third code contains the safe rules defined in the first cluster. The first matching result will indicate whether the third code follows these safe coding practices. The second rules are matched with the third code to check whether the third code contains unsafe rules defined in the second cluster. The second matching result will indicate whether the third code contains known unsafe patterns or risks. If the first matching result is yes (i.e., the third code follows the safe rules) and the second matching result is no (i.e., the third code does not have unsafe patterns), the third code may be considered safe. If the first matching result is no (ie, the third code does not follow the security rules), or the second matching result is yes (ie, the third code contains an unsafe pattern), the third code may be considered to have a vulnerability.

[0110] In some embodiments, rule extraction is the process of automatically identifying and generating rules or patterns from a code base or code snippet. These rules are used to describe specific characteristics of the code, such as coding standards, security practices, or potential vulnerability patterns. In the software development and security fields, rule extraction is often used to create rule sets for code analysis tools, such as those used for static application security testing (SAST). The generated rules can be used to detect patterns in the code to identify security vulnerabilities, coding errors, or inconsistencies.

[0111] In some embodiments, rule extraction begins by collecting code samples from a first cluster and a second cluster. These samples are typically pre-grouped using code analysis tools, code repository mining, or other methods. The first cluster contains code considered safe, and the second cluster contains code that may pose risks. The collected code samples are analyzed to identify key features in the code. These may include code structure, used functions, variable naming, control flow, data flow, and so on. Rules are generated using automated tools such as semgrep. semgrep is a pattern-based code search tool that uses a simple declarative syntax to describe the patterns to search for. During this process, the tool generates corresponding semgrep rules based on the code features. Rule extraction is performed on the first cluster to obtain first rules, which define safe coding practices. Rule extraction is performed on the second cluster to obtain second rules, which may identify potentially safe or unsafe coding practices. Based on the first and second matching results, the security of the third code is comprehensively analyzed. If the third code complies with all safety rules (the first matching result is "yes") and contains no unsafe patterns (the second matching result is "no"), the code is considered safe. Conversely, if the third code violates security rules or has unsafe patterns, it may indicate a vulnerability in the code.

[0112] By extracting the first rule from the first cluster and the second rule from the second cluster, a comprehensive set of rules can be constructed that encompasses both secure coding best practices and potential risk patterns. These rules are then applied to the third code matching process, improving the targeted nature of detection while effectively reducing false positives and negatives. The combined analysis of the first and second matching results provides a solid basis for determining whether the third code contains vulnerabilities, significantly improving the accuracy and efficiency of vulnerability detection, ensuring software security, and optimizing the development process.

[0113] In some embodiments, the above-mentioned determination of the vulnerability detection result of the third code based on the first matching result and the second matching result can be achieved as follows: if the first matching result indicates that the third code does not have the first rule, and the second matching result indicates that the third code has the second rule, then the vulnerability detection result is determined to be that the third code has the vulnerability; if the first matching result indicates that the third code has the first rule, or the second matching result indicates that the third code does not have the second rule, then the vulnerability detection result is determined to be that the third code does not have the vulnerability.

[0114] In some embodiments, the first matching result: characterizes whether the third code complies with the security rules (first rules) extracted from the first cluster. The second matching result: characterizes whether the third code contains the potential risk rules (second rules) extracted from the second cluster. If the first matching result shows that the third code does not have the first rule, it means that the third code does not follow the security coding practice; at the same time, if the second matching result shows that the third code has the second rule, it means that the third code contains a potential risk pattern. When these two situations occur at the same time, it can be determined that the third code has a vulnerability. If the first matching result shows that the third code has the first rule, it means that the third code complies with the security coding practice; or if the second matching result shows that the third code does not have the second rule, it means that the third code does not contain a potential risk pattern. When one of these two situations occurs, it can be determined that the third code does not have a vulnerability.

[0115] As an example, in a security analysis scenario, the first rule states that all user input must be validated and sanitized to prevent cross-site scripting (XSS) attacks. The second rule states that sensitive operations must require user confirmation. Now, we have a third code segment to be tested, which contains two functional modules: Module A processes user comments but does not validate or sanitize user input. Module B modifies user account information but does not implement a second confirmation mechanism. We check whether Modules A and B comply with the first rule (user input validation and sanitization). Module A does not validate or sanitize user input, so it does not violate the first rule. Although Module B involves sensitive operations, it does not violate the first rule because it does not directly process user input. The first matching result indicates that the third code segment does not comply with the first rule. We then check whether Modules A and B comply with the second rule (secondary confirmation for sensitive operations). Module A does not involve sensitive operations, so the second rule does not apply. Module B does not implement a second confirmation mechanism and therefore meets the risk pattern defined by the second rule. The second matching result indicates that the third code segment complies with the second rule. Because the first match result indicates that the third code does not contain the first rule (a risk exists), and the second match result indicates that the third code contains the second rule (a risk exists), the detection result is determined to be a vulnerability in the third code. If the detection process is slightly different, assuming that module A implements input validation and sanitization, and module B adds a secondary confirmation mechanism: the first match result will indicate that the third code contains the first rule. The second match result will indicate that the third code does not contain the second rule. The first match result indicates that the third code contains the first rule (no risk), or the second match result indicates that the third code does not contain the second rule (no risk), so the detection result is determined to be no vulnerability in the third code.

[0116] In this way, by strictly evaluating whether the third code follows the best practices of secure coding (the first rule) and whether it contains known risk patterns (the second rule), potential vulnerabilities can be accurately identified. The dual-conditional logic judgment not only reduces false positives and improves detection accuracy, but also ensures that timely action can be taken when potential security issues are discovered.

[0117] In this way, multiple code fragments are determined by combining the first code with a vulnerability and the second code corresponding to the first code, and the first code fragment and the second code fragment are determined according to the code fragments; the first code fragment is clustered to obtain a first cluster; the second code fragment is clustered to obtain a second cluster. Since the first code fragment does not exist in the first code but exists in the second code, and the second code fragment exists in the first code and is a code fragment in the first code that is replaced by the first code fragment, the first code fragment in the first cluster is a new code fragment in the second code for repairing the fault, and the second code fragment in the second cluster is a code fragment with a fault in the first code. Vulnerability detection is performed on the third code through the first cluster and the second cluster to obtain the vulnerability detection result of the third code. Vulnerability detection of the third code is achieved through the division of the first cluster and the second cluster, so that hash calculation is not required during the detection process, thereby effectively avoiding the problem of hash collision, thereby effectively improving the accuracy of code detection.

[0118] The following describes an exemplary application of the embodiment of the present application in an actual code detection application scenario.

[0119] The main design idea of ​​this application is to extract code features by considering the core lines of code (that is, the first code snippet and the second code snippet in the first cluster and the second cluster described above) to form a semgrep rule base, and detect code cloning vulnerabilities through the rule base and the powerful semgrep engine. By collecting code security patches, the vulnerability code snippets and the patch code snippets are restored. Then, by only considering the core lines of code to extract code features, the semgrep rules are automatically generated (that is, the first rule in the first cluster and the second rule in the second cluster described above), and finally the powerful semgrep matching engine is used to efficiently detect code cloning vulnerabilities in the target program (that is, the third code described above).

[0120] See also Figure 4 , Figure 4 This is a schematic diagram of the architecture of the code detection method provided in the embodiment of the present application. The code detection method provided in the embodiment of the present application can be Figure 4 The steps 201 to 204 shown are implemented, and the following is combined Figure 4 Provide explanation.

[0121] In step 201, data is collected.

[0122] First, security patches (CVE patches) are collected. Due to the lack of an official patch management system, comprehensive security patch collection is not a simple task. Given CVE JSON feeds, this method collects patches from three data sources to improve the coverage of patch collection: GitHub repositories; Issue Tracker; and Q&A sites. For direct links, for example, CVE information pages often contain URLs to CVE patch pages. Given a CVE information page as input, this method checks direct URLs to retrieve patches. First, it searches for URLs containing the keyword "commit" or "git." Then, it uses the command "git clonerepo_url" to download the corresponding repository. Finally, it uses the command "git show commit_id" to obtain the patch file (diff file) corresponding to a CVE vulnerability. For indirect links, CVE information pages often do not contain direct patch URLs, but instead provide indirect references to web pages. These web pages contain bug IDs or commits to represent CVE patch pages. Then, the method looks for information that may link to the CVE patch page. For example, the Bug ID provided on the page. Finally, the method searches for the commits of the patch using the information extracted in the previous step. For example, if the Bug ID is provided in the previous step, the method can extract the corresponding security patch by executing the command "git log-grep='Bug ID'". This command is used to find commits related to this Bug ID, and these commits usually contain this Bug ID in the description information of the commit. For "with invisible links", although there is no visible connection between the CVE patch page and the CVE information page, the CVE patch page may contain the corresponding CVE ID.

[0123] In some embodiments, for patch collection of invisible patch links, the core idea of ​​the present application is to use user discussion information on web pages, such as Q&A sites, to search for unsafe code snippets.

[0124] In step 202, feature extraction is performed.

[0125] In some embodiments, a vulnerability code snippet (Sv) and a patch code snippet (SP) are extracted from a security patch. Given a patch file (diff file), the patch file is divided into multiple code snippets based on file delimiters. The lines of code in each code snippet are then used to determine context lines, addition lines, and subtraction lines.

[0126] Traverse all lines of code in the code snippet. If a context line (a line of code other than addition or subtraction lines in a patch code snippet) is encountered, it is added to the set of vulnerable code snippets and the set of patch code snippets. If a subtraction line is encountered, it is added to the set of vulnerable code snippets. If an addition line is encountered, it is added to the set of patch code snippets. By applying this algorithm to all code snippets, a large number of vulnerable code snippets and patch code snippets are obtained.

[0127] In the embodiments of this application, code features are essentially simplified lines of code obtained after analyzing a section of code. These lines of code can accurately represent the syntax and semantics of this section of code. Code feature extraction (Vulnerable feature extraction) follows the following principles:

[0128] Minimization principle: As more lines of code are considered, the ability to handle various types of code clone fragments will decrease. Therefore, the embodiment of the present application only considers the core line of code (core line code is the added and subtracted lines in the patch code fragment, as well as the context lines with control flow information). The minimization principle is achieved by considering only the core line of code. For a code fragment, this method does not analyze all the lines of code, but only considers the core line of code, such as the subtracted lines and the lines of code with control flow semantics. Basically, a subtracted line in the patch is included in the vulnerability feature and not all context lines are included in the vulnerability feature. Because some lines of code do not express any syntax or semantics, these lines of code can be ignored and only those lines of code representing control flow semantics are retained, such as if or while statements. Similarly, an added line and core context lines in the patch will be included in the patch feature. After obtaining the vulnerability code feature and the patch code feature, if a code fragment can match the vulnerability code feature and does not match the patch code feature, this code fragment is detected as a code clone vulnerability.

[0129] Vulnerability code signatures are features extracted from known vulnerable code. These features may include specific code patterns, function calls, data flow, control flow, and more. These features can indicate the presence of a vulnerability. When a vulnerability is discovered, developers create a patch to fix it. Patch code signatures are features extracted from this patched code that demonstrate how to correct the vulnerability. During the detection process, analysis tools examine code snippets in the tested code base to see if they match vulnerability code signatures. If so, this means the tested code may contain similar vulnerabilities. Detection tools must not only confirm that the code snippet matches the vulnerability code signature, but also that it does not match the patch code signature. This ensures that the detected code snippet is not simply a copy of the patched code, but that it actually contains potential security issues.

[0130] Flexibility principle, vulnerability features must be flexible enough to deal with variants of code cloning vulnerabilities. The flexibility principle is achieved by abstracting the variable names, variable types, and called function names in the code snippets. For example, the embodiment of the present application uses $VAR_NAME to uniformly represent variable names, $VAR_TYPE to uniformly represent variable types, and $FUNC_CALL to uniformly represent called function names. By doing so, even if the variable names, variable types, and function call names change, the characteristics of this code will not be changed because this method abstracts them. Specifically, all variable names are abstracted into $VAR_NAME. All function calls are abstracted into $FUNC_CALL, and all variable types are abstracted into $VAR_TYPE. The extracted code features can uniformly represent these changed codes. Its flexibility is increased.

[0131] In step 203, rules are generated.

[0132] In some embodiments, since some lines of code still express only a few or no syntax or semantics of any vulnerabilities, these meaningless features need to be removed. The embodiment of the present application removes meaningless features by identifying include statements, precompiled statements, and return statements. The embodiment of the present application traverses all lines of code of the feature code, and then regularly matches the keyword "include" to identify include statements. Precompiled statements are identified by regularly matching keywords "#ifdef", "#else," and "#endif". Finally, return statements are identified by regularly matching the keyword "return". Statement scenarios removed from the original features. Listing 5 shows the identified "include statement", which should be removed from the feature, and listing 6 shows the "precompiled statement", which should be removed from the feature. Listing 7 shows the "return statement", which should also be removed from the feature.

[0133] In some embodiments, after obtaining optimized features that can represent vulnerabilities, the embodiments of the present application generate semgrep rules in an automated manner. Since the rule syntax exists in the official semgrep documentation, this method automatically generates rules that conform to the semgrep rule syntax by reading code features and adding keywords such as "pattern-either", "pattern", etc. The process of automatically generating semgrep rules involves converting code features into a rule format that semgrep can understand. It is necessary to extract key code features related to the vulnerability from the patch through static code analysis or other methods. These features may include but are not limited to variable names, function calls, control flow structures, data flow structures, etc. These features need to be optimized to ensure that they can accurately represent the essence of the vulnerability rather than simply reflecting superficial code differences. In order to automatically generate semgrep rules, it is first necessary to create rule templates. These templates contain the basic structure of the semgrep rules and some placeholders to be filled with actual code features in subsequent steps. The automated tool reads the previously extracted code features and maps them to the placeholders in the rule template. In semgrep rules, specific keywords such as "pattern-either" and "pattern" are used to define different search patterns and conditions. Based on the code features and rule templates, automated tools combine the keywords with the corresponding code features to form complete rules.

[0134] In step 204, a vulnerability is discovered.

[0135] Given a target program, vulnerability signatures, patch signatures, and generated rules, this method detects code cloning vulnerabilities in the target program. First, this method reduces the code search space to improve the efficiency of vulnerability discovery. Then, this application determines that when a code fragment matches the vulnerability signature but does not match the patch signature, the code fragment is considered a code cloning vulnerability. See Figure 5 , Figure 5 This is a schematic diagram of the principle of vulnerability discovery provided by the embodiment of this application. When detecting code cloning vulnerabilities in a program with many lines of code (Target software), scanning the entire code base is a time-consuming task. Therefore, this method only considers the reused code part as the program part to be tested. Figure 5As shown, the large boxes represent the code base of the program under test, and the small boxes represent the reused open source components. In this case, this method does not scan the entire code base of the program under test, but only the reused code. The non-open source parts of the program under test are ignored and do not need to be scanned. This significantly reduces the target code base for code scanning, which greatly improves the efficiency of vulnerability discovery.

[0136] By implementing the above steps, an optimized version of the semgrep rule is obtained. By repeatedly implementing this step, the present application obtains a large number of optimized semgrep rules based on the code security patches collected in step 201 to form a semgrep rule library. Finally, the code cloning vulnerability is detected using semgrep's powerful and fast pattern matching engine.

[0137] This approach locates code vulnerabilities by searching for vulnerable code clones. By collecting patches, extracting code features, and automatically generating rules, semgrep's powerful and fast pattern recognition engine is used to rapidly scan the program under test and detect vulnerabilities. This eliminates the need to hash both the patch files and the program under test, as is required by traditional methods. This significantly improves vulnerability discovery efficiency and enhances scalability, enabling, for example, scalability to extremely large, real-world target software projects.

[0138] Use code features to accurately represent vulnerability fragments. Compared with hash-based matching methods, this method does not need to calculate hash values ​​and there is no risk of hash collision, so it can reduce the false alarm rate of code clone vulnerability mining. On the other hand, the code features proposed by this method can accurately represent the syntax and semantics of the vulnerability code. Therefore, even if the code changes (the syntax changes, the semantics remain unchanged), code clone vulnerabilities can still be detected. This also reduces the false alarm rate of code clone vulnerability mining. The combined reduction in false alarm rate and false negative rate can significantly improve the accuracy of code clone vulnerability mining.

[0139] The effectiveness of the embodiments of the present application is illustrated using a C / C++-based code patch and a tested program. In practice, the embodiments of the present application can be extended to other programming languages ​​such as Java, Python, and Go. Furthermore, the embodiments of the present application can be applied not only to vulnerability discovery scenarios for open source software and its components, but also to vulnerability discovery scenarios for closed-source web applications within a company.

[0140] The following continues to describe the exemplary structure of the code detection device 455 provided in the embodiment of the present application implemented as a software module. In some embodiments, such as Figure 2As shown, the software modules stored in the code detection device 455 of the memory 450 may include: a partitioning module, used to determine multiple code fragments based on a first code with a vulnerability and a second code corresponding to the first code, where the second code is a code after the vulnerability of the first code is repaired; determine a first code fragment and a second code fragment based on the code fragments; a clustering module, used to cluster the first code fragments to obtain a first cluster cluster; cluster the second code fragments to obtain a second cluster cluster; a detection module, used to perform vulnerability detection on a third code based on the first cluster cluster and the second cluster cluster, and obtain a vulnerability detection result of the third code, wherein the vulnerability detection result is used to characterize whether the third code has a vulnerability.

[0141] In some embodiments, the first code and the second code include multiple lines of code, and the above-mentioned division module is also used to perform the following processing on each line of code in the first code and the second code: perform semantic recognition on the code corresponding to the line to obtain the semantic recognition result of the code corresponding to the line; if the semantic recognition result indicates that the code corresponding to the line has control flow semantics, then standardize the code corresponding to the line to obtain the code fragment.

[0142] In some embodiments, the above-mentioned division module is also used to update the variable characters in the code corresponding to the line to standard characters to obtain a third code fragment; identify the characters in the third code fragment as function characters to obtain a recognition result; if the recognition result indicates that the function character does not exist in the third code fragment, the third code fragment is determined as the code fragment; if the recognition result indicates that the function character exists in the third code fragment, the function character in the third code fragment is updated to a standard function character to obtain the code fragment.

[0143] In some embodiments, the second code includes part of the first code and the first code fragment; the above-mentioned clustering module is also used to perform the following processing for each of the code fragments: if the code fragment does not exist in the first code but exists in the second code, the code fragment is determined to be the first code fragment; if the code fragment exists in the first code and does not exist in the second code, the code fragment is determined to be the second code fragment; if the code fragment exists in the first code and exists in the second code, the code fragment is determined to be the first code fragment and the second code fragment.

[0144] In some embodiments, the second code includes the first code and the first code fragment, and the first code includes a second code fragment corresponding one-to-one to the first code fragment; the above-mentioned clustering module is also used to perform the following processing for each of the code fragments: if the code fragment does not exist in the first code and exists in the second code, the code fragment is determined to be the first code fragment, and the code fragment corresponding to the code fragment in the first code is determined to be the second code fragment; if the code fragment exists in the first code and exists in the second code, and the first code fragment corresponding to the code fragment does not exist in the second code, the code fragment is determined to be the first code fragment and the second code fragment.

[0145] In some embodiments, the above-mentioned detection module is also used to delete redundant code fragments in the first cluster to obtain a third cluster, and delete redundant code fragments in the second cluster to obtain a fourth cluster; based on the third cluster and the fourth cluster, perform vulnerability detection on the third code to obtain a vulnerability detection result of the third code.

[0146] In some embodiments, the above-mentioned detection module is also used to extract rules from the first cluster to obtain a first rule in the first cluster, and to extract rules from the second cluster to obtain a second rule in the second cluster; match the first rule with the third code to obtain a first matching result for characterizing whether the third code contains the first rule; match the second rule with the third code to obtain a second matching result for characterizing whether the third code contains the second rule; and determine the vulnerability detection result of the third code based on the first matching result and the second matching result.

[0147] In some embodiments, the above-mentioned detection module is also used to determine that the vulnerability detection result is that the third code has the vulnerability if the first matching result indicates that the third code does not have the first rule, and the second matching result indicates that the third code has the second rule; if the first matching result indicates that the third code has the first rule, or the second matching result indicates that the third code does not have the second rule, then determine that the vulnerability detection result is that the third code does not have the vulnerability.

[0148] An embodiment of the present application provides a computer program product, which includes a computer program or computer-executable instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer-executable instructions from the computer-readable storage medium and executes the computer-executable instructions, causing the electronic device to perform the code detection method described above in the embodiment of the present application.

[0149] The embodiment of the present application provides a computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, the processor will execute the code detection method provided by the embodiment of the present application, for example, Figure 3 The code detection method shown.

[0150] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface storage, optical disk, or CD-ROM; or various electronic devices including one or any combination of the above memories.

[0151] In some embodiments, computer-executable instructions may be in the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0152] As an example, computer-executable instructions may, but need not, correspond to a file in a file system, may be stored as part of a file that stores other programs or data, such as, for example, in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple coordinating files (e.g., files storing one or more modules, subroutines, or code portions).

[0153] By way of example, computer-executable instructions may be deployed to be executed on one electronic device, or on multiple electronic devices located at one site, or on multiple electronic devices distributed across multiple sites and interconnected by a communication network.

[0154] In summary, the embodiments of the present application have the following beneficial effects:

[0155] (1) A plurality of code fragments are determined by combining a first code with a vulnerability and a second code corresponding to the first code, and a first code fragment and a second code fragment are determined based on the code fragments; the first code fragment is clustered to obtain a first cluster; the second code fragment is clustered to obtain a second cluster. Since the first code fragment does not exist in the first code but exists in the second code, and the second code fragment exists in the first code and is a code fragment in the first code that is replaced by the first code fragment, the first code fragment in the first cluster is a code fragment newly added in the second code for repairing the fault, and the second code fragment in the second cluster is a code fragment with a fault in the first code. Vulnerability detection is performed on the third code through the first cluster and the second cluster to obtain a vulnerability detection result of the third code. Vulnerability detection of the third code is achieved through the division of the first cluster and the second cluster, so that hash calculation is not required during the detection process, thereby effectively avoiding the problem of hash collision and effectively improving the accuracy of code detection.

[0156] (2) Through semantic recognition, we can deeply understand the actual function and intention of the code, which helps to discover potential security vulnerabilities, performance bottlenecks, and logical errors. Standardizing lines of code with clear semantics not only enhances the readability and consistency of the code, but also improves the robustness and maintainability of the code. Standardized code snippets reduce the impact of personalized coding styles, making the code base more neat and tidy, and facilitating the integration of new team members and inter-team collaboration. This improves code quality, shortens the development cycle, and reduces maintenance costs.

[0157] (3) Updating the variable characters in the code to standard characters helps unify variable naming, making the code more standardized and consistent, and easier for developers to understand and maintain. This consistency also reduces confusion and errors caused by inconsistent variable naming. Identifying and standardizing the function characters in the third code snippet ensures that the function names used in the code meet the predetermined standards, which helps improve the readability of the code and also keeps the code style consistent. If the identification result shows that there are no non-standard function characters in the code snippet, it can be confirmed that the code has met the standardization requirements and no further modification is required. If there are non-standard function characters, by updating them to standard function characters, the standardization and maintainability of the code are further improved, which not only optimizes the appearance of the code, but also improves the quality of the code and the efficiency of team collaboration, which is of great significance for ensuring the sustainable development of the code and reducing long-term maintenance costs.

[0158] (4) By sending code collection instructions to multiple data sources and receiving the returned collection results, not only can detailed information about the code be collected comprehensively and timely, thereby improving the coverage of vulnerability detection, but also the vulnerability management process can be simplified in a centralized manner. Based on these collection results, the first code containing the vulnerability and its corresponding second code that has been repaired can be accurately identified. Such accuracy greatly improves the efficiency of vulnerability response and helps track the life cycle of the vulnerability from discovery to repair, thereby reducing security risks, ensuring the stability of the software and user trust, reducing potential attack surfaces, and laying a solid foundation for maintaining code quality and improving software security.

[0159] (5) Through precise code snippet clustering, the newly added code, removed code, and retained or modified code during the code repair process are distinguished, allowing the development team to quickly identify the hot spots of the change and gain a deeper understanding of the details and impact of the repair. This not only optimizes the code review process and improves code quality, but also enhances the effectiveness assessment of security repair measures. It provides a clear change history and reference basis for subsequent code maintenance and function expansion, thereby ensuring software security and reliability while reducing long-term maintenance costs.

[0160] (6) It can effectively identify and separate the code snippets that are newly added to the first code, as well as those that are replaced or modified in subsequent development, thereby helping developers to quickly locate and understand the history and reasons for code changes. It can also maintain the integrity of the code structure because it also considers the correspondence between code snippets, ensuring that related code snippets can be accurately classified into corresponding clusters. This clustering strategy helps to improve the efficiency of code analysis and maintenance because it automatically distinguishes different parts of the code.

[0161] (7) By removing the code snippets containing keywords from the first and second clusters, we formed the more refined third and fourth clusters, effectively eliminating code patterns that are widely considered safe and reducing the false positive rate, allowing the development team to focus on addressing real potential vulnerabilities. This also improved detection efficiency, reduced unnecessary detection burden, and ultimately ensured the reliability of vulnerability detection results, strengthened software security, and provided a more solid security defense line.

[0162] (8) By implementing the open source identification process, the open source parts of the third code can be effectively distinguished from the closed source parts. Once the open source code parts of the third code are identified, the existing security review results of the open source community can be utilized to reduce the vulnerability detection work on these parts, thereby optimizing resource allocation. At the same time, based on the security rules and patterns provided by the first cluster and the second cluster, targeted vulnerability detection is performed on the open source parts of the third code, which not only improves the accuracy and efficiency of the detection, but also ensures that the security of this part of the code is fully evaluated.

[0163] (9) By extracting the first rule from the first cluster and the second rule from the second cluster, a comprehensive set of rules can be constructed that includes both the best practices of secure coding and potential risk patterns. Subsequently, these rules are applied to the matching process of the third code, which not only improves the targetedness of the detection, but also effectively reduces false positives and false negatives. The combined analysis of the first matching results and the second matching results provides a solid basis for determining whether the third code has vulnerabilities, thereby significantly improving the accuracy and efficiency of vulnerability detection, ensuring the security of the software, and optimizing the development process.

[0164] (10) By rigorously evaluating whether the third code follows the best practices of secure coding (the first rule) and whether it contains known risk patterns (the second rule), potential vulnerabilities can be accurately identified. The dual-conditional logic judgment not only reduces false positives and improves detection accuracy, but also ensures that timely action can be taken when potential security issues are discovered.

[0165] (11) This method locates code vulnerabilities by searching for vulnerable code clones. By collecting patches, extracting code features, and automatically generating rules, it uses semgrep's powerful and fast pattern recognition engine to quickly scan the program under test and detect vulnerabilities. Unlike traditional methods, it does not require hashing both the patch file and the program under test, thus significantly improving the efficiency of vulnerability mining. It also enhances its scalability, for example, to large-scale real-world target software projects.

[0166] (12) Use code features to accurately represent vulnerability fragments. Compared with hash-based matching methods, this method does not need to calculate hash values ​​and there is no risk of hash collision, so it can reduce the false positive rate of code clone vulnerability mining. On the other hand, the code features proposed by this method can accurately represent the syntax and semantics of the vulnerability code. Therefore, even if the code changes (the syntax changes, the semantics remain unchanged), code clone vulnerabilities can still be detected. This also reduces the false negative rate of code clone vulnerability mining. The combined reduction in false positive rate and false negative rate can significantly improve the accuracy of code clone vulnerability mining.

[0167] The above description is merely an embodiment of the present application and is not intended to limit the scope of protection of the present application. Any modifications, equivalent replacements, and improvements made within the spirit and scope of the present application are included in the scope of protection of the present application.

Claims

1. A code detection method, characterized in that: The method comprises: Determining a plurality of code segments based on a first code having a vulnerability and a second code corresponding to the first code, where the second code is a code obtained by fixing the vulnerability in the first code; determining a first code segment and a second code segment according to the code segment; Clustering the first code snippets to obtain a first cluster; Clustering the second code snippets to obtain a second cluster; Based on the first cluster and the second cluster, vulnerability detection is performed on the third code to obtain a vulnerability detection result of the third code.

2. The method according to claim 1, characterized in that The determining of multiple code snippets based on the first code having a vulnerability and the second code corresponding to the first code includes: The following processing is performed for each line of code in the first code and the second code respectively: Performing semantic recognition on the code corresponding to the row to obtain a semantic recognition result of the code corresponding to the row; If the semantic recognition result indicates that the code corresponding to the line has control flow semantics, the code corresponding to the line is standardized to obtain the code snippet.

3. The method according to claim 2, characterized in that The step of standardizing the code corresponding to the row to obtain the code snippet includes: Update the variable characters in the code corresponding to the line to standard characters to obtain a third code fragment; Performing function character recognition on the characters in the third code fragment to obtain a recognition result; If the recognition result indicates that the function character does not exist in the third code fragment, determining the third code fragment as the code fragment; If the recognition result indicates that the function character exists in the third code fragment, the function character in the third code fragment is updated to a standard function character to obtain the code fragment.

4. The method according to claim 1, wherein The second code includes part of the first code and the first code fragment; Determining the first code segment and the second code segment according to the code segment includes: The following processing is performed for each code snippet: If the code fragment does not exist in the first code but exists in the second code, determining the code fragment as the first code fragment; If the code fragment exists in the first code but does not exist in the second code, determining the code fragment as the second code fragment; If the code fragment exists in the first code and exists in the second code, the code fragment is determined to be the first code fragment and the second code fragment.

5. The method according to claim 1, wherein The second code includes the first code and the first code fragment, and the first code includes a second code fragment corresponding to the first code fragment in a one-to-one manner; Determining the first code segment and the second code segment according to the code segment includes: The following processing is performed for each code snippet: If the code snippet does not exist in the first code but exists in the second code, determining the code snippet as the first code snippet, and determining a code snippet in the first code corresponding to the code snippet as the second code snippet; If the code fragment exists in the first code and the second code, and there is no first code fragment corresponding to the code fragment in the second code, the code fragment is determined to be the first code fragment and the second code fragment.

6. The method according to claim 1, characterized in that The performing vulnerability detection on the third code based on the first cluster and the second cluster to obtain a vulnerability detection result of the third code includes: Deleting redundant code snippets in the first cluster to obtain a third cluster, and deleting redundant code snippets in the second cluster to obtain a fourth cluster; Based on the third cluster and the fourth cluster, vulnerability detection is performed on the third code to obtain a vulnerability detection result of the third code.

7. The method according to claim 1, characterized in that The performing vulnerability detection on the third code based on the first cluster and the second cluster to obtain a vulnerability detection result of the third code includes: Performing rule extraction on the first cluster to obtain a first rule in the first cluster, and performing rule extraction on the second cluster to obtain a second rule in the second cluster; Matching the first rule with the third code to obtain a first matching result indicating whether the third code contains the first rule; Matching the second rule with the third code to obtain a second matching result indicating whether the third code contains the second rule; A vulnerability detection result of the third code is determined based on the first matching result and the second matching result.

8. The method according to claim 7, characterized in that The determining, based on the first matching result and the second matching result, a vulnerability detection result of the third code includes: If the first matching result indicates that the third code does not have the first rule, and the second matching result indicates that the third code has the second rule, determining that the vulnerability detection result is that the third code has the vulnerability; If the first matching result indicates that the third code has the first rule, or the second matching result indicates that the third code does not have the second rule, then the vulnerability detection result is determined to be that the third code does not have the vulnerability.

9. A code detection device, characterized in that: The device comprises: a partitioning module, configured to determine a plurality of code segments based on a first code having a vulnerability and a second code corresponding to the first code, wherein the second code is a code obtained by fixing the vulnerability of the first code; and determine a first code segment and a second code segment based on the code segments; a clustering module, configured to cluster the first code snippets to obtain a first cluster; and cluster the second code snippets to obtain a second cluster; A detection module is configured to perform vulnerability detection on a third code based on the first cluster and the second cluster to obtain a vulnerability detection result of the third code.

10. An electronic device, characterized in that: The electronic device comprises: a memory for storing computer-executable instructions or computer programs; The processor is configured to implement the code detection method according to any one of claims 1 to 8 when executing the computer-executable instructions or computer program stored in the memory.

11. A computer-readable storage medium storing computer-executable instructions or a computer program, characterized in that: When the computer executable instructions or computer program are executed by a processor, the code detection method according to any one of claims 1 to 8 is implemented.

Images