Vulnerability scanning auditing method and related device

Abstract

The invention discloses a vulnerability scanning auditing method and a related device, and relates to the field of software testing. After a to-be-audited vulnerability scanning file in a preset format is obtained, whether first scanning result data in the to-be-audited vulnerability scanning file is compliant or not is judged according to a standard verification rule. And on the basis of judging that the first scanning result data is compliant, judging whether software associated with the to-be-audited vulnerability scanning file is a scanning-free type or not. If yes, whether second scanning result data in the to-be-audited vulnerability scanning file is compliant or not is judged according to pre-configured scanning-free management content. And when the software associated with the to-be-audited vulnerability scanning file is not a scanning-free type, judging whether third scanning result data in the to-be-audited vulnerability scanning file is compliant or not according to pre-configured vulnerability management content. According to the vulnerability scanning auditing method, the compliance of the vulnerability scanning file can be automatically judged according to the configured management content and the judgment process, and the checking efficiency and accuracy are effectively improved.

Description

Technical Field

[0001] The present application relates to the field of software testing technology, and in particular to a vulnerability scanning and auditing method and related devices. Background Art

[0002] Software production inspection refers to the inspection and testing of the delivered version before production according to the production inspection specification requirements, which mainly includes: non-functional inspection, specification inspection, security inspection, installation inspection and functional inspection. Among them, security inspection is a more important part of production inspection, and the vulnerability scanning and verification in security inspection is the most important. At present, the verification of vulnerability scanning is mainly done manually, which not only consumes a lot of manpower, but also has low efficiency and is prone to errors. Summary of the invention

[0003] In view of the above problems, this application provides a vulnerability scanning audit method and related devices to achieve the purpose of improving the audit efficiency. The specific scheme is as follows:

[0004] The first aspect of the present application provides a vulnerability scanning audit method, comprising:

[0005] Get the vulnerability scan file to be reviewed in a preset format;

[0006] According to the standard verification rules, determine whether the first scan result data in the vulnerability scan file to be reviewed is compliant;

[0007] If yes, determine whether the software associated with the vulnerability scanning file to be reviewed is of the scan-free type;

[0008] If so, judging whether the second scan result data in the vulnerability scan file to be reviewed is compliant according to the pre-configured scan-free management content;

[0009] If the software associated with the vulnerability scanning file to be reviewed is not of the scan-free type, it is determined whether the third scanning result data in the vulnerability scanning file to be reviewed is compliant according to the pre-configured vulnerability management content.

[0010] In a possible implementation, the vulnerability scanning audit method further includes:

[0011] When the judgment results of the second scanning result number and the third scanning result data are both compliant, the problem content is extracted from the scanning result data of the vulnerability scanning file to be audited according to the problem management field name to generate audit result data, and the scanning result data includes: the first scanning result data, the second scanning result data and the third scanning result data.

[0012] In a possible implementation, judging whether the first scan result data in the vulnerability scan file to be reviewed is compliant according to the specification verification rule includes:

[0013] According to the task code of the vulnerability scanning file to be reviewed, determining whether the vulnerability scanning file to be reviewed is a vulnerability scanning deliverable;

[0014] Determine whether the launch time point, launch type and system information in the vulnerability scanning file to be reviewed match the basic information of the software;

[0015] Determine whether the fields of the preset mandatory items in the vulnerability scanning file to be reviewed are empty.

[0016] In a possible implementation, judging whether the first scan result data in the vulnerability scan file to be reviewed is compliant according to the specification verification rule further includes:

[0017] Determine whether there are at least two identifiers representing vulnerability types in the vulnerability scanning file to be reviewed;

[0018] When the identifier representing the vulnerability type in the vulnerability scanning file to be reviewed is one, it is determined whether the rectification status of the vulnerability is a null value.

[0019] In a possible implementation, judging whether the second scan result data in the vulnerability scan file to be reviewed is compliant according to the pre-configured scan-free management content includes:

[0020] If the software is of the first scan-free type, determining whether the scan-free reason and the scan-free type of the software are correct;

[0021] If the software is of the second scan-free type, determining whether the software exists in the scan-free whitelist;

[0022] If the software is in the scan-free whitelist, determining whether the scan-free reason and scan-free type of the software are correct;

[0023] If the software is not in the scan-free whitelist, the correctness of the scan-free reason and the scan-free type is determined based on the approval information.

[0024] In a possible implementation, judging whether the third scan result data in the vulnerability scan file to be reviewed is compliant according to the pre-configured vulnerability management content includes:

[0025] If there are vulnerabilities in the vulnerability scanning file to be reviewed, and the risk level of the vulnerability is not higher than the preset risk level, the compliance of the vulnerability is determined according to the general vulnerability approval rules;

[0026] If the risk level of the vulnerability is higher than the preset risk level, compliance is determined based on vulnerability approval rules that match the type of the vulnerability.

[0027] A second aspect of the present application provides a vulnerability scanning and auditing device, comprising:

[0028] A file acquisition module, used to obtain vulnerability scanning files to be reviewed in a preset format;

[0029] A standard verification module, used to determine whether the first scan result data in the vulnerability scan file to be reviewed is compliant according to standard verification rules;

[0030] A type judgment module, configured to judge whether the software associated with the vulnerability scanning file to be reviewed is a scan-free type when the specification verification module judges that the first scan result data in the vulnerability scanning file to be reviewed is compliant;

[0031] A scan-free judgment module, used to judge whether the second scan result data in the vulnerability scanning file to be reviewed is compliant according to pre-configured scan-free management content when the type judgment module judges that the software associated with the vulnerability scanning file to be reviewed is of the scan-free type; and

[0032] The vulnerability judgment module is used to judge whether the third scanning result data in the vulnerability scanning file to be reviewed is compliant according to the pre-configured vulnerability management content when the type judgment module judges that the software associated with the vulnerability scanning file to be reviewed is not of the scan-free type.

[0033] A third aspect of the present application provides a computer program product, including computer-readable instructions. When the computer-readable instructions are executed on an electronic device, the electronic device implements the vulnerability scanning and auditing method of the first aspect or any implementation of the first aspect.

[0034] A fourth aspect of the present application provides an electronic device, comprising at least one processor and a memory connected to the processor, wherein:

[0035] The memory is used to store computer programs;

[0036] The processor is used to execute the computer program so that the electronic device can implement the vulnerability scanning and auditing method of the above-mentioned first aspect or any implementation method of the first aspect.

[0037] A fifth aspect of the present application provides a computer storage medium, which carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can perform the vulnerability scanning and auditing method of the above-mentioned first aspect or any implementation of the first aspect.

[0038] By means of the above technical scheme, the vulnerability scanning audit method provided by the present application determines whether the first scanning result data in the vulnerability scanning file to be audited is compliant according to the standard verification rules after obtaining the vulnerability scanning file to be audited in a preset format. On the basis of determining that the first scanning result data is compliant, determine whether the software associated with the vulnerability scanning file to be audited is a scan-free type. If so, determine whether the second scanning result data in the vulnerability scanning file to be audited is compliant according to the pre-configured scan-free management content. When the software associated with the vulnerability scanning file to be audited is not a scan-free type, determine whether the third scanning result data in the vulnerability scanning file to be audited is compliant according to the pre-configured vulnerability management content. The vulnerability scanning audit method can automatically judge the compliance of the vulnerability scanning file according to the configured management content and judgment process, thereby effectively improving the efficiency and accuracy of manual verification. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] The above and other features, advantages and aspects of the embodiments of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. Throughout the accompanying drawings, the same or similar reference numerals represent the same or similar elements. It should be understood that the drawings are schematic and the originals and elements are not necessarily drawn to scale.

[0040] Figure 1 An architectural diagram of a vulnerability scanning and auditing system provided for this application;

[0041] Figure 2 An architecture diagram of a terminal provided for this application;

[0042] Figure 3 An architectural diagram of a server provided for this application;

[0043] Figure 4 A flowchart of a vulnerability scanning and auditing method provided for this application;

[0044] Figure 5 A flowchart of another vulnerability scanning audit method provided for this application;

[0045] Figure 6 A flow chart for determining the scan-free type provided for this application;

[0046] Figure 7 A flowchart for determining the existence of vulnerabilities provided for this application;

[0047] Figure 8 A structural diagram of a vulnerability scanning and auditing device provided by this application;

[0048] Fig. 9 An architectural diagram of an electronic device provided in this application. DETAILED DESCRIPTION

[0049] The following describes the embodiments of the present application in conjunction with the drawings in the embodiments of the present application. The terms used in the implementation method section of the present application are only used to explain the specific embodiments of the present application, and are not intended to limit the present application.

[0050] The embodiments of the present application are described below in conjunction with the accompanying drawings. Those skilled in the art will appreciate that, with the development of technology and the emergence of new scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0051] The terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and need not be used to describe a specific order or sequential order. It should be understood that the terms used in this way can be interchangeable under appropriate circumstances, which is only to describe the distinction mode adopted by the objects of the same attributes when describing in the embodiments of the present application. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, so that the process, method, system, product or equipment comprising a series of units need not be limited to those units, but may include other units that are not clearly listed or inherent to these processes, methods, products or equipment.

[0052] See also Figure 1 , Figure 1 1 shows a schematic diagram of the architecture of a vulnerability scanning and auditing system. The system may include a terminal 100 and a server 200. The server 200 may include one or more servers ( Figure 1 In the example, a server is included, and the server 200 can provide the vulnerability scanning and auditing method provided in the embodiment of the present application for one or more terminals.

[0053] Among them, an application for managing vulnerability scanning files can be installed on the terminal 100. The above application and web page can provide an interface. The terminal 100 can receive the vulnerability scanning file input by the user on the management interface, and send the above vulnerability scanning file to the server 200. The server 200 can obtain the processing result based on the received parameters and return the processing result to the terminal 100.

[0054] It should be understood that in some optional implementations, the terminal 100 can also complete the action of obtaining the processing result based on the received parameters by itself without the cooperation of the server, and the embodiments of the present application are not limited to this.

[0055] Next describe Figure 1 The product form of the mid-terminal 100;

[0056] The terminal 100 in the embodiment of the present application can be a mobile phone, a tablet computer, a wearable device, a vehicle-mounted device, an augmented reality (AR) / virtual reality (VR) device, a laptop computer, an ultra-mobile personal computer (UMPC), a netbook, a personal digital assistant (PDA), etc., and the embodiment of the present application does not impose any limitation on this.

[0057] Figure 2 An optional hardware structure diagram of the terminal 100 is shown.

[0058] refer to Figure 2 As shown, the terminal 100 may include a radio frequency unit 110, a memory 120, an input unit 130, a display unit 140, a camera 150 (optional), an audio circuit 160 (optional), a speaker 161 (optional), a microphone 162 (optional), an earphone jack 163 (optional), a processor 170, an external interface 180, a power supply 190 and other components. Those skilled in the art will appreciate that Figure 2 These are merely examples of terminals or multi-function devices and do not constitute limitations on the terminals or multi-function devices, which may include more or fewer components than those shown in the figures, or combinations of certain components, or different components.

[0059] The input unit 130 can be used to receive input digital or character information, and generate key signal input related to the user settings and function control of the portable multifunctional device. Specifically, the input unit 130 may include a touch screen 131 (optional) and / or other input devices 132. The touch screen 131 can collect the user's touch operations on or near it (such as the user's operation on or near the touch screen using any suitable object such as fingers, joints, stylus, etc.), and drive the corresponding connection device according to a pre-set program. The touch screen can detect the user's touch action on the touch screen, convert the touch action into a touch signal and send it to the processor 170, and can receive and execute the command sent by the processor 170; the touch signal at least includes the touch point coordinate information. The touch screen 131 can provide an input interface and an output interface between the terminal 100 and the user. In addition, the touch screen can be implemented using multiple types such as resistive, capacitive, infrared and surface acoustic wave. In addition to the touch screen 131, the input unit 130 can also include other input devices. Specifically, other input devices 132 may include, but are not limited to, one or more of a physical keyboard, function keys (such as a volume control key, a switch key, etc.), a trackball, a mouse, a joystick, and the like.

[0060] Among them, the input device 132 can receive input data and the like.

[0061] The display unit 140 can be used to display information input by the user or provided to the user, various menus of the terminal 100, interactive interfaces, file display and / or playback of any multimedia file. In the embodiment of the present application, the display unit 140 can be used to display the interface of vulnerability scanning file management, processing results, etc.

[0062] The memory 120 can be used to store instructions and data. The memory 120 can mainly include an instruction storage area and a data storage area. The data storage area can store various data, such as multimedia files, texts, etc.; the instruction storage area can store software units such as operating systems, applications, instructions required for at least one function, or their subsets and extensions. It can also include a non-volatile random access memory; provide the processor 170 with hardware, software and data resources including management of computing and processing equipment, and support control software and applications. It is also used for the storage of multimedia files, and the storage of running programs and applications.

[0063] The processor 170 is the control center of the terminal 100. It uses various interfaces and lines to connect various parts of the entire terminal 100. By running or executing instructions stored in the memory 120 and calling data stored in the memory 120, it executes various functions of the terminal 100 and processes data, thereby controlling the terminal device as a whole. Optionally, the processor 170 may include one or more processing units; preferably, the processor 170 may integrate an application processor and a modem processor, wherein the application processor mainly processes the operating system, user interface and application program, and the modem processor mainly processes wireless communication. It is understandable that the above-mentioned modem processor may not be integrated into the processor 170. In some embodiments, the processor and the memory may be implemented on a single chip, and in some embodiments, they may also be implemented separately on separate chips. The processor 170 may also be used to generate corresponding operation control signals, send them to corresponding components of the computing and processing device, read and process data in the software, especially read and process data and programs in the memory 120, so that each functional module therein performs corresponding functions, thereby controlling the corresponding components to act according to the requirements of the instructions.

[0064] Among them, the memory 120 can be used to store software codes related to the vulnerability scanning and auditing method, the processor 170 can execute the steps of the vulnerability scanning and auditing method, and can also schedule other units (such as the above-mentioned input unit 130 and display unit 140) to implement corresponding functions.

[0065] The radio frequency unit 110 (optional) can be used for receiving and sending information or receiving and sending signals during a call, for example, after receiving the downlink information of the base station, it is sent to the processor 170 for processing; in addition, the designed uplink data is sent to the base station. Generally, the RF circuit includes but is not limited to an antenna, at least one amplifier, a transceiver, a coupler, a low noise amplifier (Low Noise Amplifier, LNA), a duplexer, etc. In addition, the radio frequency unit 110 can also communicate with network devices and other devices through wireless communication. The wireless communication can use any communication standard or protocol, including but not limited to Global System of Mobile communication (Global System of Mobile communication, GSM), General Packet Radio Service (General Packet Radio Service, GPRS), Code Division Multiple Access (Code Division Multiple Access, CDMA), Wideband Code Division Multiple Access (Wideband Code Division Multiple Access, WCDMA), Long Term Evolution (Long Term Evolution, LTE), email, Short Messaging Service (SMS), etc.

[0066] In this embodiment of the present application, the radio frequency unit 110 can send the vulnerability scanning file to the server 200 and receive the audit result information sent by the server 200.

[0067] It should be understood that the radio frequency unit 110 is optional and can be replaced by other communication interfaces, such as a network port.

[0068] The terminal 100 also includes a power supply 190 (such as a battery) for supplying power to various components. Preferably, the power supply can be logically connected to the processor 170 through a power management system, so that the power management system can manage functions such as charging, discharging, and power consumption.

[0069] The terminal 100 further includes an external interface 180 , which may be a standard Micro USB interface or a multi-pin connector, and may be used to connect the terminal 100 to communicate with other devices, or to connect a charger to charge the terminal 100 .

[0070] Although not shown, the terminal 100 may also include a flashlight, a wireless fidelity (WiFi) module, a Bluetooth module, sensors with different functions, etc., which are not described in detail here. Some or all of the methods described below may be applied in the following embodiments. Figure 2 In the terminal 100 shown.

[0071] Next describe Figure 1 The product form of the server 200;

[0072] Figure 3 A structural diagram of a server 200 is provided, such as Figure 3 As shown, the server 200 includes a bus 201, a processor 202, a communication interface 203, and a memory 204. The processor 202, the memory 204, and the communication interface 203 communicate with each other via the bus 201.

[0073] The bus 201 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 3 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0074] The processor 202 may be any one or more of a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0075] The memory 204 may include a volatile memory, such as a random access memory (RAM). The memory 204 may also include a non-volatile memory, such as a read-only memory (ROM), a flash memory, a hard disk drive (HDD), or a solid state drive (SSD).

[0076] The memory 204 may be used to store software codes related to the vulnerability scanning and auditing method, the processor 202 may execute the steps of the vulnerability scanning and auditing method of the chip, and may also schedule other units to implement corresponding functions.

[0077] It should be understood that the above-mentioned terminal 100 and server 200 can be centralized or distributed devices, and the processors in the above-mentioned terminal 100 and server 200 (such as processor 170 and processor 202) can be hardware circuits (such as application specific integrated circuit (ASIC), field-programmable gate array (FPGA), general-purpose processor, digital signal processor (DSP), microprocessor or microcontroller, etc.), or a combination of these hardware circuits. For example, the processor can be a hardware system with an instruction execution function, such as a CPU, DSP, etc., or a hardware system without an instruction execution function, such as an ASIC, FPGA, etc., or a combination of the above-mentioned hardware systems without an instruction execution function and hardware systems with an instruction execution function.

[0078] The production inspection of software products includes: non-functional inspection, specification inspection, security inspection, installation inspection, functional inspection, etc. Among them, security inspection is a more important part of production inspection, including code security inspection, cascade WAF inspection, open source vulnerability scanning and verification, etc.

[0079] Among them, the scanning and verification of open source vulnerabilities is particularly important. The timeliness, accuracy, and standardization of the results of the open source vulnerability scanning all have an impact on the verification results. Therefore, the open source vulnerability scanning automated review system must not only verify the timeliness and accuracy of the delivered report, but also verify the standardization, and automatically record the problems generated during the verification process. At present, the timeliness of the open source vulnerability scanning is mainly verified manually, which can neither guarantee accuracy nor waste a lot of manpower.

[0080] The accuracy check of open source vulnerability scanning includes the inspection of leadership approval information, scan exemption reason matching information, etc., which is mainly done through manual comparison, which is prone to errors and has high labor costs.

[0081] In order to solve the above problems, the embodiment of the present application provides a vulnerability scanning and auditing method. The vulnerability scanning and auditing method of the embodiment of the present application is described in detail below in conjunction with the accompanying drawings.

[0082] Reference Figure 4 , Figure 4 A schematic diagram of a vulnerability scanning and auditing method provided in an embodiment of the present application is shown in FIG. Figure 4 As shown, a vulnerability scanning and auditing method provided in an embodiment of the present application may include steps 401 to 405, and these steps are described in detail below.

[0083] 401. Get the vulnerability scan file to be reviewed in a preset format.

[0084] Specifically, after the open source vulnerability scan of the software is completed, a vulnerability scan file containing the scan results in json format will be generated. Of course, files in other formats can also be used to generate vulnerability scan files, which is not limited here.

[0085] 402. According to the standard verification rules, determine whether the first scan result data in the vulnerability scan file to be reviewed is compliant.

[0086] Specifically, a normative check is performed first, and only after the normative check is passed will the subsequent compliance judgment process be carried out. That is, the normative check is the basis for the subsequent free scanning and vulnerability detection process.

[0087] Normative verification may include: task coding verification, confirming whether it is an open source vulnerability scanning deliverable; three-factor verification, verifying the matching relationship between the commissioning point, commissioning type, and English name of the physical subsystem and the baseline information; mandatory field verification: verification that the mandatory fields in the json message are not empty; mutually exclusive scenario verification, verifying whether the "whether a new vulnerability is added", "whether it is a general vulnerability", and "whether it is a mitigation and downgrade vulnerability" flags of the vulnerability are both "yes" at the same time. Here, the compliant scenario should be that only one is "yes", that is, there will be only one classification for each vulnerability; abnormal scenario verification: verifying whether the "whether a new vulnerability is added", "whether it is a general vulnerability", and "whether it is a mitigation and downgrade vulnerability" of the vulnerability is "yes", whether the "rectification status" is a false alarm / no rectification required / rectified. At this time, the compliant scenario should be that when there is any judgment result of any verification vulnerability, there should be corresponding rectification status information, and the rectification status information should not be an empty value.

[0088] On the basis of the above-mentioned normative verification criteria, the judgment process of whether the first scan result data is compliant may include: judging whether the vulnerability scanning file to be reviewed is a vulnerability scanning deliverable according to the task code of the vulnerability scanning file to be reviewed. Judging whether the production time point, production type and system information in the vulnerability scanning file to be reviewed match the basic information of the software respectively. Judging whether the fields of the preset required items in the vulnerability scanning file to be reviewed are empty. Judging whether there are no less than two identifiers representing the vulnerability type in the vulnerability scanning file to be reviewed, and when there is only one identifier representing the vulnerability type in the vulnerability scanning file to be reviewed, judging whether the rectification status of the vulnerability is a null value. Only after the above-mentioned judgment processes are verified and passed, will it be judged that the normative verification has passed. If any of the verifications fail, it will be judged as a verification failure.

[0089] It is understandable that those skilled in the art may adjust the criteria and verification process of the above-mentioned standard verification as needed, which will not be elaborated here.

[0090] 403. If yes, determine whether the software associated with the vulnerability scanning file to be reviewed is of the scan-free type.

[0091] Specifically, after the above-mentioned specification verification is passed, it is determined whether the software is exempt from scanning (i.e., the process of exempting the open source vulnerability scanning). Here, the exempt scanning type can be determined by identifying the exempt scanning flag bit in the vulnerability scanning file.

[0092] 404. If yes, determine whether the second scan result data in the vulnerability scan file to be reviewed is compliant based on the pre-configured scan-free management content.

[0093] Specifically, the second scan result data is the scan result data of the scan-free scenario, where the scan-free type can be divided into two types: the first scan-free type is version scan-free, that is, the current version of the software is exempted from the scan of open source vulnerabilities. The second scan-free type is system scan-free, that is, all versions of the software are exempted from the scan of open source vulnerabilities.

[0094] When the software is of the first scan-free type, it is determined whether the scan-free reason and the scan-free type of the software are correct.

[0095] When the software is of the second scan-free type, it is determined whether the software is in the scan-free whitelist. When it is determined that the software is in the scan-free whitelist, it is determined whether the scan-free reason and the scan-free type of the software are correct. If the software is not in the scan-free whitelist, the correctness of the scan-free reason and the scan-free type is determined based on the approval information.

[0096] The scan-free whitelist can be configured to achieve flexible revision of configuration options, including scan-free reason configuration, general unrepair reason configuration, risk mitigation type configuration, approval personnel information configuration, approval personnel rank configuration, scan-free system whitelist configuration, etc.

[0097] 405. If the software associated with the vulnerability scanning file to be reviewed is not of the scan-free type, determine whether the third scan result data in the vulnerability scanning file to be reviewed is compliant based on the pre-configured vulnerability management content.

[0098] Specifically, when the software is not a scan-free type, the vulnerability information in the vulnerability scan file is reviewed and determined. When there is a vulnerability in the vulnerability scan file to be reviewed, and the risk level of the vulnerability is not higher than the preset risk level, the vulnerability is judged for compliance based on the general vulnerability approval rules. When the risk level of the vulnerability is higher than the preset risk level, the vulnerability is judged for compliance based on the vulnerability approval rules that match the type of vulnerability.

[0099] For example, the risk level of the vulnerability can be divided into five levels in order from low to high. When the risk level is higher than the third risk level, it is necessary to judge whether it is compliant according to the vulnerability approval rules.

[0100] This vulnerability scanning audit method, for open source vulnerability scanning of software, can automatically judge the compliance of vulnerability scanning files according to the configured management content and judgment process, thereby effectively improving the efficiency and accuracy of manual verification. And by adopting a matching design for configurable whitelists involving many verification items, flexible revision of configuration options is achieved, increasing the scope of application of this vulnerability scanning audit method.

[0101] In order to facilitate the subsequent targeted processing and improvement of the problems existing in the vulnerability scanning file, the vulnerability scanning file review method also includes:

[0102] When the judgment results of the second scan result number and the third scan result data are both compliant, the problem content is extracted from the scan result data of the vulnerability scan file to be audited according to the problem management field name to generate audit result data, and the scan result data includes: first scan result data, second scan result data and third scan result data.

[0103] Specifically, for the problems generated in the above review process, the result data of the comparison process can be statistically analyzed by matching key fields, so as to facilitate the tracking and improvement of subsequent problems. The following table can be used for recording:

[0104]

[0105] It is understandable that those skilled in the art can adaptively increase or decrease the management content of the above-mentioned issues as needed, which will not be elaborated here.

[0106] As a specific application of the above vulnerability scanning and auditing method, refer to Figures 5 to 7 As shown, the vulnerability scanning and auditing method may specifically include the following processing procedures:

[0107] Reference Figure 5 As shown, after the delivery operation on the baseline of the open source vulnerability scan is detected, the delivery of the vulnerability scan file is obtained. The vulnerability scan file is subjected to a compliance check, and when it is determined that the compliance check condition is not met, it is determined that the check fails.

[0108] Reference Figure 6As shown in the figure, after the compliance check is passed, the vulnerability scanning file is judged whether it is exempt from scanning. On the basis of judging that it is exempt from scanning, the type of exempt scanning is judged. The types of exempt scanning are divided into version exempt scanning and system exempt scanning. If it is version exempt scanning, the correctness of the reasons for exempt scanning and the types of exempt scanning is verified. If it is system exempt scanning, first determine whether the system exists in the exempt scanning whitelist. If it is in the exempt scanning whitelist, determine the type of exempt scanning and the reasons for exempt scanning. If it is not in the exempt scanning whitelist, determine the type of exempt scanning, the reasons for exempt scanning, and the approval information.

[0109] Reference Figure 7 As shown in the figure, for non-scan-free software systems, first determine whether there are vulnerabilities. If there are vulnerabilities and they are high-risk vulnerabilities, several special scenarios are determined. Special scenarios are divided into risk mitigation and degradation, and scenarios containing general identification vulnerabilities. If it is a medium-low risk vulnerability, it is approved according to the medium-low risk vulnerability approval rules.

[0110] It should be noted that the above audit process can be adjusted according to different audit items and types, which will not be elaborated here.

[0111] A vulnerability scanning and auditing method provided by an embodiment of the present application is introduced above, and a device for executing the above vulnerability scanning and auditing method will be introduced below.

[0112] See also Figure 8 , Figure 8 A schematic diagram of the structure of a vulnerability scanning and auditing device provided in an embodiment of the present application. Figure 8 As shown, the vulnerability scanning and auditing device includes:

[0113] The file acquisition module 801 is used to acquire a vulnerability scanning file to be reviewed in a preset format.

[0114] The standard verification module 802 is used to determine whether the first scan result data in the vulnerability scan file to be reviewed is compliant according to the standard verification rules.

[0115] The type determination module 803 is used to determine whether the software associated with the vulnerability scanning file to be reviewed is a scan-free type when the specification verification module determines that the first scan result data in the vulnerability scanning file to be reviewed is compliant.

[0116] The scan-free judgment module 804 is used to judge whether the second scan result data in the vulnerability scanning file to be reviewed is compliant according to the pre-configured scan-free management content when the type judgment module judges that the software associated with the vulnerability scanning file to be reviewed is of the scan-free type. And,

[0117] The vulnerability judgment module 805 is used to judge whether the third scanning result data in the vulnerability scanning file to be reviewed is compliant according to the pre-configured vulnerability management content when the type judgment module judges that the software associated with the vulnerability scanning file to be reviewed is not of the scan-free type.

[0118] In a possible implementation, it also includes: an audit result generation module, which is used to extract the problem content from the scan result data of the vulnerability scan file to be audited according to the problem management field name when the judgment results of the second scan result number and the third scan result data are both compliant, and generate audit result data, the scan result data including: the first scan result data, the second scan result data and the third scan result data.

[0119] In a possible implementation, the process of the specification verification module 802 determining whether the first scan result data in the vulnerability scan file to be reviewed is compliant according to the specification verification rule includes:

[0120] According to the task code of the vulnerability scanning file to be reviewed, determining whether the vulnerability scanning file to be reviewed is a vulnerability scanning deliverable;

[0121] Determine whether the launch time point, launch type and system information in the vulnerability scanning file to be reviewed match the basic information of the software;

[0122] Determine whether the fields of the preset mandatory items in the vulnerability scanning file to be reviewed are empty.

[0123] In a possible implementation, the process of the specification verification module 802 determining whether the first scan result data in the vulnerability scan file to be reviewed is compliant according to the specification verification rule also includes:

[0124] Determine whether there are at least two identifiers representing vulnerability types in the vulnerability scanning file to be reviewed;

[0125] When the identifier representing the vulnerability type in the vulnerability scanning file to be reviewed is one, it is determined whether the rectification status of the vulnerability is a null value.

[0126] In a possible implementation, the process of the scan-free determination module 804 determining whether the second scan result data in the vulnerability scan file to be reviewed is compliant according to the pre-configured scan-free management content includes:

[0127] If the software is of the first scan-free type, determining whether the scan-free reason and the scan-free type of the software are correct;

[0128] If the software is of the second scan-free type, determining whether the software exists in the scan-free whitelist;

[0129] If the software is in the scan-free whitelist, determining whether the scan-free reason and scan-free type of the software are correct;

[0130] If the software is not in the scan-free whitelist, the correctness of the scan-free reason and the scan-free type is determined based on the approval information.

[0131] In a possible implementation, the process of the vulnerability determination module 805 determining whether the third scan result data in the vulnerability scan file to be reviewed is compliant according to the pre-configured vulnerability management content includes:

[0132] If there are vulnerabilities in the vulnerability scanning file to be reviewed, and the risk level of the vulnerability is not higher than the preset risk level, the compliance of the vulnerability is determined according to the general vulnerability approval rules;

[0133] If the risk level of the vulnerability is higher than the preset risk level, compliance is determined based on vulnerability approval rules that match the type of the vulnerability.

[0134] The present application also provides an electronic device in an embodiment. Fig. 9 As shown, it shows a schematic diagram of the structure of an electronic device suitable for implementing the embodiment of the present application. The electronic device in the embodiment of the present application may include but is not limited to fixed terminals such as mobile phones, laptops, PDAs (personal digital assistants), PADs (tablet computers), desktop computers, etc. Fig. 9 The electronic device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0135] like Fig. 9 As shown, the electronic device may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 901, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 902 or a program loaded from a storage device 908 to a random access memory (RAM) 903. When the electronic device is powered on, various programs and data required for the operation of the electronic device are also stored in the RAM 903. The processing device 901, the ROM 902, and the RAM 903 are connected to each other via a bus 904. An input / output (I / O) interface 905 is also connected to the bus 904.

[0136] Typically, the following devices may be connected to the I / O interface 905: an input device 906 including, for example, a touch screen, a touch pad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; an output device 907 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 908 including, for example, a memory card, a hard disk, etc.; and a communication device 909. The communication device 909 may allow the electronic device to communicate with other devices wirelessly or by wire to exchange data. Although Fig. 9 An electronic device having various devices is shown, but it should be understood that it is not required to implement or possess all the devices shown. More or fewer devices may be implemented or possessed instead.

[0137] An embodiment of the present application also provides a computer program product including computer-readable instructions. When the computer-readable instructions are executed on an electronic device, the electronic device implements any vulnerability scanning and auditing method provided in the embodiment of the present application.

[0138] A computer-readable storage medium is also provided in an embodiment of the present application. The storage medium carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any vulnerability scanning and auditing method provided in an embodiment of the present application.

[0139] It should also be noted that the device embodiments described above are merely schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed over multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. In addition, in the drawings of the device embodiments provided by the present application, the connection relationship between the modules indicates that there is a communication connection between them, which may be specifically implemented as one or more communication buses or signal lines.

[0140] Through the description of the above implementation mode, the technicians in the field can clearly understand that the present application can be implemented by means of software plus necessary general hardware, and of course, it can also be implemented by special hardware including special integrated circuits, special CPUs, special memories, special components, etc. In general, all functions completed by computer programs can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be various, such as analog circuits, digital circuits or special circuits. However, for the present application, software program implementation is a better implementation mode in more cases. Based on such an understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a readable storage medium, such as a computer floppy disk, a U disk, a mobile hard disk, a ROM, a RAM, a disk or an optical disk, etc., including a number of instructions to enable a computer device (which can be a personal computer, a training device, or a network device, etc.) to execute the methods described in each embodiment of the present application.

[0141] In the above embodiments, all or part of the embodiments may be implemented by software, hardware, firmware or any combination thereof. When implemented by software, all or part of the embodiments may be implemented in the form of a computer program product.

[0142] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website site, a computer, a training device, or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, training device, or data center. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device, a data center, etc. that includes one or more available media integrations. The available medium may be a magnetic medium, (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)), etc.

Claims

1. A vulnerability scanning and auditing method, characterized in that: include: Get the vulnerability scan file to be reviewed in a preset format; According to the standard verification rules, determine whether the first scan result data in the vulnerability scan file to be reviewed is compliant; If yes, determine whether the software associated with the vulnerability scanning file to be reviewed is of the scan-free type; If so, judging whether the second scan result data in the vulnerability scan file to be reviewed is compliant according to the pre-configured scan-free management content; If the software associated with the vulnerability scanning file to be reviewed is not of the scan-free type, it is determined whether the third scanning result data in the vulnerability scanning file to be reviewed is compliant according to the pre-configured vulnerability management content.

2. The vulnerability scanning and auditing method according to claim 1, characterized in that: Also includes: When the judgment results of the second scanning result number and the third scanning result data are both compliant, the problem content is extracted from the scanning result data of the vulnerability scanning file to be audited according to the problem management field name to generate audit result data, and the scanning result data includes: the first scanning result data, the second scanning result data and the third scanning result data.

3. The vulnerability scanning and auditing method according to claim 1, characterized in that: The step of judging whether the first scan result data in the vulnerability scan file to be reviewed is compliant according to the standard verification rule includes: According to the task code of the vulnerability scanning file to be reviewed, determining whether the vulnerability scanning file to be reviewed is a vulnerability scanning deliverable; Determine whether the launch time point, launch type and system information in the vulnerability scanning file to be reviewed match the basic information of the software; Determine whether the fields of the preset mandatory items in the vulnerability scanning file to be reviewed are empty.

4. The vulnerability scanning and auditing method according to claim 3, characterized in that: The step of judging whether the first scan result data in the vulnerability scan file to be reviewed is compliant according to the standard verification rule also includes: Determine whether there are at least two identifiers representing vulnerability types in the vulnerability scanning file to be reviewed; When the identifier representing the vulnerability type in the vulnerability scanning file to be reviewed is one, it is determined whether the rectification status of the vulnerability is a null value.

5. The vulnerability scanning and auditing method according to claim 1, characterized in that: The step of judging whether the second scan result data in the vulnerability scan file to be reviewed is compliant according to the pre-configured scan-free management content includes: If the software is of the first scan-free type, determining whether the scan-free reason and the scan-free type of the software are correct; If the software is of the second scan-free type, determining whether the software exists in the scan-free whitelist; If the software is in the scan-free whitelist, determining whether the scan-free reason and scan-free type of the software are correct; If the software is not in the scan-free whitelist, the correctness of the scan-free reason and the scan-free type is determined based on the approval information.

6. The vulnerability scanning and auditing method according to any one of claims 1 to 5, characterized in that: The determining, based on the pre-configured vulnerability management content, whether the third scan result data in the vulnerability scan file to be reviewed is compliant includes: If there are vulnerabilities in the vulnerability scanning file to be reviewed, and the risk level of the vulnerability is not higher than the preset risk level, the compliance of the vulnerability is determined according to the general vulnerability approval rules; If the risk level of the vulnerability is higher than the preset risk level, compliance is determined based on vulnerability approval rules that match the type of the vulnerability.

7. A vulnerability scanning and auditing device, characterized in that: include: A file acquisition module, used to obtain vulnerability scanning files to be reviewed in a preset format; A standard verification module, used to determine whether the first scan result data in the vulnerability scan file to be reviewed is compliant according to standard verification rules; A type judgment module, configured to judge whether the software associated with the vulnerability scanning file to be reviewed is a scan-free type when the specification verification module judges that the first scan result data in the vulnerability scanning file to be reviewed is compliant; The scan-free judgment module is used to judge whether the second scan result data in the vulnerability scanning file to be reviewed is compliant according to the pre-configured scan-free management content when the type judgment module judges that the software associated with the vulnerability scanning file to be reviewed is of the scan-free type; as well as, The vulnerability judgment module is used to judge whether the third scanning result data in the vulnerability scanning file to be reviewed is compliant according to the pre-configured vulnerability management content when the type judgment module judges that the software associated with the vulnerability scanning file to be reviewed is not of the scan-free type.

8. A computer program product, characterized in that It includes computer-readable instructions, and when the computer-readable instructions are executed on an electronic device, the electronic device implements the vulnerability scanning and auditing method as described in any one of claims 1 to 6.

9. An electronic device, characterized in that: The method comprises at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program so that the electronic device can implement the vulnerability scanning and auditing method as described in any one of claims 1 to 6.

10. A computer storage medium, characterized in that: The storage medium carries one or more computer programs, and when the one or more computer programs are executed by an electronic device, the electronic device can implement the vulnerability scanning and auditing method as described in any one of claims 1 to 6.

Images