Open source component evaluation method and device, computer equipment and storage medium

Abstract

The invention discloses an open source component evaluation method and device, computer equipment and a storage medium. The method comprises the steps of obtaining related data of an open source component; converting related data of the open source component into numerical values and calculating risk values of all indexes; calculating a total risk score of the open source component according to the risk value of each index and the corresponding weight; determining the risk level of the open source component according to the total risk score; and outputting the risk level. By implementing the method provided by the invention, the accuracy of open source component risk assessment can be further improved, potential risks can be accurately identified and dealt with, and different types of projects can be better served.

Description

Technical Field

[0001] The present invention relates to computers, and more particularly to an open source component evaluation method, apparatus, computer equipment, and storage medium. Background Art

[0002] In modern software development, open source components have become a key tool for improving development efficiency, reducing costs, and achieving feature richness. Many development teams accelerate the development process by integrating existing open source libraries and frameworks. However, while open source components offer numerous benefits, they also carry potential risks, most notably security vulnerabilities and licensing issues. If not effectively identified and addressed, these issues can have significant impacts on the security, compliance, and even operations of software systems. To address these risks, risk assessment of open source components has become a key research topic in software development in recent years. With the rapid growth of the open source ecosystem, numerous tools and methodologies have emerged to help developers identify the open source components used in their projects and analyze them for potential vulnerabilities and licensing issues. These tools analyze the component composition of a project's source code to identify all included open source components, compare these components with vulnerability information repositories and open source license databases, and ultimately identify risks that could impact the project.

[0003] While these technologies and methods have achieved considerable success, practical application challenges remain. Existing open source component analysis methods often employ a unified model, producing similar risk assessment results for all projects. For example, analysis tools often assign the same risk level to the same vulnerability or licensing issue in both internet-based projects and internal enterprise projects. This analysis approach fails to fully consider the specific nature and requirements of the project itself, overlooking factors such as its usage scenario, distribution channels, and operating environment. In reality, the risk of open source components is closely related to the project's characteristics. The same vulnerability or licensing issue may pose different levels of risk for different types of projects. For example, a vulnerability in an internal enterprise system may be less vulnerable to exploitation and therefore present a lower risk. However, in a public internet application, the same vulnerability could be exploited by malicious actors, resulting in more serious consequences. Similarly, a licensing issue with an open source component may lead to liability in commercial software, but may have no significant impact in non-commercial projects. Therefore, customized risk assessments should be conducted for each project based on its characteristics and usage scenarios.

[0004] Therefore, it is necessary to design a new method to further improve the accuracy of open source component risk assessment, accurately identify and respond to potential risks, and better serve different types of projects. Summary of the Invention

[0005] The purpose of the present invention is to overcome the shortcomings of the prior art and provide an open source component evaluation method, device, computer equipment and storage medium.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: an open source component evaluation method, comprising:

[0007] Obtain data related to open source components;

[0008] Convert the relevant data of the open source components into numerical values ​​and calculate the risk value of each indicator;

[0009] Calculate the total risk score of the open source component based on the risk value of each indicator and the corresponding weight;

[0010] determining a risk level for the open source component based on the total risk score;

[0011] The risk level is output.

[0012] Its further technical solution is: the open source component related data includes the distribution method, vulnerability level, vulnerability exploitation difficulty, POC disclosure status and health of the open source component.

[0013] Its further technical solution is: the risk value of each indicator includes the coding result formed after the distribution method of the open source component is numerically encoded, the vulnerability level, data leakage, vulnerability exploitation difficulty, POC disclosure and the risk value corresponding to the health level.

[0014] A further technical solution is: converting the open source component related data into numerical values ​​and calculating the risk value of each indicator, including:

[0015] Encoding the distribution method of the open source component to obtain an encoding result;

[0016] The vulnerability level, vulnerability exploitation difficulty, POC disclosure and healthiness are input into the comprehensive assessment model for risk value assessment to obtain the risk value of the corresponding indicator.

[0017] A further technical solution is to input the vulnerability level, vulnerability exploitation difficulty, POC disclosure and healthiness into a comprehensive assessment model to perform risk value assessment to obtain the risk value of the corresponding indicator, including:

[0018] Input the vulnerability level, vulnerability exploitation difficulty, POC disclosure and healthiness into the comprehensive assessment model to assign different risk levels based on the severity and possible impact of the vulnerability, thereby obtaining a risk value corresponding to the vulnerability level;

[0019] Scoring is done based on the likelihood and consequences of data leakage to obtain the corresponding risk value of the data leakage;

[0020] Assess the likelihood and difficulty of a vulnerability being successfully exploited by an attacker to obtain a risk value corresponding to the difficulty of exploiting the vulnerability;

[0021] Weighting is performed based on the disclosure of POC information to obtain the risk value corresponding to the vulnerability level, so as to obtain the risk value corresponding to the disclosure of POC;

[0022] The health of open source components is assessed by their maintenance frequency and developer activity to obtain the risk value corresponding to the health.

[0023] A further technical solution is: calculating the total risk score of the open source component based on the risk value of each indicator and the corresponding weight, including:

[0024] The risk values ​​of the various indicators and their corresponding weights are weighted and summed to obtain the total risk score of the open source component.

[0025] The present invention also provides an open source component evaluation device, comprising:

[0026] A data acquisition unit, used to obtain data related to open source components;

[0027] A risk value calculation unit, configured to convert the data related to the open source component into numerical values ​​and calculate the risk value of various indicators;

[0028] A total risk score calculation unit, configured to obtain the risk values ​​of the various indicators and the corresponding weights to calculate the total risk score of the open source component;

[0029] a level determination unit, configured to determine a risk level of the open source component based on the total risk score;

[0030] The output unit is used to obtain and output the risk level.

[0031] A further technical solution is as follows: the risk value calculation unit includes:

[0032] An encoding subunit, configured to encode the distribution method of the open source component to obtain an encoding result;

[0033] The evaluation subunit is used to input the vulnerability level, vulnerability exploitation difficulty, POC disclosure and health into the comprehensive evaluation model to perform risk value evaluation to obtain the risk value of the corresponding indicator.

[0034] The present invention further provides a computer device, comprising a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the above method when executing the computer program.

[0035] The present invention also provides a storage medium, wherein the storage medium stores a computer program, and the computer program implements the above method when executed by a processor.

[0036] The beneficial effects of the present invention compared with the existing technology are: the present invention collects and converts relevant data of open source components into numerical indicators, calculates the risk value of each indicator, and then calculates the total risk score of the open source components according to the weight, and finally determines the risk level and outputs it; this process can more accurately evaluate the security and potential risks of components, enabling developers to identify and respond to high-risk components in a timely manner, thereby improving the accuracy of open source component risk assessment and better providing risk management and decision-making support for different types of projects.

[0037] The present invention will be further described below with reference to the accompanying drawings and specific embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0039] Figure 1 A schematic diagram of an application scenario of the open source component evaluation method provided by an embodiment of the present invention;

[0040] Figure 2 A schematic diagram of a process for evaluating an open source component according to an embodiment of the present invention;

[0041] Figure 3 A schematic diagram of a sub-process of an open source component evaluation method provided by an embodiment of the present invention;

[0042] Figure 4 A schematic diagram of a sub-process of an open source component evaluation method provided by an embodiment of the present invention;

[0043] Figure 5 A schematic block diagram of an open source component evaluation device provided by an embodiment of the present invention;

[0044] Figure 6 A schematic block diagram of a risk value calculation unit of an open source component evaluation device provided by an embodiment of the present invention;

[0045] Figure 7 A schematic block diagram of an evaluation subunit of an open source component evaluation device provided in an embodiment of the present invention;

[0046] Figure 8 A schematic block diagram of a computer device provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0047] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0048] It will be understood that when used in this specification and the appended claims, the terms “comprises” and “comprising” indicate the presence of described features, integers, steps, operations, elements and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or groups thereof.

[0049] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the present invention. As used in the specification and appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms unless the context clearly indicates otherwise.

[0050] It should be further understood that the term "and / or" used in the present description and the appended claims refers to and includes any and all possible combinations of one or more of the associated listed items.

[0051] See also Figure 1 and Figure 2 , Figure 1 A schematic diagram of an application scenario of the open source component evaluation unit method provided in an embodiment of the present invention. Figure 2 A schematic flow chart of an open source component evaluation method provided in an embodiment of the present invention. The open source component evaluation method is applied to a server. The server interacts with the terminal to perform data exchange, and by comprehensively considering multiple factors such as distribution method, vulnerability level, vulnerability exploitation difficulty, POC disclosure and health, it uses numerical conversion and weighted calculation to accurately evaluate the various risk indicators of the open source component, and then derives a total risk score. This process can more accurately identify and quantify potential risks and improve the accuracy of risk assessment of open source components. Through this method, the security, stability and maintenance status of the components can be dynamically evaluated, and more customized risk prevention measures can be provided for different types of projects, effectively serving the actual needs of the project.

[0052] Figure 2 FIG. 1 is a flow chart of an open source component evaluation method provided by an embodiment of the present invention. Figure 2 As shown, the method includes the following steps S110 to S150.

[0053] S110. Obtain data related to open source components.

[0054] In this embodiment, the above-mentioned open source component related data includes the distribution method, vulnerability level, vulnerability exploitation difficulty, POC disclosure status and health of the open source component.

[0055] Specifically, first, you need to collect information on the distribution methods of open source components. Open source components can be distributed through various channels, such as internal use, commercial sales, internet-based SaaS deployment, and public open source projects. Each distribution method may carry different risks, so it is important to accurately understand the distribution method of each open source component in order to assess the potential risks associated with that distribution method.

[0056] Obtain vulnerability risk level information from vulnerability databases or other relevant data sources. Vulnerability risk levels are directly related to component security and are typically identified and assessed using vulnerability databases (such as CVSS scores). This information helps analyze vulnerability severity and provides a basis for subsequent risk level assessments.

[0057] The vulnerability's CVSS description provides information about its exploitability difficulty. CVSS (Common Vulnerability Scoring System) is a standardized method for assessing vulnerability severity and exploitation difficulty. A higher exploitation difficulty means it's more difficult for an attacker to exploit the vulnerability, potentially posing a lower risk to the system. Conversely, a lower exploitation difficulty may pose a higher risk. Therefore, vulnerability exploitation difficulty data is a crucial dimension in assessing component risk.

[0058] Collect information on whether a proof of concept (PoC) has been made public for the vulnerability. A PoC demonstrates that a vulnerability can be exploited by an attacker. A public PoC may make the vulnerability more vulnerable to exploitation. The risk of open source components varies depending on whether the PoC is made public. If a PoC is made public, the risk of exploitation is greater, so this data needs to be collected and evaluated.

[0059] Obtain data related to the health of open source components. This data can be measured by the activity of the open source community, including the component's age, number of contributors, number of participating organizations, commit frequency, number of versions released in the past year, and number of open source issues resolved within a certain period. A healthy component generally indicates active developers, frequent maintenance, and high security and stability. A healthier component may also indicate risks.

[0060] The core of step S110 is to collect data related to open source components from multiple dimensions (such as project distribution method, vulnerability risk level, vulnerability exploitation difficulty, POC disclosure information, and component health), laying a data foundation for subsequent risk assessment. The accuracy and comprehensiveness of this process directly affect the precision of subsequent assessment results. Therefore, it is imperative to collect as comprehensive and high-quality data as possible to conduct a comprehensive assessment of the risks of open source components.

[0061] S120: Convert the open source component related data into numerical values ​​and calculate the risk value of each indicator.

[0062] In this embodiment, the risk values ​​of the various indicators include the risk values ​​corresponding to the encoding result formed after the distribution method of the open source component is numerically encoded, the vulnerability level, data leakage, vulnerability exploitation difficulty, POC disclosure status and health.

[0063] In one embodiment, see Figure 3 , the above-mentioned step S120 may include steps S121 to S122.

[0064] S121. Encode the distribution method of the open source component to obtain an encoding result.

[0065] In this embodiment, the encoding result refers to the result obtained by encoding the distribution method of the open source component.

[0066] First, we numerically encode the distribution method of open source components according to given encoding rules. Different distribution methods affect risk factors such as the component's reach and potential attack surface. By converting each distribution method into a corresponding numerical code, we can more easily perform calculations in the subsequent comprehensive assessment model.

[0067] The distribution methods and their codes are as follows:

[0068] Internal use: coded as 1;

[0069] Commercial sales: coded as 2;

[0070] Internet SAAS deployment: coded as 2;

[0071] Open source project: coded as 4;

[0072] For example, if an open source component is distributed as open source, its distribution method code will be 4.

[0073] S122: Input the vulnerability level, vulnerability exploitation difficulty, POC disclosure and healthiness into a comprehensive assessment model to perform risk value assessment to obtain the risk value of the corresponding indicator.

[0074] In this embodiment, the risk value of the corresponding indicator refers to a quantitative indicator reflecting the security and potential risks of the open source component obtained after comprehensive evaluation based on multiple factors (such as vulnerability level, vulnerability exploitation difficulty, POC disclosure and health).

[0075] Multiple indicators (vulnerability level, vulnerability exploitation difficulty, POC disclosure, data leakage, health, etc.) are input into a comprehensive assessment model to calculate the risk value corresponding to each indicator. This comprehensive assessment model mainly relies on factors such as weighted calculation, vulnerability severity assessment, and data leakage consequence assessment.

[0076] The licensing risk assessment of the open source components managed by the project through package management is shown in Table 1. (From the perspective of component licensing, the top risk level is divided into four levels: high, medium, low, and none).

[0077] Table 1. Licensing risks of open source components managed by a project through package management

[0078]

[0079] In one embodiment, see Figure 4 , the above-mentioned step S122 may include steps S1221 to S1225.

[0080] S1221. Input the vulnerability level, vulnerability exploitation difficulty, POC disclosure and healthiness into a comprehensive assessment model to assign different risk levels according to the severity and possible impact of the vulnerability, so as to obtain a risk value corresponding to the vulnerability level.

[0081] In this embodiment, the vulnerability level of a component is evaluated based on its vulnerability information. Each component may have multiple vulnerabilities, and the most serious vulnerability level is taken as the vulnerability risk level of the component. The following code logic is used for evaluation:

[0082] #The risk level of the initialization component is low;

[0083] component_risk_level="low risk";

[0084] #Traverse each vulnerability information;

[0085] for vulnerability in component_vulnerabilities:

[0086] #Update the risk level of the component according to the vulnerability level;

[0087] if vulnerability.level=="critical":

[0088] component_risk_level = "critical";

[0089] break#Terminate the loop;

[0090] elif vulnerability.level=="High Risk"and component_risk_level!="Critical":

[0091] component_risk_level = "High Risk";

[0092] elif vulnerability.level=="Medium Risk"and component_risk_level not in["Serious","High Risk"]:

[0093] component_risk_level="medium risk";

[0094] elif vulnerability.level=="Low Risk"and component_risk_level not in["Serious","High Risk","Medium Risk"]:

[0095] component_risk_level="low risk";

[0096] #Returns the risk level of the component;

[0097] return component_risk_level.

[0098] The final vulnerability level risk value is determined, which may be "critical", "high risk", "medium risk" or "low risk", and a corresponding risk score will be assigned.

[0099] S1222. Score data based on the likelihood and consequences of data leakage to obtain a risk value corresponding to the data leakage.

[0100] In this embodiment, the risk assessment of data leakage mainly considers the possibility of leakage and the possible consequences of leakage. Based on the scoring of the possibility and consequences of data leakage, the corresponding risk value is given:

[0101] High likelihood and severe consequences: High risk;

[0102] Medium likelihood and consequence: Medium risk;

[0103] Low likelihood and low consequence: low risk.

[0104] Through the assessment, the risk value related to data leakage can be obtained.

[0105] S1223. Evaluate the possibility and difficulty of the vulnerability being successfully exploited by an attacker to obtain a risk value corresponding to the difficulty of exploiting the vulnerability.

[0106] In this embodiment, the likelihood and difficulty of a vulnerability being successfully exploited by an attacker are assessed. Generally, vulnerabilities with a higher degree of difficulty in exploiting represent lower risks, while vulnerabilities with a lower degree of difficulty in exploiting may pose a higher risk. Therefore, vulnerabilities are scored based on the difficulty of exploiting:

[0107] Easy to exploit: high risk;

[0108] Medium difficulty: medium risk;

[0109] Difficult to exploit: low risk.

[0110] S1224. Weighting is performed according to the disclosure of the POC information to obtain a risk value corresponding to the vulnerability level, so as to obtain a risk value corresponding to the disclosure of the POC.

[0111] In this embodiment, the disclosure of the POC information has a direct impact on the risk assessment of the vulnerability. If the POC has been made public and widely circulated, attackers can easily replicate the attack process, and the risk value of the vulnerability will be higher.

[0112] Therefore, the disclosure of POC needs to be weighted and the specific evaluation criteria are:

[0113] The POC is public and widespread: high risk;

[0114] POC is not disclosed or is limited to certain populations: low risk.

[0115] S1225. Evaluate the health of open source components based on their maintenance frequency and developer activity to obtain the risk value corresponding to the health.

[0116] The health assessment of open source components includes multiple indicators (such as project age, update frequency, submission review rate, etc.). Each indicator is weighted to obtain the project's health score. The higher the health score, the more stable and secure the open source component is. The health assessment method is as follows:

[0117] The calculation formula of health index is: Then, the sum of all health indices is divided by the sum of their weights to finally get the project's health score.

[0118] The health scores are:

[0119] 8-10: Health;

[0120] 5-8: Average;

[0121] 0-5: unhealthy;

[0122] The risk value corresponding to the final health score is:

[0123] Health: Low risk;

[0124] General: medium risk;

[0125] Unhealthy: High risk.

[0126] Specifically, the health of open source components is primarily assessed based on several indicators within the Criticality Score, including the age of the open source component project, update frequency, number of contributors, number of issues closed and updated within 90 days, and number of comments within 90 days, as shown in Table 2.

[0127] Table 2. Health assessment process for open source components

[0128]

[0129] The total score is 10 points, and the calculation method is as follows:

[0130] i=1to7 / / 7 indices;

[0131] M(i)=S(i)*[X(i) / T(i)];

[0132] Total M / Total S*10=Project Health Score;

[0133] 8-10: healthy; 5-8: average; 0-5: unhealthy.

[0134] The comprehensive assessment model combines the risk values ​​corresponding to all indicators (distribution method encoding, vulnerability level, data leakage risk, vulnerability exploitation difficulty, POC disclosure and health) to evaluate the security and reliability of the entire open source component.

[0135] Through these steps, the risk of open source components will be effectively assessed and quantified, helping developers and security experts better understand the potential risks they may face when using these components. In practical applications, developers can use these assessment results to make more informed decisions and choose safer and more robust open source components.

[0136] S130. Calculate the total risk score of the open source component based on the risk value of each indicator and the corresponding weight.

[0137] In this embodiment, the total risk score is

[0138] Specifically, the risk values ​​of the various indicators and their corresponding weights are weighted and summed to obtain the total risk score of the open source component.

[0139] First, define the weights corresponding to each indicator, as shown in Table 3.

[0140] Table 3. Weights of various indicators

[0141]

[0142] Each indicator is given an assessment value based on the actual situation, and then the total risk score is calculated based on the scores of these assessment values.

[0143] Based on the risk value and corresponding score of each indicator, a weighted sum is used to obtain the total risk score.

[0144] The specific steps are as follows:

[0145] Get the risk value of each indicator: Each indicator (such as vulnerability risk, vulnerability exploitation difficulty, etc.) has different risk levels (such as high, medium, low, etc.), corresponding to a specific score.

[0146] Weighted summation: Add up the risk scores of each indicator to get a total risk score.

[0147] Total score classification: The risk level of open source components is determined based on the total score. The specific classification rules are as follows:

[0148] High risk (H): total score greater than or equal to 6 points.

[0149] Medium risk (M): total score between 6 and 3.

[0150] Low risk (L): total score less than 3 points.

[0151] For example, suppose there are risk assessment values ​​for a component, which are:

[0152] Vulnerability risk: High (3 points);

[0153] Difficulty of exploitation: Average (0.5 points);

[0154] Is it POC: Yes (1.5 points);

[0155] Whether it is applied to the external network: Yes (1 point);

[0156] Permit risk: Medium (1 point);

[0157] Maturity: Unhealthy (1 point);

[0158] Based on the above evaluation values, the function calculate_risk_score is called to perform weighted summation. Based on the input values, the total score is calculated as follows:

[0159] Vulnerability risk: High (3 points);

[0160] Difficulty of exploitation: Average (0.5 points);

[0161] Is it POC: Yes (1.5 points);

[0162] Whether it is applied to the external network: Yes (1 point);

[0163] Permit risk: Medium (1 point);

[0164] Maturity: Unhealthy (1 point).

[0165] Total score calculation: 3+0.5+1.5+1+1+1=8.

[0166] The risk level is determined by the total score. The implementation code sample is as follows:

[0167] def calculate_risk_score(vulnerability_risk,exploit_difficulty,has_poc,external_application,license_risk,maturity):

[0168] #Define the scores of each indicator;

[0169] vulnerability_risk_scores = {'high':4,'medium':3,'low':2};

[0170] exploit_difficulty_scores = {'Very Easy': 1, 'Moderate': 0.5};

[0171] has_poc_scores = {'yes': 1.5, 'no': 1};

[0172] external_application_scores = {'yes': 1, 'no': 0.5};

[0173] license_risk_scores = {'high':1.5,'medium':1,'low':0.5};

[0174] maturity_scores = {'unrobust': 1, 'average': 0.5};

[0175] #Calculate the total score;

[0176] total_score=(vulnerability_risk_scores[vulnerability_risk]+

[0177] exploit_difficulty_scores[exploit_difficulty]+

[0178] has_poc_scores[has_poc]+

[0179] external_application_scores[external_application]+

[0180] license_risk_scores[license_risk]+

[0181] maturity_scores[maturity]);

[0182] return total_score;

[0183] # Sample input;

[0184] vulnerability_risk = 'high';

[0185] exploit_difficulty = 'normal';

[0186] has_poc = 'yes';

[0187] external_application='yes';

[0188] license_risk='medium';

[0189] maturity = 'not robust';

[0190] #Calculate the total score;

[0191] total_score=calculate_risk_score(vulnerability_risk,exploit_difficulty,has_poc,external_application,license_risk,maturity);

[0192] print(f"Total score:{total_score}");

[0193] S140. Determine the risk level of the open source component according to the total risk score.

[0194] In this example, the interpretation of the total risk score is:

[0195] ≥6 points: High risk (H). In this case, the open source component is at high risk and should be fixed first.

[0196] 6-3 points: Medium risk (M). At this point, the risk is moderate and repair is recommended.

[0197] <3 points: Low risk (L). The risk is low, and if resources are limited, deferred treatment may be considered.

[0198] The nature of the enterprise itself or the type of customers may affect the weights of certain risk items. For example, in terms of licensing risks or extranet applications, adjustments may need to be made based on the specific circumstances of the enterprise to accurately reflect the priority of risk management.

[0199] By taking a weighted summation approach, the total risk score of an open source component can be calculated based on different evaluation indicators, and the risk level of the component can be judged based on the total score, thus providing a reference for the company's repair decisions.

[0200] S150: Output the risk level.

[0201] In this embodiment, the risk level of each component is output based on its specific situation by performing risk assessment on the open source components. The risk level can be expressed in letters, specifically:

[0202] L: low risk;

[0203] M: medium risk;

[0204] H: high risk;

[0205] Based on the assessment results, a detailed risk report is automatically generated. This report includes each component's risk level and relevant assessment factors, such as vulnerability risk and component health. The report provides development teams with specific risk analysis and response recommendations for each open source component.

[0206] The method of this embodiment can play an important role in the software development process, especially in the selection and management of open source components. Through this risk assessment, developers can:

[0207] More accurately assess the risks of open source components: Evaluate the potential risks of each component to help developers make informed choices.

[0208] Optimize vulnerability repair priority: Determine which vulnerabilities need to be repaired first based on risk level to ensure system security.

[0209] This technical solution can be deployed on a server to regularly collect and process project-related open source component data and automatically perform risk assessments.

[0210] Collect information such as component distribution methods, vulnerability risk levels, vulnerability impact factors, and health status. This data is processed through encoding and weighted calculations to determine the specific risk level of each open source component. Based on the calculated results, the risk level is output and a risk report is generated to help developers make decisions.

[0211] In this way, developers and related personnel can timely understand the security status of components and take effective measures for risk management.

[0212] The above-mentioned open source component assessment method collects and converts relevant data of open source components into numerical indicators, calculates the risk value of each indicator, and then calculates the total risk score of the open source component based on the weight. Finally, the risk level is determined and output. This process can more accurately assess the security and potential risks of components, enabling developers to identify and respond to high-risk components in a timely manner, thereby improving the accuracy of open source component risk assessment and better providing risk management and decision-making support for different types of projects.

[0213] Figure 5 FIG is a schematic block diagram of an open source component evaluation device 300 provided by an embodiment of the present invention. Figure 5 As shown, corresponding to the above open source component evaluation method, the present invention also provides an open source component evaluation device 300. The open source component evaluation device 300 includes a unit for executing the above open source component evaluation method, and the device can be configured in a server. Figure 5 The open source component evaluation device 300 includes a data acquisition unit 301 , a risk value calculation unit 302 , a total risk score calculation unit 303 , a level determination unit 304 and an output unit 305 .

[0214] The data acquisition unit 301 is used to obtain data related to open source components; the risk value calculation unit 302 is used to obtain the risk value of each indicator by converting the data related to the open source components into numerical values; the total risk score calculation unit 303 is used to obtain the total risk score of the open source component based on the risk values ​​of each indicator and the corresponding weights; the level determination unit 304 is used to obtain the risk level of the open source component determined based on the total risk score; and the output unit 305 is used to obtain and output the risk level.

[0215] In one embodiment, if Figure 6 As shown, the risk value calculation unit 302 includes:

[0216] The encoding sub-unit 3021 is used to encode the distribution method of the open source component to obtain an encoding result; the evaluation sub-unit 3022 is used to input the vulnerability level, vulnerability exploitation difficulty, POC disclosure and health into the comprehensive evaluation model for risk value evaluation to obtain the risk value of the corresponding indicator.

[0217] In one embodiment, if Figure 7 As shown, the evaluation subunit 3022 includes:

[0218] The first processing module 30221 is configured to input the vulnerability level, vulnerability exploitation difficulty, POC disclosure, and healthiness into a comprehensive assessment model to assign different risk levels based on the severity and potential impact of the vulnerability, thereby obtaining a risk value corresponding to the vulnerability level;

[0219] The second processing module 30222 is used to score the data leakage based on the possibility and consequences to obtain a risk value corresponding to the data leakage;

[0220] The third processing module 30223 is used to evaluate the possibility and difficulty of the vulnerability being successfully exploited by an attacker to obtain a risk value corresponding to the difficulty of exploiting the vulnerability;

[0221] The fourth processing module 30224 is configured to perform weighting according to the disclosure of the POC information to obtain a risk value corresponding to the vulnerability level, so as to obtain a risk value corresponding to the disclosure of the POC;

[0222] The fifth processing module 30225 is used to evaluate the health of the open source component based on its maintenance frequency and developer activity to obtain a risk value corresponding to the health.

[0223] In one embodiment, the total risk score calculation unit 303 is configured to perform a weighted summation of the risk values ​​of the various indicators and the corresponding weights to obtain a total risk score of the open source component.

[0224] It should be noted that those skilled in the art can clearly understand that the specific implementation process of the above-mentioned open source component evaluation device 300 and each unit can refer to the corresponding description in the aforementioned method embodiment. For the convenience and brevity of the description, it will not be repeated here.

[0225] The open source component evaluation device 300 can be implemented in the form of a computer program. The computer program can be used in Figure 8 Runs on the computer device shown.

[0226] See also Figure 8 , Figure 81 is a schematic block diagram of a computer device provided in an embodiment of the present application. The computer device 500 may be a server, wherein the server may be an independent server or a server cluster composed of multiple servers.

[0227] See Figure 8 The computer device 500 includes a processor 502 , a memory, and a network interface 505 connected via a system bus 501 , wherein the memory may include a non-volatile storage medium 503 and an internal memory 504 .

[0228] The non-volatile storage medium 503 may store an operating system 5031 and a computer program 5032. The computer program 5032 includes program instructions, which, when executed, may cause the processor 502 to perform an open source component evaluation method.

[0229] The processor 502 is used to provide computing and control capabilities to support the operation of the entire computer device 500.

[0230] The internal memory 504 provides an environment for the operation of the computer program 5032 in the non-volatile storage medium 503. When the computer program 5032 is executed by the processor 502, the processor 502 can execute an open source component evaluation method.

[0231] The network interface 505 is used to communicate with other devices through the network. Figure 8 The structure shown in the figure is merely a block diagram of a portion of the structure related to the solution of the present application, and does not constitute a limitation on the computer device 500 to which the solution of the present application is applied. The specific computer device 500 may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0232] The processor 502 is configured to execute a computer program 5032 stored in the memory to implement the following steps:

[0233] Obtain data related to open source components; convert the data related to open source components into numerical values ​​and calculate the risk value of each indicator; calculate the total risk score of the open source components based on the risk value of each indicator and the corresponding weight; determine the risk level of the open source components based on the total risk score; and output the risk level.

[0234] The open source component-related data includes the distribution method, vulnerability level, vulnerability exploitation difficulty, POC disclosure status and health of the open source component.

[0235] The risk values ​​of each indicator include the risk values ​​corresponding to the coding results formed after the distribution method of the open source component is numerically encoded, the vulnerability level, data leakage, vulnerability exploitation difficulty, POC disclosure status and health.

[0236] In one embodiment, when the processor 502 converts the open source component-related data into numerical values ​​and calculates the risk value of each indicator, it specifically implements the following steps:

[0237] The distribution method of the open source component is encoded to obtain an encoding result; the vulnerability level, vulnerability exploitation difficulty, POC disclosure and health are input into a comprehensive assessment model for risk value assessment to obtain the risk value of the corresponding indicator.

[0238] In one embodiment, when the processor 502 implements the step of inputting the vulnerability level, vulnerability exploitation difficulty, POC disclosure, and healthiness into the comprehensive assessment model to perform risk value assessment to obtain the risk value of the corresponding indicator, the processor 502 specifically implements the following steps:

[0239] Input the vulnerability level, vulnerability exploitation difficulty, POC disclosure and healthiness into the comprehensive assessment model to assign different risk levels based on the severity and possible impact of the vulnerability, thereby obtaining a risk value corresponding to the vulnerability level;

[0240] Scoring is performed based on the possibility and consequences of data leakage to obtain the risk value corresponding to the data leakage; the possibility and difficulty of the vulnerability being successfully exploited by attackers are evaluated to obtain the risk value corresponding to the difficulty of vulnerability exploitation; weighting is performed according to the disclosure of POC information to obtain the risk value corresponding to the vulnerability level, in order to obtain the risk value corresponding to the disclosure of POC; the health of open source components is evaluated through the maintenance frequency and developer activity to obtain the risk value corresponding to the health.

[0241] In one embodiment, when the processor 502 implements the step of calculating the total risk score of the open source component based on the risk values ​​of the various indicators and the corresponding weights, the processor 502 specifically implements the following steps:

[0242] The risk values ​​of the various indicators and their corresponding weights are weighted and summed to obtain the total risk score of the open source component.

[0243] It should be understood that in the embodiment of the present application, the processor 502 may be a central processing unit (CPU), and the processor 502 may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

[0244] Those skilled in the art will appreciate that all or part of the steps in the method of the above-described embodiment can be implemented by instructing the relevant hardware through a computer program. The computer program includes program instructions, which can be stored in a storage medium that is computer-readable. The program instructions are executed by at least one processor in the computer system to implement the steps in the method of the above-described embodiment.

[0245] Therefore, the present invention also provides a storage medium. The storage medium may be a computer-readable storage medium. The storage medium stores a computer program, wherein when the computer program is executed by a processor, the processor performs the following steps:

[0246] Obtain data related to open source components; convert the data related to open source components into numerical values ​​and calculate the risk value of each indicator; calculate the total risk score of the open source components based on the risk value of each indicator and the corresponding weight; determine the risk level of the open source components based on the total risk score; and output the risk level.

[0247] The open source component-related data includes the distribution method, vulnerability level, vulnerability exploitation difficulty, POC disclosure status and health of the open source component.

[0248] The risk values ​​of each indicator include the risk values ​​corresponding to the coding results formed after the distribution method of the open source component is numerically encoded, the vulnerability level, data leakage, vulnerability exploitation difficulty, POC disclosure status and health.

[0249] In one embodiment, when the processor executes the computer program to implement the step of converting the open source component-related data into numerical values ​​and calculating the risk value of each indicator, the processor specifically implements the following steps:

[0250] The distribution method of the open source component is encoded to obtain an encoding result; the vulnerability level, vulnerability exploitation difficulty, POC disclosure and health are input into a comprehensive assessment model for risk value assessment to obtain the risk value of the corresponding indicator.

[0251] In one embodiment, when the processor executes the computer program to implement the step of inputting the vulnerability level, vulnerability exploitation difficulty, POC disclosure, and healthiness into the comprehensive assessment model to perform risk value assessment to obtain the risk value of the corresponding indicator, the processor specifically implements the following steps:

[0252] The vulnerability level, vulnerability exploitation difficulty, POC disclosure and health are input into the comprehensive assessment model to assign different risk levels according to the severity and possible impact of the vulnerability, so as to obtain the risk value corresponding to the vulnerability level; score based on the possibility and consequences of data leakage to obtain the risk value corresponding to data leakage; evaluate the possibility and difficulty of the vulnerability being successfully exploited by attackers to obtain the risk value corresponding to the difficulty of vulnerability exploitation; weight according to the disclosure of POC information to obtain the risk value corresponding to the vulnerability level, so as to obtain the risk value corresponding to the POC disclosure; evaluate the health by the maintenance frequency of open source components and the developer activity to obtain the risk value corresponding to the health.

[0253] In one embodiment, when the processor executes the computer program to implement the step of calculating the total risk score of the open source component based on the risk values ​​of the various indicators and the corresponding weights, the processor specifically implements the following steps:

[0254] The risk values ​​of the various indicators and their corresponding weights are weighted and summed to obtain the total risk score of the open source component.

[0255] The storage medium may be any computer-readable storage medium that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a magnetic disk, or an optical disk.

[0256] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the composition and steps of each example according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0257] In the several embodiments provided herein, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the various units is merely a logical functional division, and actual implementation may employ other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be omitted or not implemented.

[0258] The steps in the methods of the embodiments of the present invention may be adjusted in order, combined, or deleted as needed. The units in the devices of the embodiments of the present invention may be combined, divided, or deleted as needed. Furthermore, the functional units in the various embodiments of the present invention may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit.

[0259] If this integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the existing technology, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes a number of instructions for causing a computer device (which can be a personal computer, terminal, or network device, etc.) to execute all or part of the steps of the method described in various embodiments of the present invention.

[0260] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and such modifications or substitutions are intended to be within the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be subject to the scope of protection of the claims.

Claims

1. Open source component evaluation method, characterized by: include: Obtain data related to open source components; Convert the relevant data of the open source components into numerical values ​​and calculate the risk value of each indicator; Calculate the total risk score of the open source component based on the risk value of each indicator and the corresponding weight; determining a risk level for the open source component based on the total risk score; The risk level is output.

2. The open source component evaluation method according to claim 1, characterized in that: The open source component-related data includes the distribution method, vulnerability level, vulnerability exploitation difficulty, POC disclosure status and health of the open source component.

3. The open source component evaluation method according to claim 2, characterized in that: The risk values ​​of each indicator include the risk values ​​corresponding to the coding results formed after the distribution method of the open source component is numerically encoded, the vulnerability level, data leakage, vulnerability exploitation difficulty, POC disclosure status and health.

4. The open source component evaluation method according to claim 3, characterized in that: The process of converting the open source component related data into numerical values ​​and calculating the risk value of each indicator includes: Encoding the distribution method of the open source component to obtain an encoding result; The vulnerability level, vulnerability exploitation difficulty, POC disclosure and healthiness are input into the comprehensive assessment model for risk value assessment to obtain the risk value of the corresponding indicator.

5. The open source component evaluation method according to claim 4, characterized in that: The vulnerability level, vulnerability exploitation difficulty, POC disclosure and healthiness are input into the comprehensive assessment model for risk value assessment to obtain the risk value of the corresponding indicator, including: Input the vulnerability level, vulnerability exploitation difficulty, POC disclosure and healthiness into the comprehensive assessment model to assign different risk levels based on the severity and possible impact of the vulnerability, thereby obtaining a risk value corresponding to the vulnerability level; Scoring is done based on the likelihood and consequences of data leakage to obtain the corresponding risk value of the data leakage; Assess the likelihood and difficulty of a vulnerability being successfully exploited by an attacker to obtain a risk value corresponding to the difficulty of exploiting the vulnerability; Weighting is performed based on the disclosure of POC information to obtain the risk value corresponding to the vulnerability level, so as to obtain the risk value corresponding to the disclosure of POC; The health of open source components is assessed by their maintenance frequency and developer activity to obtain the risk value corresponding to the health.

6. The open source component evaluation method according to claim 1, characterized in that: Calculating the total risk score of the open source component based on the risk value of each indicator and the corresponding weight includes: The risk values ​​of the various indicators and their corresponding weights are weighted and summed to obtain the total risk score of the open source component.

7. An open source component evaluation device, characterized in that: include: A data acquisition unit, used to obtain data related to open source components; A risk value calculation unit, configured to convert the data related to the open source component into numerical values ​​and calculate the risk value of various indicators; A total risk score calculation unit, configured to obtain the risk values ​​of the various indicators and the corresponding weights to calculate the total risk score of the open source component; a level determination unit, configured to determine a risk level of the open source component based on the total risk score; The output unit is used to obtain and output the risk level.

8. The open source component evaluation device according to claim 7, characterized in that: The risk value calculation unit includes: An encoding subunit, configured to encode the distribution method of the open source component to obtain an encoding result; The evaluation subunit is used to input the vulnerability level, vulnerability exploitation difficulty, POC disclosure and health into the comprehensive evaluation model to perform risk value evaluation to obtain the risk value of the corresponding indicator.

9. A computer device, characterized in that: The computer device includes a memory and a processor, the memory stores a computer program, and the processor implements the method according to any one of claims 1 to 6 when executing the computer program.

10. A storage medium, characterized in that: The storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

Images