Information processing device, verification method, and verification program

Abstract

An information processing device (10) comprises: a reception unit (15B) that receives a designation of configuration information of a software product; a verification unit (15D) that, for each combination for which a dependency relationship between software components is described by the configuration information of the software product for which the designation has been received, compares the description of each software component corresponding to a constituent element of the combination with a reference corresponding to each software component corresponding to the constituent element of the combination among references collected from a source (30) of information about the software components, and verifies whether there are inconsistencies in the dependency relationships between the software components; and an output unit (15E) that outputs a result of the verification by the verification unit (15D).

Description

Information processing device, verification method, and verification program

[0001] The present invention relates to an information processing device, a verification method, and a verification program.

[0002] 2. Description of the Related Art Regarding software vulnerability management, SBOM (Software Bill of Materials) is known as one method for managing configuration information of software products that solves problems faced by both software development organizations and software user organizations.

[0003] SBOM is a machine-processable list that includes information on software components and their dependencies, and is sometimes called a "software bill of materials."

[0004] Examples of frameworks that guarantee the correctness or accuracy of such SBOM include Supply-chain Levels for Software Artifacts (SLSA) and CIS Software Supply Chain Security.

[0005] However, frameworks defined by SLSA, CIS Software Supply Chain Security, etc., are not yet widely adopted in society because they are time-consuming to implement and use, as they are widely related to the entire supply chain of software products.

[0006] Given that frameworks that guarantee validity are not widespread, there is a need for a system that can prevent incorrect information from being mixed into SBOM due to errors in the description of configuration information, and that can improve the quality of SBOM.

[0007] For example, as one of the conventional techniques for verifying an SBOM, a verification tool has been proposed that verifies whether or not the SBOM is written in accordance with a specific format.

[0008] "Guide to the Implementation of Software Bill of Materials (SBOM) for Software Management, Ver. 1.0," Cybersecurity Division, Commerce and Information Policy Bureau, Ministry of Economy, Trade and Industry, July 28, 2023; SLSA (Supply-chain Levels for Software Artifacts), [Retrieved August 8, 2024], Internet <URL: https: / / slsa.dev>; "CIS Software Supply Chain Security Guide v1.0," [Retrieved August 8, 2024], Internet <URL: https: / / www.cisecurity.org / insights / white-papers / cis-software-supply-chain-security-guide>

[0009] However, in the above-mentioned conventional technology, only whether or not the SBOM is written according to the format is verified, so there is room for improvement in that if the SBOM is written according to the format, any problems with accuracy will be overlooked.

[0010] Therefore, an object of the present invention is to provide an information processing device, a verification method, and a verification program that can verify the accuracy of an SBOM.

[0011] In order to solve the above-mentioned problems and achieve the object, the information processing device of the present invention has a receiving unit that receives specification of configuration information of a software product, a verification unit that, for each combination in which dependencies between software components are described in the configuration information of the software product for which the specification has been received, compares the descriptions of each of the software components corresponding to the components of the combination with references collected from information sources related to the software components that correspond to each of the software components corresponding to the components of the combination to verify whether or not there are any contradictions in the dependencies between the software components, and an output unit that outputs the verification results by the verification unit.

[0012] According to the present invention, the accuracy of SBOM can be verified.

[0013] FIG. 1 is a block diagram showing an example of the functional configuration of an information processing device. FIG. 2 is a diagram showing an example of reference collection items. FIG. 3 is a diagram showing an example of SBOM. FIG. 4 is a diagram showing an example of extraction of vertical dependency relationships. FIG. 5 is a diagram showing an example of reference collection. FIG. 6 is a diagram showing an example of verification of inconsistencies in development timing. FIG. 7 is a diagram showing an example of output of verification results. FIG. 8 is a flowchart showing the procedure of collection processing. FIG. 9 is a flowchart showing the procedure of verification processing. FIG. 10 is a diagram showing an example of hardware configuration.

[0014] Hereinafter, an information processing device, a verification method, and a verification program according to the present disclosure will be described with reference to the accompanying drawings. Note that this embodiment merely illustrates one example or one aspect, and the following description does not limit the structure, action, function, properties, characteristics, methods, uses, etc. according to the present disclosure.

[0015] <Overall Configuration> Fig. 1 is a block diagram showing an example of the functional configuration of an information processing device 10. For example, Fig. 1 shows the information processing device 10 that provides a verification function for verifying inconsistencies in descriptions of an SBOM against references collected from reliable information sources.

[0016] In one aspect, the information processing device 10 may be realized by a server device. For example, the information processing device 10 can provide the above-described verification function as a cloud service by executing platform as a service (PaaS) type middleware or software as a service (SaaS) type application.

[0017] 1, the information processing device 10 can be communicatively connected to an information source 30 and a verifier terminal 50 via a network NW. For example, the network NW may be realized by any type of communication network, whether wired or wireless, such as the Internet or a LAN (Local Area Network).

[0018] The information source 30 is a source of information about software components. In one aspect, if the software component is an OSS, the information source 30 may be a repository identified by a package URL (Uniform Resource Locator) in the SBOM. In another aspect, if the software component is proprietary, the information source 30 may be a URL where a supplier publishes information about the software component. Information about software components whose accuracy is guaranteed to a certain extent by these reliable information sources 30 is collected as a reference.

[0019] The verifier terminal 50 is a terminal device used by a user who receives the above-mentioned verification function. The term "verifier" here is not limited to the supplier who creates the SBOM, but may also include a third party who checks the SBOM, such as a government agency or an administrator of a platform that manages the SBOM. For example, the verifier terminal 50 may be implemented by any computer, including a personal computer, a smartphone, a tablet device, or a wearable device.

[0020] Although the above example illustrates a case in which the verification function is provided as a cloud service, the present invention is not limited to this. For example, the verification function may be provided on-premise. Furthermore, the verification function may be packaged as a function of a tool used by an SBOM verifier or SBOM creator, such as a creation tool that creates an SBOM from software source code or binary files.

[0021] Although the above verification function is implemented as a client-server system, the present invention is not limited to this. For example, the verification function may be provided as a standalone function by causing an application running on the verifier terminal 50 to execute processing corresponding to the verification function on the verifier terminal 50.

[0022] <Configuration of Information Processing Device 10> Next, the functional configuration of the information processing device 10 that provides the above-described verification function will be described. Fig. 1 schematically illustrates blocks related to the verification function possessed by the information processing device 10. As shown in Fig. 1, the information processing device 10 has a communication control unit 11, a storage unit 13, and a control unit 15. Note that Fig. 1 merely illustrates a selection of functional units related to the above-described verification function, and the information processing device 10 may be provided with functional units other than those illustrated.

[0023] The communication control unit 11 is a functional unit that controls communication with other devices such as the information source 30 and the verifier terminal 50. In one embodiment, the communication control unit 11 can be realized by a network interface card such as a LAN card. In one aspect, the communication control unit 11 can receive information about software components from the information source 30 as a reference. In another aspect, the communication control unit 11 can receive a request for verifying the SBOM from the verifier terminal 50, or output a response to the request, such as a verification result, to the verifier terminal 50.

[0024] The storage unit 13 is a functional unit that stores various types of data. In one embodiment, the storage unit 13 may be realized by internal, external, or auxiliary storage of the information processing device 10. For example, the storage unit 13 stores a reference DB (DataBase) 13A. The reference DB 13A will be described later together with a scene in which reference to or registration of the reference DB 13A is performed.

[0025] The control unit 15 is a functional unit that performs overall control of the information processing device 10. For example, the control unit 15 may be realized by a hardware processor. As shown in FIG. 1 , the control unit 15 includes a collection unit 15A, a reception unit 15B, an extraction unit 15C, a verification unit 15D, and an output unit 15E. Note that the control unit 15 may also be realized by hardwired logic or the like.

[0026] The collection unit 15A is a processing unit that collects information about software components as references from information sources 30. In one aspect, if the software component is an OSS, the collection unit 15A collects references from repositories identified by package URLs in the SBOM. In another aspect, if the software component is proprietary, the collection unit 15A collects references from URLs where suppliers publish information about the software components. Information about software components whose accuracy is confirmed to a certain extent by these reliable information sources 30 is collected as references.

[0027] Here, the collection unit 15A can collect references by targeting software components published by any supplier, not limited to a specific supplier or a specific domain.

[0028] More specifically, the collection unit 15A performs the following process for each of the K software components from which references are to be collected. That is, if the kth software component is an OSS, the collection unit 15A collects references for the kth software component from a repository or the like identified by a package URL. On the other hand, if the kth software component is proprietary, the collection unit 15A collects references for the kth software component from specification information that a supplier such as a vendor makes public at an official URL.

[0029] If a reference to the kth software component cannot be collected through any of these paths, the collection unit 15A determines whether or not there is a description of the kth software component in the SBOM with a digital signature. Note that, although an example in which the condition is that the SBOM has a digital signature has been given, an additional condition can be that the developer who issues the digital signature is a developer registered on the positive list.

[0030] At this time, if the SBOM with the digital signature contains a description related to the kth software component, the collection unit 15A collects the description related to the kth software component from the SBOM with the digital signature as a reference.

[0031] Furthermore, if the digitally signed SBOM does not contain a description of the kth software component, the collection unit 15A collects, as a reference, a description of the kth software component from the SBOM obtained via a specific system, such as a mobile device management system, which is assumed to be a route through which the possibility of tampering with the SBOM is low.

[0032] The references collected for each software component in this manner are stored in the reference DB 13A. These references may include basic information about the software component. For example, the references may include information that can be defined in a data field as SBOM configuration information. FIG. 2 is a diagram showing an example of reference collection items. As shown in FIG. 2, for each version of a software component, information such as the release date of the version, supported OS (Operating System), API (Application Programming Interface) compatibility, lower-level libraries, licenses, and vulnerabilities may be collected.

[0033] The reception unit 15B is a processing unit that receives various information from the verifier terminal 50. In one embodiment, the reception unit 15B can receive a request from the verifier terminal 50 to verify an SBOM. When receiving such a verification request, the reception unit 15B can also receive a specification of the SBOM to be verified. FIG. 3 is a diagram illustrating an example of an SBOM. FIG. 3 illustrates an excerpt from an XML (Extensible Markup Language) file written in accordance with a specific SBOM format, such as CycloneDX 1.2, as an example of an SBOM 200. For example, the SBOM 200 illustrated in FIG. 3 may include object models such as "Metadata," "Components," "Services," "Dependencies," "Compositions," "Vulnerabilities," "Formulation," "Annotations," and "Extensions." Note that the SBOM 200 shown in FIG. 3 is merely an example, and other SBOM formats or other file formats, such as JSON, may also be used.

[0034] The extraction unit 15C is a processing unit that extracts dependencies between software components described in the SBOM. In one embodiment, the extraction unit 15C can select a method for extracting vertical dependencies based on the SBOM format and file format of the SBOM, the specifications of which are accepted by the acceptance unit 15B. FIG. 4 illustrates an example of vertical dependency extraction. FIG. 4 schematically illustrates how vertical dependencies are extracted from the SBOM 200 shown in FIG. 3. As shown in FIG. 4, the extraction unit 15C can extract vertical dependencies based on the element name "Dependency" or the description of the section between the start tag and the end tag identified by the element name "Dependencies" among the tags described in the SBOM. In other words, in the example shown in FIG. 4, the description on line 30 of the SBOM 200 shown in FIG. 3 indicates that "bcprov-jdk15to18@1.78" is used as a JAR package as a subordinate library of "sbomtestsuite-parent@1.0.0." In this case, the combination of the upper software "sbomtestsuite-parent@1.0.0" and the lower library "bcprov-jdk15to18@1.78" can be extracted as one combination of vertical dependencies between software components.

[0035] The verification unit 15D is a processing unit that verifies whether there are any contradictions in the dependencies between software components. In one aspect, for each combination in which dependencies between software components are described in the SBOM, the specification of which is accepted by the accepting unit 15B, the verification unit 15D compares the descriptions of each software component corresponding to the components of the combination with references collected from the information source 30, which correspond to each software component corresponding to the components of the combination. For example, the verification unit 15D extracts an SBOM description for the mth combination from the SBOM, the specification of which is accepted by the accepting unit 15B. Furthermore, the verification unit 15D acquires references corresponding to each of the upper software and lower software corresponding to the components of the mth combination from the reference DB 13A stored in the storage unit 13. Then, the verification unit 15D compares the SBOM description with the reference description for each of the N verification items.

[0036] When comparing the SBOM description with the reference description, the verification unit 15D can verify whether there are any inconsistencies regarding the following verification items: "Inconsistencies in API compatibility," "Inconsistencies in API specifications," "Inconsistencies in vulnerability response," "Inconsistencies before and after development," and "Inconsistencies in development timing."

[0037] (1) API Compatibility Conflicts When verifying API compatibility conflicts, the verification unit 15D compares the SBOM description and the reference description regarding the API compatibility of the upper software and the lower software. For example, the verification unit 15D verifies whether the versions match or mismatch between the reference description regarding the API version of the lower software used by the upper software and the SBOM description regarding the API version of the lower software. For example, if there is a version mismatch between the reference description and the SBOM description, an API compatibility conflict can be detected. In this case, as an example only, an API compatibility conflict can be detected in which the reference description states that upper software X uses the API of lower library Y from the v1 era, while the description of lower library Y included in the SBOM states that v5 is used.

[0038] (2) Inconsistencies in API Specifications: When verifying inconsistencies in API specifications, the verification unit 15D compares the SBOM description and the reference description regarding the API specifications of the upper software and the lower software. For example, the verification unit 15D verifies whether the specifications match or mismatch between the reference description regarding the API specifications of the lower library and the SBOM description regarding the API specifications of the lower library. In this case, if there is a specification mismatch between the reference description and the SBOM description, an inconsistency in the API specifications can be detected. For example, a reference to lower library Y may state that the API has been updated in v5 and that the API from the v1 era cannot be compiled. However, this can detect an inconsistency in the API specifications where the description of lower library Y included in the SBOM indicates that v5 is being used.

[0039] (3) Inconsistencies in Vulnerability Responses: When a vulnerability response inconsistency is detected, the verification unit 15D compares the SBOM descriptions and reference descriptions regarding vulnerability responses for the upper and lower software. For example, the verification unit 15D verifies whether a reference description regarding the completion of development and maintenance of the lower software is present and whether an SBOM description regarding vulnerability responses for the lower software is present. In this case, if a reference description regarding the completion of development and maintenance of the lower software is present but an SBOM description regarding vulnerability responses for the lower software is absent, a vulnerability response inconsistency can be detected. For example, in a dependency relationship in which an upper library X uses a lower library Y, development and maintenance of the lower library Y ceased several years ago, and a fatal vulnerability remains unaddressed. However, there is no comment in the SBOM indicating that the vulnerability was addressed independently. This can detect an example of a vulnerability response inconsistency.

[0040] (4) Inconsistencies between Pre- and Post-Development In another aspect, when inconsistencies between pre- and post-development are verified, the verification unit 15D compares the SBOM description and the reference description regarding the development dates of the upper-level software and the lower-level software. For example, the verification unit 15D chronologically verifies the SBOM description regarding the development date of the upper-level software and the reference description regarding the development date of the lower-level software. In this case, the verification unit 15D can determine, by way of example only, whether the development date of the upper-level software precedes the development date of the lower-level software. If the development date of the upper-level software precedes the development date of the lower-level software, inconsistencies between pre- and post-development can be detected. In this case, by way of example only, a case of inconsistencies between pre- and post-development can be detected in which X from Company B is an application created in 2010 and describes the use of Company A's library Y as a lower-level library, but Company A's library Y was first published in 2020.

[0041] (5) Development Time Inconsistency: When verifying a development time inconsistency, the verification unit 15D compares the SBOM description and the reference description regarding the development time of the upper-level software and the lower-level software. For example, the verification unit 15D verifies whether the reference description regarding the development time of a software component of the upper-level software or the lower-level software matches or does not match the SBOM description regarding the development time of the software component. In this case, if there is a development time inconsistency between the reference description and the SBOM description, a development time inconsistency can be detected. For example, a development time inconsistency can be detected when the SBOM describes that library X is an application developed using language A in 1995, but the reference describes that language A itself was developed in 2009.

[0042] Here, we will explain the verification of the above-mentioned inconsistencies in development time using an example. Figure 5 is a diagram showing an example of reference collection. Figure 6 is a diagram showing an example of verification of inconsistencies in development time. Both Figures 5 and 6 show an example of verifying inconsistencies in development time in the dependency relationship between the upper software "sbomtestsuite-parent@1.0.0" and the lower library "bcprov-jdk15to18@1.78" shown in Figure 4.

[0043] 5 shows a scene in which a reference to the lower library "bcprov-jdk15to18@1.78" is collected before the specification of the SBOM 200 is accepted by the accepting unit 15B. As shown in FIG. 5, the collecting unit 15A collects the release date "Apr 06, 2024" of the lower library "BouncyCastleProvider v1.78" as a reference by referencing the repository of the package URL of the lower library "bcprov-jdk15to18@1.78=(BouncyCastleProvider v1.78)". The release date "Apr 06, 2024" of the lower library "BouncyCastleProvider v1.78" collected in this manner is stored in the reference DB 13A.

[0044] With such references collected in advance, verification unit 15D extracts the SBOM creation timestamp "2020-08-02T16:21:19Z" of the upper software "sbomtestsuite-parent@1.0.0" from SBOM 200. Then, verification unit 15D compares the SBOM creation timestamp "2020-08-02T16:21:19Z" of the upper software "sbomtestsuite-parent@1.0.0" with the release date "Apr 06, 2024" obtained from reference DB 13A as a reference for the lower library "BouncyCastleProvider v1.78." As a result, it is possible to detect a discrepancy in the development period, in that the SBOM creation timestamp “2020-08-02T16:21:19Z” of the upper software “sbomtestsuite-parent@1.0.0” is older than the release date “Apr 06, 2024” of the lower library “BouncyCastleProvider v1.78”.

[0045] Returning to the explanation of Fig. 1, output unit 15E is a processing unit that executes output control for verifier terminal 50. In one aspect, output unit 15E outputs the verification results by verification unit 15D to verifier terminal 50. For example, when an inconsistency in the dependency relationships between software components is detected, output unit 15E can display a message warning of the inconsistency or highlight a portion of the specified SBOM that is related to the inconsistency.

[0046] 7 is a diagram showing an example of the output of the verification results. In FIG. 7, an example of the verification results of SBOM 200 shown in FIG. 6 being displayed on verifier terminal 50 is shown. As shown in FIG. 7, SBOM 200 may be associated with and display a pop-up 210 containing a warning message about a development timing inconsistency: "Inconsistency detected. Possible inconsistency between lines 4 and 30...It is suspected that there is an error in the timing of SBOM creation or an error in the specification of the lower-level libraries being used." In addition, range W1 corresponding to line 4 and range W2 corresponding to line 30 in SBOM 200, which are related to the development timing inconsistency, may be highlighted, for example, in reverse video.

[0047] <Processing Flow> Next, a processing flow of the information processing device 10 according to this embodiment will be described. Here, (1) collection processing executed by the information processing device 10 according to this embodiment will be described, followed by (2) verification processing.

[0048] (1) Collection Processing Fig. 8 is a flowchart showing the procedure of the collection processing. This processing is merely an example and can be executed periodically, for example, once a day, once a week, once a month, or at a regular time.

[0049] 8, the collection unit 15A executes loop processing 1, which repeats the processes from step S101 to step S108 described below a number of times corresponding to the total number K of software components from which references are to be collected. Note that the processes from step S101 to step S108 described below do not necessarily have to be executed serially, and may be executed in parallel.

[0050] That is, if the k-th software component is an OSS (Yes in step S101), the collection unit 15A collects references of the k-th software component from a repository or the like identified by the package URL (step S102).

[0051] On the other hand, if the k-th software component is proprietary (No in step S101), the collection unit 15A collects references to the k-th software component from specification information published by suppliers such as vendors at official URLs (step S103).

[0052] If a reference to the kth software component cannot be collected in either step S102 or step S103 (No in step S104), the collection unit 15A determines whether there is a description of the kth software component in the SBOM with a digital signature (step S105).

[0053] At this time, if a description regarding the kth software component exists in the SBOM with the digital signature (Yes in step S105), the collection unit 15A collects the description regarding the kth software component from the SBOM with the digital signature as a reference (step S106).

[0054] On the other hand, if there is no description regarding the kth software component in the SBOM with a digital signature (step S105 No), the collection unit 15A collects a description regarding the kth software component from the SBOM obtained via a specific system as a reference (step S107).

[0055] Thereafter, the collection unit 15A stores the references collected in any one of the above steps S102, S103, S106, and S107 in the reference DB 13A (step S108).

[0056] By repeating this loop process 1, it is possible to collect references for each software component, targeting software components published by all suppliers, not just those from a specific supplier or a specific domain.

[0057] (2) Verification Process Fig. 9 is a flowchart showing the procedure of the verification process. This process can be started when the specification of SBOM is accepted by the accepting unit 15B.

[0058] As shown in FIG. 9, when the designation of an SBOM is accepted (step S301), the extraction unit 15C extracts dependencies between software components described in the SBOM whose designation is accepted in step S301 (step S302).

[0059] Thereafter, the verification unit 15D executes loop processing 1, which repeats the processes from step S303 to step S305 described below a number of times corresponding to the total number M of combinations of dependencies between the software components extracted in step S302. Note that the processes from step S303 to step S305 described below do not necessarily have to be executed serially, and may be executed in parallel.

[0060] That is, verification unit 15D extracts the description of the SBOM related to the m-th combination from the SBOM whose designation was accepted in step S301 (step S303). Furthermore, verification unit 15D acquires references corresponding to the upper software and the lower software corresponding to the components of the m-th combination from reference DB 13A stored in storage unit 13 (step S304).

[0061] Thereafter, the verification unit 15D executes a loop process 2 in which the process of step S305 described below is repeated a number of times corresponding to the total number N of verification items. Note that the process of step S305 may also be executed in parallel for each of the N verification items.

[0062] That is, the verification unit 15D verifies whether or not there is a contradiction in the nth verification item by comparing the description in the SBOM related to the nth verification item with the description in the reference related to the nth verification item (step S305).

[0063] By repeating this loop process 2, it is possible to verify the presence or absence of contradictions for each of the N verification items. Furthermore, by repeating loop process 1, it is possible to verify the presence or absence of contradictions for the N verification items for all M upward and downward dependencies described in the SBOM.

[0064] Thereafter, the output unit 15E outputs the verification result obtained in step S305 to the verifier terminal 50 (step S306), and the process ends.

[0065] <Summary> As described above, the information processing device 10 according to this embodiment accepts the specification of configuration information for a software product, and for each combination in which dependencies between software components are described in the configuration information for the software product whose specification has been accepted, compares the descriptions of each software component corresponding to the components of the combination with the references collected from the information source 30 that correspond to each software component corresponding to the components of the combination to verify whether there are any inconsistencies in the dependencies between the software components, and outputs the verification results. This makes it possible to verify inconsistencies in the dependencies between software components even if the SBOM is written exactly in the specified format. Therefore, the information processing device 10 according to this embodiment can verify the accuracy of the SBOM.

[0066] By verifying the accuracy of the SBOM in this way, it is also possible to reduce inquiries to suppliers when errors are discovered. For example, when creating an SBOM manually, if a suspected error in existing configuration information is found, it was necessary to find and inquire with the vendor or developer who actually manages the configuration information to confirm the content and the situation. However, this type of confirmation work can also be reduced.

[0067] <Exercise of Creativity> The matters described in this embodiment, such as specific examples of SBOM and references, and furthermore, the types of verification items, are merely examples and can be changed. Furthermore, the order of processes in the flowchart described in this embodiment can be changed or some processes can be skipped within a consistent range.

[0068] <Relative Evaluation> For example, in the above embodiment, absolute evaluation is given as an example to verify whether or not there is a contradiction between the description in the SBOM and the description in the reference, but relative evaluation can also be performed to verify whether or not there is a contradiction between the descriptions in the SBOM.

[0069] (1) License Conflicts An example of a verification item related to such relative evaluation is "license conflicts." For example, when verifying license conflicts, the verification unit 15D compares the SBOM descriptions related to the licenses of the upper software and the lower software. For example, the verification unit 15D determines whether the license of the lower software imposes an obligation to disclose source code and the license of the upper software is proprietary. If the above conditions are met, the verification unit 15D can detect license conflicts such as those exemplified below. For example, the verification unit 15D can detect license conflicts such as a case where the license of lower library Y is GPLv3, but the license of upper library X, which clearly states that it uses a modified version of GPLv3, is proprietary, and the source code of the modified lower library Y remains private.

[0070] (2) Inconsistency in Supported OS Another example of a verification item related to the relative evaluation described above is "inconsistency in supported OS." For example, when verifying inconsistency in supported OS, the verification unit 15D verifies whether the SBOM descriptions regarding the supported OS between the upper software and the lower software match or mismatch. In this case, if there is a mismatch in the supported OS, the verification unit 15D can detect inconsistencies in supported OS, such as the following example. For example, in a dependency relationship in which upper library X uses lower library Y, an inconsistency in supported OS can be detected, such as when upper library X supports only OS1 and lower library Y supports only OS2. In this case, it is also possible to further verify whether the SBOM describes that lower library Y is a proprietary product, its source code is not public, and that it uses stubs or converters.

[0071] (3) Inconsistencies Due to Insufficient Implemented Functions: Another example of a verification item related to the relative evaluation described above is a "inconsistency due to insufficient implemented functions." For example, when verifying inconsistencies due to insufficient implemented functions, the verification unit 15D determines whether the software product described in the SBOM achieves functionality at or above a certain level. If the software product achieves functionality at or above a certain level, the verification unit 15D determines whether an SBOM description exists for software components, such as libraries, that implement the software product's functionality. In this case, if an SBOM description does not exist for software components, such as libraries, that implement the software product's functionality, the verification unit 15D can detect inconsistencies due to insufficient implemented functions, as exemplified by the following example. For example, a software product may be an application with advanced Virtual Private Network (VPN) functionality, but may lack libraries that implement the VPN functionality or encryption functionality, and may also lack components that independently implement these functions.

[0072] (4) Inconsistencies in Constraint Specifications of Development Languages ​​Another example of a verification item related to the relative evaluation described above is "inconsistencies in Constraint Specifications of Development Languages." For example, when inconsistencies in Constraint Specifications of Development Languages ​​are verified, the verification unit 15D verifies inconsistencies in the Constraint Specifications of Development Languages ​​for software components of upper-level software or lower-level software. This makes it possible to detect cases such as, for example, Library X having a function to rewrite privileged memory on the OS, contrary to the description in the SBOM running on a Java™ VM, and no description in the SBOM indicating that the function to rewrite privileged memory uses another library.

[0073] (5) Inconsistency in Implementation Size: Another example of a verification item related to the relative evaluation described above is "inconsistency in implementation size." For example, when inconsistency in implementation size is verified, the verification unit 15D predicts the file size required to implement a function based on the description of the function of the upper software. The verification unit 15D then determines whether or not there is an inconsistency in implementation size based on the difference between the predicted file size and the actual file size described in the SBOM. For example, if the difference between the predicted file size and the actual file size is equal to or greater than a threshold, an inconsistency in implementation size, such as the following example, can be detected. For example, an inconsistency in implementation size can be detected, such as when the file size of upper application X itself is 1 KB, contrary to the description in the SBOM that upper application X is supposed to have all Apache-compatible web server functions. In this case, it can also be further verified whether libraries and applications commonly used in Apache systems are described as lower-level libraries.

[0074] <Implementation of a Specific Protocol> For example, the information processing device 10 can check the operation of a software product described in the SBOM by executing a process. For example, a specific protocol can be executed on a computer on which the software product is installed, and the execution results can be obtained and used to determine whether the software product is operating normally. As just one example, a protocol can be executed to call the API of a lower-level library and obtain the version information of the lower-level library as a result of the execution.

[0075] <System> The information including the processing procedures, control procedures, specific names, various data, and parameters shown in the above documents and drawings can be changed as desired unless otherwise specified. For example, any one or more of the functional units of the collection unit 15A, the reception unit 15B, the extraction unit 15C, the verification unit 15D, and the output unit 15E of the information processing device 10 may be configured as separate devices.

[0076] Furthermore, the components of each device shown in the figure are functional concepts and do not necessarily have to be physically configured as shown. In other words, the specific form of distribution and integration of each device is not limited to that shown. In other words, all or part of them can be functionally or physically distributed and integrated in any unit depending on various loads, usage conditions, etc. Note that each configuration may also be a physical configuration.

[0077] Furthermore, all or any part of the processing performed by the illustrated device may be realized by a program executed by a hardware processor such as an MPU (Micro-Processing Unit) or a CPU (Central Processing Unit), or may be realized as hardware using wired logic.

[0078] <Hardware> Next, an example of the hardware configuration of the information processing device 10 described in this embodiment will be described. For example, the information processing device 10 can be implemented by installing a program that realizes the functions of the information processing device 10 on a computer. For example, the information processing device 10 can be implemented by having the computer execute the program, which is provided as package software or online software. The computer referred to here includes desktop or notebook personal computers, rack-mounted server computers, and the like. Furthermore, the computer also includes smartphones, mobile phones, PHS (Personal Handyphone System) and other mobile communication terminals, as well as PDAs (Personal Digital Assistants). The functions of the information processing device 10 may also be implemented on a cloud server.

[0079] An example of a computer that executes the above program (verification program) will be described using Fig. 10. As shown in Fig. 10, the computer 1000 includes, for example, a memory 1010, a CPU 1020, a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. These components are connected by a bus 1080.

[0080] The memory 1010 includes a read-only memory (ROM) 1011 and a random access memory (RAM) 1012. The ROM 1011 stores a boot program such as a basic input / output system (BIOS). The hard disk drive interface 1030 is connected to a hard disk drive 1090. The disk drive interface 1040 is connected to a disk drive 1100. A removable storage medium such as a magnetic disk or optical disk is inserted into the disk drive 1100. The serial port interface 1050 is connected to a mouse 1110 and a keyboard 1120, for example. The video adapter 1060 is connected to a display 1130, for example.

[0081] 10 , the hard disk drive 1090 stores, for example, an OS 1091, an application program 1092, a program module 1093, and program data 1094. The storage unit 13 described in the above embodiment is provided in, for example, the hard disk drive 1090 or the memory 1010.

[0082] Then, the CPU 1020 reads out the program module 1093 and the program data 1094 stored in the hard disk drive 1090 into the RAM 1012 as necessary, and executes the above-mentioned procedures.

[0083] The program module 1093 and program data 1094 relating to the above-described verification program are not limited to being stored in the hard disk drive 1090, but may be stored in, for example, a removable storage medium and read by the CPU 1020 via the disk drive 1100. Alternatively, the program module 1093 and program data 1094 relating to the above-described program may be stored in another computer connected via a network such as a LAN or a WAN (Wide Area Network), and read by the CPU 1020 via the network interface 1070.

[0084] REFERENCE SIGNS LIST 10 Information processing device 11 Communication control unit 13 Storage unit 13A Reference DB 15 Control unit 15A Collection unit 15B Reception unit 15C Extraction unit 15D Verification unit 15E Output unit 30 Information source 50 Verifier terminal

Claims

a receiving unit that receives designation of configuration information of a software product; a verification unit that, for each combination in which dependencies between software components are described in the configuration information of the software product whose designation has been accepted, verifies whether or not there is a contradiction in the dependencies between the software components by comparing the description of each software component corresponding to the constituent elements of the combination with references collected from information sources related to the software components and corresponding to each software component corresponding to the constituent elements of the combination; an output unit that outputs a verification result by the verification unit; An information processing device comprising:

2. The information processing apparatus according to claim 1, wherein the information source corresponds to a repository identified by a package URL that publishes the software component, or a URL published by a supplier of the software component. 　 A verification method executed by an information processing device, comprising: a receiving step of receiving designation of configuration information of the software product; a verification step of verifying, for each combination in which dependencies between software components are described in the configuration information of the software product whose designation has been accepted, whether or not there is a contradiction in the dependencies between the software components by comparing the description of each software component corresponding to the components of the combination with a reference corresponding to each software component corresponding to the components of the combination among references collected from information sources related to software components; an output step of outputting a verification result obtained by the verification step; A verification method comprising: 　 a receiving step of receiving designation of configuration information of the software product; a verification step of verifying, for each combination in which dependencies between software components are described in the configuration information of the software product whose designation has been accepted, whether or not there is a contradiction in the dependencies between the software components by comparing the description of each of the software components corresponding to the components of the combination with references collected from information sources related to the software components and corresponding to each of the software components corresponding to the components of the combination; an output step of outputting a verification result obtained by the verification step; A verification program for running the above on a computer.

Images