A vulnerability risk prediction method, device, equipment and medium

Abstract

The embodiment of the application provides a vulnerability risk prediction method, device, equipment and medium, to solve the problem of low vulnerability prediction efficiency and inability to accurately determine the risk level of the vulnerability in the prior art. In the method, the to-be-detected SBOM is matched with a vulnerability database to determine a target vulnerability existing in the to-be-detected SBOM and a target component associated with the target vulnerability; a first score corresponding to the severity of the target vulnerability is determined; a second score corresponding to a target dependency relationship between the project and the target component is determined; a third score corresponding to a target reference frequency of the project referencing the target component is determined; the risk score of the target vulnerability is determined according to the first score, the second score and the third score; and whether the target vulnerability is processed preferentially is determined based on the risk score of the target vulnerability, thereby improving the vulnerability risk prediction efficiency, multi-dimensionally evaluating the vulnerability risk, and more accurately determining the vulnerability risk level.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and in particular to a vulnerability risk prediction method, apparatus, device, and medium. Background Technology

[0002] In today's complex software development environment, software supply chain security has become a critical issue. With the widespread adoption of open-source software and increased reuse of software components, software projects often rely on hundreds or even thousands of third-party libraries and frameworks. While this high level of dependency accelerates the development process, it also introduces unprecedented security challenges. Once a security vulnerability is exposed in a component of the supply chain, it can quickly affect a large number of applications that depend on it, triggering a chain reaction and causing serious security incidents.

[0003] Currently, Software Composition Analysis (SCA) is a technique for identifying and tracking all open-source and third-party components used in software development. It is used to detect known security vulnerabilities, license violations, and other issues within these 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 their respective dependencies. The SBOM typically includes metadata for each component, such as its name, version number, license information obtained from the SCA analysis, and its source.

[0004] Vulnerability prediction typically relies on manual monitoring of security bulletins or vulnerability information recorded in the Common Vulnerabilities and Exposures (CVE) database, along with information on components with the vulnerability. This involves manually checking whether software dependencies are affected. This method is not only time-consuming and inefficient, but it also relies solely on experience to determine the risk level of each vulnerability, making it impossible to accurately assess the risk level and thus providing precise protection.

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

[0006] This application provides a vulnerability risk prediction method, apparatus, device, and medium to address the problems of low vulnerability prediction efficiency and inability to accurately determine the risk level of vulnerabilities in the prior art.

[0007] In a first aspect, embodiments of this application provide a vulnerability risk prediction method, the method comprising:

[0008] The software bill of materials (SBOM) to be tested is matched with the stored vulnerability database to determine the target vulnerabilities in the SBOM to be tested and the target components associated with the target vulnerabilities.

[0009] Based on the severity of the target vulnerability recorded in the vulnerability description information and the correspondence between the saved severity and severity scores, determine the first score corresponding to the severity of the target vulnerability; based on the dependencies between the project and each component recorded in the SBOM to be detected, determine the target dependency relationship between the project and the target component; based on the target dependency relationship and the correspondence between the saved dependency relationship and dependency score, determine the second score corresponding to the target dependency relationship between the project and the target component; obtain the target reference count of the project referencing the target component, and determine the third score corresponding to the target reference count; based on the first score, second score, and third score, determine the risk score of the target vulnerability.

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

[0011] Secondly, embodiments of this application provide a vulnerability risk prediction device, the device comprising:

[0012] The matching module is used to match the Software Bill of Materials (SBOM) to be tested with the stored vulnerability database to determine the target vulnerabilities in the SBOM to be tested and the target components associated with the target vulnerabilities.

[0013] The assessment module is used to determine the severity score of the target vulnerability based on the severity of the target vulnerability recorded in the vulnerability description information and the correspondence between the saved severity scores; to determine the target dependency relationship between the project and the target component based on the dependency relationship between the project and each component recorded in the SBOM to be tested; to determine the target dependency relationship between the project and the target component based on the target dependency relationship and the correspondence between the saved dependency relationship scores; to obtain the target reference count of the project referencing the target component and to determine the target reference count corresponding to the third score; and to determine the risk score of the target vulnerability based on the first score, second score, and third score.

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

[0015] Thirdly, embodiments of this application also provide an electronic device, which includes at least a processor and a memory, wherein the processor is used to implement the steps of any of the vulnerability risk prediction methods described above when executing a computer program stored in the memory.

[0016] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of any of the vulnerability risk prediction methods described above.

[0017] Fifthly, embodiments of this application provide a computer program product, which includes computer program code. When the computer program code is run on a computer, it causes the computer to perform the steps of the vulnerability risk prediction method as described in any one of the first aspects.

[0018] In this embodiment, the Software Bill of Materials (SBOM) to be tested is matched with a stored vulnerability database to identify target vulnerabilities and associated target components within the SBOM. Based on the severity of the target vulnerability recorded in its description and the correspondence between stored severity scores, a first score is determined for the target vulnerability's severity. Based on the dependencies between items and components recorded in the SBOM, the target dependency relationship between the item and the target component is determined. Based on the target dependency relationship and the correspondence between stored dependency scores, a second score is determined for the target dependency relationship between the item and the target component. The number of times the item references the target component is obtained, and a third score is determined for the number of references. Based on the first, second, and third scores, a risk score for the target vulnerability is determined. Based on the risk score, it is determined whether to prioritize handling the target vulnerability. In this embodiment, manual vulnerability risk prediction is eliminated, improving the efficiency of vulnerability risk prediction. Furthermore, a multi-dimensional assessment of vulnerability risk, considering factors such as the vulnerability's severity and the role of the associated target component in the project, allows for a more accurate determination of the vulnerability's risk level, resulting in more precise risk warnings. Attached Figure Description

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

[0020] Figure 1 This is a schematic diagram of a vulnerability risk prediction process provided in an embodiment of this application;

[0021] Figure 2 This is a schematic diagram of a vulnerability risk prediction process provided in an embodiment of this application;

[0022] Figure 3This is a schematic diagram of another vulnerability risk prediction process provided in an embodiment of this application;

[0023] Figure 4 This is a schematic diagram of a vulnerability risk prediction device provided in an embodiment of this application;

[0024] Figure 5 This is a schematic diagram of an electronic device structure provided in an embodiment of this application. Detailed Implementation

[0025] To make the objectives and implementation methods of this application clearer, the exemplary implementation methods of this application will be clearly and completely described below with reference to the accompanying drawings of the exemplary embodiments of this application. Obviously, the exemplary embodiments described are only some embodiments of this application, and not all embodiments.

[0026] It should be noted that the brief descriptions of terms in this application are only for the convenience of understanding the embodiments described below, and are not intended to limit the embodiments of this application. Unless otherwise stated, these terms should be understood in their ordinary and common meaning.

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

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

[0029] The term "module" refers to any known or subsequently 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 this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

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

[0032] This application provides a vulnerability risk prediction method, apparatus, device, and medium. The method includes: matching a Software Bill of Materials (SBOM) to be detected with a stored vulnerability database to determine target vulnerabilities and associated target components in the SBOM; determining a first score corresponding to the severity of the target vulnerability based on the severity of the target vulnerability recorded in its description information and the stored correspondence between severity and severity scores; determining the target dependency relationship between the project and the target component based on the dependency relationship between the project and each component recorded in the SBOM; determining a second score corresponding to the target dependency relationship between the project and the target component based on the target dependency relationship and the stored correspondence between dependency and dependency scores; obtaining the target reference count of the project referencing the target component and determining a third score corresponding to the target reference count; determining a risk score for the target vulnerability based on the first, second, and third scores; and determining whether to prioritize handling the target vulnerability based on the risk score. In this embodiment, no manual prediction of vulnerability risk is required, which improves the efficiency of vulnerability risk prediction. Furthermore, the vulnerability risk is assessed from multiple dimensions, 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. This allows for a more accurate determination of the vulnerability risk level, thereby making risk warnings more precise.

[0033] Example 1:

[0034] Figure 1 This application provides a schematic diagram of a vulnerability risk prediction process, which includes:

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

[0036] The vulnerability risk prediction method provided in this application is applied to electronic devices, such as computers (PCs), servers, etc.

[0037] The electronic device obtains the SBOM (Software Module Object) of the software corresponding to the project. The SBOM records information such as the component name, component version number, dependency relationship with the project, and vendor name of each component.

[0038] Electronic devices contain a vulnerability database that records vulnerability information for each vulnerability. This vulnerability information includes at least a description of the vulnerability, the name of the component containing the vulnerability, and the component's version number.

[0039] Furthermore, since the naming convention of the component names and version numbers stored in the SBOM to be detected may be the same as that of the component names and 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 this embodiment of the application, the SBOM to be detected is matched with the vulnerability database according to the component name and component version number. The vulnerability corresponding to the 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: Based on the severity of the target vulnerability recorded in the description information and the correspondence between the saved severity and severity scores, determine the first score corresponding to the severity of the target vulnerability; based on the dependencies between the project and each component recorded in the SBOM to be detected, determine the target dependency relationship between the project and the target component; based on the target dependency relationship and the correspondence between the saved dependency relationship and dependency scores, determine the second score corresponding to the target dependency relationship between the project and the target component; obtain the target reference count of the project referencing the target component, and determine the third score corresponding to the target reference count; based on the first score, second score, and third score, determine the risk score of the target vulnerability.

[0041] To more accurately determine the risk level of vulnerabilities in project software, this application embodiment comprehensively assesses the risk score of target vulnerabilities by considering multiple dimensions, including 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 assessing the risk level of target vulnerabilities is described below:

[0042] Specifically, for each target vulnerability, since the vulnerability information includes a description of the vulnerability, which records its severity, and the electronic device stores the severity level and its corresponding severity score, in this embodiment, the electronic device determines the first score corresponding to the severity of the target vulnerability based on its own stored severity-severity score correspondence. It can be understood that the higher the severity of the target vulnerability, the higher the corresponding severity score.

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

[0044] Dependencies can be direct or indirect. If the target component is determined to be a component in the project, the dependency between the project and the target component is determined to be a direct dependency. If the target component is determined not to be a component in the project, but is a component that the project directly depends on, the dependency between the project and the target component is determined to be a direct dependency. If the target component is determined not to be a component in the project, but is a component that the project indirectly depends on, the dependency between the project and the target component is determined to be an indirect dependency.

[0045] The correspondence between dependency relationships and dependency scores includes a direct dependency score of m and an indirect dependency score of n. Score m is usually greater than score n. In other words, if the target component that the project directly depends on has a vulnerability, it will have a greater impact on the project than if the target component that the project indirectly depends on has a vulnerability.

[0046] For example, if component A is a component in the project, then the target dependency relationship between the project and component A is a direct dependency, and the second score corresponding to this 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 this target dependency relationship is determined to be score m; if component B and component C are not components in the project, but 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 this target dependency relationship is determined to be score n.

[0047] In this embodiment of the application, the electronic device records the number of times the project references each component, as well as the correspondence between the number of references and the score of the number of references. Therefore, the electronic device obtains the target number of references of the project to the target component that it has saved, 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 references based on the correspondence between the number of references and the score of the number of references it has saved.

[0048] It is understandable that the more times a component is referenced in a project, the higher the reference count score will be. In other words, if a project references a certain component more often, it indicates that the component has a greater impact on the project. Therefore, if the component has a vulnerability, the vulnerability will also have a greater impact on the project.

[0049] After obtaining the first, second, and third scores, since the electronic device stores the preset weights corresponding to each dimension of data, namely, 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 a weighted summation of the first, second, and third scores based on the first score and its corresponding first weight, the second score and its corresponding second weight, and the third score and its corresponding third weight, to obtain the corresponding sum value, and determines the sum value as the risk score of the target vulnerability.

[0050] S103: Based on the risk score of the target vulnerability, determine whether to prioritize the handling of the target vulnerability.

[0051] After determining the risk score of each target vulnerability, the priority of each target vulnerability is determined based on the risk score. A higher risk score indicates a higher risk posed by the vulnerability, thus requiring priority in handling; in other words, a higher priority is assigned to that vulnerability.

[0052] For each target vulnerability, if the target vulnerability has a high priority, it is determined that the target vulnerability needs to be addressed first; if the target vulnerability has a low priority, it is determined that the target vulnerability does not need to be addressed first, thereby ensuring that critical risks are addressed first.

[0053] In one possible implementation, after obtaining the risk score for each target vulnerability, the electronic device can further determine the target hazard level of each vulnerability based on the stored correspondence between risk scores and hazard levels, and determine the priority of each target vulnerability based on the stored correspondence between hazard levels and priorities. The hazard levels, from highest to lowest, include high-risk, medium-risk, and low-risk, and the higher the hazard level of a vulnerability, the higher its priority, meaning that the vulnerability should be addressed more quickly.

[0054] For example, if a high-risk vulnerability is identified, it will be prioritized for handling, and an alert will be automatically triggered. Since the electronic device stores information about the relevant project personnel and the SBOM to be detected contains the SBOM author information, and the electronic device has a closed-loop management system for detection, response, alerts, and remediation recommendations, it can use this system to send vulnerability details, impact analysis, and preliminary remediation recommendations to the relevant personnel and the development team (i.e., the SBOM author) via email or other instant messaging tools.

[0055] The impact analysis includes the names and version numbers of the components affected by the target vulnerability. For example, the target vulnerability affects version 2.15.0 of the Apache Log4j component.

[0056] Initial remediation recommendations typically include: upgrading the target component associated with the vulnerability and avoiding versions affected by the vulnerability (i.e., versions containing the vulnerability); deprecating an interface; modifying a configuration; and remediating based on a Git commit message.

[0057] Furthermore, if a high-risk vulnerability is identified, the electronic device can automatically generate an emergency response guide based on the vulnerability's characteristics. This guide includes, but is not limited to, version upgrades, patch application, configuration modifications, and temporary mitigation measures; no specific restrictions are set here.

[0058] The vulnerability characteristics of the target vulnerability include detailed information about the vulnerability, such as the affected component version, which function in the component triggers the vulnerability, how it can be triggered, and related reference links. Based on these vulnerability characteristics, the appropriate incident response guidelines can be determined.

[0059] In another possible implementation, the electronic device can display key information such as the overall security posture of the project, the ranking of risky components, the distribution of vulnerability risks, and the distribution of component references on the display page, supporting relevant personnel to conduct multi-dimensional filtering and drill-down analysis. Furthermore, the electronic device can automatically generate weekly / monthly security reports, summarizing vulnerability discovery and remediation, providing security improvement suggestions, and supporting the export of security reports to Portable Document Format (PDF) or spreadsheet (Excel) files for easy team review or management approval. Thus, through an intuitive visual interface, it provides relevant personnel with convenient security support tools, enhancing team collaboration and communication efficiency.

[0060] In this embodiment, no manual prediction of vulnerability risks is required, which improves the efficiency of vulnerability risk prediction. Furthermore, the vulnerability risk is assessed from multiple dimensions, 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. This allows for a more accurate determination of the vulnerability risk level, resulting in more precise risk warnings. 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 leaks caused by vulnerability exploitation, and thus ensure business continuity.

[0061] Example 2:

[0062] To further accurately determine the risk level of a vulnerability, based on the above embodiments, in this embodiment, the severity of the target vulnerability recorded in the description information of the target vulnerability and the correspondence between the saved severity and severity scores are used to determine a first score corresponding to the severity of the target vulnerability, including:

[0063] Based on the exploitability information contained in the severity of the target vulnerability and the stored correspondence between exploitability and exploitability score, determine the first sub-score corresponding to the exploitability of the target vulnerability.

[0064] 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, the second sub-score corresponding to the impact scope of the target vulnerability is determined.

[0065] Based on the severity information of consequences included in the severity of the target vulnerability and the correspondence between the saved severity of consequences and severity scores, the third sub-score corresponding to the severity of consequences of the target vulnerability is determined.

[0066] Based on the first sub-score, the second sub-score, and the third sub-score, determine the first score corresponding to the severity of the target vulnerability.

[0067] In this embodiment, the description information of the target vulnerability records its severity. Specifically, the severity of the target vulnerability includes, but is not limited to, its exploitability, the scope of affected components, and the severity of its consequences. Therefore, to more accurately determine the first score corresponding to the severity of the target vulnerability, in this embodiment, the first score corresponding to the severity of the target vulnerability can be determined by combining the exploitability information, the scope of affected components, and the severity of its consequences. The process of determining the first score corresponding to the severity of the target vulnerability is explained below:

[0068] If an electronic device stores a correspondence between exploitability and exploitability score, the electronic device obtains the exploitability information contained in the severity of the target vulnerability description information. Based on the exploitability information of the target vulnerability and the correspondence between exploitability and exploitability score stored in the device itself, the electronic device determines the first sub-score corresponding to the exploitability of the target vulnerability.

[0069] Exploitability includes the complexity of how users operate on the vulnerability, such as whether it is operable by authorized users or by all users.

[0070] It is understandable that the higher the complexity of operating on the target vulnerability, i.e. the higher the privilege level, the lower the exploitability and the smaller the impact on the project, the lower the exploitability score. In other words, in the embodiments of this application, the correspondence between exploitability and exploitability score is that the lower the exploitability, the lower the corresponding exploitability score.

[0071] Furthermore, the electronic device also stores the correspondence between the scope of impact and the score of the scope of impact. The electronic device obtains the scope of affected components included in the severity of the target vulnerability description information, and matches the component names and version numbers recorded in the scope of impact with the SBOM to be detected corresponding to the project to determine whether the SBOM to be detected contains the components in the scope of impact. If it does, the number of components in the scope of impact contained in the SBOM to be detected is determined. The number of components in the scope of impact contained in the SBOM to be detected is determined as the scope of impact of the target vulnerability on the project. Based on the scope of impact information and the correspondence between the scope of impact and the score of the scope of impact stored by the device, the second sub-score corresponding to the scope of impact of the target vulnerability is determined.

[0072] The scope of impact includes whether it is possible to use a component with the vulnerability to affect other components that the project depends on, and if so, determining the number of other components that the component with the vulnerability affects.

[0073] It is understandable that if the number of other components that the project depends on is greater than the number of components affected by the component with the target vulnerability (i.e. the target component mentioned above), the scope of the target vulnerability will be larger and the impact on the project will be greater. In other words, the corresponding score for the scope of impact is higher. In this embodiment of the application, the correspondence between the scope of impact and the score of the scope of impact is that the larger the scope of impact, the higher the score of the corresponding scope of impact.

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

[0075] The severity of the consequences includes the extent of the operations that the vulnerability can enable, such as whether the vulnerability enables the modification of file content or the direct acquisition of host privileges.

[0076] It is understandable that the higher the severity of the operation that the target vulnerability can achieve, the higher the severity of the consequences and the greater the impact on the project. In other words, the higher the score corresponding to the severity of the consequences, the higher the severity of the consequences. In this embodiment of the application, the correspondence between the severity of the consequences and the severity score is that the higher the severity of the consequences, the higher the severity of the corresponding consequences.

[0077] After obtaining the first sub-score, second sub-score, and third sub-score, since the electronic device stores the preset weights corresponding to each sub-dimensional 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 the vulnerability's impact, and the third sub-weight corresponding to the severity of the vulnerability's consequences, the electronic device performs a weighted summation of 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 value, and determines the sum value as the first score corresponding to the severity of the target vulnerability.

[0078] In this embodiment, the first score corresponding to the severity of the target vulnerability is determined by combining the exploitability information, the scope of impact information, and the severity of the consequences information of the target vulnerability. This improves the accuracy of the first score corresponding to the severity of the target vulnerability and makes it easier to further determine the risk level of the vulnerability based on the first score.

[0079] Example 3:

[0080] To further accurately determine the risk level of a vulnerability, based on the above embodiments, this application embodiment determines whether to prioritize handling the target vulnerability based on its risk score, 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 risk score;

[0082] The target score for the target vulnerability is determined based on its risk score and risk value.

[0083] The target priority of the target vulnerability is determined based on its target score.

[0084] Based on the target vulnerability's priority, determine whether to prioritize addressing the target vulnerability.

[0085] In this embodiment of the application, the description information of each vulnerability in the vulnerability database stored in the electronic device records the risk level of the vulnerability. Then, 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 itself.

[0086] Electronic devices also store 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 risk levels and risk scores stored in the device itself.

[0087] It is understandable 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 a weighted sum of the risk score and the risk score based on the risk score and the corresponding fourth weight and the risk score and the corresponding fifth weight of the target vulnerability to determine the target score of the target vulnerability.

[0089] In addition, electronic devices also store the correspondence between the score range and priority of vulnerabilities. For example, different score ranges of vulnerabilities correspond to different priorities, and the higher the priority, the larger the score range contains each score.

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

[0091] After obtaining the target priority of each target vulnerability, for each target vulnerability, determine whether the target priority is high priority based on the target priority of the target vulnerability. If so, the target vulnerability is processed first.

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

[0093] In this embodiment of the 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 the risk warning more accurate and the priority ranking more accurate.

[0094] Example 4:

[0095] To improve the detection rate, based on the above embodiments, in this embodiment, the SBOM to be detected is matched with a stored vulnerability database to determine the target vulnerabilities present in the SBOM to be detected and the target components associated with the target vulnerabilities, including:

[0096] The component names and version numbers of each component contained in the SBOM to be detected are fuzzily matched with the component names and version numbers of the components with the same vulnerability recorded in the vulnerability information contained in the vulnerability database to determine the target vulnerability in the SBOM to be detected and the target component associated with the target vulnerability.

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

[0098] Furthermore, considering that although the naming conventions of component names and version numbers stored in the SBOM to be detected may be the same as those in the vulnerability database, the naming format of component names and version numbers stored in the SBOM to be detected may differ from that in the vulnerability database, for example, by using spaces or underscores between two characters. Therefore, in order to improve the detection rate and avoid missed detections, in this embodiment of the application, the electronic device performs fuzzy matching between the component names and version numbers of each component in the SBOM to be detected and the component names and version numbers of the components with the corresponding vulnerability recorded in the vulnerability information in the vulnerability database, to determine the target vulnerability in the SBOM to be detected and the target component associated with the target vulnerability.

[0099] Specifically, the probability that the component names and version numbers of each component in the SBOM to be detected belong to the same entity as the component names and version numbers of the vulnerable components recorded in the vulnerability information contained in the vulnerability database, 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 with a similarity greater than a preset similarity threshold and the second target <component name, component version number> in the vulnerability database are determined.

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

[0101] In this embodiment of the application, a fuzzy match is performed between the SBOM to be detected and the stored vulnerability database based on the component name and component version number, which avoids the situation of missed detection due to incomplete matching of component name and component version number, and improves the detection rate.

[0102] Example 5:

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

[0104] By connecting to an authoritative vulnerability database via a real-time data interface, information on each vulnerability in the database is obtained in real time. The vulnerability information includes at least a description of the vulnerability, the name of the component containing the vulnerability, and the component version number.

[0105] Save vulnerability information from authoritative vulnerability databases to the vulnerability database.

[0106] Currently, related technologies typically involve manual static matching of the SBOM to be detected with existing vulnerabilities, which cannot promptly acquire newly disclosed vulnerabilities and thus cannot effectively mitigate the security risks posed by them. Therefore, to monitor the existence of newly disclosed vulnerabilities in real time, this application embodiment establishes a real-time data interface with an authoritative vulnerability database. This facilitates the immediate acquisition of newly disclosed vulnerabilities. Furthermore, considering future security threats and the evolution of the software supply chain, this real-time data interface possesses high flexibility and scalability, enabling easy integration with new vulnerability databases and adaptation to different security standards and frameworks.

[0107] Specifically, electronic devices obtain vulnerability information from authoritative vulnerability databases in real time through a real-time data interface connected to the database.

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

[0109] The real-time data interface is connected to the vulnerability data query interfaces provided by various authoritative vulnerability databases.

[0110] The vulnerability descriptions, component names containing the vulnerability, and component version numbers from the authoritative vulnerability database are saved to the electronic device's vulnerability database.

[0111] Meanwhile, electronic devices monitor authoritative vulnerability databases for newly disclosed vulnerabilities through real-time data interfaces. If so, the vulnerability information of the newly disclosed vulnerabilities is added to the vulnerability database.

[0112] In addition, to differentiate between vulnerabilities, before saving the vulnerability information corresponding to each vulnerability to the vulnerability database, the identification information of each vulnerability can be determined, and then the identification information and vulnerability information of each vulnerability can be saved to the vulnerability database at the same time.

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

[0114] In this embodiment of the application, by connecting to an authoritative vulnerability database through a real-time data interface, the vulnerability information in the authoritative vulnerability database is obtained in real time, and the vulnerability database contained in the electronic device is updated. This facilitates real-time early warning of potential security vulnerabilities, timely discovery of vulnerabilities in the project, and helps the development team to identify and fix problems in the early stages of the software development life cycle, preventing vulnerabilities from spreading with product release. Furthermore, it provides security warnings for newly disclosed vulnerabilities, improving work efficiency and response speed.

[0115] Example 6:

[0116] To expand the monitoring scope, based on the above embodiments, the method in this application embodiment further includes:

[0117] At preset time intervals, the web crawler extracts potential vulnerability information from non-authoritative vulnerability databases.

[0118] Add potential vulnerability information to the vulnerability database.

[0119] In this embodiment of the application, in addition to referring to vulnerabilities contained in authoritative vulnerability databases, the electronic device can also extract potential vulnerability information contained in other non-authoritative vulnerability databases by crawling at preset time intervals, that is, timed crawling to extract potential vulnerability information contained in non-authoritative vulnerability databases.

[0120] Non-authoritative vulnerability databases include, but are not limited to, unstructured sources such as security bulletins, blog posts, and social media.

[0121] Electronic devices will supplement the vulnerability database with descriptions of vulnerabilities, names of components containing the vulnerabilities, and component version numbers from potential vulnerability information extracted from non-authoritative vulnerability databases. This will enrich the vulnerability database and improve the accuracy of target vulnerability detection in subsequent projects.

[0122] In this application embodiment, in addition to referring to vulnerabilities contained in authoritative vulnerability databases, vulnerabilities contained in other non-authoritative vulnerability database sources can also be referenced, and the vulnerability database can be supplemented based on the vulnerabilities contained in the non-authoritative vulnerability database sources, thereby expanding the monitoring scope and facilitating more accurate identification of target vulnerabilities in the project.

[0123] Example 7:

[0124] Based on the above embodiments, in this embodiment, the process of determining the SBOM to be detected includes:

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

[0126] Extract the component information of each component contained in the file to be tested, and scan the dependencies between the project and each component in the file to be tested. Save the dependencies 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 tested.

[0127] Electronic devices can obtain the file to be tested corresponding to a project in various ways. This file can be a Java archive (jar) data package for the project, or a web application archive (war) data package for the project. Furthermore, this file contains the source code of the project.

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

[0129] Another example is an electronic device pulling Git to obtain the files to be tested for the project.

[0130] As another example, electronic devices obtain the files to be tested for the project through an Integrated Development Environment (IDE).

[0131] After obtaining the file to be tested for the project, extract the component information of each component contained in the file to be tested, and use a scanning tool to scan the dependencies between the project and each component in the file to be tested.

[0132] The component information for each component includes the component name, component version number, and supplier name.

[0133] The project's dependencies on each component, along with the vendor name, component name, and component version number contained in the corresponding component information, are saved to the SBOM to be tested. The author information of the SBOM can also be saved to the SBOM to be tested.

[0134] The SBOM to be tested supports Software Package Data Exchange (SPDX) format, CycloneDX format, or Software Identification (SWID) format. In other words, when saving component information and dependencies into the SBOM to be tested, it can be saved in SPDX, CycloneDX, or SWID formats.

[0135] In addition, in this embodiment of the application, in order to determine whether there is any modification or update of component information, the Git command is used to check whether there are any modification records in the file to be tested within the set time interval. If so, it is determined whether the modification record is a modification of component information or an update of component information. If it is determined that there is a modification of component information, the original component information in the SBOM to be tested 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 there is an update of component information, the supplier name, component name, component version number, project and dependency relationship of the updated component contained in the updated component information are saved to the SBOM to be tested.

[0136] The above embodiments are described below with a specific example. See [link to example]. Figure 2 The diagram shown illustrates a vulnerability risk prediction process, which includes the following steps:

[0137] Step 1: Obtain 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; save the dependencies of each component in the project and the component name and version number contained in the corresponding component information into the SBOM to be detected.

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

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

[0141] Step four: Based on the vulnerability severity recorded in the description information of each vulnerability in the vulnerability database, determine the exploitability information and corresponding first sub-score, consequence severity information and corresponding third sub-score for each target vulnerability severity; based on the scope of affected components recorded in the target vulnerability description information and the components contained in the SBOM to be detected, determine the impact scope information of the target vulnerability on the project, and determine the second sub-score corresponding to the impact scope information; based on the target dependency relationship between the project and the target component associated with the target vulnerability, determine the second score corresponding to the target dependency relationship; 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] Since a vulnerability in a component affects other components that depend on it and projects that reference it, both target dependencies and target reference counts are considered important. Figure 2 The scope of the vulnerability is shown in the diagram.

[0143] Specifically, the intersection of the scope of affected components recorded in the description information of the target vulnerability and the components contained in the SBOM to be detected is determined, and the scope of impact of the target vulnerability on the project is determined based on the target components contained in the intersection.

[0144] Step 5: For each target vulnerability, perform a weighted summation 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 severity of the consequences, the second sub-score corresponding to the target dependency relationship, and the third sub-score corresponding to the target reference count, to determine the risk score of the target vulnerability.

[0145] Step 6: Based on the risk score of each target vulnerability, determine the target priority of each target vulnerability, sort the target vulnerabilities in descending order of priority, and prioritize the handling of high-priority (i.e., high-risk) vulnerabilities.

[0146] Step 7: After obtaining the risk scores for each target vulnerability, the electronic device can also determine the target risk level of each target vulnerability based on the saved correspondence between risk scores and risk levels. If a target vulnerability with a high risk level is determined, an early warning will be automatically triggered, and details of the target vulnerability, impact analysis, and preliminary remediation suggestions will be pushed to the relevant personnel.

[0147] The above embodiments are described below with a specific example. See [link to example]. Figure 3 The diagram shown illustrates another vulnerability risk prediction process, which includes the following steps:

[0148] Step 1: The electronic device obtains the file to be tested corresponding to the project; this can be done by receiving the file to be tested uploaded by the user, pulling the file from Git, or obtaining the file through an IDE.

[0149] Step 2: Extract the component information of each component in the file to be tested, including the component name, component version number, vendor name, etc., and use a scanning tool to scan the dependencies between the project and each component in the file to be tested. At the same time, obtain the author information of the SBOM. Save the component name, component version number, vendor name, dependencies between the project and each component, and author information of the SBOM to the SBOM to be tested.

[0150] Step 3: Obtain vulnerability information from authoritative vulnerability databases in real time via a real-time data interface connected to such databases. Save the vulnerability descriptions, component names containing the vulnerabilities, and component version numbers from these databases to the electronic device's vulnerability database. Authoritative vulnerability databases include, but are not limited to, CVE databases, CNNVD, and OSV.

[0151] Furthermore, it can extract potential vulnerability information from non-authoritative vulnerability database sources (such as security bulletins, blog posts, social media, etc.) at preset time intervals and add the potential vulnerability information to the vulnerability database.

[0152] Step 4: Perform a fuzzy match between the component names and version numbers of each component in the SBOM to be tested and the component names and version numbers of the components with the same vulnerability recorded in the vulnerability database, in order to determine the target vulnerability in the SBOM to be tested and the target component associated with the target vulnerability.

[0153] Step 5: Obtain the severity of each vulnerability from the description information recorded in the vulnerability database. Combine the severity of the target vulnerability (i.e., the exploitability information, scope of impact information, and severity of consequences information mentioned above) with the component dependency information (i.e., the target dependency relationship between the project and the target component mentioned above, and the number of times the project references the target component) to conduct a risk assessment of the target vulnerability and determine the risk score of each target vulnerability.

[0154] Based on the target risk level contained in the description information of each target vulnerability, the risk score corresponding to each target vulnerability is determined, and based on the risk score and risk value of each target vulnerability, the target score of each target vulnerability is determined.

[0155] Based on 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. Based on the correspondence between the saved danger level and the priority, the target priority of each target vulnerability is determined, and target vulnerabilities with higher target priorities are processed first.

[0156] Step 6: If a target vulnerability with a high risk level is identified, not only should the target vulnerability be prioritized for handling, but an early warning and response mechanism should also be automatically triggered.

[0157] Specifically, obtain the author information of the SBOM contained in the SBOM to be detected, as well as the relevant person in charge of the project stored on the electronic device, and push the target vulnerability details, impact analysis and preliminary remediation suggestions 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 (such as version upgrade, patch application, configuration modification, temporary mitigation measures, etc.) is automatically generated for the target vulnerability.

[0159] Example 8:

[0160] Based on the same technical concept and the above embodiments, this application provides a vulnerability risk prediction device. Figure 4 This is a schematic diagram of a vulnerability risk prediction device provided in an embodiment of this application, as shown below. Figure 4 As shown, the device includes:

[0161] The matching module 401 is used to match the Software Bill of Materials (SBOM) to be tested with the stored vulnerability database to determine the target vulnerability in the SBOM to be tested and the target component associated with the target vulnerability.

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

[0163] Module 403 is used to determine whether to prioritize the target vulnerability based on the risk score of the target vulnerability.

[0164] In one possible implementation, the evaluation module 402 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 stored correspondence between exploitability and exploitability scores; 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 stored correspondence between impact scope and impact scope scores; 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 stored correspondence between consequence severity and consequence severity scores; 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.

[0165] In one possible implementation, the determining module 403 is specifically used to obtain the target risk level of the saved target vulnerability, determine the risk score corresponding to the target vulnerability based on the correspondence between the saved risk level and risk score, determine the target score of the target vulnerability based on the risk score and risk score of the target vulnerability, determine the target priority of the target vulnerability based on the target score of the target vulnerability, and determine whether to prioritize the handling of 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 a fuzzy match between the component names and component version numbers of each component contained in the SBOM to be detected and the component names and component version numbers of the components with the vulnerability recorded in the vulnerability information contained in the vulnerability database, so as to determine the target vulnerability in the SBOM to be detected and the target component associated with the target vulnerability.

[0167] In one possible implementation, the vulnerability risk prediction device further includes an acquisition module 404, which is used to acquire vulnerability information in the authoritative vulnerability database in real time through a real-time data interface connected to the authoritative vulnerability database; wherein the vulnerability information includes at least a description of the vulnerability, the name of the component containing the vulnerability, and the component version number; and saves the vulnerability information in the authoritative vulnerability database to the vulnerability database.

[0168] In one possible implementation, the acquisition module 404 is further configured to extract potential vulnerability information contained in non-authoritative vulnerability databases by crawling at preset time intervals; and to supplement the vulnerability database with the potential vulnerability information.

[0169] In one possible implementation, the acquisition module 404 is specifically used to acquire the file to be tested corresponding to the project; extract the component information of each component contained in the file to be tested, and scan the dependency relationship between the project and each component in the file to be tested, 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 tested.

[0170] Example 9:

[0171] Based on the same technical concept, this application also provides an electronic device. Figure 5 This application provides a schematic diagram of an electronic device structure, such as... Figure 5 As shown, it includes: processor 501, communication interface 502, memory 503 and communication bus 504, wherein processor 501, communication interface 502 and memory 503 communicate with each other through 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] The software bill of materials (SBOM) to be tested is matched with the stored vulnerability database to determine the target vulnerabilities in the SBOM to be tested and the target components associated with the target vulnerabilities.

[0174] Based on the severity of the target vulnerability recorded in the vulnerability description information and the correspondence between the saved severity and severity scores, determine the first score corresponding to the severity of the target vulnerability; based on the dependencies between the project and each component recorded in the SBOM to be detected, determine the target dependency relationship between the project and the target component; based on the target dependency relationship and the correspondence between the saved dependency relationship and dependency score, determine the second score corresponding to the target dependency relationship between the project and the target component; obtain the target reference count of the project referencing the target component, and determine the third score corresponding to the target reference count; based on the first score, second score, and third score, determine the risk score of the target vulnerability.

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

[0176] In one possible implementation, the processor 501 is specifically configured to: determine a first sub-score corresponding to the exploitability of the target vulnerability based on exploitability information included in the severity of the target vulnerability and a stored correspondence between exploitability and exploitability scores; 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 a stored correspondence between impact scope and impact scope scores; 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 a stored correspondence between consequence severity and consequence severity scores; 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, the processor 501 is specifically configured to obtain the target risk level of the stored target vulnerability, determine the risk score corresponding to the target vulnerability based on the correspondence between the stored risk level and risk score, determine the target score of the target vulnerability based on the risk score and risk score of the target vulnerability, determine the target priority of the target vulnerability based on the target score of the target vulnerability, and determine whether to prioritize the processing of the target vulnerability based on the target priority of the target vulnerability.

[0178] In one possible implementation, the processor 501 is specifically configured to perform a fuzzy match between the component names and component version numbers of each component contained in the SBOM to be detected and the component names and component version numbers of the components with the vulnerability recorded in the vulnerability information contained in the vulnerability database, so as to determine the target vulnerability in the SBOM to be detected and the target component associated with the target vulnerability.

[0179] In one possible implementation, the processor 501 is specifically configured to acquire vulnerability information from the authoritative vulnerability database in real time via a real-time data interface connected to the authoritative vulnerability database; wherein the vulnerability information includes at least a description of the vulnerability, the name of the component containing the vulnerability, and the component version number; and save the vulnerability information from the authoritative vulnerability database to the vulnerability database.

[0180] In one possible implementation, the processor 501 is specifically configured to extract potential vulnerability information contained in non-authoritative vulnerability databases by crawling at preset time intervals; and to supplement the vulnerability database with the potential vulnerability information.

[0181] In one possible implementation, the processor 501 is specifically used to obtain the file to be tested corresponding to the project; extract the component information of each component contained in the file to be tested, and scan the dependency relationship between the project and each component in the file to be tested, 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 tested.

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

[0183] Communication interface 502 is used for communication between the above-mentioned electronic device and other devices.

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

[0185] The processors mentioned above can be general-purpose processors, including central processing units, network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits, field-programmable gate arrays or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0186] Example 10:

[0187] Based on the same technical concept, embodiments of this application provide a computer-readable storage medium storing a computer program executable by an electronic device. When the program is run on the electronic device, it causes the electronic device to implement any of the above embodiments.

[0188] The aforementioned computer-readable storage medium can be any available medium or data storage device that can be accessed by the processor in an electronic device, including but not limited to magnetic storage such as floppy disks, hard disks, magnetic tapes, magneto-optical disks (MO), optical storage such as CDs, DVDs, BDs, HVDs, etc., and semiconductor storage such as ROMs, EPROMs, EEPROMs, non-volatile memory (NAND flash), solid-state drives (SSDs), etc.

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

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

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

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

[0193] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A vulnerability risk prediction method, characterized in that, The method includes: The software bill of materials (SBOM) to be tested is matched with the stored vulnerability database to determine the target vulnerabilities in the SBOM to be tested and the target components associated with the target vulnerabilities. Based on the exploitability information included in the severity of the target vulnerability recorded in the description information of the target vulnerability, and the stored correspondence between exploitability and exploitability scores, a first sub-score corresponding to the exploitability of the target vulnerability is determined; based on the impact scope information of the target vulnerability on the project included in the severity of the target vulnerability, and the stored correspondence between impact scope and impact scope scores, a second sub-score corresponding to the impact scope of the target vulnerability is determined; based on the consequence severity information included in the severity of the target vulnerability, and the stored correspondence between consequence severity and consequence severity scores, a third sub-score corresponding to the consequence severity of the target vulnerability is determined; based on the first sub-score, second sub-score, and third sub-score, a first score corresponding to the severity of the target vulnerability is determined. Based on the dependencies between the items and components recorded in the SBOM to be detected, the target dependency relationship between the item and the target component is determined. Based on the target dependency relationship and the correspondence between the saved dependency relationship and the dependency relationship score, the second score corresponding to the target dependency relationship between the item and the target component is determined. The correspondence between the dependency relationship and the dependency relationship score includes the score corresponding to direct dependency and the score corresponding to indirect dependency, and the score corresponding to direct dependency is greater than the score corresponding to indirect dependency. Obtain the target reference count of the project referencing the target component, and determine the third score corresponding to the target reference count. The more times the project references the component, the higher the corresponding reference count score. The risk score of the target vulnerability is determined by weighting and summing the first score, the second score, and the third score according to the first weight corresponding to the severity of the vulnerability, the second weight corresponding to the second score and the dependency relationship between the project and the component, and the third weight corresponding to the third score and the number of times the project references the component. Based on the risk score of the target vulnerability, it is determined whether the target vulnerability should be prioritized for handling.

2. The method according to claim 1, characterized in that, The process of determining whether to prioritize handling the target vulnerability based on its risk score includes: Obtain the saved target risk level of the target vulnerability, and determine the risk score corresponding to the target vulnerability based on the saved correspondence between risk level and risk score; Based on the risk score and risk value of the target vulnerability, the target score of the target vulnerability is determined; The target priority of the target vulnerability is determined based on its target score. Based on the target priority of the target vulnerability, determine whether to prioritize the handling of the target vulnerability.

3. 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 in the SBOM to be detected and the target component associated with the target vulnerability includes: The component names and version numbers of each component contained in the SBOM to be detected are fuzzily matched with the component names and version numbers of the components with the vulnerability recorded in the vulnerability information contained in the vulnerability database to determine the target vulnerability in the SBOM to be detected and the target component associated with the target vulnerability.

4. The method according to claim 3, characterized in that, The process of determining the vulnerability database includes: By connecting to an authoritative vulnerability database via a real-time data interface, the vulnerability information in the database is obtained in real time; wherein the vulnerability information includes at least a description of the vulnerability, the name of the component containing the vulnerability, and the component version number. The vulnerability information from the authoritative vulnerability database is saved to the vulnerability database.

5. The method according to claim 4, characterized in that, The method further includes: At preset time intervals, the web crawler extracts potential vulnerability information from non-authoritative vulnerability databases. The potential vulnerability information is added to the vulnerability database.

6. The method according to claim 3, characterized in that, The process of determining the SBOM to be detected includes: Obtain the file to be tested corresponding to the project; Extract the component information of each component contained in the file to be tested, and scan the dependency relationship between the project and each component in the file to be tested. 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 tested.

7. A vulnerability risk prediction device, characterized in that, The device includes: The matching module is used to match the Software Bill of Materials (SBOM) to be tested with the stored vulnerability database to determine the target vulnerability in the SBOM to be tested and the target component associated with the target vulnerability. The evaluation module is 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 recorded in the description information of the target vulnerability and the stored correspondence between exploitability and exploitability scores; to determine a second sub-score corresponding to the impact scope of the target vulnerability based on the impact scope information of the target vulnerability included in the severity of the target vulnerability and the stored correspondence between impact scope and impact scope scores; to 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 stored correspondence between consequence severity and consequence severity scores; to determine a first score corresponding to the severity of the target vulnerability based on the first sub-score, second sub-score, and third sub-score; and to determine the dependency relationship between the project and the target component based on the dependency relationship between the project and each component recorded in the SBOM to be tested. The system identifies the dependency relationships. Based on the target dependency relationships and the stored correspondence between dependency relationships and dependency scores, a second score is determined corresponding to the target dependency relationship between the project and the target component. The correspondence between dependency relationships and dependency scores includes scores for direct dependencies and scores for indirect dependencies, with the score for direct dependencies being greater than the score for indirect dependencies. The system also obtains the target number of references the project to the target component and determines a third score corresponding to this target number of references. The more times the project references the component, the higher the corresponding reference score. Finally, the system performs a weighted sum of the first score and the third score, based on a first weight corresponding to the vulnerability severity, a second weight corresponding to the dependency relationship between the project and the component, and a third weight corresponding to the number of references the project makes to the component. This weighted sum determines the risk score for the target vulnerability. The determination module is used to determine whether to prioritize the handling of the target vulnerability based on the risk score of the target vulnerability.

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

9. A computer storage medium, characterized in that, It stores a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of the vulnerability risk prediction method according to any one of claims 1-6.

Images