A NET platform open source software supply chain vulnerability scoring method based on dependency detection and open source scoring system

Abstract

The application faces open source software supply chain security and proposes a NET platform open source software supply chain vulnerability scoring method based on dependency detection and open source scoring system, which can solve the problem that the security vulnerability scoring system in the open source.Net software supply chain scene does not consider the upstream and downstream dependency relationship. The method comprises the following steps: 1) dependency detection: using a dependency detection program to obtain upstream and downstream dependency data information of the open source component; 2) open source scoring system: based on the scoring index for the upstream and downstream dependency relationship, an open source scoring system and a scoring formula are proposed. In the application, the dependency detection of the NuGet platform provides a measurement index for judging the influence degree of the upstream and downstream dependency relationship for the open source vulnerability scoring, the open source scoring system can give a more accurate severity score when evaluating the open source component vulnerability, and finally the.Net open source supply chain vulnerability scoring method can effectively improve the objectivity and globality of the severity scoring process of the.Net security vulnerability.

Description

TECHNICAL FIELD

[0001] The application relates to a.Net open source supply chain vulnerability scoring method based on dependency detection and an open source scoring system, which is suitable for vulnerability evaluation of open source industrial components and considers scoring indexes of upstream and downstream dependency relationships in a software supply chain, and improves the globality and objectivity of a security scoring system for vulnerability scoring of open source industrial components. BACKGROUND

[0002] Due to the iteration of information technology and the needs of business development, numerous enterprise teams begin to adopt agile development modes to improve the efficiency of software development, and open source components provide a solid foundation for developers to realize rapid development and technical innovation. With the gradual prosperity of the open source ecology and the rapid rise of the industrial Internet, the security problems of the open source software supply chain are increasingly prominent.

[0003] If an industrial component in the open source ecology has a vulnerability defect, the development team or security personnel needs to perform security evaluation on the component before the defect is repaired, and accurately inform the component users of the degree of harm and the risk range. The two key points in security evaluation are the quantification of risk elements and the identification of defects, which are directly related to the accuracy and objectivity of security evaluation. In the field of information security, the Common Vulnerability Scoring System (CVSS) is the most authoritative industry standard in the scoring method for the severity of software vulnerabilities. After a software vulnerability is published, CVSS will perform specific analysis, and finally obtain a quantitative score, that is, a specific score between 0 and 10. The larger the value, the higher the risk level. CVSS is intuitive, universal and completely open, and its wide application in the industry solves most security vulnerability evaluation problems, but still has some shortcomings.

[0004] The three groups of measurement standards of CVSS can obtain three scores, the base score, the temporal score and the environmental score. Some index factors in the score are defined ambiguously, and the score is too subjective in actual operation. Therefore, most manufacturers in the industry only pay attention to the base score, and pay less attention to the temporal score and the environmental score, which greatly reduces the accuracy and objectivity of the overall evaluation of CVSS on security vulnerabilities or component defects. At the same time, the complexity of the open source ecology and the component dependency relationship of the software supply chain are not considered in the scoring factors of CVSS, and the actual harm of industrial dependency vulnerabilities depends largely on the external exposure degree of the software API, which is closely related to the specific position of the component in the supply chain. The measurement indexes of CVSS for the industrial software supply chain scene are not clear and detailed enough, so it cannot perform comprehensive and effective security evaluation on the industrial component vulnerabilities in the current open source software supply chain.

[0005] In order to solve the above problems, the present application proposes a.Net open source supply chain vulnerability scoring method based on dependency detection and open source scoring system, so as to realize more reasonable and objective comprehensive evaluation of open source component vulnerabilities. The upstream and downstream dependency data of the open source component is obtained by using the NuGet open source platform API and the custom information processing program, and the measurement index for evaluating the influence degree of the upstream and downstream of the supply chain is selected and defined for the method, so that more accurate severity score can be made when the security of the open source industrial component vulnerability is evaluated, and the objectivity of the security vulnerability scoring system is effectively improved. SUMMARY

[0006] The present application is directed to the security evaluation problem of open source vulnerabilities in industrial software supply chain, and proposes a.Net platform open source software supply chain vulnerability scoring method based on dependency detection and open source scoring system. The method is used for security evaluation of industrial component vulnerabilities in the scene of open source software supply chain. Firstly, the upstream and downstream dependency relationship of the open source component in the NuGet open source ecological community is statistically analyzed, and the related index interval is defined. Then, the open source scoring system is constructed based on CVSS, and the scoring index of the dependency relationship factor is included in the open source scoring system. Finally, the open source supply chain vulnerability scoring method is proposed by combining the scoring formula of CVSS and the open source scoring system. The method fully considers the upstream and downstream dependency relationship in the industrial software supply chain, and can give a more reasonable score when evaluating the severity of the open source vulnerability, effectively improving the objectivity of the security vulnerability scoring system.

[0007] In order to achieve the above-mentioned application purposes, the present application is implemented by the following specific technical solutions:

[0008] A.Net open source supply chain vulnerability scoring method based on dependency detection and open source scoring system, characterized by the following steps:

[0009] 1) Dependency detection: using a dependency detection program to obtain upstream and downstream dependency data information and define index interval;

[0010] 2) Open source scoring system: proposing an open source scoring system and scoring formula based on the scoring index of the upstream and downstream dependency relationship.

[0011] The step 1) specifically includes the following steps:

[0012] Step 1.1, realizing the cursor of NuGet directory reader, identifying the time point or time period of processing directory resources;

[0013] Step 1.2, determining the resource link of the directory reader, and performing directory search on the JSON format resource document;

[0014] Step 1.3. In the resource directory identified by the @type attribute, read the next level directory according to the corresponding @id attribute;

[0015] Step 1.4. Process the secondary directory page obtained in step 1.3 to read the name, description, size and dependency information of the corresponding NuGet component;

[0016] Step 1.5. Based on the NuGet component information obtained in step 1.4, data statistics are performed, and related concepts of data results are defined and induced.

[0017] The step 2) specifically comprises the following steps:

[0018] Step 2.1. Re-grade the attack complexity index E ac in the CVSS exploitability score S e , and use it as the basic score index of the open source scoring system, and the remaining basic score indexes follow the CVSS;

[0019] Step 2.2. Re-select the measurement index for the impact score S i , and perform grade division and weight distribution;

[0020] Step 2.3. Obtain the severity score S oc of the vulnerability through the open source scoring system, and the scoring formula of the scoring index group is:

[0021]

[0022] Where the scope scope takes the value of change (C) and unchanged (U), and does not have a specific value. BRIEF DESCRIPTION OF DRAWINGS

[0023] Figure 1(a) is a NuGet component downstream dependency interval distribution statistical graph.

[0024] Figure 1(b) is a NuGet component upstream dependency interval distribution statistical graph.

[0025] Figure 1(c) is a NuGet component average dependency depth interval distribution statistical graph.

[0026] Figure 1(d) is a NuGet component download quantity interval distribution statistical graph.

[0027] Figure 2 The figure is a scoring measurement index of the method of the present application.

[0028] Figure 3(a) is a vulnerability information page of CVE-2022-21167.

[0029] Figure 3(b) is a vulnerability information page of CVE-2022-0749.

[0030] Figure 4 A flowchart of the method of the present application. DETAILED DESCRIPTION

[0031] The present application will be described in detail below with reference to the accompanying drawings and specific examples.

[0032] Reference Figure 4 A NET platform open source software supply chain vulnerability scoring method based on dependency detection and open source scoring system, comprising the following steps:

[0033] 1) Dependency detection: using a dependency detection program to obtain upstream and downstream dependency data information and define an index interval;

[0034] 2) Open source scoring system: based on the scoring indicators for upstream and downstream dependencies, an open source scoring system and scoring formula are proposed.

[0035] The step 1) specifically comprises the following steps:

[0036] Step 1.1, implement a NuGet directory reader cursor to identify the time point or time period for processing directory resources;

[0037] Step 1.2, determine the resource link of the directory reader, and perform directory search on the JSON format resource document;

[0038] Step 1.3, in the resource directory identified by the @type attribute, read the next level directory according to the corresponding @id attribute;

[0039] Step 1.4, process the secondary directory page obtained in step 1.3 to read the name, description, size and dependencies of the corresponding NuGet component, etc.

[0040] Step 1.5, based on the NuGet component information obtained in step 1.4, perform data statistics, and define and induce the interval of the related concepts of the data results.

[0041] Preferably, in step 1.1, the current time point is set as the initial value of the cursor, and the C# program code is shown in Table 1.

[0042] Table 1 NuGet directory reader setting time point code

[0043]

[0044] Preferably, in the step 1.2, NuGet Protocol V3 is selected as the API protocol, the resource library link address is api.nuget.org / v3 / catalog0 / index.json, and the C# program code is shown in Table 2.

[0045] Table 2 NuGet catalog reader determines catalog resource code

[0046]

[0047] Preferably, in the step 1.3, NuGet.CatalogReader is selected as the NuGet component information reading module.

[0048] Preferably, in the step 1.4, the NuGet.CatalogReader is used to search the catalog page mounted by the specified NuGet component @id attribute, obtain the complete upstream and downstream dependency relationship, and output the related data, and the C# program code is shown in Table 3.

[0049] Table 3 NuGet package program dependency information reading code

[0050]

[0051] Further, in the step 1.5, based on the 30341 components with high user activity in the NuGet platform obtained in the step 1.4, the dependency is detected and analyzed, wherein the concept definition and interval induction of the component dependency relationship are as follows:

[0052] (a) Based on the statistics of the downstream dependency degree of the NuGet component

[0053] The downstream dependency degree of the NuGet component represents the degree to which the component is dependent on other NuGet components. The greater the value, the more dependency items depend on the component. The downstream dependency degree largely reflects the degree of influence of the NuGet component on the downstream supply chain. As shown in FIG. 1(a), the distribution of the downstream dependency degree of the NuGet component is shown.

[0054] (b) Based on the statistics of the upstream dependency degree of the NuGet component

[0055] The upstream dependency degree of the NuGet component represents the degree to which the component depends on other NuGet components. The greater the dependency degree, the more dependency items the component has. As shown in FIG. 1(b), the distribution of the upstream dependency degree of the NuGet component is shown.

[0056] According to the upper and lower dependency degrees of the NuGet component, the position of the component in the open source industrial software supply chain can be determined. The data shows that more than 90% of the downstream dependency degrees of the NuGet component are distributed in 10 or less, and in particular, the NuGet component with a downstream dependency degree of 0 accounts for nearly 50% of the total number. Such NuGet components are terminal user-oriented and can be directly used, and can be classified as finished components; the upstream dependency degree is concentrated in 2 or less, and such NuGet components are basically important dependencies of application programs and can be classified as basic components; and the NuGet component with a large upper and lower dependency value can be classified as an intermediate component.

[0057] (c) Statistics based on the dependency depth of the NuGet component

[0058] The downstream dependency degree only reflects the number of dependency items of the next level of a NuGet component, and lacks intuitive measurement of the multi-level dependency relationship of the NuGet component, and the dependency depth can be used as a reference index. Each component has a number of downstream dependency items, and each dependency item may still contain a next level of dependency, where the number of levels of dependency is referred to as the dependency depth. According to the total number of dependency depths of all dependency items and the number of dependency items, the average dependency depth of the NuGet component can be obtained. Figure 1(c) shows the distribution of the average dependency depth of the NuGet component in the statistics, where the maximum value is 8, and the packages with a large dependency depth are mainly finished components downstream. According to the data distribution of the average dependency depth, it can be divided into three groups 0, 1-2 and 3-8, which correspond to the number of levels of downstream dependency items being few, less and high, respectively.

[0059] (d) Statistics based on the download volume of the NuGet component

[0060] As shown in Figure 1(d), the download volume distribution of the NuGet component counts the historical download times of the component, fully reflecting the influence and popularity of the component. According to the download volume statistics, the NuGet component can be divided into three range intervals of low download volume (0-90), high download volume (90-600) and extremely high download volume (more than 600).

[0061] The step 2) specifically comprises the following steps:

[0062] Step 2.1, reclassifying the attack complexity index E e in the CVSS exploitability score S ac as the basic score index of the open source scoring system, and the remaining basic score indexes remain the same as the CVSS;

[0063] Step 2.2, reselecting the measurement index for the impact score S i and performing grade division and weight allocation;

[0064] Step 2.3, obtaining the severity score S of the vulnerability by the open source scoring system oc The scoring formula of the scoring index group is:

[0065]

[0066] Wherein the value of scope is change (C) and unchanged (U), and no specific value is taken.

[0067] Preferably, the CVSS exploitability score S in step 2.1 e The attack complexity index E ac The division of the level is re-performed, and the two grades in CVSS are subdivided into four grades in the open source scoring system, namely low, medium, high and extremely high, according to different models of vulnerability exploitation. The specific grading standards are shown in Table 4. This makes the complexity of exploitation of open source industrial component vulnerabilities more practical and accurate. The attack vector E av , the permission requirement E pr and the user interaction E ui index in the CVSS exploitability are clearly defined and graded, so the open source scoring system continues to use these standards.

[0068] Table 4 Attack complexity grading standards

[0069] Rank Attack complexity description Low L No special conditions are required to achieve the attack expectation Medium M Certain conditions are required, but the conditions are relatively simple High H Certain or multiple conditions are required, and the conditions are relatively strict Extremely high E Conditions are required, and the attack is extremely difficult

[0070] Preferably, the impact score S i of the open source scoring system in step 2.2 is reselected, graded and scored. The impact score S i is considered from two aspects: one aspect is the information technology security ISS sec from the perspective of three elements, including the confidentiality requirement I c , the integrity requirement I i and the availability requirement I a , and the specific grading standards are shown in Table 5; the other aspect is the open source supply chain dependency ISS osd , and the proposed measurement index includes the dependency depth I dd , the component property I nc and the download size I ds . In step 1.5, based on the NuGet platform data analysis, the corresponding concepts are defined and the intervals of the three groups of measurement indexes are divided, and the specific numerical ranges of the three groups of grading are shown in Table 6. The actual vulnerability score can be graded according to the index interval.

[0071] Table 5 Confidentiality requirement, integrity requirement, availability requirement index grading standards

[0072]

[0073]

[0074] Table 6: Dependence depth, component property, download size index grading standards

[0075] Rank Dependency depth Component properties Download size High H There are many levels of downstream dependencies Basic components Extremely high download volume Medium M There are fewer levels of downstream dependencies Intermediate components High download volume Low L There are very few levels of downstream dependencies Finished components Low download volume

[0076] All the metric indicators in the open source scoring system are shown in Table 6, and the corresponding grading values are shown in Table 7. Figure 2

[0077] Table 7: Weight of open source scoring system metric indicators

[0078] Metrics Metrics ranking Weighting sub-grades Attack vector E av ]] [N, A, L, P] [0.85,0.62,0.55,0.2] Attack complexity E ac ]] [L, M, H, E] [0.77,0.61,0.44,0.2] Privilege requirements E pr ]] [N, L, H] [0.85,0.62 / 0.68,0.27 / 0.5] User interaction E ui ]]> [N, R] [0.85,0.62] Scope [U, C] [U, C] Confidentiality requirement I c ]]> [H, L, N] [0.56,0.22,0] Integrity requirement I i ]]> [H, L, N] [0.56,0.22,0] Availability requirement I a ]]> [H, L, N] [0.56,0.22,0] Dependent depth I dd ]]> [H, M, L] [0.56,0.44,0.2] Component properties I nc ]] [H, M, L] [0.96,0.44,0.22] Download size I ds ]] [H, M, L] [0.8,0.4,0.2]

[0079] Further, the weight distribution of the scoring formula in step 2.3 is obtained according to the CVSS scoring system and experimental experience. The Roundup() function in the formula represents rounding up the decimal part of the scoring formula value, for example, the result of Roundup(1.0008) is 1.1, because the minimum scoring unit is 0.1, so the value is retained to one decimal place. In security scoring, it is necessary to avoid the precision problem caused by rounding, that is, to discard the part not greater than 5, which will cause the vulnerability score to be lower than the unrounded score. Therefore, the final score obtained by using the rounding up function is greater than or equal to the unrounded score, and overestimating the severity of the vulnerability is relatively safe.

[0080] The availability score scoring formula is: e S av = 8.22·E ac ·E pr ·E ui

[0081] Where the grading weight of E pr depends on the state of scope. That is, when scope is U, the weight of E pr is taken as [0.85, 0.62, 0.27]; when scope is C, E pr is taken as [0.85, 0.68, 0.5].

[0082] The impact score S i scoring formula is:

[0083]

[0084] Where ISS is a temporary variable in the impact score, which can be obtained from the information technology security score ISS sec and the open source supply chain dependence relationship score ISS osd ​The calculation is as follows. The ISS scoring formula is:

[0085] ISS = 0.6ISS osd + 0.4ISS sec

[0086] ISS osd The calculation formula is as follows:

[0087] ISS osd = 1-[(1-I pv )·(1-I nc )·(1-I ds )]

[0088] ISS sec The calculation formula is as follows:

[0089] ISS sec = 1-[(1-I c )·(1-I i )·(1-I a )]

[0090] From the two indicators of ISS sec and ISS osd , the impact of an open source component vulnerability is evaluated, and when assigning weights, more weight is given to the ISS osd indicator. Therefore, the ISS scoring formula finally assigns a weight of 0.6 to the open source supply chain dependency indicator and a weight of 0.4 to the information technology security indicator.

[0091] Beneficial results

[0092] Take the open source component vulnerabilities CVE-2022-21167 and CVE-2022-0749 of the NuGet platform as examples for vulnerability instance scoring analysis. Their triggering principles and exploitation scenarios are very similar, so the CVSS scores are very close, at 7.5 and 7.4 respectively.

[0093] Figure 3(a) shows the vulnerability information page of CVE-2022-21167, and the vulnerable component is Masuit.Tools.Core.

[0094] Figure 3(b) shows the vulnerability information page of CVE-2022-0749, and the vulnerable component is SinGooCMS.Utility.

[0095] According to the method of the application, two vulnerabilities are re-scored. Based on the data statistics of the NuGet platform, it is known that the Masuit.Tools.Core library is an intermediate component with a download volume of 174.7K, and the average dependency depth is 3 levels; the SinGooCMS.Utility library is a finished product component with a download volume of 2.8K, and the average dependency depth is 0 level. Table 8 lists the actual values of some indicators of the open source scoring system, and the comparison of the vulnerability component scores obtained by the method of the application and the CVSS score is shown in Table 9.

[0096] Table 8 Actual values of scoring indicators

[0097]

[0098] As shown in Table 9, compared with the CVSS score, the application method score of CVE-2022-21167 is improved, and the application method score of CVE-2022-0749 is reduced. Because the risk component Masuit.Tools.Core of CVE-2022-21167 is a high download volume intermediate component, and the vulnerability risk covers all versions; while the download volume of the SinGooCMS.Utility vulnerability component of CVE-2022-0749 is low, the popularity is very low, and the harmfulness is low. From the actual open source industrial software supply chain point of view, the coverage and influence of the Masuit.Tools.Core library should be much higher than that of the SinGooCMS.Utility library. Although the principles of the two vulnerabilities are similar, CVSS only expresses the similar risk characteristics of the two, but the method of the application can more objectively reflect the different severity of the two vulnerabilities in the open source ecology.

[0099] Table 9 Comparison of CVSS and open source supply chain vulnerability scoring method scores

[0100]

Claims

1. A vulnerability scoring method for the .NET platform open-source software supply chain based on dependency detection and open-source scoring system. Its features include the following steps: 1) Dependency detection: Use a dependency detection program to obtain upstream and downstream dependency data and define indicator ranges; 2) Open source scoring system: Based on scoring indicators for upstream and downstream dependencies, an open source scoring system and scoring formula are proposed; Step 2) specifically includes the following steps: Step 2.1: Score the availability of CVSS. Attack complexity metrics The grading system was redefined and used as the basic grading metric for the open-source rating system. The remaining basic grading metrics will be the same as those in CVSS. Step 2.2: Score the impact. Reselect the metrics and assign levels and weights accordingly; Step 2.3: Determine the severity score of the vulnerability using an open-source scoring system. The scoring formula for the scoring indicator group is as follows: ； The scope value can be either changed (C) or unchanged (U), without specifying a particular value; In step 2.3, the scoring formula for the degree score can be used as follows: ; Indicators in the formula This is the attack vector. For attack complexity, Due to access restrictions, For user interaction; The hierarchical weights depend on the state of the scope; that is, when the scope is U, The weights are set to [0.85, 0.62, 0.27]; when the scope is C, Choose [0.85, 0.68, 0.5]; Influence score The scoring formula is: ； in As a temporary variable in the impact score, it is determined by the information technology security score. Dependency score with open source supply chain Calculated; The scoring formula is: ; The calculation formula is: ； The calculation formula is: ； for Assign higher weights; Indicators in the formula For depth-dependent purposes, As a component, To accommodate download volume, For confidentiality requirements, For availability requirements.

2. The vulnerability scoring method for the .NET platform open-source software supply chain based on dependency detection and open-source scoring system as described in claim 1, characterized in that: Step 1) specifically includes the following steps: Step 1.1: Implement a cursor in the NuGet directory reader to mark the time point or time period for processing directory resources; Step 1.2: Determine the resource links of the directory reader and perform a directory search on the resource documents in JSON format; Step 1.3: In the resource directory identified by the @type attribute, read the next level directory according to the corresponding @id attribute; Step 1.4: Process the subdirectory pages obtained in Step 1.3, and read the name, description, size, and dependencies of the corresponding NuGet components; Step 1.5: Perform data statistics based on the NuGet component information obtained in Step 1.4, and define and summarize the relevant concepts of the data results.

3. The vulnerability scoring method for the .NET platform open-source software supply chain based on dependency detection and open-source scoring system as described in claim 2, characterized in that: In step 1.5, based on the 30,341 components with high user activity obtained in step 1.4, dependency detection and analysis are performed. The conceptual definition and interval summary of component dependency relationships are as follows: (a) Statistics based on downstream dependencies of NuGet components The downstream dependency of a NuGet component indicates the degree to which the component is depended on by other NuGet components. The higher the value, the more dependencies that depend on the component. Downstream dependence largely reflects the extent to which NuGet components influence the downstream supply chain; (b) Statistics based on upstream dependencies of NuGet components The upstream dependency of a NuGet component indicates the degree to which the component depends on other NuGet components. The higher the dependency, the more dependencies the component has. The position of a NuGet component in the open-source industrial software supply chain is determined by its upstream and downstream dependencies. Data shows that over 90% of NuGet components have downstream dependencies below 10, with nearly 50% having zero downstream dependencies. These NuGet components are end-user-facing, directly used software and are classified as finished products. Upstream dependencies are concentrated below 2; these NuGet components are generally important dependencies of the application and are classified as basic components. NuGet components with both upstream and downstream dependencies at relatively high values ​​are classified as intermediate components. (c) Statistics based on NuGet component dependency depth Downstream dependency only reflects the distribution of the number of dependencies of a NuGet component at the next level, but lacks an intuitive measure of the multi-level dependency relationship of the NuGet component. Dependency depth serves as a reference indicator. Each component has several downstream dependencies, and each dependency contains a next-level dependency. The number of dependency levels is called the dependency depth. The average dependency depth of the NuGet component is calculated based on the total dependency depth of all dependencies and the number of dependencies. Based on the data distribution of the average dependency depth, it is divided into three groups: 0, 1~2, and 3~8, corresponding to the three cases of very few, few, and high number of downstream dependency levels, respectively. (d) Statistics on NuGet component downloads Based on download statistics, NuGet components are divided into three ranges: low download volume, high download volume, and extremely high download volume; low download volume: 0~90, high download volume: 90~600, and extremely high download volume: greater than 600.

4. The vulnerability scoring method for the .NET platform open-source software supply chain based on dependency detection and open-source scoring system as described in claim 1, characterized in that: In step 2.1, the availability of CVSS is scored. Attack complexity metrics The rating system has been reclassified, and the two levels in CVSS have been subdivided into four levels in the open source rating system based on different vulnerability exploitation models: low, medium, high and very high. The specific rating criteria are shown in Table 1. Table 1 Attack Complexity Classification Standards 。 5. The vulnerability scoring method for the .NET platform open-source software supply chain based on dependency detection and open-source scoring system as described in claim 1, characterized in that: In step 2.2, the impact score of the open-source scoring system is calculated. Reselect the metrics and assign levels and scores; impact score. Consider it from two aspects: one is information technology security. From the perspective of the three elements, including confidentiality requirements Integrity requirements and availability requirements The specific grading criteria are shown in Table 2; on the other hand, there is the dependency relationship of the open source supply chain. From this perspective, the proposed metrics depend on depth. Component properties and download scale In step 1.5, based on data analysis of the NuGet platform, corresponding concepts were defined and three sets of measurement index ranges were divided. The specific numerical ranges of the three levels are shown in Table 3. The actual vulnerability scoring is based on the classification of the index ranges. At the same time, the classification values ​​of all measurement indexes in the open source scoring system are shown in Table 4. Table 2. Classification Standards for Confidentiality Requirements, Integrity Requirements, and Availability Requirements Table 3. Grading Standards for Dependency Depth, Component Nature, and Download Size Indicators Table 4 Weights of Metrics in the Open Source Scoring System 。

Images