A source code security defect analysis method and device

Abstract

The application provides a source code security defect analysis method and device, the method comprises the following steps: slicing the to-be-tested source code according to the semantic information of the to-be-tested source code, and generating defect characteristic values corresponding to each to-be-tested slice; determining a defect matching set of the to-be-tested source code according to a preset security defect analysis index and the defect characteristic values corresponding to each to-be-tested slice; analyzing the security defect of the to-be-tested source code according to the security defect analysis index and the defect matching set, obtaining a security state rating of the to-be-tested source code, and maintaining the to-be-tested source code according to the security state rating. The application can objectively evaluate the security defect existing in the to-be-tested source code.

Description

Technical Field

[0001] This application relates to the field of computer source code analysis, specifically a method and apparatus for analyzing source code security flaws. Background Technology

[0002] With the development of computer and communication technologies, network security is facing unprecedented challenges. The greatest threat to network security is often vulnerabilities in source code. However, many companies are unaware of which vulnerable open-source components their software uses, and the number of vulnerabilities in these components continues to grow. Therefore, scholars have conducted research on source code defect detection, evolving from early methods based on string matching and lexical analysis to semantic analysis, and now to common methods like data flow, control flow analysis, and symbolic execution. Before detecting source code defects, massive amounts of source code need to be processed through methods such as program slicing to obtain more accurate samples. There are many methods for program slicing, such as data flow equation slicing based on data flow analysis and reachability analysis slicing based on program dependency graphs. However, these methods only utilize a single characteristic of the source code, thus failing to generate more accurate source code detection results through slicing. Although source code defect detection techniques are abundant, there is a lack of research evaluating the impact of defects on software security performance, especially the overall quantitative evaluation of source code security defects. Furthermore, because the correlation between the impact of various defects in the source code on software security varies, equal analysis of all defects in the source code cannot provide a relatively objective evaluation of source code security defects. Summary of the Invention

[0003] To address the problems in the prior art, this application provides a source code security defect analysis method and apparatus that can objectively evaluate the security defects existing in the source code under test.

[0004] To solve the above-mentioned technical problems, this application provides the following technical solution:

[0005] Firstly, this application provides a source code security flaw analysis method, including:

[0006] The source code to be tested is sliced ​​based on the semantic information of the source code to be tested, and defect feature values ​​corresponding to each slice are generated.

[0007] The defect matching set of the source code to be tested is determined based on the preset security defect analysis indicators and the defect feature values ​​corresponding to each slice to be tested;

[0008] The security defects of the source code under test are analyzed based on the security defect analysis indicators and the defect matching set to obtain a security status rating of the source code under test, and the source code under test is maintained based on the security status rating.

[0009] Further, the step of slicing the source code under test based on its semantic information and generating defect feature values ​​corresponding to each slice includes:

[0010] The source code to be tested is subjected to noise removal; wherein, the source code to be tested after noise removal does not contain declarations, announcements and comments;

[0011] Analyze the noise-removed source code of the test and generate the corresponding code attribute map;

[0012] The source code to be tested is sliced ​​based on the semantic information in the code attribute graph to obtain the slice to be tested;

[0013] Defect feature values ​​corresponding to each of the tested slices are generated using a hash function.

[0014] Further, determining the defect matching set of the source code to be tested based on preset security defect analysis indicators and defect feature values ​​corresponding to each slice to be tested includes:

[0015] By comparing the historical defect feature values ​​corresponding to each historical slice of the historical source code with the defect feature values ​​corresponding to each slice under test, the security defects existing in each slice under test can be determined.

[0016] Match the security defects existing in each of the test slices with the first-tier indicators in the security defect analysis indicators, and determine whether the security defects existing in each of the test slices are high-risk defects; wherein, the first-tier indicators correspond to high-risk defects;

[0017] Based on the matching results, a defect matching set is generated for the source code to be tested.

[0018] Further, generating the defect matching set of the source code to be tested based on the matching results includes:

[0019] If the security defects existing in each of the test slices are determined to be high-risk defects, then a first set of successful matches is generated based on the security defects existing in each of the test slices and the first echelon indicators.

[0020] If the security defects existing in each of the test slices are determined to be low-risk defects, then the security defects existing in each of the test slices are matched with the second-tier indicators in the security defect analysis indicators to generate a second successful matching set.

[0021] Further, the step of analyzing the security defects of the source code under test based on the security defect analysis indicators and the defect matching set to obtain the security status rating of the source code under test includes:

[0022] Construct a safety status decision matrix based on the security defect analysis indicators and the defect matching set;

[0023] The weights and corresponding trade-off values ​​of each security defect analysis index are determined using the security status decision matrix.

[0024] The security status score of the source code under test is calculated based on the weights of each security defect analysis index and the corresponding trade-off values.

[0025] The security status rating is determined based on the preset security status rating strategy and the security status score.

[0026] Secondly, this application provides a source code security defect analysis device, comprising:

[0027] The slicing and feature value generation unit is used to slice the source code to be tested according to the semantic information of the source code to be tested, and generate defect feature values ​​corresponding to each slice to be tested.

[0028] The feature set generation unit is used to determine the defect matching set of the source code to be tested based on the preset security defect analysis indicators and the defect feature values ​​corresponding to each slice to be tested;

[0029] The security status rating unit is used to analyze the security defects of the source code under test according to the security defect analysis index and the defect matching set, obtain the security status rating of the source code under test, and maintain the source code under test according to the security status rating.

[0030] Furthermore, the slicing and feature value generation unit includes:

[0031] The noise removal module is used to remove noise from the source code under test; wherein the source code under test after noise removal does not contain declarations, announcements and comments;

[0032] The attribute graph generation module is used to parse the source code under test after noise removal and generate the corresponding code attribute graph.

[0033] The test slice generation module is used to slice the source code to be tested according to the semantic information in the code attribute diagram to obtain the test slice;

[0034] The feature value calculation module is used to generate defect feature values ​​corresponding to each of the slices to be tested using a hash function.

[0035] Further, the feature set generation unit includes:

[0036] The security defect determination module is used to compare the historical defect feature values ​​corresponding to each historical slice of the historical source code with the defect feature values ​​corresponding to each slice to be tested, so as to determine the security defects existing in each slice to be tested.

[0037] The security defect matching module is used to match the security defects existing in each of the test slices with the first-tier indicators in the security defect analysis indicators, and to determine whether the security defects existing in each of the test slices are high-risk defects; wherein, the first-tier indicators correspond to high-risk defects.

[0038] The feature set generation module is used to generate a defect matching set of the source code to be tested based on the matching results.

[0039] Furthermore, the feature set generation module includes:

[0040] The first feature set generation submodule is used to generate a first matching success set based on the security defects of each slice under test and the first echelon index when it is determined that the security defects of each slice under test are high-risk defects.

[0041] The second feature set generation submodule is used to match the security defects of each of the test slices with the second-tier indicators in the security defect analysis indicators when the security defects of each test slice are determined to be low-risk defects, so as to generate a second successful matching set.

[0042] Furthermore, the security status rating unit includes:

[0043] The decision matrix generation module is used to construct a safety status decision matrix based on the safety defect analysis indicators and the defect matching set.

[0044] The weight and trade-off calculation module is used to determine the weight and corresponding trade-off value of each of the security defect analysis indicators using the security status decision matrix;

[0045] The status score calculation module is used to calculate the security status score of the source code under test based on the weights of each security defect analysis index and the corresponding trade-off values.

[0046] The security status rating module is used to determine the security status rating based on a preset security status rating strategy and the security status score.

[0047] Thirdly, this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the source code security defect analysis method under test.

[0048] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method for analyzing security flaws in the source code under test.

[0049] Fifthly, this application provides a computer program product, including a computer program / instructions, which, when executed by a processor, implement the steps of the source code security defect analysis method under test.

[0050] To address the problems in existing technologies, the source code security defect analysis method and apparatus provided in this application can perform an overall quantitative evaluation of source code security defects based on the source code security defect analysis index of "security vulnerability + code quality defects", providing a basis for subsequent source code maintenance work; it can combine code attribute graphs with slice feature values ​​to perform defect matching and overall quantitative evaluation in stages, thereby establishing the overall quantitative evaluation of source code on a precise, efficient and objective basis. Attached Figure Description

[0051] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0052] Figure 1 This is a flowchart of the source code security defect analysis method in the embodiments of this application;

[0053] Figure 2 This is a flowchart illustrating the generation of defect feature values ​​corresponding to each slice to be tested in this embodiment of the application.

[0054] Figure 3 This is a flowchart illustrating the process of determining the defect matching set of the source code to be tested in an embodiment of this application;

[0055] Figure 4 This is a flowchart illustrating the process of generating a defect matching set for the source code to be tested, as described in this embodiment of the application.

[0056] Figure 5 This is a flowchart illustrating the security status rating of the source code under test in this embodiment of the application.

[0057] Figure 6 This is a structural diagram of the source code security defect analysis device in the embodiments of this application;

[0058] Figure 7 This is a structural diagram of the slicing and feature value generation unit in the embodiments of this application;

[0059] Figure 8 This is a structural diagram of the feature set generation unit in the embodiments of this application;

[0060] Figure 9 This is a structural diagram of the feature set generation module in an embodiment of this application;

[0061] Figure 10 This is a structural diagram of the security status rating unit in the embodiments of this application;

[0062] Figure 11 This is a schematic diagram of the structure of the electronic device in the embodiments of this application;

[0063] Figure 12 This is a schematic diagram of the overall process of an embodiment of this application;

[0064] Figure 13 This is a schematic diagram of source code security defect analysis indicators in the embodiments of this application;

[0065] Figure 14 This is a schematic diagram illustrating the process of generating the slice defect matching set in an embodiment of this application;

[0066] Figure 15 This is a flowchart illustrating the calculation of source code security evaluation values ​​and their status in embodiments of this application. Detailed Implementation

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

[0068] In one embodiment, see Figure 1 In order to objectively evaluate the security flaws existing in the source code under test, this application provides a source code security flaw analysis method, including:

[0069] S101: The source code to be tested is sliced ​​according to the semantic information of the source code to be tested, and defect feature values ​​corresponding to each slice are generated.

[0070] S102: Determine the defect matching set of the source code to be tested based on the preset security defect analysis indicators and the defect feature values ​​corresponding to each slice to be tested;

[0071] S103: Analyze the security defects of the source code under test according to the security defect analysis index and the defect matching set, obtain the security status rating of the source code under test, and maintain the source code under test according to the security status rating.

[0072] Understandably, given the numerous source code security issues emerging in the software development industry and the continuous need for improvement to address these vulnerabilities, providing a scientific and comprehensive method for evaluating source code security flaws is crucial for their detection. This application provides a source code security evaluation method based on a dual-factor coupling of "security vulnerability + code quality defect," which assists software developers in statistically analyzing the current security status of software based on source code security evaluation results. This plays a vital role in discovering and promptly fixing software vulnerabilities.

[0073] Specifically, this embodiment first pre-defines a set of security defect analysis indicators based on the coupling of two factors: "security vulnerability + code quality defects"; then, it slices the source code to be tested according to the semantic information of the source code to be tested, and generates defect feature values ​​corresponding to each slice; finally, it analyzes the security defects of the source code to be tested according to the security defect analysis indicators and defect matching set, and obtains the security status rating of the source code to be tested, so as to maintain the source code to be tested according to the security status rating. For details, see [link to specific process]. Figure 12 As shown.

[0074] It should be noted that, Figure 13 The analysis indicators for source code security flaws are shown. These indicators are set based on relevant public vulnerability dictionaries, security vulnerability sharing platforms, published vulnerability databases, and security vulnerability scanning analysis results from professional source code scanning tools, and can meet the needs of performing full performance analysis on the target system (source code under test).

[0075] Specifically, see Figure 13 The source code security defect analysis indicators are divided into two main categories (security vulnerabilities and code quality defects), 22 subcategories, and 51 analysis indicators.

[0076] Source code security vulnerability analysis indicators are divided into two main categories: security vulnerabilities and code quality defects. Security vulnerabilities include 14 primary indicators and 32 secondary indicators; code quality defects include 8 primary indicators and 19 secondary indicators. The 14 primary indicators for security vulnerabilities are: open-source frameworks, default configuration security, authentication and authorization, communication security, database security, sensitive information leakage, error handling, input validation, minimal privileges, API misuse, output validation, memory management (C / C++), session management, and logging issues.

[0077] The 32 secondary indicators of security vulnerabilities are: Struts errors, misconfiguration, missing configuration, user access control, resource access control, password and credential management, data communication security, data transmission protection issues, database access issues, database operation issues (such as SQL injection), unencrypted sensitive information, other operations that lead to the leakage of sensitive information, inappropriate error handling, command injection, resource injection, configuration manipulation, insecure serialization, insecure reflection, resource access permissions, file permissions, user permission issues, inappropriate use of EJB, inappropriate use of J2EE, undetected null, violation of the object model, various types of cross-site scripting, buffer overflow, memory leak, unreleased resources, session persistence, inter-session information leakage in multi-threaded environments, and inappropriate use of logs.

[0078] The eight primary indicators of code quality defects are: logical errors, runtime errors, performance issues (JAVA), coding style, maintainability and portability issues, testing and redundant code, complexity issues, and robustness issues.

[0079] The 19 secondary indicators of code quality defects are: code errors, program execution, program data, abnormal program status, resource consumption, denial of service, coding style, coding naming, writing style related issues, magic numbers, constant values ​​in conditional statements, omission of curly braces, legacy test code, test files, redundant code, invalid code, too many parameters, too many nesting levels, and unstable operation.

[0080] Based on the above security defect analysis indicators, the security defects of the source code under test can be analyzed, and the security status rating of the source code under test can be obtained. The specific method is described in detail below.

[0081] As can be seen from the above description, the source code security defect analysis method provided in this application can perform an overall quantitative evaluation of the security defects of the source code based on the source code security defect analysis index of "security vulnerability + code quality defects", providing a basis for subsequent source code maintenance work; it can combine code attribute graphs with slice feature values ​​to perform defect matching and overall quantitative evaluation in stages, thereby making the overall quantitative evaluation of the source code based on accuracy, efficiency and objectivity.

[0082] In one embodiment, see Figure 2 The source code under test is sliced ​​based on its semantic information, and defect feature values ​​corresponding to each slice are generated, including:

[0083] S201: Noise removal is performed on the source code to be tested; wherein, the noise-removed source code to be tested does not contain declarations, announcements, or comments; after noise removal, some useless declarations, announcements, or comments can be removed, so that the source code to be tested only contains source code related to its operation, which can reduce the amount of code data and the error rate of code data preparation, thereby improving the accuracy of subsequent source code testing. Specifically, code analysis tools (such as angr) can be used to analyze the source code to be tested to obtain the source code related to its operation, and then remove source code that is not related to operation (such as declarations, announcements, or comments), thereby improving the accuracy of subsequent source code testing.

[0084] S202: Analyze the source code to be tested after noise removal and generate the corresponding code attribute map;

[0085] S203: The source code to be tested is sliced ​​according to the semantic information in the code attribute diagram to obtain the slice to be tested; a static program slicing tool such as WALA can be used to slice the source code to be tested.

[0086] S204: Use a hash function to generate the defect feature values ​​corresponding to each of the slices to be tested.

[0087] It is understandable that steps S201 to S204 are the process of preparing data.

[0088] Specifically, the source of the source code data to be tested is the target system, where the program corresponding to the source code to be tested runs. The source program (source code to be tested) corresponding to the target system has not been analyzed before executing the method provided in this application. A software compiler running on the target system can compile the source code to be tested. The compiled source code to be tested can run on the target system. The software compiler is divided into a front-end (input source code) and a back-end (output target code). The target code is the output of different operations performed on the source code according to different target machines.

[0089] This application embodiment provides the source code of the target system through a software compiler front-end, providing a data foundation for subsequent testing and evaluation. All source code involved in the data preparation process is the source code to be tested. The data preparation process consists of four steps: source code noise removal, source code semantic information extraction, source code slicing, and slice feature value calculation.

[0090] The specific data preparation steps are as follows:

[0091] (1) Source code noise removal

[0092] Noise stored in source code snippets can be easily exploited to interfere with the source code detection process and affect the inspection results. Examples include useless declarations, announcements, or comments. To improve the accuracy and speed of subsequent source code matching against defect databases, some worthless code snippets mixed in with the source code are removed.

[0093] (2) Extraction of semantic information from source code (code attribute maps can be generated using code analysis tools such as Joern).

[0094] Semantic information extraction involves parsing source code and generating a code property graph (CPG). CPG integrates abstract syntax trees (AST), control flow graphs (CFG), and program dependence graphs (PDG) into a single data structure. This allows us to obtain relatively comprehensive and crucial information during graph traversal, facilitating subsequent auditing or management teams to understand the control flow of each function in the source code and to perform vulnerability remediation.

[0095] (3) Source code slicing

[0096] Currently, program slicing has become an indispensable step in solving software security and quality issues. Program slicing is a method for simplifying program decomposition, identifying core elements of a software program and extracting them from complex code, thereby saving significant time and cost. Static program slicing tools such as WALA can be used to slice the source code.

[0097] (4) Calculation of slice eigenvalues

[0098] The feature value calculation uses the Simhash algorithm, which excels in deduplication of massive amounts of text. Compared to traditional hashing, its digital signature can characterize the similarity of the original content to a certain extent, and text content with high similarity will also have relatively close digital hash signatures.

[0099] When faced with source code slices in the big data dimension, the first step is to extract the AST from the CPG to which the slice belongs and convert it into plain text content. Then, the Simhash algorithm is used to map it into numbers (hash signatures). Similar numbers are removed to remove duplicates, thus completing the task of extracting slice feature values.

[0100] As can be seen from the above description, the source code security defect analysis method provided in this application can slice the source code to be tested according to the semantic information of the source code to be tested, and generate defect feature values ​​corresponding to each slice to be tested.

[0101] In one embodiment, see Figure 3 The step of determining the defect matching set of the source code to be tested based on preset security defect analysis indicators and defect feature values ​​corresponding to each slice to be tested includes:

[0102] S301: Compare the historical defect feature values ​​corresponding to each historical slice of the historical source code with the defect feature values ​​corresponding to each slice to be tested, in order to determine the security defects existing in each slice to be tested;

[0103] S302: Match the security defects existing in each of the test slices with the first-tier indicators in the security defect analysis indicators, and determine whether the security defects existing in each of the test slices are high-risk defects; wherein, the first-tier indicators correspond to high-risk defects;

[0104] S303: Generate a defect matching set for the source code to be tested based on the matching results.

[0105] In one embodiment, see Figure 4 When performing step S303, if it is determined that the security defects existing in each of the test slices are high-risk defects, then a first successful matching set is generated based on the security defects existing in each of the test slices and the first echelon indicators (S401); if it is determined that the security defects existing in each of the test slices are low-risk defects, then the security defects existing in each of the test slices are matched with the second echelon indicators in the security defect analysis indicators to generate a second successful matching set (S402).

[0106] Understandably, the first step is to compare the historical defect feature values ​​corresponding to each historical slice of the historical source code with the defect feature values ​​corresponding to each slice under test to determine the security defects present in each slice under test, which is essentially the detection result of each slice under test. Specifically, the method involves first retrieving the historical defect feature values ​​corresponding to each historical slice of the historical source code from the historical information system, and then using a similarity algorithm to compare the historical defect feature values ​​corresponding to each historical slice with the defect feature values ​​corresponding to each slice under test. If the defect feature value corresponding to a slice under test has a very high similarity to the historical defect feature value corresponding to a historical slice, then it is considered that the security defect present in the slice under test is the same as the security defect present in the historical slice.

[0107] Specifically, the historical defect feature values ​​corresponding to each historical slice and the defect feature values ​​corresponding to each slice under test are both obtained using the Simhash algorithm. This algorithm maps text to a 64-bit binary string and then represents the differences in text content by comparing the differences between the binary strings. The similarity between two Simhash hashes is compared by the number of different binary (01) values ​​they correspond to; this is called using Hamming distance to compare similarity (e.g., 10101 and 00110 differ in the first, fourth, and fifth bits respectively, so the Hamming distance is 3). Empirically, for 64-bit SimHash hashes, a Hamming distance within 3 is considered to indicate a relatively high similarity.

[0108] Identifying the security defects in each slice under test is equivalent to determining the detection results of each slice. Next, the formation of the defect matching set requires matching the detection results of the source code under test (i.e., the detection results of m slices under test) with the defect database. The defect database is a set of preset security defect analysis indicators. The defect matching set is specifically represented by the names of secondary indicators in the analysis indicator system and their frequency of occurrence, as shown in formula (1).

[0109]

[0110] In the formula, The vulnerability / defect in the i-th slice detection result belongs to the a-th secondary indicator l and appears s times. The order 'a' of the secondary indicators l is based on the established analysis indicator system, prioritizing security vulnerabilities over code quality defects, and proceeding from left to right. For example, user access control issues are l4.

[0111] This application proposes a tiered defect database matching mechanism to improve the efficiency of defect set generation and promptly identify source code under test that is at a high risk. See also... Figure 14 The specific process for generating the defect matching set is as follows:

[0112] Step 1: After retrieving slice feature values ​​from the massive code feature value database comprised of historical information systems, the detection results for a total of m slices are obtained, which represent the detection results of the source code. (This step corresponds to S301)

[0113] Step 2: Matching the source code inspection results (inspection results of m slices) with the first-tier defect indicators. For defects with high frequency and high risk that have been published by relevant authoritative institutions, eight secondary indicators were selected from the established analysis indicator system as the first-tier defect indicators for matching. The names of the eight selected secondary indicators are shown in Table 1; see [link to Table 1] for details. Figure 13 As shown.

[0114] Table 1. Eight selected source code defects

[0115]

[0116]

[0117] Step 3: Each slice obtains its first successful matching set 1.

[0118] Step 4: Determine if the number of defect indicators in the successful matching set 1 of the slice is greater than 4. If not, proceed to step 5; otherwise, proceed to step 8.

[0119] Step 5: Match the source code detection results (detection results of m slices) with the second-tier defect indicators (43 secondary indicators).

[0120] Step 6: Each slice obtains its own second successful matching set 2.

[0121] Step 7: The successful matching sets 1 and 2 of each slice together form the defect matching set of the slice itself.

[0122] Step 8: Determine if the number of slices with more than 4 defect indicators in the successfully matched set 1 is greater than m / 2. If so, proceed to step 9; otherwise, proceed to step 5 (wherein, after proceeding to step 5, step 6 and step 7 are then performed to finally obtain the defect matching set).

[0123] Step 9: Output the security status of the source code of the target under test as highly dangerous; the security defects existing in the corresponding slice under test are high-risk defects.

[0124] As can be seen from the above description, the source code security defect analysis method provided in this application can determine the defect matching set of the source code to be tested based on the preset security defect analysis indicators and the defect feature values ​​corresponding to each slice to be tested.

[0125] In one embodiment, see Figure 5 The step of analyzing the security defects of the source code under test based on the security defect analysis indicators and the defect matching set to obtain the security status rating of the source code under test includes:

[0126] S501: Construct a safety status decision matrix based on the safety defect analysis indicators and the defect matching set;

[0127] S502: Use the safety status decision matrix to determine the weights and corresponding trade-off values ​​of each of the safety defect analysis indicators;

[0128] S503: Calculate the security status score of the source code under test based on the weights of each security defect analysis index and the corresponding trade-off values;

[0129] S504: Determine the security status rating based on the preset security status rating strategy and the security status score.

[0130] It is understandable that steps S501 to S504 are the process of generating the safety status evaluation results.

[0131] It should be noted that in "Step 4" above, if the number of defect indicators in the successful matching set 1 is greater than 4, the security status of the source code under test is directly output as "highly dangerous". Steps S501 to S504 for security status determination can be omitted. Conversely, if the "defect matching set" is composed of both successful matching set 1 and successful matching set 2, then steps S501 to S504 are required to complete the security status determination.

[0132] Specifically, steps S501 to S504 can be understood as follows:

[0133] Based on the defect matching set and analysis index system, the security evaluation value (security status score) of the source code can be calculated. Using this method, given a defect matching set, the security status rating corresponding to the source code security evaluation value can be automatically generated.

[0134] The source code security risk value calculation method in this embodiment uses a first-level indicator set I = {I1, I2, ..., I...} of the analysis indicator system. 22}, and the weight set of each indicator is h = (h1, h2, ..., h n The method provided in this application is more objective than methods that pre-fix or rely on expert evaluation to generate security assessment values, as the security vulnerability is in an unknown state. In one embodiment, when generating the indicator set, the order of the indicators in the first-level indicators is the same as the order of the indicators in the second-level indicators, that is, security vulnerability indicators first, then code quality defect indicators, and each indicator can be arranged according to its position in the system. Figure 13 The positions in the middle are arranged from left to right. For example, I 14 It's a log issue that poses a security vulnerability; I 15 It's a logical error stemming from a code quality defect.

[0135] Let Y = {Y1, Y2, ..., Y} m Let} represent the m slice defect matching sets. The calculation process for the source code security evaluation value and its status is as follows: Figure 15 As shown.

[0136] Step 1: Input the slice defect matching set Y = {Y1, Y2, ..., Y} m The first-level indicator set I = {I1, I2, ..., I...} in the analysis indicator system 22}

[0137] Step 2: Construct the decision matrix Z = (z... ij ) m×22 As shown in formula (2).

[0138] Z ij =Y i I j (2)

[0139] Z ij Represents Y = {Y1, Y2, ..., Y} m In the first-level index I = {I1, I2, ..., I...} 22 The number of sub-indicators under the corresponding primary indicator in the slice defect matching set is denoted as 100 if they exist and 1.01 if they do not exist. For example, Y1 has the following sub-indicators under I3 (Certification and Authorization): (The user access control issue occurred twice) and (If the password credential management problem occurs once, it is recorded as Z) 13 =300.

[0140] Step 3: Apply formula (3) to Z = (z ij ) m×22 Perform a positive transformation Z' = (z' ij ) m×22 Therefore, the higher the value, the higher the satisfaction level.

[0141]

[0142] Step 4: Obtain the positive decision matrix Z', where larger values ​​in each row and column indicate higher satisfaction, meaning the code corresponding to the slice is more secure.

[0143] Step 5: For Z' = (z i ' j ) m×22 Standardize the process, z” ij The specific calculation formula is as follows: the denominator is the square root of the sum of the squares of the elements in each column, and the numerator is the z-value of the positive transformation. i ' j .

[0144]

[0145] Step 6: Obtain the normalized decision matrix Z” = (z i ' j 'j) m×22 This makes the first-level index set I = {I1, I2, ..., I...} 22 The comparability of different variables is enhanced.

[0146] Step 7: Based on the normalized matrix Z”=(z”ij ) m×22 The positive and negative ideal solutions are determined, which are the maximum and minimum values ​​of each column in the normalized matrix Z. The formula is shown below:

[0147]

[0148]

[0149] Step 8: Calculate Y i The group benefit value P of ∈Y i Individual Regret Value Q i and compromise value R i :

[0150]

[0151]

[0152]

[0153]

[0154] In the formula: μ is the decision-making mechanism coefficient, μ∈[0,1]. When μ>0.5, it indicates that the decision-maker focuses on evaluating risk based on the maximum group utility; when μ<0.5, it indicates that the decision-maker focuses on evaluating risk based on the minimum individual regret. This patent adopts a compromise of μ=0.5, where the decision-maker reaches a consensus through negotiation.

[0155] Step 9: In the weight set h = (h1, h2, ..., h...) for each indicator n When the index weights are unknown, the problem of solving for them is transformed into solving a multi-objective optimization problem. Since the group benefit value P... i It represents Y i The degree of proximity of ∈Y to the positive ideal solution, the group benefit value P i The smaller the value, the closer the sample is to the positive ideal solution. The formula is expressed as follows:

[0156]

[0157] Step 10: The weight h can be obtained by using a multi-objective optimization solver (such as CPLEX). j By normalizing these values, we can obtain the following indices: I = {I1, I2, ..., I...} 22 The weight of} is h' j The normalization formula is as follows:

[0158]

[0159] Step 11: Based on the calculated weight values, Y is obtained from formulas (7), (8), and (9). i The group benefit value P of ∈Y i Individual Regret Value Q i and compromise value R i .

[0160] Step 12: The security evaluation value of the source code is the average of the compromise values ​​corresponding to each slice. The calculation formula is as follows:

[0161]

[0162] Step 13: Output the security evaluation value of the source code, which is the compromise average value R, and its corresponding security status, as shown in Table 2 below. (Compromise value R) i Conforms to normalization standards, i.e., R i ∈[0,1]).

[0163] Table 2 Safety Status Corresponding to the Compromise Average R

[0164] [0，0.2] (0.2，0.4) (0.4，0.6) (0.6，0.8) [0.8，1]

[0165] As can be seen from the above description, the source code security defect analysis method provided in this application can analyze the security defects of the source code under test based on security defect analysis indicators and defect matching sets, and obtain the security status rating of the source code under test.

[0166] Based on the same inventive concept, this application also provides a source code security defect analysis device, which can be used to implement the method described in the above embodiments, as described in the following embodiments. Since the principle of the source code security defect analysis device in solving the problem is similar to that of the source code security defect analysis method, the implementation of the source code security defect analysis device can refer to the implementation of the software performance benchmark determination method, and repeated details will not be elaborated further. As used below, the terms "unit" or "module" can refer to a combination of software and / or hardware that implements a predetermined function. Although the system described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0167] In one embodiment, see Figure 6 In order to objectively evaluate the security defects existing in the source code under test, this application provides a source code security defect analysis device, including: a slice and feature value generation unit 601, a feature set generation unit 602, and a security status rating unit 603.

[0168] The slicing and feature value generation unit 601 is used to slice the source code to be tested according to the semantic information of the source code to be tested, and generate defect feature values ​​corresponding to each slice to be tested.

[0169] The feature set generation unit 602 is used to determine the defect matching set of the source code to be tested based on the preset security defect analysis index and the defect feature value corresponding to each slice to be tested;

[0170] The security status rating unit 603 is used to analyze the security defects of the source code under test according to the security defect analysis index and the defect matching set, obtain the security status rating of the source code under test, and maintain the source code under test according to the security status rating.

[0171] In one embodiment, see Figure 7 The slicing and feature value generation unit 601 includes:

[0172] The noise removal module 701 is used to remove noise from the source code under test; wherein the source code under test after noise removal does not contain declarations, announcements and comments;

[0173] The attribute graph generation module 702 is used to parse the source code to be tested after noise removal and generate the corresponding code attribute graph.

[0174] The test slice generation module 703 is used to slice the source code to be tested according to the semantic information in the code attribute diagram to obtain the test slice;

[0175] The feature value calculation module 704 is used to generate defect feature values ​​corresponding to each of the slices to be tested using a hash function.

[0176] In one embodiment, see Figure 8 The feature set generation unit 602 includes:

[0177] The security defect determination module 801 is used to compare the historical defect feature values ​​corresponding to each historical slice of the historical source code with the defect feature values ​​corresponding to each slice to be tested, so as to determine the security defects existing in each slice to be tested.

[0178] The security defect matching module 802 is used to match the security defects existing in each of the test slices with the first-tier indicators in the security defect analysis indicators, and to determine whether the security defects existing in each of the test slices are high-risk defects; wherein, the first-tier indicators correspond to high-risk defects.

[0179] The feature set generation module 803 is used to generate a defect matching set of the source code to be tested based on the matching results.

[0180] In one embodiment, see Figure 9 The feature set generation module 803 includes:

[0181] The first feature set generation submodule 901 is used to generate a first matching success set based on the security defects of each slice under test and the first echelon index when it is determined that the security defects of each slice under test are high-risk defects.

[0182] The second feature set generation submodule 902 is used to match the security defects of each of the test slices with the second-tier indicators in the security defect analysis indicators when it is determined that the security defects of each test slice are low-risk defects, so as to generate a second successful matching set.

[0183] In one embodiment, see Figure 10 The security status rating unit 603 includes:

[0184] The decision matrix generation module 1001 is used to construct a safety status decision matrix based on the safety defect analysis index and the defect matching set.

[0185] The weight and trade-off calculation module 1002 is used to determine the weight and corresponding trade-off value of each of the safety defect analysis indicators using the safety status decision matrix;

[0186] The status score calculation module 1003 is used to calculate the security status score of the source code under test based on the weight of each security defect analysis index and the corresponding compromise value.

[0187] The security status rating module 1004 is used to determine the security status rating based on the preset security status rating strategy and the security status score.

[0188] From a hardware perspective, in order to objectively evaluate the security flaws in the source code under test, this application provides an embodiment of an electronic device for implementing all or part of the security flaw analysis method for the source code under test. The electronic device specifically includes the following components:

[0189] The system comprises a processor, a memory, a communications interface, and a bus; wherein the processor, memory, and communications interface communicate with each other via the bus; the communications interface is used to realize information transmission between the source code security defect analysis device and core business systems, user terminals, and related databases and other related devices; the logic controller can be a desktop computer, tablet computer, or mobile terminal, etc., and this embodiment is not limited to these. In this embodiment, the logic controller can be implemented with reference to the embodiments of the source code security defect analysis method and the embodiment of the source code security defect analysis device in the embodiments, the content of which is incorporated herein, and repeated parts will not be described again.

[0190] It is understood that the user terminal may include smartphones, tablet computers, network set-top boxes, portable computers, desktop computers, personal digital assistants (PDAs), in-vehicle devices, smart wearable devices, etc. Among these, the smart wearable devices may include smart glasses, smartwatches, smart bracelets, etc.

[0191] In practical applications, parts of the source code security flaw analysis method can be executed on the electronic device side as described above, or all operations can be completed on the client device. The choice can be made based on the processing power of the client device and the limitations of the user's usage scenario. This application does not impose any limitations on this. If all operations are completed on the client device, the client device may further include a processor.

[0192] The aforementioned client device may have a communication module (i.e., a communication unit) that can communicate with a remote server to achieve data transmission. The server may include a server on the task scheduling center side; in other implementation scenarios, it may also include a server on an intermediate platform, such as a server on a third-party server platform that has a communication link with the task scheduling center server. The server may include a single computer device, a server cluster consisting of multiple servers, or a distributed server structure.

[0193] Figure 11 This is a schematic block diagram illustrating the system configuration of the electronic device 9600 according to an embodiment of this application. Figure 11 As shown, the electronic device 9600 may include a central processing unit 9100 and a memory 9140; the memory 9140 is coupled to the central processing unit 9100. It is worth noting that... Figure 11 This is an example; other types of structures can also be used to supplement or replace this structure to achieve telecommunications functions or other functions.

[0194] In one embodiment, the source code security flaw analysis method functionality can be integrated into the central processing unit 9100. The central processing unit 9100 can be configured to perform the following controls:

[0195] S101: The source code to be tested is sliced ​​according to the semantic information of the source code to be tested, and defect feature values ​​corresponding to each slice are generated.

[0196] S102: Determine the defect matching set of the source code to be tested based on the preset security defect analysis indicators and the defect feature values ​​corresponding to each slice to be tested;

[0197] S103: Analyze the security defects of the source code under test according to the security defect analysis index and the defect matching set, obtain the security status rating of the source code under test, and maintain the source code under test according to the security status rating.

[0198] As can be seen from the above description, the source code security defect analysis method provided in this application can perform an overall quantitative evaluation of the security defects of the source code based on the source code security defect analysis index of "security vulnerability + code quality defects", providing a basis for subsequent source code maintenance work; it can combine code attribute graphs with slice feature values ​​to perform defect matching and overall quantitative evaluation in stages, thereby making the overall quantitative evaluation of the source code based on accuracy, efficiency and objectivity.

[0199] In another embodiment, the source code security defect analysis device can be configured separately from the central processing unit 9100. For example, the data composite transmission device source code security defect analysis device can be configured as a chip connected to the central processing unit 9100, and the function of the source code security defect analysis method can be realized through the control of the central processing unit.

[0200] like Figure 11 As shown, the electronic device 9600 may further include: a communication module 9110, an input unit 9120, an audio processor 9130, a display 9160, and a power supply 9170. It is worth noting that the electronic device 9600 does not necessarily need to include these components. Figure 11 All components shown; in addition, the electronic device 9600 may also include Figure 11 For components not shown, please refer to existing technologies.

[0201] like Figure 11 As shown, the central processing unit 9100, sometimes also referred to as a controller or operating control, may include a microprocessor or other processor device and / or logic device, which receives input and controls the operation of various components of the electronic device 9600.

[0202] The memory 9140 may be, for example, one or more of a cache, flash memory, hard drive, removable media, volatile memory, non-volatile memory, or other suitable devices. It may store the aforementioned failure-related information, and also store a program for executing that information. The central processing unit 9100 may execute the program stored in the memory 9140 to perform information storage or processing, etc.

[0203] Input unit 9120 provides input to central processing unit 9100. Input unit 9120 may be, for example, a keypad or touch input device. Power supply 9170 provides power to electronic device 9600. Display 9160 displays images and text. Display may be, for example, an LCD display, but is not limited thereto.

[0204] The memory 9140 can be a solid-state memory, such as a read-only memory (ROM), random access memory (RAM), a SIM card, etc. It can also be a memory that retains information even when power is off, can be selectively erased, and contains more data; examples of this type of memory are sometimes referred to as EPROMs. The memory 9140 can also be some other type of device. The memory 9140 includes a buffer memory 9141 (sometimes referred to as a buffer). The memory 9140 may include an application / function storage unit 9142 for storing application programs and function programs or processes for executing the operation of the electronic device 9600 via the central processing unit 9100.

[0205] The memory 9140 may also include a data storage unit 9143 for storing data, such as contacts, digital data, pictures, sounds, and / or any other data used by the electronic device. The driver storage unit 9144 of the memory 9140 may include various drivers for the electronic device's communication functions and / or for performing other functions of the electronic device (such as messaging applications, address book applications, etc.).

[0206] The communication module 9110 is a transmitter / receiver 9110 that transmits and receives signals via the antenna 9111. The communication module (transmitter / receiver) 9110 is coupled to the central processing unit 9100 to provide input signals and receive output signals, which can be the same as in a conventional mobile communication terminal.

[0207] Based on different communication technologies, multiple communication modules 9110 can be configured in the same electronic device, such as cellular network modules, Bluetooth modules, and / or wireless LAN modules. The communication module (transmitter / receiver) 9110 is also coupled to a speaker 9131 and a microphone 9132 via an audio processor 9130 to provide audio output via the speaker 9131 and receive audio input from the microphone 9132, thereby realizing typical telecommunications functions. The audio processor 9130 may include any suitable buffer, decoder, amplifier, etc. Additionally, the audio processor 9130 is also coupled to a central processing unit 9100, enabling on-device recording via the microphone 9132 and on-device playback of stored sound via the speaker 9131.

[0208] Embodiments of this application also provide a computer-readable storage medium capable of implementing all steps of the source code security defect analysis method with a server or client execution subject in the above embodiments. The computer-readable storage medium stores a computer program that, when executed by a processor, implements all steps of the source code security defect analysis method with a server or client execution subject in the above embodiments. For example, when the processor executes the computer program, it implements the following steps:

[0209] S101: The source code to be tested is sliced ​​according to the semantic information of the source code to be tested, and defect feature values ​​corresponding to each slice are generated.

[0210] S102: Determine the defect matching set of the source code to be tested based on the preset security defect analysis indicators and the defect feature values ​​corresponding to each slice to be tested;

[0211] S103: Analyze the security defects of the source code under test according to the security defect analysis index and the defect matching set, obtain the security status rating of the source code under test, and maintain the source code under test according to the security status rating.

[0212] As can be seen from the above description, the source code security defect analysis method provided in this application can perform an overall quantitative evaluation of the security defects of the source code based on the source code security defect analysis index of "security vulnerability + code quality defects", providing a basis for subsequent source code maintenance work; it can combine code attribute graphs with slice feature values ​​to perform defect matching and overall quantitative evaluation in stages, thereby making the overall quantitative evaluation of the source code based on accuracy, efficiency and objectivity.

[0213] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0214] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (devices), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0215] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0216] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0217] Specific embodiments have been used to illustrate the principles and implementation methods of this invention. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of this invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this invention. Therefore, the content of this specification should not be construed as a limitation of this invention.

Claims

1. A source code security defect analysis method, characterized in that, include: The source code to be tested is sliced ​​based on the semantic information of the source code to be tested, and defect feature values ​​corresponding to each slice are generated. Based on preset security defect analysis indicators and the defect feature values ​​corresponding to each slice to be tested, a defect matching set of the source code to be tested is determined. The specific steps include: First, after retrieving the defect feature values ​​corresponding to the slice to be tested from a massive code feature value database composed of historical information systems, a total of [number missing] defect matching sets are obtained. m The first step is to use the detection results of each slice as the source code detection results; the second step is to match the source code detection results with the first-tier indicators in the security defect analysis indicators; wherein, the first-tier indicators correspond to high-risk defects; the third step is for each slice to obtain its first successful matching set; the fourth step is to determine whether the number of defect indicators in the first successful matching set is greater than 4. If not, proceed to the fifth step; otherwise, proceed to the eighth step; the fifth step is to match the source code detection results with the second-tier indicators in the security defect analysis indicators; the sixth step is for each slice to obtain its second successful matching set; the seventh step is for each slice to combine its first and second successful matching sets to form its own defect matching set; the eighth step is to determine whether the number of slices with a defect indicator greater than 4 in the first successful matching set is greater than 4. m / 2, if yes, proceed to step nine; otherwise, proceed to step five, then proceed to steps six and seven; Step nine: output the security status of the source code of the target under test as highly dangerous; the security defects existing in the corresponding slice under test are high-risk defects; finally, summarize the defect matching set of each slice itself to obtain the defect matching set of the source code under test; The security defects of the source code under test are analyzed based on the security defect analysis indicators and the defect matching set to obtain a security status rating of the source code under test, and the source code under test is maintained based on the security status rating; wherein, the security defect analysis indicators include security vulnerability indicators and code quality defect indicators.

2. The source code security defect analysis method according to claim 1, characterized in that, The step of slicing the source code under test based on its semantic information and generating defect feature values ​​corresponding to each slice includes: Noise removal is performed on the source code to be tested; Analyze the noise-removed source code of the test and generate the corresponding code attribute map; The source code to be tested is sliced ​​based on the semantic information in the code attribute graph to obtain the slice to be tested; Defect feature values ​​corresponding to each of the tested slices are generated using a hash function.

3. The source code security defect analysis method according to claim 1, characterized in that, The step of determining the defect matching set of the source code to be tested based on preset security defect analysis indicators and defect feature values ​​corresponding to each slice to be tested includes: By comparing the historical defect feature values ​​corresponding to each historical slice of the historical source code with the defect feature values ​​corresponding to each slice under test, the security defects existing in each slice under test can be determined. Match the security defects existing in each of the test slices with the first-tier indicators in the security defect analysis indicators, and determine whether the security defects existing in each of the test slices are high-risk defects; Based on the matching results, a defect matching set is generated for the source code to be tested.

4. The source code security defect analysis method according to claim 3, characterized in that, The step of generating the defect matching set of the source code to be tested based on the matching results includes: If the security defects existing in each of the test slices are determined to be high-risk defects, then a first set of successful matches is generated based on the security defects existing in each of the test slices and the first echelon indicators. If the security defects existing in each of the test slices are determined to be low-risk defects, then the security defects existing in each of the test slices are matched with the second-tier indicators in the security defect analysis indicators to generate a second successful matching set.

5. The source code security defect analysis method according to claim 1, characterized in that, The step of analyzing the security defects of the source code under test based on the security defect analysis indicators and the defect matching set to obtain the security status rating of the source code under test includes: Construct a safety status decision matrix based on the security defect analysis indicators and the defect matching set; The weights and corresponding trade-off values ​​of each security defect analysis index are determined using the security status decision matrix. The security status score of the source code under test is calculated based on the weights of each security defect analysis index and the corresponding trade-off values. The security status rating is determined based on the preset security status rating strategy and the security status score.

6. A source code security defect analysis device, characterized in that, include: The slicing and feature value generation unit is used to slice the source code to be tested according to the semantic information of the source code to be tested, and generate defect feature values ​​corresponding to each slice to be tested. The feature set generation unit is used to determine the defect matching set of the source code to be tested based on preset security defect analysis indicators and the defect feature values ​​corresponding to each slice to be tested. Specific steps include: First, after retrieving the defect feature values ​​corresponding to the slice to be tested from a massive code feature value database constructed by a historical information system, a total of... m The first step is to use the detection results of each slice as the source code detection results; the second step is to match the source code detection results with the first-tier indicators in the security defect analysis indicators; wherein, the first-tier indicators correspond to high-risk defects; the third step is for each slice to obtain its first successful matching set; the fourth step is to determine whether the number of defect indicators in the first successful matching set is greater than 4. If not, proceed to the fifth step; otherwise, proceed to the eighth step; the fifth step is to match the source code detection results with the second-tier indicators in the security defect analysis indicators; the sixth step is for each slice to obtain its second successful matching set; the seventh step is for each slice to combine its first and second successful matching sets to form its own defect matching set; the eighth step is to determine whether the number of slices with a defect indicator greater than 4 in the first successful matching set is greater than 4. m / 2, if yes, proceed to step nine; otherwise, proceed to step five, then proceed to steps six and seven; Step nine: output the security status of the source code of the target under test as highly dangerous; the security defects existing in the corresponding slice under test are high-risk defects; finally, summarize the defect matching set of each slice itself to obtain the defect matching set of the source code under test; A security status rating unit is used to analyze the security defects of the source code under test based on the security defect analysis indicators and the defect matching set, and obtain a security status rating of the source code under test, so as to maintain the source code under test based on the security status rating; wherein, the security defect analysis indicators include security vulnerability indicators and code quality defect indicators.

7. The source code security defect analysis device according to claim 6, characterized in that, The slicing and feature value generation unit includes: The noise removal module is used to remove noise from the source code under test. The attribute graph generation module is used to parse the source code under test after noise removal and generate the corresponding code attribute graph. The test slice generation module is used to slice the source code to be tested according to the semantic information in the code attribute diagram to obtain the test slice; The feature value calculation module is used to generate defect feature values ​​corresponding to each of the slices to be tested using a hash function.

8. The source code security defect analysis device according to claim 6, characterized in that, The feature set generation unit includes: The security defect determination module is used to compare the historical defect feature values ​​corresponding to each historical slice of the historical source code with the defect feature values ​​corresponding to each slice to be tested, so as to determine the security defects existing in each slice to be tested. The security defect matching module is used to match the security defects existing in each of the test slices with the first-tier indicators in the security defect analysis indicators, and to determine whether the security defects existing in each of the test slices are high-risk defects. The feature set generation module is used to generate a defect matching set of the source code to be tested based on the matching results.

9. The source code security defect analysis device according to claim 8, characterized in that, The feature set generation module includes: The first feature set generation submodule is used to generate a first matching success set based on the security defects of each slice under test and the first echelon index when it is determined that the security defects of each slice under test are high-risk defects. The second feature set generation submodule is used to match the security defects of each of the test slices with the second-tier indicators in the security defect analysis indicators when the security defects of each test slice are determined to be low-risk defects, so as to generate a second successful matching set.

10. The source code security defect analysis device according to claim 6, characterized in that, The security status rating unit includes: The decision matrix generation module is used to construct a safety status decision matrix based on the safety defect analysis indicators and the defect matching set. The weight and trade-off calculation module is used to determine the weight and corresponding trade-off value of each of the security defect analysis indicators using the security status decision matrix; The status score calculation module is used to calculate the security status score of the source code under test based on the weights of each security defect analysis index and the corresponding trade-off values. The security status rating module is used to determine the security status rating based on a preset security status rating strategy and the security status score.

11. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the source code security defect analysis method according to any one of claims 1 to 5.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the source code security defect analysis method according to any one of claims 1 to 5.

13. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instruction is executed by the processor, it implements the steps of the source code security defect analysis method according to any one of claims 1 to 5.

Images