Open source component selection method and system

Abstract

The invention discloses an open source component selection method and system. The method comprises the steps of obtaining a code file of a target open source component; counting the number of functional modules in the code file to obtain a first module number; counting the number of complex modules in the functional modules to obtain a second module number; calculating a ratio of the second module number to the first module number to obtain a first parameter; counting the number of overlong modules in the function modules to obtain a third module number; calculating the ratio of the third module number to the first module number to obtain a second parameter; fitting a first evaluation parameter based on the first parameter and the second parameter; and selecting the target open source component based on the first evaluation parameter. The method is beneficial to objectively evaluating the code quality of the open source component. Complex modules and overlong modules often mean that codes are poor in readability and maintainability, so that the parameters can comprehensively reflect the code quality level of open source components.

Description

Technical Field

[0001] The present invention relates to the technical field of software system development, and in particular to an open source component selection method and system for selecting open source components in a software system development process. Background Art

[0002] In modern software development, the use of open source components is becoming increasingly popular because they can significantly improve development efficiency and reduce costs. However, the security issues of open source components have gradually attracted widespread attention. With the widespread use of open source software, various security vulnerabilities are constantly being discovered and disclosed, which brings potential risks to software development. Therefore, when developers select open source components, they need to comprehensively consider their security performance to avoid serious consequences such as system vulnerabilities and data leaks caused by security risks.

[0003] Currently, the evaluation of open source components usually relies on static analysis tools and vulnerability databases. However, these methods often have problems such as incomplete evaluation and lack of real-time performance, and cannot effectively reflect the security status of open source components in actual use. Summary of the invention

[0004] The object of the present invention is to provide an open source component selection method and system which can select open source components based on the code conditions of the open source components.

[0005] In order to achieve the above object, the present invention provides an open source component selection method, which includes:

[0006] Obtain the code files of the target open source components;

[0007] Counting the number of functional modules in the code file to obtain a first module number;

[0008] Counting the number of complex modules in the functional module to obtain a second number of modules, wherein the cyclomatic complexity of the complex modules is greater than a preset first threshold;

[0009] Calculating a ratio of the second number of modules to the first number of modules to obtain a first parameter;

[0010] Counting the number of overlong modules in the functional module to obtain a third module number, wherein the number of code lines in the overlong module is greater than a preset second threshold or the weighted number of code lines is greater than a preset third threshold;

[0011] Calculating a ratio of the third number of modules to the first number of modules to obtain a second parameter;

[0012] Fitting a first evaluation parameter based on the first parameter and the second parameter;

[0013] The target open source component is selected based on the first evaluation parameter

[0014] Preferably, the first evaluation parameter S is fitted based on the following formula: M :

[0015]

[0016] Among them, CP is the first parameter, and LP is the second parameter.

[0017] Preferably, vulnerability information corresponding to the target open source component is also obtained from an open source vulnerability database, wherein the vulnerability information includes vulnerability type, vulnerability release date, and vulnerability score given by a vulnerability scoring system;

[0018] Obtaining the average daily download volume and average daily release volume of the target open source component within a specified time period from a public open source service platform;

[0019] Generate a third parameter based on the average daily download volume and the average daily release volume;

[0020] Generate a fourth parameter based on the number of days from the vulnerability release date to the present and the vulnerability score of each vulnerability;

[0021] Generate a second evaluation parameter representing a safety factor based on the third parameter and the fourth parameter;

[0022] The target open source component is selected based on the first evaluation parameter and the second evaluation parameter.

[0023] Preferably, the third parameter S1 is fitted based on the following formula:

[0024]

[0025] Among them, USE_c represents the average daily download volume, and REL_c represents the average daily release volume.

[0026] Preferably, the fourth parameter S2 is fitted based on the following formula:

[0027]

[0028] Among them, e is a natural constant, CVSS i represents the vulnerability score of the i-th vulnerability in the target open source component, Time i It represents the number of days from the release date of the i-th vulnerability in the target open source component to the present time, and T represents the statistical duration.

[0029] Preferably, the second evaluation parameter S is fitted based on the following formula: s :

[0030]

[0031] Wherein, a and b are preset adjustment constants, 1.5≤a≤2, 1<b<1.5.

[0032] Preferably, vulnerability information corresponding to the target open source component is obtained from an open source vulnerability database, the vulnerability information including vulnerability type and vulnerability release date; vulnerability repair status information of the vulnerability in the target open source component is obtained from an open source community platform, and a third evaluation parameter representing the vulnerability response situation is fitted according to the vulnerability repair status information and the corresponding vulnerability release date; and the target open source component is selected in combination with the first evaluation parameter and the third evaluation parameter.

[0033] Preferably, the following four response states are set for evaluating vulnerability response status:

[0034] Waiting for response: the vulnerability is not fixed and Δt1<δ1;

[0035] No response: the vulnerability is not fixed and Δt1≥δ1;

[0036] Slow response: the vulnerability has been fixed and Δt2≥δ2;

[0037] Fast response: the vulnerability has been fixed and Δt2<δ2;

[0038] Wherein, Δt1 is the time interval between the release date of the vulnerability and the current statistical date;

[0039] Δt2 is the time interval between the release date of the vulnerability and the completion date of the vulnerability repair;

[0040] δ1 and δ2 are two preset time thresholds;

[0041] According to the vulnerability repair status information and the vulnerability release date, for each vulnerability, a corresponding response status is matched;

[0042] creating a fifth parameter related to a response speed of the vulnerabilities in the open source component based on the response status of all the vulnerabilities in the open source component;

[0043] Calculating the ratio of the number of vulnerabilities in the open source component that are in the slow response state and the fast response state to the total number of vulnerabilities to obtain a vulnerability response ratio;

[0044] The third evaluation parameter is obtained based on a product of the fifth parameter and the vulnerability response ratio.

[0045] Preferably, the fifth parameter CoV is created based on the following formula:

[0046] CoV=∑W i×A i

[0047]

[0048] Among them, W i represents the weight assigned to each of the response states, A i Indicates the proportion of any of the response states in all the response states, B i Indicates the number of any of the response statuses.

[0049] Preferably, the number of occurrences of participation events of the target open source component is also obtained from the open source community platform, wherein the participation events include behavioral events in which multiple users participate and are related to the target open source component;

[0050] The participation events include at least two or more of the initiated issues, issue comments, initiated pull requests, pull request comments, and merged pull requests related to the target open source component, and each type of the participation events includes a number of event items that occur at different times;

[0051] Creating a fourth evaluation parameter representing the activity of the target open source component based on the number of occurrences of the participation event;

[0052] The target open source component is selected based on the first evaluation parameter and the fourth evaluation parameter.

[0053] Preferably, the method for generating the fourth evaluation parameter includes:

[0054] Assign a proportional weight to each type of engagement event, and the sum of the proportional weights of all engagement events of all types is 100%;

[0055] For a plurality of the event items in any type of the participating event, based on a time function, a time weight is configured for each of the event items according to the occurrence time of each of the event items;

[0056] The activity level AL of any of the above mentioned participation events is calculated based on the following formula i :

[0057] AL i =W i ×∑Q n

[0058] Among them, W i is the proportion weight of the participating event, Q n is the time weight of any event item in the participating event;

[0059] The fourth evaluation parameter SCA representing the community activity of the target open source component is calculated based on the following formula:

[0060]

[0061] Preferably, based on the following formula combined with the time weight Q of any event item in the participating event n :

[0062]

[0063] Wherein, e is a natural constant, T is the statistical duration, t is a preset time constant, and Δt is the number of days after the behavioral event of the event item occurs.

[0064] Preferably, the community size of the target open source component is also obtained from the open source community platform, and a fifth evaluation parameter is generated based on the community size; proportional weights are configured for the fifth evaluation parameter and the fourth evaluation parameter, and the sum of the proportional weights of the fifth evaluation parameter and the fourth evaluation parameter is 100%; and the target open source component is selected based on the first evaluation parameter, the fourth evaluation parameter and the fifth evaluation parameter.

[0065] Preferably, the method for generating the fifth evaluation parameter includes:

[0066] Obtaining indicator parameters related to the community size of the target open source component from an open source community platform, wherein the indicator parameters include the number of contributors, the number of followers, the number of event activities, and the number of discussions;

[0067] The number of contributors represents the number of people who participated in the development of the target open source component;

[0068] The number of followers represents the number of users who are interested in the target open source component;

[0069] The number of event activities represents the number of times the user interacts with the target open source component;

[0070] The number of discussions represents the number of posts issued by users to discuss the target open source component;

[0071] According to the importance relationship between the various indicator parameters, a proportional weight is configured for each of the indicator parameters, and the sum of the proportional weights of the various indicator parameters is 100%;

[0072] The fifth evaluation parameter SCZ is calculated based on the following formula:

[0073] SCZ=∑Y i ×N i

[0074] Among them, Y i Represents the proportional weight of any of the indicator parameters, N iIndicates the number of any of the index parameters.

[0075] Preferably, the importance relationship between the various indicator parameters is adjusted and confirmed based on a judgment matrix.

[0076] The present invention also provides an open source component selection system, which includes an evaluation parameter generator, wherein the evaluation parameter generator generates evaluation parameters for evaluating a target open source component based on the open source component selection method as described above.

[0077] The present invention also provides an open source component selection system, which includes:

[0078] one or more processors;

[0079] Memory;

[0080] and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, and the programs include instructions for executing the open source component selection method as described above.

[0081] The present invention also provides a computer-readable storage medium, characterized in that it includes a computer program, and the computer program can be executed by a processor to complete the open source component selection method as described above.

[0082] Compared with the prior art, the open source component selection method disclosed in the above technical solution of the present invention counts the number of complex modules and overlong modules in the code file and calculates the ratio of the number of complex modules and overlong modules to the total number of modules as an evaluation parameter, which is conducive to objectively evaluating the code quality of the open source components. Complex modules and overlong modules often mean that the code readability and maintainability are poor, so these parameters can more comprehensively reflect the code quality level of the open source components. BRIEF DESCRIPTION OF THE DRAWINGS

[0083] Figure 1 This is a flow chart of a method for selecting an open source component in one embodiment of the present invention.

[0084] Figure 2 This is a flow chart of a method for selecting an open source component in another embodiment of the present invention.

[0085] Figure 3 This is a flow chart of a method for selecting an open source component in another embodiment of the present invention.

[0086] Figure 4 This is a flow chart of a method for selecting an open source component in another embodiment of the present invention.

[0087] Figure 5 This is a flow chart of a method for selecting an open source component in another embodiment of the present invention. DETAILED DESCRIPTION

[0088] In order to explain the technical content, structural features, achieved objectives and effects of the present invention in detail, the following is a detailed description in conjunction with the implementation methods and the accompanying drawings.

[0089] This embodiment discloses an open source component selection method, which is used to select open source components from a third-party platform during software development and improve the security performance of the selected open source components.

[0090] like Figure 1 The open source component selection method in this embodiment evaluates the open source components from the maintainability aspect, and includes the following steps:

[0091] S10: Obtain the code file of the target open source component.

[0092] S11: Count the number of functional modules in the code file to obtain a first module number.

[0093] S12: Count the number of complex modules in the functional module to obtain a second module number, and the cyclomatic complexity of the complex module is greater than the preset first threshold; and count the number of overlong modules in the functional module to obtain a third module number, and the number of code lines in the overlong module is greater than the preset second threshold or the weighted number of code lines is greater than the preset third threshold.

[0094] S13: Calculate the ratio of the second number of modules to the first number of modules to obtain a first parameter.

[0095] A ratio of the third number of modules to the first number of modules is calculated to obtain a second parameter.

[0096] S14: Fitting a first evaluation parameter based on the first parameter and the second parameter.

[0097] S15: Selecting the target open source component based on the first evaluation parameter.

[0098] On the other hand, the first evaluation parameter S is fitted based on the following formula: M :

[0099]

[0100] Among them, CP is the first parameter, and LP is the second parameter.

[0101] Specifically, the GitHub API is used to obtain the code files of the target open source components in the NumPy project.

[0102] Among them, in this code file:

[0103] The first module number N M =12143;

[0104] The second module number N C =323;

[0105] The third module number N L =1910;

[0106] Then, the first parameter CP = N C / N M =323 / 12143=0.0266;

[0107] The second parameter LP = N L / N M =1910 / 12143=0.157;

[0108] Then, the first evaluation parameter

[0109] In this embodiment, by counting the number of complex modules and overlong modules in the code file and calculating the ratio of the number of complex modules and overlong modules to the total number of modules as an evaluation parameter, it is helpful to objectively evaluate the code quality of the open source component. Complex modules and overlong modules often mean that the code readability and maintainability are poor, so these parameters can more comprehensively reflect the maintainability level of the open source component.

[0110] In addition, the statistical method for complex modules in code files is as follows:

[0111] First, the first threshold is defined, that is, modules with a cyclomatic complexity greater than 10 are considered complex modules;

[0112] Then, cyclomatic complexity refers to the number of independent execution paths in the control flow graph and can be calculated by the following formula:

[0113] V(G)=E-N+2

[0114] Among them, V(G) represents the cyclomatic complexity, E represents the number of edges in the control flow graph, and N represents the number of nodes in the control flow graph.

[0115] It can also be calculated as: V(G)=P+1, where P is the number of decision nodes (such as if, while, for statements, etc.).

[0116] Assume that the Numpy component contains a module named module_A, whose control flow graph contains 15 edges and 10 nodes.

[0117] Then the cyclomatic complexity of module_A is: V(G)=15-10+2=7.

[0118] Since 7 is less than 10, module_A is not a complex module.

[0119] Furthermore, the statistical method for the overly long modules in the code file is as follows:

[0120] First, the second threshold and the third threshold are defined, that is, a module with a code line number greater than 500 or a weighted code line number greater than 1000 is considered as an over-long module.

[0121] The weighted code lines refer to weighted calculation of the code lines at different levels, and the weighted code lines S is calculated based on the following formula: u as follows:

[0122] S u =∑(i×Len_i)

[0123] Among them, Len_i represents the number of lines of code at the i-th level (such as in the i-th loop).

[0124] Assume that the Numpy component contains a module named module_B, which has 600 lines of code and contains a loop with a nesting depth of 2 and 300 lines of code in the loop.

[0125] Then the weighted number of code lines of module_B is: 1×600+2×300=1200.

[0126] Since 1200 is greater than 1000, module_B is too long.

[0127] In another preferred embodiment of the present invention, the target open source component is also evaluated from the aspects of vulnerability repair status and usage status, which represent the security of the open source component. Figure 2 , the open source component selection method in this embodiment includes:

[0128] S20: Obtain vulnerability information corresponding to the target open source component from the open source vulnerability database, where the vulnerability information includes vulnerability type, vulnerability release date, and vulnerability score given by the vulnerability scoring system.

[0129] S21: Obtain the average daily download volume and average daily release volume of the target open source component within a specified time period from a public open source service platform.

[0130] It should be noted that there is no requirement for the order of performing step S20 and step S21 , and either one may be performed first.

[0131] S22: Generate a third parameter based on the average daily download volume and the average daily release volume.

[0132] S23: Generate a fourth parameter based on the number of days from the vulnerability release date of each vulnerability to the current time and the vulnerability score.

[0133] S24: Generate a second evaluation parameter representing a safety factor based on the third parameter and the fourth parameter.

[0134] S25: Select a target open source component based on the first evaluation parameter and the second evaluation parameter.

[0135] Specifically, the third parameter S1 is fitted based on the following formula:

[0136]

[0137] Among them, USE_c represents the average daily download volume, and REL_c represents the average daily release volume.

[0138] In addition, the fourth parameter S2 is fitted based on the following formula:

[0139]

[0140] Among them, e is a natural constant, an infinite non-repeating decimal, and its value is approximately 2.718281828459045, CVSS i represents the vulnerability score of the i-th vulnerability in the target open source component, Time i It indicates the number of days from the release date of the ith vulnerability in the target open source component to the current time, and T indicates the statistical duration.

[0141] Then, the second evaluation parameter S is fitted based on the following formula: s :

[0142]

[0143] Wherein, a and b are preset adjustment constants, 1.5≤a≤2, 1<b<1.5.

[0144] In this embodiment, the values ​​of a and b are preferably: a=1.915, b=1.0386.

[0145] The following is a specific example to illustrate the execution process of the above open source component selection method in detail.

[0146] 1. Basic data acquisition

[0147] In this embodiment, the information in the past 5 years is counted, that is, the statistical time length T = 5*365.

[0148] Search for vulnerability information of the target open source component Numpy 1.26.0 through NVD API or web crawling.

[0149] Assume that Numpy 1.26.0 has 3 vulnerabilities discovered in the past 5 years, as follows:

[0150] Vulnerability 1: CVSS score is 7.5, release date is 2023-01-01;

[0151] Vulnerability 2: CVSS score is 5.0, and the release date is 2022-03-15;

[0152] Vulnerability 3: CVSS score is 3.0 and the release date is 2020-05-20.

[0153] Get the download and release data of Numpy 1.26.0 in the past five years through PyPI API or web crawling, and calculate the average daily downloads and releases.

[0154] For example, the average daily download volume USE_c = 5680131 times;

[0155] The average daily release volume REL_c = 150 times.

[0156] 2. Data processing

[0157]

[0158] For vulnerability 1, Time1 = 365 days, CVSS1 = 7.5;

[0159] For vulnerability 2, Time2 = 540 days, CVSS2 = 5.0;

[0160] For vulnerability 3, Time1 = 1095 days, CVSS3 = 3.0;

[0161] So,

[0162] Then, the final value of the second evaluation parameter is 1.43. According to the corresponding relationship between the preset value of the second evaluation parameter and the degree of danger, the security of Numpy 1.26.0 can be accurately evaluated.

[0163] In another preferred embodiment of the present invention, the open source components are evaluated from another dimension. To this end, the open source component selection method in this embodiment further includes the following steps:

[0164] The vulnerability repair status information of the vulnerability in the target open source component is obtained from the open source community platform, and a third evaluation parameter representing the vulnerability response situation is fitted according to the vulnerability repair status information and the corresponding vulnerability release date. The target open source component is selected by combining the first evaluation parameter and the third evaluation parameter.

[0165] In this embodiment, the third evaluation parameter is fitted based on the vulnerability repair status information reflected in the open source community platform, so as to evaluate the target open source component from two aspects of the first evaluation parameter and the third evaluation parameter, so as to further improve the comprehensiveness and accuracy of the evaluation of the open source component. Of course, the target open source component can also be evaluated from three aspects of the first evaluation parameter, the second evaluation parameter and the third evaluation parameter.

[0166] Specifically, the following four response states are set to evaluate the vulnerability response status:

[0167] Waiting for response: the vulnerability is not fixed and Δt1<δ1;

[0168] No response: the vulnerability is not fixed and Δt1≥δ1;

[0169] Slow response: the vulnerability has been fixed and Δt2≥δ2;

[0170] Fast response: the vulnerability has been fixed and Δt2<δ2;

[0171] Among them, Δt1 is the time interval between the vulnerability release date and the current statistical date;

[0172] Δt2 is the time interval between the vulnerability release date and the vulnerability repair completion date;

[0173] δ1 and δ2 are two preset time thresholds.

[0174] In this regard, the open source component selection method in this embodiment is as follows:

[0175] According to the vulnerability repair status information and vulnerability release date, for each vulnerability, match the corresponding response status for it;

[0176] creating a fifth parameter related to the response speed of the vulnerabilities in the open source components based on the response status of all the vulnerabilities in the open source components;

[0177] Calculate the ratio of the number of vulnerabilities in the open source components that are in the slow response and fast response states to the total number of vulnerabilities to obtain the vulnerability response ratio;

[0178] A third evaluation parameter is obtained based on a product of the fifth parameter and the vulnerability response ratio.

[0179] More specifically, the fifth parameter CoV is created based on the following formula:

[0180] CoV=∑W i ×A i

[0181]

[0182] Among them, Wi represents the weight assigned to each response state, A i Indicates the proportion of any response status in all response statuses, B i Indicates the number of any one response status.

[0183] The process of generating the third evaluation parameter in the above embodiment is described in detail below.

[0184] Still taking Numpy 1.26.0, the target open source component in the second evaluation parameter generation process, as an example, assume that Numpy1.26.0 has found three vulnerabilities in the past five years, as follows:

[0185] Vulnerability 1: CVSS score is 7.5, release date is 2023-01-01;

[0186] Vulnerability 2: CVSS score is 5.0, and the release date is 2022-03-15;

[0187] Vulnerability 3: CVSS score is 3.0 and the release date is 2020-05-20.

[0188] The vulnerability repair status information obtained from the open source community platform is as follows:

[0189] Vulnerability 1 has been fixed on 2023-06-10;

[0190] Vulnerability 2 has been fixed on 2022-03-20;

[0191] Vulnerability 3 has been fixed on 2020-05-25.

[0192] Taking δ1 and δ2 as 30 days as an example, each vulnerability is divided into one of the following four states: pending response, no response, slow response, and fast response according to the repair time and response status:

[0193] Vulnerability 1: Since it has been repaired, the repair time Δt2>δ2, so vulnerability 1 is a slow response;

[0194] Vulnerability 2: Since it has been repaired, the repair time Δt2<δ2, so vulnerability 2 is a fast response;

[0195] Vulnerability 3: Since it has been repaired, the repair time Δt2<δ2, so vulnerability 2 is a fast response.

[0196] Then, the number of each response state is:

[0197] Waiting for response: 0;

[0198] No response: 0;

[0199] Slow response: 1 (vulnerability 1);

[0200] Fast response: 2 (vulnerabilities 2 and 3).

[0201] The proportion of any response status in all response statuses A i as follows:

[0202] Waiting for response: A1=0 / 3=0;

[0203] No response: A2=0 / 3=0;

[0204] Slow response: A3 = 1 / 3 = 0.33;

[0205] Fast response: A4=2 / 3=0.67.

[0206] The preset weights of pending response, no response, slow response, and fast response are 0, 0.5, 1, and 2 respectively.

[0207] Then, the fifth parameter CoV = (0*0) + (0.5*0) + (1*0.33) + (2*0.67) = 1.67.

[0208] Vulnerability response ratio Rv = (number of responded vulnerabilities) / (total number of vulnerabilities) = 2 / 3 = 0.67.

[0209] Then, the third evaluation parameter representing the vulnerability response situation is Sv=Rv*CoV=0.67*1.67=1.072.

[0210] In this embodiment, by comprehensively analyzing the download volume, release frequency, vulnerability scores of open source components and vulnerability repair status information of the open source community platform, the screening security and reliability of open source components in the software development process are effectively improved.

[0211] In addition, when an open source component is in an active large-scale community, the quality and security of the open source component can be better guaranteed. An active community means that more developers and users actively participate in the development, maintenance, and problem solving of the component, which makes it more likely to respond to vulnerabilities and problems in a timely manner and develop more robust testing and verification processes. In addition, a large-scale community often means higher visibility and review, making it easier to identify and resolve potential security vulnerabilities.

[0212] In this regard, in another embodiment of the present invention, the security performance and reliability of open source components are evaluated from the perspective of community support. Figure 3 , the open source component selection method also includes:

[0213] S30: Acquire the number of occurrences of participation events of the target open source component from the open source community platform, where the participation events include behavior events in which multiple users participate and are related to the target open source component.

[0214] Participation events include at least two or more of initiating issues, commenting on issues, initiating pull requests, commenting on pull requests, and merging pull requests related to the target open source component. Each type of participation event includes several event items that occur at different times.

[0215] S31: Creating a fourth evaluation parameter representing the activity of the target open source component based on the number of occurrences of the participation event.

[0216] S32: Selecting the target open source component based on the first evaluation parameter and the fourth evaluation parameter. Of course, the first evaluation parameter, the second evaluation parameter, the third evaluation parameter and the fourth evaluation parameter may be combined to select the target open source component.

[0217] Initiating a question means that a user has a question about a target open source component and asks it in the open source community to seek help.

[0218] For problem comments, it means that users discuss problems raised in the open source community and provide solutions.

[0219] Pull Requests means that developers submit code modification suggestions for target open source components in the open source community.

[0220] Pull request comments (PR Comments) mean that developers submit code modification suggestions for target open source components in the open source community for discussion and review.

[0221] For merged pull requests (Merged PRs), it means that developers merge code modification suggestions about the target open source components into the main branch in the open source community.

[0222] Based on this, Figure 4 , the method for generating the fourth evaluation parameter specifically includes:

[0223] S40: assign a proportional weight to each type of participation event, and the sum of the proportional weights of all participation events of all types is 100%;

[0224] S41: for a plurality of the event items in any type of the participating event, based on a time function and according to the occurrence time of each of the event items, configure a time weight for each of the event items;

[0225] S42: Calculate the activity level AL of any of the participating events based on the following formula: i :

[0226] ALi =W i ×∑Q n

[0227] Among them, W i is the proportion weight of the participating event, Q n is the time weight of any event item in the participating event;

[0228] S43: Calculate a fourth evaluation parameter SCA representing the community activity of the target open source component based on the following formula:

[0229] .

[0231] In addition, the time weight Q of any event item in the participating event is configured based on the following formula: n :

[0232]

[0233] Wherein, e is a natural constant, T is the statistical duration, t is a preset time constant, and Δt is the number of days after the behavioral event of the event item occurs.

[0234] Specifically, for a certain target open source component, the community participation obtained in the past 365 days (i.e., the statistical duration T) is shown in Table 1 below, and a proportional weight is assigned to each participation event.

[0235] Table 1

[0236] Participate in events Number of event items Proportional Weight Ask a question 1000 0.2 Question Comments 5000 0.3 Open a pull request 2000 0.1 Pull request comments 3000 0.2 Merge pull request 1000 0.2

[0237] For example, for the participation event of raising a question, according to the occurrence time of 1000 event items, through the above Q n The time weight Q1 of the event item that initiates the problem is calculated by the calculation formula. Similarly, the time weights Q2, Q3, Q4, and Q5 of the other four event items participating in the time are calculated.

[0238] Then, ∑AL i =0.2×Q1+0.3×Q2+0.1×Q3+0.2×Q4+0.2×Q5

[0239] Finally, the value of the fourth evaluation parameter SCA is obtained through square root calculation. The SCA reflects the activity of the current target open source component in the open source community in the past 365 days. The larger the value, the higher the community activity.

[0240] On the other hand, the size of the open source community reflects the popularity and widespread adoption of the open source components. Having a large community enables more thorough testing and review of open source components, thereby increasing the chances of discovering and resolving any potential vulnerabilities. A large community enables more thorough testing and review of open source components, thereby increasing the chances of discovering and resolving potential vulnerabilities, increasing the likelihood of discovering and resolving potential vulnerabilities.

[0241] In this regard, in another preferred embodiment of the present invention, the open source component selection method further includes:

[0242] The community size of the target open source component is obtained from the open source community platform, and a fifth evaluation parameter is generated based on the community size.

[0243] Since the fourth evaluation parameter and the fifth evaluation parameter are both community support elements that have an important impact on the selection of open source components. Therefore, proportional weights are configured for the fourth evaluation parameter and the fifth evaluation parameter, and the sum of the proportional weights of the fourth evaluation parameter and the fifth evaluation parameter is 100%. The actual values ​​of the fourth evaluation parameter and the fifth evaluation parameter are comprehensively calculated by the configured weights. Therefore, in this embodiment, the target open source component is selected based on the first evaluation parameter, the fourth evaluation parameter, and the fifth evaluation parameter. Of course, the first evaluation parameter, the second evaluation parameter, the third evaluation parameter, the fourth evaluation parameter, and the fifth evaluation parameter can also be combined as a basis for selecting the target open source component.

[0244] On the other hand, Figure 5 , the method for generating the fifth evaluation parameter includes:

[0245] S50: Obtaining indicator parameters related to the community size of the target open source component from an open source community platform, wherein the indicator parameters include the number of contributors, the number of followers, the number of event activities, and the number of discussions.

[0246] The number of contributors represents the number of people who participated in the development of the target open source component. The larger the number of contributors, the larger the development team of the open source component, which also implies that more people are involved in code review and maintenance, which is conducive to improving code quality and stability.

[0247] The number of followers represents the number of users who are interested in the target open source component. The more followers there are, the more popular the open source component is, which also implies that the user group is larger and more likely to discover and feedback problems, thereby promoting the improvement and perfection of the open source component. For example, on the GitHub platform, the star data of the target open source component, that is, the number of users who follow the target open source component, can be obtained through the GitHub API.

[0248] The number of event activities represents the number of times users interact with the target open source component, such as discussing the target open source component, reporting issues, contributing code, etc. On the GitHub platform, the number of issues, pull requests, and commits of the target open source component can be obtained through the GitHub API, and the number of interactions of related events (such as comments, likes, and reposts) can be used to measure the number of event activities.

[0249] The number of discussions represents the number of posts that users have made to discuss the target open source component. The more discussions there are, the higher the user's attention and participation in the target open source component, which is conducive to mutual exchange of experience and problem solving among users, and improves the efficiency and effectiveness of component use.

[0250] It should be noted that the number of events in the open source community focuses on the user participation and interaction level for specific events, while the number of discussions focuses on the activeness of users' discussions and exchanges on the open source components themselves.

[0251] S51: In this regard, according to the importance relationship between the various indicator parameters, a proportional weight is configured for each of the indicator parameters, and the sum of the proportional weights of the various indicator parameters is 100%.

[0252] S52: Calculate the fifth evaluation parameter SCZ based on the following formula:

[0253] SCZ=∑Y i ×N i

[0254] Among them, Y i Represents the proportional weight of any of the indicator parameters, N i Indicates the number of any of the index parameters.

[0255] Specifically, the importance relationship between the various indicator parameters is adjusted and confirmed based on the judgment matrix.

[0256] For example, the number of each indicator parameter obtained is as follows:

[0257] Number of contributors (NT): 100;

[0258] Number of followers (NF): 5000;

[0259] Number of events (NE): 1000 (e.g. comments and likes on issues and pull requests, etc.);

[0260] Number of Discussions (ND): 500 (for example, the number of discussion posts about MyLib).

[0261] Pre-configured:

[0262] The number of followers is 3 times more important than the number of contributors;

[0263] The number of contributors is 2x more important than the number of events;

[0264] The number of events is 1.5 times more important than the number of discussions.

[0265] Then we can construct a 4x4 judgment matrix X:

[0266]

[0267] Each element X[i][j] in the judgment matrix X represents the importance of the i-th indicator relative to the j-th indicator. For example, X[1][2] = 1 / 3, which means that NF is 3 times more important than NT.

[0268] Next, calculate the maximum eigenvalue (λ max ) and the corresponding eigenvector (P):

[0269] Maximum eigenvalue λ max =4.2;

[0270] Corresponding eigenvector P: [0.13, 0.31, 0.41, 0.15];

[0271] Then, perform a consistency check:

[0272] Check whether the judgment matrix X is consistent, that is, whether the importance relationship between the indicators in the judgment matrix X is self-consistent. Calculate the consistency index (CI) and consistency ratio (CR):

[0273] Consistency index CI = (λ max -n) / (n-1)=(4.2-4) / (4-1)=0.067;

[0274] The consistency ratio CR=CI / RI=0.067 / 0.90=0.074.

[0275] Where n is the number of indicators (i.e. 4), and RI is the average consistency index corresponding to the n-order matrix, which can be obtained by looking up the table and will not be repeated here. Generally speaking, when CR<0.1, the consistency of the judgment matrix is ​​considered acceptable. In this example, CR=0.074, which is less than 0.1, so the consistency of the judgment matrix X is acceptable.

[0276] Then, according to the calculated proportional weight P, each indicator parameter can be weighted to obtain the final community size score, which is the fifth evaluation parameter SCZ:

[0277] SCZ=P[1]*NT+P[2]*NF+P[3]*NE+P[4]*ND;

[0278] SCZ=0.13*100+0.31*5000+0.41*1000+0.15*500;

[0279] SCZ=2265.

[0280] In summary, the present invention discloses a method for selecting an open source component, which evaluates a target open source component from several aspects, including maintainability, security, developer support, and community support of the open source component, wherein maintainability is evaluated by a first evaluation parameter. Security is evaluated by a second evaluation parameter. Developer support is evaluated by a third evaluation parameter. Community support is evaluated by a fourth evaluation parameter and a fifth evaluation parameter. Thus, the method evaluates the target open source component from multiple dimensions, providing a more accurate and comprehensive basis for software developers to select target open source components.

[0281] In another preferred embodiment of the present invention, a system for selecting an open source component is disclosed, including an evaluation parameter generator, which generates evaluation parameters for evaluating a target open source component based on the open source component selection method in the above embodiment.

[0282] The present invention also discloses another open source component selection system, which includes one or more processors, a memory and one or more programs, wherein the one or more programs are stored in the memory and are configured to be executed by the one or more processors, and the program includes instructions for executing the open source component selection method as described above. The processor can adopt a general central processing unit (CPU), a microprocessor, an application specific integrated circuit (ASIC), or one or more integrated circuits to execute related programs to implement the functions required to be executed by the modules in the open source component selection system of the embodiment of the present application, or to execute the open source component selection method of the method embodiment of the present application.

[0283] The present invention also discloses a computer-readable storage medium, which includes a computer program, and the computer program can be executed by a processor to complete the open source component selection method as described above. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or a data center that includes one or more available media integrated. The available medium can be a read-only memory (ROM), or a random access memory (RAM), or a magnetic medium, such as a floppy disk, a hard disk, a tape, a magnetic disk, or an optical medium, such as a digital versatile disc (DVD), or a semiconductor medium, such as a solid state disk (SSD), etc.

[0284] The embodiment of the present application also discloses a computer program product or a computer program, which includes a computer instruction stored in a computer-readable storage medium. A processor of an electronic device reads the computer instruction from the computer-readable storage medium, and the processor executes the computer instruction, so that the electronic device executes the above-mentioned open source component selection method.

[0285] The above disclosure is only the preferred embodiment of the present invention, which certainly cannot be used to limit the scope of rights of the present invention. Therefore, equivalent changes made according to the scope of the patent application of the present invention are still within the scope covered by the present invention.

[0286] The above disclosure is only the preferred embodiment of the present invention, which certainly cannot be used to limit the scope of rights of the present invention. Therefore, equivalent changes made according to the scope of the patent application of the present invention are still within the scope covered by the present invention.

Claims

1. A method for selecting an open source component, characterized in that: include: Obtain the code files of the target open source components; Counting the number of functional modules in the code file to obtain a first module number; Counting the number of complex modules in the functional module to obtain a second number of modules, wherein the cyclomatic complexity of the complex modules is greater than a preset first threshold; Calculating a ratio of the second number of modules to the first number of modules to obtain a first parameter; Counting the number of overlong modules in the functional module to obtain a third module number, wherein the number of code lines in the overlong module is greater than a preset second threshold or the weighted number of code lines is greater than a preset third threshold; Calculating a ratio of the third number of modules to the first number of modules to obtain a second parameter; Fitting a first evaluation parameter based on the first parameter and the second parameter; The target open source component is selected based on the first evaluation parameter.

2. The open source component selection method according to claim 1, characterized in that: The first evaluation parameter S is fitted based on the following formula M : Among them, CP is the first parameter, and LP is the second parameter.

3. The open source component selection method according to claim 1, characterized in that: Also obtaining vulnerability information corresponding to the target open source component from an open source vulnerability database, the vulnerability information including vulnerability type, vulnerability release date, and vulnerability score given by a vulnerability scoring system; Obtaining the average daily download volume and average daily release volume of the target open source component within a specified time period from a public open source service platform; Generate a third parameter based on the average daily download volume and the average daily release volume; Generate a fourth parameter based on the number of days from the vulnerability release date to the present and the vulnerability score of each vulnerability; Generate a second evaluation parameter representing a safety factor based on the third parameter and the fourth parameter; The target open source component is selected based on the first evaluation parameter and the second evaluation parameter.

4. The open source component selection method according to claim 3, characterized in that: The third parameter S1 is fitted based on the following formula: Among them, USE_c represents the average daily download volume, and REL_c represents the average daily release volume.

5. The open source component selection method according to claim 4, characterized in that: The fourth parameter S2 is fitted based on the following formula: Among them, e is a natural constant, CVSS i represents the vulnerability score of the i-th vulnerability in the target open source component, Time i It represents the number of days from the release date of the i-th vulnerability in the target open source component to the present time, and T represents the statistical duration.

6. The open source component selection method according to claim 5, characterized in that: The second evaluation parameter S is fitted based on the following formula s : Wherein, a and b are preset adjustment constants, 1.5≤a≤2, 1<b<1.

5.

7. The open source component selection method according to claim 1, characterized in that: Acquire vulnerability information corresponding to the target open source component from an open source vulnerability database, wherein the vulnerability information includes vulnerability type and vulnerability release date; acquire vulnerability repair status information of the vulnerability in the target open source component from an open source community platform, and fit a third evaluation parameter representing the vulnerability response situation according to the vulnerability repair status information and the corresponding vulnerability release date; and select the target open source component in combination with the first evaluation parameter and the third evaluation parameter.

8. The open source component selection method according to claim 7, characterized in that: Set the following four response statuses to evaluate vulnerability response status: Waiting for response: the vulnerability is not fixed and Δt1<δ1; No response: the vulnerability is not fixed and Δt1≥δ1; Slow response: the vulnerability has been fixed and Δt2≥δ2; Fast response: the vulnerability has been fixed and Δt2<δ2; Wherein, Δt1 is the time interval between the release date of the vulnerability and the current statistical date; Δt2 is the time interval between the release date of the vulnerability and the completion date of the vulnerability repair; δ1 and δ2 are two preset time thresholds; According to the vulnerability repair status information and the vulnerability release date, for each vulnerability, a corresponding response status is matched; creating a fifth parameter related to a response speed of the vulnerabilities in the open source component based on the response status of all the vulnerabilities in the open source component; Calculating the ratio of the number of vulnerabilities in the open source component that are in the slow response state and the fast response state to the total number of vulnerabilities to obtain a vulnerability response ratio; The third evaluation parameter is obtained based on a product of the fifth parameter and the vulnerability response ratio.

9. The open source component selection method according to claim 8, characterized in that: The fifth parameter CoV is created based on the following formula: CoV=∑W i ×A i Among them, W i represents the weight assigned to each of the response states, A i Indicates the proportion of any of the response states in all the response states, B i Indicates the number of any of the response statuses.

10. The open source component selection method according to claim 1, characterized in that: Also obtaining the number of participation events of the target open source component from the open source community platform, wherein the participation events include behavior events in which multiple users participate and are related to the target open source component; The participation events include at least two or more of the initiated issues, issue comments, initiated pull requests, pull request comments, and merged pull requests related to the target open source component, and each type of the participation events includes a number of event items that occur at different times; Creating a fourth evaluation parameter representing the activity of the target open source component based on the number of occurrences of the participation event; The target open source component is selected based on the first evaluation parameter and the fourth evaluation parameter.

11. The open source component selection method according to claim 10, characterized in that: The method for generating the fourth evaluation parameter includes: Assign a proportional weight to each type of engagement event, and the sum of the proportional weights of all engagement events of all types is 100%; For a plurality of the event items in any type of the participating event, based on a time function, a time weight is configured for each of the event items according to the occurrence time of each of the event items; The activity level AL of any of the above mentioned participation events is calculated based on the following formula i : <h2 style=";text-align:left;direction:ltr">AL<h2 style=";text-align:left;direction:ltr"> i <h2 style=";text-align:left;direction:ltr"> =W<h2 style=";text-align:left;direction:ltr"> i <h2 style=";text-align:left;direction:ltr"> ×∑Q<h2 style=";text-align:left;direction:ltr"> n Among them, W i is the proportion weight of the participating event, Q n is the time weight of any event item in the participating event; The fourth evaluation parameter SCA representing the community activity of the target open source component is calculated based on the following formula:

12. The open source component selection method according to claim 11, characterized in that: Based on the following formula combined with the time weight Q of any event item in the participating event n : Wherein, e is a natural constant, T is the statistical duration, t is a preset time constant, and Δt is the number of days after the behavioral event of the event item occurs.

13. The open source component selection method according to claim 10, characterized in that: The community size of the target open source component is also obtained from the open source community platform, and a fifth evaluation parameter is generated based on the community size; a proportional weight is configured for the fifth evaluation parameter and the fourth evaluation parameter, and the sum of the proportional weights of the fifth evaluation parameter and the fourth evaluation parameter is 100%; the target open source component is selected based on the first evaluation parameter, the fourth evaluation parameter and the fifth evaluation parameter.

14. The open source component selection method according to claim 13, characterized in that: The method for generating the fifth evaluation parameter includes: Obtaining indicator parameters related to the community size of the target open source component from an open source community platform, wherein the indicator parameters include the number of contributors, the number of followers, the number of event activities, and the number of discussions; The number of contributors represents the number of people who participated in the development of the target open source component; The number of followers represents the number of users who are interested in the target open source component; The number of event activities represents the number of times the user interacts with the target open source component; The number of discussions represents the number of posts issued by users to discuss the target open source component; According to the importance relationship between the various indicator parameters, a proportional weight is configured for each of the indicator parameters, and the sum of the proportional weights of the various indicator parameters is 100%; The fifth evaluation parameter SCZ is calculated based on the following formula: SCZ=∑Y i ×N i Among them, Y i Represents the proportional weight of any of the indicator parameters, N i Indicates the number of any of the index parameters.

15. The open source component selection method according to claim 14, characterized in that: The importance relationship between the various indicator parameters is adjusted and confirmed based on the judgment matrix.

16. An open source component selection system, characterized in that: It includes an evaluation parameter generator, which generates evaluation parameters for evaluating a target open source component based on the open source component selection method according to any one of claims 1 to 15.

17. An open source component selection system, characterized in that: include: one or more processors; Memory; and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the programs comprising instructions for executing the open source component selection method as described in any one of claims 1 to 15.

18. A computer-readable storage medium, characterized in that: It includes a computer program, which can be executed by a processor to complete the open source component selection method as described in any one of claims 1 to 15.

Images