Composition of management device, composition of management method, and composition of management program

Abstract

[Problem] The dependency relationships between multiple software components can be easily and appropriately detected. [Solution] A component management device (20) for managing the dependency relationships between multiple components in multiple software components includes: a component information receiving unit (21) for receiving component information about the composition of upper-level and lower-level components in multiple software components; and a dependency relationship parsing processing unit (22) for detecting the dependency relationships between multiple components in multiple software components based on the aforementioned component information about multiple software components and storing the aforementioned dependency relationships in a memory device (20).

Description

Composition of management device, composition of management method, and composition of management program This invention relates to the dependency relationships of complex number compositions in software for managing complex numbers. In recent years, cyberattacks against medical devices have increased, making security a critical issue. To prevent cyberattacks, regulatory authorities in various countries, led by the United States, and the International Medical Device Regulators Forum (IMDRF) have disclosed cybersecurity requirements for medical devices. The US FDA (Food and Drug Administration) guidelines define the cybersecurity requirements that medical device manufacturers should consider before and after the market launch of their devices. The IMDRF guidelines require minimizing safety risks that could harm patients throughout the entire product lifecycle, from the design phase to post-marketing. In April 2023, Japan's Ministry of Health, Labour and Welfare revised and issued guidelines related to medical devices. The revised guidelines, for medical devices using software, added requirements for specific assessment of cybersecurity risks and risk mitigation management. The guidelines also require customers to provide a Software Bill of Materials (SBOM) as part of their security documentation. A SBOM (Structured Business Object Model) is a list of components that manage the building blocks of software. It manages all the software components contained in a finished product, their dependencies, certifications, etc. In the medical field, medical device manufacturers create and manage SBOMs to identify medical devices potentially affected by component vulnerabilities. Customers also manage SBOMs for their own medical devices provided by the manufacturers. By using a shared SBOM between medical device manufacturers and customers, information can be easily shared when vulnerabilities are discovered in the components. Patent Document 1 discloses a technique for managing components provided from an unspecified number of sources. In the technique of Patent Document 1, a database of component information is managed by a database server, enabling a component retrieval server to perform searches for components managed by the database server. Furthermore, Patent Document 2 discloses a technique for users to retrieve information about necessary components. In the technique of Patent Document 2, by inputting search conditions specifying the execution environment and functions of a component from search statements and search selections, information about components that match or are similar to the search conditions can be retrieved from the database. [Prior Art Documents] [Patent Documents] [Patent Document 1] Japanese Patent Application Publication No. 2019-215621 [Patent Document 2] Japanese Patent Application Publication No. 2023-38730 [The problem the invention aims to solve] While the use of SBOMs is valued, several challenges exist when utilizing them. A single SBOM file only manages the parent-child relationships among the components contained within the software. Therefore, in managing the file base, understanding the dependencies and hierarchical structure among the components of multiple SBOMs is difficult. Furthermore, there is a possibility of vulnerability in dependent components, and the scope of this vulnerability can vary due to dependencies. However, without understanding the overall composition of multiple software programs, it is impossible to pinpoint the specific scope of impact, making effective risk management difficult. Furthermore, as a challenge in the medical field, medical device manufacturers need to manage the software configuration information of their medical devices, including the SBOM (Business Module Name) of third-party products, as part of the overall SBOM management for the medical device. Moreover, because medical devices undergo software updates for each customer, and each customer uses different versions of the medical device, managing the SBOM of the medical devices used by customers and understanding the scope of their vulnerabilities is difficult. In the technologies of Patent Documents 1 and 2, the components of database management are managed independently, and the dependencies between the components of the multiple software programs are not defined. Furthermore, because the relationships between the components are not defined, it is difficult to search for and determine the vulnerability of the components of the multiple software programs. The present invention, in view of the above, aims to provide a technique that can easily and appropriately detect the dependencies between multiple software components. [Means of the Problem] To achieve the above objective, a composition management device, which manages the dependencies between multiple compositions in multiple software programs, includes: a composition information receiving unit that receives composition information about the composition of higher-level and lower-level compositions in the multiple software programs; and a dependency relationship parsing processing unit that, based on the composition information of the multiple software programs, detects the dependencies between the multiple compositions in the multiple software programs and stores the dependencies in a memory device. [Effects of the Invention] According to the present invention, the dependencies between multiple software components can be easily and appropriately detected. The embodiments are described with reference to the drawings. Furthermore, the embodiments described below are not intended to limit the scope of the patent application, and not all elements and combinations thereof described in these embodiments are necessarily essential to the solution of this invention. Figure 1 is a diagram showing the overall configuration of a computer system in one embodiment. Computer system 1 includes a terminal device 11 and a component management device 20. The terminal device 11 and the component management device 20 are connected, for example, via a network 12. The network 12 can be, for example, a wired LAN (Local Area Network), a wireless LAN, or a WAN (Wide Area Network). Alternatively, the terminal device 11 and the component management device 20 can be directly connected via a cable or the like. Furthermore, the terminal device 11 and the component management device 20 can be configured as a single device. Figure 2 is a structural diagram of a component management device in one embodiment. The management device 20 comprises a processing unit 20a, a memory unit 20b, an input / output unit 20c, and a communication unit 20d. The processing unit 20a includes a component information update processing unit 21, a dependency relationship analysis processing unit 22, a retrieval processing unit 23, a vulnerability information update processing unit 24, and a risk calculation processing unit 25. The memory unit 20b includes a component information storage unit 26 and a vulnerability information storage unit 27. The component information storage unit 26 stores the component information database 50, the SAME information database 200, and the SIMILAR information database 220. The vulnerability information storage unit 27 stores the vulnerability information database 60. The input / output section 20c handles operator instructions, inputs / outputs various data, and outputs (displays) processing results. The communication unit 20d controls communication with other devices (such as terminal device 11) via network 12. The component information update processing unit 21 receives information about software components (component information) from the terminal device 11 via the input / output unit 20c or via the communication unit 20d, such as receiving SBOM (Software Bill of Materials) and storing the component information in the component information database 50. The dependency resolution processing unit 22, based on the component information of the new software (product) received by the component information update processing unit 21 and the component information in the component information database 50, resolves the dependency relationships between the components of multiple software products, and stores the resolution results in the SAME information database 200 and the SIMILAR information database 220. The resolved dependency relationships are categorized into two types: SAME with the same component (i.e., the component name and version are the same) and SIMILAR with similar components (i.e., the component name is the same but the version is different). Alternatively, it may resolve the dependency relationships of only SAME or SIMILAR. The retrieval processing unit 23 receives specified retrieval information (retrieval specified information) from the terminal device 11 via the input / output unit 20c or through the communication unit 20d, and extracts retrieval results containing groups of components that correspond to the retrieval specified information based on the information in the component information database 50. The retrieval specified information includes the retrieval method, retrieval content, and risk calculation specification. The retrieval method may include, for example, a method that uses the component that is the starting point (topmost) (starting point component) and the number of levels counted from it, or a method that uses the starting point component and the component that is the ending point (bottommost) (ending point component). The retrieval content is the specific retrieval conditions used by the retrieval method (i.e., information such as starting point component, number of levels, and ending point component). The risk calculation specification is the specification of indicators such as the risk value of the Common Vulnerability Scoring System (CVSS) used for risk calculation, or EOL (End of Life) and EOS (End of Service). Furthermore, the retrieval processing unit 23 outputs the extracted retrieval results via the input / output unit 20c or sends them to the terminal device 11 via the communication unit 20d. The retrieval processing unit 23 is an example of a retrieval result output control unit and a vulnerability information output control unit. The vulnerability information update processing unit 24 receives information about the vulnerability of a component (vulnerability information) from the input / output unit 20c or via the communication unit 20d from the terminal device 11, and stores the vulnerability information in the vulnerability information database 60. The vulnerability information update processing unit 24 is an example of a vulnerability information receiving unit and a vulnerability information estimation unit. The hazard calculation processing unit 25 calculates the vulnerability information (e.g., hazard level) of each component based on the search-specified information, the vulnerability information database 60, the component information database 50, the SAME information database 200, and the SIMILAR information database 220 received by the search processing unit 23. As a method for calculating the hazard level, the hazard level can be calculated using the CVSS hazard value; for example, the hazard level of the parent component (parent component) can be used as the average of the hazard values ​​of the components that become children (child components). Figure 3 is a configuration diagram of a terminal device and a component management device in one embodiment. Furthermore, a communication unit 20d is interposed between the component management device 20 and the terminal device 11, but this is omitted in Figure 3. The terminal device 11 includes an information update input unit 30, a search method input unit 31, a search content input unit 32, a risk calculation input unit 33, and a search result output unit 34. Information update input unit 30 receives component information and vulnerability information, sends component information to component information update processing unit 21, and sends vulnerability information to vulnerability information update processing unit 24. The search method input unit 31 receives a search method, for example, via the search screen 150 (refer to FIG. 15), and sends it to the search processing unit 23. The search content input unit 32 receives search content, for example, via the search screen 150, and sends it to the search processing unit 23. The risk level calculation input unit 33 receives a risk level calculation specification, for example, via the search screen 150, and sends it to the search processing unit 23. The search result output unit 34 receives search results from the search processing unit 23 and outputs (displays) the search results on the search result display screen (Figure 17, Figure 20, etc.). Figure 4 is a hardware configuration diagram of a component management device and a terminal device according to one embodiment. Since the terminal device 11 and the component management device 20 can have the same hardware structure, the same diagram will be used to illustrate them in this embodiment. The management device 20 and the terminal device 11 can be respectively composed of a personal computer or a general-purpose server or other computer 40. The computer 40 includes a CPU (Central Processing Unit) 41, memory 42, auxiliary memory 43, communication device 44, input device 45, output device 46, and reading device 47. These components 41 to 47 are connected to each other via an internal communication line 49 to send and receive data. CPU 41 loads various programs from auxiliary memory 43 into memory 42, and performs various processes by executing the predetermined programs. Memory 42 is, for example, RAM (Random Access Memory), which stores the programs executed by CPU 41 and necessary information. Auxiliary memory 43 is, for example, a hard drive or flash memory, which stores the programs executed by CPU 41 (such as component management programs) or data used by CPU 41. Communication device 44 is, for example, a wired LAN card or a wireless LAN card interface, communicating with other devices via network 12. Input device 45 is, for example, a mouse or keyboard, accepting user information input. Output device 46 is, for example, a monitor or printer, outputting (displaying, etc.) various information. Reading device 47 reads information from portable memory media (recording media) 48 such as CD-ROM and USB memory. In this embodiment, each processing unit of the processing unit 20a is implemented as a processing process consisting of a configuration management program executed by, for example, the CPU 41; the memory unit 20b is implemented by the CPU 41 using memory 42 or auxiliary memory device 43. Furthermore, the input / output unit 20c is implemented by the CPU 41 using input device 45, output device 46, read device 47, etc. Also, the communication unit 20d is implemented by the CPU 41 using communication device 44. The various programs executed by CPU 41 can be pre-stored in auxiliary memory device 43, or read from memory medium 48 containing various programs via reading device 47 as needed, or downloaded from other devices via communication device 44 as needed. Figure 5 is a diagram showing the composition of an implementation of an information database. The component information database 50 stores the component information of each software component used as a product as columns. Each column corresponds to the name of the software (product name). In this embodiment, the component information database 50 is created based on the SBOM information of the software received by the component information update processing unit 21. The information database 50 consists of rows 51 (Name), 52 (Version), 53 (ID), 54 (Link-ID), 55 (Packages), and 56 (Relationships). In line 51 of the Name section, the component name of the component that is a software parent (parent component) is stored. In line 52 of the Version section, the version information of the parent component is stored. In line 53 of the ID section, the unique ID of the parent component is stored. In this embodiment, the ID serves as both the component name and version information, but is not limited to these. In line 54 of the Link-ID section, a link is stored between the parent component and components that differ only in version. In Packages group 55, information about sub-components (sub-components) that are one or more parent components in the software is stored. Each sub-component has its own group of Packages group 55, Name group 55a, Version group 55b, and ID group 55c. Name group 55a stores the component name of the sub-component. Version group 55b stores the version information of the sub-component. ID group 55c stores the unique ID of the sub-component. In Relationships group 56, information on the dependency relationships between parent and child components in the software is stored. Each child component has an ID row 56a and a Type row 56b. ID row 56a stores the ID of the child component. Type row 56b stores the type of dependency relationship between parent and child components. Figure 6 is a diagram of the structure of a vulnerability information database in one implementation mode. The vulnerability information database 60 manages the vulnerability information of each component. In this embodiment, the vulnerability information database 60 is created based on the vulnerability information received by the vulnerability information update processing unit 24. The vulnerability information database 60 includes a Name row 61, a Version row 62, and an ID row 63 for each component. The Name row 61 stores the component name. The Version row 62 stores the component's version information. The ID row 63 stores the component's ID. The vulnerability information database 60 includes columns 64 (CVSS v3.0), 65 (CVSS v4.0), and 66 (EOL / EOS). Column 64 (CVSS v3.0) stores the risk values ​​resulting from the composition of CVSS v3.0. Column 65 (CVSS v4.0) stores the risk values ​​resulting from the composition of CVSS v4.0. Column 66 (EOL / EOS) stores information indicating whether the composition has become EOL / EOS. In this embodiment, the case of becoming EOL / EOS is stored as ○. Figure 7 is a diagram of the structure of an implementation of the SAME information database. SAME Information Database 200 manages information representing the correspondence between identical components in different software. SAME Information Database 200 stores items (rows) for each group of identical components. SAME Information Database 200 includes FROM column group 201 storing information about one component of the identical components and TO column group 211 storing information about another component of the identical components. FROM column group 201 includes Product column 202, Name column 203, Version column 204, and ID column 205. Product column 202 stores the name of the program to which the component belongs. Name column 203 stores the component name. Version column 204 stores the component's version information. ID column 205 stores the component's unique ID. Column group 211 contains columns 212 (Product), 213 (Name), 214 (Version), and 215 (ID). Column 212 stores the name of the program to which the component belongs. Column 213 stores the component name. Column 214 stores the component's version information. Column 215 stores the component's unique ID. Figure 8 is a structural diagram of an implementation of the SIMILAR information database. The SIMILAR database 220 manages information representing the correspondence between similar components in different software. "Similar" refers to components with the same name but different versions. The SIMILAR database 220 stores the items (rows) of each group of similar components. The SIMILAR database 220 includes a FROM column group 221 storing information about one component of a similar component and a TO column group 231 storing information about another component of the same component. FROM column group 221 contains Product column 222, Name column 223, Version column 224, and ID column 225. Product column 222 stores the name of the program to which the component belongs. Name column 223 stores the component name. Version column 224 stores the component's version information. ID column 225 stores the component's unique ID. Column group 231 includes columns 232 (Product), 233 (Name), 234 (Version), and 235 (ID). Column 232 stores the name of the program to which the component belongs. Column 233 stores the component name. Column 234 stores the component's version information. Column 235 stores the component's unique ID. Next, the processing actions in computer system 1 will be explained. Figure 9 is a flowchart of a database update process in one implementation. The information update input unit 30 of the terminal device 11 receives update information from the user regarding component information or vulnerability information (S70). Update information regarding component information may be, for example, the SBOM of newly released software. Vulnerability information regarding vulnerability information may be, for example, information about newly disclosed vulnerabilities in the components. Next, the information update input unit 30 of the terminal device 11 sends the received update information to the component management device 20 (S71). In contrast, in the component management device 20, the component information update processing unit 21 receives component information update information, and the vulnerability information update processing unit 24 receives vulnerability information update information (S72). The component information update processing unit 21 updates the component information database 50, the SAME information database 200, and the SIMILAR information database 220 based on the component information update information; the vulnerability information update processing unit 24 updates the vulnerability information database 60 based on the vulnerability information update information (S73). Next, the dependency resolution process performed in steps S72 and S73 will be explained. Figure 10 is a flowchart of the dependency resolution process in one embodiment. In Figure 10, the processing of step S90 corresponds to a part of the processing of step S72, and the processing of steps S91 to S96 corresponds to a part of the processing of step S73. The component information update processing unit 21 of the component management device 20 receives component information update information from the terminal device 11 (S90). Next, the component information update processing unit 21, in conjunction with the received component information update information and the information stored in the component information database 50, determines whether there exists a related component with an ID that matches the ID in ID row 55c of Packages row group 55 (i.e., whether there is an identical component) (S91). Furthermore, in this embodiment, although the determination of whether there is an identical component is based on whether the ID is the same, it is also possible to determine whether there is an identical component based on whether the component name and version are the same. As a result, there is a case where there is a parent composition with an ID that is consistent with the ID in ID row 55c (S91: Yes). The composition information update processing unit 21 combines the sub-composition with the parent composition that has the same ID as SAME, that is, as the same, and registers the group of such compositions as an item in the SAME information database 200 (S92), so that the processing proceeds to step S93. On the other hand, if there is no family member with an ID that matches the ID in ID row 55c (S91: No), the family member information update processing unit 21 will proceed to step S93. In step S93, the component information update processing unit 21 determines, in the received component information update information and the information stored in the component information database 50, whether there are similar components (i.e., whether there are similar components) that have the same component name in the Name row 55a of the Packages row group 55 and a different version in the Version row 55b. As a result, there are cases where the component names in Name line 55a are the same, but the versions in Version line 55b are different (S93: Yes). The component information update processing unit 21 combines the sub-components with the same component names and different versions with the parent components as SIMILAR, that is, similarly, it registers the group of such components as an item in the SIMILAR information database 220 (S94), and the processing proceeds to step S95. On the other hand, there is no case where the component name in Name line 55a is the same and the version in Version line 55b is different (S93: No), and the component information update processing unit 21 causes the processing to proceed to step S95. In step S95, the component information update processing unit 21 determines, in the received component information update information and the information stored in the component information database 50, whether there are parent components with the same component name in the Name row 51 and different versions in the Version row 52. As a result, there are cases where the component names in Name row 51 are the same, but the versions in Version row 52 are different (S95: Yes). The component information update processing unit 21 inputs the ID of the old version of the component into the Link-ID row 54 of the new version of the component (S96) and ends the processing. On the other hand, there is no situation where the component names in Name line 51 are the same and the versions in Version line 52 are different (S95: No), and the component information update processing unit 21 ends the processing. Next, a conceptual diagram is presented to represent the complex numbers that are analyzed by the dependency relation analytic process. Figure 11 is a first conceptual diagram showing the dependency relationships of a component in an implementation. Figure 11 is a conceptual diagram showing the composition of the components linked by the SAME relationships in the dependency relationships in the case where the SAME information database 200 shown in Figure 7 is created through dependency relationship resolution processing. Each software component is represented by a software frame 120. On the right shoulder of the software frame 120, the parent component version of the software corresponding to the software frame 120 is recorded. Within the software frame 120, the components constituting the software are represented by component frames 121. The component frame 121 records the name of the component. The parent component frame 121 and the child component frame 121 are connected by arrows 122 showing the dependency relationship described in the appended Type line 56b. Furthermore, the component boxes 121 of the components in the SAME information database 200 that are related to SAME are connected by arrows 123 with SAME attached. According to the conceptual diagram in Figure 11, the software component "C" containing component "A" of Ver.1.0 is the same as component "C" of Ver.1.2, and the software component "X" containing component "C" of Ver.1.2 is the same as component "X" of Ver.1.3. Figure 12 is a second conceptual diagram illustrating the dependency relationships of an implementation. Figure 12 is a conceptual diagram illustrating the composition of the SAME and SIMILAR linked by the dependency relationships in the case where the SAME information database 200 shown in Figure 7 and the SIMILAR information database 220 shown in Figure 8 are created through dependency resolution processing. In the conceptual diagram shown in Figure 12, in addition to the conceptual diagram shown in Figure 11, the component boxes 121 of the group of components with SIMILAR relationships in the SIMILAR information database 220 are connected by arrows 124 with SIMILAR attached. According to the conceptual diagram in Figure 12, the software component "C" containing component "A" of Ver.1.0 is similar to component "C" of Ver.1.2.1, and the software component "X" containing component "C" of Ver.1.2.1 is similar to component "X" of Ver.1.3. Next, the hazard calculation and processing caused by the hazard calculation and processing unit 25 will be explained. Figure 13 is an explanatory diagram of a hazard calculation process in one embodiment. Figure 13 shows an example of calculating the hazard of each component using the risk values ​​in CVSS v3.0, in a configuration where the component dependencies are as shown in Figure 11 and the vulnerability information database 60 is in the state shown in Figure 6. In this example, the hazard calculation processing unit 25 sets the hazard of the parent component as the average of the hazard of all sub-components. In Figure 13, the degree of danger of each component is displayed in the degree of danger box 125 located next to the component box 121. In the vulnerability information database 60, as shown in Figure 6, the risk values ​​(hazard levels) of the components "B", "Y", and "N" are recorded as 6.7, 4.8, and 3.5, respectively. The hazard calculation processing unit 25 calculates the hazard of component "X" in Ver. 1.3 as the average of the hazard ... Since component "X" of the software containing component "X" of version 1.3 and component "C" of version 1.2 is a SAME, the risk calculation processing unit 25 calculates the risk of component "X" of the software containing component "C" of version 1.2 as 3.5. Next, the hazard calculation processing unit 25 calculates the hazard of component "C" in Ver.1.2 as the average of the hazard values ​​of all sub-components "X" and "Y" of component "C" (3.5 and 4.8) to 4.2. Since component "C" of the software containing component "C" of version 1.2 and component "A" of version 1.0 is a SAME, the risk calculation processing unit 25 calculates the risk of component "C" of the software containing component "A" of version 1.0 as 4.2. Next, the hazard calculation processing unit 25 calculates the hazard of component "A" in Ver.1.0 as the average of the hazard values ​​of all sub-components "B" and "C" of component "A" (6.7 and 4.2 respectively) to 5.5 (rounded to the second decimal place). Based on this risk level, the processing can be calculated, and for components that have not been registered with corresponding risk values, the risk level can be easily and appropriately estimated. Next, the retrieval process in computer system 1 will be described. Figure 14 is a flowchart of a retrieval process in one embodiment. The search method input unit 31 of the terminal device 11 selects a search method from the user via the search screen 150 (see FIG15) (S80); the search content input unit 32 selects search content from the user (S81); and the risk calculation input unit 33 calculates the specified risk from the user (S82). Next, the search method input unit 31, the search content input unit 32, and the risk calculation input unit 33 send the search information, including the accepted search method, search content, and risk calculation specification, to the component management device 20 (S83). The retrieval processing unit 23 of the management device 20 receives retrieval information from the terminal device 11 (S84). Next, the retrieval processing unit 23 performs retrieval processing based on the received retrieval method, extracting the component information corresponding to the retrieval content from the component information database 50, the SAME information database 200, and the SIMILAR information database 220 (S85). Next, the hazard calculation processing unit 25 performs a hazard calculation specification based on the hazard information of the components registered in the vulnerability information database 60 and the dependency information of the components obtained by the search process, and calculates the hazard of each component included in the search results (S86). Next, the retrieval processing unit 23 sends the retrieval result obtained in step S85 and the risk calculated by the risk calculation process together as the retrieval result to the terminal device 11 (S87). The search result output unit 34 of the terminal device 11 receives the search results from the component management device 20 (S88) and displays the search results (S89). Next, let's explain about the search screen 150. Figure 15 is a diagram showing the configuration of a search screen in one embodiment. Furthermore, Figure 15 shows a search screen in which input is used to form a range of predetermined search levels from a starting point. The search screen 150 includes a search method selection bar 151, a search content input bar 152, a risk level calculation selection bar 153, and a search button 154. The search method selection bar 151 is the area for selecting and inputting a search method. Examples of search methods include methods that search from the starting point composition and the number of levels, and methods that search from the starting point composition and the ending point composition. The search screen in Figure 15 shows the selection of methods that search from the starting point composition and the number of levels. Furthermore, in the example of Figure 15, although the search method selection bar 151 is selected by pressing a button, it can also be selected from a drop-down list, for example. The search content input field 152 is the area for entering search content. Search content includes the starting point component ID, the ending point component ID, and the number of levels. Users must enter the search method selected in the search method selection field 151 in the search content input field 152. For example, if the search method selected in the search method selection field 151 is based on the starting point component and the number of levels, it is necessary to enter the starting point component ID and the number of levels; if the search method is based on the starting point component and the ending point component, it is necessary to enter the starting point component ID and the ending point component ID. Furthermore, in the example of Figure 15, although text input is accepted, it is also possible to display selectable components in a drop-down list and select from the drop-down list. The hazard calculation specification selection field 153 is the area for selecting the information used when specifying the hazard calculation composition. In this embodiment, the hazard calculation specification includes specifying the hazard value using CVSS v3.0, specifying the hazard value using CVSS v4.0, specifying the EOL / EOS, and specifying that no hazard is calculated. The search button 154 is pressed when a search is executed based on the search information entered on the search screen. After the search button 154 is pressed, the specified search information, including the search method, search content, and risk level, is calculated and sent to the component management device 20 to perform the search. Next, the retrieval process performed in steps S84 and S85 will be explained, specifically the retrieval process where the starting point composition and the number of levels are used as retrieval conditions. Figure 16 is a flowchart of the retrieval process when the starting point composition and the number of levels of an embodiment are used as retrieval conditions. In Figure 16, the process of step S100 corresponds to the process of step S84, and the processes of steps S101 to S107 correspond to the process of step S85. The retrieval processing unit 23 of the component management device 20 receives the component retrieval information from the terminal device 11 (S100). Next, the retrieval processing unit 23 determines whether there exists a parent component with an ID that matches the starting component ID of the retrieval information in the component information database 50 (S101). As a result, there is no parent component with an ID that matches the starting component ID of the search information (S101: No), and the search processing unit 23 ends the search processing. On the other hand, if there is a parent composition with an ID that is consistent with the starting point composition ID of the search information (S101: Yes), the search processing unit 23 sets the starting point composition to level 0 (S102) and initializes the variable N that maintains the level number to 1 (S103). The retrieval processing unit 23 extracts the composition of the ID of the ID row 56a of the Relationships row group 56, which is set as the N-1 level, from the information in the composition information database 50 as the composition of the N-1 level (S104). Next, the retrieval processing unit 23 refers to the SAME information database 200 and the SIMILAR information database 220, identifies all components that have the same (SAME) or similar (SIMILAR) relationship as components extracted as components of the Nth level, and extracts the identified components as components of the Nth level (S105). Next, the retrieval processing unit 23 determines whether variable N has reached the level of the retrieval information (S106). As a result, if variable N has reached the level of the retrieval information (S106: Yes), since this indicates that the detection of the composition up to the level specified by the retrieval information has ended, the retrieval processing unit 23 ends the processing. On the other hand, if the variable N does not reach the number of layers of information to be retrieved (S106: No), the retrieval processing unit 23 increases the variable N by 1 (S107) in order to retrieve the composition of the next layer, and the processing proceeds to step S104. According to this retrieval process, it is possible to retrieve the composition of multiple software within a range of a specified number of hierarchical levels from the starting point. Next, we will explain an example of a search result screen displayed by the search processing unit 23 and the search result output unit 34 when the starting point composition and the number of levels are used as search criteria. Figure 17 shows an example of a search result screen when the starting point composition and number of levels of an implementation form are used as search criteria. The search results screen 160 includes a search content display area 161 and a component dependency relationship display area 162. The specified search content is displayed in the search content display area 161. The component dependency relationship display area 162 displays a relationship diagram of the complex components extracted from the search process. The relationship diagram can be displayed in a form similar to the concept diagram shown in Figure 11, with each component displaying its calculated risk level as shown in Figure 13. In the example of Figure 17, the relationship diagram of the complex components is displayed, with extracted components or arrows connecting them highlighted compared to other components or arrows (e.g., extracted components and arrows connecting them are shown as solid black lines, while other components are shown as solid gray lines). In the example of Figure 17, although the component dependency relationship display area 162 is displayed as a relationship diagram, the relationships of the components can also be displayed on a text-based basis, for example. Any method can be used to represent the search results from the starting point component and the hierarchical level. Based on the search results screen 160, it is easy and appropriate to grasp the compositional relationships of multiple software components within a specified number of levels from the starting point. Furthermore, it is possible to determine the vulnerabilities of the multiple software components and easily grasp the scope of their impact. Next, the search processing for cases where the starting point and ending point are used as search criteria will be explained. Figure 18 is a diagram showing the composition of a search screen that uses the starting point and ending point of an embodiment as search criteria. The structure of the search screen 150 is the same as that shown in Figure 15. In this example, in the search method selection bar 151 of the search screen 150, the search is selected from the start point composition and the end point composition, and in the search content input bar 152, the start point composition and the end point composition are entered. Next, the retrieval process performed in steps S84 and S85 will be explained, specifically the retrieval process where the starting point and ending point are used as retrieval conditions. Figure 19 is a flowchart of the search process when the starting point and ending point of an embodiment are used as search conditions. In Figure 19, the process of step S110 corresponds to the process of step S84, and the processes of steps S111 to S114 correspond to the process of step S85. The retrieval processing unit 23 of the component management device 20 receives the component retrieval information from the terminal device 11 (S110). Next, the retrieval processing unit 23 determines whether, among the information in the constituent information database 50, there exists a constituent with an ID that matches the starting constituent ID of the retrieval information and a constituent with an ID that matches the ending constituent ID of the retrieval information (S111). As a result, there is no case where there is an ID that matches the starting point ID, or an ID that matches the starting point ID (S111: No). Since there is no result that meets the search criteria, the search processing unit 23 ends the search process. On the other hand, if there are components with IDs that are consistent with the starting component ID, and components with IDs that are consistent with the starting component ID (S111: Yes), the retrieval processing unit 23 retrieves the components contained in the Relationships row group 56 of the starting component, and searches for the routes of components that can be reached by the relationship of SAME or SIMILAR, for example, according to the prior order in the exploration method (S112). Next, the retrieval processing unit 23 determines whether there is a path from the starting point to the ending point among the retrieved paths (that is, whether there is a path that can reach the same ending point as the starting point) (S113). As a result, there is no path that can be formed from the starting point to the ending point (S113: No), because it means there is no path that meets the search criteria, and the search processing unit 23 ends the process. On the other hand, if there is a path that can be formed from the starting point to the ending point (S113: Yes), the retrieval processing unit 23 extracts the path from the starting point to the ending point (S114). According to this retrieval process, as a path that can be formed from the starting point to the ending point, it is possible to retrieve the path of the composition of multiple software. Next, we will explain an example of a search result screen displayed by the search processing unit 23 and the search result output unit 34 when the starting point and ending point are used as search criteria. Figure 20 shows an example of a search result screen when the starting point composition and number of levels of an implementation form are used as search criteria. The search results screen 180 includes a search content display area 181 and a component dependency relationship display area 182. The search content display area 181 displays the specified search content (i.e., the starting component ID and the ending component ID). The component dependency relationship display area 182 displays a graph of relationships between the complex components extracted from the search process. This graph can be displayed, for example, in the same format as the concept diagram shown in Figure 11. In the example of Figure 20, the graph of complex components is displayed, and the paths of the extracted components are emphasized compared to other components or arrows (e.g., extracted paths are shown as solid black lines, while other paths are shown as solid gray lines). In the example of Figure 20, although the component dependency relationship display area 182 is displayed as a graph, the relationships between components can also be displayed on a text-based basis, for example. Any method can be used to represent the path between the starting and ending components. Based on the search results screen 180, one can easily and appropriately grasp the relationship between the multiple software components of the path between the starting point and the ending point. Furthermore, the present invention is not limited to the above-described embodiments, and can be adapted and modified without departing from the spirit of the present invention. For example, in the above-described embodiment, although the search results are obtained by tracing the relationship between SAME and SIMILAR during the search process, it is also possible to obtain search results by tracing the relationship between either SAME or SIMILAR. Furthermore, in the above embodiments, some or all of the processing performed by the processor may be performed by hardware circuitry. 1: Computer System 10: Management Unit 11: Terminal Device 12: Network 20: Management Unit 20a: Processing Unit 20b: Memory Unit 20c: Input / Output Unit 20d: Communication Unit 21: Information Update Processing Unit 22: Dependency Resolution Processing Unit 23: Retrieval Processing Unit 24: Vulnerability Information Update Processing Unit 25: Risk Calculation Processing Unit 26: Information Storage Unit 27: Vulnerability Information Storage Unit [Figure 1] Figure 1 is an overall configuration diagram of a computer system according to an embodiment. [Figure 2] Figure 2 is a configuration diagram of a component management device according to an embodiment. [Figure 3] Figure 3 is a configuration diagram of a terminal device and a component management device according to an embodiment. [Figure 4] Figure 4 is a hardware configuration diagram of a component management device and a terminal device according to an embodiment. [Figure 5] Figure 5 is a configuration diagram of a component information database according to an embodiment. [Figure 6] Figure 6 is a configuration diagram of a vulnerability information database according to an embodiment. [Figure 7] Figure 7 is a configuration diagram of a SAME information database according to an embodiment. [Figure 8] Figure 8 is a configuration diagram of a SIMILAR information database according to an embodiment. [Figure 9] Figure 9 is a flowchart of a database update process according to an embodiment. [Figure 10] Figure 10 is a flowchart of a dependency resolution process according to an embodiment. [Figure 11] Figure 11 is a first conceptual diagram showing the dependency relationship of a component according to an embodiment. [Figure 12] Figure 12 is a second conceptual diagram showing the dependency relationship of a component according to an embodiment. [Figure 13] Figure 13 is an explanatory diagram of the hazard calculation process for one embodiment. [Figure 14] Figure 14 is a flowchart of the search process for one embodiment. [Figure 15] Figure 15 is a diagram showing the structure of the search screen for one embodiment. [Figure 16] Figure 16 is a flowchart of the search process when the starting point composition and number of levels of an embodiment are used as search criteria. [Figure 17] Figure 17 is an example of a search result screen when the starting point composition and number of levels of an embodiment are used as search criteria. [Figure 18] Figure 18 is a diagram showing the structure of a search screen when the starting point composition and ending point composition of an embodiment are used as search criteria. [Figure 19] Figure 19 is a flowchart of the search process when the starting point composition and ending point composition of an embodiment are used as search criteria. [Figure 20] Figure 20 is an example of a search result screen when the starting point composition and number of levels of an embodiment are used as search criteria. 20: Composition of management device 20a: Processing Department 20b: Memory Department 20c: Input / Output Section 20d: Ministry of Communications 21: Formation of the Information Update Processing Department 22: Dependency Relationship Analysis and Processing Department 23: Retrieval Processing Department 24: Vulnerability Information Update Processing Department 25: Hazard Calculation and Handling Department 26: Form an Information Preservation Department 27: Vulnerability Information Preservation Department

Claims

1. A composition management device for managing the dependencies of multiple compositions in multiple software, comprising: a composition information receiving unit for receiving composition information of the composition of a higher-level composition and a lower-level composition in the multiple software; a dependency resolution processing unit for detecting dependencies between the multiple compositions in the multiple software based on the composition information of the multiple software and storing the dependencies in a memory device; a vulnerability information receiving unit for receiving vulnerability information of at least some of the compositions; and a vulnerability information estimation unit for estimating vulnerability information of compositions without vulnerability information based on the dependencies.

2. The component management device as described in claim 1, wherein, The aforementioned dependency relationship is at least one of the relationships that are either identical in composition or have different versions of composition.

3. The component management device as described in claim 1 further comprises: a search processing unit that accepts the topmost component, which is the object of the search dependency relationship, and the search level as search conditions, and detects the component group that meets the search conditions based on the aforementioned dependency relationship; and a search result output control unit that outputs information of the detected component group.

4. The component management device as described in claim 1 further comprises: a search processing unit that accepts the topmost component and the bottommost component, which are objects of search dependencies, as search conditions, and detects component groups that conform to the search conditions based on the aforementioned dependencies; and a search result output control unit that outputs information of the detected component groups.

5. The component management device as described in claim 1, wherein, The aforementioned vulnerability information estimation unit estimates the vulnerability information of the higher-level components based on the vulnerability information of the lower-level components.

6. The component management device as described in claim 5, wherein, The aforementioned vulnerability information includes the degree of risk of the vulnerability of the aforementioned components; the aforementioned vulnerability information estimation unit estimates the degree of risk of the parent component by averaging the degree of risk of all sub-components.

7. The component management device as described in claim 1 further includes: a vulnerability information output control unit that outputs the estimated vulnerability information.

8. A composition management method, comprising a composition management device for managing the dependency relationships of complex compositions in complex software, wherein, Regarding the multiple software applications, the system accepts structural information about the higher and lower components of the software; based on the structural information about the multiple software applications, it detects the dependencies between the multiple components of the multiple software applications; it stores the aforementioned dependencies in a memory device; it accepts vulnerability information about at least a portion of the components; based on the aforementioned dependencies, it presumes the vulnerability information of the components without vulnerability information.

9. A composition management program that enables a computer to execute management software to manage the dependencies of complex compositions, wherein, The aforementioned component management program enables the aforementioned computer to perform the following functions: a component information receiving unit for receiving component information of the upper-level and lower-level components in multiple software; a dependency resolution processing unit for detecting the dependencies between the multiple components in the multiple software based on the component information of the aforementioned multiple software, and storing the aforementioned dependencies in a memory device; a vulnerability information receiving unit for receiving vulnerability information of at least some components; and a vulnerability information estimation unit for estimating the vulnerability information of components without vulnerability information based on the aforementioned dependencies.

Images