Computer system and proposed test method

Abstract

It is necessary to narrow down the tests performed on IT systems that include software with patches applied to fix vulnerabilities. [Solution] The computer system maintains a database that manages vulnerability information of software constituting an IT system, defects that occurred in the IT system after the corresponding software vulnerability was corrected, and tests that detected the defects. When the computer system receives new vulnerability information, it calculates a similarity score that represents the similarity between the new vulnerability information and the vulnerability information stored in the database, identifies vulnerability information similar to the new vulnerability information based on the similarity score, identifies combinations of tests and defects that correspond to the identified vulnerability information, generates and outputs recommended test information for displaying the identified combinations of tests and defects.

Description

Technical Field

[0001] The present invention relates to a proposed technique for testing IT systems.

Background Art

[0002] In system development, it is necessary to conduct tests to verify the operation of the system. As a technique for generating a test execution plan, the technique described in Patent Document 1 is known. Patent Document 1 describes that "the generation of a test execution plan is performed by a test execution plan generation tool. The test execution plan generation tool uses a pre-defined test execution plan data model together with user-set test parameters. The pre-defined test execution plan data model accommodates test metadata representing software test domain data of a software test system used to evaluate a software application to be tested. The user-set test parameters provide specific test parameters for the test execution plan."

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] As a system development method, DevSecOps has attracted attention for shortening the development period and increasing the release frequency while ensuring the security of the system. In DevSecOps, it is necessary to conduct regression tests to confirm the operation of a system including software to which a patch for fixing a vulnerability has been applied. However, the number of tests to be conducted is large, and there are also tests that cannot be automated. Therefore, it is necessary to narrow down the tests to be conducted.

[0005] The present invention aims to provide a system and method for efficiently verifying the operation of a system after a vulnerability has been fixed. [Means for solving the problem]

[0006] A typical example of the invention disclosed in this application is as follows: A computer system comprising a processor, a storage device connected to the processor, and a communication device connected to the processor, wherein the system maintains a database that manages in association with vulnerability information of software constituting an IT system, defects that occurred in the IT system after the vulnerability of the software corresponding to the vulnerability information has been corrected, and tests that detected the defects, and the processor, upon receiving new vulnerability information, calculates a similarity score representing the similarity between the new vulnerability information and the vulnerability information stored in the database, identifies vulnerability information stored in the database that is similar to the new vulnerability information based on the similarity score, identifies a combination of the test and the defect that corresponds to the identified vulnerability information stored in the database, generates recommended test information for displaying the identified combination of the test and the defect, and outputs the recommended test information. [Effects of the Invention]

[0007] According to the present invention, the computer system can suggest recommended tests depending on the vulnerabilities that have been fixed. Other issues, configurations, and effects will be clarified by the following description of the embodiments. [Brief explanation of the drawing]

[0008] [Figure 1] This figure shows an example of the system configuration of Example 1. [Figure 2] This figure shows an example of the vulnerability information database in Example 1. [Figure 3] This figure shows an example of the vulnerability / defect response relationship database in Example 1. [Figure 4]This figure shows an example of the defect / test response relationship database for Example 1. [Figure 5] This figure shows an example of a test database for Example 1. [Figure 6] This is a sequence diagram illustrating the processing flow of the system in Example 1. [Figure 7] This flowchart shows an example of the process performed by the client terminal in Example 1. [Figure 8] This flowchart illustrates an example of the similarity calculation process performed by the test proposal device in Example 1. [Figure 9] This flowchart illustrates an example of the test search process performed by the test suggestion device of Example 1. [Figure 10] This figure illustrates an example of recommended test information generated by the test suggestion device of Example 1. [Figure 11] This figure shows an example of a screen displayed by the client terminal in Example 1. [Figure 12] This figure shows an example of the defect / test response relationship database from Example 1 in Example 2. [Figure 13] This flowchart illustrates an example of the test search process performed by the test suggestion device of Example 2. [Figure 14] This figure shows an example of the system configuration of Example 3. [Figure 15] This figure shows an example of the SBOM management database in Example 3. [Figure 16] This figure shows an example of the hierarchical structure of elements managed by SBOM. [Figure 17] This flowchart illustrates an example of the similarity calculation process performed by the test proposal device in Example 3. [Figure 18A] This flowchart illustrates an example of the test search process performed by the test suggestion device of Example 3. [Figure 18B] This flowchart illustrates an example of the test search process performed by the test suggestion device of Example 3. [Modes for carrying out the invention]

[0009] Hereinafter, embodiments of the present invention will be described with reference to the drawings. However, the present invention is not construed as being limited to the description of the embodiments shown below. It will be readily understood by those skilled in the art that the specific configuration can be changed without departing from the spirit or gist of the present invention.

[0010] In the configuration of the invention described below, the same or similar configurations or functions are denoted by the same reference numerals, and redundant descriptions are omitted.

[0011] The notations such as "first", "second", "third", etc. in this specification and the like are for identifying components, and do not necessarily limit the number or order.

[0012] The positions, sizes, shapes, and ranges, etc. of each configuration shown in the drawings and the like may not represent the actual positions, sizes, shapes, and ranges, etc. in order to facilitate the understanding of the invention. Therefore, in the present invention, it is not limited to the positions, sizes, shapes, and ranges, etc. disclosed in the drawings and the like.

Embodiment

[0013] FIG. 1 is a diagram showing an example of the configuration of the system of Embodiment 1.

[0014] The system is composed of a test proposal device 100, a plurality of client terminals 101, and a vulnerability information providing device 102. The test proposal device 100, the plurality of client terminals 101, and the vulnerability information providing device 102 are connected via a network 105 such as a LAN (Local Area Network). The connection method of the network may be either wired or wireless.

[0015] A client terminal 101 is a terminal operated by a user who develops or operates an IT system. A client terminal 101 may be, for example, a general-purpose computer, a smartphone, or a tablet device. An IT system consists of elements such as physical devices, an operating system (OS), middleware, and application software. Information about the elements of the IT system is managed as configuration information. Configuration information is, for example, an SBOM (Software Bill of Materials). The SBOM stores data including the software's identifier, version, and vendor.

[0016] The vulnerability information provider 102 manages information related to vulnerabilities (vulnerability information). Vulnerability information includes, for example, a CVE (Common Vulnerabilities and Exposures) identification number, information about the vulnerable element, and the content of the vulnerability.

[0017] The test suggestion device 100 suggests tests to be performed after applying patches to fix vulnerabilities in the software that constitutes the IT system. The test suggestion device 100 comprises an arithmetic unit 110, a storage device 111, and a communication device 112. Each hardware element is connected via a bus 114.

[0018] The arithmetic unit 110 is a processor or the like, and executes programs stored in the memory device 111. By executing processing according to the program, the arithmetic unit 110 operates as a functional unit (module) that realizes a specific function. In the following description, when the processing is described with a functional unit as the subject, it indicates that the arithmetic unit 110 is executing a program that realizes that functional unit.

[0019] The storage device 111 is a memory or similar device that stores the program executed by the arithmetic unit 110 and the information used by the program. The storage device 111 is also used as a work area. The test proposal device 100 may also be equipped with secondary storage devices such as an HDD (Hard Disk Drive) and an SSD (Solid State Drive). The communication device 112 is a device for connecting to the network 105.

[0020] The test suggestion device 100 may also include input devices such as a keyboard, mouse, and touch panel, and output devices such as a display.

[0021] The test suggestion device 100 has a similarity calculation unit 120, a test search unit 121, and an input / output unit 122 as its functional units. The test suggestion device 100 also maintains a vulnerability information DB 130, a vulnerability / defect response relationship DB 131, a defect / test response relationship DB 132, and a test DB 133.

[0022] Furthermore, the functional units of the test suggestion device 100 may be combined into a single functional unit, or a single functional unit may be divided into multiple functional units according to its function. In addition, the functions of the test suggestion device 100 may be implemented using a computer system consisting of multiple computers.

[0023] Figure 2 shows an example of the vulnerability information DB130 in Example 1.

[0024] The vulnerability information DB130 is a database for managing vulnerability information provided by the vulnerability information providing device 102.

[0025] The vulnerability information DB130 is, for example, a table-formatted information as shown in Figure 2, and stores entries containing vulnerability identifier 201, software 202, and vulnerability 203. Each entry corresponds to one piece of vulnerability information. Note that the fields included in an entry are not limited to those described above. It may not include any of the fields described above, or it may include other fields.

[0026] Vulnerability Identifier 201 is a field that stores an identifier for vulnerability information, such as a CVE identification number. Software 202 is a field that stores an identifier for software, such as the name of the vulnerable software. Vulnerability 203 is a field that stores data describing the nature of the vulnerability.

[0027] Note that the vulnerability information DB130 may use a data structure other than a table format.

[0028] Figure 3 shows an example of the vulnerability / defect response relationship DB131 in Example 1.

[0029] The Vulnerability / Defect Relationship Database 131 is a database for managing the correspondence between vulnerabilities and defects in IT systems that occur after applying patches to fix those vulnerabilities to the software. In some cases, multiple defects may occur in an IT system after a vulnerability has been fixed. In the following explanation, defects in IT systems that occur after applying patches to fix vulnerabilities to the software will simply be referred to as defects.

[0030] The vulnerability / defect response database DB131 is, for example, a table-formatted information as shown in Figure 3, and stores entries containing vulnerability identifiers 301 and defect identifiers 302. There is one entry for each combination of vulnerability information and defect type. Note that the fields included in an entry are not limited to those mentioned above. It may not include any of the fields mentioned above, or it may include other fields.

[0031] Vulnerability identifier 301 is the same field as vulnerability identifier 201. Defect identifier 302 is a field that stores an identifier representing the type of defect.

[0032] Note that the vulnerability / bug response DB131 may have a data structure other than a table format. Furthermore, the vulnerability / bug response DB131 may store tables for each IT system, as shown in Figure 3.

[0033] Figure 4 shows an example of the defect / test response relationship DB132 in Example 1.

[0034] The Defect / Test Relationship DB132 is a database for managing the relationship between defects and the tests that detected them. There may be multiple tests used to detect a defect.

[0035] The defect / test response database DB132 is, for example, a table-formatted information as shown in Figure 4, and stores entries containing a defect identifier 401, a defect description 402, and a test identifier 403. There is one entry for each combination of defect and test. Note that the fields included in an entry are not limited to those described above. It may not include any of the fields described above, or it may include other fields.

[0036] Defect identifier 401 is the same field as defect identifier 302. Defect description 402 is a field that stores the specific details of the defect that occurred. Test identifier 403 is a field that stores an identifier representing the type of test in which the defect was detected.

[0037] Note that the defect / test response DB132 may have a data structure other than a table format. Furthermore, the defect / test response DB132 may store tables for each IT system, as shown in Figure 4.

[0038] Figure 5 shows an example of Test DB133 in Example 1.

[0039] Test DB133 is a database for managing tests. Test DB133 contains information in a table format, such as shown in Figure 5, and stores entries that include a test identifier 501 and a test description 502. There is one entry for each test. Note that the fields included in an entry are not limited to those mentioned above. It may not include any of the fields mentioned above, or it may include other fields.

[0040] Test identifier 501 is the same field as test identifier 403. Test content 502 is a field that stores the specific details of the test. For example, test content 502 stores the program (tool) to be used and the parameters to be used.

[0041] Note that Test DB133 may have a data structure other than a table format. Also, Test DB133 may store tables for each IT system, as shown in Figure 5.

[0042] The test suggestion device 100 may also maintain a database that integrates the vulnerability / defect response DB 131 and the defect / test response DB 132 to manage the correspondence between vulnerability information, defects, and tests.

[0043] Figure 6 is a sequence diagram illustrating the processing flow of the system in Example 1.

[0044] The client terminal 101 obtains vulnerability information provided by the vulnerability information provider 102 (step S101). Alternatively, the vulnerability information provider 102 may send the vulnerability information to the client terminal 101 via push notification.

[0045] The client terminal 101 sends a search request containing vulnerability information to the test suggestion device 100 (step S102). At this point, the user operating the client terminal 101 does not need to have generated a patch to fix the vulnerability corresponding to the vulnerability information.

[0046] The input / output unit 122 of the test suggestion device 100 receives a search request. When the test suggestion device 100 receives a search request, it performs a similarity calculation process and a test search process (steps S103 and S104). Details of the similarity calculation process and the test search process will be described later.

[0047] The input / output unit 122 of the test suggestion device 100 transmits the recommended test information 1000 (see Figure 10) generated in the test search process to the client terminal 101 (step S105).

[0048] The user generates a patch based on vulnerability information. The user also refers to Recommended Test Information 1000 to determine which tests to perform and then runs tests on the IT system after applying the patch.

[0049] The user operates the client terminal 101 to send a registration request to the test suggestion device 100 to register the test execution results (step S111). The registration request includes vulnerability information, a test identifier, and details of the detected defects. If a new test not registered in the test DB 133 is executed, the registration request will include information indicating the content of the test instead of the test identifier.

[0050] When the test suggestion device 100 receives a registration request, it executes a DB update process (step S112). In the DB update process, at least the vulnerability / defect response DB 131 and the defect / test response DB 132 are updated. If a new test is executed, the test DB 133 is also updated.

[0051] After the DB update process is completed, the test suggestion device 100 sends a response to the client terminal 101 (step S113).

[0052] Figure 7 is a flowchart showing an example of the process performed by the client terminal 101 in Embodiment 1.

[0053] The client terminal 101 sends a search request to the test suggestion device 100 according to the user's operation (step S201).

[0054] When the client terminal 101 receives recommended test information 1000 from the test suggestion device 100, it displays the recommended test information 1000 (step S202).

[0055] Figure 8 is a flowchart illustrating an example of the similarity calculation process performed by the test suggestion device 100 of Example 1.

[0056] When the input / output unit 122 of the test suggestion device 100 receives a search request from the client terminal 101, it calls the similarity calculation unit 120. The called similarity calculation unit 120 starts the similarity calculation process.

[0057] The similarity calculation unit 120 generates a list of vulnerability information registered in the vulnerability information DB 130 (step S301).

[0058] The similarity calculation unit 120 selects one vulnerability from the list (step S302).

[0059] The similarity calculation unit 120 calculates a similarity score that represents the similarity between the selected vulnerability information and the vulnerability information included in the search request (step S303). Here, an example of how to calculate the similarity score is explained. In the following explanation, the vulnerability information included in the search request will be referred to as the target vulnerability information.

[0060] (S303-1) The similarity calculation unit 120 converts the content of the vulnerabilities contained in the selected vulnerability information and the target vulnerability information into text.

[0061] (S303-2) The similarity calculation unit 120 performs morphological analysis on each of the two texts. Based on the results of the morphological analysis, the similarity calculation unit 120 calculates a vector which is an embedding representation of the content of the vulnerability information contained in each of the selected vulnerability information and the target vulnerability information.

[0062] (S303-3) The similarity calculation unit 120 calculates the cosine similarity of the two vectors. The similarity calculation unit 120 assigns a similarity to the selected vulnerability information in the list.

[0063] The method for calculating the embedded text representation described above is just one example and is not limited thereto. Similarly, the method for calculating the similarity described above is just one example and is not limited thereto. Any index that represents the similarity between two pieces of vulnerability information is acceptable.

[0064] The similarity calculation unit 120 determines whether processing has been completed for all vulnerability information registered in the list (step S304).

[0065] If processing has not been completed for all vulnerability information registered in the list, the similarity calculation unit 120 returns to step S302 and performs the same processing.

[0066] Once processing is complete for all vulnerability information registered in the list, the similarity calculation unit 120 outputs the list to the test search unit 121 (step S305), and then terminates the similarity calculation process.

[0067] Figure 9 is a flowchart illustrating an example of the test search process performed by the test suggestion device 100 of Embodiment 1. Figure 10 is a diagram illustrating an example of recommended test information 1000 generated by the test suggestion device 100 of Embodiment 1.

[0068] When the test search unit 121 of the test suggestion device 100 receives input from the similarity calculation unit 120, it starts the test search process.

[0069] The test search unit 121 refers to the vulnerability / defect response relationship DB 131 and identifies the corresponding defect for each vulnerability information registered in the list (step S401). The test search unit 121 generates combinations of vulnerability information and defects and stores them in the work area.

[0070] The test search unit 121 refers to the defect / test correspondence DB 132 to identify the corresponding test for each identified defect (step S402). The test search unit 121 generates combinations of defects and tests and stores them in the work area.

[0071] The test search unit 121 generates a combination of vulnerability information, defects, and tests based on the processing results of steps S401 and S402 (step S403).

[0072] The test search unit 121 selects combinations based on similarity (step S404). For example, the test search unit 121 may select combinations with similarity greater than a threshold, select a predetermined number of combinations in descending order of similarity, or combine the two methods described above.

[0073] Alternatively, after selecting vulnerability information similar to the target vulnerability information based on similarity, steps S401, S402, and S403 may be executed.

[0074] The test search unit 121 generates recommended test information 1000 based on the selected combination (step S405), and then terminates the test search process. Specifically, the following processes are executed.

[0075] (S405-1) The test search unit 121 generates entries for the number of selected combinations in the recommended test information 1000.

[0076] (S405-2) The test search unit 121 sets the test identifier 1001 of each entry to the identifier of the test included in each combination. The test search unit 121 sets the recommendation level 1002 of each entry to the similarity of the vulnerability information included in each combination. The test search unit 121 sets the defect content 1003 of each entry to the defect content corresponding to the defect included in each combination.

[0077] Figure 11 shows an example of a screen displayed by the client terminal 101 of Embodiment 1.

[0078] When client terminal 101 receives recommended test information 1000, it displays screen 1100. Screen 1100 displays the vulnerability information included in the search request and the recommended test information 1000.

[0079] Similar vulnerabilities are often fixed with similar fixes, and when similar vulnerabilities are fixed, the detected defects are likely to be similar as well. Therefore, the test suggestion device 100 manages vulnerability information, tests, and defects in an associated manner, identifying defects caused by fixes for past vulnerabilities similar to the new vulnerability, and further identifying the tests that detected the defects. By presenting the identified tests and the details of the defects detected by those tests, the test suggestion device 100 enables users to prioritize testing for defects that are likely to occur. This makes it possible to conduct tests efficiently. [Examples]

[0080] Example 2 differs from Example 1 in that it considers the frequency of malfunctions and the degree of their impact. Below, Example 2 will be described focusing on the differences from Example 1.

[0081] The system configuration of Example 2 is the same as that of Example 1. The hardware configuration and functional configuration of the test suggestion device 100 in Example 2 are the same as those in Example 1. Furthermore, the information held by the test suggestion device 100 in Example 2 is the same as that in Example 1. However, in Example 2, the data structure of the defect / test response relationship DB 132 differs from that of Example 1. Figure 12 shows an example of the defect / test response relationship DB 132 of Example 2 as in Example 1.

[0082] Example 2 differs from Example 1 in that an impact level of 404 is added to the entry. Impact level 404 is a field that stores the impact level, which represents the magnitude of the impact of a defect in the IT system. The impact level may be set by the user, or it may be set based on a calculation algorithm that uses the scope of the impact or the nature of the defect.

[0083] The processing flow in the system of Example 2 is the same as that of Example 1. The similarity calculation process in Example 2 is the same as that of Example 1.

[0084] In Example 2, the content of the test search process differs in some respects. Figure 13 is a flowchart illustrating an example of the test search process performed by the test suggestion device 100 in Example 2.

[0085] The test search unit 121 calculates the execution frequency of each test by referring to the defect / test response relationship DB 132 (step S451). Specifically, the test search unit 121 counts the number of test identifiers stored in the test identifier 403.

[0086] The test search unit 121 refers to the vulnerability / defect response database 131 and identifies the corresponding defect for each vulnerability information registered in the list (step S401).

[0087] The test search unit 121 refers to the defect / test response relationship DB 132 to identify the corresponding test for each identified defect (step S402).

[0088] The test search unit 121 generates a combination of vulnerability information, defects, and tests based on the processing results of steps S401 and S402 (step S403).

[0089] The test search unit 121 calculates the recommendation score for each combination based on the similarity of vulnerability information, the impact of the defect, and the frequency of test execution (step S452).

[0090] For example, the test search unit 121 calculates the recommendation score by multiplying or adding the similarity score to the influence score and the execution frequency score. Note that the above calculation method is just an example and is not limited to it. Any calculation method that uses at least one of the influence score and the execution frequency score is acceptable.

[0091] The test search unit 121 selects a combination based on the recommendation level (step S453). The selection method is the same as in step S404.

[0092] The test search unit 121 generates recommended test information 1000 based on the selected combination (step S405), and then terminates the test search process.

[0093] According to Example 2, by considering not only the similarity of vulnerabilities but also the magnitude of the impact of the defects and the frequency of testing, it is possible to recommend more appropriate tests. [Examples]

[0094] Example 3 describes a method for presenting tests when no similar vulnerability information exists. The following description focuses on the differences between Example 3 and Example 1.

[0095] Figure 14 shows an example of the system configuration of Example 3.

[0096] The system configuration of Example 3 is the same as that of Example 1. The hardware and functional configuration of the test suggestion device 100 in Example 3 is the same as that of Example 1. In Example 3, some of the information held by the test suggestion device 100 is different. Specifically, the test suggestion device 100 in Example 3 newly holds an SBOM management DB 134.

[0097] Figure 15 shows an example of the SBOM management DB134 in Example 3. Figure 16 shows an example of the hierarchical structure of elements managed by SBOM.

[0098] The SBOM management DB134 is a database for managing the SBOM of an IT system. The SBOM management DB134 stores, for example, a table 1500, as shown in Figure 15, for each IT system. Table 1500 corresponds to the SBOM. Table 1500 stores entries including software 1501, vendor 1502, version 1503, and related information 1504. There is one entry for each piece of software (element). Note that the fields included in an entry are not limited to those mentioned above. It may not include any of the fields mentioned above, or it may include other fields.

[0099] Software 1501 is a field that stores the software identifier. Vendor 1502 is a field that stores the name of the software vendor, etc. Version 1503 is a field that stores the software version. Related 1504 is a field that stores the identifier of related software. Related 1504 stores the identifier of the software that is a component of the software corresponding to the entry.

[0100] SBOM allows us to understand the software's hierarchical structure (software dependencies) as shown in Figure 16.

[0101] The processing flow in the system of Example 3 is the same as in Example 1. In Example 3, the similarity calculation process and the test search process differ in some respects.

[0102] Figure 17 is a flowchart illustrating an example of the similarity calculation process performed by the test suggestion device 100 in Example 3.

[0103] The similarity calculation unit 120 generates a list of vulnerability information registered in the vulnerability information DB 130 (step S301).

[0104] The similarity calculation unit 120 selects one vulnerability from the list (step S302).

[0105] The similarity calculation unit 120 calculates a similarity score that represents the similarity between the selected vulnerability information and the target vulnerability information (step S303).

[0106] The similarity calculation unit 120 determines whether processing has been completed for all vulnerability information registered in the list (step S304).

[0107] If processing has not been completed for all vulnerability information registered in the list, the similarity calculation unit 120 returns to step S302 and performs the same processing.

[0108] Once processing is complete for all vulnerability information registered in the list, the similarity calculation unit 120 determines whether or not there is any vulnerability information with a similarity greater than the threshold (step S351). The threshold is assumed to be set in advance. Note that the threshold can be updated as needed.

[0109] If vulnerability information with a similarity score greater than the threshold exists, the similarity calculation unit 120 outputs a list to the test search unit 121 (step S305), and then terminates the similarity calculation process.

[0110] If no vulnerability information exists with a similarity score greater than the threshold, the similarity calculation unit 120 outputs an error to the test search unit 121 (step S352), and then terminates the similarity calculation process.

[0111] Figures 18A and 18B are flowcharts illustrating an example of the test search process performed by the test suggestion device 100 of Embodiment 3.

[0112] The test search unit 121 determines whether or not it has received a list input from the similarity calculation unit 120 (step S461).

[0113] When the similarity calculation unit 120 receives input from the list, the test search unit 121 refers to the vulnerability / defect response relationship DB 131 and identifies the corresponding defect for each vulnerability information registered in the list (step S401).

[0114] The test search unit 121 refers to the defect / test response relationship DB 132 to identify the corresponding test for each identified defect (step S402).

[0115] The test search unit 121 generates a combination of vulnerability information, defects, and tests based on the processing results of steps S401 and S402 (step S403).

[0116] The test search unit 121 selects a combination based on similarity (step S404).

[0117] The test search unit 121 generates recommended test information 1000 based on the selected combination (step S405), and then terminates the test search process.

[0118] In step S461, if the similarity calculation unit 120 determines that an error has been received, the test search unit 121 identifies the defect that occurred as a result of fixing the vulnerability corresponding to the target vulnerability information (step S462). In the following description, the software in the target vulnerability information will be referred to as the target software. Specifically, the following processes are executed.

[0119] (S462-1) The test search unit 121 refers to the vulnerability information DB 130 to search for an entry in which the target software identifier is set in the software 202, and obtains the vulnerability information identifier from the vulnerability identifier 201 of that entry.

[0120] (S462-2) The test search unit 121 refers to the vulnerability / defect response relationship DB 131 and searches for an entry in which the vulnerability identifier 301 is set to the identifier of the acquired vulnerability information. The test search unit 121 obtains the defect identifier from the defect identifier 401 of the found entry.

[0121] The test search unit 121 identifies defects in the higher-level software that uses the target software as a component (step S463). Specifically, the following processes are executed.

[0122] (S463-1) The test search unit 121 refers to the table 1500 corresponding to the IT system in the SBOM management DB 134 to identify the higher-level software of the target software. The search range can be set arbitrarily. In this embodiment, the number of steps is set to 1. In this case, the software of the entry in which the identifier of the target software is set in association 1504 is identified as the higher-level software.

[0123] (S463-2) The test search unit 121 selects one higher-level software.

[0124] (S463-3) The test search unit 121 refers to the vulnerability information DB 130 to search for an entry in which the identifier of the higher-level software is set in the software 202, and obtains the vulnerability information identifier from the vulnerability identifier 201 of the said entry.

[0125] (S463-4) The test search unit 121 refers to the vulnerability / defect response database 131 and searches for an entry in which the vulnerability identifier 301 is set to the identifier of the acquired vulnerability information. The test search unit 121 obtains the defect identifier from the defect identifier 401 of the found entry.

[0126] (S463-5) The test search unit 121 determines whether processing has been completed for all higher-level software. If processing has not been completed for all higher-level software, the test search unit 121 returns to S463-2 and performs the same processing. If processing has been completed for all higher-level software, the test search unit 121 terminates the processing in step S463.

[0127] The test search unit 121 identifies tests corresponding to the defects identified in steps S462 and S463 (step S464).

[0128] Specifically, the test search unit 121 refers to the defect / test response relationship DB 132 and searches for an entry in which the defect identifier obtained in step S462 or step S463 is set in the defect identifier 401.

[0129] The test search unit 121 generates a combination of vulnerability information, defects, and tests based on the processing results of steps S462, S463, and S464 (step S465).

[0130] The test search unit 121 generates recommended test information 1000 based on the generated combinations (step S466), and then terminates the test search process. The process in step S466 is the same as in step S405, except that the recommendation level 1002 for each entry is left blank.

[0131] Note that either the process in step S462 or the process in step S463 may be executed.

[0132] When a vulnerability in the target software is fixed, there is a possibility that defects that occurred in the target software in the past may reappear. Therefore, the test proposal device 100 in Example 3 presents a test that detects defects that occurred as a result of fixing vulnerabilities in the target software in the past, if no vulnerability information similar to the target vulnerability information exists.

[0133] Fixing a vulnerability in the target software may affect higher-level software. Therefore, the test proposal device 100 in Example 3 presents a test that detects defects that occurred as a result of fixing vulnerabilities in higher-level software in the past, if no vulnerability information similar to the target vulnerability information exists.

[0134] According to Example 3, even if no vulnerability information similar to the target vulnerability information exists, recommended tests can be presented.

[0135] It should be noted that the present invention is not limited to the embodiments described above, and various modifications are included. Furthermore, for example, the embodiments described above are detailed explanations of the configuration in order to clearly illustrate the present invention, and are not necessarily limited to those having all the configurations described. In addition, some of the configurations in each embodiment can be added to, deleted from, or replaced with other configurations.

[0136] Furthermore, each of the above-mentioned configurations, functions, processing units, processing means, etc., may be implemented in hardware, in whole or in part, for example, by designing them as integrated circuits. The present invention can also be implemented by software program code that realizes the functions of the embodiment. In this case, a storage medium on which the program code is recorded is provided to a computer, and the processor of that computer reads the program code stored in the storage medium. In this case, the program code read from the storage medium itself realizes the functions of the embodiment described above, and the program code itself and the storage medium on which it is stored constitute the present invention. Examples of storage media used to supply such program code include flexible disks, CD-ROMs, DVD-ROMs, hard disks, SSDs (Solid State Drives), optical disks, magneto-optical disks, CD-Rs, magnetic tapes, non-volatile memory cards, ROMs, and the like.

[0137] Furthermore, the program code that implements the functions described in this embodiment can be implemented in a wide range of programming or scripting languages, such as assembler, C / C++, Perl, Shell, PHP, Python, and Java (registered trademark).

[0138] Furthermore, the program code for the software that implements the functions of the embodiment may be distributed via a network and stored in a storage means such as a computer's hard disk or memory, or in a storage medium such as a CD-RW or CD-R, and the computer's processor may read and execute the program code stored in the storage means or storage medium.

[0139] In the above-described embodiment, the control lines and information lines shown are those deemed necessary for explanation and do not necessarily represent all control lines and information lines in the actual product. All components may be interconnected. [Explanation of Symbols]

[0140] 100 Test Proposal Devices 101 Client terminals 102 Vulnerability information providing device 105 Network 110 Arithmetic equipment 111 Storage device 112 Communication equipment 114 Bus 120 Similarity calculation unit 121 Test Search Section 122 Input / output section 130 Vulnerability information DB 131 Vulnerability / Bug Response Related Database 132 Bug / Test Response Related Database 133 Test DB 134 SBOM management DB 201 Vulnerability Identifier 1000 Recommended Test Information 1100 screens

Claims

1. A computer system comprising a processor, a storage device connected to the processor, and a communication device connected to the processor, The system maintains a database that manages in association the vulnerability information of the software constituting the IT system, the defects that occurred in the IT system after the vulnerability corresponding to the software was corrected, and the tests that detected the defects. The aforementioned processor, When new vulnerability information is received, a similarity score is calculated that represents the similarity between the new vulnerability information and the vulnerability information stored in the database. Based on the similarity, identify the vulnerability information stored in the database that is similar to the new vulnerability information. Identify the combination of the test and the defect that corresponds to the vulnerability information stored in the identified database, Generate recommended test information to display the identified combination of the test and the defect, A computer system characterized by outputting the aforementioned recommended test information.

2. A computer system according to claim 1, The aforementioned vulnerability information includes the vulnerable software and the details of the vulnerability. The aforementioned processor, The aforementioned new vulnerability information is converted into text, and a first vector, which is an embedded representation of the text, is calculated. The vulnerability information stored in the database is converted into text, and a second vector, which is an embedded representation of the text, is calculated. A computer system characterized by calculating cosine similarity using the first vector and the second vector as the similarity.

3. A computer system according to claim 1, In the aforementioned database, the vulnerability information, the defects, the tests, and the magnitude of the impact of the defects on the IT system are managed in a corresponding manner. The frequency of execution of the test associated with the vulnerability information stored in the identified database is calculated. Using the similarity, the frequency of the test execution, and the magnitude of the impact of the defect on the IT system associated with the vulnerability information stored in the identified database, a recommendation level is calculated for each vulnerability information stored in the database. A computer system characterized by identifying vulnerability information stored in the database that is similar to the new vulnerability information, based on the recommendation level.

4. A computer system according to claim 1, It maintains configuration information for managing the relationships between the software that constitutes the IT system, The aforementioned processor, Determine whether or not the vulnerability information with a similarity greater than the threshold is stored in the database. If the vulnerability information with a similarity greater than the threshold is not stored in the database, the configuration information is referenced to identify related software that is associated with the software targeted by the new vulnerability information. By referring to the aforementioned database, identify the vulnerability information related to the aforementioned related software, A computer system characterized by identifying combinations of tests and defects associated with identified vulnerability information.

5. A proposed test method to be performed by a computer system, The aforementioned computer system, The system comprises a processor, a storage device connected to the processor, and a communication device connected to the processor. The system maintains a database that manages in association the vulnerability information of the software constituting the IT system, the defects that occurred in the IT system after the vulnerability corresponding to the software was corrected, and the tests that detected the defects. The aforementioned test proposal method is, When the processor receives new vulnerability information, it performs the step of calculating a similarity score that represents the similarity between the new vulnerability information and the vulnerability information stored in the database. The processor identifies vulnerability information stored in the database that is similar to the new vulnerability information based on the similarity, The processor includes the step of identifying a combination of the test and the defect that corresponds to the vulnerability information stored in the identified database, The processor generates recommended test information for displaying the identified combination of the test and the defect, A test suggestion method characterized by comprising the step of the processor outputting the recommended test information.

Images