Open source component selection method and system based on post-maintenance support

Abstract

The invention discloses an open source component selection method and system based on post-maintenance support, and the method comprises the steps: obtaining vulnerability information corresponding to a target open source component from an open source vulnerability database, the vulnerability information comprising vulnerability types and vulnerability publishing dates; acquiring vulnerability repair state information of vulnerabilities in the target open source component from an open source community platform; fitting a first evaluation parameter representing a vulnerability response condition for maintaining the vulnerability according to the vulnerability repair state information and the corresponding vulnerability release date; and selecting the target open source component based on the first evaluation parameter. According to the method, information support with high real-time performance can be provided for selection of the open source component, and the reliability of the selected open source component in safety is ensured. Moreover, the first evaluation parameter is fitted by using the vulnerability repair state information and the release date, so that the advantages and disadvantages of the open source component in vulnerability response and maintenance can be quantified, an objective standard is provided for selection of the target open source component, and the scientificity of decision is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of software development, and in particular to a method and system for selecting open source components based on post-maintenance support. 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, security assessments for open source components usually rely on static analysis tools and vulnerability databases. However, these methods often have problems such as incomplete assessments 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 a method and system for selecting open source components based on post-maintenance support, which can select open source components based on real-time maintenance information.

[0005] In order to achieve the above object, the present invention provides a method for selecting open source components based on post-maintenance support, which includes:

[0006] Acquire vulnerability information corresponding to the target open source component from an open source vulnerability database, wherein the vulnerability information includes a vulnerability type and a vulnerability release date;

[0007] Obtain vulnerability repair status information of the vulnerability in the target open source component from the open source community platform;

[0008] Fitting a first evaluation parameter representing a vulnerability response situation for maintaining the vulnerability according to the vulnerability repair status information and the corresponding vulnerability release date;

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

[0010] Preferably, the following four response states are set for evaluating vulnerability response situations:

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

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

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

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

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

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

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

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

[0019] Creating a first parameter related to a response speed of a vulnerability in the open source component based on the response status of all vulnerabilities in the open source component;

[0020] 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;

[0021] The first evaluation parameter is obtained based on a product of the first parameter and the vulnerability response ratio.

[0022] Preferably, the first parameter CoV is created based on the following formula:

[0023] CoV=∑W i ×A i

[0024]

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

[0026] Preferably, the number of participation events of the target open source component is also obtained from the open source community platform, the participation events include behavioral events involving multiple users related to the target open source component, and a second evaluation parameter representing the activity of the target open source component is created based on the number of participation events; and the target open source component is selected in combination with the first evaluation parameter and the second evaluation parameter.

[0027] Preferably, the 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, and each type of the participation event includes several event items that occur at different times.

[0028] Preferably, the method for generating the second evaluation parameter includes:

[0029] 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%;

[0030] 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;

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

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

[0033] 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;

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

[0035]

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

[0037]

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

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

[0040] Preferably, the method for generating the third evaluation parameter includes:

[0041] 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;

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

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

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

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

[0046] 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%;

[0047] The third evaluation parameter SCZ is calculated based on the following formula:

[0048] SCZ=∑Y i ×N i

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

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

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

[0052] The present invention also provides an open source component selection system, comprising:

[0053] one or more processors;

[0054] Memory;

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

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

[0057] Compared with the prior art, the open source component selection method provided by the above technical solution of the present invention realizes the reasonable selection of the target open source component by collecting and analyzing the vulnerability information and repair status of the target open source component. First, by obtaining the latest vulnerability information and repair status from the open source vulnerability database and community platform, the method can provide high real-time information support to ensure the reliability of the selected open source component in terms of security. Secondly, by fitting the first evaluation parameter using the vulnerability repair status information and the release date, the advantages and disadvantages of the open source component in terms of vulnerability response and maintenance can be quantified, providing an objective standard for the selection of the target open source component and improving the scientific nature of the decision. In addition, this method pays attention to the maintenance response of the open source component, so that the development team not only pays attention to the existing functions of the open source component when selecting the component, but also considers its future security maintenance capabilities, thereby enhancing the long-term stability of the project. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

[0062] This embodiment discloses a method for selecting open source components based on post-maintenance support, which is used for selecting open source components from a third-party platform during software development and improving the security performance and reliability of the selected open source components.

[0063] like Figure 1 The open source component selection method in this embodiment includes the following steps:

[0064] S10: Acquire vulnerability information corresponding to the target open source component from an open source vulnerability database, where the vulnerability information includes vulnerability type and vulnerability release date;

[0065] S11: Acquire vulnerability repair status information of the vulnerability in the target open source component from the open source community platform;

[0066] S12: fitting a first evaluation parameter representing a vulnerability response situation for maintaining the vulnerability according to the vulnerability repair status information and the corresponding vulnerability release date;

[0067] S13: Selecting the target open source component based on the first evaluation parameter.

[0068] In this embodiment, by collecting and analyzing the vulnerability information and repair status of the target open source components, a reasonable selection of the target open source components is achieved. First, by obtaining the latest vulnerability information and repair status from the open source vulnerability database and community platform, the method can provide high real-time information support to ensure the reliability of the selected open source components in terms of security. Secondly, by fitting the first evaluation parameter using the vulnerability repair status information and the release date, the advantages and disadvantages of the open source components in terms of vulnerability response and maintenance can be quantified, providing an objective standard for the selection of the target open source components and improving the scientific nature of the decision. In addition, this method pays attention to the maintenance response of the open source components, so that the development team not only pays attention to the existing functions of the open source components when selecting components, but also considers their future security maintenance capabilities, thereby enhancing the long-term stability of the project.

[0069] On the other hand, the following four response states are set to evaluate the vulnerability response situation:

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

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

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

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

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

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

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

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

[0078] Creating a first parameter related to a response speed of a vulnerability in the open source component based on the response status of all vulnerabilities in the open source component;

[0079] 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;

[0080] The first evaluation parameter is obtained based on a product of the first parameter and the vulnerability response ratio.

[0081] Specifically, the third parameter CoV is created based on the following formula:

[0082] CoV=∑W i ×A i

[0083]

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

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

[0086] Taking the target open source component Numpy 1.26.0 as an example, assume that three vulnerabilities have been found in Numpy 1.26.0 in the past five years, as follows:

[0087] Vulnerability 1 (type): Release date is 2023-01-01;

[0088] Vulnerability 2: Release date is 2022-03-15;

[0089] Vulnerability 3: Release date is 2020-05-20.

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

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

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

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

[0094] 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:

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

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

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

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

[0099] Waiting for response: 0;

[0100] No response: 0;

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

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

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

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

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

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

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

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

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

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

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

[0112] On the other hand, 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.

[0113] In this regard, in another preferred embodiment of the present invention, the security performance and reliability of the open source component are evaluated from the perspective of community support. Then, the open source component selection method further includes:

[0114] Acquire the number of participation events of the target open source component from an 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, and create a second evaluation parameter representing the activity of the target open source component based on the number of participation events;

[0115] The target open source component is selected in combination with the first evaluation parameter and the second evaluation parameter.

[0116] In this embodiment, for the target open source component, the number of its participation events in the open source community is evaluated to generate a second evaluation parameter, thereby further improving the comprehensiveness of the open source component evaluation.

[0117] On the other hand, the 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, and each type of the participation event includes several event items that occur at different times.

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

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

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

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

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

[0123] Based on this, Figure 2 , the method for generating the second evaluation parameter includes:

[0124] S20: 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%;

[0125] S21: 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;

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

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

[0128] 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;

[0129] S23: Calculate a second evaluation parameter SCA representing the community activity of the target open source component based on the following formula:

[0130]

[0131] In addition, based on the following formula combined with the time weight Q of any of the event items in the participating event n :

[0132]

[0133] Where 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 behavior event of the event item occurs.

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

[0135] Table 1

[0136] 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

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

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

[0139] Finally, the value of the second 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.

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

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

[0142] Acquire the community size of the target open source component from the open source community platform, and generate a third evaluation parameter based on the community size;

[0143] Since both the second evaluation parameter and the third evaluation parameter are community support elements that have an important impact on the selection of open source components. Therefore, proportional weights are configured for the second evaluation parameter and the third evaluation parameter, and the sum of the proportional weights of the second evaluation parameter and the third evaluation parameter is 100%. The actual values ​​of the second evaluation parameter and the third evaluation parameter are calculated by comprehensive calculation of the configured weights. Therefore, in this embodiment, the target open source component is selected based on the first evaluation parameter, the second evaluation parameter, and the third evaluation parameter.

[0144] On the other hand, Figure 3 , the method for generating the third evaluation parameter includes:

[0145] S30: 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.

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

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

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

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

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

[0151] S31: 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%.

[0152] S32: Calculate the third evaluation parameter SCZ based on the following formula:

[0153] SCZ=∑Y i ×N i

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

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

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

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

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

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

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

[0161] Pre-configured:

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

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

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

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

[0166]

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

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

[0169] Maximum eigenvalue λ max =4.2;

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

[0171] Then, perform a consistency check:

[0172] 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):

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

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

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

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

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

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

[0179] SCZ=2265.

[0180] In summary, the present invention discloses a method for selecting open source components based on post-maintenance support, which evaluates the security and reliability of the target open source components from two aspects: developer support and community support after the open source components are released, so as to provide software developers with a more accurate basis for selecting open source components.

[0181] In another preferred embodiment of the present invention, a system for selecting an open source component is disclosed, including 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 in the above embodiment.

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

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

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

[0185] 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 open source components based on post-maintenance support, characterized in that: include: Acquire vulnerability information corresponding to the target open source component from an open source vulnerability database, wherein the vulnerability information includes a vulnerability type and a vulnerability release date; Obtain vulnerability repair status information of the vulnerability in the target open source component from the open source community platform; Fitting a first evaluation parameter representing a vulnerability response situation for maintaining the vulnerability according to the vulnerability repair status information and the corresponding vulnerability release date; The target open source component is selected based on the first evaluation parameter.

2. The method for selecting open source components based on post-maintenance support according to claim 1, characterized in that: Set the following four response states for evaluating vulnerability responses: 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 first parameter related to a response speed of a vulnerability in the open source component based on the response status of all 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 first evaluation parameter is obtained based on a product of the first parameter and the vulnerability response ratio.

3. The method for selecting open source components based on security performance according to claim 2, characterized in that: The first 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.

4. The method for selecting open source components based on security performance according to claim 1, characterized in that: The number of participation events of the target open source component is also obtained from the open source community platform, where the participation events include behavioral events involving multiple users related to the target open source component, and a second evaluation parameter representing the activity of the target open source component is created based on the number of participation events; the target open source component is selected in combination with the first evaluation parameter and the second evaluation parameter.

5. The method for selecting open source components based on security performance according to claim 4, characterized in that: The 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, and each type of the participation event includes several event items that occur at different times.

6. The method for selecting open source components based on security performance according to claim 5, characterized in that: The method for generating the second 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 second evaluation parameter SCA representing the community activity of the target open source component is calculated based on the following formula:

7. The method for selecting open source components based on security performance according to claim 6, 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.

8. The method for selecting open source components based on security performance according to claim 4, characterized in that: The community size of the target open source component is also obtained from the open source community platform, and a third evaluation parameter is generated based on the community size; proportional weights are configured for the second evaluation parameter and the third evaluation parameter, and the sum of the proportional weights of the second evaluation parameter and the third evaluation parameter is 100%; the target open source component is selected based on the first evaluation parameter, the second evaluation parameter and the third evaluation parameter.

9. The method for selecting open source components based on security performance according to claim 8, characterized in that: The method for generating the third 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 third 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.

10. The method for selecting open source components based on security performance according to claim 9, characterized in that: The importance relationship between the various indicator parameters is adjusted and confirmed based on the judgment matrix.

11. An open source component selection system, characterized in that: It comprises 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 10.

12. 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 are 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 10.

13. A computer-readable storage medium, characterized in that: It comprises 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 10.

Images