Detailed Description
Example embodiments will now be described more fully with reference to the accompanying drawings. However, the exemplary embodiments may be embodied in many forms and should not be construed as limited to the examples set forth herein, but rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of the present disclosure. One skilled in the relevant art will recognize, however, that the aspects of the disclosure may be practiced without one or more of the specific details, or with other methods, components, devices, steps, etc. In other instances, well-known technical solutions have not been shown or described in detail to avoid obscuring aspects of the present disclosure.
The terms "a," "an," "the," and "said" are used in this specification to denote the presence of one or more elements/components/etc., and the terms "comprising" and "having" are used in an open-ended sense and mean that there may be additional elements/components/etc. in addition to the listed elements/components/etc.
Furthermore, the drawings are merely schematic illustrations of the present disclosure and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and thus a repetitive description thereof will be omitted. Some of the block diagrams shown in the figures are functional entities and do not necessarily correspond to physically or logically separate entities. These functional entities may be implemented in software or in one or more hardware modules or integrated circuits or in different networks and/or processor devices and/or microcontroller devices.
With the rapid development of information technology, software systems have become increasingly complex, often relying on a large number of external libraries and frameworks to achieve various functions. These third party components, while accelerating the development process, introduce new security challenges. An attacker often exploits known vulnerabilities in these components to launch attacks, resulting in data leakage, service interruption, or even more serious security events. Therefore, it becomes critical for software developers and security specialists to identify and manage security risks in these dependencies.
Traditional vulnerability detection methods, such as Static Application Security Test (SAST) and Dynamic Application Security Test (DAST), have achieved a certain success in identifying software vulnerabilities. However, these methods often have limitations such as insufficient support for dynamic type languages, high false positive rates, and inability to intervene in early stages of software development. In addition, with the popularization of continuous set practice, the iteration speed of software is increased, and the conventional vulnerability detection method has difficulty in meeting the requirements of quickly finding and repairing vulnerabilities.
In order to solve the above-mentioned problems, the present disclosure provides a method and apparatus for detecting software vulnerabilities, which can be applied to the system architecture of the exemplary application environment shown in fig. 1.
As shown in fig. 1, the system architecture 100 may include a terminal device 110 and a server 120. The terminal device 110 may be a terminal device such as a smart phone, a tablet computer, a desktop computer, a notebook computer, or an intelligent wearable device, and the server 120 generally refers to a background system that provides a service related to software vulnerability detection in the present exemplary embodiment, and may be a server or a cluster formed by multiple servers. The terminal 110 and the server 120 may form a connection through a wired or wireless communication link for data interaction.
In an exemplary embodiment, the software vulnerability detection method described above may be performed by terminal device 110. Accordingly, the software vulnerability detection apparatus may be disposed in the terminal device 110 to implement the corresponding module functions. For example, the terminal device 110 may extract attribute information of target dependence of the software to be detected, generate a unique dependence identifier of the software to be detected according to the attribute information of the target dependence, then obtain a vulnerability from the vulnerability library, generate a unique vulnerability identifier corresponding to the obtained vulnerability, and match the unique vulnerability identifier with the unique dependence identifier, so that candidate vulnerabilities are obtained according to the matching results of each stage. And then calculating the correlation degree of each candidate vulnerability and the software to be detected, determining a target vulnerability from the candidate vulnerabilities according to the correlation degree, and generating a vulnerability detection report of the software to be detected based on the target vulnerability.
In an exemplary embodiment, the software vulnerability detection method described above may be performed by the server 120. Accordingly, the software vulnerability detection apparatus may be disposed in the server 120 to implement the corresponding module functions. For example, the terminal device 110 may send the software to be detected to the server, the server 120 may extract attribute information of target dependence of the software to be detected, generate a unique dependence identifier of the software to be detected according to the attribute information of the target dependence, obtain a vulnerability from the vulnerability library, generate a unique vulnerability identifier corresponding to the obtained vulnerability, and match the unique vulnerability identifier with the unique dependence identifier, where each level of matching result obtains candidate vulnerabilities. And calculating the correlation degree of each candidate vulnerability and the software to be detected, determining a target vulnerability from the candidate vulnerabilities according to the correlation degree, generating a vulnerability detection report of the software to be detected based on the target vulnerability, and transmitting the generated vulnerability detection report of the software to be detected to the terminal equipment 110.
It should be understood that the number of terminal devices and servers in fig. 1 is merely illustrative. There may be any number of terminal devices and servers, as desired for implementation. For example, the server 120 may be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, or a cloud server that provides cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDNs, basic cloud computing services such as big data and artificial intelligence platforms, and the like.
However, it is easy to understand by those skilled in the art that the above application scenario is only for example, and the present exemplary embodiment is not limited thereto.
Fig. 2 is a flow chart illustrating a software vulnerability detection method according to an exemplary embodiment of the disclosure. Referring to fig. 2, the method includes:
step S210, extracting attribute information of target dependence of software to be detected, and generating a unique dependence identifier of the software to be detected according to the attribute information of the target dependence;
Step S220, matching the unique dependence identifiers of the software to be detected with the unique vulnerability identifiers in the vulnerability database, and determining candidate vulnerabilities according to the vulnerabilities indicated by the successfully matched unique vulnerability identifiers;
Step S230, determining a target vulnerability of the software to be detected from the candidate vulnerabilities according to the influence degree of the candidate vulnerabilities on the software to be detected, and generating a vulnerability detection report of the software to be detected based on the target vulnerability.
In the technical scheme provided by the embodiment shown in fig. 2, a candidate vulnerability is obtained by matching a unique identifier of a target dependence of software to be detected with a unique identifier of a vulnerability, so that a target vulnerability is obtained according to the correlation degree of the candidate vulnerability and the software to be detected, and a vulnerability detection report of the software to be detected is generated based on the target vulnerability. Compared with the related art, on one hand, the method and the device for detecting the vulnerability have the advantages that candidate vulnerabilities are determined through matching of the unique identifier of the target dependence and the unique identifier of the vulnerability, false alarm and missing report can be reduced, and accuracy of vulnerability detection is improved, and on the other hand, the method and the device for detecting the vulnerability can effectively screen the vulnerabilities in the vulnerability library, save time of manual intervention, and improve efficiency of software vulnerability detection and restoration through matching and correlation degrees.
Next, first, in step S210, attribute information of a target dependency of the software to be detected is extracted, and a specific embodiment of generating a unique dependency identifier of the software to be detected according to the attribute information of the target dependency is described in detail.
For example, dependencies of software include external components, libraries, or resources that are required by a software module or application during normal operation. These dependencies may be code libraries, frameworks, system services or external resources, etc., which together form the infrastructure of the software, ensuring proper functioning and functional implementation of the software.
In an example embodiment, the target dependency may include a dependency of actual use in the software to be detected. Based on this, by way of example, FIG. 3 shows a flow diagram of a method of determining target dependencies in an exemplary embodiment of the present disclosure. Referring to fig. 3, the method may include steps S310 to S320. Wherein:
in step S310, the dependencies indicated by the dependency reference information in the dependency file of the software to be detected and the code information of the software to be detected are matched.
In an exemplary embodiment, dependency reference information is used to indicate dependencies of references in the software to be detected. In other words, there is a dependency file in the package of the software to be detected, where the dependency file is specifically used to record relevant information of the dependency of the software to be detected, that is, the dependency file includes information of component names, versions, suppliers, etc. referred to by the software to be detected.
By way of example, FIG. 4 illustrates a flow diagram of a method of determining dependent files of software to be detected in an exemplary embodiment of the present disclosure. Referring to fig. 4, the method may include steps S410 to S430.
In step S410, a target programming language used by the software to be detected is determined.
For example, different software to be tested may be written in different programming languages, such as Python, C, c++, JAVA, etc.
In one exemplary embodiment, the different programming languages may be categorized by a programming language analyzer to obtain the target programming language used by the software to be tested. The programming language analyzer may categorize different types of programming languages according to their characteristics. Therefore, language features of the software to be detected can be extracted, and the language features of the software to be detected are input into a programming language analyzer to obtain a target programming language used by the software to be detected.
In another exemplary embodiment, the target programming language used by the software to be tested may also be manually validated.
In step S420, a target format of the dependent file corresponding to the target programming language is searched in the first mapping relation.
In one exemplary embodiment, the first mapping relationship is used to indicate a mapping relationship between different programming languages and their corresponding formats of dependent files.
For example, for each programming language, the dependent files in the software developed using the programming language may have a fixed file format, such as a fixed suffix format for each type of dependent file in the software that may be used to distinguish the dependent file from other function code files in the software. The mapping relation between different programming languages and the formats of the corresponding dependent files can be generated in advance, for example, the formats of the dependent files corresponding to the different programming languages can be recorded in the first mapping relation.
After the target programming language used by the software to be detected is determined, the format of the dependent file corresponding to the target programming language can be searched in the first mapping relation, so that the target format is obtained.
In step S430, a dependent file of the software to be detected is determined according to the file in the target format in the software to be detected.
As described above, the format of the dependent file in the software to be detected is different from the format of the software entity function code file of the software to be detected, so that the file with the target format can be searched in the file package of the software to be detected, thereby determining the dependent file of the software to be detected from the file package of the software to be detected.
Through the steps S410 to S430, unified processing can be performed on the software to be detected in different programming languages, so as to improve the universality of the software vulnerability detection method in the disclosure. Meanwhile, the dependent files of the software to be detected in different programming languages can be automatically determined, and the efficiency of software vulnerability detection is improved in an auxiliary mode.
In an exemplary embodiment, it is contemplated that some dependencies, although described in a dependency file, are not actually used, that is, there are dependencies that only reference but are not actually used, for example, some external libraries or modules are introduced in the software to be tested, but the functions that actually use these libraries or modules are not used in the code. Based on the above, the reference information in the dependence file of the software to be detected and the code information of the software to be detected can be matched, and the dependence really used in the software to be detected can be determined according to the matching result, so that the target dependence can be obtained.
For example, the content of the dependency corresponding to the dependency indicated by the reference information in the dependency file of the software to be detected and the related code of the software to be detected may be matched, for example, the function identifier of the key function in each dependency in the dependency file of the software to be detected and the code having the same function as the dependency in the software to be detected may be matched, so as to find whether the function identifier exists in the code of the software to be detected, if so, the matching is determined to be successful, otherwise, the matching is determined to be failed. If a certain dependency in the dependency file is a user identity verification module, the user identity verification module has a key function, the function name of the key function is A, whether the function with the name A exists in the identity verification code of the software to be detected can be searched, if so, the successful matching is determined, and if not, the matching is determined to be failed.
In step S320, a dependency of the matching success is determined as the target dependency.
For example, if it is matched in step S310, it is explained that the dependency indicated by the dependency reference information is indeed used in the software to be detected, so that the dependency can be determined as the target dependency. In this way, vulnerability detection can be performed on the software to be detected according to target dependence in subsequent steps.
Through the steps S310 to S320, the dependency of the real use of the software to be detected can be filtered from the dependency file, so that the software vulnerability detection is performed in the subsequent steps based on the dependency of the real use of the software to be detected, and the accuracy of the software vulnerability detection can be improved.
After obtaining the target dependency, a unique identification of the target from now on can be generated. For example, attribute information of the target dependency, such as information of an organization, vendor, product name, version number, etc. of the target dependency may be extracted.
In an exemplary embodiment, the unique identification of the target dependency may include a target dependency CPE (Common Platform Enumeration, universal platform enumeration). CPE is an open, standardized framework for describing and identifying configurations on software and hardware platforms. IT provides a structured way to uniquely identify IT assets, including operating systems, applications, databases and other software components, as well as the hardware they run. The purpose of the CPE is to provide a common language that allows consistent communication of information about IT assets between different organizations and tools, particularly in the security arts, for accurate description of vulnerabilities and configuration management related data.
For example, the dependent CPE of the software to be detected may be generated according to the extracted attribute information of the target dependency, such as information of an organization, a product name, a version number, etc. to which the target dependency belongs.
Next, a detailed description is given of the specific embodiment of "step S220, in which the dependency unique identifier of the software to be detected and the unique identifier of the vulnerability in the vulnerability library are matched, and the candidate vulnerability is determined according to the vulnerability indicated by the successfully matched unique identifier of the vulnerability".
For example, a vulnerability unique identifier corresponding to a vulnerability in the vulnerability database may be generated according to the vulnerability attribute information in the vulnerability database, where the vulnerability unique identifier may also include a vulnerability CPE.
For example, the dependent CPE of the software to be detected may be respectively matched with the vulnerability CPE corresponding to the vulnerability in the vulnerability library, and if the matching is successful, the vulnerability indicated by the vulnerability CPE is determined as a candidate vulnerability.
Next, a detailed description is given of the specific implementation manner of "step S230, in which the target vulnerability of the software to be detected is determined from the candidate vulnerabilities according to the influence degree of the candidate vulnerabilities on the software to be detected", and the vulnerability detection report of the software to be detected is generated based on the target vulnerability ".
In an exemplary embodiment, the determination mode of the influence degree of the candidate vulnerability on the software to be detected comprises the steps of inputting vulnerability information of the candidate vulnerability and software information of the software to be detected into a pre-trained machine learning model, obtaining the confidence degree of the candidate vulnerability according to output of the machine learning model, and determining the confidence degree as the influence degree of the candidate vulnerability on the software to be detected.
The vulnerability information of the candidate vulnerability may include vulnerability type, vulnerability influence range, vulnerability repair difficulty, vulnerability attack complexity, vulnerability authority requirement, and the like, and the software information of the software to be detected may include information of software functions of the software to be detected, and the like.
The method for determining the pre-trained machine learning model comprises the steps of obtaining training data and sample labels, wherein the training data comprise vulnerabilities and software, the sample labels comprise correlations between the vulnerabilities in the training data and the software, inputting the training data into an initial machine learning model to obtain a prediction result of the training data, obtaining training loss according to the prediction result of the training data and the difference degree of the sample labels, and carrying out iterative training on the initial machine learning model based on the training loss until preset conditions are met to obtain the pre-trained machine learning model.
For example, different vulnerabilities and software can be obtained, and the impact levels of the different vulnerabilities on the different software can be manually marked, so that training data and sample tags can be obtained. Then, extracting vulnerability information corresponding to the vulnerability in the training data and software information corresponding to the software in the training data, inputting the extracted vulnerability information and the software information into an initial machine learning model, predicting the influence level of the vulnerability in the training data on the software through the initial machine learning model to obtain a prediction result, comparing the prediction result with a sample label to obtain the difference degree between the prediction result and the sample label, determining the difference degree as training loss, and converging the initial machine learning model in the direction of continuously reducing the training loss in the iterative training process until the preset iteration times are reached or the training loss is smaller than a preset value, and ending training to obtain the pre-trained machine learning model.
In an exemplary embodiment, the machine learning module may include any machine learning model capable of performing prediction, such as a convolutional neural network model, a support vector machine model, and the exemplary embodiment is not limited in this regard.
For example, the software information of the software to be detected and the vulnerability information of each candidate vulnerability may be input into a pre-trained machine learning model, and the pre-trained machine learning model may output the influence probability of the candidate vulnerability to the software to be detected, where the influence probability may be used to measure the confidence level of the candidate vulnerability, so that the influence probability is used as the influence degree of the candidate vulnerability to the software to be detected.
In an exemplary embodiment, determining the target vulnerability of the software to be detected from the candidate vulnerabilities according to the influence degree of the candidate vulnerabilities on the software to be detected includes determining the candidate vulnerabilities with the influence degree greater than a preset value as the target vulnerability according to the influence degree of the candidate vulnerabilities on the software to be detected.
For example, a preset value may be set, and then candidate vulnerabilities with a correlation degree greater than the preset value are determined as target vulnerabilities. The preset value is used for selecting the loopholes with high correlation degree with the software to be detected from the candidate loopholes, so the preset value can be set to be larger, and the value range of the preset value can be larger than or equal to 0.6 and smaller than 1 because the influence degree is determined by probability and the probability value is 1 at the maximum. Specific values of the preset values can be set in a self-defined manner according to requirements, and the exemplary embodiment does not limit the characteristics.
In an exemplary embodiment, the generating the bug detection report of the software to be detected based on the target bug includes sorting the target bug according to a descending order of the influence degree, and generating the bug detection report of the software to be detected based on the sorting result.
For example, the target vulnerabilities can be ranked according to the order of the influence degree from high to low, and then the ranking result is written into the vulnerability detection report, so that the user can determine the importance degrees of different target vulnerabilities according to the ranking result in the vulnerability detection report, and repair and optimize the vulnerabilities according to different importance degrees.
Illustratively, FIG. 5 shows a flow diagram of another software vulnerability detection method in an exemplary embodiment of the present disclosure. Referring to fig. 5, the method may include steps S501 to S513. Wherein:
In step S501, obtaining software to be detected, in step S502, obtaining a programming language type used by the software to be detected through a programming language analyzer, in step S503, determining a dependent file from the software to be detected according to a dependent file format corresponding to the programming language type, in step S504, determining whether the dependence in the dependent file is actually used, if not, turning to step S505, otherwise turning to step S506, in step S505, ignoring and not processing, in step S506, extracting a dependent attribute to generate a dependent unique identifier, in step S507, extracting a vulnerability attribute in a vulnerability database to generate a vulnerability unique identifier, in step S508, comparing the dependent unique identifier with the vulnerability unique identifier to generate a first data set, in step S509, scoring each unique identifier in the first data set by using a machine learning model, in step S510, judging whether the confidence score is larger than a set threshold, if not, turning to step S511, otherwise turning to step S512, in step S511, ignoring, in step S511, not processing, and in step S513, recording the second data set, and processing, and obtaining a second data set.
For example, different programming languages may be classified according to a programming language analyzer, thereby obtaining the type of programming language used by the software to be detected. The programming language analyzer can also be a pre-trained programming language classifier obtained by training any machine learning model. And then, according to a first mapping relation stored in advance, finding a dependent file format corresponding to the type of the programming language used by the software to be detected, and obtaining a target file format. And searching the file in the target file format in the software package of the software to be detected, thereby obtaining the dependent file of the software to be detected. Typically, the dependency file contains information such as the name, version, vendor, etc. of the component referenced by the software. The dependency file segmenter may then be used to filter out dependencies that are actually used in the software to be detected, ignoring dependencies that are only referenced but not used. And extracting the filtered key information of the dependency, namely the dependency attribute information, such as the information of the organization, manufacturer, product name, version number and the like to which the dependency belongs. Based on the filtered dependent attribute information, generating dependent CPE of the software to be detected, acquiring the loophole from the loophole database, and generating the loophole CPE, wherein the loophole CPE contains relevant information of the loophole, such as the affiliated organization/manufacturer, the product name, the version number and the like of the loophole.
And comparing the dependent CPE of the software to be detected with the vulnerability CPE, and adding the vulnerability into the first data set when the dependent attribute and the vulnerability attribute have a matching relationship, namely, the first data set contains the potential vulnerability of the software to be detected. Each vulnerability CPE in the first data set is then assigned a confidence score via the machine learning model, which score is used to estimate how likely it is that the vulnerability is to be relevant to the item of software to be detected. If the confidence score of a vulnerability CPE is high, it means that the vulnerability will affect the item of the software to be detected, and more attention needs to be paid to the vulnerability, and if the confidence score is low, it means that the relationship between the vulnerability and the item of the software to be detected is not great, or the actual influence will not be caused to the software to be detected. Based on this, vulnerability CPE with a confidence score exceeding a certain threshold may be selected from the first data set according to the confidence score, and a second data set may be generated, where the second data set includes vulnerabilities that are most likely to affect the software to be detected, i.e. the target vulnerabilities described above.
And forming a vulnerability report according to the confidence score from high to low by vulnerability information in the second data set, and repairing and optimizing the vulnerability according to the importance degree by a user through the report.
The present disclosure can classify dependencies in dependency files of software in different programming languages according to a programming language analyzer and a dependency file analyzer, filter and ignore dependencies that are only referenced but not actually used, and analyze only dependencies that are actually used. Different programming languages can be processed, the method has strong universality, and the dependence analysis can be focused more on the dependence analysis of actual use through the dependence filtering, so that the vulnerability detection efficiency is improved. And secondly, based on the extracted dependency attribute and the vulnerability attribute, false alarm and missing report can be reduced by matching the dependency CPE and the vulnerability CPE, and the accuracy of vulnerability detection is improved. Meanwhile, the loopholes are scored automatically through the machine learning model, so that unnecessary inspection is reduced based on accurate dependency analysis and loophole scoring, and consumption of computing resources and human resources is reduced. In addition, through confidence score and threshold setting, a quantifiable risk management tool is provided for the software, and a user can perform vulnerability detection management on the software or a software item through customization.
In other words, the method can deeply understand the software dependency relationship, accurately identify the potential security hole and provide timely feedback. Not only is static code analysis handled, but also a dynamically changing runtime environment is accommodated. The method has high accuracy and high efficiency, can adapt to a fast-paced software development period, and reduces the dependence of software detection loopholes on manual intervention.
Furthermore, it should be noted that the above-described figures are merely illustrative of the processes involved in the method according to the exemplary embodiment of the present invention, and are not intended to be limiting. It will be readily appreciated that the processes shown in the above figures do not indicate or limit the temporal order of these processes. In addition, it is also readily understood that these processes may be performed synchronously or asynchronously, for example, among a plurality of modules.
Further, the exemplary embodiment of the disclosure also provides a software vulnerability detection device. Referring to fig. 6, the software bug detection device 600 includes a dependency extraction module 610 configured to extract attribute information of a target dependency file of software to be detected, generate a dependency unique identifier of the software to be detected according to the attribute information of the target dependency file, a matching module 620 configured to match the dependency unique identifier of the software to be detected with a bug unique identifier in a bug library, determine a candidate bug according to a bug indicated by the matched bug unique identifier, and a bug detection report generation module 630 configured to determine a target bug of the software to be detected from the candidate bugs according to an influence degree of the candidate bugs on the software to be detected, and generate a bug detection report of the software to be detected based on the target bug.
In an exemplary embodiment, the determining mode of the target dependence comprises the steps of matching the dependence indicated by the dependence reference information in the dependence file of the software to be detected with the code information of the software to be detected, wherein the dependence reference information is used for indicating the dependence referred to in the software to be detected, and determining the successfully matched dependence as the target dependence.
In an exemplary embodiment, the method for determining the dependent file of the software to be detected includes determining a target programming language used by the software to be detected, searching a first mapping relation for a target format of the dependent file corresponding to the target programming language, wherein the first mapping relation is used for indicating mapping relations between different programming languages and formats of the dependent file corresponding to the different programming languages, and determining the dependent file of the software to be detected according to the file of the target format in the software to be detected.
In an exemplary embodiment, the determination mode of the influence degree of the candidate vulnerability on the software to be detected comprises the steps of inputting vulnerability information of the candidate vulnerability and software information of the software to be detected into a pre-trained machine learning model, obtaining the confidence degree of the candidate vulnerability according to output of the machine learning model, and determining the confidence degree as the influence degree of the candidate vulnerability on the software to be detected.
In an exemplary embodiment, the method for determining the pre-trained machine learning model includes the steps of obtaining training data and a sample label, wherein the training data comprises holes and software, the sample label comprises the influence level of the holes in the training data on the software, inputting the training data into an initial machine learning model to obtain a prediction result of the training data, obtaining training loss according to the prediction result of the training data and the difference degree of the sample label, and carrying out iterative training on the initial machine learning model based on the training loss until preset conditions are met to obtain the pre-trained machine learning model.
In an exemplary embodiment, determining the target vulnerability of the software to be detected from the candidate vulnerabilities according to the influence degree of the candidate vulnerabilities on the software to be detected includes determining the candidate vulnerabilities with the influence degree greater than a preset value as the target vulnerability according to the influence degree of the candidate vulnerabilities on the software to be detected.
In an exemplary embodiment, the generating the vulnerability detection report of the software to be detected based on the target vulnerabilities includes sorting the target vulnerabilities according to a descending order of the influence degree, and generating the vulnerability detection report of the software to be detected based on the sorting result.
The specific details of each part in the above apparatus are already described in the method part embodiments, and the details not disclosed can refer to the embodiment content of the method part, so that the details are not repeated.
It should be noted that although in the above detailed description several modules or units of a device for action execution are mentioned, such a division is not mandatory. Indeed, the features and functionality of two or more modules or units described above may be embodied in one module or unit in accordance with exemplary embodiments of the present disclosure. Conversely, the features and functions of one module or unit described above may be further divided into a plurality of modules or units to be embodied.
Furthermore, although the steps of the methods in the present disclosure are depicted in a particular order in the drawings, this does not require or imply that the steps must be performed in that particular order, or that all illustrated steps be performed, to achieve desirable results. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step to perform, and/or one step decomposed into multiple steps to perform, etc.
Exemplary embodiments of the present disclosure also provide a computer program product. The computer program product comprises a computer program which, when executed by a processor, implements the software vulnerability detection method described above.
In one embodiment, the computer program product may be a tangible product comprising a computer program, such as a computer readable storage medium having the computer program stored thereon. The readable storage medium may be a storage medium based on signals of electric, magnetic, optical, electromagnetic, infrared, etc., including, but not limited to, random Access Memory (RAM), read Only Memory (ROM), magnetic tape, floppy disk, flash memory (Flash), mechanical hard disk (HDD), solid State Disk (SSD), etc. By way of example, the computer program product may be embodied as a non-volatile storage medium, such as read-only memory, nand flash memory (NAND FLASH), or the like, in which the computer program is stored.
In one embodiment, the computer program product may be an intangible product containing a computer program. By way of example, the computer program product may be embodied as a virtual digital product, such as a digital file, an executable file storing a computer program, an installation package, or the like.
The code of the computer program may be written in one or more programming languages. Programming languages such as C language, java, c++, python, etc. The program code may execute entirely on the user's computing device, or partly on the user's computing device, or as a stand-alone software package, or partly on the user's computing device, partly on a remote computing device, or entirely on the remote computing device or server. In the case of remote computing devices, the remote computing device may be connected to the user computing device through any kind of network, such as a Local Area Network (LAN), wide Area Network (WAN), etc., or may be connected to an external computing device (e.g., an Internet connection provided by an operator).
The computer program may be carried or transmitted by signals of electronic, magnetic, optical, electromagnetic, infrared, etc. The electronic device may convert a signal carrying the computer program into a digital signal, thereby running the computer program. When the computer program runs on the electronic device, the code is used for enabling the electronic device to execute (more specifically, enabling a processor of the electronic device to execute) the method steps of various exemplary embodiments of the present disclosure, for example, the software bug detection method can be executed, and the method comprises the steps of extracting attribute information of target dependence of software to be detected, generating a dependence unique identification of the software to be detected according to the attribute information of the target dependence, matching the dependence unique identification of the software to be detected with a bug unique identification in a bug library, determining candidate bugs according to bugs indicated by the matched bug unique identification, determining a target of the software to be detected from the candidate bugs according to influence degree of the candidate bugs on the software to be detected, and generating a bug detection report of the software to be detected based on the target bugs.
The method comprises the steps of executing the method through a computer program, on one hand, determining candidate loopholes based on matching of the unique identification of the target dependence and the unique identification of the loopholes, so that false alarm and missing alarm can be reduced, accuracy of loophole detection is improved, and on the other hand, the loopholes in a loophole library can be effectively screened through influence degree, time of manual intervention is saved, and efficiency of software loophole detection and repair is improved.
The exemplary embodiments of the present disclosure also provide an electronic device, such as may be the terminal device 110 or the server 120 described above. The electronic device may include a processor and a memory. The memory stores executable instructions of the processor, such as may be a computer program. The processor performs the method steps of the various exemplary embodiments of the present disclosure by executing the executable instructions. The electronic device may further comprise a display for displaying the graphical user interface.
An electronic device is illustrated in the form of a general purpose computing device with reference to fig. 7. It should be understood that the electronic device 700 illustrated in fig. 7 is merely an example and should not be taken as limiting the functionality and scope of use of the disclosed embodiments.
As shown in FIG. 7, electronic device 700 may include a processor 710, memory 720, bus 730, I/O (input/output) interface 740, network adapter 750, and display 760.
The memory 720 may include volatile memory such as RAM 721, cache unit 722, and nonvolatile memory such as ROM 723. Memory 720 may also include one or more program modules 724, such program modules 724 including, but not limited to, an operating system, one or more application programs, other program modules, and program data, each or some combination of which may include an implementation of a network environment. For example, program modules 724 may include modules in the apparatus described above.
Processor 710 may include one or more processing units, for example, processor 710 may include an AP (Application Processor ), a modem Processor, a GPU (Graphics Processing Unit, graphics Processor), an ISP (IMAGE SIGNAL Processor ), a controller, an encoder, a decoder, a DSP (DIGITAL SIGNAL Processor ), a baseband Processor, and/or an NPU (Neural-Network Processing Unit, neural network Processor), and the like.
The processor 710 may be configured to execute executable instructions stored in the memory 720, for example, may execute the above-mentioned software bug detection method, and includes the steps of extracting attribute information of target dependence of software to be detected, generating a unique dependence identifier of the software to be detected according to the attribute information of the target dependence, matching the unique dependence identifier of the software to be detected with a unique bug identifier in a bug library, determining a candidate bug according to a bug indicated by the unique matching identifier, determining a target bug of the software to be detected from the candidate bugs according to an influence degree of the candidate bug on the software to be detected, and generating a bug detection report of the software to be detected based on the target bug.
The method is realized through the computer program, on one hand, candidate loopholes are determined based on matching of the unique identification of the target dependence and the unique identification of the loopholes, false alarm and missing alarm can be reduced, accuracy of loophole detection is improved, on the other hand, loopholes in a loophole library can be effectively screened through influence degree, time of manual intervention is saved, and efficiency of software loophole detection and repair is improved.
Bus 730 is used to enable connections between the different components of electronic device 700 and may include a data bus, an address bus, and a control bus.
The electronic device 700 may communicate with one or more external devices 800 (e.g., keyboard, mouse, external controller, etc.) through the I/O interface 740.
The electronic device 700 may communicate with one or more networks through the network adapter 750, e.g., the network adapter 750 may provide a mobile communication solution such as 3G/4G/5G, or a wireless communication solution such as wireless local area network, bluetooth, near field communication, etc. The network adapter 750 may communicate with other modules of the electronic device 700 over the bus 730.
The electronic device 700 may display a graphical user interface, such as an interface displaying the generated vulnerability detection report, etc., via the display 760.
Although not shown in FIG. 7, other hardware and/or software modules may also be provided in electronic device 700, including, but not limited to, microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems, among others.
Furthermore, the above-described figures are only schematic illustrations of processes included in the method according to the exemplary embodiments of the present disclosure, and are not intended to be limiting. It will be readily appreciated that the processes shown in the above figures do not indicate or limit the temporal order of these processes. In addition, it is also readily understood that these processes may be performed synchronously or asynchronously, for example, among a plurality of modules.
From the foregoing, it will be appreciated that the techniques of this disclosure may be implemented as a method, apparatus, system, computer program product, storage medium, electronic device, or the like. Those skilled in the art will appreciate that the various aspects of the disclosure may be embodied in the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, microcode, etc.), or an embodiment combining hardware and software aspects that may be referred to as a "circuit," "module" or "system," respectively.
It is to be understood that the disclosure is not limited to the particular process steps or structures described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. Other embodiments will readily occur to those skilled in the art based on the specific embodiments provided by this disclosure. Accordingly, the detailed description provided herein is exemplary only, and the scope and spirit of the present disclosure is indicated by the appended claims, to encompass any modifications, uses, or adaptations of the disclosure following the general principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains.