Multi-tool static code checking management method and device and computer equipment

Abstract

The present disclosure relates to a multi-tool static code checking management method, device and computer equipment. The method comprises: receiving an error category checking instruction input by a user; determining a target static code checking tool according to the error category checking instruction; checking a target code module by calling the target static code checking tool to obtain an initial error level of each vulnerability problem in a vulnerability problem set; reclassifying the initial error level of each vulnerability problem in the vulnerability problem set based on a preset error level classification standard to obtain a preset error level of each vulnerability problem; obtaining a final problem score of each vulnerability problem based on the preset error level of each vulnerability problem; obtaining state information of each vulnerability problem in real time; and processing each vulnerability problem according to the state information of each vulnerability problem and the final problem score of each vulnerability problem. The method can process each vulnerability problem according to a unified standard, thereby improving user experience.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a multi-tool static code inspection and management method, apparatus, and computer equipment. Background Technology

[0002] Software code quality determines the final application quality of large projects, and code quality checks typically rely on various static code analysis tools. There are many existing static code analysis tools, each with different implementation methods, vulnerability classification criteria, and areas of expertise. In real-world applications, a large project consists of code from multiple developers submitting different functional modules, each requiring different error categories for detection. However, when using multiple tools, the scoring criteria for detected issues differ, making it impossible to handle all detected issues in a project according to a unified standard.

[0003] In related technologies, one or more static code analysis tools are typically integrated into a single static code analysis tool. However, incompatibility issues may arise during the integration process. Therefore, how to integrate multiple static code analysis tools into a unified analysis and management mechanism is a pressing problem that needs to be solved. Summary of the Invention

[0004] In order to solve the above-mentioned technical problems, or at least partially solve the above-mentioned technical problems, this disclosure provides a display device and a multi-tool static code inspection and management method, apparatus and computer equipment.

[0005] Firstly, this disclosure provides a multi-tool static code analysis management method, applied to a target application, wherein the target application integrates calling interfaces for multiple static code analysis tools, including:

[0006] Receive user-input error category checking instructions;

[0007] Based on the error category inspection instructions, a target static code inspection tool is determined; the target static code inspection tool is the tool recommended to the user from a variety of static code inspection tools based on the error category inspection instructions, which has the highest accuracy rate for the error category inspection.

[0008] The target code module is inspected by calling the target static code inspection tool through the interface, and the initial error level of each vulnerability in the vulnerability issue set is obtained;

[0009] The initial error levels of each vulnerability in the vulnerability problem set are reclassified based on the preset error level classification standard to obtain the preset error level of each vulnerability problem;

[0010] Based on the preset error level of each vulnerability issue, the final issue score of each vulnerability issue is obtained;

[0011] Real-time acquisition of status information for various vulnerability issues;

[0012] Each vulnerability issue is processed based on its status information and final issue score.

[0013] As an optional implementation of this disclosure, obtaining the final problem score for each vulnerability problem based on a preset error level includes:

[0014] Based on the preset error level of each vulnerability issue, the initial problem score of each vulnerability issue is determined;

[0015] Obtain the set of vulnerabilities detected by the target static code analysis tool under the target language type; the set of vulnerabilities includes: a first preset number of valid vulnerabilities and a second preset number of invalid vulnerabilities corresponding to various error categories;

[0016] Input the first preset number of valid questions and the second preset number of invalid questions corresponding to each of the various error categories into the preset service scoring model, and output the accuracy rate of question judgment corresponding to each error category;

[0017] The initial problem score of each vulnerability problem and the accuracy of the judgment of the error category corresponding to each vulnerability problem are input into the preset problem scoring model, and the final problem score of each vulnerability problem is output.

[0018] As an optional implementation of this disclosure, the real-time acquisition of status information for each vulnerability issue includes:

[0019] Obtain key information for each vulnerability issue; the key information for each vulnerability issue includes: language type, file name, project name, sub-project name, line number of the issue, function name, error category, error identifier, error sub-identifier, error description, code content of a preset number of lines, and source address;

[0020] Hash calculations are performed based on the file name, function name, error identifier, and error sub-identifier to obtain the key values ​​for each vulnerability issue;

[0021] The key values ​​of each vulnerability issue are compared sequentially with the key values ​​of historical vulnerability issues in the historical database to determine the status information of each vulnerability issue; the historical database includes: key information and key values ​​of historical vulnerability issues.

[0022] As an optional implementation of this disclosure, the step of comparing the key values ​​of each vulnerability issue sequentially with the key values ​​of historical vulnerability issues in the historical database to determine the status information of each vulnerability issue includes:

[0023] Based on the key value of the problem to be processed, determine whether the problem to be processed is consistent with the target historical vulnerability problem in the historical database;

[0024] If the problem to be processed is inconsistent with the target historical vulnerability problem in the historical database, then the status information of the problem to be processed is determined to be unresolved.

[0025] If the problem to be processed is consistent with the target historical vulnerability problem in the historical database, then it is determined whether the problem to be processed is a duplicate of the target historical vulnerability problem in the historical database;

[0026] If the problem to be processed does not overlap with the target historical vulnerability problem in the historical database, then the status information of the problem to be processed is determined to be unresolved.

[0027] As an optional implementation of this disclosure, determining whether the problem to be processed overlaps with a target historical vulnerability problem in the historical database includes:

[0028] Determine whether the code content of the preset number of lines in the problem to be processed is consistent with the code content of the preset number of lines in the target historical vulnerability problem;

[0029] If the code content of the preset number of lines of the problem to be processed is consistent with the code content of the preset number of lines of the target historical vulnerability problem, then it is determined that the problem to be processed is a duplicate of the target historical vulnerability problem in the historical database;

[0030] If the code content of the preset number of lines of the problem to be processed is inconsistent with the code content of the preset number of lines of the target historical vulnerability problem, it is determined that the problem to be processed and the target historical vulnerability problem in the historical database have not been duplicated.

[0031] As an optional implementation of this disclosure, after determining that the problem to be processed overlaps with a target historical vulnerability problem in the historical database, the method further includes:

[0032] Determine whether the error level of the target historical vulnerability issue is a low-level error;

[0033] If the error level of the target historical vulnerability issue is a low-level error, then the status information of the issue to be processed is determined to be an ignorable issue;

[0034] If the error level of the target historical vulnerability is not a low-level error, the status information of the problem to be processed is determined to be resolved, and the person in charge of the problem to be processed is updated.

[0035] As an optional implementation of this disclosure, the status information of each vulnerability issue includes: unresolved, resolved, and negligible.

[0036] The process of handling each vulnerability issue based on its status information and final issue score includes:

[0037] For the vulnerabilities in the aforementioned vulnerability issue set whose status information is "resolved" or "negligible", close the vulnerability operation;

[0038] For the vulnerability issues in the vulnerability issue set whose status information is unresolved, the processing priority is sorted according to the final score of each vulnerability issue, and each vulnerability issue is processed according to the processing priority of each vulnerability issue.

[0039] As an optional implementation of this disclosure, the method further includes:

[0040] Generate a static code analysis report; wherein the static code analysis report includes: overview information and detailed information; the overview information includes: the name of the target static code analysis tool, the total number of issues scanned by the target static code analysis tool, and the number of issues corresponding to each error level scanned by the target static code analysis tool; the detailed information includes: the error category of each vulnerability issue scanned by the target static code analysis tool, the error level of each vulnerability issue, the person responsible for each vulnerability issue, and the status information of each vulnerability issue.

[0041] Secondly, a multi-tool static code analysis management device is provided, applied to a target application, wherein the target application integrates calling interfaces for multiple static code analysis tools, and the device includes:

[0042] The instruction receiving module is used to receive error category checking instructions input by the user;

[0043] The tool recommendation module is used to determine the target static code inspection tool based on the error category inspection instruction; the target static code inspection tool is the tool with the highest accuracy in checking the error category recommended to the user from a variety of static code inspection tools based on the error category inspection instruction.

[0044] The level acquisition module is used to call the target static code inspection tool through the interface to inspect the target code module and obtain the initial error level of each vulnerability in the vulnerability issue set;

[0045] The error classification module is used to reclassify the initial error level of each vulnerability in the vulnerability problem set based on a preset error level classification standard, and obtain the preset error level of each vulnerability problem.

[0046] The issue scoring module is used to obtain the final issue score for each vulnerability issue based on a preset error level for each vulnerability issue;

[0047] The status information module is used to obtain the status information of each vulnerability in real time;

[0048] The problem handling module is used to process each vulnerability problem based on its status information and final problem score.

[0049] As an optional implementation of this disclosure, the problem scoring module includes:

[0050] An initial scoring unit is used to determine the initial problem score for each vulnerability problem based on a preset error level for each vulnerability problem.

[0051] The issue acquisition unit is used to acquire a set of vulnerability issues detected by the target static code analysis tool under the target language type; the set of vulnerability issues includes: a first preset number of valid issues and a second preset number of invalid issues corresponding to various error categories;

[0052] The accuracy acquisition unit is used to input the first preset number of valid questions and the second preset number of invalid questions corresponding to the various error categories into the preset service scoring model, and output the question judgment accuracy corresponding to the various error categories.

[0053] The final scoring unit is used to input the initial problem score of each vulnerability problem and the accuracy of the judgment of the error category corresponding to each vulnerability problem into a preset problem scoring model, and output the final problem score of each vulnerability problem.

[0054] As an optional implementation of this disclosure, the status information module is specifically used for:

[0055] The vulnerability issue set is analyzed to obtain key information for each vulnerability issue. The key information for each vulnerability issue includes: language type, file name, project name, sub-project name, line number of the issue, function name, error category, error identifier, error sub-identifier, error description, code content of a preset number of lines, and source address.

[0056] Hash calculations are performed based on the file name, function name, error identifier, and error sub-identifier to obtain the key values ​​for each vulnerability issue;

[0057] The key values ​​of each vulnerability issue are compared sequentially with the key values ​​of historical vulnerability issues in the historical database to determine the status information of each vulnerability issue; the historical database includes: key information and key values ​​of historical vulnerability issues.

[0058] As an optional implementation of this disclosure, the step of comparing the key values ​​of each vulnerability issue sequentially with the key values ​​of historical vulnerability issues in the historical database to determine the status information of each vulnerability issue includes:

[0059] Based on the key value of the problem to be processed, determine whether the problem to be processed is consistent with the target historical vulnerability problem in the historical database;

[0060] If the problem to be processed is inconsistent with the target historical vulnerability problem in the historical database, then the status information of the problem to be processed is determined to be unresolved.

[0061] If the problem to be processed is consistent with the target historical vulnerability problem in the historical database, then it is determined whether the problem to be processed is a duplicate of the target historical vulnerability problem in the historical database;

[0062] If the problem to be processed does not overlap with the target historical vulnerability problem in the historical database, then the status information of the problem to be processed is determined to be unresolved.

[0063] As an optional implementation of this disclosure, determining whether the problem to be processed overlaps with a target historical vulnerability problem in the historical database includes:

[0064] Determine whether the code content of the preset number of lines in the problem to be processed is consistent with the code content of the preset number of lines in the target historical vulnerability problem;

[0065] If the code content of the preset number of lines of the problem to be processed is consistent with the code content of the preset number of lines of the target historical vulnerability problem, then it is determined that the problem to be processed is a duplicate of the target historical vulnerability problem in the historical database;

[0066] If the code content of the preset number of lines of the problem to be processed is inconsistent with the code content of the preset number of lines of the target historical vulnerability problem, it is determined that the problem to be processed and the target historical vulnerability problem in the historical database have not been duplicated.

[0067] As an optional implementation of this disclosure, after determining that the problem to be processed is a duplicate of a target historical vulnerability problem in the historical database, it is determined whether the error level of the target historical vulnerability problem is a low-level error; if the error level of the target historical vulnerability problem is a low-level error, the status information of the problem to be processed is determined to be an ignorable problem; if the error level of the target historical vulnerability problem is not a low-level error, the status information of the problem to be processed is determined to be resolved, and the person in charge of handling the problem is updated.

[0068] As an optional implementation of this disclosure, the status information of each vulnerability issue includes: unresolved, resolved, and negligible issues. The issue processing unit is specifically used for:

[0069] For the vulnerabilities in the aforementioned vulnerability issue set whose status information is "resolved" or "negligible", close the vulnerability operation;

[0070] For the vulnerability issues in the vulnerability issue set whose status information is unresolved, the processing priority is sorted according to the final score of each vulnerability issue, and each vulnerability issue is processed according to the processing priority of each vulnerability issue.

[0071] As an optional implementation of this disclosure, the apparatus further includes:

[0072] A report generation module is used to generate a static code inspection report. The static code inspection report includes: overview information and detailed information. The overview information includes: the name of the target static code inspection tool, the total number of issues scanned by the target static code inspection tool, and the number of issues corresponding to each error level scanned by the target static code inspection tool. The detailed information includes: the error category of each vulnerability issue scanned by the target static code inspection tool, the error level of each vulnerability issue, the person responsible for each vulnerability issue, and the status information of each vulnerability issue.

[0073] Thirdly, a speech recognition device is provided, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the multi-tool static code inspection and management method as described in the first aspect.

[0074] Fourthly, a computer-readable storage medium is provided, comprising: storing a computer program on the computer-readable storage medium, wherein when the computer program is executed by a processor, it implements the multi-tool static code inspection and management method as described in the first aspect.

[0075] Compared with the prior art, the technical solution provided in this disclosure has the following advantages: After receiving the error category inspection instruction input by the user, the target static code inspection tool is determined according to the error category inspection instruction, and then the target code module is inspected based on the target static code tool. After obtaining the initial error level of each vulnerability issue in the vulnerability issue set, the initial error level of each vulnerability issue in the vulnerability issue set is reclassified based on the preset error level classification standard to obtain the preset error level of each vulnerability issue. Based on the preset error level of each vulnerability issue, the final problem score of each vulnerability issue is obtained. The status information of each vulnerability issue is obtained in real time, and each vulnerability issue is processed according to the status information and the final problem score of each vulnerability issue. Because the target application establishes a unified management mechanism by integrating the APIs of various static code analysis tools, it recommends the most accurate analysis tool for each error category based on the user's input error category and the user's different analysis needs. Furthermore, it reclassifies the error levels of all issues according to a preset error level classification standard, obtaining a final score for each vulnerability. Simultaneously, it acquires the status information of each vulnerability in real time. Combining this status information with the final score, each vulnerability is processed according to a unified standard, thus completing the analysis of the target code module and improving the user experience. Attached Figure Description

[0076] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0077] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0078] Figure 1 This is a schematic diagram illustrating an application scenario of a multi-tool static code inspection and management method according to an embodiment of this disclosure;

[0079] Figure 2A This is a hardware configuration block diagram of a speech recognition device according to one or more embodiments of the present disclosure;

[0080] Figure 2BThis is a software configuration block diagram of a speech recognition device according to one or more embodiments of the present disclosure;

[0081] Figure 3A One of the flowcharts for a multi-tool static code inspection and management method provided in this disclosure embodiment;

[0082] Figure 3B A second flowchart illustrating a multi-tool static code inspection and management method provided in this embodiment of the disclosure;

[0083] Figure 3C The third flowchart illustrating a multi-tool static code analysis and management method provided in this embodiment of the disclosure;

[0084] Figure 3D The fourth flowchart illustrating a multi-tool static code inspection and management method provided in this disclosure embodiment;

[0085] Figure 3E The fifth flowchart illustrating a multi-tool static code inspection and management method provided in this disclosure embodiment;

[0086] Figure 3F A flowchart illustrating a multi-tool static code inspection and management method provided in this disclosure is shown in Figure 6.

[0087] Figure 3G The seventh flowchart illustrating a multi-tool static code inspection and management method provided in this disclosure embodiment;

[0088] Figure 4A This is one of the structural schematic diagrams of a multi-tool static code inspection and management device provided in an embodiment of this disclosure;

[0089] Figure 4B A second schematic diagram of a multi-tool static code inspection and management device provided in this embodiment of the present disclosure;

[0090] Figure 5 This is a schematic diagram of the structure of a computer device provided in an embodiment of this disclosure. Detailed Implementation

[0091] To better understand the above-mentioned objectives, features, and advantages of this disclosure, the solutions disclosed herein will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0092] Numerous specific details are set forth in the following description in order to provide a full understanding of this disclosure, but this disclosure may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only some, and not all, of the embodiments of this disclosure.

[0093] The terms "first," "second," "third," etc., used in this disclosure, in the specification, claims, and accompanying drawings are used to distinguish similar or related objects or entities, and do not necessarily imply a specific order or sequence, unless otherwise specified. It should be understood that such terms are interchangeable where appropriate.

[0094] The terms “comprising” and “having”, and any variations thereof, are intended to cover but not exclude inclusion, for example, a product or device that includes a range of components is not necessarily limited to all of the components that are clearly listed, but may include other components that are not clearly listed or that are inherent to such product or device.

[0095] Static code analysis (SCR) refers to checking the correctness of a program without running the program itself, solely by analyzing or examining the syntax, structure, process, and interfaces of the source code. SCR helps developers automate static code analysis, quickly locate hidden errors and defects, and allows code designers to focus more on analyzing and resolving code design flaws. It significantly reduces the time spent on line-by-line code inspection, improves software reliability, and saves software development and testing costs. SCR can detect error categories such as uninitialized variables, null pointer references, data type mismatches, array out-of-bounds errors, and memory leaks. There are various existing SCR tools, each with different vulnerability classification criteria and areas of expertise. In real-world applications, a large project consists of code from multiple developers submitting different functional modules, each requiring different error categories for detection. However, when using multiple tools, the scoring criteria for detected issues differ, making it impossible to handle all detected issues in a project according to a unified standard.

[0096] In existing technologies, one or more static code analysis tools are typically integrated into a single static code analysis tool. However, this approach may lead to incompatibility issues between the different tools during the integration process. Therefore, it is necessary to integrate multiple static code analysis tools to form a unified analysis and management mechanism.

[0097] To address the shortcomings of the aforementioned methods, this embodiment of the present disclosure, after receiving an error category inspection instruction input by the user, determines a target static code inspection tool based on the instruction, then inspects the target code module based on the target static code tool, obtains the initial error level of each vulnerability in the vulnerability issue set, then reclassifies the initial error level of each vulnerability in the vulnerability issue set based on a preset error level classification standard, obtains the preset error level of each vulnerability issue, obtains the final issue score of each vulnerability issue based on the preset error level of each vulnerability issue, obtains the status information of each vulnerability issue in real time, and processes each vulnerability issue based on the status information and the final issue score of each vulnerability issue. Because the target application establishes a unified management mechanism by integrating the APIs of various static code analysis tools, it recommends the most accurate analysis tool for each error category based on the user's input error category and the user's different analysis needs. Furthermore, it reclassifies the error levels of all issues according to a preset error level classification standard, obtaining a final score for each vulnerability. Simultaneously, it acquires the status information of each vulnerability in real time. Combining this status information with the final score, each vulnerability is processed according to a unified standard, thus completing the analysis of the target code module and further improving the user experience.

[0098] For example, such as Figure 1 As shown, Figure 1 This is a schematic diagram illustrating an application scenario of a multi-tool static code analysis and management method provided in this disclosure embodiment. Figure 1 In this context, the multi-tool static code analysis management method can be used in scenarios where users interact with target applications installed on computer devices. For example, when a user wants to inspect code modules submitted by developers via a server through a target application installed on computer device 100, they first need to input an error category inspection command. Upon receiving the error category inspection command, the target application selects from multiple static code analysis tools (…). Figure 1(As shown in 103) The target static code analysis tool is identified, and the target static code analysis tool is invoked through interface 102 to examine the target code module. The initial error level of each vulnerability in the vulnerability issue set is obtained, and the error levels of all issues are reclassified uniformly according to a preset error level classification standard to obtain the final issue score for each vulnerability issue. Simultaneously, the status information of each vulnerability issue is acquired in real time. Combining the status information and the final issue score of each vulnerability issue, each vulnerability issue is processed according to a unified standard, thereby completing the examination of the target code module and further improving the user experience. Interface 102 can be an API (Application Programming Interface). An API consists of predefined functions designed to provide target applications and developers with the ability to access a set of routines based on a static code analysis tool, without needing to access the source code or understand the details of the internal workings.

[0099] The multi-tool static code inspection and management method provided in this disclosure can be implemented based on computer equipment, or functional modules or functional entities in computer equipment.

[0100] The computer equipment can be a personal computer (PC), server, mobile phone, tablet computer, laptop computer, mainframe computer, etc., and this disclosure does not specifically limit it.

[0101] For example, Figure 2A This is a hardware configuration block diagram of a computer device according to one or more embodiments of the present disclosure. Figure 2AAs shown, the computer device includes at least one of the following: a tuner / demodulator 210, a communicator 220, a detector 230, an external device interface 240, a controller 250, a display 260, an audio output interface 270, a memory, a power supply, and a user interface 280. The controller 250 includes a central processing unit, a video processor, an audio processor, a graphics processor, RAM, ROM, and a first to nth interface for input / output. The display 260 can be at least one of a liquid crystal display, an OLED display, a touch display, and a projection display, and can also be a projection device and a projection screen. The tuner / demodulator 210 receives broadcast television signals via wired or wireless means, and demodulates audio and video signals, such as EPG audio and video data signals, from multiple wireless or wired broadcast television signals. The communicator 220 is a component used to communicate with external devices or servers according to various communication protocol types. For example, the communicator may include at least one of a Wi-Fi module, a Bluetooth module, a wired Ethernet module, other network communication protocol chips or near-field communication protocol chips, and an infrared receiver. The computer equipment can establish the transmission and reception of control signals and data signals with the server or local control equipment through the communicator 220. The detector 230 is used to collect signals from the external environment or to interact with the outside world. The controller 250 and the tuner / demodulator 210 can be located in different separate devices; that is, the tuner / demodulator 210 can also be located in an external device of the main device where the controller 250 is located, such as an external set-top box.

[0102] In some embodiments, the controller 250 controls the operation of the computer device and responds to user operations through various software control programs stored in memory. The controller 250 controls the overall operation of the computer device. The user can input commands through a graphical user interface (GUI) displayed on the monitor 260, and the user input interface receives the user input commands through the GUI. Alternatively, the user can input commands by entering specific sounds or gestures, and the user input interface receives the user input commands by recognizing the sounds or gestures through sensors.

[0103] Figure 2B This is a schematic diagram of the software configuration of a computer device according to one or more embodiments of the present disclosure, such as... Figure 2B As shown, the system is divided into four layers, from top to bottom: the Applications layer (referred to as the "Application Layer"), the Application Framework layer (referred to as the "Framework Layer"), the Android runtime and system library layer (referred to as the "System Runtime Library Layer"), and the kernel layer.

[0104] To illustrate this solution in more detail, the following will use examples to illustrate it. Figures 3A-3G To explain, it is understandable that, although Figures 3A-3G The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figures 3A-3G At least some of the steps may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least a portion of the sub-steps or stages of other steps. The aim is to implement the multi-tool static code inspection and management method provided in the embodiments of this disclosure.

[0105] like Figure 3A As shown, the method specifically includes the following steps:

[0106] S1: Receive error category checking instructions input by the user.

[0107] Error categories include, but are not limited to: uninitialized variables, null pointer references, data type mismatches, array out-of-bounds errors, memory leaks, parameter mismatches, ambiguous nested statements, incorrect recursion, and illegal calculations.

[0108] Specifically, the target application receives error category checking instructions input by the user.

[0109] For example, the target application receives an error category check instruction from the user, which may be to perform any of the following checks: uninitialized variable, null pointer reference, data type mismatch, array out of bounds, memory leak, parameter mismatch, ambiguous nested statement, erroneous recursion, illegal calculation, etc.

[0110] S2. Determine the target static code inspection tool based on the error category inspection instructions.

[0111] Among them, the target static code inspection tool is the tool recommended to the user from a variety of static code inspection tools based on the error category inspection instructions, and is the one with the highest accuracy in checking the error category.

[0112] Specifically, the target application recommends the static code checking tool with the highest accuracy for that error category to the user based on the error category checking instructions entered by the user; that is, it determines the target static code checking tool.

[0113] For example, suppose the target application receives an error category check instruction from the user to perform a null pointer reference check. Among the checking tools 1, 2, 3, ..., n, checking tool 2 has the highest accuracy for null pointer reference checks at 98%, while the accuracy of the other checking tools for null pointer reference checks is all below 98%. In this case, the static code checking tool recommended to the user is checking tool 2.

[0114] S3. Call the target static code inspection tool through the interface to inspect the target code module and obtain the initial error level of each vulnerability in the vulnerability issue set.

[0115] The calling interface can be an API (Application Programming Interface). An API is a set of predefined functions designed to provide target applications and developers with the ability to access a set of routines using static code tools, without needing to access the source code or understand the details of the internal workings.

[0116] Specifically, since the target application integrates the calling interfaces of multiple static code analysis tools, the target static code analysis tools are called through the calling interfaces to check the target code modules and obtain the initial error level of each vulnerability in the vulnerability issue set.

[0117] For example, suppose the target static code analysis tool is cppcheck. cppcheck categorizes detected code defects into eight levels: none, error, warning, style (code cleanliness tips), performance (suggestions to make the code run faster, based on general knowledge), portability, information (configuration issues), and debug. The target code module is inspected using the target static code analysis tool to obtain the initial error level for each vulnerability in the vulnerability set. For example, vulnerability issue 1 might have an initial error level of error, vulnerability issue 2 of style, vulnerability issue 3 of warning, and vulnerability issue 4 of error.

[0118] S4. Based on the preset error level classification standard, the initial error level of each vulnerability problem in the vulnerability problem set is reclassified to obtain the preset error level of each vulnerability problem.

[0119] The default error level classification criteria are: high-level errors, medium-level errors, and low-level errors. This means that the code defect classification of static code analysis tools is uniformly mapped to these default error levels.

[0120] Specifically, high-level errors are represented by "Critical," medium-level errors by "Major," and low-level errors by "Minor." High-level errors are those that affect system functionality or operation, with serious defects in major functions, but do not affect system stability. These problems can cause any of the following: 1) Function not implemented, 2) Function error, 3) System refresh error, 4) Data communication error, 5) Minor numerical calculation error, 6) Misspelled words or spelling errors affecting functionality and the interface, 7) Security issues. Medium-level errors cause interface defects, performance defects, and compatibility problems. These can cause any of the following: 1) Errors in the user interface (including inconsistent column names and meanings in data windows), 2) Boundary condition errors, 3) Errors in prompts (including no prompts or incorrect prompts), 4) No progress indicators during prolonged operation, 5) Unoptimized system (performance issues), 6) Inaccurate cursor jump settings or incorrect mouse (cursor) positioning, 7) Compatibility issues. Low-level errors are suggestions or issues that may include the following defects: 1) Non-standard interface format; 2) Unclear auxiliary instructions; 3) No prompts for users during operation; 4) No clear distinction between input and read-only areas; 5) A few minor typos that do not affect the understanding of the product; 6) Uneven text arrangement and other minor issues.

[0121] For example, suppose the target static code analysis tool is cppcheck. cppcheck classifies detected code defects into eight levels: none, error, warning, style, performance, portability, information, and debug. The default error level classification standard is: Critical, Major, and Minor. For instance, one possible implementation is to classify error and warning as Critical; style, performance, portability, and information as Major; and none and debug as Minor. Different static code analysis tools have different original code defect classification levels. Mapping these original code defect classification levels to the default standard classification level facilitates the quantitative calculation of the final score for vulnerabilities of different error categories according to a unified standard.

[0122] Additionally, the preset error level classification criteria can also be: extremely high-level errors, high-level errors, medium-level errors, and low-level errors. Extremely high-level errors, represented by "Blocker," are problems that cause the system to fail to execute, crash, suffer from severe resource shortages, prevent application modules from starting or exiting abnormally, become untestable, or cause system instability. These problems may result in any of the following: 1) severe screen flickering, 2) memory leaks, 3) user data loss or corruption, 4) system crashes / freezes / freezes, 5) modules failing to start or exiting abnormally, 6) severe numerical calculation errors, 7) serious mismatch between functional design and requirements, and 8) other errors that prevent testing.

[0123] S5. Based on the preset error level of each vulnerability issue, obtain the final issue score for each vulnerability issue.

[0124] Figure 3B This is a flowchart illustrating another multi-tool static code analysis and management method provided in this embodiment. This embodiment is... Figure 3A Further expansion and optimization based on this. (Refer to...) Figure 3B As shown, step S5 (obtaining the final problem score for each vulnerability problem based on the preset error level of each vulnerability problem) can be implemented through the following steps S51-S54:

[0125] S51. Determine the initial problem score for each vulnerability problem based on the preset error level of each vulnerability problem.

[0126] Specifically, corresponding problem scores can be set for high-level errors, medium-level errors, and low-level errors.

[0127] For example, a high-level error might have an initial problem score of 10 points; a medium-level error might have an initial problem score of 5 points; and a low-level error might have an initial problem score of 1 point. It should be noted that the initial problem score settings for high-level, medium-level, and low-level errors can be adjusted according to different application scenarios, and no specific restrictions are imposed here.

[0128] S52. Obtain the set of vulnerability issues detected by the target static code analysis tool under the target language type.

[0129] The vulnerability problem set includes: a first preset number of valid problems and a second preset number of invalid problems corresponding to various error categories.

[0130] Specifically, the number of valid and invalid issues for each error category is counted separately.

[0131] For example, for the error category of "uninitialized variable", the number of valid errors is 20 and the number of invalid errors is 3; for the error category of "null pointer reference", the number of valid errors is 50 and the number of invalid errors is 2; for the error category of "array out of bounds", the number of valid errors is 10 and the number of invalid errors is 1.

[0132] S53. Input the first preset number of valid questions and the second preset number of invalid questions corresponding to each of the various error categories into the preset service scoring model, and output the accuracy rate of question judgment corresponding to each error category.

[0133] The input to the preset service scoring model is the number of valid and invalid issues for the target error category in the target language type by the target static code analysis tool; the output is the accuracy rate of the target static code analysis tool in judging the error category in the target language type.

[0134] Specifically, the preset service scoring model is used to obtain the accuracy of the target static code inspection tool in judging the target error category under the target language type.

[0135] For example, assuming the checking tool is SonarQube and the language is C, when the error category is null pointer reference, if the number of valid problems corresponding to this error category is n11 and the number of invalid problems is n12, the accuracy rate of identifying the problem corresponding to this error category is 95%; when the error category is array out of bounds, if the number of valid problems corresponding to this error category is n21 and the number of invalid problems is n22, the accuracy rate of identifying the problem corresponding to this error category is 85%; when the error category is memory leak, if the number of valid problems corresponding to this error category is n31 and the number of invalid problems is n32, the accuracy rate of identifying the problem corresponding to this error category is 78%.

[0136] S54. Input the initial problem score of each vulnerability problem and the judgment accuracy of the error category corresponding to each vulnerability problem into the preset problem scoring model, and output the final problem score of each vulnerability problem.

[0137] The preset problem scoring model is used to obtain the final problem score for each vulnerability problem.

[0138] Specifically, the final problem score for each vulnerability issue = the initial problem score for each vulnerability issue * the problem judgment accuracy rate corresponding to that error category.

[0139] For example, vulnerability issue 1 corresponds to the error category of "uninitialized variable," with an accuracy rate of 90%. Vulnerability issue 1 initially scores 10 points, therefore its final score is 10 * 90% = 9 points. Vulnerability issue 2 corresponds to the misalignment category of "null pointer reference," with an accuracy rate of 98%. Vulnerability issue 2 initially scores 10 points, therefore its final score is 10 * 98% = 9.8 points. Vulnerability issue 3 corresponds to the error category of "non-standard interface format," with an accuracy rate of 95%. Vulnerability issue 3 initially scores 1 point, therefore its final score is 1 * 95% = 0.95 points.

[0140] S6. Obtain real-time status information for each vulnerability issue.

[0141] Figure 3C This is a flowchart illustrating another multi-tool static code analysis and management method provided in this embodiment. This embodiment is... Figure 3A Further expansion and optimization based on this. (Refer to...) Figure 3C As shown, step S6 (real-time acquisition of status information for each vulnerability issue) can be implemented in the following way:

[0142] S61. Obtain key information on each vulnerability issue.

[0143] The key information for each vulnerability includes: language type, file name, project name, sub-project name, line number of the vulnerability, function name, error category, error identifier, error sub-identifier, error description, a preset number of lines of code content, and source address.

[0144] Specifically, a single static code analysis tool may support multiple detection languages, such as C, C++, and Java. Generally, for the same code module, the developers use the same programming language. Therefore, in this embodiment, the language type for each vulnerability issue is the same. Then, the following information is obtained for each vulnerability issue: file name, project name, sub-project name, line number, function name, error category, error identifier, error sub-identifier, error description, and the code content of several lines before and after each issue, as well as the original address of each issue. The preset number can be 10, 20, 30, etc., and a reasonable value can be selected according to different application scenarios; no specific limit is placed on the preset number here.

[0145] S62. Perform hash calculation based on the file name, function name, error identifier, and error sub-identifier to obtain the key values ​​of each vulnerability issue.

[0146] Among them, error identifiers and error sub-identifiers have different levels. Error identifiers can be understood as first-level identifiers, while error sub-identifiers can be understood as second-level identifiers. Error sub-identifiers are a more granular representation of errors.

[0147] Specifically, the key values ​​for each vulnerability are obtained through hash calculation. Hash calculation transforms input data of arbitrary length into a fixed-length output using a hash algorithm; in this embodiment, this output is the key value of the vulnerability.

[0148] It should be noted that the methods for calculating the key values ​​of each vulnerability issue include, but are not limited to, hashing file names, function names, error identifiers, and error sub-identifiers. Other reasonable methods can also be used to obtain the key values ​​of each vulnerability issue.

[0149] S63. The key values ​​of each vulnerability issue are compared sequentially with the key values ​​of historical vulnerability issues in the historical database to determine the status information of each vulnerability issue.

[0150] The historical database includes key information and key values ​​related to historical vulnerabilities.

[0151] Specifically, the historical database stores key information and values ​​for numerous historical vulnerabilities. For example, it might contain key information and values ​​for hundreds or thousands of historical vulnerabilities detected by static code analysis tools in the same project. By comparing the key values ​​of the current vulnerability to be addressed with those in the historical database, it can be determined whether the vulnerability to be addressed matches a specific historical vulnerability in the database.

[0152] Figure 3D This is a flowchart illustrating another multi-tool static code analysis and management method provided in this embodiment. This embodiment is... Figure 3C Further expansion and optimization based on this. (Refer to...) Figure 3D As shown, step S63 (comparing the key values ​​of each vulnerability issue sequentially with the key values ​​of historical vulnerability issues in the historical database to determine the status information of each vulnerability issue) can be implemented in the following way:

[0153] S631. Based on the key value of the problem to be processed, determine whether the problem to be processed is consistent with the target historical vulnerability problem in the historical database.

[0154] If the problem to be processed is consistent with the target historical vulnerability problem in the historical database, then execute S632. If the problem to be processed is inconsistent with the target historical vulnerability problem in the historical database, then execute S633.

[0155] S632. Determine whether the problem to be processed is a duplicate of the target historical vulnerability problem in the historical database.

[0156] S633. Determine that the status information of the problem to be processed is unresolved.

[0157] If the problem to be processed is the same as the target historical vulnerability problem in the historical database, then S634 is executed further.

[0158] S634. Determine whether the error level of the target historical vulnerability problem is a low-level error.

[0159] The error levels of historical vulnerabilities in the historical database are categorized as: high-level errors, medium-level errors, and low-level errors.

[0160] For example, low-level errors can be labeled as "won't fix" or "Not a bug".

[0161] If the error level of the target historical vulnerability is a low-level error, then execute S635. If the error level of the target historical vulnerability is not a low-level error, then execute S636.

[0162] S635. Determine that the status information of the problem to be processed is negligible.

[0163] S636. Determine the status information of the problem to be processed as resolved, and update the person in charge of handling the problem.

[0164] Specifically, when the error level of the target historical vulnerability issue is low, the status information of the issue to be processed is determined to be negligible; when the error level of the target historical vulnerability issue is medium or high, the person in charge of the issue to be processed is updated to the person in charge of the most recent time that the target code module was processed, to prevent the person in charge of submitting the target code module from having left the company or no longer being responsible for the module.

[0165] Figure 3E This is a flowchart illustrating another multi-tool static code analysis and management method provided in this embodiment. This embodiment is... Figure 3D Further expansion and optimization based on this. (Refer to...) Figure 3E As shown, step S632 (determining whether the problem to be processed is a duplicate of the target historical vulnerability problem in the historical database) can be implemented in the following way:

[0166] S6321. Determine whether the code content of the preset number of lines of the problem to be processed is consistent with the code content of the preset number of lines of the target historical vulnerability problem.

[0167] Specifically, determine whether the problem to be addressed overlaps with the target historical vulnerability issue; that is, determine whether the lines of code before and after the problem to be addressed are consistent with the lines of code before and after the target historical vulnerability issue.

[0168] If the code content of the preset number of lines in the problem to be processed is consistent with the code content of the preset number of lines in the target historical vulnerability problem, then proceed to step S6322. If the code content of the preset number of lines in the problem to be processed is inconsistent with the code content of the preset number of lines in the target historical vulnerability problem, then proceed to step S6323.

[0169] S6322. Determine that the problem to be processed is a duplicate of the target historical vulnerability problem in the historical database.

[0170] S6323. Determine that the problem to be processed does not overlap with the target historical vulnerability problem in the historical database.

[0171] For example, it is determined whether the code of the five lines before and after the problem to be processed is consistent with the code of the five lines before and after the target historical vulnerability problem. If the code of the five lines before and after the problem to be processed is consistent with the code of the five lines before and after the target historical vulnerability problem, it is determined that the problem to be processed is a duplicate of the target historical vulnerability problem in the historical database. If the code of the five lines before and after the problem to be processed is inconsistent with the code of the five lines before and after the target historical vulnerability problem, it is determined that the problem to be processed is not a duplicate of the target historical vulnerability problem in the historical database.

[0172] S7. Process each vulnerability issue according to its status information and final issue score.

[0173] The status information for each vulnerability includes: unresolved, resolved, and negligible.

[0174] Figure 3F This is a flowchart illustrating another multi-tool static code analysis and management method provided in this embodiment. This embodiment is... Figure 3A Further expansion and optimization based on this. (Refer to...) Figure 3F As shown, step S7 (processing each vulnerability issue based on its status information and final issue score) can be implemented as follows:

[0175] S71. Close the vulnerability issues in the vulnerability issue set whose status information is resolved / ignorable.

[0176] S72. For the vulnerability issues in the vulnerability issue set whose status information is unresolved, sort them according to the final score of each vulnerability issue, and process each vulnerability issue according to the processing priority of each vulnerability issue.

[0177] For example, for vulnerability issues in the vulnerability issue set whose status information is unresolved, the processing priority is sorted according to the final score of each vulnerability issue. For example, the final scores of vulnerability issue 1, vulnerability issue 2, vulnerability issue 3, and vulnerability issue 4 are 5 points, 8 points, 2 points, and 9 points, respectively. The processing priority is: vulnerability issue 4 > vulnerability issue 2 > vulnerability issue 1 > vulnerability issue 3. Therefore, the processing order of the above issues is: vulnerability issue 4, vulnerability issue 2, vulnerability issue 1, and vulnerability issue 3.

[0178] Figure 3G This is a flowchart illustrating another multi-tool static code analysis and management method provided in this embodiment. This embodiment is... Figure 3A Further expansion and optimization based on this. (Refer to...) Figure 3G As shown, after processing each vulnerability issue based on its status information and final issue score, the following steps can be performed:

[0179] S8. Generate a static code analysis report.

[0180] The static code inspection report includes: overview information and detailed information; the overview information includes: the name of the target static code inspection tool, the total number of issues scanned by the target static code inspection tool, and the number of issues corresponding to each error level scanned by the target static code inspection tool; the detailed information includes: the error category of each vulnerability issue scanned by the target static code inspection tool, the error level of each vulnerability issue, the person responsible for each vulnerability issue, and the status information of each vulnerability issue.

[0181] In this embodiment of the disclosure, after receiving the error category inspection instruction input by the user, a target static code inspection tool is determined according to the error category inspection instruction. Then, the target code module is inspected based on the target static code inspection tool. After obtaining the initial error level of each vulnerability issue in the vulnerability issue set, the initial error level of each vulnerability issue in the vulnerability issue set is reclassified based on the preset error level classification standard to obtain the preset error level of each vulnerability issue. Based on the preset error level of each vulnerability issue, the final issue score of each vulnerability issue is obtained. The status information of each vulnerability issue is obtained in real time. Based on the status information and the final issue score of each vulnerability issue, each vulnerability issue is processed. Because the target application establishes a unified management mechanism by integrating the APIs of various static code analysis tools, it recommends the most accurate analysis tool for each error category based on the user's input error category and the user's different analysis needs. Furthermore, it reclassifies the error levels of all issues according to a preset error level classification standard, obtaining a final score for each vulnerability. Simultaneously, it acquires the status information of each vulnerability in real time. Combining this status information with the final score, each vulnerability is processed according to a unified standard, thus completing the analysis of the target code module and further improving the user experience.

[0182] Figure 4A This is a schematic diagram of a multi-tool static code analysis and management device provided in an embodiment of this disclosure. The device is configured in a computer device and can implement the multi-tool static code analysis and management method described in any embodiment of this disclosure. The multi-tool static code analysis and management device 400 specifically includes the following:

[0183] Instruction receiving module 410 is used to receive error category checking instructions input by the user;

[0184] The tool recommendation module 420 is used to determine a target static code inspection tool based on the error category inspection instruction; the target static code inspection tool is the tool with the highest accuracy in checking the error category recommended to the user from a variety of static code inspection tools based on the error category inspection instruction.

[0185] The level acquisition module 430 is used to call the target static code inspection tool through the call interface to inspect the target code module and obtain the initial error level of each vulnerability in the vulnerability issue set;

[0186] The level classification module 440 is used to reclassify the initial error level of each vulnerability in the vulnerability problem set based on the preset error level classification standard, and obtain the preset error level of each vulnerability problem.

[0187] The issue scoring module 450 is used to obtain the final issue score for each vulnerability issue based on the preset error level of each vulnerability issue;

[0188] Status information module 460 is used to obtain the status information of each vulnerability issue in real time;

[0189] The problem processing module 470 is used to process each vulnerability problem based on the status information of each vulnerability problem and the final problem score of each vulnerability problem.

[0190] As an optional implementation of this disclosure, the problem scoring module 450 includes:

[0191] An initial scoring unit is used to determine the initial problem score for each vulnerability problem based on a preset error level for each vulnerability problem.

[0192] The issue acquisition unit is used to acquire a set of vulnerability issues detected by the target static code analysis tool under the target language type; the set of vulnerability issues includes: a first preset number of valid issues and a second preset number of invalid issues corresponding to various error categories;

[0193] The accuracy acquisition unit is used to input the first preset number of valid questions and the second preset number of invalid questions corresponding to the various error categories into the preset service scoring model, and output the question judgment accuracy corresponding to the various error categories.

[0194] The final scoring unit is used to input the initial problem score of each vulnerability problem and the accuracy of the judgment of the error category corresponding to each vulnerability problem into a preset problem scoring model, and output the final problem score of each vulnerability problem.

[0195] As an optional implementation of this disclosure, the status information module 460 is specifically used for:

[0196] The vulnerability issue set is analyzed to obtain key information for each vulnerability issue. The key information for each vulnerability issue includes: language type, file name, project name, sub-project name, line number of the issue, function name, error category, error identifier, error sub-identifier, error description, code content of a preset number of lines, and source address.

[0197] Hash calculations are performed based on the file name, function name, error identifier, and error sub-identifier to obtain the key values ​​for each vulnerability issue;

[0198] The key values ​​of each vulnerability issue are compared sequentially with the key values ​​of historical vulnerability issues in the historical database to determine the status information of each vulnerability issue; the historical database includes: key information and key values ​​of historical vulnerability issues.

[0199] As an optional implementation of this disclosure, the step of comparing the key values ​​of each vulnerability issue sequentially with the key values ​​of historical vulnerability issues in the historical database to determine the status information of each vulnerability issue includes:

[0200] Based on the key value of the problem to be processed, determine whether the problem to be processed is consistent with the target historical vulnerability problem in the historical database;

[0201] If the problem to be processed is inconsistent with the target historical vulnerability problem in the historical database, then the status information of the problem to be processed is determined to be unresolved.

[0202] If the problem to be processed is consistent with the target historical vulnerability problem in the historical database, then it is determined whether the problem to be processed is a duplicate of the target historical vulnerability problem in the historical database;

[0203] If the problem to be processed does not overlap with the target historical vulnerability problem in the historical database, then the status information of the problem to be processed is determined to be unresolved.

[0204] As an optional implementation of this disclosure, determining whether the problem to be processed overlaps with a target historical vulnerability problem in the historical database includes:

[0205] Determine whether the code content of the preset number of lines in the problem to be processed is consistent with the code content of the preset number of lines in the target historical vulnerability problem;

[0206] If the code content of the preset number of lines of the problem to be processed is consistent with the code content of the preset number of lines of the target historical vulnerability problem, then it is determined that the problem to be processed is a duplicate of the target historical vulnerability problem in the historical database;

[0207] If the code content of the preset number of lines of the problem to be processed is inconsistent with the code content of the preset number of lines of the target historical vulnerability problem, it is determined that the problem to be processed and the target historical vulnerability problem in the historical database have not been duplicated.

[0208] As an optional implementation of this disclosure, after determining that the problem to be processed is a duplicate of a target historical vulnerability problem in the historical database, it is determined whether the error level of the target historical vulnerability problem is a low-level error; if the error level of the target historical vulnerability problem is a low-level error, the status information of the problem to be processed is determined to be an ignorable problem; if the error level of the target historical vulnerability problem is not a low-level error, the status information of the problem to be processed is determined to be resolved, and the person in charge of handling the problem is updated.

[0209] As an optional implementation of this disclosure, the status information of each vulnerability issue includes: unresolved, resolved, and negligible issues. The issue processing unit is specifically used for:

[0210] For the vulnerabilities in the aforementioned vulnerability issue set whose status information is "resolved" or "negligible", close the vulnerability operation;

[0211] For the vulnerability issues in the vulnerability issue set whose status information is unresolved, the processing priority is sorted according to the final score of each vulnerability issue, and each vulnerability issue is processed according to the processing priority of each vulnerability issue.

[0212] Figure 4B This is a schematic diagram of another multi-tool static code inspection and management device provided in an embodiment of this disclosure. Figure 4A Further expansion and optimization based on this. (Refer to...) Figure 4B As shown, the device further includes:

[0213] The report generation module 480 is used to generate a static code inspection report; wherein the static code inspection report includes: overview information and detailed information; the overview information includes: the name of the target static code inspection tool, the total number of issues scanned by the target static code inspection tool, and the number of issues corresponding to each error level scanned by the target static code inspection tool; the detailed information includes: the error category of each vulnerability issue scanned by the target static code inspection tool, the error level of each vulnerability issue, the person responsible for each vulnerability issue, and the status information of each vulnerability issue.

[0214] In this embodiment of the disclosure, after receiving the error category inspection instruction input by the user, a target static code inspection tool is determined according to the error category inspection instruction. Then, the target code module is inspected based on the target static code inspection tool. After obtaining the initial error level of each vulnerability issue in the vulnerability issue set, the initial error level of each vulnerability issue in the vulnerability issue set is reclassified based on the preset error level classification standard to obtain the preset error level of each vulnerability issue. Based on the preset error level of each vulnerability issue, the final issue score of each vulnerability issue is obtained. The status information of each vulnerability issue is obtained in real time. Based on the status information and the final issue score of each vulnerability issue, each vulnerability issue is processed. Because the target application establishes a unified management mechanism by integrating the APIs of various static code analysis tools, it recommends the most accurate analysis tool for each error category based on the user's input error category and the user's different analysis needs. Furthermore, it reclassifies the error levels of all issues according to a preset error level classification standard, obtaining a final score for each vulnerability. Simultaneously, it acquires the status information of each vulnerability in real time. Combining this status information with the final score, each vulnerability is processed according to a unified standard, thus completing the analysis of the target code module and further improving the user experience.

[0215] The multi-tool static code inspection and management device provided in this disclosure can execute the multi-tool static code inspection and management method provided in any embodiment of this disclosure, and has the corresponding functional modules and beneficial effects of the execution method. To avoid repetition, it will not be described again here.

[0216] This disclosure provides a computer device, including: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement any of the multi-tool static code inspection and management methods described in this disclosure.

[0217] Figure 5 This is a schematic diagram of the structure of a computer device provided in an embodiment of this disclosure. Figure 5 As shown, the computer device includes a processor 510 and a storage device 520; the number of processors 510 in the computer device can be one or more. Figure 5 Taking a processor 510 as an example; the processor 510 and the storage device 520 in the computer device can be connected via a bus or other means. Figure 5 Taking the example of a connection between China and Israel via a bus.

[0218] Storage device 520, as a computer-readable storage medium, can be used to store software programs, computer-executable programs, and modules, such as the program instructions / modules corresponding to the multi-tool static code inspection and management method in this embodiment of the disclosure. Processor 510 executes various functional applications and data processing of the computer device by running the software programs, instructions, and modules stored in storage device 520, thereby implementing the multi-tool static code inspection and management method provided in this embodiment of the disclosure.

[0219] Storage device 520 may primarily include a program storage area and a data storage area. The program storage area may store the operating system and at least one application program required for a function; the data storage area may store data created based on terminal usage. Furthermore, storage device 520 may include a high-speed random access storage device, and may also include a non-volatile storage device, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some instances, storage device 520 may further include storage devices remotely located relative to processor 510, which can be connected to computer equipment via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0220] The computer device provided in this embodiment can be used to execute the multi-tool static code inspection and management method provided in any of the above embodiments, and has corresponding functions and beneficial effects.

[0221] This disclosure also provides a storage medium containing computer-executable instructions. When executed by a computer processor, the computer-executable instructions implement the various processes of the methods provided in any of the above embodiments and achieve the same technical effects. To avoid repetition, further details are omitted here.

[0222] The computer-readable storage medium can be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0223] For ease of explanation, the above description has been provided in conjunction with specific embodiments. However, the discussion in some embodiments above is not intended to be exhaustive or to limit the embodiments to the specific forms disclosed above. Various modifications and variations can be obtained based on the above teachings. The selection and description of the above embodiments are for the purpose of better explaining the principles and practical applications, thereby enabling those skilled in the art to better utilize the embodiments and various different variations of the embodiments suitable for specific application considerations.

Claims

1. A multi-tool static code analysis and management method, characterized in that, Applied to a target application that integrates calling interfaces for various static code analysis tools, the method includes: Receive user-input error category checking instructions; Based on the error category checking instructions, a target static code checking tool is determined; the target static code checking tool is the one recommended to the user from a variety of static code checking tools based on the error category checking instructions, which has the highest accuracy rate for checking the error category. The target code module is inspected by calling the target static code inspection tool through the interface, and the initial error level of each vulnerability in the vulnerability issue set is obtained; The initial error levels of each vulnerability in the vulnerability problem set are reclassified based on the preset error level classification standard to obtain the preset error level of each vulnerability problem; Based on the preset error level of each vulnerability issue, the final issue score of each vulnerability issue is obtained; Real-time acquisition of status information for various vulnerability issues; Each vulnerability issue is processed based on its status information and final issue score. The process of obtaining a final problem score for each vulnerability based on a preset error level includes: Based on the preset error level of each vulnerability issue, the initial problem score of each vulnerability issue is determined; Obtain the set of vulnerabilities detected by the target static code analysis tool under the target language type; the set of vulnerabilities includes: a first preset number of valid vulnerabilities and a second preset number of invalid vulnerabilities corresponding to various error categories; Input the first preset number of valid questions and the second preset number of invalid questions corresponding to each of the various error categories into the preset service scoring model, and output the accuracy rate of question judgment corresponding to each error category; The initial problem score of each vulnerability problem and the accuracy of the judgment of the error category corresponding to each vulnerability problem are input into the preset problem scoring model, and the final problem score of each vulnerability problem is output.

2. The method according to claim 1, characterized in that, The real-time acquisition of status information for each vulnerability issue includes: Obtain key information for each vulnerability issue; the key information for each vulnerability issue includes: language type, file name, project name, sub-project name, line number of the issue, function name, error category, error identifier, error sub-identifier, error description, code content of a preset number of lines, and source address; Hash calculations are performed based on the file name, function name, error identifier, and error sub-identifier to obtain the key values ​​for each vulnerability issue; The key values ​​of each vulnerability issue are compared sequentially with the key values ​​of historical vulnerability issues in the historical database to determine the status information of each vulnerability issue; the historical database includes: key information and key values ​​of historical vulnerability issues.

3. The method according to claim 2, characterized in that, The step of comparing the key values ​​of each vulnerability issue sequentially with the key values ​​of historical vulnerability issues in the historical database to determine the status information of each vulnerability issue includes: Based on the key value of the problem to be processed, determine whether the problem to be processed is consistent with the target historical vulnerability problem in the historical database; If the problem to be processed is inconsistent with the target historical vulnerability problem in the historical database, then the status information of the problem to be processed is determined to be unresolved. If the problem to be processed is consistent with the target historical vulnerability problem in the historical database, then it is determined whether the problem to be processed is a duplicate of the target historical vulnerability problem in the historical database; If the problem to be processed does not overlap with the target historical vulnerability problem in the historical database, then the status information of the problem to be processed is determined to be unresolved.

4. The method according to claim 3, characterized in that, Determining whether the problem to be processed overlaps with a target historical vulnerability problem in the historical database includes: Determine whether the code content of the preset number of lines in the problem to be processed is consistent with the code content of the preset number of lines in the target historical vulnerability problem; If the code content of the preset number of lines of the problem to be processed is consistent with the code content of the preset number of lines of the target historical vulnerability problem, then it is determined that the problem to be processed is a duplicate of the target historical vulnerability problem in the historical database; If the code content of the preset number of lines of the problem to be processed is inconsistent with the code content of the preset number of lines of the target historical vulnerability problem, it is determined that the problem to be processed and the target historical vulnerability problem in the historical database have not been duplicated.

5. The method according to claim 4, characterized in that, After determining that the problem to be processed overlaps with a target historical vulnerability problem in the historical database, the method further includes: Determine whether the error level of the target historical vulnerability issue is a low-level error; If the error level of the target historical vulnerability issue is a low-level error, then the status information of the issue to be processed is determined to be an ignorable issue; If the error level of the target historical vulnerability is not a low-level error, the status information of the problem to be processed is determined to be resolved, and the person in charge of the problem to be processed is updated.

6. The method according to claim 1, characterized in that, The status information for each vulnerability issue includes: unresolved, resolved, and negligible. The process of handling each vulnerability issue based on its status information and final issue score includes: For the vulnerabilities in the aforementioned vulnerability issue set whose status information is "resolved" or "negligible", close the vulnerability operation; For the vulnerability issues in the vulnerability issue set whose status information is unresolved, the processing priority is sorted according to the final score of each vulnerability issue, and each vulnerability issue is processed according to the processing priority of each vulnerability issue.

7. The method according to claim 1, characterized in that, The method further includes: Generate a static code analysis report; wherein the static code analysis report includes: overview information and detailed information; the overview information includes: the name of the target static code analysis tool, the total number of issues scanned by the target static code analysis tool, and the number of issues corresponding to each error level scanned by the target static code analysis tool; the detailed information includes: the error category of each vulnerability issue scanned by the target static code analysis tool, the error level of each vulnerability issue, the person responsible for each vulnerability issue, and the status information of each vulnerability issue.

8. A multi-tool static code analysis and management device, characterized in that, Applied to a target application that integrates calling interfaces for various static code analysis tools, the device includes: The instruction receiving module is used to receive error category checking instructions input by the user; The tool recommendation module is used to determine the target static code inspection tool based on the error category inspection instruction; the target static code inspection tool is the tool with the highest accuracy in checking the error category recommended to the user from a variety of static code inspection tools based on the error category inspection instruction. The level acquisition module is used to call the target static code inspection tool through the interface to inspect the target code module and obtain the initial error level of each vulnerability in the vulnerability issue set; The error classification module is used to reclassify the initial error level of each vulnerability in the vulnerability problem set based on a preset error level classification standard, and obtain the preset error level of each vulnerability problem. The issue scoring module is used to obtain the final issue score for each vulnerability issue based on a preset error level for each vulnerability issue; The status information module is used to obtain the status information of each vulnerability in real time; The problem handling module is used to process each vulnerability problem based on its status information and final problem score. The question scoring module is specifically used for: Based on the preset error level of each vulnerability issue, the initial problem score of each vulnerability issue is determined; Obtain the set of vulnerabilities detected by the target static code analysis tool under the target language type; the set of vulnerabilities includes: a first preset number of valid vulnerabilities and a second preset number of invalid vulnerabilities corresponding to various error categories; Input the first preset number of valid questions and the second preset number of invalid questions corresponding to each of the various error categories into the preset service scoring model, and output the accuracy rate of question judgment corresponding to each error category; The initial problem score of each vulnerability problem and the accuracy of the judgment of the error category corresponding to each vulnerability problem are input into the preset problem scoring model, and the final problem score of each vulnerability problem is output.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the multi-tool static code inspection management method as described in any one of claims 1 to 7.

Images