A risk assessment method, apparatus, device, and medium for open-source software components.

Abstract

This application discloses a risk assessment method, apparatus, device, and medium for open-source software components. The method includes: acquiring multi-dimensional data such as component attributes, security risk data, and ecosystem health data of the open-source software component; evaluating the component attributes based on a license risk assessment model to obtain an assessment result; if the assessment result is satisfactory, evaluating the security risk data based on a vulnerability risk evaluation model to obtain a vulnerability risk score, and evaluating the ecosystem health data based on a technical reliability evaluation model to obtain a technical reliability score; and determining the risk level of the open-source software component based on the vulnerability risk score and the technical reliability score. This technical solution uses a license risk assessment model as a pre-review item, combined with a vulnerability risk evaluation model and a technical reliability evaluation model, to systematically and quantitatively assess the risks of open-source software components, providing a scientific and accurate basis for enterprise component inclusion review and supply chain security management.

Description

Technical Field

[0001] This application relates to the field of open source component management technology, and in particular to a risk assessment method, apparatus, device and medium for open source software components. Background Technology

[0002] With the widespread application of open-source software in enterprise R&D and product development, component security risks have become a key factor affecting system stability and compliance. Currently, open-source components face multiple risks, including security vulnerabilities, license compliance conflicts, and insufficient technical reliability. Traditional assessment methods suffer from limitations such as single-dimensionality, inconsistent standards, and non-standardized processes, making it difficult to comprehensively quantify component risk levels. Industry statistics indicate that over 60% of enterprises have experienced security incidents or compliance penalties due to the use of non-compliant or high-risk open-source components.

[0003] Therefore, how to provide a technical solution for accurately assessing the risks of open-source software components is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0004] This application provides a risk assessment method, apparatus, device, and medium for open-source software components. The method uses a license risk assessment model as a prerequisite for review and combines it with a vulnerability risk assessment model and a technical reliability assessment model to conduct a systematic and quantitative assessment of the risks of open-source software components, providing a scientific and accurate basis for enterprise component warehousing review and supply chain security management.

[0005] According to one aspect of this application, a risk assessment method for open-source software components is provided, the method comprising: The component attributes are evaluated based on the license risk assessment model to obtain the evaluation results; If the assessment result is passed, the security risk data is evaluated based on the vulnerability risk assessment model to obtain a vulnerability risk score, and the ecological health data is evaluated based on the technical reliability assessment model to obtain a technical reliability score. The risk level of the open-source software component is determined based on the vulnerability risk score and the technical reliability score.

[0006] According to another aspect of this application, a risk assessment device for open-source software components is provided, characterized in that the device comprises: A multidimensional data acquisition module is used to acquire multidimensional data of open-source software components; wherein, the multidimensional data includes component attributes, security risk data, and ecosystem health data; The component attribute evaluation module is used to evaluate the component attributes based on the license risk assessment model and obtain the evaluation results; The risk and reliability assessment module is used to evaluate the security risk data based on the vulnerability risk assessment model and obtain a vulnerability risk score if the assessment result is passed, and to evaluate the ecological health data based on the technical reliability assessment model and obtain a technical reliability score. The risk level determination module is used to determine the risk level of the open-source software component based on the vulnerability risk score and the technical reliability score.

[0007] According to another aspect of this application, an electronic device is provided, the device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform a risk assessment method for open-source software components as described in any embodiment of this application.

[0008] According to another aspect of this application, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the risk assessment method for open-source software components described in any embodiment of this application.

[0009] According to another aspect of this application, a computer program product is provided, the computer program product including a computer program that, when executed by a processor, implements the risk assessment method for open-source software components described in any embodiment of this application.

[0010] The technical solution provided in this application acquires multi-dimensional data, including component attributes, security risk data, and ecosystem health data, of open-source software components. It then evaluates the component attributes based on a license risk assessment model to obtain an assessment result. If the assessment result is satisfactory, it evaluates the security risk data based on a vulnerability risk assessment model to obtain a vulnerability risk score, and evaluates the ecosystem health data based on a technical reliability assessment model to obtain a technical reliability score. Finally, it determines the risk level of the open-source software component based on the vulnerability risk score and the technical reliability score. This technical solution uses the license risk assessment model as a prerequisite for review, and combines it with the vulnerability risk assessment model and the technical reliability assessment model to systematically and quantitatively assess the risks of open-source software components, providing a scientific and accurate basis for enterprise component inclusion review and supply chain security management.

[0011] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent from the following description. Attached Figure Description

[0012] 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.

[0013] Figure 1 This is a flowchart of a risk assessment method for an open-source software component provided in Embodiment 1 of this application.

[0014] Figure 2 This is a flowchart of a risk assessment method for an open-source software component provided in Embodiment 2 of this application.

[0015] Figure 3 This is a flowchart of a risk assessment method for an open-source software component provided in Embodiment 3 of this application.

[0016] Figure 4 This is a flowchart of a risk assessment method for an open-source software component provided in Embodiment 4 of this application.

[0017] Figure 5 This is a flowchart of the full lifecycle risk assessment of an open-source software component provided in Embodiment 4 of this application.

[0018] Figure 6 This is a schematic diagram of the structure of a risk assessment device for an open-source software component provided in Embodiment 5 of this application.

[0019] Figure 7 This is a schematic diagram of the structure of a device that implements a risk assessment method for an open-source software component according to an embodiment of this application. Detailed Implementation

[0020] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0021] It should be noted that the terms "first," "second," "third," "fourth," "fifth," "sixth," "seventh," "eighth," and "ninth," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0022] It should also be noted that the acquisition, storage, use, and processing of data in the technical solution of this application all comply with the relevant provisions of national laws and regulations.

[0023] Example 1 Figure 1 This is a flowchart illustrating a risk assessment method for open-source software components provided in Embodiment 1 of this application. This embodiment is applicable to scenarios requiring risk management of open-source software components, such as technology companies, financial institutions, and government IT projects. The method can be executed by a risk assessment device for open-source software components, which can be implemented in hardware and / or software and configured in a device with data processing capabilities. Figure 1 As shown, the method includes the following steps.

[0024] S110. Obtain multidimensional data of open-source software components; wherein, the multidimensional data includes component attributes, security risk data, and ecosystem health data.

[0025] Open-source software components refer to modules or units within open-source software that can be used independently and possess specific functionalities. In software product development, it is common practice to integrate some open-source software components to reduce development costs and accelerate development efficiency.

[0026] Component attributes refer to the basic identity information and compliance identifiers of open-source software components. For example, these may include component name, component version, component developer, license name, license authentication type, and license infection type.

[0027] Security risk data refers to data related to defects and vulnerabilities in open-source software components. For example, it may include vulnerability CVE numbers, vulnerability CVSS scores, vulnerability types, vulnerability attack paths, open-source code vulnerability rates, the total number of historical vulnerabilities in the component, and the number of high-risk / critical vulnerabilities.

[0028] Ecosystem health data refers to the community vitality, maintenance quality, and long-term viability of open-source software components. For example, it may include component release frequency, the component's most recent update time, the number of contributors, issue / PR (Pull Request) responses, and the number of stars / forks.

[0029] In this application, the component attributes of open-source software components can be obtained through materials such as code hosting platform records, documentation, source code, and audit reports; security risk data of open-source software components can be obtained through channels such as the National Cybersecurity Notification Center, industry blacklists, and vulnerability platforms; and ecological health data of open-source software components can be obtained by integrating multi-source information such as component source, fault records, community data, and version update records.

[0030] In addition, software component analysis tools can be used to directly obtain component attributes, security risk data, and ecosystem health data of open-source software components.

[0031] S120. Based on the license risk assessment model, evaluate the component attributes to obtain the evaluation results.

[0032] A license risk assessment model is a model used to assess the compliance of open-source software component licenses.

[0033] The evaluation results, including pass and fail, correspond to low risk and high risk for the open-source software component's license, respectively.

[0034] In this application, the license risk assessment model can be a machine learning-based classification model that takes the component attributes of open-source software components as input and outputs assessment results. Specifically, the original license text and other component attributes can be first converted into multi-dimensional feature vectors; these multi-dimensional feature vectors are then input into a logistic regression model, support vector machine, or neural network classifier pre-trained based on historical data, and the confidence level of the classification result is output, such as "high risk: 85%, low risk: 15%"; the assessment result is then determined based on a probability threshold or decision function.

[0035] In addition, the license risk assessment model can also be a rule engine-based model, which uses predefined execution rules to match and evaluate component attributes to obtain assessment results.

[0036] S130. If the assessment result is passed, the security risk data is evaluated based on the vulnerability risk assessment model to obtain a vulnerability risk score, and the ecological health data is evaluated based on the technical reliability assessment model to obtain a technical reliability score.

[0037] If the evaluation result is unsatisfactory, indicating a high risk of license issues for the open-source software component, the component can be directly blacklisted and disabled without further steps.

[0038] When the evaluation result is passed, that is, the license risk of the open source software component is low, the vulnerability risk and technical reliability of the open source software component are evaluated by combining the vulnerability risk assessment model and the technical reliability assessment model, and the corresponding score is obtained.

[0039] Among them, the higher the vulnerability risk score, the higher the risk of the open source software component; the higher the technical reliability score, the lower the risk of the open source software component.

[0040] In this application, the vulnerability risk assessment model can be a supervised learning regression model, such as Gradient Boosting Decision Tree (GBDT), Random Forest, or Neural Network, which takes a multi-dimensional feature vector of security risk data as input and outputs a predicted vulnerability risk score. Alternatively, the vulnerability risk assessment model can be a mathematical model with predefined weights and calculation rules, which directly calculates a quantified vulnerability risk score from the input security risk data using a pre-determined formula.

[0041] Technical reliability assessment models can be supervised learning regression models, such as Gradient Boosting Decision Tree (GBDT), Random Forest, or neural networks, which take multidimensional feature vectors of ecological health data as input and output predicted technical reliability scores. Alternatively, technical reliability assessment models can be mathematical models with predefined weights and calculation rules, which directly calculate quantified technical reliability scores from input ecological health data using predetermined formulas.

[0042] S140. Determine the risk level of the open-source software component based on the vulnerability risk score and the technical reliability score.

[0043] In this application, the vulnerability risk score and technical reliability score can be weighted and summed to determine the total risk score of the open-source software component. Based on the total risk score and a pre-defined threshold range, the risk level of the open-source software component is determined. The weights of the vulnerability risk score and technical reliability score can be adjusted according to the actual application scenario.

[0044] The higher the risk level, the higher the risk of the open-source software component.

[0045] For example, the total risk score = vulnerability risk score * 80% + technical reliability score * 20%. When the total risk score is 80 or higher, the open-source software component is classified as a critical defect; when the total risk score is less than 80 but greater than or equal to 60, it is classified as a high-risk defect; when the total risk score is less than 60 but greater than or equal to 40, it is classified as a medium-risk defect; and when the total risk score is less than 40, it is classified as a low-risk defect.

[0046] In addition, vulnerability databases, license standards, and component data can be synchronized regularly to update model parameters and evaluation results.

[0047] This invention provides a risk assessment method for open-source software components. The method acquires multi-dimensional data, including component attributes, security risk data, and ecosystem health data. It then evaluates the component attributes based on a license risk assessment model to obtain an assessment result. If the assessment result is satisfactory, it evaluates the security risk data based on a vulnerability risk assessment model to obtain a vulnerability risk score, and evaluates the ecosystem health data based on a technical reliability assessment model to obtain a technical reliability score. Finally, it determines the risk level of the open-source software component based on the vulnerability risk score and the technical reliability score. This technical solution uses a license risk assessment model as a prerequisite for review, combined with a vulnerability risk assessment model and a technical reliability assessment model, to systematically and quantitatively assess the risks of open-source software components, providing a scientific and accurate basis for enterprise component inclusion review and supply chain security management.

[0048] Example 2 Figure 2 This is a flowchart illustrating a risk assessment method for open-source software components provided in Embodiment 2 of this application. This embodiment is an optimization based on the above embodiment, specifically optimizing the execution process of the license risk assessment model. Figure 2 As shown, the steps include the following.

[0049] S210. Obtain multidimensional data of open-source software components; wherein, the multidimensional data includes component attributes, security risk data and ecosystem health data, and the component attributes include at least license authentication type and infection type.

[0050] License certification type refers to the certification organization of the open source license used by the open source software component. For example, OSI (Open Source Initiative) and FSF (Free Software Foundation).

[0051] Infectivity type refers to the strength of the binding force of an open-source software component's license on the open-source obligations of derivative works or composite works using its use. Infectivity types include mandatory open-source licenses, limited sharing licenses, and free licenses. Among them, mandatory open-source licenses are highly infectious licenses, requiring that derivative works of the software component using this license also use the same license and must open-source all source code (such as the GPL license); limited sharing licenses are less infectious licenses, allowing derivative works of the software component using this license to use other licenses, but requiring the original license statement and copyright information to be retained (such as the LGPL license); free licenses are permissive licenses, meaning that derivative works of the software component using this license can use other licenses without other restrictions.

[0052] S220. Based on the license risk assessment model, determine whether the license certification type has been certified by the preset license certification system.

[0053] Specifically, a preset licensing and authentication system can be set in advance, and the system can be used to compare and match to determine whether the license authentication type has been certified by the licensing and authentication system.

[0054] For example, this application can set the default license certification system to OSI certification and FSF certification. If the license certification type of the open source software component is not OSI certification or FSF certification, or is a non-standard license, the component will be directly blacklisted and disabled. If the license certification type of the open source software component is OSI certification or FSF certification, it will enter the subsequent risk assessment process.

[0055] S230. If it is determined that the license certification type has not been certified by the preset license certification system, then the evaluation result is determined to be unsuccessful; and if it is determined that the license certification type has been certified by the preset license certification system, then it is determined whether the infection type is a preset type.

[0056] For open-source software components whose license authentication type is not certified by the preset license authentication system, their license risk assessment result is not passed, the component is directly added to the blacklist, and the component is disabled.

[0057] For open-source software components whose license authentication type is certified through a preset license authentication system, their license risk assessment result is passed, and subsequent processes proceed. Specifically, it is determined whether their infection type is a preset type. For example, in this application, the preset types can be set as a limited shared license and a free license.

[0058] S240. If the infection type is determined to be a preset type, the evaluation result is determined to be passed; if the infection type is determined to be not a preset type, the evaluation result is determined to be failed.

[0059] For example, if the infection type is determined to be a limited shared license or a free license, the assessment result is considered passed, and the process proceeds to the next risk assessment stage. If the infection type is determined to be a mandatory open-source license, the assessment result is considered failed, and the component is directly blacklisted and disabled.

[0060] S250. If the assessment result is passed, the security risk data is evaluated based on the vulnerability risk assessment model to obtain a vulnerability risk score, and the ecological health data is evaluated based on the technical reliability assessment model to obtain a technical reliability score.

[0061] S260. Determine the risk level of the open-source software component based on the vulnerability risk score and the technical reliability score.

[0062] This invention provides a risk assessment method for open-source software components. This method constructs a two-level license risk assessment model based on license authentication type and infection type, which pre-screens high-risk components, standardizes the assessment process, prevents high-risk components from entering the usage stage, and ensures the compliance and security of software products.

[0063] Example 3 Figure 3 This is a flowchart illustrating a risk assessment method for open-source software components provided in Embodiment 3 of this application. This embodiment is an optimization based on the above embodiments, specifically optimizing the execution process of the license risk assessment model. Figure 3 As shown, the steps include the following.

[0064] S310. Obtain multidimensional data of open-source software components; wherein, the multidimensional data includes component attributes, security risk data and ecosystem health data, and the security risk data includes at least CVSS score, open-source code vulnerability rate, and the existence of high-risk or critical vulnerabilities.

[0065] CVSS score refers to the score calculated by the Common Vulnerability Scoring System using a set of publicly available evaluation criteria. These criteria include attack methods, attack complexity, privilege requirements, user interaction, scope of impact, confidentiality impact, integrity impact, usability impact, exploit code, remediation plan, and source credibility.

[0066] Specifically, the CVSS scores provided by at least two software component analysis tools can be compared, and the highest score can be taken as the CVSS score of the open-source software component.

[0067] Open source code vulnerability rate refers to the number of original vulnerabilities and the vulnerability rate per thousand lines of code in open source software components.

[0068] Specifically, the number of vulnerabilities can be calculated by summarizing the component vulnerability lists provided by at least two software component analysis tools, then deduplicating the lists by CVE number, and finally counting the original vulnerabilities. Lines of code can be calculated using pseudocode to exclude comments and blank lines, and then the line count function can be embedded into the software component analysis platform via API calls or command-line plugins.

[0069] The existence of high-risk or critical vulnerabilities refers to the number of high-risk or critical vulnerabilities in an open-source software component. This distinguishes between a high CVSS score without any high-risk or critical vulnerabilities, and a low CVSS score with the presence of high-risk or critical vulnerabilities.

[0070] Specifically, the vulnerability lists provided by at least two software component analysis tools can be summarized, and the severity level of each vulnerability can be calculated. If the vulnerability levels are inconsistent, the highest level should be taken as the vulnerability level.

[0071] S320. Based on the license risk assessment model, the component attributes are evaluated to obtain the evaluation results.

[0072] S330. If the evaluation result is passed, obtain the vulnerability list of the open source software component, and for each vulnerability in the vulnerability list, determine the risk score value of the vulnerability based on the vulnerability risk assessment model, according to the vulnerability rate of the open source code of the open source software component, the CVSS score of the vulnerability, and the existence result of high-risk or critical vulnerabilities.

[0073] A vulnerability list can be obtained by summarizing the component vulnerability lists provided by at least two software component analysis tools, and then removing duplicates from the component vulnerability lists by CVE number.

[0074] For each vulnerability, a risk score is determined based on a vulnerability risk assessment model, taking into account the vulnerability rate of the open-source software component's code, the vulnerability's CVSS score, and the presence of high-risk or critical vulnerabilities. Specifically, the vulnerability risk assessment model can be a supervised learning regression model, such as Gradient Boosting Decision Tree (GBDT), Random Forest, or Neural Network. It takes a multi-dimensional feature vector of the open-source software component's code vulnerability rate, the vulnerability's CVSS score, and the presence of high-risk or critical vulnerabilities as input, and outputs the vulnerability's risk score. Alternatively, the vulnerability risk assessment model can be a mathematical model with predefined weights and calculation rules, directly calculating the vulnerability's risk score from the input security risk data using a pre-defined formula.

[0075] In some embodiments, optionally, determining the risk score of a vulnerability based on the open-source code vulnerability rate of the open-source software component, the CVSS score of the vulnerability, and the existence result of high-risk or critical vulnerabilities includes: determining a first score based on the CVSS score of the vulnerability; determining a second score based on the existence result of high-risk or critical vulnerabilities; determining a third score based on the open-source code vulnerability rate of the open-source software component; and determining the risk score of the vulnerability based on the first score, the second score, and the third score.

[0076] Specifically, the CVSS score of a vulnerability can be determined based on a pre-defined CVSS score range, and the first score value can then be determined accordingly. For example, if the vulnerability's CVSS score corresponds to a high level, the first score value is set at 10 points; if the vulnerability's CVSS score corresponds to a medium level, the first score value is set at 5 points; and if the vulnerability's CVSS score corresponds to a low level, the first score value is set at 2 points.

[0077] Alternatively, the first score can be determined by performing a linear transformation on the CVSS score, or the CVSS score can be directly used as the first score.

[0078] The second score can be determined by Boolean mapping to whether the vulnerability is high-risk or critical. For example, if the vulnerability is high-risk or critical, the second score is set to 10 points; if the vulnerability is not high-risk or critical, the second score is set to 0 points.

[0079] The third score can be determined by using a threshold-based method to classify the vulnerability rate of open-source code. For example, if the number of original vulnerabilities is ≤5 and the vulnerability rate per thousand lines is ≤10‰, it is classified as a low-risk level, with a third score of 2 points; if the number of original vulnerabilities is ≤20 and the vulnerability rate per thousand lines is ≤40‰, it is classified as a medium-risk level, with a third score of 5 points; if the number of original vulnerabilities is >20 or the vulnerability rate per thousand lines is >40‰, it is classified as a high-risk level, with a third score of 10 points.

[0080] Finally, the first, second, and third scores are weighted and summed to determine the vulnerability's risk score. For example, the vulnerability risk score = first score * 80% + second score * 15% + third score * 5%. The weights can be adjusted based on the actual application scenario.

[0081] S340. Sort the risk scores of each vulnerability in descending order, and take the risk score of the first-ranked vulnerability as the vulnerability risk score.

[0082] If an open-source software component contains only one vulnerability, the risk score of that vulnerability will be used as the vulnerability risk score of the open-source software component. If an open-source software component contains two or more vulnerabilities, the highest risk score among the vulnerabilities will be used as the vulnerability risk score of the open-source software component. Alternatively, the average risk score of all vulnerabilities can be used as the vulnerability risk score of the open-source software component.

[0083] S350. Based on the technical reliability evaluation model, the ecological health data is evaluated to obtain a technical reliability score.

[0084] S360. Determine the risk level of the open-source software component based on the vulnerability risk score and the technical reliability score.

[0085] This invention provides a risk assessment method for open-source software components. This method achieves a comprehensive and automated assessment of component vulnerability risks by comprehensively scoring multiple key risk indicators, thereby significantly improving the accuracy of overall security protection.

[0086] Example 4 Figure 4 This is a flowchart illustrating a risk assessment method for open-source software components provided in Embodiment 4 of this application. This embodiment is an optimization based on the above embodiments, specifically optimizing the execution process of the technical reliability evaluation model. Figure 4 As shown, the steps include the following.

[0087] S410. Obtain multidimensional data of open-source software components; wherein, the multidimensional data includes component attributes, security risk data and ecosystem health data, and the ecosystem health data includes at least component maturity, historical failure rate, product activity, open-source community reliability, open-source community activity and service support.

[0088] Component maturity refers to the survival time of an open-source software component since its creation. The longer the survival time, the higher the self-recovery ability of the open-source software component to resist internal or external interference.

[0089] Specifically, the component maturity can be calculated by comparing the latest version time and the first version time provided by at least two software component analysis tools, taking the earliest and latest times respectively, calculating the number of months the component is still alive, and then calculating the component maturity.

[0090] Component maturity = (survival months / 36) * 100%.

[0091] Historical failure rate refers to the number of vulnerabilities that have been exposed in the history of open-source software components.

[0092] Specifically, the historical vulnerability lists of components provided by at least two software component analysis tools can be summarized, and then the number of historical vulnerabilities can be counted after deduplication of the historical vulnerability lists by CVE number. Finally, the historical failure rate can be calculated.

[0093] Historical failure rate = (number of historical vulnerabilities / 50) * 100%.

[0094] Product activity refers to the frequency of version updates for open-source software components.

[0095] Specifically, product activity can be calculated by summarizing the list of versions of open-source software components released in the past 12 months from at least two software component analysis tools, and then counting the number of versions after deduplication based on the version number.

[0096] Product activity level = (number of versions released in the past 12 months / 30) * 100%.

[0097] Open source community reliability refers to the evaluation based on whether open source software components originate from official repositories or mainstream open source communities. Official repositories and mainstream open source communities for various programming languages ​​include: GitHub, Gitee, Maven Central, Google repositories, Gradle repositories, Spring repositories, JBoss repositories, UQBar repositories, Hortonworks repositories, Clojars repositories, Conan official repository, NuGet official repository, Golang official repository, npm official repository, PyPI official repository, etc. If the source is an official repository or mainstream open source community, the open source community's reliability is high; if it originates from other communities or websites, the open source community's reliability is low.

[0098] Specifically, the reliability of the open-source software component can be determined by comparing the sources of open-source software components provided by at least two software component analysis tools and taking the lowest value.

[0099] Open source community activity refers to the activity level of an open source software component in the open source community over the past 12 months, including the total number of commits, the total number of contributors, and the total number of versions.

[0100] Specifically, open-source community activity = total number of commits + total number of contributors + total number of versions.

[0101] Service support refers to the average time for issues to be resolved and the average time for pull requests to be closed for open-source software components.

[0102] Specifically, service support = average issue resolution time + average PR closure time; average issue resolution time (MTTR) = total resolution time / number of issues, where total resolution time refers to the total time from issue creation to closure; average PR closure time = total PR closure time / number of PRs, where total PR closure time is the sum of PR closure time and creation time.

[0103] S420. Based on the license risk assessment model, the component attributes are evaluated to obtain the evaluation results.

[0104] S430. If the assessment result is passed, the security risk data is evaluated based on the vulnerability risk assessment model to obtain a vulnerability risk score.

[0105] S440. Determine the technical stability score based on the component maturity, the historical failure rate, and the product activity level.

[0106] In this application, a technical reliability evaluation model can be used to calculate a technical stability score based on component maturity, historical failure rate, and product activity. The technical reliability evaluation model can be a supervised learning regression model, such as Gradient Boosting Decision Tree (GBDT), Random Forest, or Neural Network, which takes multi-dimensional feature vectors of component maturity, historical failure rate, and product activity as input and outputs a predicted technical stability score. Alternatively, the technical reliability evaluation model can be a mathematical model with predefined weights and calculation rules, which directly calculates the input component maturity, historical failure rate, and product activity into a quantified technical stability score using a pre-determined formula.

[0107] In some embodiments, optionally, determining the technical stability score based on the component maturity, the historical failure rate, and the product activity level includes: determining a fourth score based on the component maturity; determining a fifth score based on the historical failure rate; determining a sixth score based on the product activity level; and determining the technical stability score based on the fourth score, the fifth score, and the sixth score.

[0108] Specifically, based on the pre-defined maturity levels, the maturity level corresponding to the component's maturity can be determined, and then the fourth score value can be determined based on the maturity level. For example, if the component maturity is ≤10%, it corresponds to a low maturity level, and its fourth score value is 15 points; if the component maturity is 10% < and ≤40%, it corresponds to a medium maturity level, and its fourth score value is 7 points; if the component maturity is >40%, it corresponds to a low maturity level, and its fourth score value is 3 points.

[0109] A fourth score can also be obtained by linearly transforming the component maturity level.

[0110] The fifth score can be determined based on the pre-defined failure rate levels, which correspond to the historical failure rate level. For example, if 50% < historical failure rate, it corresponds to a high failure rate level, and its fifth score is 15 points; if 10% < historical failure rate ≤ 50%, it corresponds to a medium failure rate level, and its fifth score is 7 points; if historical failure rate ≤ 10%, it corresponds to a low failure rate level, and its fifth score is 3 points.

[0111] A fifth score can also be obtained by linearly transforming the historical failure rate.

[0112] The sixth score is determined based on the pre-defined product activity levels, which correspond to the activity level of the product. For example, if the product activity level is ≤10%, it corresponds to a low activity level, and its sixth score is 20 points; if the product activity level is 10% < ≤60%, it corresponds to a medium activity level, and its sixth score is 10 points; if the product activity level is >60%, it corresponds to a high activity level, and its sixth score is 3 points.

[0113] A sixth score can also be obtained by linearly transforming the product activity level.

[0114] Finally, the fourth, fifth, and sixth scores are weighted and summed to determine the technical stability score. For example, the technical stability score = fourth score * 15% + fifth score * 15% + sixth score * 20%. The weights can be adjusted according to the actual application scenario.

[0115] S450. Determine the service support score based on the reliability of the open source community, the activity level of the open source community, and the service support level.

[0116] In this application, a technical reliability evaluation model can be used to calculate a technical stability score based on the reliability, activity, and service support of the open-source community. The technical reliability evaluation model can be a supervised learning regression model, such as Gradient Boosting Decision Tree (GBDT), Random Forest, or Neural Network, which takes a multi-dimensional feature vector of open-source community reliability, activity, and service support as input and outputs a predicted service support score. Alternatively, the technical reliability evaluation model can be a mathematical model with predefined weights and calculation rules, which directly calculates the input open-source community reliability, activity, and service support into a quantified service support score using a pre-determined formula.

[0117] In some embodiments, optionally, determining the service support score based on the reliability of the open source community, the activity level of the open source community, and the service support level includes: determining a seventh score based on the reliability of the open source community; determining an eighth score based on the activity level of the open source community; determining a ninth score based on the service support level; and determining a technical stability score based on the seventh score, the eighth score, and the ninth score.

[0118] Specifically, the reliability of an open-source community can be determined by whether the open-source software component originates from an official repository or a mainstream open-source community, thus determining the seventh score. For example, if the open-source software component originates from an official repository or a mainstream open-source community, the open-source community has high reliability and its seventh score is 3 points; if the open-source software component originates from channels other than official repositories or mainstream open-source communities, the open-source community has low reliability and its seventh score is 20 points.

[0119] The eighth score is determined based on a pre-defined open-source community activity level. For example, an open-source community activity level ≤ 20 corresponds to a low open-source community activity level, with an eighth score of 15; an open-source community activity level ≤ 60 corresponds to a medium open-source community activity level, with an eighth score of 7; and an open-source community activity level > 60 corresponds to a high open-source community activity level, with an eighth score of 3.

[0120] An eighth score can also be obtained by linearly transforming the activity level of the open-source community.

[0121] The ninth score is determined based on the pre-defined support levels, which correspond to the level of service support. For example, if service support is greater than 500 hours, it corresponds to a low support level, and the ninth score is 15 points; if service support is less than 50 hours and less than or equal to 500 hours, it corresponds to a medium support level, and the ninth score is 7 points; if service support is less than or equal to 50 hours, it corresponds to a high support level, and the ninth score is 3 points.

[0122] The ninth rating can also be obtained by linearly transforming the service support level.

[0123] Finally, the seventh, eighth, and ninth scores are weighted and summed to determine the technical stability score. For example, the technical stability score = seventh score * 20% + eighth score * 15% + ninth score * 15%. The weights can be adjusted according to the actual application scenario.

[0124] S460. Determine the technical reliability score based on the technical stability score and the service support score.

[0125] Specifically, the technical stability score and the service support score can be directly added together or weighted and summed to determine the technical reliability score. For example, the technical reliability score = technical stability score + service support score.

[0126] S470. Determine the risk level of the open-source software component based on the vulnerability risk score and the technical reliability score.

[0127] This invention provides a risk assessment method for open-source software components. By quantitatively evaluating and integrating technical stability and community service support, this method achieves an objective and comprehensive assessment of the long-term reliability of open-source components. It effectively helps to identify and avoid long-term operational risks caused by project stagnation or an unhealthy community, thereby improving the scientific nature and sustainability of component selection.

[0128] Based on the above embodiments, optionally, after determining the risk level of the open-source software component according to the vulnerability risk score and the technical reliability score, the method further includes: if the risk level is lower than or equal to a preset level, then the open-source software component is included in a whitelist reserve list; in response to the entry review result of the whitelist reserve list, the open-source software component is included in a preset list; wherein, the preset list includes a whitelist, a graylist, and a blacklist.

[0129] In this application, risk levels can be categorized from highest to lowest as critical defects, high-risk defects, medium-risk defects, and low-risk defects. The preset levels can be determined based on actual scenario needs. For example, if the preset level is high-risk defect, then open-source software components with risk levels of high-risk, medium-risk, and low-risk defects will be included in the whitelist reserve list.

[0130] The Technical Committee regularly reviews the whitelist reserve and provides feedback on the review results. Based on the feedback, it determines whether to include open-source software components in the whitelist, graylist, or blacklist. The whitelist refers to a list of available open-source software components, the graylist refers to a list of open-source software components that can be used under certain conditions, and the blacklist refers to a list of prohibited open-source software components.

[0131] The advantage of the above technical solution is that by establishing a reserve list and a secondary review mechanism, it achieves refined control over low- and medium-risk components, avoids a one-size-fits-all approach while ensuring safe access, and provides a compliant use channel for some qualified components, thereby balancing safety control and R&D efficiency.

[0132] Based on the above embodiments, Figure 5 This is a flowchart illustrating the full lifecycle risk assessment of an open-source software component, as provided in Embodiment 4 of this application. Figure 5 As shown, this flowchart illustrates the full lifecycle risk management process for enterprise-level open-source software components, aiming to achieve hierarchical and classified control of introduced components through automated screening and manual auditing.

[0133] The first step is pre-entry filtering. The process begins with scanning components, first verifying the legitimacy of the component license through OSI / FSS certification; non-compliant components are directly blocked from entering the database. Next, the infectivity of the components is checked; components with strong infectivity are also blocked, and only components with weak infectivity or lenient licenses can proceed to the next stage.

[0134] Secondly, there is the core risk assessment. Components that pass the initial screening enter the in-depth analysis stage, where the system comprehensively collects multi-dimensional data for calculation: on the one hand, it assesses vulnerability risks based on CVSS scores, code vulnerability rates, etc.; on the other hand, it assesses ecosystem health and technical reliability based on component maturity, historical failure rate, community activity, etc.

[0135] The next step is tiered classification and handling. After the assessment is completed, if the model calculates a severe result, the component is directly added to the blacklist and disabled; if the result is high-risk, medium-risk, or low-risk, a whitelist reserve list is generated as candidate components awaiting manual intervention.

[0136] Finally, there is the manual final review and closure process. Components in the whitelist reserve list need to be submitted to the technical committee for review. The committee conducts a final review based on the business scenario. If the review is passed, they are included in the whitelist and officially available; if specific restrictions are found, they are included in the gray list for conditional use; if the review is not passed, they are added to the blacklist and disabled.

[0137] The above technical solution effectively overcomes the shortcomings of the existing technology and produces the following technical effects: 1. It solves the problem of a single assessment dimension. By assessing multiple dimensions such as licenses, vulnerabilities, and technical reliability, it comprehensively covers the key security risks of components, resulting in more comprehensive and accurate assessment results; 2. Resolved the issue of inconsistent standards. Established a unified scoring framework, weight allocation, and scoring rules, enabling the comparability of evaluation results across different scenarios and components, and demonstrating strong universality; 3. Resolved the issue of non-standard processes. By incorporating a license risk model as a pre-screening item, high-risk components are identified in advance, the assessment process is standardized, and high-risk components are prevented from entering the usage stage. 4. It solves the problem of inability to quantify and assess risks. Through clear quantitative scoring rules and comprehensive score calculation methods, it enables the quantitative scoring and classification of component risks, accurately reflecting the degree of component risk and providing a scientific and accurate basis for enterprise component warehousing review and supply chain security management; 5. Improved risk management efficiency. Automated data collection, scoring calculation, and rating determination reduce manual intervention and improve assessment efficiency. A dynamic update mechanism ensures the timeliness of assessment results. 6. Reduce enterprise security and compliance risks. It can effectively identify high-risk open-source components, helping enterprises avoid security incidents and compliance penalties caused by the use of non-compliant or high-risk components, and ensuring system stability and compliance.

[0138] Example 5 Figure 6 This is a schematic diagram of the structure of a risk assessment device for an open-source software component provided in Embodiment 5 of this application. Figure 6 As shown, the device includes: The multidimensional data acquisition module 510 is used to acquire multidimensional data of open-source software components; wherein, the multidimensional data includes component attributes, security risk data, and ecosystem health data; The component attribute evaluation module 520 is used to evaluate the component attributes based on the license risk assessment model and obtain the evaluation results; The risk and reliability assessment module 530 is used to evaluate the security risk data based on the vulnerability risk assessment model and obtain a vulnerability risk score if the assessment result is passed, and to evaluate the ecological health data based on the technical reliability assessment model and obtain a technical reliability score. The risk level determination module 540 is used to determine the risk level of the open-source software component based on the vulnerability risk score and the technical reliability score.

[0139] This invention provides a risk assessment device for open-source software components. This device acquires multi-dimensional data, including component attributes, security risk data, and ecosystem health data, of the open-source software components. It then evaluates the component attributes based on a license risk assessment model to obtain an assessment result. If the assessment result is satisfactory, it evaluates the security risk data based on a vulnerability risk assessment model to obtain a vulnerability risk score, and evaluates the ecosystem health data based on a technical reliability assessment model to obtain a technical reliability score. Finally, it determines the risk level of the open-source software component based on the vulnerability risk score and the technical reliability score. This technical solution uses a license risk assessment model as a pre-review item, combined with a vulnerability risk assessment model and a technical reliability assessment model, to systematically and quantitatively assess the risks of open-source software components, providing a scientific and accurate basis for enterprise component inclusion review and supply chain security management.

[0140] Furthermore, the component attributes include at least the license authentication type and the infection type; The component attribute evaluation module 520 includes: The license certification type assessment unit is used to determine, based on the license risk assessment model, whether the license certification type has been certified by a preset license certification system; The infection type assessment unit is used to determine that the assessment result is unsuccessful if the license certification type is determined to be uncertified by a preset license certification system, and to determine whether the infection type is a preset type if the license certification type is determined to be certified by a preset license certification system. The component attribute evaluation unit is configured to determine the evaluation result as passed if the infection type is determined to be a preset type, and to determine the evaluation result as failed if the infection type is determined to be a preset type.

[0141] Furthermore, the security risk data includes at least CVSS scores, open-source code vulnerability rates, and the existence of high-risk or critical vulnerabilities. The risk and reliability assessment module 530 includes: The vulnerability risk assessment unit is used to obtain a vulnerability list of the open source software component, and for each vulnerability in the vulnerability list, based on the vulnerability risk assessment model, according to the vulnerability rate of the open source code of the open source software component, the CVSS score of the vulnerability, and the existence of high-risk or critical vulnerabilities, to determine the risk score value of the vulnerability. The component risk assessment unit is used to sort the risk scores of each vulnerability in descending order, and take the risk score of the first-ranked vulnerability as the vulnerability risk score.

[0142] Furthermore, the vulnerability risk assessment unit includes: The CVSS scoring evaluation subunit is used to determine a first score value based on the CVSS score of the vulnerability. The high-risk or critical vulnerability assessment subunit is used to determine a second score value based on the existence of the high-risk or critical vulnerability. The open-source code evaluation subunit is used to determine a third score value based on the open-source code vulnerability rate of the open-source software component. The vulnerability risk assessment subunit is used to determine the risk score of the vulnerability based on the first score, the second score, and the third score.

[0143] Furthermore, the ecological health data includes at least component maturity, historical failure rate, product activity, open source community reliability, open source community activity and service support. The risk and reliability assessment module 530 includes: The technology stability assessment unit is used to determine a technology stability score based on the component maturity, the historical failure rate, and the product activity level. The service support evaluation unit is used to determine the service support score based on the reliability of the open source community, the activity level of the open source community, and the service support level. The technical reliability assessment unit is used to determine the technical reliability score based on the technical stability score and the service support score.

[0144] Furthermore, the technical stability assessment unit includes: The component maturity assessment subunit is used to determine a fourth score value based on the component maturity. The historical failure rate assessment subunit is used to determine the fifth score value based on the historical failure rate. The product activity assessment subunit is used to determine the sixth score value based on the product activity. The technology stability assessment subunit is used to determine the technology stability score based on the fourth score, the fifth score, and the sixth score. The service support evaluation unit includes: The open-source community reliability assessment subunit is used to determine the seventh score value based on the reliability of the open-source community. The open-source community activity evaluation subunit is used to determine the eighth score value based on the open-source community activity. The service support assessment subunit is used to determine the ninth score value based on the service support. The service support evaluation subunit is used to determine the technical stability score based on the seventh score, the eighth score, and the ninth score.

[0145] Furthermore, the device also includes: The risk level assessment module is used to determine the risk level of the open source software component based on the vulnerability risk score and the technical reliability score. If the risk level is lower than or equal to a preset level, the open source software component is included in the whitelist reserve list. The component inclusion module is used to include the open-source software component into a preset list in response to the inclusion review result of the whitelist reserve list; wherein the preset list includes a whitelist, a graylist and a blacklist.

[0146] The risk assessment device for open-source software components provided in the embodiments of the present invention can execute the risk assessment method for open-source software components provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the method execution.

[0147] Example 6 Figure 7A schematic diagram of the structure of a device 10 that can be used to implement embodiments of this application is shown. The device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (such as helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the application described and / or claimed herein.

[0148] like Figure 7 As shown, device 10 includes at least one processor 11 and a memory, such as read-only memory (ROM) 12, random access memory (RAM) 13, etc., communicatively connected to at least one processor 11. The memory stores computer programs executable by at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded into the RAM 13 from storage unit 18. The RAM 13 may also store various programs and data required for the operation of device 10. The processor 11, ROM 12, and RAM 13 are interconnected via bus 14. Input / output (I / O) interface 15 is also connected to bus 14.

[0149] Multiple components in device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of monitors, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0150] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as risk assessment methods for open-source software components.

[0151] In some embodiments, the risk assessment method for open-source software components may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the risk assessment method for open-source software components described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the risk assessment method for open-source software components by any other suitable means (e.g., by means of firmware).

[0152] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0153] Computer programs used to implement the methods of this application may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0154] In the context of this application, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium can be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0155] To provide interaction with a user, the systems and techniques described herein can be implemented on a device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0156] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0157] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0158] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication unit 19, or installed from storage unit 18, or installed from ROM 12. When the computer program is executed by processor 11, it performs the functions defined in the methods of the embodiments of the present invention.

[0159] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this application can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this application can be achieved, and this is not limited herein.

[0160] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for risk assessment of open source software components, characterized in that, The method includes: Obtain multidimensional data of open-source software components; wherein, the multidimensional data includes component attributes, security risk data, and ecosystem health data; The component attributes are evaluated based on the license risk assessment model to obtain the evaluation results; If the assessment result is passed, the security risk data is evaluated based on the vulnerability risk assessment model to obtain a vulnerability risk score, and the ecological health data is evaluated based on the technical reliability assessment model to obtain a technical reliability score. The risk level of the open-source software component is determined based on the vulnerability risk score and the technical reliability score.

2. The risk assessment method for open-source software components according to claim 1, characterized in that, The component attributes include at least the license authentication type and the infection type; The component attributes are evaluated based on the license risk assessment model to obtain the evaluation results, including: Based on the license risk assessment model, it is determined whether the license certification type has been certified by a preset license certification system; If it is determined that the license certification type has not been certified by the preset license certification system, then the evaluation result is determined to be unsuccessful; and if it is determined that the license certification type has been certified by the preset license certification system, then it is determined whether the infection type is a preset type. If the infection type is determined to be a preset type, the evaluation result is determined to be passed; if the infection type is determined to be a different type, the evaluation result is determined to be failed.

3. The risk assessment method for open-source software components according to claim 1, characterized in that, The security risk data includes at least CVSS scores, open-source code vulnerability rates, and the existence of high-risk or critical vulnerabilities. The vulnerability risk assessment model is used to evaluate the security risk data and obtain a vulnerability risk score, including: Obtain the vulnerability list of the open source software component, and for each vulnerability in the vulnerability list, determine the risk score value of the vulnerability based on the vulnerability rate of the open source code of the open source software component, the CVSS score of the vulnerability, and the existence result of high-risk or critical vulnerabilities, according to the vulnerability risk assessment model. The risk scores of each vulnerability are sorted in descending order, and the risk score at the top of the list is taken as the vulnerability risk score.

4. The risk assessment method for open-source software components according to claim 3, characterized in that, The step of determining the risk score of a vulnerability based on the open-source code vulnerability rate of the open-source software component, the CVSS score of the vulnerability, and the existence results of high-risk or critical vulnerabilities includes: Based on the CVSS score of the vulnerability, determine the first score value; A second score is determined based on the existence of high-risk or critical vulnerabilities. The third score is determined based on the vulnerability rate of the open-source code of the aforementioned open-source software component; The risk score of the vulnerability is determined based on the first score, the second score, and the third score.

5. The risk assessment method for open-source software components according to claim 1, characterized in that, The ecological health data includes at least component maturity, historical failure rate, product activity, open source community reliability, open source community activity and service support. The technology reliability evaluation model is used to evaluate the ecological health data and obtain a technology reliability score, including: The technical stability score is determined based on the component maturity, the historical failure rate, and the product activity level. The service support score is determined based on the reliability of the open source community, the activity level of the open source community, and the service support level. The technical reliability score is determined based on the technical stability score and the service support score.

6. The risk assessment method for open-source software components according to claim 5, characterized in that, The process of determining a technology stability score based on the component maturity, the historical failure rate, and the product activity level includes: A fourth score is determined based on the maturity level of the components. The fifth score is determined based on the historical failure rate. The sixth score value is determined based on the product activity level. The technical stability score is determined based on the fourth score, the fifth score, and the sixth score. The process of determining a service support score based on the reliability of the open-source community, the activity level of the open-source community, and the service support level includes: Based on the reliability of the open-source community, a seventh rating value was determined; The eighth score value was determined based on the activity level of the open-source community. Based on the service support level, a ninth rating value is determined; The technical stability score is determined based on the seventh score, the eighth score, and the ninth score.

7. The risk assessment method for open-source software components according to claim 1, characterized in that, After determining the risk level of the open-source software component based on the vulnerability risk score and the technical reliability score, the method further includes: If the risk level is lower than or equal to the preset level, the open-source software component will be included in the whitelist reserve list. In response to the review results of the whitelist reserve list, the open-source software component is included in a preset list; wherein the preset list includes a whitelist, a graylist, and a blacklist.

8. A risk assessment device for open-source software components, characterized in that, The device includes: A multidimensional data acquisition module is used to acquire multidimensional data of open-source software components; wherein, the multidimensional data includes component attributes, security risk data, and ecosystem health data; The component attribute evaluation module is used to evaluate the component attributes based on the license risk assessment model and obtain the evaluation results; The risk and reliability assessment module is used to evaluate the security risk data based on the vulnerability risk assessment model and obtain a vulnerability risk score if the assessment result is passed, and to evaluate the ecological health data based on the technical reliability assessment model and obtain a technical reliability score. The risk level determination module is used to determine the risk level of the open-source software component based on the vulnerability risk score and the technical reliability score.

9. An electronic device, characterized in that, The device includes: At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the risk assessment method for the open-source software component of any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, implement the risk assessment method for the open-source software component as described in any one of claims 1-7.

Images