Vulnerability risk prediction method and device, equipment and medium

Abstract

The embodiment of the invention provides a vulnerability risk prediction method and device, equipment and a medium, and is used for solving the problems that in the prior art, vulnerability prediction efficiency is low, and the risk level of vulnerabilities cannot be accurately determined. In the method, a to-be-detected SBOM is matched with a vulnerability database, and a target vulnerability existing in the to-be-detected SBOM and a target component associated with the target vulnerability are determined; determining a first score corresponding to the severity of the target vulnerability; determining a second score corresponding to a target dependency relationship between the item and the target component; determining a third score corresponding to the target quotation frequency of the item quoting the target component; determining a risk score of the target vulnerability according to the first score, the second score and the third score; based on the risk score of the target vulnerability, whether the target vulnerability is processed preferentially is determined, the vulnerability risk prediction efficiency is improved, and the vulnerability risk level can be determined more accurately by performing multi-dimensional assessment on the vulnerability risk.

Description

Technical Field

[0001] The present invention relates to the field of network security technology, and in particular to a vulnerability risk prediction method, device, equipment and medium. Background Art

[0002] In today's complex software development environment, software supply chain security has become a critical issue. With the popularity of open source software and the increase in software component reuse, software projects often rely on hundreds or thousands of third-party libraries and frameworks. Although this high degree of dependence accelerates the development process, it also introduces unprecedented security challenges. Once a component in the supply chain is exposed to a security vulnerability, it may quickly spread to a large number of applications that rely on it, triggering a chain reaction and causing serious security incidents.

[0003] Currently, Software Composition Analysis (SCA) is a technology that identifies and tracks all open source and third-party components used in software development, and is used to detect whether there are known security vulnerabilities, license violations, and other issues in the components. The Software Bill of Materials (SBOM) lists all components that make up a software product or application, including directly used libraries and frameworks, as well as the dependencies of these components. The SBOM usually contains metadata such as the name and version number of each component, license information obtained through SCA analysis, and source.

[0004] Vulnerability prediction usually relies on manually monitoring the vulnerability information and component information recorded in security bulletins or the Common Vulnerabilities and Exposures (CVE) database, and manually checking whether software dependencies are affected. This method is not only time-consuming and inefficient, but also can only determine the risk of each vulnerability based on the risk level recorded in the manually monitored security bulletins or CVE database. In other words, when determining the risk level of a vulnerability, it is only judged by experience, resulting in the inability to accurately determine the risk level of the vulnerability, and there is no way to provide accurate protection for the vulnerability.

[0005] In summary, the current traditional vulnerability prediction methods have problems such as low efficiency and inability to accurately determine the risk level of the vulnerability. Summary of the invention

[0006] The embodiments of the present application provide a vulnerability risk prediction method, device, equipment and medium to solve the problems in the prior art of low vulnerability prediction efficiency and inability to accurately determine the risk level of the vulnerability.

[0007] In a first aspect, an embodiment of the present application provides a vulnerability risk prediction method, the method comprising:

[0008] Matching the software bill of materials (SBOM) to be tested with the stored vulnerability database to determine the target vulnerability existing in the SBOM to be tested and the target component associated with the target vulnerability;

[0009] Determine a first score corresponding to the severity of the target vulnerability according to the severity of the target vulnerability recorded in the description information of the target vulnerability and the correspondence between the saved severity and the severity score; determine a target dependency between the project and the target component according to the dependency between the project and each component recorded in the SBOM to be detected, and determine a second score corresponding to the target dependency between the project and the target component according to the target dependency and the correspondence between the saved dependency and the dependency score; obtain the target reference count of the target component referenced by the project, and determine a third score corresponding to the target reference count; determine a risk score of the target vulnerability according to the first score, the second score, and the third score;

[0010] Based on the risk score of the target vulnerability, determine whether to prioritize the target vulnerability.

[0011] In a second aspect, an embodiment of the present application provides a vulnerability risk prediction device, the device comprising:

[0012] A matching module is used to match the software bill of materials SBOM to be detected with the stored vulnerability database to determine the target vulnerability existing in the SBOM to be detected and the target component associated with the target vulnerability;

[0013] An evaluation module is used to determine a first score corresponding to the severity of the target vulnerability according to the severity of the target vulnerability recorded in the description information of the target vulnerability and the correspondence between the saved severity and the severity score; determine a target dependency between the project and the target component according to the dependency between the project and each component recorded in the SBOM to be detected, and determine a second score corresponding to the target dependency between the project and the target component according to the target dependency and the correspondence between the saved dependency and the dependency score; obtain the number of target references of the project to the target component, and determine a third score corresponding to the number of target references; determine a risk score of the target vulnerability according to the first score, the second score, and the third score;

[0014] The determination module is used to determine whether to prioritize the target vulnerability based on the risk score of the target vulnerability.

[0015] In a third aspect, an embodiment of the present application further provides an electronic device, which includes at least a processor and a memory, and the processor is used to implement the steps of any of the above-mentioned vulnerability risk prediction methods when executing a computer program stored in the memory.

[0016] In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium storing a computer program, which implements the steps of any of the above-mentioned vulnerability risk prediction methods when the computer program is executed by a processor.

[0017] In a fifth aspect, an embodiment of the present application provides a computer program product, which includes: a computer program code, which, when executed on a computer, enables the computer to execute the steps of the vulnerability risk prediction method as described in any one of the first aspects.

[0018] In the embodiment of the present application, the software bill of materials SBOM to be detected is matched with the stored vulnerability database to determine the target vulnerability existing in the SBOM to be detected and the target component associated with the target vulnerability; according to the severity of the target vulnerability recorded in the description information of the target vulnerability and the correspondence between the stored severity and the severity score, the first score corresponding to the severity of the target vulnerability is determined; according to the dependency relationship between the project and each component recorded in the SBOM to be detected, the target dependency relationship between the project and the target component is determined, and according to the correspondence between the target dependency relationship and the stored dependency relationship and the dependency score, the second score corresponding to the target dependency relationship between the project and the target component is determined; the number of target references of the target component referenced by the project is obtained, and the third score corresponding to the number of target references is determined; according to the first score, the second score, and the third score, the risk score of the target vulnerability is determined; based on the risk score of the target vulnerability, it is determined whether to give priority to the target vulnerability. In the embodiment of the present application, there is no need to manually predict the vulnerability risk, which improves the efficiency of vulnerability risk prediction, and the vulnerability risk is evaluated in multiple dimensions, which integrates the severity of the vulnerability itself, the role of the target component associated with the target vulnerability in the project, and other factors, and can more accurately determine the risk level of the vulnerability, thereby making the risk warning more accurate. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0020] Figure 1 A schematic diagram of a vulnerability risk prediction process provided in an embodiment of the present application;

[0021] Figure 2 A schematic diagram of a vulnerability risk prediction process provided in an embodiment of the present application;

[0022] Figure 3A schematic diagram of another vulnerability risk prediction process provided in an embodiment of the present application;

[0023] Figure 4 A schematic diagram of the structure of a vulnerability risk prediction device provided in an embodiment of the present application;

[0024] Figure 5 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0025] In order to make the purpose and implementation method of the present application clearer, the exemplary implementation method of the present application will be clearly and completely described below in conjunction with the drawings in the exemplary embodiments of the present application. Obviously, the described exemplary embodiments are only part of the embodiments of the present application, rather than all the embodiments.

[0026] It should be noted that the brief description of terms in this application is only for the convenience of understanding the embodiments described below, and is not intended to limit the embodiments of this application. Unless otherwise specified, these terms should be understood according to their common and usual meanings.

[0027] The terms "first", "second", "third", etc. in the specification and claims of this application and the above drawings are used to distinguish similar or similar objects or entities, and do not necessarily mean to limit a specific order or sequence, unless otherwise noted. It should be understood that the terms used in this way can be interchangeable under appropriate circumstances.

[0028] The terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover but not exclude inclusion, for example, a product or device comprising a list of components is not necessarily limited to all the components expressly listed but may include other components not expressly listed or inherent to such product or device.

[0029] The term "module" refers to any known or later developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware and / or software code that is capable of performing the functions associated with that element.

[0030] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

[0031] For the convenience of explanation, the above description has been made in conjunction with specific embodiments. However, the above exemplary discussion is not intended to be exhaustive or limit the embodiments to the specific forms disclosed above. Based on the above teachings, various modifications and variations can be obtained. The selection and description of the above embodiments are to better explain the principles and practical applications, so that those skilled in the art can better use the embodiments and various different variations of the embodiments suitable for specific use considerations.

[0032] The embodiment of the present application provides a vulnerability risk prediction method, apparatus, device and medium, the method comprising: matching a software bill of materials (SBOM) to be detected with a stored vulnerability database to determine a target vulnerability existing in the SBOM to be detected and a target component associated with the target vulnerability; determining a first score corresponding to the severity of the target vulnerability according to the severity of the target vulnerability recorded in the description information of the target vulnerability and the correspondence between the stored severity and the severity score; determining a target dependency between the project and the target component according to the dependency between the project and each component recorded in the SBOM to be detected, and determining a second score corresponding to the target dependency between the project and the target component according to the target dependency and the correspondence between the stored dependency and the dependency score; obtaining a target reference count of the target component referenced by the project to determine a third score corresponding to the target reference count; determining a risk score of the target vulnerability according to the first score, the second score and the third score; and determining whether to give priority to the target vulnerability based on the risk score of the target vulnerability. In the embodiments of the present application, there is no need for manual prediction of vulnerability risks, which improves the efficiency of vulnerability risk prediction, and conducts a multi-dimensional assessment of vulnerability risks, taking into account factors such as the severity of the vulnerability itself and the role of the target component associated with the target vulnerability in the project, so as to more accurately determine the risk level of the vulnerability, thereby making risk warnings more precise.

[0033] Embodiment 1:

[0034] Figure 1 A schematic diagram of a vulnerability risk prediction process provided in an embodiment of the present application, the process includes:

[0035] S101: Match the SBOM to be detected with the stored vulnerability database to determine the target vulnerability existing in the SBOM to be detected and the target component associated with the target vulnerability.

[0036] The vulnerability risk prediction method provided in the embodiment of the present application is applied to an electronic device, which may be a computer (Personal Computer, PC), a server, etc.

[0037] The electronic device obtains the SBOM to be tested of the software corresponding to the project, in which the SBOM to be tested records information such as the component name, component version number, dependency relationship with the project, and supplier name of each component.

[0038] The electronic device stores a vulnerability database, which records vulnerability information of various vulnerabilities, wherein the vulnerability information of each vulnerability at least includes description information of the vulnerability, the name of the component in which the vulnerability exists, and the version number of the component.

[0039] Furthermore, since the naming method of the component names and component version numbers stored in the SBOM to be detected may be the same as the naming method of the component names and component version numbers contained in the vulnerability database, in order to determine the vulnerability status of each component in the software of the current project, in an embodiment of the present application, the SBOM to be detected is matched with the vulnerability database according to the component name and component version number, and the vulnerability corresponding to the successfully matched target component name and target component version number in the vulnerability database is determined as the target vulnerability, and the component corresponding to the target component name and target component version number of the target vulnerability in the SBOM to be detected is determined as the target component associated with the target vulnerability.

[0040] S102: Determine a first score corresponding to the severity of the target vulnerability according to the severity of the target vulnerability recorded in the description information of the target vulnerability and the correspondence between the saved severity and the severity score; determine a target dependency between the project and the target component according to the dependency between the project and each component recorded in the SBOM to be detected, and determine a second score corresponding to the target dependency between the project and the target component according to the target dependency and the correspondence between the saved dependency and the dependency score; obtain the target reference count of the target component referenced by the project, and determine a third score corresponding to the target reference count; determine a risk score of the target vulnerability according to the first score, the second score, and the third score.

[0041] In order to more accurately determine the risk level of the vulnerabilities in the project software, the embodiment of the present application evaluates the risk score of the target vulnerability by combining multiple factors such as the severity of the vulnerability itself and the role of the target component associated with the target vulnerability in the project. The process of multi-dimensionally evaluating the risk level of the target vulnerability is described below:

[0042] Specifically, for each target vulnerability, since the vulnerability information of the target vulnerability includes the description information of the target vulnerability, the severity of the target vulnerability is recorded in the description information, and the electronic device stores the corresponding relationship between the severity and the severity score, in the embodiment of the present application, the electronic device determines the first score corresponding to the severity of the target vulnerability according to the severity of the target vulnerability and the corresponding relationship between the severity and the severity score stored by itself. It can be understood that the higher the severity of the target vulnerability, the higher the corresponding severity score.

[0043] In addition, the electronic device also stores the correspondence between dependencies and dependency scores. Therefore, in an embodiment of the present application, the target dependency between the project and the target component is determined based on the target component associated with the target vulnerability and the dependency between the project and each component recorded in the SBOM to be detected; the second score corresponding to the target dependency is determined based on the target dependency and the correspondence between the dependency and the dependency score stored by itself.

[0044] Among them, the dependency relationship may include direct dependency or indirect dependency. If it is determined that the target component is a component in the project, then the dependency relationship between the project and the target component is determined to be a direct dependency; if it is determined that the target component is not a component in the project, and the target component is a component that the project directly depends on, then the dependency relationship between the project and the target component is determined to be a direct dependency; if it is determined that the target component is not a component in the project, and the target component is a component that the project indirectly depends on, then the dependency relationship between the project and the target component is determined to be an indirect dependency.

[0045] The correspondence between dependencies and dependency scores includes direct dependency corresponding score m and indirect dependency corresponding score n, where score m is usually greater than score n. That is to say, if a vulnerability exists in the target component that the project directly depends on, it will have a greater impact on the project than if a vulnerability exists in the target component that the project indirectly depends on.

[0046] For example, if component A is a component in the project, the target dependency relationship between the project and component A is a direct dependency, and the second score corresponding to the target dependency relationship is determined to be score m; if component B is not a component in the project, but the project depends on component B, then the target dependency relationship between the project and component B is a direct dependency, and the second score corresponding to the target dependency relationship is determined to be score m; if component B and component C are not components in the project, and the project depends on component B and component B depends on component C, then the target dependency relationship between the project and component C is an indirect dependency, and the second score corresponding to the target dependency relationship is determined to be score n.

[0047] In an embodiment of the present application, the electronic device records the number of times the project cites each component, as well as the correspondence between the number of citations and the number of citation scores. Therefore, the electronic device obtains the target number of citations of the target component by the project stored in itself based on the identification information of the target component associated with the target vulnerability, and determines the third score corresponding to the target number of citations based on the correspondence between the number of citations and the number of citation scores stored in itself.

[0048] Among them, it can be understood that the more times the project cites a component, the higher the corresponding citation score. That is to say, the more times the project cites a component, the greater the impact of the component on the project. Therefore, if there is a vulnerability in the component, the impact of the vulnerability on the project will also be greater.

[0049] After obtaining the above-mentioned first score, second score and third score, since the electronic device stores the preset weight corresponding to the dimensional data for each dimensional data, that is, the electronic device stores the first weight corresponding to the severity of the vulnerability, the second weight corresponding to the dependency relationship between the project and the component, and the third weight corresponding to the number of times the project references the component, the electronic device performs weighted summation of the first score, the second score and the third score according to the first score and the corresponding first weight, the second score and the corresponding second weight, and the third score and the corresponding third weight to obtain the corresponding sum, and determines the sum as the risk score of the target vulnerability.

[0050] S103: Determine whether to prioritize the target vulnerability based on the risk score of the target vulnerability.

[0051] After determining the risk score of each target vulnerability, the priority of each target vulnerability is determined according to the risk score of each target vulnerability. Among them, if the risk score of the target vulnerability is higher, it means that the risk of the target vulnerability is higher, so the target vulnerability needs to be dealt with first, that is, the priority of the target vulnerability is determined to be higher.

[0052] For each target vulnerability, if the priority of the target vulnerability is higher, it is determined that the target vulnerability needs to be handled first; if the priority of the target vulnerability is lower, it is determined that the target vulnerability does not need to be handled first, thereby ensuring that key risks are handled first.

[0053] In a possible implementation, after obtaining the risk score of each target vulnerability, the electronic device can also determine the target risk level of each target vulnerability according to the correspondence between the saved risk score and the risk level, and determine the priority of each target vulnerability according to the correspondence between the saved risk level and the priority. The risk levels include high risk, medium risk, low risk, etc. from high to low, and the higher the risk level of the vulnerability, the higher the corresponding priority, that is, the higher the priority of the vulnerability should be handled.

[0054] For example, if it is determined that there is a target vulnerability with a target risk level of high risk, the target vulnerability is determined to be handled with priority and an early warning is automatically triggered. Since the electronic device stores the relevant person in charge of the project, and the SBOM to be detected records the SBOM author information, and the electronic device has built a closed-loop management system for detection, response, early warning and repair suggestions, the electronic device can send the target vulnerability details, impact analysis and preliminary repair suggestions to the relevant person in charge and the development team (i.e., SBOM author) in the closed-loop management system through email or other instant messaging tools.

[0055] The impact analysis includes the component name and component version number affected by the target vulnerability. For example, the target vulnerability affects version 2.15.0 of the apache log4j component.

[0056] Initial repair suggestions may usually include: upgrading the target components associated with the target vulnerability and avoiding the version affected by the target vulnerability (i.e., the version in which the target vulnerability exists); abandoning a certain interface; modifying a certain configuration; referring to a certain Git commit information for repair, etc.

[0057] At the same time, if it is determined that there is a target vulnerability with a high risk level, the electronic device can also automatically generate an emergency response guide for the target vulnerability based on the vulnerability characteristics of the target vulnerability. The emergency response guide includes but is not limited to version upgrades, patch applications, configuration modifications, temporary mitigation measures, etc., and is not specifically limited here.

[0058] Among them, the vulnerability characteristics of the target vulnerability are detailed information of the target vulnerability, such as the affected component version, which function triggers the vulnerability in the component, how it can be triggered, related reference links, etc., so that the target emergency response guide to be adopted can be determined based on the vulnerability characteristics.

[0059] In addition, in a possible implementation, the electronic device can display key information such as the overall security situation of the project, risk component rankings, vulnerability risk distribution, component reference distribution, etc. on the display page, supporting relevant persons in charge to conduct multi-dimensional screening and drill-down analysis. In addition, the electronic device can automatically generate weekly / monthly security reports, summarize vulnerability discovery and repair situations in the security reports, provide security improvement suggestions, and support exporting security reports to portable document formats (PDF) or spreadsheets (Excel) format files for team review or management review, thereby providing relevant personnel with convenient security support tools through an intuitive visual interface, enhancing the efficiency of collaboration and communication between teams.

[0060] In the embodiments of the present application, there is no need for manual prediction of vulnerability risks, which improves the efficiency of vulnerability risk prediction, and conducts a multi-dimensional assessment of vulnerability risks. Taking into account factors such as the severity of the vulnerability itself and the role of the target component associated with the target vulnerability in the project, the risk level of the vulnerability can be determined more accurately, thereby making risk warnings more precise. At the same time, through timely and accurate risk warnings and efficient vulnerability management, enterprises can respond to security incidents more quickly, reduce the risk of service interruptions or data leakage caused by vulnerability exploitation, and thus ensure business continuity.

[0061] Embodiment 2:

[0062] In order to further accurately determine the risk level of the vulnerability, based on the above embodiment, in the embodiment of the present application, according to the severity of the target vulnerability recorded in the description information of the target vulnerability and the correspondence between the saved severity and the severity score, the first score corresponding to the severity of the target vulnerability is determined, including:

[0063] Determine a first sub-score corresponding to the exploitability of the target vulnerability according to the exploitability information included in the severity of the target vulnerability and the stored correspondence between the exploitability and the exploitability score;

[0064] Determine a second sub-score corresponding to the impact scope of the target vulnerability according to the impact scope information of the target vulnerability on the project contained in the severity of the target vulnerability and the saved correspondence between the impact scope and the impact scope score;

[0065] Determine a third sub-score corresponding to the consequence severity of the target vulnerability according to the consequence severity information included in the severity of the target vulnerability and the stored correspondence between the consequence severity and the consequence severity score;

[0066] A first score corresponding to the severity of the target vulnerability is determined according to the first sub-score, the second sub-score, and the third sub-score.

[0067] In the embodiment of the present application, the severity of the target vulnerability is recorded in the description information of the target vulnerability. Specifically, the severity of the target vulnerability includes but is not limited to the exploitability information of the target vulnerability, the scope of affected components, the severity of consequences, etc. Therefore, in order to more accurately determine the first score corresponding to the severity of the target vulnerability, in the embodiment of the present application, the first score corresponding to the severity of the target vulnerability can be determined in combination with the exploitability information, the scope of impact information, the severity of consequences, etc. of the target vulnerability. The following is an explanation of the process of determining the first score corresponding to the severity of the target vulnerability:

[0068] The electronic device stores a correspondence between exploitability and exploitability score. The electronic device obtains the exploitability information included in the severity in the description information of the target vulnerability, and determines a first sub-score corresponding to the exploitability of the target vulnerability based on the exploitability information of the target vulnerability and the correspondence between exploitability and exploitability score stored in the electronic device.

[0069] Among them, exploitability includes the complexity of the user's operation on the vulnerability, such as whether it can be operated by authorized users or by all users.

[0070] It can be understood that if the complexity of operating the target vulnerability is higher, that is, the higher the authority, the lower the exploitability is, and the smaller the impact on the project is, the lower the score corresponding to the exploitability is. In other words, in the embodiment of the present application, the corresponding relationship between the exploitability and the exploitability score is that the lower the exploitability is, the lower the corresponding exploitability score is.

[0071] In addition, the electronic device also stores a correspondence between the impact scope and the impact scope score. The electronic device then obtains the impact component scope included in the severity in the description information of the target vulnerability, matches the component name and component version number recorded in the impact component scope with the SBOM to be detected corresponding to the project, determines whether the SBOM to be detected includes components in the impact component scope, and if so, determines the number of components in the impact component scope included in the SBOM to be detected; determines the number of components in the impact component scope included in the SBOM to be detected as the impact scope information of the target vulnerability on the project, and determines the second sub-score corresponding to the impact scope of the target vulnerability based on the impact scope information and the correspondence between the impact scope and the impact scope score stored in itself.

[0072] The scope of impact includes whether the component with the vulnerability can be used to affect other components that the project depends on, and if so, the number of other components that the project depends on that are affected by the component with the vulnerability.

[0073] It can be understood that if the component determined to have the target vulnerability (i.e., the above-mentioned target component) affects more other components that the project depends on, the impact range of the target vulnerability will be larger, and the greater the impact on the project, the higher the score corresponding to the impact range will be. In other words, in the embodiment of the present application, the corresponding relationship between the impact range and the impact range score is that the larger the impact range, the higher the corresponding impact range score.

[0074] In addition, the electronic device also stores the correspondence between the severity of consequences and the severity of consequences score. The electronic device then obtains the severity of consequences of the target vulnerability contained in the severity of the target vulnerability, and determines the third sub-score corresponding to the severity of consequences of the target vulnerability based on the severity of consequences and the correspondence between the severity of consequences and the severity of consequences score stored in the electronic device.

[0075] The severity of the consequences includes the severity of the operations that the vulnerability can achieve, such as whether the vulnerability can modify file contents or directly obtain host permissions.

[0076] It can be understood that if the severity of the operation that can be achieved by the target vulnerability is higher, the severity of the consequence is higher, and the greater the impact on the project, the higher the score corresponding to the severity of the consequence. That is to say, in the embodiment of the present application, the corresponding relationship between the severity of the consequence and the severity of the consequence score is that the higher the severity of the consequence, the higher the corresponding severity of the consequence.

[0077] After obtaining the above-mentioned first sub-score, second sub-score, and third sub-score, since the electronic device stores preset weights corresponding to the sub-dimensions for each sub-dimension of the severity of the vulnerability, that is, the electronic device stores the first sub-weight corresponding to the exploitability of the vulnerability, the second sub-weight corresponding to the scope of impact of the vulnerability, and the third sub-weight corresponding to the severity of the consequences of the vulnerability, the electronic device performs weighted summation of the first sub-score, the second sub-score, and the third sub-score according to the first sub-score and the corresponding first sub-weight, the second sub-score and the corresponding second sub-weight, and the third sub-score and the corresponding third sub-weight to obtain the corresponding sum, and determines the sum as the first score corresponding to the severity of the target vulnerability.

[0078] In an embodiment of the present application, the first score corresponding to the severity of the target vulnerability is determined in combination with the exploitability information, impact scope information, consequence severity information, etc. of the target vulnerability, thereby improving the accuracy of the first score corresponding to the severity of the target vulnerability and facilitating the subsequent further accurate determination of the risk level of the vulnerability based on the first score.

[0079] Embodiment 3:

[0080] In order to further accurately determine the risk level of the vulnerability, based on the above embodiments, in the embodiment of the present application, based on the risk score of the target vulnerability, it is determined whether to give priority to the target vulnerability, including:

[0081] Obtain the target risk level of the saved target vulnerability, and determine the risk score corresponding to the target vulnerability based on the correspondence between the saved risk level and the risk score;

[0082] Determine the target score of the target vulnerability based on the risk score and risk score of the target vulnerability;

[0083] Determine the target priority of the target vulnerability according to the target score of the target vulnerability;

[0084] Determine whether to prioritize the target vulnerability based on its target priority.

[0085] In an embodiment of the present application, the risk level of the vulnerability is recorded in the description information of each vulnerability information in the vulnerability database stored in the electronic device. For each target vulnerability, the electronic device determines the target risk level of the target vulnerability based on the identification information of the target vulnerability and the risk levels of each vulnerability stored in the electronic device.

[0086] The electronic device also stores the correspondence between risk levels and risk scores. Therefore, for each target vulnerability, the risk score corresponding to the target vulnerability is determined based on the target risk level of the target vulnerability and the correspondence between the risk level and risk score stored in the electronic device.

[0087] Among them, it can be understood that the higher the risk level of the target vulnerability, the higher the corresponding risk score.

[0088] After obtaining the risk score corresponding to the target vulnerability, since the electronic device stores the fourth weight corresponding to the risk score and the fifth weight corresponding to the risk score, for each target vulnerability, the electronic device performs weighted summation of the risk score and the risk score according to the risk score and the corresponding fourth weight of the target vulnerability and the risk score and the corresponding fifth weight to determine the target score of the target vulnerability.

[0089] In addition, the electronic device also stores the correspondence between the score range and the priority of the vulnerability. For example, different score ranges of the vulnerability correspond to different priorities, and the higher the priority, the larger the scores contained in the corresponding score range.

[0090] Therefore, after obtaining the target score of each target vulnerability, the electronic device determines the target priority of each target vulnerability according to the target score corresponding to each target vulnerability and the correspondence between the score range and the priority of the saved vulnerability.

[0091] After obtaining the target priority of each target vulnerability, for each target vulnerability, according to the target priority of the target vulnerability, it is determined whether the target priority is a high priority. If so, the target vulnerability is processed first.

[0092] In addition, in an embodiment of the present application, a vulnerability list corresponding to a project may be stored in the electronic device. After obtaining the target priority of each target vulnerability, the priority of each vulnerability in the vulnerability list may be dynamically adjusted, and the target vulnerabilities included in the adjusted vulnerability list may be processed in turn, thereby helping to concentrate resources to deal with the most critical security issues.

[0093] In an embodiment of the present application, when determining the priority of each target vulnerability, the risk level recorded in the description information of the vulnerability itself is also combined to further accurately determine the risk level of the vulnerability, thereby making risk warnings more precise and priority sorting more accurate.

[0094] Embodiment 4:

[0095] In order to improve the detection rate, based on the above embodiments, in the embodiment of the present application, the SBOM to be detected is matched with the saved vulnerability database to determine the target vulnerability existing in the SBOM to be detected and the target component associated with the target vulnerability, including:

[0096] The component name and component version number of each component included in the SBOM to be detected are fuzzy matched with the component name and component version number of the vulnerability recorded in the vulnerability information contained in the vulnerability database to determine the target vulnerability existing in the SBOM to be detected and the target component associated with the target vulnerability.

[0097] Since the SBOM to be detected corresponding to the project contains the component name and component version number of each component, the vulnerability database contains vulnerability information corresponding to each vulnerability, and each vulnerability information records the component name and component version number of the vulnerability. Therefore, in order to determine the target vulnerability in the project and the target component containing the target vulnerability, in the embodiment of the present application, the SBOM to be detected is matched with the stored vulnerability database according to the component name and component version number.

[0098] In addition, although the naming method of the component name and component version number stored in the SBOM to be detected may be the same as the naming method of the component name and component version number contained in the vulnerability database, the naming format of the component name and component version number stored in the SBOM to be detected may be different from the naming format of the component name and component version number contained in the vulnerability database, such as using a space or underscore between two characters. Therefore, in order to improve the detection rate and avoid missed detection, in an embodiment of the present application, the electronic device fuzzily matches the component name and component version number of each component contained in the SBOM to be detected with the component name and component version number of the vulnerability recorded in each vulnerability information contained in the vulnerability database, and determines the target vulnerability existing in the SBOM to be detected and the target component associated with the target vulnerability.

[0099] Specifically, the possibility that the component name and component version number of each component included in the SBOM to be detected and the component name and component version number recorded in each vulnerability information contained in the vulnerability database belong to the same entity is calculated, that is, the similarity between each <component name, component version number> in the SBOM to be detected and each <component name, component version number> in the vulnerability database is calculated, and the first target <component name, component version number> in the SBOM to be detected and the second target <component name, component version number> in the vulnerability database whose similarity is greater than a preset similarity threshold are determined.

[0100] For any pair of the first target <component name, component version number> and the second target <component name, component version number> whose similarity is greater than the preset similarity threshold, the vulnerability corresponding to the second target <component name, component version number> in the vulnerability database is determined as the target vulnerability, and the component corresponding to the first target <component name, component version number> in the SBOM to be detected is determined as the target component associated with the target vulnerability.

[0101] In the embodiment of the present application, fuzzy matching is performed between the SBOM to be detected and the stored vulnerability database based on the component name and the component version number, thereby avoiding missed detections due to incomplete matching of the component name and the component version number and improving the detection rate.

[0102] Embodiment 5:

[0103] In order to timely discover vulnerabilities in the project, based on the above embodiments, in the embodiment of the present application, the process of determining the vulnerability database includes:

[0104] Through a real-time data interface connected to an authoritative vulnerability database, information about each vulnerability in the authoritative vulnerability database is obtained in real time; wherein the vulnerability information at least includes description information of the vulnerability, the name of the component in which the vulnerability exists, and the version number of the component;

[0105] Save the vulnerability information in the authoritative vulnerability library to the vulnerability database.

[0106] In the current related technologies, static matching between the SBOM to be detected and the existing vulnerabilities is usually performed manually, which makes it impossible to obtain newly published vulnerabilities in a timely manner, and thus it is impossible to avoid the security risks brought by new vulnerabilities in a timely manner. Therefore, in order to monitor in real time whether there are newly published vulnerabilities, in the embodiment of the present application, a real-time data interface is established with the authoritative vulnerability library, so that newly published vulnerabilities can be obtained at the first time, and the design takes into account the evolution of future security threats and software supply chains. The real-time data interface has a high degree of flexibility and scalability, and can easily integrate new vulnerability databases and adapt to different security standards and frameworks.

[0107] Specifically, the electronic device obtains the vulnerability information in the authoritative vulnerability library in real time through a real-time data interface connected to the authoritative vulnerability library.

[0108] Among them, authoritative vulnerability databases include but are not limited to the CVE database, the China National Vulnerability Database (CNNVD), and the Open Source Vulnerability Database (OSV).

[0109] Among them, the real-time data interface is connected to the vulnerability data query interface provided by each authoritative vulnerability database.

[0110] The vulnerability description information, component name and component version number contained in each vulnerability information in the obtained authoritative vulnerability library are saved in the vulnerability database of the electronic device.

[0111] At the same time, the electronic device monitors the authoritative vulnerability database through a real-time data interface to see whether there are newly published vulnerabilities. If so, the vulnerability information of the newly published vulnerabilities is added to the vulnerability database.

[0112] In addition, in order to distinguish various vulnerabilities, before saving the vulnerability information corresponding to each vulnerability into the vulnerability database, identification information of each vulnerability may be determined, and then the identification information of each vulnerability and the vulnerability information may be simultaneously saved into the vulnerability database.

[0113] Among them, the process of determining the identification information of each vulnerability includes: for each vulnerability, based on the CVE number contained in the description information of the vulnerability, the component version range affected by the vulnerability, the vulnerability type number and other key attribute information, the CVE number of the vulnerability, the version numbers of each component in the affected component version range, and the vulnerability type number are spliced, and the spliced ​​number is determined as the identification information of the vulnerability.

[0114] In an embodiment of the present application, through a real-time data interface connected to an authoritative vulnerability library, information on each vulnerability in the authoritative vulnerability library is obtained in real time, and the vulnerability database contained in the electronic device is updated, so as to facilitate real-time warning of potential security vulnerabilities and timely discovery of vulnerabilities in the project, which helps the development team to identify and fix problems early in the software development life cycle and avoid the spread of vulnerabilities with product releases; and security warnings are issued for newly announced vulnerabilities, thereby improving work efficiency and response speed.

[0115] Embodiment 6:

[0116] In order to expand the monitoring scope, based on the above embodiments, in the embodiment of the present application, the method further includes:

[0117] At preset time intervals, crawlers are used to extract potential vulnerability information contained in non-authoritative vulnerability database sources;

[0118] Supplement potential vulnerability information into the vulnerability database.

[0119] In an embodiment of the present application, in addition to referring to the vulnerabilities contained in the authoritative vulnerability database, the electronic device can also extract potential vulnerability information contained in other non-authoritative vulnerability library sources through a crawler at a preset time interval, that is, regularly crawling to extract potential vulnerability information contained in non-authoritative vulnerability library sources.

[0120] Among them, the sources of non-authoritative vulnerability libraries include but are not limited to unstructured sources such as security announcements, blog posts, and social media.

[0121] The electronic device will add the vulnerability description information, component name and component version number contained in the potential vulnerability information extracted from non-authoritative vulnerability library sources to the vulnerability database, thereby enriching the vulnerability database and improving the accuracy of target vulnerabilities in subsequent detection projects.

[0122] In an embodiment of the present application, in addition to referring to the vulnerabilities included in the authoritative vulnerability library, you can also refer to the vulnerabilities included in other non-authoritative vulnerability library sources, and complete the vulnerability database based on the vulnerabilities included in the non-authoritative vulnerability library sources, thereby expanding the monitoring scope and facilitating more accurate identification of target vulnerabilities in the project in the subsequent period.

[0123] Embodiment 7:

[0124] On the basis of the above embodiments, in the embodiment of the present application, the process of determining the SBOM to be detected includes:

[0125] Get the file to be tested corresponding to the project;

[0126] Extract the component information of each component contained in the file to be detected, scan the dependency relationship between the project and each component in the file to be detected, and save the dependency relationship between the project and each component, as well as the component name and component version number contained in the corresponding component information into the SBOM to be detected.

[0127] The electronic device can obtain the file to be detected corresponding to the project in a variety of ways, and the file to be detected can be a Java Archive (jar) data package of the project, or a file format (war) data package of the Web application deployed by the project. And the file to be detected contains the source code of the project.

[0128] For example, the electronic device receives the file to be detected corresponding to the project uploaded by the user.

[0129] In another example, the electronic device pulls Git to obtain the file to be detected corresponding to the project.

[0130] In another example, the electronic device obtains the to-be-detected file corresponding to the project through an integrated development environment (IDE).

[0131] After obtaining the file to be detected corresponding to the project, the component information of each component contained in the file to be detected is extracted, and a scanning tool is used to scan the dependency relationship between the project and each component in the file to be detected.

[0132] The component information of each component includes the component name, component version number, supplier name, etc. of the component.

[0133] The dependency relationship between the project and each component, as well as the supplier name, component name and component version number contained in the corresponding component information are saved in the SBOM to be detected, and the author information of the SBOM can also be saved in the SBOM to be detected.

[0134] The SBOM to be tested supports the Software Package Data Exchange (SPDX) format, the CycloneDX format, or the Software Identification (SWID) format. That is, when the component information and dependency information are saved in the SBOM to be tested, they can be saved in the SPDX, CycloneDX or SWID format.

[0135] In addition, in an embodiment of the present application, in order to determine whether there is a component information modification or update, according to a set time interval, a Git command is used to check whether there is a modification record in the file to be detected within the set time interval. If so, it is determined whether the modification record is a modification of the component information or an update of the component information. If it is determined that the component information is modified, the corresponding original component information in the SBOM to be detected is determined according to the component name and component version number contained in the modified component information, and the original component information is modified according to the modification parameters carried in the modified component information; if it is determined that the component information is updated, the supplier name, component name, component version number, and the dependency relationship between the project and the updated component contained in the updated component information are saved in the SBOM to be detected.

[0136] The above embodiments are described below with a specific embodiment. Figure 2 A schematic diagram of a vulnerability risk prediction process is shown, comprising the following steps:

[0137] Step 1: Get the file to be tested corresponding to the project.

[0138] Step 2: Automatically detect the file to be detected and generate the corresponding SBOM to be detected; and save the dependency relationship between each component in the project and the component name and component version number contained in the corresponding component information into the SBOM to be detected.

[0139] The automatic detection of the file to be detected is achieved by extracting the component information of each component contained in the file to be detected and scanning the dependency relationship between each component and the project in the file to be detected.

[0140] Step 3: Obtain the saved vulnerability database, compare the SBOM to be detected with the vulnerability database according to the component name and component version number, and determine the affected target components and corresponding target vulnerabilities in the project.

[0141] Step 4: Determine the exploitability information and the corresponding first sub-score, consequence severity information and the corresponding third sub-score in the severity of each target vulnerability according to the vulnerability severity recorded in the description information of each vulnerability contained in the vulnerability database; determine the impact range information of the target vulnerability on the project according to the affected component range recorded in the description information of the target vulnerability and the components included in the SBOM to be detected, and determine the second sub-score corresponding to the impact range information; determine the second score corresponding to the target dependency according to the target dependency relationship of the target component associated with the project and the target vulnerability; obtain the target reference count of the project referencing the target component associated with the target vulnerability, and determine the third score corresponding to the target reference count.

[0142] Among them, if a component has a vulnerability, other components that depend on it and projects that reference it will be affected. Therefore, both the target dependency and the target reference count belong to Figure 2 The scope of the vulnerability is shown in .

[0143] The intersection of the affected component range recorded in the description information of the target vulnerability and the components included in the SBOM to be detected is determined, and based on the target components included in the intersection, the impact range information of the target vulnerability on the project is determined.

[0144] Step 5: For each target vulnerability, a weighted sum is performed based on the first sub-score corresponding to the exploitability information in the severity of the target vulnerability, the second sub-score corresponding to the impact scope information of the target vulnerability on the project, the third sub-score corresponding to the consequence severity information, the second score corresponding to the target dependency, and the third score corresponding to the target citation count to determine the risk score of the target vulnerability.

[0145] Step 6: Determine the target priority of each target vulnerability based on its risk score, sort the target vulnerabilities in descending order, and give priority to high-priority (i.e., high-risk) vulnerabilities.

[0146] Step seven, after obtaining the risk score of each target vulnerability, the electronic device can also determine the target danger level of each target vulnerability based on the corresponding relationship between the saved risk score and the danger level. If it is determined that there is a target vulnerability with a high target danger level, an early warning is automatically triggered; and the target vulnerability details, impact analysis and preliminary repair suggestions are pushed to the relevant person in charge.

[0147] The above embodiments are described below with a specific embodiment. Figure 3 Another vulnerability risk prediction process diagram is shown, comprising the following steps:

[0148] Step 1: The electronic device obtains the file to be detected corresponding to the project; wherein, the file to be detected can be received from the user, or the file to be detected can be obtained by pulling Git, or the file to be detected can be obtained through the IDE.

[0149] Step 2: extract the component name, component version number, supplier name, etc. of each component contained in the component information of the file to be detected, and use a scanning tool to scan the dependency relationship between the project and each component in the file to be detected, and obtain the author information of the SBOM; save the component name, component version number, supplier name, dependency relationship between the project and each component, and author information of the SBOM in the SBOM to be detected.

[0150] Step 3: Obtain the vulnerability information in the authoritative vulnerability database in real time through the real-time data interface connected to the authoritative vulnerability database; save the vulnerability description information, component name and component version number contained in the vulnerability information in the obtained authoritative vulnerability database to the vulnerability database of the electronic device. The authoritative vulnerability database includes but is not limited to CVE database, CNNVD and OSV.

[0151] In addition, potential vulnerability information contained in non-authoritative vulnerability library sources (such as security announcements, blog posts, social media, etc.) can be extracted through crawlers at preset time intervals, and the potential vulnerability information can be added to the vulnerability database.

[0152] Step 4: Fuzzy match the component name and component version number of each component included in the SBOM to be detected with the component name and component version number of the vulnerability recorded in each vulnerability information included in the vulnerability database to determine the target vulnerability existing in the SBOM to be detected and the target component associated with the target vulnerability.

[0153] Step 5: Obtain the severity of the vulnerability contained in the description information of each vulnerability recorded in the vulnerability database, comprehensively consider the severity of the target vulnerability (i.e., the exploitability information, impact scope information, and consequence severity information mentioned above) and component dependency information (i.e., the target dependency relationship between the project and the target component, and the target reference count of the project referencing the target component mentioned above), conduct a risk assessment on the target vulnerability, and determine the risk score of each target vulnerability.

[0154] And according to the target risk level contained in the description information of each target vulnerability, the risk score corresponding to each target vulnerability is determined, and according to the risk score and risk score of each target vulnerability, the target score of each target vulnerability is determined.

[0155] According to the target score of each target vulnerability and the correspondence between the saved risk score and the danger level, the target danger level of each target vulnerability is determined. According to the correspondence between the saved danger level and priority, the target priority of each target vulnerability is determined, and target vulnerabilities with high target priorities are processed first.

[0156] Step six: If it is determined that there is a target vulnerability with a high risk level, not only should the target vulnerability be processed as a priority, but the early warning and response mechanism should also be automatically triggered.

[0157] Specifically, the author information of the SBOM contained in the SBOM to be detected and the relevant person in charge corresponding to the project stored in the electronic device are obtained, and the target vulnerability details, impact analysis and preliminary repair suggestions are pushed to the relevant person in charge and the SBOM author through email or other instant messaging tools.

[0158] At the same time, based on the vulnerability characteristics of the target vulnerability, an emergency response guide for the target vulnerability (such as version upgrade, patch application, configuration modification, temporary mitigation measures, etc.) is automatically generated.

[0159] Embodiment 8:

[0160] Based on the same technical concept, on the basis of the above embodiments, the present application provides a vulnerability risk prediction device. Figure 4 A schematic diagram of a vulnerability risk prediction device structure provided in an embodiment of the present application is shown in FIG. Figure 4 As shown, the device comprises:

[0161] The matching module 401 is used to match the software bill of materials SBOM to be detected with the stored vulnerability database to determine the target vulnerability existing in the SBOM to be detected and the target component associated with the target vulnerability;

[0162] The evaluation module 402 is used to determine a first score corresponding to the severity of the target vulnerability according to the severity of the target vulnerability recorded in the description information of the target vulnerability and the correspondence between the saved severity and the severity score; determine a target dependency between the project and the target component according to the dependency between the project and each component recorded in the SBOM to be detected, and determine a second score corresponding to the target dependency between the project and the target component according to the target dependency and the correspondence between the saved dependency and the dependency score; obtain the target reference count of the project referencing the target component, and determine a third score corresponding to the target reference count; determine a risk score of the target vulnerability according to the first score, the second score, and the third score;

[0163] The determination module 403 is used to determine whether to give priority to the target vulnerability based on the risk score of the target vulnerability.

[0164] In a possible implementation, the evaluation module 402 is specifically used to determine a first sub-score corresponding to the exploitability of the target vulnerability based on the exploitability information included in the severity of the target vulnerability and the correspondence between the saved exploitability and the exploitability score; determine a second sub-score corresponding to the impact scope of the target vulnerability based on the impact scope information of the target vulnerability on the project included in the severity of the target vulnerability and the correspondence between the saved impact scope and the impact scope score; determine a third sub-score corresponding to the consequence severity of the target vulnerability based on the consequence severity information included in the severity of the target vulnerability and the correspondence between the saved consequence severity and the consequence severity score; determine a first score corresponding to the severity of the target vulnerability based on the first sub-score, the second sub-score, and the third sub-score.

[0165] In one possible implementation, determination module 403 is specifically used to obtain a target risk level of a saved target vulnerability, determine a risk score corresponding to the target vulnerability based on a correspondence between the saved risk level and the risk score; determine a target score for the target vulnerability based on the risk score and the risk score of the target vulnerability; determine a target priority for the target vulnerability based on the target score of the target vulnerability; and determine whether to give priority to the target vulnerability based on the target priority of the target vulnerability.

[0166] In one possible implementation, the matching module 401 is specifically used to perform fuzzy matching on the component name and component version number of each component included in the SBOM to be detected with the component name and component version number of the vulnerability recorded in each vulnerability information included in the vulnerability database, so as to determine the target vulnerability existing in the SBOM to be detected and the target component associated with the target vulnerability.

[0167] In a possible implementation, the vulnerability risk prediction device also includes an acquisition module 404, which is used to obtain, in real time, vulnerability information of each vulnerability in an authoritative vulnerability library through a real-time data interface connected to the authoritative vulnerability library; wherein the vulnerability information at least includes description information of the vulnerability, the name of the component where the vulnerability exists, and the version number of the component; and save the vulnerability information of each vulnerability in the authoritative vulnerability library into a vulnerability database.

[0168] In a possible implementation, the acquisition module 404 is further configured to extract potential vulnerability information contained in a non-authoritative vulnerability database source through a crawler at a preset time interval; and add the potential vulnerability information to the vulnerability database.

[0169] In one possible implementation, the acquisition module 404 is specifically used to obtain the file to be detected corresponding to the project; extract the component information of each component contained in the file to be detected, and scan the dependency relationship between the project and each component in the file to be detected, and save the dependency relationship between the project and each component, as well as the component name and component version number contained in the corresponding component information into the SBOM to be detected.

[0170] Embodiment 9:

[0171] Based on the same technical concept, the present application also provides an electronic device, Figure 5 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application is shown in FIG. Figure 5 As shown, it includes: a processor 501, a communication interface 502, a memory 503 and a communication bus 504, wherein the processor 501, the communication interface 502, and the memory 503 communicate with each other through the communication bus 504;

[0172] The memory 503 stores a computer program. When the program is executed by the processor 501, the processor 501 performs the following steps:

[0173] Matching the software bill of materials (SBOM) to be tested with the stored vulnerability database to determine the target vulnerability existing in the SBOM to be tested and the target component associated with the target vulnerability;

[0174] Determine a first score corresponding to the severity of the target vulnerability according to the severity of the target vulnerability recorded in the description information of the target vulnerability and the correspondence between the saved severity and the severity score; determine a target dependency between the project and the target component according to the dependency between the project and each component recorded in the SBOM to be detected, and determine a second score corresponding to the target dependency between the project and the target component according to the target dependency and the correspondence between the saved dependency and the dependency score; obtain the target reference count of the target component referenced by the project, and determine a third score corresponding to the target reference count; determine a risk score of the target vulnerability according to the first score, the second score, and the third score;

[0175] Based on the risk score of the target vulnerability, determine whether to prioritize the target vulnerability.

[0176] In a possible implementation, the processor 501 is specifically configured to determine a first sub-score corresponding to the exploitability of the target vulnerability based on the exploitability information included in the severity of the target vulnerability and the correspondence between the saved exploitability and the exploitability score; determine a second sub-score corresponding to the impact scope of the target vulnerability based on the impact scope information of the target vulnerability on the project included in the severity of the target vulnerability and the correspondence between the saved impact scope and the impact scope score; determine a third sub-score corresponding to the consequence severity of the target vulnerability based on the consequence severity information included in the severity of the target vulnerability and the correspondence between the saved consequence severity and the consequence severity score; and determine a first score corresponding to the severity of the target vulnerability based on the first sub-score, the second sub-score, and the third sub-score.

[0177] In one possible implementation, processor 501 is specifically used to obtain a saved target risk level of a target vulnerability, determine a risk score corresponding to the target vulnerability based on a correspondence between the saved risk level and the risk score; determine a target score for the target vulnerability based on the risk score and the risk score of the target vulnerability; determine a target priority for the target vulnerability based on the target score of the target vulnerability; and determine whether to give priority to the target vulnerability based on the target priority of the target vulnerability.

[0178] In one possible implementation, the processor 501 is specifically used to perform fuzzy matching on the component name and component version number of each component included in the SBOM to be detected with the component name and component version number of the vulnerability recorded in each vulnerability information included in the vulnerability database, so as to determine the target vulnerability existing in the SBOM to be detected and the target component associated with the target vulnerability.

[0179] In one possible implementation, processor 501 is specifically used to obtain, in real time, vulnerability information of each item in an authoritative vulnerability library through a real-time data interface connected to the authoritative vulnerability library; wherein the vulnerability information at least includes description information of the vulnerability, the name of the component where the vulnerability exists, and the version number of the component; and save the vulnerability information of each item in the authoritative vulnerability library into a vulnerability database.

[0180] In a possible implementation, the processor 501 is specifically configured to extract potential vulnerability information contained in a non-authoritative vulnerability database source through a crawler at a preset time interval; and add the potential vulnerability information to the vulnerability database.

[0181] In one possible implementation, the processor 501 is specifically used to obtain the file to be detected corresponding to the project; extract the component information of each component contained in the file to be detected, and scan the dependency relationship between the project and each component in the file to be detected, and save the dependency relationship between the project and each component, as well as the component name and component version number contained in the corresponding component information into the SBOM to be detected.

[0182] The communication bus mentioned in the above electronic device can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus.

[0183] The communication interface 502 is used for communication between the electronic device and other devices.

[0184] The memory may include a random access memory (RAM) or a non-volatile memory (NVM), such as at least one disk memory. Optionally, the memory may also be at least one storage device located away from the aforementioned processor.

[0185] The above-mentioned processor can be a general-purpose processor, including a central processing unit, a network processor (Network Processor, NP), etc.; it can also be a digital signal processing processor (Digital Signal Processing, DSP), an application-specific integrated circuit, a field programmable gate array or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component, etc.

[0186] Embodiment 10:

[0187] Based on the same technical concept, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program that can be executed by an electronic device. When the program runs on the electronic device, the electronic device implements any of the above embodiments when executing.

[0188] The above-mentioned computer-readable storage medium can be any available medium or data storage device that can be accessed by the processor in the electronic device, including but not limited to magnetic storage such as floppy disks, hard disks, magnetic tapes, magneto-optical disks (MO), etc., optical storage such as CD, DVD, BD, HVD, etc., and semiconductor storage such as ROM, EPROM, EEPROM, non-volatile memory (NANDFLASH), solid-state drive (SSD), etc.

[0189] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that include computer-usable program code.

[0190] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0191] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0192] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0193] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

Claims

1. A vulnerability risk prediction method, characterized in that: The method comprises: Matching the software bill of materials (SBOM) to be detected with the stored vulnerability database to determine the target vulnerability existing in the SBOM to be detected and the target component associated with the target vulnerability; Determine a first score corresponding to the severity of the target vulnerability according to the severity of the target vulnerability recorded in the description information of the target vulnerability and the correspondence between the saved severity and the severity score; determine a target dependency between the project and the target component according to the dependency between the project and each component recorded in the SBOM to be detected, and determine a second score corresponding to the target dependency between the project and the target component according to the target dependency and the correspondence between the saved dependency and the dependency score; obtain the number of target references of the project to the target component, and determine a third score corresponding to the number of target references; determine a risk score of the target vulnerability according to the first score, the second score, and the third score; Based on the risk score of the target vulnerability, determine whether to give priority to the target vulnerability.

2. The method according to claim 1, characterized in that The determining, according to the severity of the target vulnerability recorded in the description information of the target vulnerability and the correspondence between the severity and the severity score, a first score corresponding to the severity of the target vulnerability includes: Determine a first sub-score corresponding to the exploitability of the target vulnerability according to the exploitability information included in the severity of the target vulnerability and the stored correspondence between the exploitability and the exploitability score; Determine a second sub-score corresponding to the impact scope of the target vulnerability according to the impact scope information of the target vulnerability on the project contained in the severity of the target vulnerability and the saved correspondence between the impact scope and the impact scope score; Determine a third sub-score corresponding to the consequence severity of the target vulnerability according to the consequence severity information included in the severity of the target vulnerability and the stored correspondence between the consequence severity and the consequence severity score; A first score corresponding to the severity of the target vulnerability is determined according to the first sub-score, the second sub-score, and the third sub-score.

3. The method according to claim 1, characterized in that The determining whether to prioritize the target vulnerability based on the risk score of the target vulnerability includes: Obtaining the saved target risk level of the target vulnerability, and determining the risk score corresponding to the target vulnerability according to the correspondence between the saved risk level and the risk score; Determining a target score for the target vulnerability according to the risk score and risk score of the target vulnerability; Determining a target priority of the target vulnerability according to the target score of the target vulnerability; According to the target priority of the target vulnerability, it is determined whether to give priority to the target vulnerability.

4. The method according to claim 1, characterized in that The step of matching the SBOM to be detected with the stored vulnerability database to determine the target vulnerability existing in the SBOM to be detected and the target component associated with the target vulnerability includes: The component name and component version number of each component included in the SBOM to be detected are fuzzily matched with the component name and component version number of the vulnerability recorded in each vulnerability information included in the vulnerability database to determine the target vulnerability existing in the SBOM to be detected and the target component associated with the target vulnerability.

5. The method according to claim 4, characterized in that The process of determining the vulnerability database includes: Through a real-time data interface connected to an authoritative vulnerability library, each vulnerability information in the authoritative vulnerability library is obtained in real time; wherein the vulnerability information at least includes description information of the vulnerability, the name of the component where the vulnerability exists, and the version number of the component; The vulnerability information in the authoritative vulnerability library is saved in the vulnerability database.

6. The method according to claim 5, characterized in that The method further comprises: At preset time intervals, crawlers are used to extract potential vulnerability information contained in non-authoritative vulnerability database sources; The potential vulnerability information is added to the vulnerability database.

7. The method according to claim 4, characterized in that The process of determining the SBOM to be detected includes: Obtain the file to be detected corresponding to the project; Extract the component information of each component contained in the file to be detected, scan the dependency relationship between the project and each component in the file to be detected, and save the dependency relationship between the project and each component, as well as the component name and component version number contained in the corresponding component information into the SBOM to be detected.

8. A vulnerability risk prediction device, characterized in that: The device comprises: A matching module, used to match the software bill of materials SBOM to be detected with the stored vulnerability database, and determine the target vulnerability existing in the SBOM to be detected and the target component associated with the target vulnerability; An evaluation module is used to determine a first score corresponding to the severity of the target vulnerability according to the severity of the target vulnerability recorded in the description information of the target vulnerability and the correspondence between the severity and the severity score; determine a target dependency relationship between the project and the target component according to the dependency relationship between the project and each component recorded in the SBOM to be detected, and determine a second score corresponding to the target dependency relationship between the project and the target component according to the target dependency relationship and the correspondence between the saved dependency relationship and the dependency score; obtain the number of target references of the project to the target component to determine a third score corresponding to the number of target references; determine a risk score of the target vulnerability according to the first score, the second score, and the third score; The determination module is used to determine whether to give priority to the target vulnerability based on the risk score of the target vulnerability.

9. An electronic device, characterized in that: The electronic device includes at least a processor and a memory, and the processor is used to implement the steps of the vulnerability risk prediction method as described in any one of claims 1 to 7 when executing a computer program stored in the memory.

10. A computer storage medium, characterized in that: It stores a computer program executable by an electronic device. When the program runs on the electronic device, the electronic device executes the steps of the vulnerability risk prediction method according to any one of claims 1 to 7.

Images