Information processing system, information processing method and program

Abstract

To provide an information processing system, an information processing method, and a program for supporting the management of software assets. [Solution] An information processing system comprising: an expected information storage unit that stores expected model information that indicates at least one of information indicating components that should be included in the software asset and attribute information according to the classification axis of the software asset; a data acquisition unit that acquires an SBOM related to the software asset to be evaluated; an estimation unit that compares the SBOM to be evaluated with the expected model information and generates suspected omission information that indicates the possibility of information being missing in the SBOM to be evaluated from the information difference between the SBOM and the expected model information; and a presentation unit that presents the suspected omission information to a user.

Description

[Technical Field]

[0001] The present disclosure relates to an information processing system, an information processing method, and a program for managing software assets. [Background technology]

[0002] In recent years, with the increasing sophistication of software development and usage, software assets are now composed of a large number of software components, including open source software, external libraries, etc. In this situation, the importance of the Software Bill of Materials (SBOM) is increasing as a means of understanding the components that make up software assets and their attribute information.

[0003] SBOM is used as basic information for understanding vulnerability risks inherent in software assets. For example, Patent Document 1 discloses a technology for detecting vulnerability risks in software assets by comparing software component information described in SBOM with a vulnerability database. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Publication No. 2025-023828 Summary of the Invention [Problem to be solved by the invention]

[0005] When using SBOM to assess risks such as vulnerabilities in software assets, the quality of the information contained in the SBOM itself has a significant impact on the results of the risk assessment of the software assets. SBOMs may be provided by vendors (e.g., IT vendors, system integrators (SIers)) that provide at least part of the software assets, or they may be generated using SBOM generation tools. The content and granularity of the information contained in an SBOM may vary depending on the source of the SBOM or the generation tool, etc. Therefore, there is a need for technology to assess the quality of an SBOM.

[0006] One of the objectives of the exemplary embodiments of the present disclosure is to provide an information processing system, an information processing method, and a program for supporting the management of software assets. [Means for solving the problem]

[0007] An information processing system according to one aspect of the present disclosure includes: an expected information storage unit that stores expected model information that indicates at least one of information indicating components to be included in the software assets and attribute information according to a classification axis of the software assets; a data acquisition unit that acquires an SBOM including at least one of information indicating a plurality of components included in the software asset to be evaluated and attribute information; an estimation unit that compares the SBOM of the evaluation target with the expected model information, and generates missing information indicating a possibility of missing information in the SBOM of the evaluation target from an information difference between the SBOM and the expected model information; and a presentation unit that presents the suspected missing information to a user.

[0008] According to the information processing system, by comparing the SBOM for the software asset to be evaluated with expected model information that indicates the information that should normally be included in the software asset, it is possible to systematically grasp the sufficiency of the information included in the SBOM. Other problems and other solutions disclosed in the present application will become clear from the embodiments and drawings of the present disclosure. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 is a diagram illustrating an example of the configuration of an information processing system according to an embodiment of the present disclosure. [Figure 2] FIG. 2 is a block diagram illustrating an example of a hardware configuration of the management server 1 shown in FIG. [Figure 3] FIG. 3 is a block diagram illustrating an example of the software configuration of the information processing system shown in FIG. [Figure 4] FIG. 4 is a diagram for explaining an example of a method for acquiring an SBOM. [Figure 5] FIG. 5 is a flowchart illustrating an example of information processing executed in the information processing system illustrated in FIG. DETAILED DESCRIPTION OF THE INVENTION

[0010] An information processing system according to an embodiment of the present disclosure will be described below with reference to the drawings. In the accompanying drawings, identical or similar elements are designated by identical or similar reference symbols and names, and duplicate descriptions of identical or similar elements may be omitted in the description of the embodiment. Note that the contents shown in the drawings are merely examples for explaining the present embodiment and are merely schematic examples for ease of explanation of the present embodiment. The contents of the drawings may be modified or changed within the scope of no technical problem.

[0011] <System Overview> An information processing system according to this embodiment (hereinafter, sometimes referred to as the present system) is a system that supports software asset management by evaluating the quality of SBOM related to software assets. In this embodiment, "software assets" refer to software operated by a business entity that is a user of this system. The term "software assets" refers to software in a broad sense, including not only application programs for running a computer but also computer systems that include multiple programs, libraries, middleware, operating systems (OSs), and the like. In other words, software assets include all elements that make up a computer system, excluding physical devices (hardware). Software assets may include software provided by a business entity to external parties, as well as software used only internally by the business entity.

[0012] SBOM, also known as a software bill of materials (SBOM), is a list of software asset components and their attribute information organized in a machine-readable format. The SBOM may include information indicating the components that make up a software asset, as well as software asset attribute information, such as the names of each component (including the names of libraries, frameworks, or modules used in the software asset), version information for each component, license information applicable to each component, manufacturer information for each component (information indicating the component's developer or provider), information indicating the relationships between components (information indicating the dependencies, call relationships, or hierarchical structure between components), verification information such as hash values ​​for verifying the integrity of the components, and management information such as timestamps (e.g., information indicating the time of creation, publication, incorporation, or activation of the software component, or the time the SBOM was created or updated).

[0013] In this embodiment, as shown in Figure 4, a case will be described as an example in which a software asset is constructed by combining programs delivered from multiple vendors and the software asset is operated. Figure 4 illustrates a case in which systems delivered by a contractor such as an SIer (System Integrator) and a product vendor such as an IT vendor are combined and deployed via a source code management tool to a software asset operation server (a server for using or providing software assets to external parties; a provision system). In such a case, the SBOM may be obtained from each vendor that provides the system, or may be generated using an SBOM generation tool. SBOMs obtained by these multiple methods may be combined to generate an SBOM for a single software asset.

[0014] When using an SBOM generation tool, the SBOM generation tool may be applied to a source code management tool, or the SBOM generation tool may be applied to a delivery system, which is the execution environment of the software assets. Furthermore, an SBOM may be generated by combining component information obtained by running the SBOM generation tool on the source code management tool with component information obtained by running the SBOM generation tool on the delivery system. When the SBOM generation tool is applied to a source code management tool, the entire source code managed by the source code management tool can be analyzed, which tends to result in a higher comprehensiveness of detectable components compared to when the SBOM generation tool is run in the execution environment of the software assets. On the other hand, when the SBOM generation tool is run in the execution environment of the software assets, component information about not only application programs but also middleware and OS can be obtained.

[0015] Note that Figure 4 is merely an example, and the software assets to which this system can be applied are not limited to the configuration shown in Figure 4. For example, this system may be applied to software assets developed in-house by a business entity that is a user of this system, with the SBOM being the evaluation target. In this case, the SBOM may be created by a person involved in the development or production of the software asset.

[0016] The content and granularity of the information contained in the SBOM varies depending on the source and generation method of the SBOM, and may not fully cover all the information that should normally be included in software assets. Missing information in the SBOM may hinder the management of software assets using the SBOM and the risk assessment of software assets.

[0017] In this embodiment, the information processing system evaluates the quality of the SBOM for a software asset to be evaluated using expected model information that indicates at least one of information indicating components to be included in the software asset and attribute information. Specifically, the system estimates the possibility of missing information in the SBOM by comparing the SBOM to be evaluated with the expected model information. Then, based on the comparison result between the SBOM to be evaluated and the expected model information, generates suspected omission information indicating the possibility of missing information in the SBOM to be evaluated. This suspected omission information does not conclusively determine the absence of information in the SBOM, but is evaluation information indicating the possibility of information insufficiency that may arise due to differences in the SBOM's acquisition source, generation method, description granularity, etc. This makes it possible to objectively and systematically grasp the sufficiency of information contained in the SBOM to be evaluated, regardless of the SBOM's acquisition method (provider, generation tool). The specific configuration and operation of the system will be described in detail below with reference to the accompanying drawings.

[0018] <System configuration> As shown in FIG. 1, the information processing system of this embodiment includes a management server 1 and one or more user terminals 2. The management server 1 and the user terminals 2 are communicably connected to each other via a network NW. In this embodiment, the network NW is primarily assumed to be the Internet, but is not limited thereto and may be constructed using, for example, a public telephone line network, a mobile phone line network, a wireless communication network, Ethernet (registered trademark), or the like. This system may also include an information processing terminal used by a provider (e.g., a contractor or manufacturing vendor shown in FIG. 4) that provides at least a portion of the software assets to users. Note that the illustrated configuration is an example and is not limiting.

[0019] <Administration Server 1> The management server 1 is an information processing device that performs various information processing related to software asset management, SBOM evaluation, etc. The management server 1 may be deployed in a user organization that uses the system, or in a business that provides the system. The "user organization" that uses the system may be a business entity or a constituent unit thereof, such as a corporate enterprise, research institution, non-profit organization (such as an educational institution or medical corporation), an organization without legal personality, a public organization, a public interest corporation, or a business association that operates software assets in a specific business activity, but is not limited to such an entity. The management server 1 may be configured in an on-premise form using a general-purpose computer such as a workstation or personal computer, or may be logically realized using cloud computing.

[0020] 2 is a block diagram illustrating an example of the hardware configuration of the management server 1. Note that the illustrated configuration is an example, and the management server 1 may have other configurations. The management server 1 includes at least a processor 10, a memory 11, a storage 12, a transmission / reception unit 13, an input / output unit 14, etc., which are electrically connected to one another via a bus 16.

[0021] The processor 10 is a computing device that controls the overall operation of the management server 1, controls the transmission and reception of data between each element, and performs information processing necessary for executing applications. For example, the processor 10 is a CPU (Central Processing Unit) and / or a GPU (Graphics Processing Unit). Each function of the management server 1 is realized by the processor 10 executing a program stored in the storage 12 and deployed in the memory 11.

[0022] The memory 11 includes a main memory configured with a volatile storage device such as a DRAM (Dynamic Random Access Memory), and an auxiliary memory configured with a non-volatile storage device such as a flash memory, an HDD (Hard Disc Drive), etc. The memory 11 is used as a work area for the processor 10, and also stores a BIOS (Basic Input / Output System) that is executed when the management server 1 starts up, various setting information, etc.

[0023] The storage 12 stores various programs such as application programs, and in particular stores programs for executing the various functions of the present system. A database storing data used for each process may also be constructed in the storage 12. For example, a storage unit 120 (described later) is realized as part of the storage area of ​​the memory 11 and / or the storage 12.

[0024] The transmitting / receiving unit 13 is a communication interface that enables the management server 1 to communicate with various information processing terminals such as the user terminal 2 via a communication network. The transmitting / receiving unit 13 may further include a short-range communication interface such as Bluetooth (registered trademark) and BLE (Bluetooth Low Energy) and / or a USB (Universal Serial Bus) terminal.

[0025] The input / output unit 14 is an information input device such as a keyboard, a mouse, etc., and an output device such as a display, etc. The input / output unit 14 may include a touch panel or the like that has both functions of inputting and outputting information, and may also include a printer, a speaker, etc. as output devices.

[0026] A bus 16 is commonly connected to the above elements and transmits, for example, address signals, data signals and various control signals.

[0027] <User device 2> The user terminal 2 is an information processing terminal owned by a member (member refers to any person belonging to a business entity, regardless of job title or position) of a user organization that uses this system. The user terminal 2 may be, for example, a mobile terminal such as a smartphone or tablet terminal, or a general-purpose computer such as a workstation or personal computer. The user terminal 2 also includes a processor 20, memory 21, storage 22, a transmitter / receiver 23, an input / output unit 24, etc., which are electrically connected to each other via a bus 26. Each element in the hardware configuration of the user terminal 2 can be configured in the same way as the management server 1 shown in FIG. 2, and detailed description of each element of the user terminal 2 will be omitted.

[0028] <System Functions (Software Configuration)> FIG. 3 is a block diagram illustrating an example of functions (software configuration) implemented in the present system. The management server 1 may include, for example, a data acquisition unit 101, an expected information generation unit 102, an estimation unit 103, a proposal information generation unit 104, a quality evaluation unit 105, and a presentation unit 106 as functions realized by the processor 10 executing a program. These functional units are illustrated as functions executed by the processor 10 of the management server 1, but may be configured to be executed by a processor of another information processing device, such as a user terminal 2, instead of the management server 1. The storage unit 120 of the management server 1 may include various databases, such as an expected information storage unit 121, an SBOM information storage unit 122, a setting information storage unit 123, and a vulnerability information database 124. Each storage unit is realized as part of the storage area of ​​the memory 11 and / or the storage 12 in the management server 1.

[0029] The expected information storage unit 121 stores expected model information indicating at least one of information indicating components to be included in a software asset and attribute information according to a classification axis of the software asset. Here, a "classification axis" refers to a criterion used to classify software assets based on a predetermined perspective. The expected information storage unit 121 may store expected model information for each classification category defined based on the classification axis. The specific content of the classification axis is not particularly limited, and may be set based on, for example, the configuration, usage, and application field of the software asset. A classification category is a division of software assets classified according to the above-mentioned classification axis. For example, when classifying software assets based on the type of operating system (OS), Linux (registered trademark)-based OS, Windows-based OS, etc. may be set as classification categories. In this case, the expected information storage unit 121 may store expected model information for each type of OS.

[0030] The expected model information is information indicating the desired SBOM for a software asset (information that should be included in the SBOM). The expected model information may include, for example, information indicating components that should be included in a software asset belonging to a classification category, and information indicating data items or attribute information contents that should be included as attribute information for a software asset. In the expected model information, components that should be included in a software asset may be set as required components, optional components, or recommended components. In addition, in the expected model information, data items of attribute information that should be included in the SBOM may be set as required items, optional items, or recommended items. The information set in the expected model information (information that should be included in the SBOM) may be divided into at least one layer of an operating system layer, a middleware layer, a library layer, and an application layer. In other words, the expected model information may include component information and / or attribute information for each layer.

[0031] The expected model information stored in the expected information storage unit 121 may be information generated based on an SBOM for one or more reference software assets, or may be information generated or supplemented based on standard configuration information of software assets published in an external information source. The expected information storage unit 121 may store information indicating data used to generate the expected model information, in association with identification information for each piece of expected model information. For example, the expected information storage unit 121 may store information identifying the reference software assets, information identifying standard configuration information acquired from an external information source, information identifying the external information source, etc. Furthermore, the expected information storage unit 121 may store management information for the expected model information, such as management information indicating the generation date and time of the expected model information, the classification axis and classification category to which the expected model information is applied, in association with the expected model information.

[0032] The expected information storage unit 121 may store one piece of expected model information for each classification category, or may store multiple pieces of expected model information. For example, the expected model information for each classification category may include expected model information indicating components that should be included in the software asset and expected model information indicating attribute information that should be included in the SBOM. Alternatively, expected model information may be set for each layer, such as an operating system layer, a middleware layer, a library layer, and an application layer.

[0033] The SBOM information storage unit 122 stores information related to the SBOM of software assets managed by this system. For example, the SBOM information storage unit 122 may store the SBOM related to the software asset in association with identification information for uniquely identifying the software asset operated by a user organization. The SBOM of each software asset stored in the SBOM information storage unit 122 may be associated with identification information (e.g., a user ID) for uniquely identifying the user organization that operates the software asset.

[0034] The SBOM stored in the SBOM information storage unit 122 may include information indicating the components that constitute the software asset, and attribute information of the software asset, such as the name, version information, license information, manufacturer information, information indicating the dependency or call relationships between the components, verification information such as a hash value, and management information related to each component (for example, a timestamp indicating the time of generation, publication, incorporation, or activation of the component). The SBOM information storage unit 122 may store this information in association with management information indicating the provider, generation method, generation date and time, or update date and time of the SBOM. Note that, when multiple SBOMs are acquired for the same software asset as shown in FIG. 4, the SBOM information storage unit 122 may store the multiple SBOMs in association with the identification information of the software asset, or may store an integrated SBOM formed by combining the multiple SBOMs in association with the identification information of the software asset.

[0035] The SBOM information storage unit 122 may store data used in generating the expected model information. For example, among the SBOMs stored in the SBOM information storage unit 122, the SBOM of the reference software asset referenced when generating the expected model information may be linked with label information indicating that it was the reference source, or with identification information of the generated expected model information. Furthermore, the SBOM information storage unit 122 may store standard configuration information of the software asset acquired from an external information source during the generation process of the expected model information.

[0036] "Standard configuration information" refers to information that indicates a general or representative configuration of a given software asset or software component and is published in an external information source. Standard configuration information is not necessarily limited to information indicating the actual configuration in a specific individual environment, but may also include configurations that are typically expected, recommended, or shown as reference examples. For example, standard configuration information may include configuration information described in configuration specifications, installation guides, reference configurations, recommended configuration examples, official documentation, etc. published by software vendors or developers. Standard configuration information may also include configuration information described in configuration files, dependency definition files, build definition files, etc., located in repositories published in open source software (OSS) projects. The SBOM information storage unit 122 may store such standard configuration information in association with management information indicating the source and date of acquisition of the information, and the software asset or software component to which it applies.

[0037] The setting information storage unit 123 stores various setting information used when information processing is performed by each functional unit described below. For example, the setting information storage unit 123 may store corrective action standard information that defines a selection policy for corrective actions to compensate for missing information for at least one of the components and attribute information items indicated in the expected model information. The corrective action standard information may include, for example, the type of recommended corrective action, the priority of the corrective action, conditions regarding whether or not the corrective action can be implemented, etc., corresponding to the data items of the components and / or attribute information included in the expected model information, and the data structure of the corrective action standard information is not particularly limited.

[0038] The setting information storage unit 123 may store, as setting information, determination conditions used when determining whether there is a possibility of information missing in the SBOM. Furthermore, when evaluating the degree of sufficiency of information in the SBOM, the setting information storage unit 123 may store setting information that defines the criteria for the evaluation, etc. In addition, the setting information storage unit 123 may store setting information that defines rules for generating expected model information, or may store display setting information when outputting the evaluation results of the SBOM to a user terminal. The display setting information may include setting information that defines the display format (format when outputting the evaluation results, UI settings, etc.), display priority, etc.

[0039] The setting information storage unit 123 may store setting information defined for each software asset classification category. The setting information storage unit 123 may also store setting information defined for each user organization. The above-described various setting information is merely an example, and the data structure of the various setting information stored in the setting information storage unit 123 is not particularly limited.

[0040] The vulnerability information database 124 stores information used to determine the vulnerability of software assets. For example, the vulnerability information database 124 may store attribute information used to determine the vulnerability of a software component and vulnerability information associated with the software component, in association with identification information for uniquely identifying the software component.

[0041] The vulnerability information stored in the vulnerability information database 124 may include, for example, a vulnerability identifier (such as a CVE identifier), information indicating an overview of the vulnerability, information indicating the severity of the vulnerability, information indicating the scope of impact, and information on countermeasures against the vulnerability. Items of attribute information used in vulnerability determination may include, for example, version information, manufacturer information, platform information, dependency information, or information on the execution environment, and at least some of these may be specified as information necessary for vulnerability determination.

[0042] The vulnerability information database 124 may be constructed based on vulnerability information provided by an external vulnerability information service, a public database, or vulnerability information independently managed by a user organization. For example, the vulnerability information database 124 may be updated to reflect vulnerability information periodically acquired or updated from an external information source, or may contain vulnerability information selected or processed by a user organization. The method and frequency of updating the information stored in the vulnerability information database 124 are not particularly limited.

[0043] In addition to the information stored in each of the above-mentioned storage units, the storage unit 120 may store history information of various information processes in the system, history information of evaluation results, user operation history, log information, etc. These pieces of information may be stored in association with identification information of software assets, identification information of SBOMs, information identifying user organizations, etc. The types and data structures of information stored in the storage unit 120 are not limited to the examples described above.

[0044] The data acquisition unit 101 acquires various data related to software assets to be managed by this system. Specifically, the data acquisition unit 101 acquires an SBOM that includes at least one of information indicating multiple components included in the software asset to be evaluated and attribute information of the software asset. The data acquisition unit 101 executes a process of registering the acquired SBOM in the SBOM information storage unit 122 in association with information that identifies the software asset to be evaluated.

[0045] The method of generating and acquiring an SBOM by the data acquisition unit 101 is not particularly limited. As described above, the SBOM for a software asset may be generated by a vendor that provides at least a portion of the software asset, or may be generated by applying an SBOM generation tool to a source code management tool and / or an operation server. The data acquisition unit 101 may acquire an SBOM generated or acquired by a user organization from the user terminal 2. For example, the data acquisition unit 101 may present a UI (User Interface) for accepting SBOM uploads from a user to the user terminal 2, and acquire an SBOM for the software asset to be evaluated via the UI.

[0046] Alternatively, the data acquisition unit 101 may acquire the SBOM from an information processing terminal and / or an SBOM generation tool used by the vendor (provider). Furthermore, the data acquisition unit 101 may refer to metadata recorded in a management ledger, a configuration management database, an asset management system, or the like related to software assets to acquire location information (file path, storage destination URL, repository reference information, etc.) of the SBOM associated with the software asset, and acquire the SBOM based on the location information.

[0047] The timing for acquiring information about software assets, such as an SBOM, is not particularly limited. For example, the data acquisition unit 101 may execute the acquisition process in response to a user instruction via the user terminal 2, or may execute the acquisition process periodically according to a preset schedule. Alternatively, the data acquisition unit 101 may acquire or reacquire the SBOM for the corresponding software asset in response to a predetermined event, such as deployment of the software asset, a version update, or a configuration change. For example, as shown in FIG. 4 , in an operation mode in which programs delivered from multiple vendors are integrated and deployed to a provider server, the data acquisition unit 101 may acquire the SBOM either before or after deployment. Furthermore, the data acquisition unit 101 may acquire or reacquire the SBOM when a predetermined operation, such as recording changes to source code or assigning identification information to indicate the status of the source code, is performed in a source code management tool.

[0048] When acquiring an SBOM, the data acquisition unit 101 may acquire management information of the SBOM. The management information may include, for example, the provider of the SBOM, the generation method, the acquisition date and time, the generation date and time, the update date and time, the type of SBOM generation tool, and the version information of the SBOM generation tool. The data acquisition unit 101 may register this management information in the SBOM information storage unit 122 in association with the acquired SBOM.

[0049] The data acquisition unit 101 may process the acquired SBOM into a format that is easy to use in the evaluation process by the estimation unit 103 (described later). For example, the data acquisition unit 101 may normalize information included in the acquired SBOM into a predetermined data format. Normalization refers to a process of absorbing differences in description format, data item configuration, or description granularity for component information and attribute information included in the SBOM and converting them into a common data structure that can be used for information processing in this system. The predetermined data format to be normalized is not particularly limited and may be, for example, a data format used for expected model information. Furthermore, when SBOMs for the same software asset are acquired from multiple sources (providers, creators), the data acquisition unit 101 may execute a process of combining and integrating the multiple SBOMs. The integration method is not particularly limited. For example, the same components may be matched using verification information such as component names, manufacturer information, or hash values, eliminating duplicates, and complementary integrating the attribute information included in each SBOM.

[0050] The expectation information generating unit 102 executes a process for generating expected model information. For example, the expectation information generating unit 102 may generate the expected model information using an SBOM related to one or more reference software assets. The reference software assets used for generating the expected model information may be, for example, software assets that already have operational performance in a user organization or software assets that have been constructed or evaluated in the past. The expectation information generating unit 102 may select one software asset to be the reference software asset from among the software assets belonging to each classification category in accordance with predetermined selection criteria, and set the SBOM related to the reference software asset in the expected model information.

[0051] Alternatively, the expectation information generating unit 102 may extract multiple software assets belonging to the same classification category on the classification axis as reference software assets, analyze the SBOM trends of the reference software assets extracted for each classification category, and generate expected model information based on the analysis results. When analyzing the SBOM trends, the expectation information generating unit 102 may calculate statistical values ​​of information included in the SBOM of multiple reference software assets. In this case, the calculated statistical values ​​are not particularly limited. For example, the expectation information generating unit 102 may calculate, as the statistical values, one or more statistical values ​​selected from the appearance frequency of components in the SBOM of multiple reference software assets, the fulfillment rate of attribute information (including the appearance frequency of attribute information), the representative value of attribute information, the co-occurrence frequency between components, the distribution of component version information, and the depth distribution of the dependency structure.

[0052] The expectation information generating unit 102 may define at least one of the components and attribute information to be included in software assets belonging to a classification category based on the above-mentioned statistical values, and generate expected model information for each classification category. The expectation information generating unit 102 may aggregate the components and / or attribute information included in the SBOMs related to multiple reference software assets, and classify each of the components and / or attribute information as required, recommended, or optional elements according to their frequency of appearance. In generating expected model information, for example, the expectation information generating unit 102 may define components that appear frequently in the SBOM of the reference software asset as components that should be included in software assets belonging to the classification category. Furthermore, data items with a high fulfillment rate of attribute information may be defined as required attribute information items, and data items with a fulfillment rate below a predetermined threshold may be defined as recommended or optional items.

[0053] When generating expected model information, the expected information generating unit 102 may acquire standard configuration information of the software asset that is publicly available in an external information source and use the standard configuration information to generate the expected model information. As described above, the external information source may be an official document published by a software vendor or developer, or may be an information source published in an open source software project.

[0054] The expected information generating unit 102 may generate expected model information based on a combination of standard configuration information and the SBOM of reference software assets accumulated by the user's organization. For example, the expected model information generating unit 102 may calculate the above-described statistical value by aggregating the components described in the standard configuration information and the components included in the SBOM of one or more reference software assets. The expected model generating unit 102 may also execute a process of complementing the expected model information generated using the SBOM of the reference software assets accumulated by the user's organization, with reference to the standard configuration information. For example, if there is a component or attribute information that is not included in the SBOM of the reference software asset but is considered to be typically included in software assets of a specific classification category in the standard configuration information, the expected model information may be added or reflected in the expected model information. Note that the expected model information may be generated solely from standard configuration information obtained from an external information source, or the expected model information generated from the standard configuration information may be complemented based on the SBOM of the reference software assets.

[0055] The expectation information generating unit 102 executes a process of registering the generated expected model information in the expectation information storage unit 121. The expectation information generating unit 102 may also execute a process of updating each piece of expected model information registered in the expectation information storage unit 121. When updating, information may be added to and / or corrected in the registered expected model information based on the SBOM and / or standard configuration information of a reference software asset that is different from the information used to generate the registered expected model information. The update of the expected model information may be executed in response to an instruction operation from a user, or may be executed automatically when a predetermined event (for example, registration or update of a reference SBOM, acquisition or update of standard configuration information, etc.) occurs.

[0056] The estimation unit 103 executes a process of estimating the possibility of information missing in the SBOM of the evaluation target using expected model information. Specifically, the estimation unit 103 compares the SBOM for the software asset of the evaluation target with expected model information, and generates suspected omission information indicating the possibility of information missing in the SBOM of the evaluation target from the information difference between the SBOM and the expected model information. As described above, the suspected omission information generated by the estimation unit 103 does not necessarily determine the absence of information in the SBOM of the evaluation target, but is evaluation information indicating the possibility of information insufficiency that may occur due to predetermined factors such as differences in the source of acquisition, generation method, or description granularity of the SBOM. Note that the factors that cause information insufficiency in the SBOM are not particularly limited and may include factors other than differences in the source of acquisition, generation method, or description granularity. The estimation unit 103 generates the suspected omission information as evaluation information indicating the possibility of information insufficiency, regardless of the factors that may cause information insufficiency.

[0057] In evaluating the quality of an SBOM related to a software asset, the estimation unit 103 may first execute a process of selecting expected model information to be applied to the software asset to be evaluated. The method of selecting expected model information is not particularly limited. For example, the estimation unit 103 may refer to information included in the SBOM related to the software asset to be evaluated, and identify the classification category to which the software asset belongs (the software asset classification to which the software asset to be evaluated belongs) based on a predetermined classification axis. Then, the estimation unit 103 may read expected model information corresponding to the identified classification category from the expected information storage unit 121, and select the expected model information as the expected model information to be applied to the software asset to be evaluated.

[0058] If multiple pieces of expected model information are registered for one classification category, the estimation unit 103 may accept a selection operation from the user to specify the expected model information, or may select the expected model information to be used for evaluation based on predetermined selection conditions (for example, selecting the expected model information with the most recent generation date / time or update date / time, selecting the expected model information with the largest amount of information, etc.). Alternatively, the quality of the SBOM may be evaluated using multiple pieces of expected model information. In this case, each of the multiple pieces of expected model information set for one classification category may be compared with the SBOM to be evaluated, and an evaluation result (suspected missing information) corresponding to each piece of expected model information may be generated.

[0059] The estimation unit 103 compares the selected expected model information with the SBOM to be evaluated to extract information differences between them. The "differences" here include components and / or attribute information defined as being included in the expected model information that are not included in the SBOM to be evaluated or that are insufficiently included. Based on the differences, the estimation unit 103 generates omission suspicion information indicating the possibility of missing information. The expression format of the evaluation results in the omission suspicion information is not particularly limited. For example, the omission suspicion information may include information indicating whether or not there is a possibility of missing information, or may include a list of components and / or attribute information identified as differences from the expected model information. Furthermore, the omission suspicion information may include indicators indicating the type, importance, or degree of missing information of potentially missing information. In this way, the estimation unit 103 may generate evaluation results at various levels of granularity, from simple presence / absence determination to detailed difference information.

[0060] The estimation unit 103 may calculate a score indicating the degree of sufficiency of information about the SBOM to be evaluated based on the difference in information between the SBOM and the expected model information, and generate suspected missing information including the score. The score indicating the degree of sufficiency is an index that qualitatively or quantitatively indicates the extent to which the SBOM to be evaluated covers information relative to the expected model information. The score may be expressed in the form of a numerical value, a graded evaluation value, or a label, and the display format of the score is not particularly limited. For example, the estimation unit 103 may calculate a score indicating the degree of sufficiency based on the proportion of information described in the SBOM among the information defined as essential in the expected model information.

[0061] Furthermore, when evaluating the quality of the SBOM, the layer structure constituting the software asset to be evaluated may be taken into consideration. For example, the estimation unit 103 may compare the SBOM to be evaluated with expected model information for at least one layer of the operating system layer, middleware layer, library layer, and application layer of the software asset to be evaluated, and generate missing information for each layer. In this case, the estimation unit 103 extracts differences based on component information and / or attribute information associated with each layer, and evaluates the possibility of missing information for each layer.

[0062] When evaluating the possibility of SBOM missingness for each layer, a score indicating the degree of information sufficiency for each layer may be calculated. For example, the estimation unit 103 may calculate a layer-specific score indicating the degree of information sufficiency for each layer based on the difference between the information and the expected model information identified for each layer, and generate missingness suspicion information including the layer-specific score. In other words, scores may be calculated individually for each of the operating system layer, middleware layer, library layer, and application layer based on the difference from the expected model information, and these layer-specific scores may be included in the missingness suspicion information. Note that the layers of software assets are not necessarily limited to the four layers exemplified above.

[0063] The estimation unit 103 may execute a process of identifying components for which vulnerability determination is impossible. For example, the estimation unit 103 may refer to the result of comparing the SBOM of the evaluation target with expected model information and to a vulnerability database, and extract, from among the components described in the SBOM, components for which attribute information (e.g., version information or OS information required for vulnerability determination) defined in the vulnerability database is missing, as components for which vulnerability determination is impossible. The estimation unit 103 may generate information indicating the identified components for which vulnerability determination is impossible, as at least a part of the omission suspicion information. For example, the omission suspicion information may include identification information of the components for which vulnerability determination is impossible, the type of attribute information missing in the components, or information indicating that vulnerability determination cannot be performed due to the missing information.

[0064] The content and expression format of the missing information generated as a result of the evaluation process by the estimation unit 103 are not limited to the above examples. The estimation unit 103 may generate any information as missing information as long as the format is suitable for indicating the possibility of missing information in the SBOM to be evaluated.

[0065] The proposal information generation unit 104 executes processing related to the proposal of corrective actions. For example, the proposal information generation unit 104 may generate corrective action proposal information by selecting a recommended corrective action for each information item determined to be possibly missing in the SBOM to be evaluated based on the suspected omission information generated by the estimation unit 103 and predefined corrective action standard information. The "information item determined to be possibly missing" included in the suspected omission information is, for example, a component identified as a difference from expected model information, a data item of attribute information, or an item indicating a lack of information identified on a layer-by-layer basis. The proposal information generation unit 104 extracts these items as targets for consideration of corrective actions and reads corrective action standard information set for the item from the setting information storage unit 123.

[0066] As described above, the corrective action criteria information defines a policy for selecting a corrective action to fill in missing information for at least one of the components and the attribute information. The corrective action may be selected from among a request for information supplementation from the SBOM provider and a rescan using an SBOM generation tool different from the tool used to generate the SBOM. The corrective action options are not necessarily limited to the above two examples; the corrective action options may include manual information supplementation by the user or a response that tolerates the missing information. The corrective action criteria information may define a recommended corrective action for each component and / or attribute information item, or may set the priority or implementation conditions of the corrective action. The proposal information generator 104 may refer to the corrective action criteria information corresponding to the missing information and select a corrective action appropriate for the missing information from among the corrective action candidates.

[0067] The proposal information generator 104 generates corrective action proposal information indicating the selected corrective action. The representation format of the corrective action proposal information is not particularly limited, and for example, the corrective action proposal information may include the type of corrective action, the information item (missing information) to be the target of the corrective action, the reason for the recommendation, the priority, or precautions for implementation. The corrective action proposal information may also include information specifying the person in charge of executing the procedure related to the corrective action (for example, the provider of the SBOM, a person in the user organization, etc.).

[0068] The proposed information generation unit 104 may propose different corrective actions for each of multiple missing information items included in the missing information suspected information, or may collectively propose a single corrective action for multiple missing information items. For example, if multiple pieces of missing attribute information are detected for an SBOM acquired from the same provider, the missing information may be collectively proposed as a replenishment request. The generation method and granularity of the corrective action proposal information can be flexibly set based on the corrective action standard information.

[0069] The quality evaluation unit 105 executes a process of evaluating entities involved in providing or generating the SBOM. For example, the quality evaluation unit 105 may evaluate the quality of the SBOM provided by each entity based on the degree of omission in the provided SBOM by aggregating suspected omission information generated for one or more SBOMs provided by each entity (provider) that provided the SBOM or for each entity that generated the SBOM (e.g., SBOM generation tool, SBOM creator, SBOM creator, etc.).

[0070] When the SBOM is provided by an external business (e.g., a software asset provider, a development contractor, or an external service provider), the quality evaluation unit 105 may aggregate the suspected omission information generated for multiple SBOMs for each SBOM provider and calculate a provision quality score for each provider according to the degree of information omission in the SBOM provided by the provider. The provision quality score may be calculated based on one or more types of data including the number of suspected omission information detected in the SBOM in which the provider is involved, the importance of the missing information, the distribution of layers in which omissions occur, and a score indicating the degree of information sufficiency, and the like; the calculation method is not particularly limited. The provision quality score may be expressed as a quantitative indicator using a numerical value, or as a qualitative indicator such as a graded evaluation or a pass / fail judgment.

[0071] The quality evaluation unit 105 may evaluate an SBOM generation tool. For example, the quality evaluation unit 105 may aggregate, for each type of SBOM generation tool, suspected omission information related to multiple SBOMs generated using the SBOM generation tool, and generate an evaluation result indicating the generation quality for each SBOM generation tool. If the SBOM is created or generated within a user organization, the quality evaluation unit 105 may evaluate an employee, department, or project involved in creating or generating the SBOM. For example, the quality evaluation unit 105 may aggregate suspected omission information related to multiple SBOMs created by each person in charge or department in charge, and generate an evaluation result indicating the quality of the SBOM creation work performed by the person in charge or department in charge.

[0072] The expression format of the evaluation results generated by the quality evaluation unit 105 is not particularly limited. For example, the quality evaluation unit 105 may generate information indicating in a list format the provision quality score or generation quality score calculated for each entity to be evaluated, or may generate pass / fail information indicating whether a predetermined evaluation standard is met. Furthermore, the quality evaluation unit 105 may add, together with the evaluation results, an overview of the suspected omission information that served as the basis for the evaluation. Note that the evaluation by the quality evaluation unit 105 (evaluation of entities involved in the provision and / or generation of the SBOM) may be performed in response to an instruction from a user, or may be configured to automatically execute an evaluation process or re-evaluate when the suspected omission information is generated.

[0073] The presentation unit 106 executes a process of presenting the evaluation result including the missing information to the user. The presentation unit 106 outputs the missing information to a user interface (UI) displayed on the user terminal 2, thereby visualizing the possibility of missing information in the SBOM to be evaluated in a form that can be grasped by the user.

[0074] The presentation format of the suspected omission information presented by the presentation unit 106 is not particularly limited. For example, the presentation unit 106 may output, to a user interface, one or more of: a score indicating the degree of sufficiency of information about the SBOM to be evaluated; a layer-specific score indicating the degree of sufficiency of information for each layer in the software asset to be evaluated; and a list of components identified as being unable to be determined for vulnerability. The presentation unit 106 may output the suspected omission information in a list display format or in a dashboard format. For example, the presentation unit 106 may display a score indicating the overall degree of information sufficiency for each SBOM to be evaluated, and may also display layer-specific scores for at least one layer selected from the operating system layer, the middleware layer, the library layer, and the application layer in parallel. Furthermore, if there is a component for which vulnerability determination is unable to be performed, a list indicating the identification information of the component and any missing attribute information may be displayed.

[0075] The presentation unit 106 may present, on the user interface presenting the suspected missing information, corrective action proposal information corresponding to each item of information determined to be possibly missing, along with the item. For example, the presentation unit 106 may display the corrective action proposal information generated by the proposal information generation unit 104 in association with each item of missing component or attribute information. The method of presenting the corrective action proposal information is not particularly limited. For example, the presentation unit 106 may display an outline of the recommended corrective action near the item of information determined to be possibly missing, or may place a link or operation element (such as a button) on the user interface for displaying details of the corrective action. When the user selects the operation element, the screen may transition to a screen displaying detailed information such as the content, implementation method, or responsible party of the corrective action. When presenting information suspected to be missing, the display format, such as color or size, may be changed depending on the importance of the information, so that more important information is emphasized.

[0076] The presentation unit 106 may also aggregate and present the suspected omission information and corrective action proposal information for each SBOM, software asset, or entity being evaluated. For example, the presentation unit 106 may display the evaluation results of multiple SBOMs in a list format and output a dashboard that allows a user to grasp at a glance the degree of information sufficiency, the presence or absence of omissions, and the presence or absence of recommended corrective actions for each SBOM. The presentation unit 106 may also present the evaluation results for each SBOM supply entity (provider or generator). In this case, the suspected omission information for SBOMs in which a specific supply entity is involved may be displayed in a list format, and the evaluation results for the supply entities generated by the quality evaluation unit 105 (supply quality scores such as a provision quality score and a generation quality score) may be presented on the same screen.

[0077] In the above, some or all of the functions of the data acquisition unit 101, expected information generation unit 102, estimation unit 103, proposed information generation unit 104, quality evaluation unit 105, and presentation unit 106 shown as functional units of the management server 1 may be configured to be realized by the processor 20 of the user terminal 2.

[0078] The UI operation reception unit 201 receives input operations from the user via various user interfaces displayed on the user terminal 2. The UI operation reception unit 201 acquires operation signals via various input means provided on the user terminal 2, such as a touch panel, a mouse, a keyboard, or a pointing device, and executes a process of transmitting the operation signals to the management server 1 via the transmission / reception unit 23.

[0079] <Example of information processing method> Next, an example of an information processing method executed by the information processing system of this embodiment will be described with reference to the flowchart illustrated in Fig. 5. Note that the flowchart illustrated in Fig. 5 is merely an example, and the information processing method according to this embodiment is not limited to this, and some of the processes may be omitted, the order may be changed, or other processes may be added.

[0080] First, the expected information generation unit 102 of the management server 1 generates expected model information based on the SBOM for one or more reference software assets and / or standard configuration information published in an external information source (step SQ100). The generated expected model information is registered in the expected information storage unit 121. Next, the data acquisition unit 101 of the management server 1 acquires the SBOM for the software asset to be evaluated and registers the SBOM in the SBOM information storage unit 122 (step SQ101).

[0081] Next, the estimation unit 103 of the management server 1 compares the SBOM of the evaluation target with the expected model information (step SQ102). The estimation unit 103 determines, through this comparison, whether or not there is a difference in information between the SBOM of the evaluation target and the expected model information (step SQ103). If it is determined that there is a difference from the expected model information (difference present in step SQ103), the estimation unit 103 generates omission suspicion information indicating the possibility of information omission in the SBOM of the evaluation target based on the difference (step SQ104). At this time, the estimation unit 103 may generate omission suspicion information including a score indicating the degree of sufficiency of information about the SBOM, a layer-specific score indicating the degree of sufficiency of information for each layer, and information indicating components for which vulnerability cannot be determined. Furthermore, the proposal information generation unit 104 may generate corrective action proposal information corresponding to the items of information suspected to be missing, based on the omission suspicion information and corrective action standard information.

[0082] Thereafter, the presentation unit 106 of the management server 1 presents the suspected omission information to the user based on the evaluation result by the estimation unit 103 (step SQ105). The presentation unit 106 may output to the user interface one or more of a score indicating the degree of sufficiency of information about the SBOM to be evaluated, a layer-by-layer score indicating the degree of sufficiency of information for each layer, or a list of components for which vulnerability determination is not possible. In addition to the suspected omission information, corrective action proposal information corresponding to the omission information may also be presented. Note that if it is determined that there is no difference from the expected model information ("no difference" in step SQ103), the process proceeds to step SQ105, and the presentation unit 106 presents the evaluation result indicating that there is no (or low) possibility of omission to the user.

[0083] In this embodiment, the information processing system compares the SBOM for a software asset to be evaluated with expected model information that indicates the information that should be included in the SBOM for the software asset to estimate the possibility of information omissions in the SBOM and presents the estimation result to the user. This makes it possible to evaluate, based on objective criteria, whether the SBOM to be evaluated sufficiently contains the information normally required for the software asset. Furthermore, because possible information omissions can be identified early, communication regarding information supplementation and confirmation with the provider of the software asset (e.g., a contractor, vendor, etc.) can be made more efficient.

[0084] Furthermore, by identifying components that lack the attribute information necessary for vulnerability assessment, it is possible to prevent oversights in vulnerability testing and EOL (End of Life) management, improving the accuracy of these management tasks. As a result, it is possible to raise the level of SBOM utilization throughout the organization and strengthen SBOM-based security management and governance. Furthermore, the information processing system of this embodiment can generate corrective action proposal information based on potentially missing information and present it to the user along with the evaluation results, thereby efficiently supporting the entire process from SBOM quality evaluation to corrective action.

[0085] The above-described embodiments are merely examples for facilitating understanding of the present disclosure, and are not intended to limit the present disclosure. The present disclosure can be modified or improved without departing from the spirit thereof, and it goes without saying that the present disclosure includes equivalents thereof.

[0086] For example, in the above embodiment, expected model information is generated for each classification category and applied to the evaluation of software assets belonging to that classification category. However, the manner in which expected model information is generated and applied is not limited to this. For example, the estimation unit may evaluate the software asset to be evaluated by using expected model information corresponding to multiple classification categories to which the software asset is estimated to belong. In this case, the estimation unit 103 may estimate the possibility of missing information in the SBOM based on the comparison result with one of the multiple expected model information or the evaluation result that combines the comparison results with multiple expected model information.

[0087] Furthermore, in the above embodiment, an example was shown in which the missing information suspicion information was generated based on the difference from the expected model information, but the method for generating the missing information suspicion information is not limited to this. For example, the estimation unit 103 may estimate the possibility of missing information by considering the trend of the difference, the frequency of occurrence, or past evaluation history in addition to the presence or absence of a difference from the expected model information. Furthermore, the missing information suspicion information is not limited to information generated at a single evaluation point in time, but may be updated or corrected based on history information accumulating multiple evaluation results.

[0088] In the above embodiment, corrective action proposal information is generated based on corrective action standard information. However, the generation of corrective action proposal information is not limited to this. For example, the proposal information generator 104 may present multiple corrective action candidates with priority according to the content of the suspected omission information. Furthermore, the corrective action proposal information may include performance information on corrective actions taken in the past or examples of responses to other software assets.

[0089] In the above embodiment, the quality of SBOM provision is evaluated based on the provider or creator of the SBOM. However, the subject of evaluation and the evaluation unit are not limited to this. For example, the quality evaluation unit 105 may aggregate multiple SBOMs by project, product line, or contract, and evaluate the quality of the SBOM for each unit. This makes it possible to grasp the maturity of SBOM management from multiple angles, both inside and outside the organization.

[0090] In the above embodiment, the evaluation results are presented on a user interface, but the presentation format of the evaluation results is not limited to this. For example, the presentation unit 106 may output the suspected omission information and corrective action proposal information as report-format data, a data format that can be linked to an external system, or notification information. In addition, the evaluation results may be used not only for viewing by users but also as part of a decision process or an automated operation flow in another information processing system.

[0091] Furthermore, the series of processes performed by the information processing system described in this specification may be implemented using software, hardware, or a combination of software and hardware. A computer program for implementing each function of the management server 1 according to this embodiment may be created and installed on a PC or the like. A computer-readable recording medium storing such a computer program may also be provided. Examples of the recording medium include a magnetic disk, an optical disk, a magneto-optical disk, and a flash memory. The computer program may also be distributed, for example, via a network without using a recording medium. A database such as a vulnerability information database may be managed by an information processing device other than the management server 1, and the functional unit of the management server 1 may acquire vulnerability information from the other information processing device.

[0092] Furthermore, the effects described herein are merely descriptive or exemplary and are not limiting. In other words, the technology according to the present disclosure may achieve other effects that are apparent to those skilled in the art from the description of this specification, in addition to or in place of the above-described effects.

[0093] The conference support system and conference support method of the present disclosure may have the following configuration. [Item 1] an expected information storage unit that stores expected model information that indicates at least one of information indicating components to be included in the software assets and attribute information according to a classification axis of the software assets; a data acquisition unit that acquires an SBOM including at least one of information indicating a plurality of components included in the software asset to be evaluated and attribute information; an estimation unit that compares the SBOM of the evaluation target with the expected model information, and generates missing information indicating a possibility of missing information in the SBOM of the evaluation target from an information difference between the SBOM and the expected model information; a presentation unit that presents the suspected missing information to a user. [Item 2] 2. The information processing system according to item 1, further comprising an expected information generating unit that generates the expected model information based on SBOM related to one or more reference software assets. [Item 3] The expectation information generation unit A plurality of software assets belonging to the same classification category on the classification axis are used as the reference software assets, Based on the statistical values ​​of the information included in the SBOM of the plurality of reference software assets, 3. The information processing system according to item 2, wherein at least one of components and attribute information to be included in software assets belonging to the classification category is defined, and the expected model information for each classification category is generated. [Item 4] The information processing system described in item 3, wherein the expected information generation unit calculates, as the statistical value, one or more statistical values ​​selected from the frequency of appearance of the component, the fulfillment rate of attribute information, the representative value of attribute information, the frequency of co-occurrence between components, the distribution of version information of the component, and the depth distribution of the dependency structure. [Item 5] The expectation information generation unit Obtaining standard configuration information for software assets that is publicly available from external information sources; Item 3. The information processing system according to item 2, which generates the expected model information based on a combination of the standard configuration information and the SBOM of the reference software assets accumulated in the user's organization. [Item 6] The expectation information generation unit Obtaining standard configuration information for software assets that is publicly available from external information sources; Item 3. The information processing system according to item 2, which references the standard configuration information to complement the expected model information generated using the SBOM of the reference software assets accumulated in the user's organization. [Item 7] Item 1. The information processing system according to item 1, wherein the estimation unit compares the SBOM of the evaluation target with the expected model information for at least one layer of an operating system layer, a middleware layer, a library layer, and an application layer in the software asset of the evaluation target, and generates the suspected missing information for each layer. [Item 8] The system further includes a vulnerability information database that stores attribute information used to determine the vulnerability of a software component and vulnerability information associated with the software component; The estimation unit By referring to the comparison result between the SBOM of the evaluation target and the expected model information and the vulnerability information database, extracting, from among the components described in the SBOM, components for which the attribute information specified in the vulnerability information database is insufficient, as components for which vulnerability determination is not possible; 2. The information processing system according to item 1, wherein the information processing system generates the missing suspicion information including information indicating the component for which vulnerability cannot be determined. [Item 9] The information processing system described in item 1, wherein the estimation unit calculates a score indicating the degree of sufficiency of information regarding the SBOM to be evaluated based on the difference in information between the SBOM and the expected model information, and generates the suspected deficiency information including the score. [Item 10] Item 8. The information processing system according to Item 7, wherein the estimation unit calculates a layer-specific score indicating the degree of sufficiency of information for each layer based on the difference in information relative to the expected model information identified for each layer, and generates the missingness suspicion information including the layer-specific score. [Item 11] The presenting unit, based on the missingness suspected information, An information processing system described in any one of items 1 to 10, which outputs to a user interface one or more of a score indicating the degree of sufficiency of information regarding the SBOM of the evaluation target, a layer-specific score indicating the degree of sufficiency of information for each layer in the software asset of the evaluation target, and a list of components whose vulnerabilities cannot be determined. [Item 12] a setting information storage unit that stores corrective action standard information that defines a selection policy for corrective action to compensate for missing information for each item of at least one of the components and the attribute information; The information processing system described in item 1 further includes a proposal information generation unit that selects a recommended corrective action for each item of information determined to be possibly missing in the SBOM to be evaluated based on the suspected omission information and the corrective action standard information, and generates corrective action proposal information. [Item 13] The information processing system described in item 12, wherein the presentation unit presents the corrective action proposal information corresponding to an item of information determined to be possibly missing on a user interface that presents the suspected missing information. [Item 14] Item 13. The information processing system of item 12, wherein the corrective action is selected from the group consisting of a request to the provider of the SBOM for additional information and a rescan using an SBOM generation tool different from the tool used to generate the SBOM. [Item 15] The information processing system described in item 1 further includes a quality evaluation unit that aggregates the suspected missing information generated for multiple SBOMs and calculates a provision quality score for each provider of the SBOM according to the degree of missing information provided. [Item 16] storing expected model information indicating at least one of information indicating components to be included in the software assets and attribute information according to a classification axis of the software assets; acquiring an SBOM including at least one of information indicating a plurality of components included in the software asset to be evaluated and attribute information; By comparing the SBOM of the evaluation target with the expected model information, generating missing information indicating a possibility of missing information in the SBOM of the evaluation target from an information difference between the SBOM and the expected model information; and presenting the suspected missing information to a user. [Item 17] storing expected model information indicating at least one of information indicating components to be included in the software assets and attribute information according to a classification axis of the software assets; acquiring an SBOM including at least one of information indicating a plurality of components included in the software asset to be evaluated and attribute information; By comparing the SBOM of the evaluation target with the expected model information, generating missing information indicating a possibility of missing information in the SBOM of the evaluation target from an information difference between the SBOM and the expected model information; and presenting the suspected missing information to a user. [Explanation of symbols]

[0094] 1 Management Server 2. User terminal 121 Expected information storage unit 101 Data Acquisition Unit 103 Estimation part 106 Presentation section

Claims

1. an expected information storage unit that stores expected model information that indicates at least one of information indicating components to be included in the software assets and attribute information according to a classification axis of the software assets; a data acquisition unit that acquires an SBOM including at least one of information indicating a plurality of components included in the software asset to be evaluated and attribute information; an estimation unit that compares the SBOM of the evaluation target with the expected model information, and generates missing information indicating a possibility of missing information in the SBOM of the evaluation target from an information difference between the SBOM and the expected model information; a presentation unit that presents the suspected missing information to a user.

2. 2. The information processing system according to claim 1, further comprising an expected information generating unit that generates the expected model information based on an SBOM relating to one or more reference software assets.

3. The expectation information generation unit A plurality of software assets belonging to the same classification category on the classification axis are used as the reference software assets, Based on the statistical values ​​of the information included in the SBOM of the plurality of reference software assets, 3. The information processing system according to claim 2, wherein at least one of components and attribute information to be included in the software assets belonging to the classification category is defined to generate the expected model information for each of the classification categories.

4. 4. The information processing system of claim 3, wherein the expected information generation unit calculates one or more statistical values ​​selected from the frequency of occurrence of the component, the fulfillment rate of attribute information, the representative value of attribute information, the frequency of co-occurrence between components, the distribution of version information of the component, and the depth distribution of the dependency structure as the statistical value.

5. The expectation information generation unit Obtaining standard configuration information for software assets that is publicly available from external information sources; 3. The information processing system according to claim 2, wherein the expected model information is generated based on a combination of the standard configuration information and the SBOM of the reference software assets accumulated in the user's organization.

6. The expectation information generation unit Obtaining standard configuration information for software assets that is publicly available from external information sources; 3. The information processing system according to claim 2, wherein the expected model information generated using the SBOM of the reference software assets accumulated in the user's organization is supplemented by referring to the standard configuration information.

7. 2. The information processing system according to claim 1, wherein the estimation unit compares the SBOM of the evaluation target with the expected model information for at least one layer of an operating system layer, a middleware layer, a library layer, and an application layer in the software asset to be evaluated, and generates the suspected missing information for each layer.

8. The system further includes a vulnerability information database that stores attribute information used to determine the vulnerability of a software component and vulnerability information associated with the software component; The estimation unit By referring to the comparison result between the SBOM of the evaluation target and the expected model information and the vulnerability information database, extracting, from among the components described in the SBOM, components for which the attribute information defined in the vulnerability information database is insufficient, as components for which vulnerability determination is not possible; The information processing system according to claim 1 , wherein the missingness suspicion information is generated to include information indicating the component whose vulnerability cannot be determined.

9. 2. The information processing system of claim 1, wherein the estimation unit calculates a score indicating the degree of sufficiency of information about the SBOM to be evaluated based on the difference in information between the SBOM and the expected model information, and generates the suspected omission information including the score.

10. 8. The information processing system according to claim 7, wherein the estimation unit calculates a layer-by-layer score indicating a degree of sufficiency of information for each layer based on a difference in information from the expected model information identified for each layer, and generates the missingness suspicion information including the layer-by-layer score.

11. The presenting unit, based on the missingness suspected information, An information processing system as described in any one of claims 1 to 10, which outputs to a user interface one or more of a score indicating the degree of sufficiency of information regarding the SBOM of the object to be evaluated, a layer-specific score indicating the degree of sufficiency of information for each layer in the software asset of the object to be evaluated, and a list of components whose vulnerabilities cannot be determined.

12. a setting information storage unit that stores corrective action standard information that defines a selection policy for corrective action to compensate for missing information for each item of at least one of the components and the attribute information; The information processing system of claim 1, further comprising a proposal information generation unit that selects a recommended corrective action for each item of information determined to be possibly missing in the SBOM to be evaluated based on the suspected omission information and the corrective action standard information, and generates corrective action proposal information.

13. The information processing system according to claim 12, wherein the presentation unit presents, on a user interface that presents the suspected missing information, the corrective action proposal information corresponding to the item along with the item of information that has been determined to be possibly missing.

14. 13. The information processing system of claim 12, wherein the corrective action is selected from the group consisting of a request to a provider of the SBOM for additional information and a rescan using an SBOM generation tool different from the tool used to generate the SBOM.

15. The information processing system according to claim 1, further comprising a quality evaluation unit that aggregates the suspected missing information generated for multiple SBOMs and calculates a provision quality score for each provider of the SBOM according to the degree of missing information provided.

16. storing expected model information indicating at least one of information indicating components to be included in the software assets and attribute information according to a classification axis of the software assets; acquiring an SBOM including at least one of information indicating a plurality of components included in the software asset to be evaluated and attribute information; generating missing information indicating a possibility of missing information in the SBOM of the evaluation target from a difference in information between the SBOM and the expected model information by comparing the SBOM of the evaluation target with the expected model information; and presenting the suspected missing information to a user.

17. storing expected model information indicating at least one of information indicating components to be included in the software assets and attribute information according to a classification axis of the software assets; acquiring an SBOM including at least one of information indicating a plurality of components included in the software asset to be evaluated and attribute information; generating missing information indicating a possibility of missing information in the SBOM of the evaluation target from a difference in information between the SBOM and the expected model information by comparing the SBOM of the evaluation target with the expected model information; and presenting the suspected missing information to a user.

Images