Component management device, component management method, and component management program

Abstract

To provide a component management device capable of easily and properly detecting dependencies among a plurality of software components.SOLUTION: A component management device 20 for managing dependencies among a plurality of components in a plurality of software comprises a component information update processing unit 21 which accepts configuration information indicative of the hierarchical structure between upper-level and lower-level components in software about the plurality of software and a dependency analysis processing unit 22 which detects dependencies among components across the plurality of software on the basis of configuration information about the plurality of software, and stores the detected dependencies in a component information holding unit 20.SELECTED DRAWING: Figure 2

Description

[Technical Field]

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

[0002] Cyberattacks on medical devices have been increasing in recent years, making security an important 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 US 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 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] 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. Patent Document 2 also 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. [Prior art documents] [Patent documents]

[0006] [Patent Document 1] Japanese Patent Application Publication No. 2019-215621 [Patent Document 2] Japanese Patent Application Publication No. 2023-38730 Summary of the Invention [Problem to be solved by the invention]

[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 contained in the software. This makes it difficult to grasp the dependencies and hierarchical structure between multiple SBOM components with file-based management. 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 need to manage the software configuration information of medical devices at the time of release, so they need to manage the SBOM of the entire medical device, including the SBOM of third-party products.In addition, medical devices undergo software updates for each customer, and each customer ends up using a different version of the medical device, making it difficult to manage the SBOM of the medical devices used by customers and to understand 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 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. [Means for solving the problem]

[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. [Effects of the Invention]

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

[0013] [Figure 1] FIG. 1 is a diagram showing the overall configuration of a computer system according to one embodiment. [Figure 2] FIG. 2 is a configuration diagram of a component management device according to an embodiment. [Figure 3] FIG. 3 is a configuration diagram of a terminal device and a component management device according to an embodiment. [Figure 4] FIG. 4 is a hardware configuration diagram of a component management device and a terminal device according to an embodiment. [Figure 5] FIG. 5 is a configuration diagram of a component information database according to an embodiment. [Figure 6] FIG. 6 is a configuration diagram of a vulnerability information database according to an embodiment. [Figure 7] FIG. 7 is a configuration diagram of a SAME information database according to one embodiment. [Figure 8] FIG. 8 is a diagram showing the configuration of a SIMILAR information database according to one embodiment. [Figure 9] FIG. 9 is a flowchart of a database update process according to an embodiment. [Figure 10]FIG. 10 is a flowchart of a dependency analysis process according to an embodiment. [Figure 11] FIG. 11 is a first conceptual diagram illustrating dependency relationships between components according to an embodiment. [Figure 12] FIG. 12 is a second conceptual diagram illustrating dependency relationships between components according to an embodiment. [Figure 13] FIG. 13 is an explanatory diagram of the risk calculation process according to one embodiment. [Figure 14] FIG. 14 is a flowchart of a search process according to an embodiment. [Figure 15] FIG. 15 is a diagram showing the configuration of a search screen according to an embodiment. [Figure 16] FIG. 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. [Figure 17] FIG. 17 is 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. [Figure 18] 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. [Figure 19] FIG. 19 is a flowchart of a search process according to an embodiment when a start component and an end component are used as search conditions. [Figure 20] FIG. 20 shows an example of a search result screen when a starting component and an ending component are used as search conditions according to an embodiment. DETAILED DESCRIPTION OF THE INVENTION

[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, for example, via a network 12. The network 12 is, for example, a wired LAN (Local Area Network), a wireless LAN, or a WAN (Wide Area Network). The terminal device 11 and the component management device 20 may be directly connected via a cable or the like. The terminal device 11 and the component management device 20 may also 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 has 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 (component information) related to software components, 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, where the components are the same, i.e., the component names and versions are the same, and SIMILAR, where 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 score, EOL (End of Life), and EOS (End of Service). Furthermore, 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 (vulnerability information) related to component vulnerabilities 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 the 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, transmits the component information to the component information update processing unit 21, and transmits the vulnerability information to the vulnerability information update processing unit 24.

[0031] The search method input unit 31 receives 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 receives search content via, for example, the search screen 150 and transmits it to the search processing unit 23. The risk calculation input unit 33 receives 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. The terminal device 11 and the component management device 20 can have similar hardware configurations, so in this embodiment, for convenience, they will be described using the same diagram.

[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 units 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 RAM (Random Access Memory), 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 a 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. Furthermore, the input / output unit 20c is realized by the CPU 41 using the input device 45, output device 46, reading device 47, etc. Furthermore, 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 information about the SBOM of 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 component that is the parent 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 between the parent component and a component that differs 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 CVSS v3.0 risk value of the component. The CVSS v4.0 column 65 stores the CVSS v4.0 risk value of the component. 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 configuration diagram of a SAME information database according to one 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 an entry (row) 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 one embodiment.

[0054] The SIMILAR information database 220 manages information indicating the correspondence between similar components between different software. 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 operations 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 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, from the received update information of 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 pair 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 advances the process 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 names in the Name row 55a match but whose version in the Version row 55b is different (S93: Yes), the component information update processing unit 21 combines the child component and parent component whose component names match but whose versions are 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 advances the process 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 line 51 match but whose versions in the Version line 52 are different (S95: Yes), the component information update processing unit 21 enters the ID of the parent component of the older version into the Link-ID line 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 showing the dependency relationships of components according to one embodiment. Fig. 11 is a conceptual diagram showing 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 at the right corner 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 Figure 11, component "C" of the software that includes component "A" in Ver. 1.0 is identical to component "C" in Ver. 1.2, and component "X" of the software that includes component "C" in Ver. 1.2 is identical to component "X" in Ver. 1.3.

[0080] Fig. 12 is a second conceptual diagram showing the dependency relationships of components according to one embodiment. Fig. 12 is a conceptual diagram showing 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, the 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] According to the conceptual diagram in Figure 12, it can be seen that component "C" of the software that includes component "A" in Ver. 1.0 is similar to component "C" in Ver. 1.2.1, and component "X" of the software that includes component "C" in Ver. 1.2.1 is similar to component "X" in Ver. 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 one 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 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 component "X" of Ver. 1.3 as the average value of the risk of all child components of component "X." In this example, since the only child component is "N," the risk of component "X" is calculated to be 3.5.

[0088] Since component "X" of Ver.1.3 and component "X" of the software including component "C" of Ver.1.2 are SAME, the risk calculation processing unit 25 calculates the risk of component "X" of the software including 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", 3.5 and 4.8.

[0090] Since component "C" of Ver.1.2 and component "C" of the software including component "A" of Ver.1.0 are SAME, the risk calculation processing unit 25 calculates the risk of component "C" of the software including 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 Ver. 1.0 as 5.5 (rounded to the first decimal place), which is the average of the risk levels of all child components "B" and "C" of component "A": 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 via, for example, 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 based on the received search method 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 (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 dependency relationship information of the components obtained by the search process (S86).

[0100] Next, the search processing unit 23 transmits the result obtained in the search process in step S85 together with the risk calculated in the risk calculation process as a search result to the terminal device 11 (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 configuration diagram of a search screen according to one embodiment. Fig. 15 shows the search screen in a state where an input is being made to search for components within a range of a predetermined number of layers from the starting component.

[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 be configured to 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 start component ID, an end 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 of searching based on a start component and the number of levels is selected in the search method selection field 151, the user must input the start component ID and the number of levels, and if a method of searching based on a start component and an end component is selected, the user must input the start component ID and the end component ID. Note that, although 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 a risk value of CVSS v3.0, specification of using a risk value of CVSS v4.0, specification of using EOL / EOS, specification of not calculating a 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 origin 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 origin component ID of the search information (S101: Yes), the search processing unit 23 sets the origin component to the 0th layer (S102) and initializes the variable N that 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 in the ID row 56a of the Relationships 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 of 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 the process 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 is 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 displayed in a more emphasized manner than 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 manner. Any method of expression may be used as long as the search results based on the starting component and the number of layers can be displayed.

[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 search screen 150 is the same as the configuration shown in Fig. 15. In this example, in search method selection field 151 of search screen 150, search from a start component and an end component is selected, and in 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 having an ID that matches the starting component ID of the search information and a component having an ID that matches the ending component ID of the search information (S111).

[0131] As a result, if there is neither a component with an ID that matches the starting component ID nor a 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 in a SAME or SIMILAR relationship from the components included in the Relationships row group 56 of the starting component, 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 from the start component to the end 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 starting component and an ending 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 displayed emphasized 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, but the component relationships may also be displayed in text format, for example. Any method of expression may be used as long as it can express 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 SAME and SIMILAR relationships in the search process, but the search results may be obtained by tracing either the SAME or SIMILAR relationships.

[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. [Explanation of symbols]

[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 dependencies of multiple components in multiple software programs, a configuration information receiving unit that receives configuration information indicating a configuration of upper-level components and lower-level components in the software for a plurality of software programs; a dependency analysis processing unit that detects dependencies between multiple components across multiple software programs based on configuration information about the multiple software programs and stores the dependencies in a storage device.

2. The dependency relationship is at least one of a relationship between the same component and a relationship between components with different versions. The component management device according to claim 1 .

3. a search processing unit that receives, as search conditions, a top-level component to be searched for dependency relationships and the number of layers to be searched, and detects a group of components that match the search conditions based on the dependency relationships; a search result output control unit that outputs information on the detected component group. The component management device according to claim 1 .

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

5. a vulnerability information receiving unit that receives vulnerability information about at least some of the components; a vulnerability information estimation unit that estimates vulnerability information of a component that does not have vulnerability information based on the dependency relationship. The component management device according to claim 1 .

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

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

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

9. A component management method by a component management device that manages dependencies of multiple components in multiple software programs, comprising: receiving configuration information indicating a configuration of upper-level components and lower-level components in the software for a plurality of software programs; Detecting dependencies between a plurality of components across a plurality of software programs based on the configuration information about the plurality of software programs; The dependency relationship is stored in a storage device. Component management method.

10. A component management program that causes a computer to execute a process for managing dependencies between multiple components in multiple pieces of software, The component management program The computer a configuration information receiving unit that receives configuration information indicating a configuration of upper-level components and lower-level components in the software for a plurality of software programs; and a dependency analysis processing unit that detects dependencies between a plurality of components across a plurality of pieces of software based on the configuration information about the plurality of pieces of software, and stores the dependencies in a storage device. Component management program.

Images