Component management device, component management method, and recording medium

Abstract

The present invention makes it possible to easily and appropriately detect dependencies of components of a plurality of types of software. This component management device 20 for managing dependencies of a plurality of components in a plurality of types of software, comprises: a component information update processing unit 21 which receives configuration information indicating the configurations of a high-level component and a low-level component in software for a plurality of types of software; and a dependency analysis processing unit 22 which detects, on the basis of the configuration information about the plurality of types of software, a dependency between a plurality of components spanning a plurality of types of software, and which stores the dependency in a component information holding unit 20.

Description

Component management device, component management method, and recording medium

[0001] The present invention relates to managing dependencies between components in software.

[0002] In recent years, cyberattacks on medical devices have been increasing, making security a critical issue. To prevent cyberattacks, regulatory authorities in the United States and other countries, as well as the International Medical Device Regulators Forum (IMDRF), have set out cybersecurity requirements for medical devices. Guidance published by the U.S. Food and Drug Administration (FDA) defines cybersecurity requirements that medical device manufacturers should consider before and after the sale of medical devices. The guidance published by the IMDRF calls for the reduction of security risks that could cause harm to patients throughout the entire product lifecycle, from the design stage to post-sale.

[0003] In Japan, the Ministry of Health, Labour and Welfare revised standards related to medical devices and issued a guidebook in April 2023. The revised standards added requirements for medical devices that use programs to identify and evaluate cybersecurity risks and implement management measures to mitigate those risks. The guidebook also requires the provision of a software bill of materials (SBOM) as one of the security documents for customers.

[0004] An SBOM is a bill of materials that manages the components of software, and it manages all the components that make up the software included in a product, as well as their dependencies and licenses. In the medical field, medical device manufacturers create and manage SBOMs to identify medical devices that may be affected by component vulnerabilities. Customers also manage SBOMs for the medical devices they own, which are provided by medical device manufacturers. Managing a common SBOM between medical device manufacturers and customers makes it easier to share information when vulnerabilities are discovered in components.

[0005] Patent Document 1 discloses a technology for managing components provided by an unspecified number of people. In the technology of Patent Document 1, a DB server has a database for managing information about components, and a component search server can search for components managed by the DB server. Furthermore, Patent Document 2 discloses a technology for searching for information about components that a user needs. In the technology of Patent Document 2, a user can input search conditions that specify the execution environment or functions of a component using search terms or search options, and search a database for information about components that match or are similar to the search conditions.

[0006] JP 2019-215621 A JP 2023-38730 A

[0007] While the use of SBOM is considered important, there are many challenges associated with its use. A single SBOM file only manages the parent-child relationships of the components included in a piece of software. Therefore, file-based management makes it difficult to grasp the dependencies and hierarchical structure between multiple SBOM components. Furthermore, vulnerabilities may affect components with dependencies, and the scope of impact of vulnerabilities changes depending on the dependencies. However, without understanding the overall configuration of multiple pieces of software, it is impossible to identify the scope of impact, making effective risk management difficult.

[0008] Another challenge in the medical field is that medical device manufacturers must manage the software configuration information of medical devices at the time of release, which requires management of the SBOM for the entire medical device, including the SBOM of third-party products. Furthermore, because medical device software is updated for each customer, resulting in different versions of medical devices being used by each customer, it is difficult to manage the SBOM of the medical devices used by each customer and to grasp the scope of the impact of component vulnerabilities.

[0009] In the technologies of Patent Documents 1 and 2, components managed in a database are managed independently of each other, and the dependency relationships between components across multiple software programs are not defined. Furthermore, because the relationships between components are not defined, it is difficult to search for components across multiple software programs and to determine vulnerabilities.

[0010] The present invention has been made in view of the above circumstances, and an object of the present invention is to provide a technique that can easily and appropriately detect dependencies between multiple software components.

[0011] In order to achieve the above-mentioned object, a component management device according to one aspect is a component management device that manages the dependencies of multiple components in multiple software programs, and includes a configuration information receiving unit that receives configuration information for the multiple software programs indicating the configuration of higher-level components and lower-level components in the software, and a dependency detection unit that detects dependencies between multiple components across the multiple software programs based on the configuration information for the multiple software programs, and stores the dependencies in a storage device.

[0012] According to the present invention, it is possible to easily and appropriately detect the dependency relationships between a plurality of software components.

[0013] FIG. 1 is a diagram illustrating the overall configuration of a computer system according to an embodiment. FIG. 2 is a diagram illustrating the configuration of a component management device according to an embodiment. FIG. 3 is a diagram illustrating the configuration of a terminal device and a component management device according to an embodiment. FIG. 4 is a diagram illustrating the hardware configuration of a component management device and a terminal device according to an embodiment. FIG. 5 is a diagram illustrating the configuration of a component information database according to an embodiment. FIG. 6 is a diagram illustrating the configuration of a vulnerability information database according to an embodiment. FIG. 7 is a diagram illustrating the configuration of a SAME information database according to an embodiment. FIG. 8 is a diagram illustrating the configuration of a SIMILAR information database according to an embodiment. FIG. 9 is a flowchart of a database update process according to an embodiment. FIG. 10 is a flowchart of a dependency analysis process according to an embodiment. FIG. 11 is a first conceptual diagram illustrating dependency relationships between components according to an embodiment. FIG. 12 is a second conceptual diagram illustrating dependency relationships between components according to an embodiment. FIG. 13 is an explanatory diagram of a risk calculation process according to an embodiment. FIG. 14 is a flowchart of a search process according to an embodiment. FIG. 15 is a diagram illustrating the configuration of a search screen according to an embodiment. FIG. 16 is a flowchart of a search process according to an embodiment when a starting component and a number of layers are used as search conditions. Fig. 17 is an example of a search result screen when a starting component and a number of layers are used as search conditions according to an embodiment. Fig. 18 is a configuration diagram of a search screen when a starting component and an end component are used as search conditions according to an embodiment. Fig. 19 is a flowchart of search processing when a starting component and an end component are used as search conditions according to an embodiment. Fig. 20 is an example of a search result screen when a starting component and an end component are used as search conditions according to an embodiment.

[0014] The following description of the embodiments will be given with reference to the drawings. Note that the embodiments described below do not limit the scope of the invention as claimed, and not all of the elements and combinations thereof described in the embodiments are necessarily essential to the solution of the invention.

[0015] FIG. 1 is a diagram showing the overall configuration of a computer system according to one embodiment.

[0016] The 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 via, for example, a network 12. The network 12 is, for example, a wired local area network (LAN), a wireless LAN, or a wide area network (WAN). The terminal device 11 and the component management device 20 may be directly connected via a cable or the like. Alternatively, the terminal device 11 and the component management device 20 may be configured as a single device.

[0017] FIG. 2 is a configuration diagram of a component management device according to an embodiment.

[0018] The component management device 20 includes a processing unit 20a, a storage unit 20b, an input / output unit 20c, and a communication unit 20d.

[0019] The processing unit 20 a includes a component information update processing unit 21 , a dependency analysis processing unit 22 , a search processing unit 23 , a vulnerability information update processing unit 24 , and a risk calculation processing unit 25 .

[0020] The storage unit 20b includes a component information holding unit 26 and a vulnerability information holding unit 27. The component information holding unit 26 holds a component information database 50, a SAME information database 200, and a SIMILAR information database 220. The vulnerability information holding unit 27 holds a vulnerability information database 60.

[0021] The input / output unit 20c receives instructions from an operator, inputs and outputs various data, and outputs (displays) processing results.

[0022] The communication unit 20d controls communication with other devices (for example, the terminal device 11) via the network 12.

[0023] The component information update processing unit 21 receives information about software components (component information), such as a Software Bill of Materials (SBOM), from the input / output unit 20c or from the terminal device 11 via the communication unit 20d, and stores the component information in the component information database 50.

[0024] The dependency analysis processing unit 22 analyzes the dependency relationships between components of multiple software programs 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, and stores the analysis results in the SAME information database 200 and the SIMILAR information database 220. The dependency relationships to be analyzed are of two types: SAME, which indicates that the components are the same, i.e., the component names and versions are the same, and SIMILAR, which indicates that the components are similar, i.e., the component names are the same but the versions are different. Note that it is also possible to analyze only one of the SAME and SIMILAR dependency relationships.

[0025] The search processing unit 23 receives information specifying a search (search specification information) from the input / output unit 20c or from the terminal device 11 via the communication unit 20d, and extracts search results including a group of components that match the search specification information based on information in the component information database 50. The search specification information includes a search method, search content, and risk calculation specification. Examples of search methods include a search method using a starting (top-level) component (starting component) and the number of layers from that component, and a search method using a starting component and an ending (bottom-level) component (ending component). The search content is specific search criteria used in the search method, such as the starting component, the number of layers, and the ending component. The risk calculation specification is a specification of indicators used to calculate the risk, such as a Common Vulnerability Scoring System (CVSS) risk value, EOL (End of Life), and EOS (End of Service). The search processing unit 23 outputs the extracted search results via the input / output unit 20c or transmits them to the terminal device 11 via the communication unit 20d. The search processing unit 23 is an example of a search result output control unit and a vulnerability information output control unit.

[0026] The vulnerability information update processing unit 24 receives information about component vulnerabilities (vulnerability information) from the input / output unit 20c or from the terminal device 11 via the communication unit 20d, 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.

[0027] The risk calculation processing unit 25 calculates vulnerability information, for example, the risk level, of each component based on the search specification information received by the search processing unit 23, the information in the vulnerability information database 60, the information in the component information database 50, the information in the SAME information database 200, and the information in the SIMILAR information database 220. As a method of calculating the risk level, when the risk level is calculated using a CVSS risk value, for example, the risk level of a parent component (parent component) may be set to the average value of the risk values ​​of its child components (child components).

[0028] 3 is a configuration diagram of a terminal device and a component management device according to an embodiment. Note that a communication unit 20d is interposed between the component management device 20 and the terminal device 11, but is omitted in FIG.

[0029] The terminal device 11 has 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 .

[0030] The information update input unit 30 receives component information and vulnerability information, and transmits the component information to the component information update processing unit 21 and the vulnerability information to the vulnerability information update processing unit 24 .

[0031] The search method input unit 31 accepts a search method via, for example, a search screen 150 (see FIG. 15 ) and transmits it to the search processing unit 23. The search content input unit 32 accepts search content via, for example, the search screen 150 and transmits it to the search processing unit 23. The risk calculation input unit 33 accepts a risk calculation specification via, for example, the search screen 150 and transmits it to the search processing unit 23.

[0032] The search result output unit 34 receives the search results from the search processing unit 23, and outputs (displays) the search results on a search result display screen (FIGS. 17, 20, etc.).

[0033] 4 is a hardware configuration diagram of a component management device and a terminal device according to an embodiment. Since the terminal device 11 and the component management device 20 can have similar hardware configurations, the same diagram will be used for convenience in the description of this embodiment.

[0034] The component management device 20 and the terminal device 11 can each be configured by a computer 40 such as a personal computer or a general-purpose server.

[0035] The computer 40 includes a CPU (Central Processing Unit) 41, a memory 42, an auxiliary storage device 43, a communication device 44, an input device 45, an output device 46, and a reading device 47. These components 41 to 47 are connected via an internal communication line 49 so as to be able to send and receive data.

[0036] The CPU 41 loads various programs from the auxiliary storage device 43 into the memory 42 and executes the predetermined programs to perform various processes. The memory 42 is, for example, a random access memory (RAM) and stores the programs executed by the CPU 41 and necessary information. The auxiliary storage device 43 is, for example, a hard disk or flash memory and stores the programs executed by the CPU 41 (for example, a component management program) and data used by the CPU 41.

[0037] The communication device 44 is, for example, an interface such as a wired LAN card or a wireless LAN card, and communicates with other devices via the network 12. The input device 45 is, for example, a mouse, a keyboard, etc., and accepts information input by a user. The output device 46 is, for example, a display or a printer, and outputs (displays, etc.) various types of information. The reading device 47 reads information from a portable storage medium (recording medium) 48, such as a CD-ROM or USB memory.

[0038] In this embodiment, each processing unit of the processing unit 20a is realized as a processing process configured by, for example, the CPU 41 executing a component management program, and the storage unit 20b is realized by the CPU 41 using the memory 42 and auxiliary storage device 43. The input / output unit 20c is realized by the CPU 41 using the input device 45, output device 46, reading device 47, etc. The communication unit 20d is realized by the CPU 41 using the communication device 44.

[0039] The various programs executed by the CPU 41 may be stored in advance in the auxiliary storage device 43, or may be read as needed from a storage medium 48 that stores the various programs via a reading device 47, or may be downloaded as needed from another device via a communication device 44.

[0040] FIG. 5 is a configuration diagram of a component information database according to an embodiment.

[0041] The component information database 50 stores, as columns, information about the components that make up each piece of software treated as a product. Each column is associated with the name of the software (product name). In this embodiment, the component information database 50 is created based on the SBOM information for the software received by the component information update processing unit 21.

[0042] The component information database 50 includes a Name row 51, a Version row 52, ​​an ID row 53, a Link-ID row 54, a Packages row group 55, and a Relationships row group 56.

[0043] The Name row 51 stores the component name of the parent component of the software (parent component). The Version row 52 stores version information of the parent component. The ID row 53 stores a unique ID of the parent component. In this embodiment, the ID is the component name and version information, but is not limited to this. The Link-ID row 54 stores a link to a component that differs from the parent component only in version.

[0044] The Packages row group 55 stores information about one or more child components (child components) of a parent component in software. The Packages row group 55 has a set of a Name row 55a, a Version row 55b, and an ID row 55c for each child component. The Name row 55a stores the component name of the child component. The Version row 55b stores version information of the child component. The ID row 55c stores a unique ID of the child component.

[0045] The Relationships row group 56 stores information about the dependency relationships between parent and child components in software. The Relationships row group 56 has a pair of an ID row 56a and a Type row 56b for each child component. The ID row 56a stores the ID of the child component. The Type row 56b stores the type of dependency relationship between the parent and child component.

[0046] FIG. 6 is a configuration diagram of a vulnerability information database according to an embodiment.

[0047] The vulnerability information database 60 manages vulnerability information for each component. In this embodiment, the vulnerability information database 60 is created based on vulnerability information received by the vulnerability information update processing unit 24. The vulnerability information database 60 includes, for each component, a set of a Name row 61, a Version row 62, and an ID row 63. The Name row 61 stores the component name of the component. The Version row 62 stores version information of the component. The ID row 63 stores the ID of the component.

[0048] The vulnerability information database 60 includes a CVSS v3.0 column 64, a CVSS v4.0 column 65, and an EOL / EOS column 66. The CVSS v3.0 column 64 stores the risk value of the component according to CVSS v3.0. The CVSS v4.0 column 65 stores the risk value of the component according to CVSS v4.0. The EOL / EOS column 66 stores information indicating whether the component has reached EOL / EOS. In this embodiment, if the component has reached EOL / EOS, a circle is stored.

[0049] FIG. 7 is a diagram showing the configuration of a SAME information database according to an embodiment.

[0050] The SAME information database 200 manages information indicating the correspondence between identical components between different software programs. The SAME information database 200 stores entries (rows) for each pair of identical components. The SAME information database 200 includes a FROM column group 201 that stores information about one of the identical components, and a TO column group 211 that stores information about the other of the identical components.

[0051] The FROM column group 201 includes a Product column 202, a Name column 203, a Version column 204, and an ID column 205. The Product column 202 stores the name of the program to which the component belongs. The Name column 203 stores the component name of the component. The Version column 204 stores version information of the component. The ID column 205 stores a unique ID of the component.

[0052] The TO column group 211 includes a Product column 212, a Name column 213, a Version column 214, and an ID column 215. The Product column 212 stores the name of the program to which the component belongs. The Name column 213 stores the component name of the component. The Version column 214 stores version information of the component. The ID column 215 stores a unique ID of the component.

[0053] FIG. 8 is a diagram showing the configuration of a SIMILAR information database according to an embodiment.

[0054] The SIMILAR information database 220 manages information indicating the correspondence between similar components between different software programs. Here, "similar" means that the names are the same but the versions are different. The SIMILAR information database 220 stores entries (rows) for each pair of similar components. The SIMILAR information database 220 includes a FROM column group 221 that stores information about one of the similar components, and a TO column group 231 that stores information about the other of the similar components.

[0055] The FROM column group 221 includes a Product column 222, a Name column 223, a Version column 224, and an ID column 225. The Product column 222 stores the name of the program to which the component belongs. The Name column 223 stores the component name of the component. The Version column 224 stores version information of the component. The ID column 225 stores a unique ID of the component.

[0056] The TO column group 231 includes a Product column 232, a Name column 233, a Version column 234, and an ID column 235. The Product column 232 stores the name of the program to which the component belongs. The Name column 233 stores the component name of the component. The Version column 234 stores version information of the component. The ID column 235 stores a unique ID of the component.

[0057] Next, the processing operation in the computer system 1 will be described.

[0058] FIG. 9 is a flowchart of a database update process according to an embodiment.

[0059] The information update input unit 30 of the terminal device 11 receives update information on component information or vulnerability information from the user (S70). Here, the update information on component information is, for example, the SBOM of newly released software. Also, the vulnerability information on vulnerability information is, for example, information on newly disclosed vulnerabilities for components.

[0060] Next, the information update input unit 30 of the terminal device 11 transmits the received update information to the component management device 20 (S71).

[0061] In response to this, in the component management device 20, the component information update processing unit 21 receives the update information of the component information, and the vulnerability information update processing unit 24 receives the update information of the vulnerability information (S72).

[0062] 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 update information of the component information, and the vulnerability information update processing unit 24 updates the vulnerability information database 60 based on the update information of the vulnerability information (S73).

[0063] Next, the dependency analysis process executed in steps S72 and S73 will be described.

[0064] 10 is a flowchart of a dependency analysis process according to an embodiment. In FIG. 10, the process of step S90 corresponds to part of the process of step S72, and the processes of steps S91 to S96 correspond to part of the process of step S73.

[0065] The component information update processing unit 21 of the component management device 20 receives the update information of the component information from the terminal device 11 (S90).

[0066] Next, the component information update processing unit 21 determines whether or not there is a parent component having an ID that matches the ID in the ID row 55c in the Packages row group 55, in other words, whether or not the same component exists, based on the received update information for the component information and the information stored in the component information database 50 (S91). Note that in this embodiment, whether or not the same component exists is determined based on whether or not the IDs are the same, but whether or not the same component exists may also be determined based on whether or not the component name and version are the same.

[0067] As a result, if there is a parent component with an ID that matches the ID in ID row 55c (S91: Yes), the component information update processing unit 21 combines the child component and parent component with the matching ID as SAME, that is, considers them to be identical, and registers the set of these components as an entry in the SAME information database 200 (S92), and proceeds to step S93.

[0068] On the other hand, if there is no parent component having an ID that matches the ID in the ID row 55c (S91: No), the component information update processing unit 21 proceeds to step S93.

[0069] In step S93, the component information update processing unit 21 determines whether there is a parent component in the Packages row group 55 whose component name in the Name row 55a matches the received component update information and the information stored in the component information database 50, but whose version in the Version row 55b is different, i.e., whether there are similar components.

[0070] As a result, if there is a parent component whose component name matches in the Name row 55a but whose version is different in the Version row 55b (S93: Yes), the component information update processing unit 21 combines the child component and parent component whose component name matches but whose version is different as SIMILAR, that is, it registers the set of these components as an entry in the SIMILAR information database 220 as being similar (S94), and the process proceeds to step S95.

[0071] On the other hand, if there is no parent component with a matching component name in the Name line 55a and a different version in the Version line 55b (S93: No), the component information update processing unit 21 proceeds to step S95.

[0072] In step 95, the component information update processing unit 21 determines whether there are parent components in the received component update information and the information stored in the component information database 50 that have the same component name in the Name row 51 but different versions in the Version row 52.

[0073] As a result, if there are parent components whose component names in the Name row 51 match but whose versions in the Version row 52 are different (S95: Yes), the component information update processing unit 21 inputs the ID of the parent component of the older version into the Link-ID row 54 of the parent component with the newer version (S96), and terminates the processing.

[0074] On the other hand, if there are no parent components whose component names in the Name line 51 match but whose versions in the Version line 52 are different (S95: No), the component information update processing unit 21 ends the process.

[0075] Next, a conceptual diagram showing the dependency relationships between a plurality of components analyzed by the dependency relationship analysis process will be described.

[0076] Fig. 11 is a first conceptual diagram illustrating the dependency relationships of components according to an embodiment, which is a conceptual diagram illustrating the configuration of a component network connected by a SAME relationship in the dependency relationships when the SAME information database 200 shown in Fig. 7 is created by the dependency relationship analysis process.

[0077] Each piece of software is represented as a software frame 120. The version of the parent component of the software corresponding to the software frame 120 is written on the right side of the software frame 120. Within the software frame 120, the components that make up the software are represented as component frames 121. The component name is written within the component frame 121. The component frame 121 of the parent component and the component frame 121 of the child component are connected by an arrow 122 accompanied by the type of dependency relationship written in the Type row 56b.

[0078] Furthermore, the component frames 121 of pairs of components having a SAME relationship in the SAME information database 200 are connected by arrows 123 with SAME attached.

[0079] According to the conceptual diagram in Fig. 11, it can be seen that component "C" of the software including component "A" of version 1.0 is the same as component "C" of version 1.2, and component "X" of the software including component "C" of version 1.2 is the same as component "X" of version 1.3.

[0080] Fig. 12 is a second conceptual diagram illustrating the dependency relationships of components according to an embodiment, which is a conceptual diagram illustrating the configuration of components connected by SAME and SIMILAR in the dependency relationships when the SAME information database 200 shown in Fig. 7 and the SIMILAR information database 220 shown in Fig. 8 are created by the dependency relationship analysis process.

[0081] In the conceptual diagram shown in FIG. 12, in addition to the conceptual diagram shown in FIG. 11, component frames 121 of pairs of components that have a SIMILAR relationship in the SIMILAR information database 220 are connected by arrows 124 with SIMILAR attached.

[0082] 12, it can be seen that component "C" of the software including component "A" of version 1.0 is similar to component "C" of version 1.2.1, and component "X" of the software including component "C" of version 1.2.1 is similar to component "X" of version 1.3.

[0083] Next, the risk calculation process performed by the risk calculation processing unit 25 will be described.

[0084] Fig. 13 is an explanatory diagram of a risk calculation process according to an embodiment. Fig. 13 shows an example of calculating the risk of each component using a risk value in CVSS v3.0 when the component dependencies have the configuration shown in Fig. 11 and the vulnerability information database 60 is in the state shown in Fig. 6. In this example, the risk calculation processing unit 25 sets the risk of a parent component to the average value of the risk levels of all child components.

[0085] In FIG. 13, the risk level for each component is displayed in a risk level frame 125 arranged next to the component frame 121.

[0086] Here, as shown in FIG. 6, the vulnerability information database 60 registers the risk values ​​(degrees of danger) of components "B", "Y", and "N" as 6.7, 4.8, and 3.5, respectively.

[0087] The risk calculation processing unit 25 calculates the risk of the Ver. 1.3 component "X" as the average value of the risk of all child components of the component "X." In this example, since the only child component is "N," the risk of the component "X" is calculated to be 3.5.

[0088] Since the component "X" of the software including the component "C" of Ver. 1.2 and the component "X" of Ver. 1.3 are the same, the risk calculation processing unit 25 calculates the risk of the component "X" of the software including the component "C" of Ver. 1.2 to be 3.5.

[0089] Next, the risk calculation processing unit 25 calculates the risk of the Ver. 1.2 component "C" as 4.2, which is the average of the risks of all child components "X" and "Y" of the component "C," which are 3.5 and 4.8, respectively.

[0090] Since the component "C" of the software including the component "A" of Ver. 1.0 and the component "C" of Ver. 1.2 are the same, the risk calculation processing unit 25 calculates the risk of the component "C" of the software including the component "A" of Ver. 1.0 to be 4.2.

[0091] Next, the risk calculation processing unit 25 calculates the risk of component "A" of version 1.0 as 5.5 (rounded to one decimal place), which is the average of the risk levels of all child components "B" and "C" of component "A," which are 6.7 and 4.2.

[0092] According to this risk calculation process, it is possible to easily and appropriately estimate the risk of a component for which a corresponding risk value has not been registered.

[0093] Next, the search process in the computer system 1 will be described.

[0094] FIG. 14 is a flowchart of a search process according to an embodiment.

[0095] The search method input unit 31 of the terminal device 11 accepts a selection of a search method from the user, for example, via the search screen 150 (see Figure 15) (S80), the search content input unit 32 accepts search content from the user (S81), and the risk calculation input unit 33 accepts a risk calculation specification from the user (S82).

[0096] Next, the search method input unit 31, search content input unit 32, and risk calculation input unit 33 transmit search information including the received search method, search content, and risk calculation specification to the component management device 20 (S83).

[0097] The search processing unit 23 of the component management device 20 receives the search information from the terminal device 11 (S84).

[0098] Next, the search processing unit 23 performs a search process to extract information on components that match the search content from the component information database 50, the SAME information database 200, and the SIMILAR information database 220 based on the received search method (S85).

[0099] Next, the risk calculation processing unit 25 performs a risk calculation process based on the risk calculation specification, which calculates the risk of each component included in the search results based on the risk information of the components registered in the vulnerability information database 60 and the component dependency information obtained by the search process (S86).

[0100] Next, the search processing unit 23 transmits the search result obtained in the search process in step S85 together with the risk calculated in the risk calculation process to the terminal device 11 as a search result (S87).

[0101] 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).

[0102] Next, the search screen 150 will be described.

[0103] Fig. 15 is a diagram illustrating the configuration of a search screen according to an embodiment. Fig. 15 shows the search screen in a state where an input for searching for components within a range of a predetermined number of layers from a starting component has been made.

[0104] The search screen 150 includes a search method selection field 151 , a search content input field 152 , a risk calculation specification selection field 153 , and a search button 154 .

[0105] The search method selection field 151 is an area for selecting and inputting a search method. Search methods include, for example, a method of searching based on a starting component and the number of layers, and a method of searching based on a starting component and an ending component. The search screen in FIG. 15 shows a state in which the method of searching based on a starting component and the number of layers has been selected. Note that in the example of FIG. 15, the search method selection field 151 accepts selection by pressing a button, but it may also accept selection from, for example, a pull-down list.

[0106] The search content input field 152 is an area for inputting search content. The search content includes a starting component ID, an ending component ID, and the number of levels. In the search content input field 152, the user inputs the content required for the search method selected in the search method selection field 151. For example, if a method for searching based on a starting component and the number of levels is selected in the search method selection field 151, the user must input the starting component ID and the number of levels. If a method for searching based on a starting component and an ending component is selected, the user must input the starting component ID and the ending component ID. Note that while the example in FIG. 15 accepts input of a character string, it is also possible to display selectable components in a pull-down list and accept a selection from the pull-down list, for example.

[0107] The risk calculation specification selection field 153 is an area for selecting and specifying information to be used when calculating the risk of a component. In this embodiment, risk calculation specifications include specification of using the risk value of CVSS v3.0, specification of using the risk value of CVSS v4.0, specification of using EOL / EOS, specification of not calculating the risk, etc.

[0108] The search button 154 is a button that is pressed when executing a search according to the search information entered on the search screen. When the search button 154 is pressed, search information including the search method, search content, and risk calculation specification is sent to the component management device 20, and a search is performed.

[0109] Next, the search process executed in steps S84 and S85 when the starting component and the number of layers are used as search conditions will be described.

[0110] 16 is a flowchart of a search process according to an embodiment when a starting component and the number of layers are used as search conditions. In FIG. 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.

[0111] The search processing unit 23 of the component management device 20 receives component search information from the terminal device 11 (S100).

[0112] Next, the search processing unit 23 determines whether or not a parent component having an ID that matches the origin component ID of the search information exists in the information in the component information database 50 (S101).

[0113] As a result, if there is no parent component having an ID that matches the starting component ID of the search information (S101: No), the search processing unit 23 ends the search process.

[0114] On the other hand, if there is a parent component with an ID that matches the starting component ID of the search information (S101: Yes), the search processing unit 23 sets the starting component to the 0th layer (S102) and initializes the variable N, which holds the number of layers, to 1 (S103).

[0115] The search processing unit 23 extracts, from the information in the component information database 50, a component having the ID of the ID row 56a of the Relationship row group 56 of the component set at the N-1th layer as a component at the Nth layer (S104).

[0116] Next, the search processing unit 23 refers to the SAME information database 200 and the SIMILAR information database 220, identifies all components that have an identical (SAME) or similar (SIMILAR) relationship with the component extracted as the Nth hierarchical component, and extracts the identified components as the Nth hierarchical component (S105).

[0117] Next, the search processing unit 23 determines whether the variable N has reached the number of layers in the search information (S106). As a result, if the variable N has reached the number of layers in the search information (S106: Yes), this means that detection of components up to the number of layers specified in the search information has been completed, and the search processing unit 23 ends the process.

[0118] On the other hand, if the variable N has not reached the number of layers in the search information (S106: No), the search processing unit 23 increments the variable N by 1 to search for components in the next layer (S107), and proceeds to step S104.

[0119] This search process makes it possible to search for components across multiple software programs within a specified number of layers from the origin component.

[0120] Next, an example of a search result screen displayed by the search processing unit 23 through the search result output unit 34 when the starting component and the number of layers are used as search conditions will be described.

[0121] FIG. 17 shows an example of a search result screen when a starting component and the number of layers are used as search conditions according to an embodiment.

[0122] The search result screen 160 includes a search content display area 161 and a component dependency relationship display area 162. The search content display area 161 displays the specified search content. The component dependency relationship display area 162 displays a relationship diagram of multiple components extracted by the search process. The component relationship diagram is displayed, for example, in a format similar to the conceptual diagram shown in FIG. 11 , and each component is displayed with a calculated risk level associated with it as shown in FIG. 13 . In the example of FIG. 17 , a relationship diagram of multiple components is displayed, and the extracted components and the arrows connecting them are highlighted compared to the other components and arrows (for example, the extracted components and the arrows connecting them are displayed with solid black lines, and the other components are displayed with solid gray lines). In the example of FIG. 17 , the component dependency relationship display area 162 displays the relationship diagram. However, for example, the component relationships may be displayed in a text-based format. Any method of expression may be used as long as it can express the search results based on the starting component and the number of levels.

[0123] This search result screen 160 allows users to easily and appropriately understand the component relationships across multiple software programs within a specified number of layers from the origin component. It also allows users to determine vulnerabilities across multiple software programs, making it easy to understand the scope of impact of component vulnerabilities.

[0124] Next, a search process when a start component and an end component are used as search conditions will be described.

[0125] FIG. 18 is a diagram showing the configuration of a search screen in which a start component and an end component are used as search conditions according to an embodiment.

[0126] The configuration of the search screen 150 is the same as that shown in Fig. 15. In this example, in a search method selection field 151 of the search screen 150, a search from a start component and an end component is selected, and in a search content input field 152, the start component and the end component are input.

[0127] Next, the search process executed in steps S84 and S85 when a start component and an end component are used as search conditions will be described.

[0128] 19 is a flowchart of a search process when a start component and an end component are used as search conditions according to an embodiment. In FIG. 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.

[0129] The search processing unit 23 of the component management device 20 receives the component search information from the terminal device 11 (S110).

[0130] Next, the search processing unit 23 determines whether or not the information in the component information database 50 contains a component with an ID that matches the starting component ID of the search information and a component with an ID that matches the ending component ID of the search information (S111).

[0131] As a result, if there is no component with an ID that matches the starting component ID and no component with an ID that matches the ending component ID (S111: No), this means that there are no results that match the search conditions, so the search processing unit 23 terminates the search process.

[0132] On the other hand, if there is a component with an ID that matches the starting component ID and a component with an ID that matches the ending component ID (S111: Yes), the search processing unit 23 searches for a path of components that can be reached from the components included in the Relationships row group 56 of the starting component in a SAME or SIMILAR relationship, for example, in the order of precedence in the search method (S112).

[0133] Next, the search processing unit 23 determines whether or not there is a path among the paths of the searched components that can reach from the starting component to the ending component, i.e., whether or not there is a path that can reach a component that matches the ending component (S113).

[0134] As a result, if there is no route that can reach the destination component from the start component (S113: No), this means that there is no route that meets the search criteria, and the search processing unit 23 ends the process.

[0135] On the other hand, if there is a path that can reach the end component from the start component (S113: Yes), the search processing unit 23 extracts a path from the start component to the end component (S114).

[0136] This search process makes it possible to search for a path of components across multiple software programs as a path that can be reached from a starting component to an ending component.

[0137] Next, an example of a search result screen displayed by the search processing unit 23 and the search result output unit 34 when a start component and an end component are used as search conditions will be described.

[0138] FIG. 20 shows an example of a search result screen when a start component and an end component are used as search conditions according to an embodiment.

[0139] The search result 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 start component ID and the end component ID. The component dependency relationship display area 182 displays a relationship diagram of multiple components extracted by the search process. The component relationship diagram is displayed, for example, in a format similar to the conceptual diagram shown in FIG. 11. In the example of FIG. 20, a relationship diagram of multiple components is displayed, and the paths of the extracted components are highlighted compared to the other components and arrows (for example, the extracted paths are displayed with solid black lines, and the others are displayed with solid gray lines). In the example of FIG. 20, the component dependency relationship display area 182 displays the relationship diagram. However, for example, the component relationships may be displayed in a text-based format. Any method may be used as long as it can represent the path between the start component and the end component.

[0140] According to this search result screen 180, it is possible to easily and appropriately grasp the component relationships across multiple software programs on the path between the starting component and the ending component.

[0141] The present invention is not limited to the above-described embodiment, and can be modified appropriately without departing from the spirit of the present invention.

[0142] For example, in the above embodiment, the search results are obtained by tracing the relationship between SAME and SIMILAR in the search process, but the search results may be obtained by tracing the relationship between either SAME or SIMILAR.

[0143] In addition, in the above-described embodiment, some or all of the processing performed by the processor may be performed by a hardware circuit.

[0144] 1...computer system, 10...component management device, 11...terminal device, 12...network, 20...component management device, 20a...processing unit, 20b...storage unit, 20c...input / output unit, 20d...communication unit, 21...component information update processing unit, 22...dependency analysis processing unit, 23...search processing unit, 24...vulnerability information update processing unit, 25...risk calculation processing unit, 26...component information storage unit, 27...vulnerability information storage unit

Claims

1. A component management device that manages the dependencies between multiple components in multiple software programs, comprising: a configuration information receiving unit that receives configuration information for the multiple software programs indicating the configuration of higher-level components and lower-level components in the software; and a dependency analysis processing unit that detects dependencies between multiple components across the multiple software programs based on the configuration information for the multiple software programs and stores the dependencies in a storage device.

2. The component management device according to claim 1, wherein the dependency is at least one of a relationship in which the components are the same or a relationship in which the components are of different versions.

3. The component management device of claim 1 further comprises: a search processing unit that accepts the highest-level component to be searched for dependencies and the number of levels to be searched as search conditions, and detects a group of components that match the search conditions based on the dependencies; and a search result output control unit that outputs information on the detected group of components.

4. The component management device of claim 1 further comprises: a search processing unit that accepts a top-level component and a bottom-level component to be searched for dependencies as search conditions, and detects a group of components that match the search conditions based on the dependencies; and a search result output control unit that outputs information on the detected group of components.

5. The component management device according to claim 1, further comprising: a vulnerability information receiving unit that receives vulnerability information about at least some components; and a vulnerability information estimation unit that estimates vulnerability information about components that do not have vulnerability information based on the dependency relationships.

6. The component management device according to claim 5, wherein the vulnerability information estimation unit estimates vulnerability information of higher-level components based on vulnerability information of lower-level components.

7. The component management device according to claim 6, wherein the vulnerability information includes a risk level related to the vulnerability of the component, and the vulnerability information estimation unit estimates the risk level of the parent component by averaging the risk levels of all child components.

8. The component management device according to claim 5, further comprising a vulnerability information output control unit that outputs the estimated vulnerability information.

9. A component management method by a component management device that manages dependencies between multiple components in multiple software programs, the component management method receiving configuration information for the multiple software programs indicating the configuration of higher-level components and lower-level components in the software programs, detecting dependencies between multiple components across the multiple software programs based on the configuration information for the multiple software programs, and storing the dependencies in a storage device.

10. A recording medium having recorded thereon a component management program that causes a computer to execute a process for managing the dependencies of multiple components in multiple software programs, wherein the component management program causes the computer to function as: a configuration information receiving unit that receives configuration information indicating the configuration of higher-level components and lower-level components in the software for the multiple software programs; and a dependency analysis processing unit that detects dependencies between multiple components across the multiple software programs based on the configuration information for the multiple software programs and stores the dependencies in a storage device.

Images