Software management system

Abstract

To provide a software management system capable of grasping a use state of an OSS including a development status of the OSS to be used for a project.SOLUTION: An information processing device of a software management system acquires an OSS list being information related to an OSS included in a change place of a source code of a program in the case that change of the source code of the program stored in a source code repository is approved and committed. The information processing device determines the development status included in the OSS list on the basis of a roll or code difference amount of an approval user approving the change of the source code, and stores the determined development status of the OSS and identification information of the OSS as OSS use state information in a storage device.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to a software management system. [Background technology]

[0002] Patent Document 1 discloses an information processing device (hereinafter referred to as "prior art") that detects software vulnerabilities. This information processing device determines which versions of software contain vulnerabilities based on multiple versions and their update histories. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2023-7169 A Summary of the Invention [Problem to be solved by the invention]

[0004] QA personnel need to comprehensively and timely understand the projects, deliverables, and development processes in which OSS containing vulnerabilities is used, regarding vulnerabilities contained in OSS (Open Source Software) used within a specific organization.

[0005] Conventional technology detects multiple versions of software and the vulnerabilities contained in each version, but does not provide information on vulnerabilities contained in each version by development stage. As a result, while it is possible to identify vulnerabilities in a specific version of software, it is not possible to know the development status of that version (for example, what stage of development it is in, or whether it has been released).

[0006] The present invention has been made to solve the above problems. That is, one of the objects of the present invention is to provide a software management system that can grasp the usage status of OSS used in a project, including the development status of the OSS. [Means for solving the problem]

[0007] In order to solve the above problem, the software management system of the present invention is a software management system having a first storage device in which a source code repository in which source code of a program constituting a project is stored, and a repository server that manages the change history of the source code, a management server including a second storage device in which user information, which is information about a user including the user's role, is stored, an internal information management server including a third storage device in which OSS usage information indicating the usage status of OSS used in the project is stored, and an information processing device configured to be able to send and receive information between the repository server, the management server, and the internal information management server, wherein when a change to the source code of the program stored in the source code repository is approved and committed by an approved user, the information processing device is configured to obtain an OSS list, which is information about the OSS included in the changed parts of the source code of the program, determine the development status of the OSS included in the OSS list based on the role of the approved user based on the user information or the code difference amount based on the change history of the source code, and store the determined development status of the OSS and identification information of the OSS in the third storage device as the OSS usage information. Effect of the Invention

[0008] According to the present invention, it is possible to grasp the usage status of OSS, including the development status of OSS used in a project. Note that the effects described here are not necessarily limited to those described herein, and may be any of the effects described in this disclosure. [Brief description of the drawings]

[0009] [Figure 1] FIG. 1 is a system configuration diagram showing an example of the configuration of a system including a software management system according to a first embodiment of the present invention. [Diagram 2]FIG. 2 is a diagram illustrating an example of a hardware configuration of an information processing device. [Diagram 3] FIG. 3 is a diagram for explaining a code difference table included in the information processing device. [Figure 4] FIG. 4 is a diagram for explaining the OSS usage status table held by the information processing device. [Diagram 5] FIG. 5 is a diagram for explaining a user information table held by the management server. [Figure 6] FIG. 6 is a diagram for explaining the update history information table held by the management server. [Figure 7] FIG. 7 is a diagram for explaining the OSS information table held by the in-house information management server. [Figure 8] FIG. 8 is a diagram for explaining a project information table held by the in-house information management server. [Figure 9] FIG. 9 is a diagram for explaining the OSS usage status table held by the in-house information management server. [Figure 10] FIG. 10 is a diagram for explaining the overall operation of the system. [Figure 11] FIG. 11 is a flowchart showing a process flow of the process determination process executed by the information processing device. [Figure 12] FIG. 12 is a flowchart showing the process flow of the process determination process executed by the information processing device of the software management system according to the second embodiment. [Figure 13] FIG. 13 is a system configuration diagram showing an example of the configuration of a system including a software management system according to the third embodiment. [Figure 14] FIG. 14 is a diagram for explaining the OSS vulnerability information table stored in the in-house information management server. [Figure 15] FIG. 15 is a flowchart showing a process flow executed by the information processing device. [Figure 16] FIG. 16 is a flowchart showing a process flow executed by the information processing device. [Figure 17A] FIG. 17A is a diagram showing an example of the project list screen. [Figure 17B] FIG. 17B is a diagram showing an example of the OSS usage status list screen G showing a list of software. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] Hereinafter, each embodiment of the present invention will be described with reference to the drawings. In addition, in all the drawings of the embodiments, the same or corresponding parts may be denoted by the same reference numerals.

[0011] In the following description, various information may be described in table format or in the form of records, etc., but the various information may be expressed in other data structures. Furthermore, when describing identification information, expressions such as "ID," "name," and "identification number" are used, but these are interchangeable. Furthermore, in the following description, processing may be described with a program or functional block as the subject, but the subject of the processing may be a CPU or a device instead of a program or functional block.

[0012] <<First embodiment>> A software management system according to a first embodiment of the present invention will be described. The software management system according to the first embodiment automatically determines the development status of OSS (Open Source Software) used in a project, and manages information related to the OSS used in the project so that the usage status including the development status of the OSS can be understood.

[0013] Fig. 1 is a system configuration diagram showing an example of the configuration of a system including a software management system according to the first embodiment. As shown in Fig. 1, the system includes an information processing device 100, a management server 200, an in-house information management server 300, a repository server 400, and a user terminal 500. These are connected to each other via a network such as the Internet NW1 so as to be able to communicate with each other (to be able to send and receive information).

[0014] The information processing device 100 includes a development history information acquisition unit 110, a vulnerability information acquisition unit 120, and a storage unit 130. A code difference table 131 and an OSS usage status table 132 are stored in the storage unit 130.

[0015] The management server 200 includes a storage unit 210. In the storage unit 210, a user information table 221 and an update history information table 222 are stored.

[0016] The in-house information management server 300 includes a storage unit 310. The storage unit 310 stores an OSS information table 311, a project information table 312, and an OSS usage status table 313.

[0017] The repository server 400 includes a storage unit 410. The storage unit 410 stores a source code repository 411. The repository server 400 has the source code repository 411 in which source code of programs constituting a project and the like are stored.

[0018] The repository server 400 records and manages the history of changes to source code made by each development user on the user terminal 500. When the content of work done by a development user in his or her own development environment (user terminal 500) is committed, the source code is reflected in the source code repository 411. When a new version of source code is committed, the changes made from the previous source code are recorded as the change history. In this example, when committing source code, approval by an approval user is required.

[0019] The development user operates his / her own user terminal 500 to perform a process for requesting a commit of the contents of the work done by the development user to the repository server 400. The approval user operates his / her own user terminal 500 to perform a process for approving the commit request to the repository server 400. When this series of processes is performed, the contents of the work done by the development user (changes to the source code at a specific location) are committed and reflected in the source code repository 411, and the code difference from the state of the source code at the time of the previous commit to the time of the current commit is recorded. The user terminal 500 is a terminal such as a PC (personal computer) that is used to create a project to be used by the user. Although the number of user terminals 500 is one in FIG. 1, the number of user terminals 500 may be multiple.

[0020] Fig. 2 is a diagram showing an example of a hardware configuration of the information processing device 100. As shown in Fig. 2, the information processing device 100 includes a CPU 2011, a ROM 2012, a RAM 2013, a non-volatile storage device 2014 capable of reading and writing data, a network interface 2015, and an input / output interface 2016. These are connected to each other via a bus 2017 so as to be able to communicate with each other. Note that the server 2 may be composed of multiple servers, may be a virtual server, or may be composed of computer resources (servers, storage, etc.) on the cloud.

[0021] The CPU 2011 is a computing device that loads various programs (not shown) stored in the ROM 2012 and / or the storage device 2014 into the RAM 2013 and executes the programs loaded into the RAM 2013 to realize various functions. As described above, various programs executed by the CPU 2011 are loaded into the RAM 2013, and data used when the CPU 2011 executes the various programs is temporarily stored in the RAM 2013. The ROM 2012 and / or the storage device 2014 are non-volatile storage media, and various programs are stored in the RAM 2013. The network interface 2015 is an interface for connecting the information processing device 100 to the network NW1. The input / output interface 2016 is an interface for connecting to an operating device such as a keyboard or a mouse, and a display (display device). At least a part of the processing performed by the CPU 2011 executing the programs may be executed by another computing device (for example, hardware such as an ASIC or an FPGA).

[0022] The development history information acquisition unit 110 and the vulnerability information acquisition unit 120 are implemented by programs stored in the ROM 2012 and / or the storage device 2014 and executed by the CPU 2011. The storage unit 130 is implemented by the storage device 2014.

[0023] The hardware configurations of the management server 200, the in-house information management server 300, the repository server 400, and the user terminal 500 are the same as those in Fig. 2. The storage unit 210 of the management server 200 is configured by a storage device 2014. The storage unit 310 of the in-house information management server 300 is configured by a storage device 2014. The storage unit 410 of the repository server 400 is configured by a storage device 2014.

[0024] For convenience, the storage unit 410 may also be referred to as a "first storage device." The storage unit 210 may also be referred to as a "second storage device." The storage unit 310 may also be referred to as a "third storage device."

[0025] 3 is a diagram for explaining the code difference table 131 included in the information processing device 100. As shown in FIG. 3, the code difference table 131 has update history IDs as columns for storing information (values). * 131a, a person who modified the project 131b, a development status 131c, an approved user name 131d, a project name 131e, a code difference 131f, and a comment 131g.

[0026] In the code difference table 131, information corresponding to each column regarding the code difference of the code change of the OSS is stored as information (records) on a row basis in association with each other. * In 131a, an ID for identifying the update history is stored. In 131b, a user's name is stored. In 131c, a development status is stored. This development status is stored based on the result of automatically determining the development status at the time of the code change by a process determination process (step 1015 in FIG. 10) executed by the information processing device 100 when the code change is approved, which will be described later. Examples of the types of development status include a "programming process", a "combination test process", a "linkage test process", a "installation and acceptance test process", a "system test process", and a "comprehensive test process". In 131d, the name of the user who approved the update (change) is stored. In 131e, the name of the project is stored. In 131f, information indicating the code difference is stored. In addition, the description of this information in the table is omitted. In 131g, the comment content is stored.

[0027] 4 is a diagram for explaining the OSS usage status table 132 of the information processing device 100. As shown in FIG. 4, the OSS usage status table 132 has, as columns for storing information (values), software ID * 132a, software name 132b, version 132c, file name 132d, hash value 132f, and development status 132g.

[0028] In the OSS usage status table 132, information corresponding to each column regarding the OSS usage status is stored as information (records) on a row basis in association with each other. * 132a stores the ID of the OSS. Software name 132b stores the name of the OSS. Version 132c stores the version of the OSS. File name 132d stores the name of the file. Hash value 132f stores the hash value of the OSS. Development status 132g stores the development status. Note that this development status is also stored based on the result of the development status at the time of the code change being automatically determined by the process determination process (step 1015 in FIG. 10) executed by the information processing device 100 when the code change is approved, which will be described later.

[0029] 5 is a diagram for explaining the user information table 221 that the management server 200 has. As shown in FIG. 5, the user information table 221 has columns (rows) for storing information (values), such as user ID, * 221a, a user name 221b, a project name 221c, and a role name 221d.

[0030] In the user information table 221, information corresponding to each column related to a user is stored as information (records) in rows in association with each other. * In 221a, the ID of the user who is a member of the project is stored. In the user name 221b, the name of the user is stored. In the belonging project name 222c, the name of the belonging project is stored. In the role name 221d, the role name of the user is stored.

[0031] 6 is a diagram for explaining the update history information table 222 possessed by the management server 200. As shown in FIG. 6, the update history information table 222 has columns (rows) for storing information (values), such as update history ID *222a, version 222b, development status 222c, approved user name 222d, project name 222f, code difference 222g, and comment 222h. In the update history information table 222, information corresponding to each column related to the update history of the project is stored as information (records) on a row-by-row basis in association with each other. Specifically, * 222a stores the ID of the update history of the project. Version 222b stores the version of the project. Development status 222c stores the development status. Development status 222c stores the status at the time of project update as the development status of the project (for example, programming process, combination test process, linkage test process, introduction, acceptance test process, system test process, or comprehensive test process). Approval user name 222d stores the name of the user who approved the update (change). Project name 222f stores the name of the project. Code difference 222g stores information indicating the code difference. Note that this information is omitted from the table. Comment 222h stores the content of the comment.

[0032] 7 is a diagram for explaining the OSS information table 311 held by the in-house information management server 300. As shown in FIG. 7, the OSS information table 311 has columns (rows) for storing information (values), such as software ID * The OSS information table 311 includes a software ID 311a, a software name 311b, a version 311c, a file name 311d, and a hash value 311e. The OSS information table 311 stores information corresponding to each column related to the OSS used in the project as information (records) on a row-by-row basis in association with each other. More specifically, the software ID * In 311a, the ID of the OSS is stored. In software name 311b, the name of the OSS is stored. In version 311c, the version of the OSS is stored. In file name 311d, the name of the file is stored. In hash value 311e, the hash value of the OSS is stored.

[0033] 8 is a diagram for explaining the project information table 312 held by the in-house information management server 300. As shown in FIG. 8, the project information table 312 has, as columns for storing information (values), project ID, * The project information table 312 includes a project ID 312a, a project name 312b, a project representative name 312c, and a correction required index 312d. In the project information table 312, information corresponding to each column related to the project is stored as information (records) on a row basis in association with each other. Specifically, * The ID of the project is stored in 312a. The name of the project is stored in the project name 312b. The name of the project representative is stored in the project representative name 312c. The correction required index 312d stores the correction required index.

[0034] 9 is a diagram for explaining the OSS usage status table 313 held by the in-house information management server 300. As shown in FIG. 9, the OSS usage status table 313 has columns (rows) for storing information (values), such as usage status ID, * 313a and project ID * 313b, software ID 313c, and development status 313d. In the OSS usage status table 313, information corresponding to each column regarding the OSS usage status is stored as information (records) on a row-by-row basis in association with each other. Specifically, * An ID indicating the usage status is stored in 313a. Project ID * The project ID is stored in 313b. The software ID 313c stores the software ID. The development status 313d stores the development status.

[0035] <Summary of the Invention> In conventional technology, OSS used in a project can be automatically extracted by an OSS detection tool, but the OSS is registered manually. This places a heavy burden on the project staff. Furthermore, it is unclear in which stage of development the OSS is used, and the necessary information that QA staff wants to know is lacking. It is time-consuming to manually register the OSS used during development, which places a burden on the development user. Therefore, it is desirable to automatically register the OSS used in the project in the database without the project developers having to be aware of it.

[0036] Therefore, in the software management system of the first embodiment, the information processing device 100 cooperates with the repository server 400 to assign a development process based on the role of the approver (approved user) who approved the commit at the time the source code is committed on the repository server 400, and automates the process up to the registration of OSS included in the programs that make up the project.

[0037] <Overview of operation> Fig. 10 is a diagram for explaining the overall operation of the system. Block BR1 in Fig. 10 shows a flowchart for explaining the operation of the user. Block BR2 shows a flowchart for explaining the operation of the software management system.

[0038] The user's action, which is a prerequisite for starting the system operation, will be described with reference to the flowchart of block BR1.

[0039] S900: A user registers project personnel and roles, etc., on the management server 200 via the user terminal 500. The management server 200 registers (updates) the user ID, user name, affiliated project name, and role name in the user information table 221 based on the information transmitted from the user terminal 500.

[0040] S910: The user performs work by importing source code files that constitute the project into the user terminal 500. When the user changes the source code of a program that constitutes the project, the user requests a code review and approval from an approval user via the user terminal 500.

[0041] S920: The approver (approved user) registers a comment in the repository server 400 and approves the code change via the approved user's user terminal 500. When the code change is approved, the change to the source code of the project is committed.

[0042] The flowchart shown in block BR2 is a flowchart showing a process flow executed by the information processing device 100. Note that this process flow is executed by the development history information acquisition unit 110 of the information processing device 100.

[0043] When the user executes the operation shown in block BR1, the code change is approved, and the project change is committed in the repository server 400, the information processing apparatus 100 starts the process from step 1000 and proceeds to step 1010.

[0044] Step 1010: The information processing device 100 executes an OSS detection tool against the source code repository 411, and outputs a list of OSS in the changed parts of the source code of the programs that constitute the project (OSS list). The OSS list includes the software name, software ID, and version of the OSS in the changed parts.

[0045] Step 1015: The information processing device 100 performs a process determination process. Through the process determination process, the development status of each OSS included in the OSS list is identified (determined). The details of the process determination process will be described later.

[0046] After that, the information processing device 100 proceeds to step 1020, and repeatedly executes the loop process of steps 1025 to 1045 described below until the end condition of the loop process (completion of execution for all detected OSS) is met. As a result, the in-house information management server 300 is searched for each OSS included in the OSS list, and it is confirmed whether or not an OSS equivalent to the OSS in the OSS list has been registered in the in-house information management server 300.

[0047] Step 1025: The information processing device 100 selects one of the OSSs included in the OSS list as the target for confirmation, searches the in-house information management server 300 by OSS name and / or file name, and searches whether an OSS equivalent to the OSS in the OSS list is registered in the OSS information table 311 of the in-house information management server 300.

[0048] Step 1030: The information processing device 100 determines whether or not the search returns a hit for an equivalent OSS. If the search returns no hits, the information processing device 100 determines "NO" and proceeds to step 1045. If the search returns a hit, the information processing device 100 determines "YES" and proceeds to step 1035.

[0049] Step 1040: The information processing device 100 determines whether or not an equivalent OSS exists based on the result of the determination in step 1035. If an equivalent OSS does not exist, the information processing device 100 determines "NO" and proceeds to step 1045. If an equivalent OSS exists, the information processing device 100 determines "YES", identifies the equivalent OSS, and proceeds to step 1050.

[0050] Step 1045: When proceeding to step 1045, the OSS to be checked that is included in the OSS list is not registered in the OSS information table 311 of the in-house information management server 300. Therefore, in this case, the information processing device 100 starts the OSS registration operation, registers the software ID, software name, version, file name, and hash value of the OSS to be checked in the OSS information table 311 of the in-house information management server 300, and proceeds to step 1050.

[0051] Step 1050: When proceeding to step 1050, an OSS equivalent to the OSS to be checked included in the OSS list is already registered in the OSS information table 311 of the in-house information management server 300. Therefore, in this case, the information processing device 100 selects the OSS equivalent to the OSS to be checked as the target for updating (registering) the information in the OSS usage status table 313.

[0052] The information processing device 100 judges whether or not the loop processing end condition is satisfied. If the loop processing end condition is not satisfied, the information processing device 100 judges "NO" and returns to step 1025, selects an OSS included in the list of OSSs for which the loop processing has not yet been executed as a confirmation target, and executes the loop processing of steps 1025 to 1045. If the loop processing end condition is satisfied, the information processing device 100 judges "YES" in step 1050 and proceeds to step 1055.

[0053] By executing the loop process, it is confirmed whether or not an OSS equivalent to the OSS included in the OSS list is registered in the OSS usage status table 313 of the in-house information management server 300.

[0054] If an OSS equivalent to an OSS included in the OSS list is registered in the OSS usage status table 313 of the internal information management server 300, the OSS equivalent to the OSS included in the OSS list is extracted (identified). Hereinafter, the OSS identified here is referred to as the "identified OSS."

[0055] If an OSS equivalent (the same or similar) to an OSS included in the OSS list is not registered in the in-house information management server 300, information about that OSS is not registered in the in-house information management server 300, so step 1045 is executed and the software ID, software name, version, file name and hash value of that OSS are stored in the OSS information table 311 of the in-house information management server 300, thereby registering the OSS in the in-house information management server 300. This newly registered OSS is also referred to as a "specific OSS."

[0056] Step 1055: As soon as the loop processing ends and confirmation of all OSS included in the OSS list is completed, the information processing device 100 registers (updates) the "usage ID," "project ID," "software ID," and "development status" for the specific OSS in the OSS usage status table 313 of the in-house information management server 300 based on the information acquired by the process determination processing (OSS usage status table 132 and code difference table 131). The information processing device 100 updates the update history information table 222 with the development status acquired by the process determination processing, etc.

[0057] Step 1095: The information processing device 100 temporarily ends this processing flow.

[0058] The information processing device 100 is capable of outputting and displaying an image showing information corresponding to the OSS usage status table 313 on a display device included in the user terminal 500 or a display device connected to the information processing device 100. Therefore, the user can check the usage status of the OSS used in each development status of the project by displaying information corresponding to the OSS usage status table 313 on a screen via the user terminal 500. Furthermore, the information processing device 100 is capable of outputting and displaying an image showing at least one of information corresponding to the user information table 221, the update history information table 222, the OSS information table 311, and the project information table 312 on a display device included in the user terminal 500 or a display device connected to the information processing device 100. Therefore, as shown in block BR3, the user (QA staff) can easily grasp the registered project name, development personnel, used OSS, and development status. The user (QA staff) can know the OSS used in the in-house project and the development status in real time.

[0059] <Step 1015> The above-mentioned process determination process will now be described in detail.

[0060] Fig. 11 is a flowchart showing the process determination process flow executed by the information processing device 100. When the information processing device 100 proceeds to step 1015 in Fig. 10, it starts the process determination process from step 1100, and after sequentially executing the processes of steps 1110 to 1120 described below, it proceeds to step 1195 and temporarily ends this processing flow.

[0061] Step 1105: The information processing device 100 acquires the comment, the person who made the change, the approval user name, the project name, and the code difference corresponding to the code change from the repository server 400. Based on the OSS list and this information acquired from the repository server 400, the information processing device 100 stores information in each column of the code difference table 131 except for the development status.

[0062] Step 1110: The information processing device 100 refers to (reads) the code difference table 131 and the user information table 221 of the management server 200, and inquires about and acquires the role of the change approver using the user name of the change approver as an argument.

[0063] Step 1115: The information processing device 100 identifies the development status for the OSS based on the acquired (returned) role of the change approver. That is, the information processing device 100 identifies the development status for the OSS by estimating the development status based on the role of the change approver. For example, the information processing device 100 identifies the development status by referring to a lookup table (not shown) that indicates the correspondence between role names and development statuses.

[0064] Step 1120: The information processing device 100 stores the identified development status in the development status of the code difference table 131, and associates the identified development status with the OSS (software) extracted (detected) in step 1105 and stores it in the OSS usage status table 132.

[0065] <Effects> As described above, the software management system according to the first embodiment of the present invention automatically assigns a development status to the OSS included in the deliverable of the project, and registers and manages the OSS in the in-house information management server 300. In this way, the software management system is able to grasp the development status of the OSS, and allows the user to easily grasp the development status of the OSS. For example, the user can easily grasp the development status of the OSS in which a vulnerability has been found. In the software management system, the management server 200, the in-house information management server 300, and the information processing device 100 cooperate with each other, so that when the source code of the project is committed on the repository server 400, the information processing device 100 assigns a development process to the used OSS based on the role information of the approved user who approved the commit, and automates the registration of the used OSS included in the deliverable in the in-house information management server 300.

[0066] <<Second embodiment>> A software management system according to a second embodiment of the present invention will now be described. As with the first embodiment, the software management system according to the second embodiment automatically determines the development status of OSS used in a project, and manages information about the OSS used in a project so that the usage status, including the development status, of the OSS can be understood. However, the software management system according to the second embodiment of the present invention differs from the software management system according to the first embodiment only in the following respects.

[0067] In the second embodiment, the process determination process is performed based on the amount of code change.

[0068] The following description will focus on these differences.

[0069] Fig. 12 is a flowchart showing the process determination process executed by the information processing device 100 of the software management system according to the second embodiment. The information processing device 100 executes the process flow shown in the flowchart of Fig. 12 instead of the process flow shown in the flowchart of Fig. 11. Other than the above, it is the same as the first embodiment.

[0070] When the information processing apparatus 100 proceeds to step 1015 in FIG. 10, it starts the process determination process from step 1200, and executes the processes from step 1205 to step 1220 described below in order, and then proceeds to step 1295 to temporarily end this processing flow.

[0071] Step 1205: The information processing device 100 acquires the comment, the person who made the change, the approval user name, the project name, and the code difference corresponding to the code change from the repository server 400. Based on the OSS list and this information acquired from the repository server 400, the information processing device 100 stores information in each column of the code difference table 131 except for the development status.

[0072] Step 1210: The information processing device 100 refers to (reads) the code difference table 131, acquires the code difference using the user name of the change approver as an argument, and compares the amount of change from the time of previous approval (commit time).

[0073] Step 1215: The information processing device 100 identifies a development status based on the amount of change acquired. The information processing device 100 refers to the update history information table 222 and identifies a development status corresponding to the code difference with the similar amount of change acquired. Since the amount of code change tends to differ depending on the process (for example, the amount of code change tends to be larger in the earlier process and smaller in the later process), the development status is identified by estimating a development status with a similar amount of change based on that tendency with reference to the update history information table 222. For example, the amount of change acquired this time is compared with the amount of change of the code difference in the update history information table 222, and the development status determined to have a similar amount of change is estimated to have a similar amount of change. For example, if the difference between the amount of change acquired this time and the amount of change of the code difference in the update history information table 222 is equal to or smaller than a threshold, it is determined that the amount of change is close, and if the difference between the amount of change acquired this time and the amount of change of the code difference in the update history information table 222 is greater than the threshold, it is determined that the amount of change is not close.

[0074] Step 1220: The information processing device 100 stores the identified development status in the development status of the code difference table 131, and associates the identified development status with the OSS (software) extracted (detected) in step 1205 and stores it in the OSS usage status table 132.

[0075] <Effects> As described above, the software management system according to the second embodiment of the present invention automatically assigns the development status of OSS included in the deliverable of the project, and registers and manages it in the in-house information management server 300. In this way, the software management system grasps the development status of the OSS, and allows the user to easily grasp the development status of the OSS. For example, the user can easily grasp the development status of an OSS in which a vulnerability has been found. In the software management system, the management server and the in-house information management server 300 cooperate with the information processing device 100, so that when the source code of the project is committed on the repository server 400, the information processing device 100 assigns the development process to the used OSS from the amount of code change, and automates the registration of the used OSS included in the deliverable in the in-house information management server 300.

[0076] <<Third embodiment>> A software management system according to a third embodiment of the present invention will be described. As in the first embodiment, the software management system according to the third embodiment automatically determines the development status of OSS used in a project and manages the OSS so that the usage status of the OSS can be understood. Furthermore, the software management system according to the third embodiment acquires information on OSS vulnerabilities, determines the degree of need for correction of the project according to the development status based on the information on vulnerabilities and the development status, and provides the degree of need for correction and recommended actions.

[0077] Fig. 13 is a system configuration diagram showing an example of the configuration of a system including a software management system according to the third embodiment. As shown in Fig. 13, the system is similar to the system shown in Fig. 1, except that a vulnerability information providing server 1300 is added.

[0078] The vulnerability information providing server 1300 includes a storage unit 1310. The storage unit 1310 stores an OSS vulnerability information table 1311. The hardware configuration of the vulnerability information providing server 1300 is the same as that of FIG. 2. The storage unit 1310 of the vulnerability information providing server 1300 is configured by the storage device 2014. For convenience, the storage unit 1310 may also be referred to as a "fourth storage device."

[0079] 14 is a diagram for explaining the OSS vulnerability information table 1311 held by the in-house information management server 300. As shown in FIG. 14, the vulnerability information table 1311 has columns (rows) for storing information (values), such as CVE-ID, * The OSS vulnerability information table 1311 includes columns 1311a, 1311b, 1311c, 1311d, 1311e, and 1311f. The OSS vulnerability information table 1311 stores information corresponding to each column related to OSS vulnerabilities as row-by-row information (records) in association with each other. Specifically, the CVE-ID * 1311a stores the CVE identification number (CVE-ID) of the Common Vulnerabilities and Exposures (CVE).

[0080] The software name 1311b stores the name of the OSS. The summary 1311c stores information indicating an overview of the vulnerability. The vulnerability detection version 1311d stores the version of the OSS in which the vulnerability was detected. The vulnerability score 1311e stores a vulnerability score that indicates the level of vulnerability. The countermeasures 1311f stores countermeasures against the vulnerability. The vulnerability information providing server 1300 collects information from outside via the Internet, and stores information corresponding to each column related to OSS vulnerabilities in the OSS vulnerability information table 1311.

[0081] <Summary> An overview of a software management system according to the third embodiment will be described. QA personnel desire to be able to detect and correct all high-risk projects without fail. Furthermore, QA personnel desire to be able to detect projects that require correction regarding OSS that are being used, without having to manually analyze the registered contents.

[0082] Therefore, the software management system of the third embodiment calculates and presents the correction indicators and recommended actions for the project's OSS based on the vulnerability risk (importance and number) and development status detected at the time the source code is committed on the repository server 400.

[0083] This allows QA personnel to thoroughly identify projects that are particularly high risk (projects that are in high need of correction).

[0084] <Specific operation> 15 is a flowchart showing a processing flow executed by the information processing device 100. The information processing device 100 executes this processing periodically, for example. This processing is executed by the vulnerability information acquisition unit 120 of the information processing device 100. This processing is executed periodically (for example, once a day), for example. The information processing device 100 starts processing from step 1500 and executes the processing from step 1505 to step 1530 described below in order, and then proceeds to step 1595 to temporarily end this processing flow.

[0085] Step 1505: The information processing device 100 acquires a list of OSS used in a specific project from the in-house information management server 300.

[0086] Step 1510 : The information processing device 100 acquires the latest vulnerability information from the vulnerability information database via the Internet, and stores the information in the OSS vulnerability information table 1311 of the vulnerability information server 1300 .

[0087] Step 1515: The information processing device 100, via the internal information management server 300, obtains from the vulnerability information providing server 1300 the latest vulnerabilities and scores corresponding to the OSS for calculating the correction index in the project information table 312, and, by referring to the OSS usage status table 313, associates (assigns and updates) them with the OSS used in the project.

[0088] Step 1520: The information processing device 100 calculates the correction index for each project based on the latest vulnerability corresponding to the OSS, the score, and the development status. The details of the process of step 1520 will be described later.

[0089] Step 1525: The information processing device 100 stores the calculated correction-required index for each project in the project information table 312 of the in-house information management server 300 in association with the project ID, project name, etc. Furthermore, the information processing device 100 refers to table TB0 to identify a recommended action corresponding to the correction-required index for each project.

[0090] Step 1530: The information processing device 100 notifies the project manager and the QA staff of the need-to-correct indicators assigned to each project and the recommended actions by notifying the user terminals 500 of the project manager and the QA staff of the need-to-correct indicators assigned to each project. An example of the notification screen is shown in Fig. 17A and Fig. 17B described later.

[0091] This allows the QA staff to be notified of projects that need correction from the system, so that they can understand which projects are most in need of correction and take appropriate measures according to the recommended actions.

[0092] Fig. 16 is a flowchart showing a processing flow executed by the information processing device 100. When the information processing device 100 proceeds to step 1520 in Fig. 15, it starts processing from step 1600, proceeds to step 1605, and determines whether or not a project (OSS used in a specific project) includes an OSS with a vulnerability that has a CVSS score of 9.0 or more, which is assigned in step 1515.

[0093] If the project includes an OSS with a vulnerability having a CVSS score of 9.0 or higher, the information processing device 100 judges "YES" in step 1610 and proceeds to step 1610, assigns a correction index A to the project, stores it in the project information table 312 of the internal information management server 300, and proceeds to step 1695 to temporarily terminate this processing flow.

[0094] If the project includes an OSS with a vulnerability whose CVSS score is less than 9.0, the information processing device 100 judges "NO" in step 1605, executes the processes of steps 1615 and 1620 described below in order, and then proceeds to step 1695 to temporarily terminate this processing flow.

[0095] Step 1615: The information processing device 100 refers to the OSS usage table 313 and table TB1 in Fig. 9, and calculates, for vulnerable OSS with a CVSS score less than 9.0, the average value of values ​​obtained by multiplying the CVSS score by a gradient value according to the development status of the OSS as an evaluation value. According to this table TB1, the gradient value of the development status becomes higher as the development status becomes later. It is set so that the later the development status becomes, the higher the necessity for correction becomes.

[0096] Step 1620: The information processing device 100 refers to the table TB2 and assigns a correction-needed index corresponding to the evaluation value (calculated value) calculated in step 1615 to the project.

[0097] An example of the notification screen mentioned above will be described. FIG. 17A is a diagram showing an example of a project list screen. As shown in FIG. 17A, the project list screen GM1 includes a table showing project IDs, project names, project representatives, and correction-required indicators. The table may also include recommended actions (measures) based on the OSS vulnerability information table 1311. A project manager or the like can check the degree of need for correction of a project by looking at this project list screen GM1. The project list screen GM1 in FIG. 17A may also include recommended actions corresponding to the correction-required indicators.

[0098] When a project ID on the project list screen GM1 is operated, the screen changes to one showing a list of software used by the project corresponding to the project ID. For example, when the user places the cursor CS1 on "Project-C" on the screen and executes a specific operation on the operation device, the OSS usage status list screen GM2 (FIG. 17B) showing a list of OSS used by the project corresponding to "Project-C" is displayed on the display device.

[0099] Fig. 17B is a diagram showing an example of the OSS usage status list screen GM2 showing a list of this software. As shown in Fig. 17B, the OSS usage status list screen GM2 includes a table including software ID, software name, version, vulnerability score, and development status. A project manager or the like can check the usage status, vulnerability, and development status of the OSS used in the project by looking at the OSS usage status list screen GM2.

[0100] <Effects> As described above, the software management system according to the third embodiment of the present invention can determine the degree of need for correction of vulnerabilities in OSS used in a project, taking into account the development status of the project. The software management system according to the third embodiment can allow the QA person to take the necessary measures by notifying the user terminal 500 of the QA person or the like of the determination result. The QA person can respond in a timely manner by, for example, automatically sending a corrective email to projects that are particularly in need of correction, based on the determination result. Instead of taking the same measures for all projects, the QA person can take corrective measures according to the level of risk in light of the development process.

[0101] <<Modifications>> The present invention is not limited to the above-described embodiments, and various modified examples can be adopted within the scope of the present invention. Furthermore, the above-described embodiments can be combined with each other without departing from the scope of the present invention. The process judgment process of the third embodiment may be executed by the process judgment process of the second embodiment. In the third embodiment, the above-described method for calculating the correction index is adopted as an example, but various calculation methods can be adopted. [Explanation of symbols]

[0102] 100...information processing device, 110...development history information acquisition unit, 120...vulnerability information acquisition unit, 130...storage unit, 131...code difference table, 132...OSS usage status table, 200...management server, 210...storage unit, 221...user information table, 222...update history information table, 300...in-house information management server, 311...OSS information table, 312...project information table, 313...OSS usage status table

Claims

1. a repository server having a first storage device in which a source code repository is stored in which source code of a program constituting a project is stored and which manages a change history of the source code; a management server including a second storage device in which user information, which is information about a user including a role of the user, is stored; an in-house information management server including a third storage device for storing OSS usage status information indicating the usage status of the OSS used in the project; an information processing device configured to be capable of transmitting and receiving information to and from the repository server, the management server, and the in-house information management server; 1. A software management system comprising: The information processing device includes: When a change to the source code of the program stored in the source code repository is approved and committed by an approved user, an OSS list is obtained, which is information about the OSS included in the change to the source code of the program; determining a development status of the OSS included in the OSS list based on a role of the approved user based on the user information or a code difference amount based on a change history of the source code; storing the determined development status of the OSS and identification information of the OSS in the third storage device as the OSS utilization status information; It was configured as follows: Software Management Systems.

2. 2. The software management system according to claim 1, The third storage device stores OSS information related to the OSS used in the project, The information processing device includes: After determining the development status of the OSS, referring to the OSS information, if an OSS equivalent to the determined OSS is present in the OSS information, the development status corresponding to the OSS equivalent to the determined OSS in the OSS usage status information is updated with the determined development status; When the OSS information does not include an OSS equivalent to the determined OSS, information regarding the OSS including identification information of the determined OSS is stored in the third storage device as the OSS information. It was configured as follows: Software Management Systems.

3. 2. The software management system according to claim 1, The information processing device includes: Obtaining OSS vulnerability information regarding vulnerabilities of the OSS; Calculating a correction need index indicating a degree of need for correction of vulnerabilities of the project in which the OSS is used based on the OSS vulnerability information and the development status; It was configured as follows: Software Management Systems.

4. 4. The software management system according to claim 3, a vulnerability information providing server including a fourth storage device in which the OSS vulnerability information including countermeasures against the vulnerability of the OSS is stored; The information processing device includes: The OSS vulnerability information is acquired from the vulnerability information providing server; determining the indicators of need for correction and a recommended action based on the measures corresponding to the indicators of need for correction based on the OSS vulnerability information and the development status; It was configured as follows: Software Management Systems.

5. 5. The software management system according to claim 4, the third storage device stores project information that is information related to the project; The information processing device includes: The calculated correction need index is associated with identification information of the project, and the result is stored as the project information in the third storage device. It was configured as follows: Software Management Systems.

6. 5. The software management system according to claim 4, The OSS vulnerability information includes a vulnerability score indicating a degree of vulnerability, The information processing device includes: Calculating the correction required index based on a value obtained by multiplying the vulnerability score by a gradient value according to the development status; It was configured as follows: Software Management Systems.

7. 7. The software management system according to claim 6, The correction necessity index is an index divided into a plurality of stages according to the degree of the necessity for correction, The information processing device includes: If the vulnerability score is equal to or greater than a threshold score, the need for remediation index is calculated to a level indicating the greatest vulnerability; If the vulnerability score is smaller than the threshold score, the correction need index is calculated based on a value obtained by multiplying the vulnerability score by a gradient value according to the development status. It was configured as follows: Software Management Systems.

8. 8. The software management system according to claim 7, The gradient value is a value that increases as the development status becomes later. Software Management Systems.

9. 2. The software management system according to claim 1, The information processing device includes: outputting an image showing the OSS usage status information to an external device including a display device, and displaying the image showing the OSS usage status information on the display device; It was configured as follows: Software Management Systems.

10. 6. The software management system according to claim 5, The information processing device includes: outputting the image showing the project information to an external device including a display device, and displaying the image showing the project information on the display device; It was configured as follows: Software Management Systems.

11. 7. The software management system according to claim 6, The information processing device includes: outputting an image showing information related to the OSS used by the project, including the development status, the vulnerability score, and the index of need for correction, to an external device including a display device, and displaying the image showing the information related to the OSS used by the project on the display device; It was configured as follows: Software Management Systems.

12. 5. The software management system according to claim 4, The information processing device includes: outputting an image showing the determined recommended action to an external device including a display device, and displaying the image showing the determined recommended action on the display device; It was configured as follows: Software Management Systems.

Images