Software reliability calculation system, control method and program for the software reliability calculation system

Abstract

The risk of malicious code being inserted during the software development process is accurately calculated. [Solution] A software reliability calculation system that calculates the risk of malicious code being inserted during the software development process as the reliability of the software, comprising a processor and memory, an information acquisition unit that acquires developer information for calculating the reliability of a developer who participates in a software development project and codes the software, and development project information for calculating the reliability of a development project which represents the difficulty of a developer attempting to insert malicious code into the software within the development project, and a reliability calculation unit that calculates the reliability of the developer using the developer information and the reliability of the development project using the development project information, and calculates the reliability of the software using the reliability of the developer and the reliability of the development project.

Description

[[TECHNICAL FIELD]]

[0001] The present invention relates to a software reliability calculation system, a control method for a software reliability calculation system, and a program. [[BACKGROUND ART]]

[0002] In recent years, various open source software (hereinafter referred to as OSS) have been published to repositories available on the Internet, and there are an increasing number of cases where IT systems are constructed while utilizing such OSS.

[0003] OSS development is often progressed, for each development project provided in a repository, by the participation of several administrators and several to about a dozen developers.

[0004] However, since the source code of OSS is open to the public, there is a risk of cyberattacks exploiting vulnerabilities such as those in the code. Such characteristics of OSS can become a risk when constructing an IT system using OSS.

[0005] For this reason, technologies have been developed, such as the one disclosed in Patent Document 1, that support the selection of low-risk software during IT system design by collecting and evaluating information such as the last update date and bug density of OSS. [[PRIOR ART DOCUMENTS]] [[PATENT DOCUMENTS]]

[0006] [[Patent Document 1]] Japanese Patent No. 7464109 [[SUMMARY OF THE INVENTION]] [[Problem to be Solved by the Invention]]

[0007] On the other hand, software supply chain attacks have been increasing in recent years. Software supply chain attacks are a method of attack that involves inserting malicious code during the software development process to infiltrate the systems of recipients or downloaders of that software.

[0008] Software supply chain attacks have also occurred in open-source software (OSS). For example, there have been cases where developers who joined an OSS development project under the guise of good intentions delayed the administrator's processing by generating a workload that exceeded the administrator's processing capacity, thereby obtaining the software approval authority (administrator privileges) granted to the administrator, and injecting malicious code into the OSS.

[0009] For these reasons, when building IT systems using existing software such as open-source software (OSS), there is a need for technology that can appropriately calculate the risk of malicious code being inserted during the development process and support the selection of software with a lower risk of such issues.

[0010] This invention has been made in view of these problems, and one of its objectives is to provide a software reliability calculation system, a control method for the software reliability calculation system, and a program that can appropriately calculate the risk of malicious code being inserted during the software development process. [Means for solving the problem]

[0011] A software reliability calculation system according to one embodiment of the present invention is a software reliability calculation system that calculates the risk of malicious code being inserted during the software development process as the reliability of the software, and comprises a processor and memory, and includes an information acquisition unit that acquires developer information for calculating the reliability of a developer who participates in the software development project and codes the software, and development project information for calculating the reliability of the development project, which represents the difficulty of the developer attempting to insert malicious code into the software within the development project, and a reliability calculation unit that calculates the reliability of the developer using the developer information and calculates the reliability of the development project using the development project information, and calculates the reliability of the software using the reliability of the developer and the reliability of the development project.

[0012] Furthermore, the problems disclosed in this application and their solutions will be made clear from the description in the section on embodiments for carrying out the invention and from the drawings. [Effects of the Invention]

[0013] This invention makes it possible to appropriately calculate the risk of malicious code being inserted during the software development process. [Brief explanation of the drawing]

[0014] [Figure 1] This is an overall diagram of the software reliability calculation system. [Figure 2] This figure shows an example of the functional configuration of a software reliability calculation system. [Figure 3] This diagram shows the configuration of the candidate software decision computer. [Figure 4] This diagram shows the configuration of the confidence management calculator. [Figure 5] This diagram shows the configuration of the confidence score calculator. [Figure 6] This is a diagram showing a list of candidate software. [Figure 7]FIG. 1 is a diagram showing a configuration information table. [Figure 8] FIG. 2 is a diagram showing a hierarchical structure of software. [Figure 9] FIG. 3 is a diagram showing a development project information table. [Figure 10] FIG. 4 is a diagram showing a developer table. [Figure 11] FIG. 5 is a diagram showing a metrics definition table. [Figure 12] FIG. 6 is a diagram showing a specific gravity value definition table. [Figure 13] FIG. 7 is a diagram showing a candidate software reliability table. [Figure 14] FIG. 8 is a flowchart showing the overall processing flow executed by a software reliability calculation system. [Figure 15] FIG. 9 is a flowchart showing the processing flow executed by a candidate software determination computer. [Figure 16] FIG. 10 is a diagram showing a prompt. [Figure 17] FIG. 11 is a flowchart showing the processing flow executed by a reliability management computer. [Figure 18] FIG. 12 is a flowchart showing the processing flow executed by a reliability management computer. [Figure 19] FIG. 13 is a flowchart showing the processing flow executed by a reliability presentation computer. [Figure 20] FIG. 14 is a diagram showing a user interface for inputting required functions and outputting candidate software. [Figure 21] FIG. 15 is a diagram showing a user interface for outputting software reliability. [Figure 22] FIG. 16 is a diagram showing a user interface for setting specific gravity values. DETAILED DESCRIPTION OF THE INVENTION

[0015] At least the following matters will become apparent from the description of the present specification and the accompanying drawings. Hereinafter, the present invention will be described with reference to the accompanying drawings in accordance with an embodiment of the present invention. <Overall Configuration> Figure 1 is a block diagram showing an example of the software reliability calculation system 1000 according to this embodiment.

[0016] The Software Reliability Calculation System 1000 is a computer system capable of calculating the risk of malicious code being inserted during the software development process as software reliability (hereinafter also referred to as software reliability).

[0017] In this embodiment, as an example, the software reliability calculation system 1000 is configured such that a candidate software determination computer 10, a reliability management computer 20, and a reliability presentation computer 30 are communicated with each other via a network 40. The network 40 is an information and communication network including the Internet, a LAN (Local Area Network), a telephone network, etc.

[0018] The candidate software determination computer 10 is an information processing device such as a computer that identifies software (candidate software described below) to be used for calculating software reliability. In this embodiment, the candidate software determination computer 10 identifies software (candidate software) that satisfies the functions (hereinafter also referred to as required functions) entered by workers such as designers and administrators in charge of design work for IT system construction, and outputs a list of candidate software. The workers input the functions that the IT system to be developed, such as a railway operation management system, should have as required functions into the candidate software determination computer 10. As will be described in detail later, an example of a user interface for the worker to input required functions into the candidate software determination computer 10 is shown in Figure 20.

[0019] Returning to Figure 1, the candidate software identified by the candidate software determination computer 10 may or may not be open-source software (OSS).

[0020] Furthermore, this candidate software may consist of one or more other software components (hereinafter referred to as subprograms, or simply software), or it may consist of a single software component without any subprograms. A subprogram may also consist of one or more other subprograms. Of course, a subprogram may or may not be open-source software (OSS).

[0021] As described above, candidate software and subprograms have a hierarchical structure as shown in Figure 8, for example. The configuration of such candidate software and subprograms can be identified by referring to the configuration information stored in the configuration information DB23 and configuration information table 61, which will be described later.

[0022] Returning to Figure 1, the reliability management computer 20 is an information processing device, such as a computer, that calculates the risk of malicious code being inserted during the software development process as the reliability of the software. The software that the reliability management computer 20 uses to calculate the reliability includes candidate software and each subprogram that makes up the candidate software.

[0023] As will be explained in more detail later, the reliability management computer 20 identifies subprograms hierarchically included in candidate software by performing a configuration information acquisition process on the candidate software, and calculates the software reliability by performing a reliability calculation process on these candidate software and subprograms.

[0024] The confidence score display computer 30 displays the software confidence score calculated by the confidence score management computer 20. Figure 21 shows the confidence score display computer 30 displaying the software confidence score.

[0025] Returning to Figure 1, the number of computers constituting the candidate software determination computer 10, the reliability management computer 20, and the reliability presentation computer 30 may be one of each, but is not particularly limited, and at least some may be composed of multiple computers. Alternatively, if the operator can identify candidate software without using the candidate software determination computer 10, or if the reliability management computer 20 includes the functions of the candidate software determination computer 10, the software reliability calculation system 1000 may be configured not to include the candidate software determination computer 10. Furthermore, by making the reliability management computer 20 include the functions of the reliability presentation computer 30, the software reliability calculation system 1000 can also be configured not to include the reliability presentation computer 30.

[0026] Furthermore, the candidate software determination computer 10, the reliability management computer 20, and the reliability presentation computer 30 may be operated by a single organization (such as a company or group) or by multiple organizations. In the case of operation by multiple organizations, the entire software reliability calculation system 1000 may be operated jointly, or at least some of the organizations operating the candidate software determination computer 10, the reliability management computer 20, and the reliability presentation computer 30 may not be the same.

[0027] Furthermore, the candidate software determination computer 10, the confidence management computer 20, and the confidence presentation computer 30 may be composed of physical computers as exemplified in this embodiment, or they may be composed of virtual machines or cloud computers built on physical computers.

[0028] Figure 2 shows an example of the functions of the software reliability calculation system 1000.

[0029] As described above, the software reliability calculation system 1000 includes a candidate software determination computer 10 that determines candidate software to be used for software reliability calculation, a reliability management computer 20 that calculates the software reliability of the candidate software, and a reliability presentation computer 30 that displays a list of candidate software and the calculated software reliability.

[0030] As shown in Figure 2, the candidate software determination computer 10 has a similar OSS suggestion function 11. The similar OSS suggestion function 11 identifies candidate software that satisfies the required functions based on the required functions entered by the worker, such as a designer, who is in charge of design work for IT system construction.

[0031] Specifically, when a user inputs a requested function, the similar OSS suggestion function 11 creates a prompt as shown in Figure 16 and inputs this prompt into the language model system 41. The similar OSS suggestion function 11 then retrieves a list of candidate software from the language model system 41 and stores it in the candidate software table 60, which will be described later.

[0032] The similar OSS suggestion function 11 then sends this list of candidate software to the confidence management calculator 20.

[0033] The reliability management computer 20 has an information acquisition function (information acquisition unit) 24, a configuration information acquisition function 21, and a reliability calculation function (reliability calculation unit) 22.

[0034] The information acquisition function 24 obtains a list of candidate software from the candidate software determination computer 10. Alternatively, if the operator can identify the candidate software without using the candidate software determination computer 10, the information acquisition function 24 obtains a list of candidate software entered by the operator into the reliability management computer 20.

[0035] As will be explained in more detail later, the information acquisition function 24 acquires developer information to calculate the reliability of developers who participate in software (candidate software or subprogram) development projects and code the software, and development project information to calculate the reliability of development projects, which represents the difficulty level when developers attempt to insert malicious code into the software within the development project.

[0036] The configuration information acquisition function 21 acquires configuration information that describes the subprograms that make up the candidate software. The configuration information acquisition function 21 acquires configuration information from, for example, the configuration information DB 23 provided by the reliability management computer 20. Alternatively, the configuration information acquisition function 21 may acquire configuration information from a so-called OSS configuration information management system, such as a package manager provided on the internet. The configuration information acquisition function 21 then saves the acquired configuration information to the configuration information table 61, which will be described later. Figure 7 shows how the configuration information is stored in the configuration information table 61.

[0037] The reliability calculation function 22 calculates the reliability of the candidate software. During this process, the information acquisition function 24 acquires developer information and development project information.

[0038] Developer information consists of one or more indicator values, each representing a numerical value of the evaluation result when a developer is evaluated using one or more evaluation criteria. Similarly, development project information consists of one or more indicator values, each representing a numerical value of the evaluation result when a development project is evaluated using one or more evaluation criteria. Examples of development project information and developer information are shown in Figures 9 and 10, respectively.

[0039] Returning to Figure 2, the information acquisition function 24 acquires development project information and profile information of developers participating in this development project from so-called OSS development management systems such as repository services provided on the internet. Then, using the profile information, the information acquisition function 24 acquires developer information of the developers participating in this development project from various websites on the internet and content such as SNS and blogs created by these developers.

[0040] The reliability calculation function 22 then calculates the reliability of the developer using developer information, and the reliability of the development project using development project information, and uses the reliability of the developer and the reliability of the development project to calculate the reliability of the software (candidate software and subprograms).

[0041] Furthermore, the reliability calculation function 22 links the calculated software reliability to the configuration information and stores it in the configuration information DB 23. This improves data reusability and reduces the costs associated with communication or reliability calculation.

[0042] The confidence level display computer 30 has a confidence level display function (confidence level storage unit) 31. The confidence level display function 31 stores the calculated confidence level of the candidate software in a candidate software confidence level table 65 in association with the identification information of the candidate software, and also displays this information stored in the candidate software confidence level table 65. <Candidate Software Decision Computer> Figure 3 shows an example of the hardware configuration of the candidate software determination computer 10. The candidate software determination computer 10 is a computer that includes a CPU 101, a network interface 102, an input / output device 103, a storage device 104, and memory 105.

[0043] The candidate software determination program 50 and the candidate software table 60 are loaded into the memory 105 from the storage device 104, and the candidate software determination program 50 is executed by the CPU 101, thereby realizing the various functions of the candidate software determination computer 10 according to this embodiment.

[0044] The storage device 104 is configured to have a non-temporary recording medium such as a hard disk.

[0045] Network I / F 102 connects to network 40 and communicates with it.

[0046] The input / output device 103 includes an input device such as a keyboard, mouse, or touch panel, and an output device such as a display. <Confidence Management Calculator> Figure 4 shows an example of the hardware configuration of the reliability management computer 20. The reliability management computer 20 is a computer that includes a CPU 201, a network interface 202, an input / output device 203, a storage device 204, and memory 205.

[0047] The memory 205 is loaded with the configuration information acquisition program 51, the reliability calculation program 52, the specific gravity value definition program 53, the configuration information table 61, the development project information table 62, the developer information table 63, the specific gravity value definition table 64, and the metrics definition table 66 from the storage device 204. The configuration information acquisition program 51, the reliability calculation program 52, and the specific gravity value definition program 53 are executed by the CPU 201, thereby realizing the various functions of the reliability management computer 20 according to this embodiment.

[0048] The storage device 204 is configured to have a non-temporary recording medium such as a hard disk. Furthermore, a configuration information DB 23 is built into the storage device 204.

[0049] Network I / F 202 is connected to network 40 and communicates with it.

[0050] The input / output device 203 includes an input device such as a keyboard, mouse, or touch panel, and an output device such as a display.

[0051] The configuration information DB23 may be stored in the storage device 204 of the reliability management computer 20, or it may be stored in a storage device on a cloud system (not shown) on the network 40. <Confidence Level Calculator> Figure 5 shows an example of the hardware configuration of the confidence score presentation computer 30. The confidence score presentation computer 30 is a computer that includes a CPU 301, a network interface 302, an input / output device 303, a storage device 304, and memory 305.

[0052] The reliability display program 54 and the candidate software reliability table 65 are loaded into the memory 305 from the storage device 304, and the various functions of the reliability display computer 30 are realized when the reliability display program 54 is executed by the CPU 301.

[0053] The storage device 304 is configured to have a non-temporary recording medium such as a hard disk.

[0054] Network I / F 302 connects to network 40 and communicates with it.

[0055] The input / output device 303 includes an input device such as a keyboard, mouse, or touch panel, and an output device such as a display. Figure 6 shows an example of a candidate software table 60. The candidate software table 60 stores a list of candidate software identified by the candidate software decision computer 10. Three candidate software examples are shown in Figure 6.

[0056] The candidate software table 60 contains a candidate software name 601 in a single record. The candidate software name 601 is an identifier for the candidate software. The candidate software name 601 is obtained by the candidate software determination program 50 or determined and stored by an operator.

[0057] Figure 7 shows an example of a configuration information table 61. The configuration information table 61 stores configuration information that indicates which software is used as a component of which other software. For example, Figure 7 illustrates the configuration information of each software with the usage relationships shown in Figure 8. In the example shown in Figure 8, "Material-ui" is configured by incorporating "OSS A", and "OSS A" is configured by incorporating "OSS B" and "OSS C".

[0058] The configuration information table 61 contains the software name 611, the parent software name 612, and the confidence level 613 in a single record.

[0059] Software name 611 is an identifier for the software (candidate software or subprogram).

[0060] The "Superior Software Name 612" field stores the identifier of the superior software that uses the software identified by "Software Name 611" as a component. If the top-level software (candidate software) is not used as a component by any other software, the field will be left blank.

[0061] The "Confidence Level 613" column stores the confidence level of the software identified by software name 611, as calculated by the confidence level management calculator 20. If the confidence level has been calculated by the confidence level management calculator 20 in the past, the value calculated at that time is pre-stored in the "Confidence Level 613" column. However, if the confidence level has never been calculated, the column is left blank.

[0062] The reliability management calculator 20 can improve processing efficiency by omitting the calculation of the software's reliability if a reliability value is already stored in the reliability 613 column. Alternatively, even if a reliability value is already stored in the reliability 613 column, the reliability management calculator 20 can recalculate the reliability and update it to a new reliability value because the current reliability value of the software may differ from the value at a past point in time.

[0063] The configuration information table 61 allows for understanding the dependencies between software components, such as those being used or being used by other software. This enables the software reliability calculation system 1000 to calculate software reliability that also takes into account the reliability of the lower-level software that makes up the candidate software.

[0064] The configuration information stored in the configuration information table 61 is the same as the configuration information stored in the configuration information database 23. In other words, the reliability management computer 20 reads the configuration information from the configuration information database 23 and stores it in the configuration information table 61. When the reliability of this software is updated, the reliability management computer 20 saves the updated configuration information to the configuration information database 23, thereby making the contents of the configuration information database 23 and the contents of the configuration information table 61 consistent.

[0065] In this way, by linking the reliability score 613 already calculated by the software reliability calculation system 1000 to the software name 611 and managing it in the configuration information DB 23 and configuration information table 61, data reusability can be increased, and the costs associated with communication or reliability calculation can be reduced.

[0066] Figure 9 shows an example of a development project information table 62. The development project information table 62 stores development project information for each software.

[0067] Development project information is used to calculate the reliability of a development project, which represents the difficulty of a developer attempting to insert malicious code into the software within the development project. It consists of one or more indicator values, each representing a numerical value of the evaluation result when the development project is evaluated using one or more evaluation items (metrics).

[0068] The reliability management calculator 20 obtains development project information by acquiring various relevant information from repository service systems on the internet and other sources, and calculating the values ​​of the above metrics.

[0069] The development project information table 62 contains the software name 621, metrics 622, and value 623 in a single record.

[0070] The software name 621 is the software identifier.

[0071] Metrics622 stores the names of various evaluation items related to the development project.

[0072] Value 623 represents the numerical evaluation result corresponding to metric 622. If the evaluation result is yes or no, a boolean value of 1 or 0 is stored. If no evaluation result exists for metric 622, the field will be blank.

[0073] Metrics 622 includes, for example, the number of administrators in a development project (the number of administrators in a development project who have the authority to approve software code modifications), the number of code modifications that have occurred in that development project in the last 90 days (the number of code modification requests from developers to administrators), the workload per administrator (the number of code modification requests per administrator), and the takeover risk (the likelihood that developers will gain approval authority in a development project), as shown in Figure 9.

[0074] Here, the workload per administrator is calculated by dividing the number of code modifications in the last 90 days by the number of administrators. This serves as an indicator of the amount of work each administrator has to do to review the code modifications, i.e., the workload on the administrators.

[0075] The risk of a takeover is quantified based on information such as whether the number of developers who made more code modifications than the administrators within the last 90 days exceeded the number of code modifications made by the administrators. If there are many developers updating the code more than the administrators, it can be judged that these developers are highly likely to be plotting to take over the development project (gain administrator privileges), or that this cannot be ignored.

[0076] The reliability management calculator 20 then calculates the reliability of the development project by taking the statistical values ​​(mean, maximum, minimum, median, etc.) of each metric that constitutes the development project information. In this manner, the reliability of the development project can be calculated based on the indicator values ​​of each metric, making it possible to calculate the software reliability more appropriately.

[0077] The development project information table 62 defines one or more such metrics 622 repeatedly for each software name 621. The items of metric 622 are not limited to those described above, and may be edited as desired by the worker, for example.

[0078] For example, in this embodiment, the content of the metrics 622 is defined by the metrics definition table 66 shown in Figure 11. Therefore, the content of the metrics 622 can be changed by updating the contents of the metrics definition table 66.

[0079] The content of Metric 622 reflects the software development structure, and therefore, by utilizing the development project information managed in Development Project Information Table 62, the reliability of the development project can be calculated more accurately. Furthermore, by taking the reliability of the development project into account when calculating software reliability, it becomes possible to calculate software reliability more appropriately.

[0080] Figure 10 shows an example of a developer information table 63. The developer information table 63 stores developer information about developers participating in a software development project.

[0081] Developer information is used to calculate the reliability of developers who participate in software development projects and perform software coding. It consists of one or more indicator values, each representing a numerical value of the evaluation result when a developer is evaluated using one or more evaluation items (metrics).

[0082] The reliability management calculator 20 obtains development project information by retrieving information related to developers participating in a development project from information about the development project obtained from an internet repository service system, and then using this information to determine the values ​​of the above metrics based on information obtained from blogs and social media, as well as information obtained through internet searches.

[0083] The developer information table 63 contains the developer name 631, metrics 632, and value 633 in a single record.

[0084] Developer name 631 is the developer's identifier.

[0085] Metrics 632 stores the names of various evaluation items related to developers.

[0086] Value 633 represents the numerical evaluation result corresponding to metric 632. If the evaluation result is yes or no, a boolean value of 1 or 0 is stored. If there is no evaluation result corresponding to metric 632, the field will be blank.

[0087] Metrics 632 includes information such as whether the developer's real name is publicly available (disclosure status of the developer's real name), the number of followers on social media (developer's software development ability), the name of the organization the developer belongs to (disclosure status of the developer's organization affiliation), and development experience on multiple projects (software development experience), as shown in Figure 10.

[0088] The reliability management calculator 20 then calculates the developer's reliability based on statistical values ​​(mean, maximum, minimum, median, etc.) of each metric that constitutes the developer information. In this manner, the developer's reliability can be calculated based on the indicator values ​​of each metric, making it possible to calculate a more appropriate software reliability.

[0089] In the developer information table 63, one or more such metrics 632 are repeatedly defined for each developer name 631. The items of metric 632 are not limited to those described above, and may be edited as desired by the worker, for example.

[0090] In this embodiment, the content of the metrics 632 is defined by the metrics definition table 66 shown in Figure 11. Therefore, the content of the metrics 632 can be changed by updating the contents of the metrics definition table 66.

[0091] The content of Metric 632 reflects the attack risk by developers participating in the software development project. Therefore, by utilizing the developer information managed in Developer Information Table 63, the trustworthiness of developers can be calculated more accurately. Furthermore, by taking into account the trustworthiness of developers when calculating software trustworthiness, it becomes possible to calculate software trustworthiness in a more appropriate manner.

[0092] Furthermore, the metrics in the development project information table 62 and the developer information table 63 may include other software evaluation indicators such as the last update date and bug density, as described in Patent Document 1.

[0093] Figure 11 shows an example of a metrics definition table 66. The metrics definition table 66 defines one or more evaluation items for evaluating development projects and developers.

[0094] By managing the content of metrics using metric definition table 66, the content of metrics can be flexibly changed, making it possible to calculate the reliability of the software more accurately.

[0095] Although not shown in Figure 11, the metrics definition table 66 also stores, for each metric, the data necessary to calculate its respective value (metric value), as well as the calculation formula for obtaining that metric value from that data.

[0096] Figure 12 shows an example of a specific gravity definition table (weighting coefficient table) 64. The specific gravity definition table 64 is a table that stores the weighting coefficients (specific gravity values) set for each evaluation item (metric) according to the importance of each evaluation item used to evaluate developers and development projects.

[0097] The specific gravity value definition table 64 contains metrics 641 and specific gravity value 642 in a single record.

[0098] Metric 641 stores the item names corresponding to metrics 622 in the development project information table 62 and metrics 632 in the developer information table 63, i.e., the metrics defined in the metrics definition table 66.

[0099] The specific gravity value 642 stores the weighting coefficient set according to the importance of each evaluation item (metric). The specific gravity value is set to a value within the range of 0 to 1, for example, depending on the importance of the metric.

[0100] The reliability management calculator 20 may calculate the reliability of a developer using the values ​​(indicator values) and weight coefficients of each metric that constitutes the developer information, and calculate the reliability of a development project using the values ​​(indicator values) and weight coefficients of each metric that constitutes the development project information. For example, the reliability management calculator 20 may calculate the reliability of a developer as a statistical value (mean, maximum, minimum, median, etc.) obtained by multiplying the values ​​of each metric that constitutes the developer information by the weight coefficient, and calculate the reliability of a development project as a statistical value (mean, maximum, minimum, median, etc.) obtained by multiplying the values ​​of each metric that constitutes the development project information by the weight coefficient.

[0101] More specifically, for example, if there are four metrics for developer information, and the values ​​of these metrics for a certain developer x are A1, B1, C1, and D1, and their respective weights are a1, b1, c1, and d1, the confidence management calculator 20 calculates the confidence level Tx of this developer x as shown in (Equation 1).

[0102] Tx=(A1×a1+B1×b1+C1×c1+D1×d1) / 4…(Formula 1) Then, when three developers x, y, and z are participating in this development project, and the confidence levels of each developer are Tx, Ty, and Tz, the confidence management calculator 20 calculates the confidence level T1 of the developers participating in this development project by averaging the confidence levels of each developer as shown in (Equation 2).

[0103] T1 = (Tx + Ty + Tz) / 3 …(Equation 2) On the other hand, regarding the reliability T2 of the development project, when there are four metrics of development project information, and their index values ​​are A2, B2, C2, and D2, and their respective weights are a2, b2, c2, and d2, the reliability management calculator 20 calculates the reliability T2 of the development project as shown in (Equation 3).

[0104] T2=(A2×a2+B2×b2+C2×c2+D2×d2) / 4…(Formula 3) This approach allows for the calculation of developer reliability and development project reliability by placing greater emphasis on metrics of higher importance, thereby enabling the calculation of more appropriate software reliability.

[0105] The reliability management calculator 20 accepts input of the specific gravity values ​​for each metric defined in the metric definition table 66 by executing the specific gravity value definition program 53 and displaying an input screen as shown in Figure 22.

[0106] The specific gravity definition program 53 is executed, for example, before calculating the software reliability, and the specific gravity value 642 arbitrarily set by the operator is stored in the specific gravity definition table 64.

[0107] This makes it possible to calculate developer reliability and development project reliability that reflect the workers' policies regarding the importance of metrics, thus enabling the calculation of more appropriate software reliability.

[0108] Figure 13 shows an example of a candidate software confidence table 65. The candidate software confidence table 65 stores the software confidence of each candidate software calculated by the confidence management computer 20, in association with the software identification information.

[0109] The candidate software confidence table 65 contains the candidate software name 651 and confidence level 652 in a single record.

[0110] Candidate software name 651 is an identifier for candidate software output by the candidate software determination program 50, or for candidate software identified by the operator.

[0111] The confidence level 652 stores the software confidence level value calculated by the confidence level calculation program 52.

[0112] The information in the candidate software reliability table 65 is presented to the operator by the reliability display program 54. Figure 21 shows how the software reliability of the candidate software is presented. In this configuration, the operator can check each candidate software and its software reliability at a glance, thereby obtaining useful information for software selection in IT system design. <Process Overview> Figure 14 is a flowchart showing an example of the overall processing of the software reliability calculation system 1000.

[0113] First, the candidate software determination computer 10 receives input for the required functions that the candidate software should have (step S10).

[0114] The candidate software determination computer 10 then selects candidate software that has the input required functions and outputs a list of candidate software (step S11).

[0115] Next, the reliability management computer 20 calculates the reliability of each candidate software (step S12). As will be described in detail later, the reliability management computer 20 performs a configuration information acquisition process to obtain the configuration information of the candidate software, and then performs a reliability calculation process to calculate the reliability of the candidate software. Furthermore, based on the acquired configuration information, the reliability management computer 20 calculates the reliability of the candidate software using the reliability of the developers who participate in the development project of the candidate software and subprograms (software) and code the software, and the reliability of the development project, which represents the difficulty of it being difficult for developers to attempt to insert malicious code into the software within the development project.

[0116] The confidence level calculator 30 then displays the confidence level of the candidate software (step S13).

[0117] Through the processes described in steps S10 to S13 above, a list of candidate software possessing the requested functions entered by the operator into the candidate software determination computer 10, along with the reliability score for each candidate software, is obtained. This allows the operator to understand the risk of malicious code being inserted during the software development process.

[0118] Figure 15 is a flowchart showing an example of the processing (candidate software determination process) performed by the candidate software determination computer 10.

[0119] First, the candidate software determination computer 10 accepts input for the requested function (step S20).

[0120] When the candidate software determination computer 10 receives this requested function, it creates a prompt as shown in Figure 16 (step S21). This prompt is created, for example, by adding the content of the requested function to a pre-created template. In the example shown in Figure 16, the part that says "Library to display tables in a web application" corresponds to the requested function, and the rest corresponds to the template. By appropriately editing and improving the content of the template, it becomes possible to obtain a list of candidate software that better matches the content of the requested function. The content of the prompt will be described later.

[0121] Next, the candidate software decision computer 10 sends the prompt created in S21 to the language model system 41, which is connected via a communication interface (step S22).

[0122] Furthermore, the language model system 41 has accumulated and is updated daily with the functions of various programs that have been published to date, making it possible to identify candidate software that possesses the requested functions described in the prompt and output a list of them.

[0123] The candidate software decision computer 10 obtains a list of candidate software from the language model system 41 (step S23).

[0124] The candidate software determination computer 10 stores the list of candidate software in the candidate software table 60 (step S24).

[0125] The candidate software determination computer 10 then outputs a list of candidate software (step S25).

[0126] Steps S20 to S23 of the above candidate software determination process make it possible to identify candidate software that satisfies the requested functions entered by the operator.

[0127] Figure 16 shows an example of a prompt created in the candidate software determination process described above. This prompt is created in step S21 of the candidate software determination process, including the requested functions entered by the operator, and is input to the language model system 41 in step S22. The example of the prompt is not limited to the above and may be arbitrarily modified to obtain a more accurate list of candidate software from the language model system 41.

[0128] Figure 17 is a flowchart showing an example of the configuration information acquisition process performed by the reliability management computer 20.

[0129] First, the confidence management calculator 20 reads the list of candidate software stored in the candidate software table 60 (step S30).

[0130] Next, the reliability management computer 20 executes a process to acquire configuration information for all candidate software stored in the candidate software table 60, and for all subprograms that can be identified by performing the following processes (steps S31 to S35).

[0131] If the configuration information of the relevant software (candidate software or subprogram) is included in the configuration information DB23 (step S32), the reliability management calculator 20 retrieves the relevant configuration information from the configuration information DB23 and stores it in the configuration information table 61 (step S33).

[0132] On the other hand, if the configuration information of the relevant software is not included in the configuration information DB23, the reliability management computer 20 obtains the configuration information of the software from a so-called OSS configuration information management system such as an internet package manager and stores it in the configuration information table 61 (step S34).

[0133] Here, the method for obtaining configuration information is not limited to the above; for example, it may be entered by an operator manually editing the configuration information table 61.

[0134] Steps S30 to S35 of the above configuration information acquisition process allow the acquisition of configuration information as information about the software (subprograms) that the candidate software uses as components.

[0135] Figure 18 is a flowchart showing an example of the confidence calculation process performed by the confidence management computer 20.

[0136] First, the reliability management calculator 20 reads the candidate software table 60, the configuration information table 61, the specific gravity value definition table 64, and the metrics definition table 66 (step S40).

[0137] Then, the reliability management computer 20 executes the processes in steps S41 to S56 for each candidate software stored in the candidate software table 60 (steps S41 to S56).

[0138] The reliability management computer 20 then refers to the configuration information stored in the configuration information table 61 to identify the hierarchical structure of the subprograms that make up the candidate software, and then executes the processes in steps S42 to S54 for each software in order from the lowest-level software (for example, "OSS B" and "OSS C" in Figure 8) to the highest-level software (for example, Material-ui in Figure 8) (S42 to S54).

[0139] First, the reliability management calculator 20 identifies the data (not shown) necessary to obtain the values ​​of each metric in the development project information stored in the metric definition table 66, and obtains that data from a so-called OSS development management system, such as a repository service available on the internet, calculates the values ​​of each metric, and stores them in the development project information table 62 (step S43).

[0140] The reliability management calculator 20 then identifies the data (not shown) necessary to obtain the values ​​of each metric in the developer information stored in the metric definition table 66, and obtains this data from sources such as the developer's profile information registered in the OSS development management system or posts from the developer's social media or blog, calculates the values ​​of each metric, and stores them in the developer information table 63 (step S44).

[0141] Next, the reliability management computer 20 performs the following steps S45 to S47 on the developer information of each developer participating in the software development project to be processed.

[0142] First, the reliability management calculator 20 normalizes the developer information values ​​(index values) 633 of each developer obtained in step S44, and calculates the reliability of each developer by calculating a weighted average using the weight values ​​642 of the weight value definition table 64 (step S46).

[0143] Normalizing the metric values ​​633 here means ensuring that the metric values ​​for all metrics in each developer's developer information fall within the same numerical range (for example, between 0 and 1). For example, in the column for value 633 shown in Figure 10, there are metrics such as "Number of Followers" whose numerical range is not defined, but all metrics, including such metrics, are normalized so that their numerical ranges fall within the same range (for example, between 0 and 1).

[0144] For this purpose, in this embodiment, for example, if three developers x, y, and z are participating in a development project, and the values ​​of a certain metric are α for developer x, β for developer y, and γ for developer z, and α < β < γ (i.e., the maximum value is γ), then developer x's value is set to α / γ, developer y's value to β / γ, and developer z's value to γ / γ (=1). In other words, each developer's metric value is corrected by dividing it by the maximum value. By performing this process for all metrics, the values ​​of all metrics for each developer can be made to be within the range of 0 to 1.

[0145] This approach makes it possible to standardize the influence of each metric value when calculating developer confidence, as all metric values, regardless of type, can be set to the same numerical range (e.g., 0 to 1).

[0146] Furthermore, in this embodiment, by multiplying each normalized index value by a specific gravity value of 642 (a1, b1, c1, d1, etc. in (Equation 1)), it becomes possible to appropriately reflect the importance of each metric set by the worker when calculating the developer's reliability.

[0147] For example, if the index values ​​A1, B1, C1, and D1 in (Equation 1) are normalized and modified to A1', B1', C1', and D1', the confidence level Tx' of developer x can be calculated as shown in (Equation 4).

[0148] Tx'=(A1'×a1+B1'×b1+C1'×c1 +D1'×d1) / 4...(Formula 4) Subsequently, the reliability management calculator 20 calculates the average reliability of all developers involved in the development of the software in question and uses this as the reliability of the software's developers (step S48).

[0149] For example, if the confidence levels of the three developers, calculated using (Equation 4), were Tx', Ty', and Tz' respectively, then the developer's confidence level T1' is: T1'=(Tx'+Ty'+Tz') / 3 …(Equation 5) It is determined by this method.

[0150] Next, the reliability management calculator 20 normalizes the values ​​(index values) 623 of each metric (metric value) of the development project information obtained in step S43, and calculates the reliability of the development project by calculating a weighted average using the weight values ​​642 of the weight value definition table 64 (step S49).

[0151] Here, normalizing the metric value 623 means ensuring that the metric values ​​for all metrics in the development project information fall within the same numerical range (for example, between 0 and 1).

[0152] For example, if the index values ​​A2, B2, C2, and D2 in (Equation 3) are normalized and modified to A2', B2', C2', and D2', the confidence level T2' of the development project can be calculated as shown in (Equation 6).

[0153] T2'=(A2'×a2+B2'×b2+C2'×c2 +D2'×d2) / 4...(Formula 6) The reliability management calculator 20 then calculates the software reliability T based on the developer's reliability T1' and the development project's reliability T2' (step S50).

[0154] The reliability management calculator 20 can calculate the software reliability T as the average of the developer's reliability T1' and the development project's reliability T2', for example, as shown in (Equation 7).

[0155] T=(T1'+T2') / 2...(Equation 7) Alternatively, the reliability management calculator 20 may calculate the software reliability T as a weighted average of the developer's reliability T1' and the development project's reliability T2', for example, as shown in (Equation 8).

[0156] T=(T1'×k1+T2'×k2) / 2...(Formula 8) However, k1 and k2 are weighting constants that satisfy k1 + k2 = 1.

[0157] In this way, by allocating the developer's reliability T1' and the development project's reliability T2' in a predetermined ratio, the software's reliability can be calculated in a balance that reflects the importance of each of the developer's and development project's information.

[0158] Alternatively, the reliability management calculator 20 may store the developer's reliability T1' as one of the metrics in the development project information table 62. In this case, since the developer's reliability T1' is included in the development project's reliability T2', the development project's reliability T2' becomes the software reliability T.

[0159] Subsequently, if the software for which the software reliability T is to be calculated is not the lowest-ranking software (step S51), the reliability management calculator 20 corrects the software reliability T to software reliability T' by taking into account the reliability Ti' of software lower than the target software (i = a natural number from 1 to n, where n is the number of subprograms lower than itself) as shown in (Equation 9) below (steps S51, S52).

[0160]

number

[0161] Here, Wp is a weighting coefficient that represents how much weight to give to the reliability rating Ti' of software lower than itself.

[0162] On the other hand, if the software for which the software reliability T was calculated is the lowest-ranking software (step S51), the reliability management computer 20 omits the process in S52. That is, it sets T'=T as in (Equation 10).

[0163] T'=T...(Formula 10) The reliability management computer 20 then sequentially stores the reliability T' of the software at each level, calculated as described above, into the configuration information table 61 (step S53).

[0164] Once the calculation of the confidence level T' for all software at each level is complete (step S54), the confidence management computer 20 stores the confidence level T' of the top-level software, which is the candidate software, in the candidate software confidence level table 65 (step S55). The confidence management computer 20 also transmits the software confidence level T' of the candidate software to the confidence level presentation computer 30. At this time, the confidence management computer 20 may also transmit development project information and developer information to the confidence level presentation computer 30.

[0165] The reliability management calculator 20 can calculate the reliability T' of the top-level candidate software by repeatedly performing the software calculation process for each level of software until it reaches the top-level candidate software, as described above.

[0166] Once the software confidence level T' for one candidate software is calculated in this way, the confidence management computer 20 similarly calculates the software confidence level T' for the other candidate software (step S56).

[0167] The above calculation example is just one example, and while we have explained how to calculate the software confidence score T' using a weighted average as shown in (Equation 9), this is not the only method; for example, a simple average may also be used.

[0168] Furthermore, the software confidence level T' does not necessarily have to be calculated using the above formulas; for example, a fixed confidence level may be assigned based on pre-defined rules, or it may be arbitrarily set by the IT system administrator.

[0169] As described above, when the candidate software is configured to incorporate one or more subprograms, the reliability management computer 20 according to this embodiment acquires developer information and development project information for each subprogram, calculates the developer reliability T1' and the development project reliability T2' for each subprogram based on the developer information and development project information, and then calculates the reliability T' of the candidate software based on the developer reliability T1' and development project reliability T2' calculated for each subprogram.

[0170] In this manner, the reliability T' of a candidate software can be calculated by taking into account the reliability of the development structure (development project) of each piece of software, including the subprograms that make up the candidate software, and the reliability of the developers involved in their development. This allows for the calculation of a more appropriate software reliability score. Furthermore, it enables the operator to more accurately understand how much the candidate software can be trusted.

[0171] Figure 19 is a flowchart showing an example of the confidence level display process performed by the confidence level display computer 30.

[0172] First, the confidence level calculator 30 reads the information stored in the candidate software confidence level table 65, the development project information table 62, and the developer information table 63, which it received from the confidence level management calculator 20 (step S60).

[0173] Next, the confidence level calculator 30 displays the candidate software name 651 and confidence level 652 stored in the candidate software confidence level table 65 (step S61). At this time, the confidence level calculator 30 may also display development project information and developer information that were used as the basis for calculating the software confidence level T', as shown in Figure 21.

[0174] By executing steps S60 to S61 of the reliability display process described above, each candidate software and its respective reliability level are displayed in a list. This allows the operator to easily check candidate software and their reliability levels in the context of IT system construction. <gui> Figure 20 shows an example of a similar OSS presentation screen, which is a user interface for an operator to input a requested function into a candidate software determination computer 10 and display a list of candidate software that meets that requested function.

[0175] When the operator enters the required function in the "Required Function" field on the similar OSS presentation screen and presses the "Submit" button, the candidate software determination computer 10 displays a list of candidate software that meets the required function in the candidate software field.

[0176] This similar OSS presentation screen is displayed on a window such as a web browser via the input / output device 103 when the candidate software determination computer 10 executes the candidate software determination program 50.

[0177] The similar OSS suggestion screen displays input fields for requested functions, a submit button, and a list of candidate software obtained from the candidate software table 60.

[0178] This allows users to input the required functions for software selection in IT system construction and view a list of software that meets those requirements.

[0179] Figure 21 shows an example of a confidence display screen, which is a user interface for displaying the software confidence level T' of candidate software.

[0180] When an operator enters a candidate software into the candidate software name field on the reliability display screen and presses the "Calculate Reliability" button, the reliability display calculator 30 displays the software reliability of each candidate software calculated by the reliability management calculator 20 in the reliability field, and also displays the development project information and developer information of the candidate software and each subprogram that constitutes the candidate software in the development project information field and developer information field, respectively.

[0181] In the example shown in Figure 21, the operator enters the candidate software in the candidate software name field. However, the confidence level display computer 30 may acquire a list of candidate software identified by the candidate software determination computer 10, and these candidate software programs may be automatically entered without the operator having to input them on the screen.

[0182] This confidence level display screen is displayed on a window such as a web browser via the input / output device 303 when the confidence level display computer 30 executes the confidence level display program 54.

[0183] The reliability display screen includes a reliability calculation button, which, when pressed by the user, displays the contents of the candidate software reliability table 65. Furthermore, as justification for the software reliability calculation, which takes into account the reliability of the development project and the developers, the contents of the development project information table 62 and the developer information table 63, as well as the logs used to obtain them, are displayed.

[0184] Figure 22 shows an example of the weight value definition screen, which is a user interface for setting the weights (weight values) of each metric in development project information and developer information.

[0185] The reliability management calculator 20 refers to the metrics definition table 66 and displays the metrics in the information name field of the weight value definition screen. The operator then enters the weight of each metric in the weight value field as a number in the range of 0 to 1 and presses the "Register" button. The reliability management calculator 20 then stores the weight values ​​of each metric in the weight value definition table 64.

[0186] The specific gravity value definition screen is displayed on a window such as a web browser via the input / output device 203 when the reliability management calculator 20 executes the specific gravity value definition program 53.

[0187] The specific gravity definition screen contains a table corresponding to the specific gravity definition table 64 and a registration button. After the operator enters the specific gravity value, they can press the registration button to register the entered information in the specific gravity definition table 64. <Conclusion> According to the configuration of this embodiment described above, it becomes possible to appropriately calculate the risk of malicious code being inserted during the software development process. Specifically, for candidate software that satisfies the required functions entered by the operator into the candidate software determination computer 10, it becomes possible to calculate the risk of malicious code being inserted during the software development process as a software reliability score.

[0188] At this time, the software reliability of the candidate software is calculated by taking into account the reliability of the development project, the reliability of the developers who participated in the development project, and the reliability of the development projects and the developers who participated in the development projects of the subordinate software (subprograms) that make up the candidate software. This makes it possible for the worker to select software with a lower risk of malicious code being inserted.

[0189] For example, in a development project with a small number of administrators and few well-intentioned developers, it can be relatively easy for a malicious developer to gain administrator privileges by placing a heavy burden on the administrators. Open-source software developed in such vulnerable projects is highly likely to become a target of software supply chain attacks.

[0190] Therefore, when selecting software during IT system design, it is important to take into account factors such as the software development structure and the possibility that the developers may be attackers.

[0191] In today's world, where OSS utilizes a vast amount of other OSS as its components, manually collecting and analyzing enormous amounts of development project and developer information is impractical from a man-hour standpoint. However, as described in this embodiment, by evaluating the development structure, including OSS development project information and developer information, and presenting the risk of malicious code insertion using a quantitative indicator called software reliability, it becomes possible to support software selection for building IT systems utilizing OSS.

[0192] Furthermore, this embodiment also provides, as elemental technologies for realizing this, a method for determining the risk of attack occurrence based on time-series data and a method for calculating reliability based on OSS dependencies.

[0193] One aspect of this embodiment is, for example, a reliability management computer 20 that calculates the reliability of software in the construction of an IT system, wherein the reliability management computer 20 includes a reliability calculation function that calculates the reliability of software based on software development project information and developer information.

[0194] This configuration allows IT system builders to select software while taking into account the software development structure.

[0195] Furthermore, this embodiment enables IT system builders to select software while taking into account the software development structure. For example, the software development structure includes metrics related to the development project, such as the number of code modifications and the number of managers, and metrics related to developers, such as whether their real names are publicly available and the number of followers on social media.

[0196] As mentioned above, the reliability management calculator 20 for calculating the reliability of the software includes a configuration information acquisition function 21 for acquiring configuration information of the software, and a reliability calculation function 22 for calculating reliability based on the software development system, taking into account the reliability of the software development system and the developers involved, based on information such as the number of administrators, the number of code modifications in the last 90 days, whether the developers' real names are publicly available on social media and the number of followers.

[0197] Furthermore, the reliability calculation function 22 uses the software configuration information obtained by the configuration information acquisition function 21 to calculate the reliability, taking into account the reliability of the software used as a component by the software.

[0198] Furthermore, by linking the reliability calculated by the reliability calculation function 22 to the software name and managing it in the configuration information DB 23, data reusability is enhanced, and the costs associated with communication or reliability calculation are reduced.

[0199] Furthermore, in addition to defining the specific gravity value 642 by the worker, the specific gravity value definition program 53 may be used to automatically set the value according to the metric name in the development project information. This is because, for example, open-source software (OSS) used in operating systems (OS) may be considered nearly complete and not updated for several years, and a large number of code modifications does not necessarily increase the reliability of the software.

[0200] Alternatively, if the update interval for a specific metric in the development project information is shorter than a predetermined period (for example, less than one month has passed since the last update), the weighting of that metric can be increased by a certain amount. By increasing the weighting of metrics that fluctuate rapidly in this manner, it becomes possible to calculate software reliability that more accurately reflects the current state.

[0201] Alternatively, after the reliability display calculator 30 calculates the software reliability, the reliability management calculator 20 may display the weighting value definition screen shown in Figure 22 each time, prompting the operator to review the weighting value. This configuration allows for immediate identification of any discrepancies the operator feels immediately after calculating the software reliability, and enables the weighting value to be reviewed so that a more accurate software reliability is calculated. This makes it possible to calculate a more appropriate software reliability.

[0202] Alternatively, the reliability management calculator 20 may revise the weighting values ​​to increase the variability of the reliability values ​​of multiple candidate software by learning the relationship between the reliability values ​​of candidate software calculated in the past and the weighting values ​​at that time using a learning model. In this configuration, the software reliability values ​​of each candidate software become more varied, making it easier for the operator to select candidate software with higher reliability.

[0203] As described above, attacks on the software supply chain targeting OSS with weak development structures are on the rise, posing a risk to the construction of IT systems using OSS. Therefore, this embodiment supports software selection by collecting information on OSS and its developers and presenting their reliability. This embodiment enables IT system developers to select software while taking into account the development structure of the OSS.

[0204] It should be noted that the present invention is not limited to the embodiments described above, and various modifications are included. For example, although the embodiments were described as supporting software selection in IT system construction, other embodiments are also possible, such as managing the risks of OSS already used in an IT system that is in operation, or operating as an OSS monitoring service.

[0205] Furthermore, the embodiments described above are detailed for the purpose of clearly illustrating the present invention and are not necessarily limited to those comprising all the configurations described. In addition, some of the configurations of the embodiments described above can be added, deleted, or replaced with other configurations, either individually or in combination.

[0206] Furthermore, each of the above configurations, functions, processing units, and processing means may be implemented in hardware, in whole or in part, for example, by designing them as integrated circuits. Alternatively, each of the above configurations and functions may be implemented in software by having the CPU interpret and execute programs that implement each function. Information such as programs, tables, and files that implement each function can be stored in memory, a recording device such as a hard disk or SSD (Solid State Drive), or a recording medium such as an IC card, SD card, or DVD.

[0207] Furthermore, the control lines and information lines shown are those deemed necessary for explanatory purposes, and not all control lines and information lines are necessarily shown in the actual product. In reality, it is safe to assume that almost all components are interconnected. [Explanation of Symbols]

[0208] 10 Candidate Software Decision Computer 11 Similar OSS presentation function 101 CPU 102 Network I / F 103 Input / Output Devices 104 Storage device 105 memory 20. Confidence Management Calculator 21. Configuration Information Acquisition Function 22. Confidence Calculation Function 23 Configuration Information Database 24. Information Acquisition Function 201 CPU 202 Network Interface 203 Input / Output Devices 204 Storage device 205 memory 30 Confidence Level Calculator 31. Confidence level display function 301 CPU 302 Network Interface 303 Input / Output Devices 304 Storage device 305 memory 40 Networks 41 Language Model Systems 50 Candidate Software Selection Program 51 Configuration Information Acquisition Program 52. Confidence Calculation Program 53. Specific Gravity Value Definition Program 54. Confidence level display program 60 Candidate Software Table 61 Configuration Information Table 62 Development Project Information Table 63 Developer Information Table 64 Specific Gravity Value Definition Table 65 Candidate Software Confidence Table 66 Metrics Definition Table 1000 Software Reliability Calculation System< / gui>

Claims

1. A software reliability calculation system that calculates the risk of malicious code being inserted during the software development process as the reliability of the software, Equipped with a processor and memory, An information acquisition unit that acquires developer information for calculating the reliability of a developer who participates in the software development project and codes the software, and development project information for calculating the reliability of the development project, which represents the difficulty of a developer attempting to insert malicious code into the software within the development project. A reliability calculation unit calculates the reliability of the developer using the developer information and the reliability of the development project using the development project information, and calculates the reliability of the software using the reliability of the developer and the reliability of the development project. A software reliability calculation system equipped with the following features.

2. A software reliability calculation system according to claim 1, The developer information is comprised of one or more index values, each representing a numerical value of the evaluation result when the developer is evaluated using one or more predetermined evaluation items. The aforementioned development project information is comprised of one or more index values, each representing a numerical value of the evaluation result when the development project is evaluated using one or more predetermined evaluation items. The reliability calculation unit calculates the reliability of the developer based on the statistical values ​​of each indicator value that constitutes the developer information, and calculates the reliability of the development project based on the statistical values ​​of each indicator value that constitutes the development project information. Software reliability calculation system.

3. A software reliability calculation system according to claim 2, A weighting coefficient table storing weighting coefficients set for each evaluation item according to the importance of each evaluation item used to evaluate the developer and the development project, Furthermore, The reliability calculation unit calculates a statistical value obtained by multiplying the index value of each evaluation item constituting the developer information by the weighting coefficient as the reliability of the developer, and calculates a statistical value obtained by multiplying the index value of each evaluation item constituting the development project information by the weighting coefficient as the reliability of the development project. Software reliability calculation system.

4. A software reliability calculation system according to claim 2, The aforementioned developer information is, An index value representing the software development capabilities of the aforementioned developer, An index value representing the software development experience of the aforementioned developer, An index value representing the status of the disclosure of the developer's real name, An indicator value representing the disclosure status of the organization to which the aforementioned developer belongs, An index value representing the level of awareness of the aforementioned developer, It consists of at least one of the following: The aforementioned development project information is, An index value representing the number of administrators who have the authority to approve code modifications of the software in the aforementioned development project, An index value representing the number of code modification requests from the aforementioned developer to the aforementioned administrator, An indicator value representing the number of applications per administrator, An index value representing the likelihood of the developer obtaining the approval authority in the aforementioned development project, Composed of including at least one of the following: Software reliability calculation system.

5. A software reliability calculation system according to claim 1, The reliability calculation unit calculates the reliability of the software by allocating the reliability of the developer and the reliability of the development project in a predetermined ratio. Software reliability calculation system.

6. A software reliability calculation system according to claim 1, A reliability storage unit that stores the results of calculating the reliability of the software in association with the identification information of the software, Furthermore, Software reliability calculation system.

7. A software reliability calculation system according to claim 1, If the aforementioned software is configured to incorporate one or more subprograms, The information acquisition unit acquires developer information and development project information for each of the subprograms. The reliability calculation unit calculates the reliability of the developer and the reliability of the development project for each subprogram based on the developer information and the development project information, and calculates the reliability of the software based on the developer reliability and the reliability of the development project calculated for each subprogram. Software reliability calculation system.

8. A control method for a software reliability calculation system equipped with a processor and memory, which calculates the risk of malicious code being inserted during the software development process as the reliability of the software, The aforementioned software reliability calculation system The following are obtained: developer information for calculating the reliability of a developer who participates in the software development project and codes the software, and development project information for calculating the reliability of the development project, which represents the difficulty of a developer attempting to insert malicious code into the software within the development project. The reliability of the developer is calculated using the developer information, and the reliability of the development project is calculated using the development project information. The reliability of the software is then calculated using the developer's reliability and the development project's reliability. A control method for a software reliability calculation system.

9. A program for causing a computer equipped with a processor and memory to calculate the risk of malicious code being inserted into the software during the software development process as the reliability of the software, To the aforementioned computer, A procedure for obtaining developer information for calculating the reliability of a developer who participates in the software development project and codes the software, and development project information for calculating the reliability of the development project, which represents the difficulty of a developer attempting to insert malicious code into the software within the development project. A procedure for calculating the reliability of the software using the developer information, the reliability of the development project using the development project information, and the reliability of the software using the developer reliability and the development project reliability. A program to execute.

Images