Information processing apparatus, information processing method, and information processing program

Abstract

To manage software bills of materials at a granularity required for vulnerability management.SOLUTION: An information processing apparatus 10 comprises a determination unit 20D and a generation unit 20E. The determination unit 20D determines a vulnerable software component(s) among software components prescribed by a first software bill of materials S1. The generation unit 20E generates a second software bill of materials S2 corresponding to the determined software component(s).SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] Embodiments of the present invention relate to an information processing apparatus, an information processing method, and an information processing program.

Background Art

[0002] In recent years, for the purpose of license compliance and security assurance, risk management such as vulnerabilities has been performed by utilizing software component lists such as SBOM (Software Bills of materials).

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, in the prior art, the software component list is managed in software units, and management at the granularity required for vulnerability management has not been performed.

[0005] The problem to be solved by the present invention is to provide an information processing apparatus, an information processing method, and an information processing program capable of managing a software component list at a granularity required for vulnerability management.

Means for Solving the Problems

[0006] The information processing apparatus according to the embodiment includes a determination unit and a generation unit. The determination unit determines software components that may have vulnerabilities among the software components defined by the first software component list. The generation unit generates a second software component list according to the determined software components.

Brief Description of the Drawings

[0007]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Mode for Carrying Out the Invention

[0008] Hereinafter, with reference to the accompanying drawings, an information processing apparatus, an information processing method, and an information processing program according to the present embodiment will be described in detail.

[0009] In the following descriptions of the respective embodiments, parts denoted by the same reference numerals have substantially the same functions, and redundant parts will be omitted as appropriate.

[0010] (First Embodiment) FIG. 1 is a schematic diagram of an example of the information processing apparatus 10 according to the present embodiment.

[0011] The information processing apparatus 10 includes a storage unit 12, a communication unit 14, a UI (User Interface) unit 16, and a processing unit 20. The storage unit 12, the communication unit 14, the UI unit 16, and the processing unit 20 are communicably connected via a bus 18 or the like.

[0012] The storage unit 12 stores various types of information. The storage unit 12 may be a storage device provided outside the information processing apparatus 10. For example, the storage unit 12 may be mounted on an external information processing apparatus connected to the information processing apparatus 10 via a network or the like.

[0013] The communication unit 14 is a communication interface that communicates with an external information processing apparatus or the like via a network or the like.

[0014] The UI unit 16 has a display function for displaying various types of information and an input function for receiving operation instructions from the user. In the present embodiment, the UI unit 16 includes a display unit 16A and an input unit 16B. The display unit 16A is a display for displaying various types of information. The input unit 16B receives operation inputs from the user. The input unit 16B is, for example, a pointing device such as a mouse or a keyboard. Note that the UI unit 16 may be a touch panel that integrally configures the display unit 16A and the input unit 16B.

[0015] The processing unit 20 executes information processing in the information processing apparatus 10. The processing unit 20 includes an acquisition unit 20A, an extraction unit 20B, an operation determination unit 20C, a determination unit 20D, a generation unit 20E, a dependency information adding unit 20F, a signature adding unit 20G, and an output unit 20H.

[0016] The acquisition unit 20A, extraction unit 20B, operation determination unit 20C, determination unit 20D, generation unit 20E, dependency information adding unit 20F, signature adding unit 20G, and output unit 20H are realized by, for example, one or more processors. For example, each of the above units may be realized by causing a processor such as a CPU (Central Processing Unit) to execute a program, that is, by software. Each of the above units may be realized by a processor such as a dedicated IC, that is, by hardware. Each of the above units may be realized by using a combination of software and hardware. When using a plurality of processors, each processor may realize one of the units, or may realize two or more of the units. Further, at least one of the above units may be provided in an external information processing device connected to the information processing device 10 via a network.

[0017] The acquisition unit 20A acquires a first software component list.

[0018] The first software component list is a component list that defines software components included in a software product. The software product is, for example, an OS (Operating System), an App (Application program, or Application software), etc. The OS is, for example, Linux (registered trademark), Unix (registered trademark), Windows (registered trademark), Android (registered trademark), iOS (registered trademark), etc., but is not limited thereto. These software products operate by using or including one or more software components. Software components may also be referred to as drivers, services, libraries, etc. For example, Linux operates by using or including the kernel function of the OS itself and software components such as a large number of device drivers and services.

[0019] Examples of the first software component list include, for example, an SBOM (Software Bill of Materials).

[0020] In this embodiment, as an example of the first software component list to be processed in the information processing apparatus 10, a form in which the acquisition unit 20A acquires a defined first software component list of a plurality of software components will be described. The defined first software component list of a plurality of software components indicates that it is the first software component list of a software product that operates using or including a plurality of software components.

[0021] FIG. 2 is a schematic diagram of an example of the first software component list S1. FIG. 2 shows, as an example, a form in which the first software component list S1 is the SBOM of the software product "OS1".

[0022] Returning to FIG. 1, the description will continue.

[0023] The format of the first software component list S1 acquired by the acquisition unit 20A is not limited. For example, the format of the first software component list S1 may be a known format such as SPDX (Software Package Data Exchange), CycloneDX, etc., or it may be a software component list managed by a spreadsheet or the like.

[0024] The acquisition unit 20A may acquire the first software component list S1 stored in the storage unit 12, or may acquire the first software component list S1 from an external information processing apparatus or the like via the communication unit 14.

[0025] The extraction unit 20B extracts software components that may have vulnerabilities, which are included in the first software component list S1, based on vulnerability list information regarding vulnerabilities.

[0026] FIG. 3 is a schematic diagram of an example of the data configuration of the vulnerability list information 12A. The vulnerability list information 12A is a database in which information regarding vulnerabilities is centrally managed.

[0027] For example, the vulnerability list information 12A is information in which a plurality of vulnerability information is defined for each vulnerability and software component in which the vulnerability may exist. The vulnerability information includes, for example, a vulnerability number, target software, and vulnerability detail information. Note that the vulnerability information may further include other information related to the vulnerability. The vulnerability number is identification information for the vulnerability information. The target software is identification information for a software product including one or more software components. For the target software, identifiers such as the name of the software product, CPE (Common Platform Enumeration), SWID, PackageURL, etc., which uniquely identify the software, are used. Further, for the target software, an identifier capable of identifying the version of the software product may also be used.

[0028] The vulnerability detail information is detailed information regarding a vulnerability included in a software component included in a software product identified by the corresponding target software. FIG. 2 shows, as an example, an example in which the vulnerability detail information is described in a pattern of "vulnerability exists" of "type of vulnerability" in the "software component name" of "target software".

[0029] The extraction unit 20B reads the vulnerability list information 12A from an external information processing device via the storage unit 12 or the communication unit 14. The extraction unit 20B may use a public database such as NVD (National Vulnerability Database) or JVN (Japan Vulnerability Notes) as the vulnerability list information 12A, or may use VEX (Vulnerability Exploitability eXchange) information included in the SBOM which is the first software component list S1 as the vulnerability list information 12A.

[0030] Based on the obtained vulnerability list information 12A, the extraction unit 20B extracts software components that may have vulnerabilities from among the plurality of software components defined in the first software component list S1 obtained by the acquisition unit 20A. Software components that may have vulnerabilities are software components in which vulnerabilities exist or may exist.

[0031] The extraction unit 20B extracts, as software components that may have vulnerabilities, the software components defined in the vulnerability list information 12A from among the software components included in the first software component list S1 obtained by the acquisition unit 20A.

[0032] Specifically, for example, assume that the first software component list S1 obtained by the acquisition unit 20A is the SBOM of the software product "OS1". In this case, the extraction unit 20B reads the vulnerability information of vulnerability numbers "1" to "4" defined for the software product "OS1" from the vulnerability list information 12A. Further, the extraction unit 20B reads the software component names defined in the vulnerability detailed information included in each of the read vulnerability information. Through this reading process, the extraction unit 20B extracts the software components with the read software component names as software components that may have vulnerabilities from among the plurality of software components defined in the first software component list S1 obtained by the acquisition unit 20A.

[0033] For example, as described above, the vulnerability details information of the vulnerability list information 12A shown in FIG. 3 is described in the pattern of "there is a vulnerability" in the "vulnerability type" for the "software component name" of the "target software". Therefore, in this case, the extraction unit 20B analyzes the vulnerability details information included in the vulnerability information of the specified vulnerability numbers "1" to "4" of the software product "OS1", and determines the software components "DriverA", "DriverB", and "DriverC" specified in the vulnerability details information as software components that may have vulnerabilities among the software components specified in the first software component list S1 of the software product "OS1". Also, in the case of the vulnerability list information 12A shown in FIG. 3, the extraction unit 20B may further extract the software product "OS1" itself as a software component that may have vulnerabilities by analyzing the vulnerability information of the vulnerability number "4".

[0034] The extraction unit 20B may analyze the vulnerability information by using simple pattern matching, natural language processing, etc., or may analyze the vulnerability information by natural language processing.

[0035] FIG. 4 is an explanatory diagram of an example of software components that may have vulnerabilities extracted by the extraction unit 20B. For example, the extraction unit 20B analyzes the vulnerability details information included in the vulnerability information of the specified vulnerability numbers "1" to "4" of the software product "OS1" based on the vulnerability list information 12A, and determines the software components "DriverA", "DriverB", and "DriverC" specified in the vulnerability details information as software components that may have vulnerabilities among the software components specified in the first software component list S1 of the software product "OS1".

[0036] Returning to FIG. 1, the description will continue.

[0037] The operation determination unit 20C determines, for each software component in which a vulnerability may exist among the software components defined by the first software component list S1 and extracted by the extraction unit 20B, whether or not the software component is operable in the target device for introduction. Whether or not it is operable means whether or not the software component is operating in the target device for introduction or whether it has the possibility of operating.

[0038] For example, the operation determination unit 20C determines whether or not a software component is operable by determining whether or not the software component is being used from the execution history of an actually operating software component (for example, a program). Further, the operation determination unit 20C also assumes that the software component (for example, a module) is not included in the compilation due to the options at the time of compilation, and may determine whether or not the software component is included by analyzing the software to determine whether or not it is operable. Further, the operation determination unit 20C may determine whether or not it is operable using the configuration settings at the time of compilation, etc. Further, the operation determination unit 20C may determine in advance whether or not a software component is used by the user, save the stored information, and use the stored information to determine whether or not it is operable.

[0039] FIG. 5 is an explanatory diagram of an example of the determination result by the operation determination unit 20C. FIG. 5 shows an example of the determination result of whether or not the software components "DriverA", "DriverB", and "DriverC", which are software components extracted as software components in which a vulnerability may exist by the extraction unit 20B, are operable. In FIG. 5, "operating" indicates a determination result of having operability, and "not operating" indicates a determination result of having no operability.

[0040] Returning to FIG. 1, the description will continue.

[0041] The determination unit 20D determines software components in which a vulnerability may exist among the software components defined by the first software component list S1.

[0042] The determination unit 20D determines software components that may have vulnerabilities, for example, based on the vulnerability list information 12A.

[0043] Further, the determination unit 20D may identify software components that are used in or included in the software products of the first software component list S1 by analyzing a database in which the relationship between software components and software products is defined in advance. Further, the determination unit 20D may identify software components that are used in or included in the software products by analyzing the software products of the first software component list S1 through static analysis or the like. Then, the determination unit 20D may determine software components that may have vulnerabilities from among the identified software components using the vulnerability list information 12A or the like.

[0044] As described above, in the present embodiment, the acquisition unit 20A acquires the defined first software component list S1 of a plurality of software components. Then, the extraction unit 20B extracts a plurality of software components included in the first software component list S1 that may have vulnerabilities based on the vulnerability list information 12A. For this reason, in the present embodiment, the determination unit 20D determines a plurality of software components that may have vulnerabilities by determining the plurality of software components extracted by the extraction unit 20B from among the software components defined by the first software component list S1.

[0045] Furthermore, in the present embodiment, it is preferable that the determination unit 20D determines software components that are determined to be operable by the operation determination unit 20C from among the plurality of software components that may have vulnerabilities extracted by the extraction unit 20B.

[0046] In the case of the example shown in FIG. 5, the determination unit 20D determines the software components "DriverA" and "DriverC" that are determined to be operable from among the software components "DriverA", "DriverB", and "DriverC" that may have vulnerabilities extracted by the extraction unit 20B.

[0047] That is, the determination unit 20D preferably determines software components that may have vulnerabilities and are operable among the plurality of software components defined by the first software component list S1. Here, even for the same software component, not all software components may necessarily be used depending on the settings at the time of compilation and the operating environment. Therefore, the determination unit 20D determines software components that have vulnerabilities and are operable. By performing such determination processing by the determination unit 20D, software components that may have vulnerabilities that cannot occur in the practice of vulnerability handling can be excluded from the generation target of the second software component list described later. Also, in this case, the determination unit 20D can achieve labor saving in handling.

[0048] Returning to FIG. 1, the description will be continued.

[0049] The generation unit 20E generates a second software component list according to the software components determined by the determination unit 20D.

[0050] In the present embodiment, the generation unit 20E generates a second software component list for each of the plurality of software components determined by the determination unit 20D.

[0051] FIG. 6 is an explanatory diagram of an example of the generation of the second software component list S2 by the generation unit 20E. For example, assume a scenario where the acquisition unit 20A acquires the first software component list S1 which is the SBOM of the software product "OS1" shown in FIG. 6, and the determination unit 20D determines the software components "DriverA" and "DriverC" that may have vulnerabilities and are determined to be operable.

[0052] In this case, the generation unit 20E generates the second software component list S2B and the second software component list S2C for each of the software components "DriverA" and "DriverC". The second software component list S2B and the second software component list S2C are examples of the second software component list S2.

[0053] Further, the generation unit 20E may further generate the acquired first software component list S1 as the second software component list S2A as it is. The second software component list S2A is an example of the second software component list S2. Further, when the extraction unit 20B determines that there may be a vulnerability in the software product "OS1" defined in the first software component list S1, the generation unit 20E may further generate the acquired first software component list S1 as the second software component list S2A as it is.

[0054] FIG. 6 shows a case where the generation unit 20E generates the second software component list S2 for each of the software product "OS1" in the first software component list, and the software components "DriverA" and "DriverC" determined by the determination unit 20D.

[0055] The generation unit 20E generates the second software component list S2 for each determined software component by copying the information part regarding the corresponding software component in the SBOM which is the first software component list S1. Further, when including software names, identifiers, etc. in the second software component list S2, the generation unit 20E replaces the name and identifier of the software component with the name and identifier for the second software component list S2. Further, when the SBOM which is the first software component list S1 includes VEX (Vulnerability-Exploitability eXchange) information, the VEX information other than the corresponding software component may be deleted.

[0056] Returning to FIG. 1, the description will be continued.

[0057] The dependency information adding unit 20F adds dependency information representing the dependency relationships with respect to the software components defined in the other second software component tables S2 to the second software component table S2. The dependency information is, for example, information indicating whether a certain software component is upper-level software or lower-level software with respect to another software component. Upper-level software is software that includes one or more pieces of lower-level software. Lower-level software is software that is included as a part of upper-level software.

[0058] For example, assume that the software product "OS1" is upper-level software that includes the software components "DriverA", "DriverB", and "DriverC". In this case, the dependency information adding unit 20F adds dependency information to the second software component table S2 of the software component that is lower-level software by including the identifier of the software component or software product that is upper-level software with respect to the software component. Also, the dependency information adding unit 20F adds dependency information to the second software component table S2 of the software product or software component that is upper-level software by including the identifier of the software component that is lower-level software with respect to the software product or the software component.

[0059] By adding the dependency information, for example, as shown in FIG. 6, the dependency information adding unit 20F can add information indicating the hierarchical structure represented by the dependency information to the plurality of generated second software component tables S2.

[0060] Returning to FIG. 1, the description will continue.

[0061] The signature adding unit 20G adds a signature to the second software component table S2. For the signature, a known signature for detecting forgery may be used. For example, for the signature, a signature using a public key, a signature using a private key, etc. may be used.

[0062] The signature - adding unit 20G preferably adds one signature to at least a part or the whole of a plurality of second software component lists S2 having a dependency relationship.

[0063] Specifically, in the case of the example shown in FIG. 6, for example, the extraction unit 20B may add a signature to each of the second software component list S2A, the second software component list S2B, and the second software component list S2C. Also, the signature - adding unit 20G may add a signature to each of the second software component list S2A and the second software component list S2B and the second software component list S2C. Also, the signature - adding unit 20G may add one signature to the whole of the second software component list S2A, the second software component list S2B, and the second software component list S2C. Also, the signature - adding unit 20G may add one signature to at least a part or the whole of a plurality of second software component lists S2 having a dependency relationship, and may also add a signature to the dependency relationship information.

[0064] By the signature - adding unit 20G adding one signature to at least a part or the whole of a plurality of second software component lists S2 having a dependency relationship, even if a signature has already been added to the original data, it becomes possible to verify both the signature added by the signature - adding unit 20G and the original signature.

[0065] For example, there may be a case where a signature has already been added to the second software component list S2A which is the first software component list S1. In this case, the signature - adding unit 20G adds one signature to the whole of the second software component list S2A, the second software component list S2B, and the second software component list S2C to which the dependency relationship information is added. By the signature - adding unit 20G adding a signature in such a unit, it becomes possible to verify both the signature originally added to the first software component list S1 which is the second software component list S2A and the signature newly added by the signature - adding unit 20G to the whole. Also, it becomes possible to use the signature originally added to the first software component list S1 as it is for verification.

[0066] Returning to FIG. 1, the description will be continued.

[0067] The output unit 20H outputs the second software component list S2.

[0068] The output unit 20H may output each of the plurality of second software component lists S2 generated by the generation unit 20E separately. Also, the output unit 20H may output the plurality of second software component lists S2 generated by the generation unit 20E as one file together with the given dependency information.

[0069] The output destination by the output unit 20H is not limited. For example, the output unit 20H outputs by storing the plurality of second software component lists S2 in the storage unit 12. Also, the output unit 20H outputs by displaying the plurality of second software component lists S2 on the input unit 16B. Also, the output unit 20H outputs by transmitting the plurality of second software component lists S2 to an external information processing device or the like via the communication unit 14.

[0070] Next, an example of the information processing flow executed by the information processing apparatus 10 of the present embodiment will be described.

[0071] FIG. 7 is a flowchart showing an example of the information processing flow executed by the information processing apparatus 10 of the present embodiment.

[0072] The acquisition unit 20A acquires the first software component list S1 to be processed (step S100). The extraction unit 20B extracts software components in which vulnerabilities may exist in the first software component list S1 acquired in step S100 based on the vulnerability list information 12A (step S102).

[0073] Then, the processing unit 20 repeats the processing of steps S104 to S108 for each software component extracted in step S102.

[0074] Specifically, the operation determination unit 20C determines the operability of the software component where a vulnerability may exist in the target device for introduction among the software components extracted in step S102 (step S104). If a negative determination is made in step S104 (step S104: No), the software component is excluded from being determined and from being the target for generating the second software component list S2. If an affirmative determination is made in step S104 (step S104: Yes), the process proceeds to step S106.

[0075] In step S106, the determination unit 20D determines the software component for which an affirmative determination was made in step S104 as the target for generating the second software component list S2 (step S106).

[0076] The generation unit 20E generates the second software component list S2 for the software component determined in step S106 (step S108).

[0077] By executing the processes of steps S104 to S108 for each software component extracted by the processing unit 20 in step S102, among the software components included in the first software component list S1, for each software component that may have a vulnerability and is determined to be operable in the target device for introduction, a second software component list S2 is generated.

[0078] Next, the dependency information adding unit 20F adds dependency information representing the dependency on the software components defined in other second software component lists S2 to the second software component list S2 generated in step S108 (step S110).

[0079] The signature adding unit 20G adds a signature to the second software component list S2 to which the dependency information has been added (step S112).

[0080] The output unit 20H outputs the second software component list S2 generated in step S108 and to which the dependency information and signature have been added in steps S110 and S112 (step S114). Then, this routine ends.

[0081] As described above, the information processing apparatus 10 of the present embodiment includes a determination unit 20D and a generation unit 20E. The determination unit 20D determines software components that may have vulnerabilities among the software components defined by the first software component list S1. The generation unit 20E generates a second software component list S2 corresponding to the determined software components.

[0082] Here, in the prior art, the software component list was managed in units of software, and management at the granularity required for vulnerability management was not performed. Specifically, conventional SBOMs were often created as an extension of license compliance management, and the management granularity of SBOMs was not necessarily optimal in the use cases of vulnerability management. For example, the Linux kernel is managed by the GPLv2 license as a whole, and it is expected that the SBOM will also be managed for the entire Linux kernel. However, vulnerabilities often occur not only in the kernel itself but also at the level of drivers and services included in the kernel. Therefore, it is desirable to manage the software component list at a granularity along with such vulnerabilities. However, such management was not performed in conventional SBOMs. That is, in the prior art, SBOMs were often managed in units of software products, and it was not always the case that this was the desired granularity as a vulnerability management unit. In other words, in the prior art, the software component list was managed in units of software, and the software component list was not managed at the granularity required for vulnerability management.

[0083] On the other hand, the information processing apparatus 10 of the present embodiment determines software components that may have vulnerabilities among the software components defined by the first software component list S1, and generates a second software component list S2 corresponding to the determined software components.

[0084] Therefore, in the information processing apparatus 10 of the present embodiment, it is possible to generate a second software component list S2 for each software component that may have a vulnerability.

[0085] Therefore, the information processing apparatus 10 of the present embodiment can manage the software component list at the granularity required for vulnerability management.

[0086] In addition, in the information processing apparatus 10 of the present embodiment, since a software component list (second software component list S2) at the granularity required for vulnerability management can be provided, for example, when providing an SBOM to a user, it is possible to provide the SBOM separately when used as a VEX (Vulnerability Exploitability eXchange).

[0087] In the information processing apparatus 10 of the present embodiment, for each of the software components in which vulnerabilities may exist among the plurality of software components defined by the first software component list S1, a second software component list S2 is generated. That is, in the information processing apparatus 10 of the present embodiment, a plurality of second software component lists S2 obtained by dividing the first software component list S1 according to the granularity of vulnerabilities can be generated. Therefore, in the information processing apparatus 10 of the present embodiment, similarly to the above effect, it is possible to manageably provide the second software component list S2 at the granularity required for vulnerability management. In addition, in the information processing apparatus 10 of the present embodiment, appropriate vulnerability handling is possible.

[0088] (Second Embodiment) In the above embodiment, a form in which a plurality of second software component lists S2 obtained by dividing the first software component list S1 according to the granularity of vulnerabilities are generated has been described as an example. In the present embodiment, a form in which a plurality of first software component lists S1 are acquired, and a second software component list S2 obtained by combining at least a part of the acquired plurality of first software component lists S1 according to vulnerabilities is generated will be described as an example.

[0089] FIG. 1 is a schematic diagram of an example of the information processing apparatus 11 of the present embodiment.

[0090] The information processing apparatus 11 is the same as the information processing apparatus 10 of the above embodiment except that it includes a processing unit 21 instead of the processing unit 20.

[0091] The processing unit 21 includes an acquisition unit 21A, an extraction unit 21B, an operation determination unit 21C, a determination unit 21D, a generation unit 21E, a dependency information adding unit 20F, a signature adding unit 20G, and an output unit 20H. The dependency information adding unit 20F, the signature adding unit 20G, and the output unit 20H are the same as the processing unit 20 in the above embodiment.

[0092] The acquisition unit 21A acquires a plurality of first software component tables S1.

[0093] FIG. 8 is an explanatory diagram of an example of a plurality of first software component tables S1 acquired by the acquisition unit 21A. In the present embodiment, it is assumed that the acquisition unit 21A acquires the SBOMs of software components such as OS1, DriverA, and DriverC, which are actually one software product, as the respective first software component tables S1 (first software component tables S1A to S1C), and an explanation will be given.

[0094] Returning to FIG. 1 and continuing the explanation. Similar to the extraction unit 20B, the extraction unit 21B extracts software components in which vulnerabilities may exist, included in the first software component table S1, based on vulnerability list information regarding vulnerabilities. In the present embodiment, the extraction unit 21B extracts software components in which vulnerabilities may exist, from among the software components defined in each of the plurality of first software component tables S1 (first software component tables S1A to S1C), based on vulnerability list information regarding vulnerabilities.

[0095] FIG. 9 is a schematic diagram of an example of the data configuration of the vulnerability list information 12B. The vulnerability list information 12B is a database in which information regarding vulnerabilities is centrally managed, similar to the vulnerability list information 12A.

[0096] For example, the vulnerability list information 12B is information in which a plurality of vulnerability information is defined for each vulnerability and software component in which the vulnerability may exist. Similar to the vulnerability list information 12A, the vulnerability information includes a vulnerability number, a target software, and vulnerability detailed information. In the present embodiment, the target software is identification information for each of a software product and a software component. For the target software, the name of the software product, the name of the software component, etc. are used. Further, in the present embodiment, as an example, an example is shown in which the vulnerability detailed information is described in a pattern of "a vulnerability exists" of "type of vulnerability" for the "software component name" subordinate to the "upper software component name".

[0097] The extraction unit 21B reads the vulnerability list information 12B from an external information processing device via the storage unit 12 or the communication unit 14. The extraction unit 21B may use a public database such as NVD or JVN as the vulnerability list information 12B, or may use VEX information included in the SBOM that is the first software component list S1 as the vulnerability list information 12B.

[0098] The extraction unit 21B extracts, as software components in which a vulnerability may exist, the software products or software components defined by the vulnerability list information 12B from among the software products or software components defined by each of the plurality of first software component lists S1 acquired by the acquisition unit 21A.

[0099] FIG. 10 is an explanatory diagram of an example of a software component in which a vulnerability extracted by the extraction unit 21B may exist.

[0100] Assume a case where the acquisition unit 21A acquires the SBOMs of the software components of the OS1, DriverA, and DriverC shown in FIG. 8 as the respective first software component lists S1 (the first software component lists S1A to S1C). In this case, the extraction unit 21B extracts the software components of OS1, DriverA, and DriverC as software components in which a vulnerability may exist based on the vulnerability list information 12B (see FIG. 10).

[0101] Further, based on the obtained vulnerability list information 12B, the extraction unit 21B identifies the dependency relationship of each of the plurality of first software component tables S1 obtained by the acquisition unit 21A.

[0102] For example, assume a case where the acquisition unit 21A acquires the SBOMs of the software components of the OS1, DriverA, and DriverC shown in FIG. 8 as the respective first software component tables S1 (first software component tables S1A to S1C). In this case, the extraction unit 21B analyzes the vulnerability list information 12B shown in FIG. 9 to identify the dependency relationship indicating that the software components DriverA, DriverB, and DriverC are software components included in or used by the OS1. The extraction unit 21B identifies the dependency relationship by analyzing the vulnerability list information 12B through pattern matching, natural language processing, or the like.

[0103] Returning to FIG. 1, the description will continue.

[0104] The operation determination unit 21C determines the presence or absence of operability of each of the software components in which vulnerabilities may exist, among the software components defined by each of the plurality of first software component tables S1, in the device to which the software component is to be introduced. The operation determination unit 21C may determine the presence or absence of operability in the same manner as the operation determination unit 20C.

[0105] FIG. 11 is an explanatory diagram of an example of the determination result by the operation determination unit 21C. FIG. 11 shows an example of the determination result of the presence or absence of operability of the software components "OS1", "DriverA", and "DriverC" extracted as software components in which vulnerabilities may exist by the extraction unit 21B. In FIG. 1, "operating" indicates a determination result of having operability, and "not operating" indicates a determination result of not having operability.

[0106] Returning to FIG. 1, the description will continue.

[0107] The determination unit 21D determines software components that may have vulnerabilities among the software components defined by each of the plurality of first software component lists S1.

[0108] In the present embodiment, the determination unit 21D determines a plurality of software components that may have vulnerabilities among the software components respectively defined by each of the plurality of first software component lists S1.

[0109] As described above, in the present embodiment, the acquisition unit 21A acquires the plurality of first software component lists S1. Then, the extraction unit 21B extracts a plurality of software components that may have vulnerabilities included in each of the plurality of first software component lists S1 based on the vulnerability list information 12B. Therefore, in the present embodiment, the determination unit 21D determines a plurality of software components that may have vulnerabilities by determining the plurality of software components extracted by the extraction unit 21B among the software components defined by each of the plurality of first software component lists S1.

[0110] Furthermore, in the present embodiment, the determination unit 21D determines software components that are determined to be operable by the operation determination unit 21C among the plurality of software components that may have vulnerabilities extracted by the extraction unit 21B.

[0111] In the case of the example shown in FIG. 11, the determination unit 21D determines the software components "OS1", "DriverA", and "DriverC" that are determined to be operable among the software components "OS1", "DriverA", and "DriverC" that may have vulnerabilities extracted by the extraction unit 21B.

[0112] In addition, the determination unit 21D identifies the dependency relationships of the determined plurality of software components.

[0113] The determination unit 21D identifies the dependency relationship by analyzing the vulnerability list information 12B through pattern matching, natural language processing, or the like. Further, the determination unit 21D obtains the dependency relationship specified by the extraction unit 21B, thereby identifying the dependency relationships of the determined plurality of software components.

[0114] The generation unit 21E generates a second software component table S2 corresponding to the software components determined by the determination unit 21D.

[0115] In the present embodiment, the generation unit 21E generates the second software component table S2 for each combined software component obtained by combining at least a part of the plurality of software components determined by the determination unit 21D.

[0116] FIG. 12 is an explanatory diagram of an example of generation of the second software component table S2 in the present embodiment.

[0117] For example, assume a scenario where the acquisition unit 21A acquires the first software component tables S1 (first software component tables S1A to S1C) of the software product "OS1", the software components "DriverA" and "DriverC", and the determination unit 21D determines the software components "OS1", "DriverA", and "DriverC" that are software components where vulnerabilities may exist and are determined to have operability.

[0118] In this case, the generation unit 21E generates one second software component table S2 for the combined software obtained by combining the software components "OS1", "DriverA", and "DriverC". For example, in the case of the example shown in FIG. 12, the generation unit 21E generates one second software component table S2 for the combined software obtained by combining the first software component table S1A, the first software component table S1B, and the first software component table S1C.

[0119] Further, the generation unit 21E may generate one second software component table S2 for the combined software obtained by combining a plurality of software components having the specified dependency relationships among the determined plurality of software components. For example, in the case of the example shown in FIG. 12, the generation unit 21E generates one second software component table S2 for the combined software obtained by combining the first software component table S1A, the first software component table S1B, and the first software component table S1C, which have dependency relationships.

[0120] Further, the generation unit 21E may generate a second software component table S2 for each combined software component obtained by combining at least a part of the plurality of software components determined by the determination unit 21D, or may generate a second software component table S2 for a combined software component obtained by combining some of the software components. For example, in the case of the example shown in FIG. 12, the generation unit 21E may generate a second software component table S2 for the first software component table S1A and a second software component table S2 for the combined software obtained by combining the first software component table S1B and the first software component table S1C.

[0121] The generation unit 21E may generate the second software component table S2 in the same manner as the generation unit 20E.

[0122] The dependency relationship information adding unit 20F, the signature adding unit 20G, and the output unit 20H are the same as those in the above embodiment.

[0123] Next, an example of the information processing flow executed by the information processing apparatus 11 of the present embodiment will be described.

[0124] FIG. 13 is a flowchart showing an example of the information processing flow executed by the information processing apparatus 11 of the present embodiment.

[0125] The acquisition unit 21A acquires a plurality of first software component lists S1 to be processed (step S200). The extraction unit 21B extracts, based on the vulnerability list information 12B, software components in which vulnerabilities may exist from each of the plurality of first software component lists S1 acquired in step S200 (step S202).

[0126] Then, the processing unit 21 repeats the processing of steps S104 to S206 for each of the software components extracted in step S202.

[0127] Specifically, the operation determination unit 21C determines the presence or absence of operability in the target device for introducing the software components in which vulnerabilities may exist extracted in step S202 (step S204). If a negative determination is made in step S204 (step S204: No), the software component is excluded from being determined and from being a target for generating the second software component list S2. If an affirmative determination is made in step S204 (step S204: Yes), the process proceeds to step S206.

[0128] In step S206, the determination unit 21D determines the software components for which an affirmative determination was made in step S204 as targets for generating the second software component list S2 (step S206).

[0129] By executing the processing of steps S204 to S206 for each of the software components extracted by the processing unit 21 in step S202, among the software components included in each of the plurality of first software component lists S1, the software components in which vulnerabilities may exist and which are determined to have operability in the target device for introduction are determined as targets for generating the second software component list S2.

[0130] The generation unit 21E generates the second software component list S2 for each combined software component obtained by combining at least a part of the plurality of software components determined as targets for generating the second software component list S2 (step S208).

[0131] Next, the dependency information adding unit 20F adds dependency information representing the dependencies between the plurality of software components included in the second software component list S2 to the second software component list S2 generated in step S208 (step S210).

[0132] The signature adding unit 20G adds a signature to the second software component list S2 to which the dependency information has been added (step S212).

[0133] The output unit 20H outputs the second software component list S2 generated in step S208 and to which the dependency information and the signature have been added in steps S210 and S212 (step S214). Then, this routine ends.

[0134] As described above, in the information processing apparatus 11 of the present embodiment, the acquisition unit 21A acquires a plurality of first software component lists S1. The determination unit 21D determines, from among the software components defined in each of the plurality of first software component lists S1, a plurality of software components that may have vulnerabilities. Then, the generation unit 21E generates a second software component list S2 for each combined software component obtained by combining at least a part of the determined plurality of software components.

[0135] For example, assume that the acquisition unit 21A acquires the SBOMs of the software components of OS1, DriverA, and DriverC, which are actually one software product, as the respective first software component lists S1 (first software component list S1A to first software component list S1C) (see FIG. 8). In this case, depending on the request, it may be preferable to output a second software component list S2 obtained by combining at least a part of these software components having dependencies.

[0136] Therefore, in the information processing apparatus 11 of the present embodiment, the generation unit 21E generates a second software component list S2 for each combined software component obtained by combining at least a part of the determined plurality of software components.

[0137] Therefore, in the information processing apparatus 11 of the present embodiment, in addition to the effects of the above embodiment, it is possible to manage a software component list having vulnerabilities in units of software products.

[0138] Further, by attaching dependency information to the second software component list S2, the information processing apparatus 11 can provide the second software component list S2 hierarchically in units of software products.

[0139] Next, an example of the hardware configuration of the information processing apparatus 10 and the information processing apparatus 11 of the above embodiment will be described.

[0140] FIG. 14 is a hardware configuration diagram of an example of the information processing apparatus 10 and the information processing apparatus 11 of the above embodiment.

[0141] The information processing apparatus 10 and the information processing apparatus 11 of the above embodiment include a control device such as a CPU (Central Processing Unit) 90B, a storage device such as a ROM (Read Only Memory) 90C, a RAM (Random Access Memory) 90D, and an HDD (hard disk drive) 90E, and an I / F unit 90A which is an interface with various devices, and a bus 90F that connects each unit, and has a hardware configuration using a normal computer.

[0142] In the information processing apparatus 10 and the information processing apparatus 11 of the above embodiment, the CPU 90B reads a program from the ROM 90C and executes it on the RAM 90D, whereby each of the above units is realized on a computer.

[0143] Note that the program for executing each of the above processes executed by the information processing apparatus 10 and the information processing apparatus 11 of the above embodiment may be stored in the HDD 90E. Further, the program for executing each of the above processes executed by the information processing apparatus 10 and the information processing apparatus 11 of the above embodiment may be provided by being pre - incorporated in the ROM 90C.

[0144] In addition, the information processing apparatus 10 of the above embodiment and the program for executing the above processing executed by the information processing apparatus 11 may be stored in a computer-readable storage medium such as a CD-ROM, CD-R, memory card, DVD (Digital Versatile Disc), flexible disk (FD), etc. in a file in an installable format or an executable format, and provided as a computer program product. Further, the program for executing the above processing executed by the information processing apparatus 10 and the information processing apparatus 11 of the above embodiment may be stored on a computer connected to a network such as the Internet, and provided by being downloaded via the network. Further, the program for executing the above processing executed by the information processing apparatus 10 and the information processing apparatus 11 of the above embodiment may be provided or distributed via a network such as the Internet.

[0145] Note that although the embodiments of the present invention have been described above, the above embodiments are presented as examples and are not intended to limit the scope of the invention. This novel embodiment can be implemented in various other forms, and various omissions, replacements, and changes can be made without departing from the gist of the invention. This embodiment and its modifications are included in the scope and gist of the invention, and are included in the invention described in the claims and its equivalent scope.

Explanation of Reference Numerals

[0146] 10, 11 Information processing apparatus 20A, 21A Acquisition unit 20B, 21B Extraction unit 20C, 21C Operation determination unit 20D, 21D Determination unit 20E, 21E Generation unit 20F Dependency information adding unit 20G Signature adding unit 20H Output unit

Claims

1. A determination unit that determines, among the software components defined by the first software component list, the software components that may have vulnerabilities; and A generation unit that generates a second software component list according to the determined software components; An information processing apparatus comprising the above.

2. The determination unit determines, among the plurality of software components defined by the first software component list, the software components that may have vulnerabilities, The generation unit generates the second software component list for each of the determined plurality of software components, The information processing apparatus according to claim 1.

3. Comprising an extraction unit that extracts, based on vulnerability list information regarding vulnerabilities, the software components that may have vulnerabilities included in the first software component list, The determination unit determines the extracted software components among the software components defined by the first software component list, The information processing apparatus according to claim 1.

4. The determination unit determines, among the software components defined respectively in each of the plurality of first software component lists, the software components that may have vulnerabilities, The generation unit generates the second software component list for each combined software component obtained by combining at least a part of the determined plurality of software components, The information processing apparatus according to claim 1.

5. Comprising an extraction unit that extracts, based on vulnerability list information regarding vulnerabilities, the software components that may have vulnerabilities among the software components defined respectively in each of the plurality of first software component lists, The determination unit determines the extracted software components among the software components defined respectively in each of the plurality of first software component lists, The information processing apparatus according to claim 4.

6. Comprising an operation determination unit that determines, for each of the extracted software components, the presence or absence of operability in the target device for introducing the software component, The determination unit determines the software components determined to have operability among the software components defined by the first software component list, The information processing apparatus according to claim 3 or claim 5.

7. A dependency relationship information providing unit that provides dependency relationship information indicating a dependency relationship with respect to software components defined in another said second software component table to the said second software component table. The information processing apparatus according to claim 1.

8. A signature providing unit that provides a signature to the said second software component table. The information processing apparatus according to claim 1, comprising the same.

9. The said signature providing unit provides one signature to at least a part or all of the plurality of said second software component tables having a dependency relationship. The information processing apparatus according to claim 8.

10. An output unit that outputs the said second software component table. The information processing apparatus according to claim 1, comprising the same.

11. An information processing method executed by an information processing apparatus, comprising: a step of determining, among software components defined by a first software component table, the software components that may have vulnerabilities; a step of generating a second software component table corresponding to the determined software components; An information processing method including the above.

12. a step of determining, among software components defined by a first software component table, the software components that may have vulnerabilities; a step of generating a second software component table corresponding to the determined software components; An information processing program for causing a computer to execute the above.

Images