Vulnerability analysis device and vulnerability analysis method

Abstract

To provide a technique that can efficiently implement analysis of vulnerability.SOLUTION: A vulnerability analysis device according to the present invention comprises: a first determination unit that determines whether a product is using one vulnerable software or more; an identification unit that identifies, as usage source code, source code that is being used by the product from among source code included in the vulnerable software; and a comparison unit that compares the usage source code and the vulnerable source code. The vulnerability analysis device determines, on the basis of the result of comparing the usage source code and the vulnerable source code, the vulnerability of the product caused by use of the vulnerable software.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present disclosure relates to a vulnerability analysis device and a vulnerability analysis method. [Background technology]

[0002] With the recent advancement of the Internet of Things (IoT), various products are now connected to networks such as the Internet, and as a result, the risk of cyber attacks is increasing. In order to ensure the safety of products from such attacks, when a vulnerability is discovered in software such as OSS (Open Source Software) used in the product, it is necessary to analyze whether the vulnerability affects the product. It is desirable to perform this analysis as efficiently as possible, and to determine as quickly as possible whether a countermeasure against the vulnerability is necessary in the product.

[0003] Against this background, for example, a technique described in Patent Document 1 has been proposed. In this technique, a route that can directly reach a computer equipped with software affected by a vulnerability from an external network is searched for. Then, it is determined whether or not the software affected by the vulnerability is protected by a firewall or an IPS (Intrusion Prevention System) on the route that can directly reach the computer. Then, based on the result of this determination, it is determined whether or not the software affected by the vulnerability can be directly attacked from the external network. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP 2012-208863 A Summary of the Invention [Problem to be solved by the invention]

[0005] Even in software where vulnerabilities have been disclosed, the vulnerabilities often exist in a portion of the source code of the software. On the other hand, in conventional technology, if a product uses software that has vulnerabilities, the product is determined to have vulnerabilities, regardless of whether the product uses the source code in which the vulnerabilities exist. This makes it difficult to efficiently analyze vulnerabilities, which leads to unnecessary consideration of countermeasures and rework.

[0006] Therefore, the present disclosure has been made in consideration of the above-mentioned problems, and has an object to provide a technique that enables efficient vulnerability analysis. [Means for solving the problem]

[0007] The vulnerability analysis device of the present disclosure includes a first determination unit that determines whether a product uses one or more vulnerable software, an identification unit that identifies source code used by the product from among source code contained in the vulnerable software determined to be used by the product as utilized source code, and a matching unit that matches the utilized source code with vulnerable source code, and determines the vulnerability of the product caused by the use of the vulnerable software based on the result of matching the utilized source code with the vulnerable source code. Effect of the Invention

[0008] According to the present disclosure, the vulnerability of a product caused by the use of vulnerable software is determined based on the result of matching between the source code used by the product among the source codes included in the vulnerable software and the vulnerable source code. With this configuration, vulnerability analysis can be performed efficiently.

[0009] The objects, features, aspects and advantages of the present disclosure will become more apparent from the following detailed description and the accompanying drawings. [Brief description of the drawings]

[0010] [Figure 1] 1 is a block diagram showing a configuration of a vulnerability analysis device according to a first embodiment. [Diagram 2] 4 is a flowchart showing a process of the vulnerability analysis device according to the first embodiment. [Diagram 3] FIG. 4 is a diagram showing an example of software vulnerability information according to the first embodiment; [Figure 4] FIG. 2 is a diagram illustrating a schematic diagram of a process performed by the vulnerability analysis device according to the first embodiment; [Diagram 5] FIG. 11 is a block diagram showing a configuration of a vulnerability analysis device according to a second embodiment. [Figure 6] 11 is a flowchart showing a process of the vulnerability analysis device according to the second embodiment. [Figure 7] FIG. 11 is a diagram illustrating a schematic diagram of a process performed by a vulnerability analysis device according to a second embodiment. [Figure 8] FIG. 13 is a diagram showing an example in which a function of vulnerable source code has a function call relationship from an external IF function. [Figure 9] FIG. 11 is a block diagram showing a configuration of a vulnerability analysis device according to a third embodiment. [Figure 10] 13 is a flowchart showing a process of the vulnerability analysis device according to the third embodiment. [Figure 11] FIG. 13 is a block diagram showing a configuration of a vulnerability analysis device according to a fourth embodiment. [Figure 12] 13 is a flowchart showing a process of the vulnerability analysis device according to the fourth embodiment. [Figure 13] FIG. 13 is a block diagram showing a configuration of a vulnerability analysis device according to a fifth embodiment. [Figure 14] 13 is a flowchart showing a process of the vulnerability analysis device according to the fifth embodiment. [Figure 15] FIG. 13 is a diagram for explaining the processing of the vulnerability analysis device according to the fifth embodiment. [Figure 16] FIG. 13 is a diagram for explaining the processing of the vulnerability analysis device according to the fifth embodiment. [Figure 17] FIG. 13 is a block diagram showing a hardware configuration of a vulnerability analysis device according to another modified example. [Figure 18] FIG. 13 is a block diagram showing a hardware configuration of a vulnerability analysis device according to another modified example. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] <Embodiment 1> FIG. 1 is a block diagram showing a configuration of a vulnerability analysis device according to the first embodiment.

[0012] The vulnerability analysis device in Fig. 1 is communicatively connected to a product information storage device and a public information storage device. The product information storage device has a used software list 3, product source code 6, and used source code 7. The public information storage device has public software vulnerability information 2, public software source code information 5, and public countermeasure patch information 9. Note that in the example of Fig. 1, the product information storage device is not provided in the vulnerability analysis device, but it may be provided in the vulnerability analysis device.

[0013] The vulnerability analysis device in FIG. 1 includes a vulnerable software utilization determining unit 1 which is a first determining unit, a utilized source code identifying unit 4 which is an identifying unit, and a source code matching unit 8 which is a matching unit.

[0014] The vulnerable software usage determination unit 1 determines whether or not a product uses one or more pieces of vulnerable software. Vulnerable software is software that may be a cause of vulnerability in the product. In the following description, vulnerable software will be described as open source software whose vulnerabilities have been made public, but the present invention is not limited to this and may be, for example, undisclosed software whose vulnerabilities have been recognized by users.

[0015] In the present embodiment 1, the vulnerable software usage determination unit 1 acquires the name and version of vulnerable software from the public software vulnerability information 2, and acquires the name and version of software used by the product from the used software list 3. Then, the vulnerable software usage determination unit 1 determines whether or not the product uses vulnerable software based on the name and version of the vulnerable software and the name and version of the software used by the product.

[0016] The used source code identifying unit 4 identifies the source code used by the product from among source codes included in the vulnerable software determined to be used by the product as the used source code. In the present embodiment 1, the used source code identifying unit 4 identifies the used source code by matching the source code of the vulnerable software acquired from the public software source code information 5 with the source code of the product acquired from the product source code 6.

[0017] As a result of the above, at least a part of the source code included in the vulnerable software is identified as the source code to be used. At this stage, it is not determined whether the source code to be used is vulnerable or whether the vulnerable software is vulnerable in a part other than the source code to be used; this determination is made after the source code matching unit 8. The source code to be used identified by the source code to be used identification unit 4 is stored as the source code to be used 7 in the product information storage device.

[0018] The source code matching unit 8 matches the source code in use with vulnerable source code, which is source code that may be a cause of vulnerability in the product, determines whether the source code in use includes vulnerable source code, and generates the determination result as a matching result. In the first embodiment, the source code matching unit 8 matches the source code in use 7 of the product information storage device with the vulnerable source code on a file-by-file basis.

[0019] Here, the published countermeasure patch included in the published countermeasure patch information 9 includes source code obtained by partially correcting the source code of the vulnerable software as source code for eliminating the vulnerability of the vulnerable software. In other words, the countermeasure patch corresponds to the vulnerable source code. Therefore, in the first embodiment, the source code matching unit 8 uses the countermeasure patch included in the published countermeasure patch information 9 for the vulnerable source code.

[0020] The source code matching unit 8 judges the vulnerability of the product caused by the use of the vulnerable software based on the result of matching the utilized source code with the vulnerable source code. For example, when the result of matching indicates that the utilized source code includes a file of the vulnerable source code, the source code matching unit 8 judges that the product is affected by the vulnerability of the vulnerable software or that the product has a vulnerability. On the other hand, when the result of matching indicates that the utilized source code does not include a file of the vulnerable source code, the source code matching unit 8 judges that the product is not affected by the vulnerability of the vulnerable software or that the product has no vulnerability. In the following, this judgment is described as being performed by the source code matching unit 8, but is not limited thereto, and may be performed by, for example, a judgment unit (not shown) other than the source code matching unit 8 provided in the vulnerability analysis device.

[0021] <Operation> Fig. 2 is a flowchart showing the processing of the vulnerability analysis device according to the embodiment 1. The processing of Fig. 2 is performed when the processing of the vulnerability analysis device starts.

[0022] In step S1, the vulnerable software usage determination unit 1 acquires the name and version of vulnerable software whose vulnerability has been disclosed from the software vulnerability information stored in the public software vulnerability information 2. Fig. 3 is a diagram showing an example of software vulnerability information stored in the public software vulnerability information 2. The software vulnerability information includes, for example, an ID, a title indicating the content of the vulnerability, an update date, the name of the software containing the vulnerability, its version, and a severity evaluation value.

[0023] For example, the vulnerable software usage determination unit 1 periodically checks the information stored in the public software vulnerability information 2. Then, from the information stored in the public software vulnerability information 2, the vulnerable software usage determination unit 1 acquires the name and the version including the vulnerability for vulnerable software whose update date (i.e., publication date) is after the last check date.

[0024] In step S2, the vulnerable software usage determination unit 1 obtains the name and version information of the software (hereinafter sometimes referred to as "used software") used by the product to be analyzed by the vulnerability analysis device from the product information stored in the used software list 3.

[0025] In step S3, the vulnerable software usage determination unit 1 determines whether the name of the software in use matches the name of the vulnerable software and the version of the software in use is included in the version of the vulnerable software. If the name of the software in use matches the name of the vulnerable software and the version of the software in use is included in the version of the vulnerable software, it is determined that the vulnerable software is used in the product to be analyzed, and the process proceeds to step S4. If not, it is determined that the vulnerable software is not used in the product to be analyzed, and the process proceeds to step S9.

[0026] In step S4, the used source code identifying unit 4 obtains the source code of the vulnerable software determined to be used in the product from the public software source code information 5, and obtains the source code of the product to be analyzed from the product source code 6. The used source code identifying unit 4 then compares the source code of the vulnerable software with the source code of the product to be analyzed, thereby identifying, as the used source code, the source code used by the product to be analyzed, among the source codes included in the vulnerable software. The used source code identifying unit 4 then stores the identified used source code as used source code 7 in the product information storage device.

[0027] In step S5, the source code matching unit 8 acquires a countermeasure patch for the vulnerable software from the published countermeasure patch information 9.

[0028] In step S6, the source code matching unit 8 acquires the source code of the product to be analyzed from the source code of the product information storage device 7.

[0029] In step S7, the source code matching unit 8 uses the countermeasure patch acquired in step S5 as vulnerable source code, and matches the vulnerable source code with the source code used acquired in step S6 on a file-by-file basis. Then, the source code matching unit 8 judges whether the source code used includes a vulnerable source code file. If it is judged that the source code used includes a vulnerable source code file, it is judged that the product to be analyzed uses vulnerable source code, and the process proceeds to step S8. If it is not judged that the source code used includes a vulnerable source code file, it is judged that the product to be analyzed does not use vulnerable source code, and the process proceeds to step S9.

[0030] In step S8, the source code matching unit 8 determines whether the product is affected by the vulnerability of the vulnerable software, or whether a vulnerability exists in the product. Then, the process of FIG. 2 ends.

[0031] In step S9, the source code matching unit 8 determines that the product is not affected by the vulnerability of the vulnerable software, or that the product does not have a vulnerability. Then, the process of FIG. 2 ends.

[0032] Fig. 4 is a diagram showing a schematic diagram of the process of the vulnerability analysis device. In the case of Fig. 4, the vulnerable software utilization determination unit 1 determines that the product 21 utilizes vulnerable software 22. In addition, the utilized source code identification unit 4 identifies a part of source code included in the vulnerable software 22 as utilized source code 23.

[0033] 4, modified files 24a, 24b named "Hoge1.c" and "Hoge2.c" of vulnerable software A, which is countermeasure patch 24, have been made public. In the case of FIG. 4, source code 23 used by product 21 includes at least one of files 23a, 23b named "Hoge1.c" and "Hoge2.c" that are the same as those of vulnerable software A. For this reason, source code matching unit 8 determines that source code 23 used by product 21 includes vulnerable source code, and determines that product 21 is affected by the vulnerability of vulnerable software 22.

[0034] <Summary of the first embodiment> According to the vulnerability analysis device of the first embodiment described above, the vulnerability of the product caused by the use of the vulnerable software is determined based on the result of matching the exploitation source code used by the product among the source codes included in the vulnerable software with the vulnerable source code. With such a configuration, even if the product uses vulnerable software, if the exploitation source code does not contain the vulnerable source code, it is not determined that the product is affected by the vulnerability of the vulnerable software, so that the vulnerability analysis can be performed efficiently.

[0035] Furthermore, according to the first embodiment, it is determined whether or not a product uses vulnerable software based on the name and version of the vulnerable software and the name and version of software used by the product. With such a configuration, it is possible to efficiently determine whether or not a product uses vulnerable software. However, this determination is not limited to this, as long as there is no need to perform it efficiently. For example, it may be determined whether or not a product uses vulnerable software by comparing the source code of the vulnerable software with the source code of the product to be analyzed.

[0036] Furthermore, according to the first embodiment, the utilized source code is compared with the vulnerable source code on a file-by-file basis, so that it is possible to improve the accuracy of determining the vulnerability of a product caused by the utilization of vulnerable software.

[0037] Furthermore, according to the first embodiment, since a countermeasure patch is applied to vulnerable source code, vulnerability analysis can be performed efficiently.

[0038] <Embodiment 2> 5 is a block diagram showing the configuration of a vulnerability analysis device according to the present embodiment 2. In the following, among the components according to the present embodiment 2, components that are the same as or similar to the components described above are given the same or similar reference numerals, and different components will be mainly described.

[0039] The configuration in FIG. 5 is similar to that in FIG. 1, except that a structure analysis unit 10, which is an analysis unit, and a priority order determination unit 11, which is a second determination unit, are added to the configuration in FIG.

[0040] In the second embodiment, the source code matching unit 8 matches the utilization source code 7 of the product information storage device with the vulnerable source code not on a file-by-file basis but on a function-by-function basis.

[0041] The structure analysis unit 10 analyzes a static function call structure from an external interface (external IF). The source code matching unit 8 judges the vulnerability of the product caused by the use of one or more pieces of vulnerable software, based on the result of matching the utilized source code with the vulnerable source code and the result of the analysis of the function call structure by the structure analysis unit 10. In the following, this judgment will be described as being performed by the source code matching unit 8, but is not limited to this, and may be performed, for example, by a judgment unit (not shown) other than the source code matching unit 8 that is provided in the vulnerability analysis device.

[0042] When it is determined that there is a vulnerability in a product caused by the use of multiple pieces of vulnerable software, the priority order determination unit 11 determines the priority order of implementing measures against the vulnerabilities in the multiple pieces of vulnerable software in the product. In the second embodiment, the priority order determination unit 11 determines the priority order based on the severity evaluation value (see FIG. 3) of the published vulnerable software among the software vulnerability information stored in the published software vulnerability information 2.

[0043] <Operation> Fig. 6 is a flowchart showing the processing of the vulnerability analysis device according to the embodiment 2. The processing of Fig. 6 is performed when the processing of the vulnerability analysis device starts.

[0044] In steps S1 to S7 in FIG. 6, the same processes as in steps S1 to S7 in FIG. 2 are performed, except that in step S7, source code matching unit 8 performs matching on a function basis rather than on a file basis.

[0045] Fig. 7 is a diagram showing a schematic diagram of steps S1 to S7 of the process of the vulnerability analysis device. In the case of Fig. 7, the vulnerable software utilization determination unit 1 determines that the product 21 utilizes vulnerable software 22. Furthermore, the utilized source code identification unit 4 identifies a part of source code included in the vulnerable software 22 as utilized source code 23.

[0046] In Fig. 7, modified functions Foo1() and Foo2() in "Hoge3.c" of vulnerable software B, which is countermeasure patch 24, have been made public. Note that the return values ​​of these functions are omitted. In the case of Fig. 7, source code 23 of product 21 contains at least one of functions Foo1() and Foo2(), which are the same as those of vulnerable software B. Therefore, source code matching unit 8 determines that source code 23 of product 21 contains vulnerable source code.

[0047] 6, if it is determined that the source code to be used includes a vulnerable source code file, the process proceeds to step S11. If it is not determined that the source code to be used includes a vulnerable source code file, the process proceeds to step S9.

[0048] In step S11, the structure analysis unit 10 acquires the source code of the product to be analyzed from the product source code 6, and analyzes the function call structure from the external IF. Then, the structure analysis unit 10 judges whether or not the function of the vulnerable source code has a function call relationship from an external IF function that is publicly disclosed, and generates the judgment result as the analysis result. Fig. 8 is a diagram showing an example in which the function of the vulnerable source code has a function call relationship from an external IF function.

[0049] If it is determined that the function of the vulnerable source code has a function call relationship from the external IF function, the process proceeds to step S8, and if it is not determined that the function of the vulnerable source code has a function call relationship from the external IF function, the process proceeds to step S9. In steps S8 and S9 in Fig. 6, the same processes as steps S8 and S9 in Fig. 2 are performed. After step S8, the process proceeds to step S16, and after step S9, the process in Fig. 6 ends.

[0050] In step S16 , the priority order determination unit 11 acquires the severity evaluation value of the vulnerable software from the software vulnerability information stored in the public software vulnerability information 2 .

[0051] In step S17, the priority determination unit 11 determines the priority of countermeasure implementation for vulnerabilities of multiple vulnerable software in the product based on the severity evaluation value. For example, the priority determination unit 11 determines the priority such that the higher the severity evaluation value of the vulnerable software, the higher the priority of countermeasure implementation for the vulnerable software. Then, the process of FIG. 6 ends.

[0052] <Summary of the second embodiment> According to the vulnerability analysis device of the second embodiment as described above, the utilized source code is compared with the vulnerable source code on a function-by-function basis, thereby improving the accuracy of determining product vulnerabilities caused by the use of vulnerable software.

[0053] Furthermore, according to the second embodiment, the vulnerability of the product is determined based on the result of matching the utilized source code with the vulnerable source code and the result of analyzing the function call structure, so that the vulnerability analysis can be performed efficiently.

[0054] Furthermore, according to the second embodiment, when it is determined that there is a vulnerability in a product caused by the use of multiple pieces of vulnerable software, the priority of implementing measures against the vulnerabilities in the multiple pieces of vulnerable software in the product is determined based on the severity evaluation value of the vulnerable software. With this configuration, it is possible to efficiently implement measures against the vulnerabilities in the multiple pieces of vulnerable software in the product.

[0055] <Embodiment 3> Fig. 9 is a block diagram showing the configuration of a vulnerability analysis device according to the third embodiment. In the following, among the components according to the third embodiment, the components that are the same as or similar to the components described above are given the same or similar reference numerals, and different components are mainly described. In Fig. 9, in order to avoid complicating the figure, the components described in the first and second embodiments are omitted as appropriate.

[0056] The vulnerability analysis device in Fig. 9 further includes a countermeasure impact confirmation unit 12, which is a confirmation unit. After it is determined that there is a vulnerability in the product caused by the use of vulnerable software, and after a countermeasure against the vulnerability of the vulnerable software is implemented in the product, the countermeasure impact confirmation unit 12 confirms whether or not a predetermined function of the product is impaired. The predetermined function is, for example, a function of the product that existed before the countermeasure against the vulnerability of the vulnerable software was implemented.

[0057] In the third embodiment, when it is determined that there is a vulnerability in the product caused by the use of vulnerable software, the countermeasure impact confirmation unit 12 automatically acquires a countermeasure patch for the vulnerability of the vulnerable software, applies the countermeasure patch to the vulnerable software in the product, and executes a regression test of the product to which the countermeasure patch has been applied. The regression test is a test that executes a functional test and a non-functional test to confirm whether the changed software has the same functions as the software before the change.

[0058] <Operation> Fig. 10 is a flowchart showing the process of the countermeasure effect confirmation unit 12 according to the embodiment 3. The process of Fig. 10 is performed when the process of the vulnerability analysis device starts.

[0059] In step S21, the countermeasure impact confirmation unit 12 confirms whether or not the source code matching unit 8 has determined that there is a vulnerability in the product caused by the use of vulnerable software. If it is confirmed that there is a vulnerability in the product caused by the use of vulnerable software, the processes of steps S22 to S24 are automatically performed. If it is not confirmed that there is a vulnerability in the product caused by the use of vulnerable software, the process of FIG. 10 ends.

[0060] In step S22, the countermeasure impact confirmation unit 12 acquires countermeasure patches for vulnerabilities in vulnerable software, which are included in the published countermeasure patch information 9.

[0061] In step S23, the countermeasure impact confirmation unit 12 applies the countermeasure patch acquired from the published countermeasure patch information 9 to the vulnerable source code stored in the product source code 6 and included in the source code of the product that has been determined to have a vulnerability.

[0062] In step S24, the countermeasure impact confirmation unit 12 executes a regression test on the product determined to have a vulnerability, triggered by the application of the countermeasure patch, and confirms that the product has not been degraded due to the countermeasure against the vulnerability. After that, the process of FIG. 10 ends.

[0063] <Summary of the Third Embodiment> According to the vulnerability analysis device of the third embodiment as described above, after it is determined that a vulnerability of a product exists due to the use of vulnerable software, and after a countermeasure against the vulnerability of the vulnerable software is implemented in the product, it is confirmed whether or not a predetermined function of the product is impaired. For example, when it is determined that a vulnerability of a product exists due to the use of vulnerable software, the device automatically acquires a countermeasure patch against the vulnerability of the vulnerable software, applies the countermeasure patch to the vulnerable software in the product, and executes a regression test of the product to which the countermeasure patch has been applied. According to such a configuration, it is possible to efficiently implement a countermeasure against the vulnerability of the vulnerable software in the product.

[0064] <Fourth embodiment> 11 is a block diagram showing the configuration of a vulnerability analysis device according to the present embodiment 4. In the following, among the components according to the present embodiment 4, components that are the same as or similar to the components described above are given the same or similar reference numerals, and different components will be mainly described.

[0065] 11, the product information storage device has a used software list 3 and used software (library) 14. The public information storage device has public software vulnerability information 2. Note that in the example of Fig. 11, the product information storage device is not provided in the vulnerability analysis device, but may be provided in the vulnerability analysis device.

[0066] The vulnerability analysis device in FIG. 11 includes a vulnerable software (library) usage determination unit 13 which is a first determination unit, a structure analysis unit 10 which is an analysis unit, and a priority order determination unit 11 which is a second determination unit.

[0067] The vulnerable software (library) usage determination unit 13 determines whether or not the product uses one or more libraries of vulnerable software. Except for the fact that the product is judged to be vulnerable software in libraries, the vulnerable software (library) usage determination unit 13 is substantially the same as the vulnerable software usage determination unit 1 described in the first embodiment. Accordingly, the source code in the fourth embodiment is binaryized and organized into a library. And the "vulnerable software (library)" is vulnerable software in libraries, which is an open source software library whose vulnerabilities have been made public.

[0068] The structure analysis unit 10 in FIG. 11 analyzes a static function call structure from an external interface (external IF) in the same manner as in the second embodiment.

[0069] The priority determination unit 11 determines the vulnerability of the product caused by the use of vulnerable software (libraries) based on the determination result of the use of vulnerable software (libraries) and the analysis result of the function call structure. In the following, this determination will be described as being performed by the priority determination unit 11, but is not limited to this, and may be performed by, for example, a determination unit (not shown) other than the priority determination unit 11 provided in the vulnerability analysis device. Similarly to the second embodiment, the priority determination unit 11 in Fig. 11 determines the priority of implementation of measures against the vulnerabilities of the multiple vulnerable software (libraries) in the product when it is determined that there is a vulnerability in the product caused by the use of multiple vulnerable software (libraries).

[0070] <Operation> Fig. 12 is a flowchart showing the processing of the vulnerability analysis device according to the embodiment 4. The processing of Fig. 12 is performed when the processing of the vulnerability analysis device starts.

[0071] In step S31, the vulnerable software (library) usage determination unit 13 acquires the name and version of the vulnerable software (library) in which the vulnerability has been disclosed from the software vulnerability information stored in the public software vulnerability information 2. The software vulnerability information stored in the public software vulnerability information 2 is similar to that in Fig. 3, and includes, for example, an ID, a title indicating the content of the vulnerability, an update date, the name of the software containing the vulnerability, its version, and a severity evaluation value.

[0072] For example, the vulnerable software (library) usage determination unit 13 periodically checks the information stored in the public software vulnerability information 2. Then, the vulnerable software (library) usage determination unit 13 acquires the name and the version including the vulnerability for vulnerable software (library) whose update date (i.e., publication date) is after the last check date from the information stored in the public software vulnerability information 2.

[0073] In step S32, the vulnerable software (library) usage determination unit 13 obtains the name and version information of the library software (hereinafter sometimes referred to as the software (library) used) used by the product being analyzed by the vulnerability analysis device from the product information stored in the software used list 3.

[0074] In step S33, the vulnerable software (library) usage determination unit 13 determines whether or not the name of the used software (library) matches the name of the vulnerable software (library) and the version of the used software (library) is included in the version of the vulnerable software (library). If the name of the used software (library) matches the name of the vulnerable software (library) and the version of the used software (library) is included in the version of the vulnerable software (library), it is determined that the vulnerable software (library) is used in the product to be analyzed, and the process proceeds to step S34. If not, it is determined that the vulnerable software (library) is not used in the product to be analyzed, and the process proceeds to step S38.

[0075] In step S34, the structure analysis unit 10 acquires the software (library) of the product to be analyzed from the used software (library) 14, and analyzes the function call structure from the external IF. Then, the structure analysis unit 10 determines whether or not a function of the used software (library) has a function call relationship from an external IF function that is publicly available, and generates the determination result as the analysis result.

[0076] If it is determined that the function of the software being used (library) has a function call relationship from the external IF function, processing proceeds to step S35; if it is not determined that the function of the software being used (library) has a function call relationship from the external IF function, processing proceeds to step S38.

[0077] In step S35, the priority determination unit 11 determines that the product is affected by the vulnerability of the vulnerable software (library) or that a vulnerability exists in the product.

[0078] In step S36, the priority order determination unit 11 acquires the severity evaluation value of the vulnerable software (library) from the software vulnerability information stored in the public software vulnerability information 2 (see FIG. 3).

[0079] In step S37, the priority determination unit 11 determines the priority of countermeasure implementation for vulnerabilities of multiple vulnerable software (libraries) in the product based on the severity evaluation value. For example, the priority determination unit 11 determines the priority such that the higher the severity evaluation value of the vulnerable software (library), the higher the priority of the countermeasure implementation for the vulnerable software. Then, the process of FIG. 12 ends.

[0080] In step S38, the priority order determination unit 11 determines that the product is not affected by the vulnerability of the vulnerable software (library), or determines that the product does not have a vulnerability, after which the process of FIG. 12 ends.

[0081] <Summary of the fourth embodiment> According to the vulnerability analysis device of the fourth embodiment described above, the vulnerability of a product caused by the use of vulnerable software (libraries) is judged based on the judgment result of the use of vulnerable software (libraries) and the analysis result of the function call structure. With such a configuration, it is possible to efficiently analyze the vulnerability of software in a library.

[0082] <Embodiment 5> 13 is a block diagram showing the configuration of a vulnerability analysis device according to the present embodiment 5. In the following, among the components according to the present embodiment 5, components that are the same as or similar to the components described above are given the same or similar reference numerals, and different components will be mainly described.

[0083] FIG. 13 is similar to FIG. 5 except that a countermeasure patch is illustrated as an example of source code of the public countermeasure patch information 9 and the priority order determination unit 11 does not use the public software vulnerability information 2.

[0084] In the fifth embodiment, the structure analysis unit 10 analyzes the function call structure from the function of the vulnerable source code (hereinafter, sometimes referred to as the "vulnerable function") to the function of the external IF. This will be described in detail in the description of step S11 to be described later.

[0085] In the fifth embodiment, the priority order determination unit 11 determines the priority order of countermeasure implementation based on whether or not a vulnerable function is called from an external IF using all possible parameter combinations, the number of external IFs that are callers, and the presence or absence of an external IF with a predetermined risk level. This will be described in detail in the description of step S41 below. Note that the priority order determination unit 11 may determine the priority order of countermeasure implementation based on at least one of whether or not a vulnerable function is called from an external IF using all possible parameter combinations, the number of external IFs that are callers, and the presence or absence of an external IF with a predetermined risk level.

[0086] <Operation> Fig. 14 is a flowchart showing the processing of the vulnerability analysis device according to the fifth embodiment. The flowchart in Fig. 14 is similar to the flowchart in Fig. 6 except that step S11 in the flowchart in Fig. 6 is partially changed and step S16 and step S17 are changed to step S41. Therefore, the processing of steps S11 and S41 will be described below.

[0087] <Step S11> In step S11, the structure analysis unit 10 acquires the source code of the product to be analyzed from the product source code 6, and analyzes the function call structure from the external IF. Then, the structure analysis unit 10 determines whether or not the vulnerable function has a function call relationship from an external IF function that is published to the outside, and generates the determination result as the analysis result.

[0088] FIG. 15 is a diagram showing the function call relationship of the source code, and each circle represents a function. In terms of the structure of the source code, analyzing the function call structure from the vulnerable function, which is the callee function, to the external IF function, which is the caller function, as shown in FIG. 15, tends to result in fewer branches to follow than analyzing the function call structure from the caller function to the callee function. Therefore, in this fifth embodiment, the structure analysis unit 10 analyzes the function call structure from the vulnerable function to the external IF function. Then, when the structure analysis unit 10 reaches the external IF function from the vulnerable function, it determines that the vulnerable function has a function call relationship from the external IF function.

[0089] <Step S41> In step S41, the priority determination unit 11 determines the priority of implementing countermeasures against vulnerabilities based on whether a vulnerable function is called from an external interface using all possible combinations of parameters, the number of external interfaces that are the call source, and whether or not there is an external interface that has a predetermined level of risk.

[0090] 16 is a diagram for explaining the determination of priority in the priority determination unit 11. The priority determination unit 11 acquires all external IFs that are determined by the structural analysis unit 10 to have a function call relationship up to a vulnerable function in the structure of the source code. Then, the priority determination unit 11 performs a process of actually calling functions from all external IFs using all possible parameter combinations, and determines whether calls reach the vulnerable function from all external IFs. Then, for vulnerable software in which a function is not actually called from an external IF even if there is a structural call relationship, the priority determination unit 11 determines "no need to implement countermeasures" as the priority of countermeasure implementation.

[0091] Next, the priority determination unit 11 determines whether the external IFs whose calls reach the vulnerable function include an external IF having a predetermined risk level. An external IF having a predetermined risk level is, for example, an external IF whose function is exposed to the Internet and can be changed and whose risk level is "high". An external IF whose function is not exposed to the Internet and whose risk level is not "high" and whose function can be changed only by a command line with administrator authority. The priority determination unit 11 sets the priority level of countermeasure implementation for vulnerable software whose calls reach the vulnerable function from an external IF whose risk level is "high" higher than the priority level of countermeasure implementation for vulnerable software whose calls reach the vulnerable function from an external IF whose risk level is not "high".

[0092] For vulnerable software in which a call reaches a vulnerable function from an external IF with a "high" risk, the priority order determination unit 11 assigns a higher priority to the countermeasure implementation as the number of external IFs that are call sources increases. Similarly, for vulnerable software in which a call reaches a vulnerable function from an external IF with a non-"high" risk, the priority order determination unit 11 assigns a higher priority to the countermeasure implementation as the number of external IFs that are call sources increases. After step S41, the process of FIG. 16 ends.

[0093] <Summary of the fifth embodiment> According to the vulnerability analysis device of the fifth embodiment described above, the priority of countermeasure implementation is determined based on whether a vulnerable function is called from an external IF using all possible parameter combinations, the number of external IFs that are call sources, and the presence or absence of an external IF with a predetermined risk. With this configuration, countermeasures against vulnerabilities in multiple vulnerable software in a product can be efficiently implemented.

[0094] Furthermore, according to the fifth embodiment, the function call structure is analyzed from the vulnerable function toward the external IF function. With such a configuration, the number of branches to be followed can be reduced, and therefore the processing time can be shortened.

[0095] <Sixth embodiment> A block diagram showing the configuration of a vulnerability analysis device according to the sixth embodiment is the same as that in Fig. 13, and a flowchart showing the operation of the vulnerability analysis device according to the sixth embodiment is the same as that in Fig. 14. The sixth embodiment is different from the fifth embodiment in terms of the processing of step S11 in Fig. 14. Hereinafter, among the components according to the fifth embodiment, components that are the same as or similar to the components described above are given the same or similar reference symbols, and different components will be mainly described.

[0096] When the source code becomes large-scale and complicated, the number of branches to be traced in the analysis in step S11 becomes enormous, and the processing time becomes long. Therefore, the vulnerability analysis device according to the sixth embodiment stores all the function call structures in the source code in advance as a database. With such a configuration, the structure analysis unit 10 can obtain the function call structures from the data in the database without analyzing the product source code 6, and therefore the processing time can be shortened.

[0097] <Other Modifications> The vulnerable software utilization determination unit 1, the utilized source code specification unit 4, and the source code matching unit 8 in FIG. 1 described above are hereinafter referred to as the "vulnerable software utilization determination unit 1, etc." The vulnerable software utilization determination unit 1, etc. are realized by a processing circuit 81 shown in FIG. 17. That is, the processing circuit 81 includes the vulnerable software utilization determination unit 1 that determines whether or not a product utilizes one or more pieces of vulnerable software, the utilized source code specification unit 4 that specifies, as utilized source code, source code utilized by the product among source codes included in the vulnerable software determined to be utilized by the product, and the source code matching unit 8 that matches the utilized source code with the vulnerable source code and determines the vulnerability of the product caused by the utilization of the vulnerable software based on the result of matching the utilized source code with the vulnerable source code. The processing circuit 81 may be implemented with dedicated hardware, or may be implemented with a processor that executes a program stored in a memory. The processor may be, for example, a central processing unit, a processing unit, an arithmetic unit, a microprocessor, a microcomputer, a DSP (Digital Signal Processor), or the like.

[0098] When the processing circuit 81 is a dedicated hardware, the processing circuit 81 corresponds to, for example, a single circuit, a composite circuit, a programmed processor, a parallel programmed processor, an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or a combination of these. Each function of the vulnerable software usage determination unit 1 and the like may be realized by a circuit in which the processing circuits are distributed, or the functions of each unit may be realized by a single processing circuit.

[0099] When the processing circuit 81 is a processor, the functions of the vulnerable software utilization determination unit 1 and the like are realized by a combination with software and the like. The software and the like corresponds to, for example, software, firmware, or software and firmware. The software and the like are written as a program and stored in a memory. As shown in FIG. 18, the processor 82 applied to the processing circuit 81 realizes the functions of each unit by reading and executing a program stored in the memory 83. That is, the vulnerability analysis device includes a memory 83 for storing a program that, when executed by the processing circuit 81, results in the execution of the steps of: determining whether or not the product uses one or more pieces of vulnerable software; identifying the source code used by the product as the utilized source code among the source codes included in the vulnerable software determined to be used by the product; and matching the utilized source code with the vulnerable source code and determining the vulnerability of the product caused by the utilization of the vulnerable software based on the result of matching the utilized source code with the vulnerable source code. In other words, this program can be said to cause a computer to execute the procedure or method of the vulnerable software utilization determination unit 1 and the like. Here, the memory 83 may be, for example, a non-volatile or volatile semiconductor memory such as a Random Access Memory (RAM), a Read Only Memory (ROM), a flash memory, an Erasable Programmable Read Only Memory (EPROM), an Electrically Erasable Programmable Read Only Memory (EEPROM), an HDD (Hard Disk Drive), a magnetic disk, a flexible disk, an optical disk, a compact disk, a mini disk, a DVD (Digital Versatile Disc), a drive device for any of these, or any storage medium to be used in the future.

[0100] The above describes a configuration in which each function of the vulnerable software utilization determination unit 1, etc. is realized either in hardware or software, etc. However, the present invention is not limited to this, and a configuration in which a part of the vulnerable software utilization determination unit 1, etc. is realized in dedicated hardware and another part is realized in software, etc. For example, the vulnerable software utilization determination unit 1 can be realized by a processing circuit 81 as dedicated hardware, an acquisition circuit (acquisition circuitry) such as an interface, etc., and the other functions can be realized by the processing circuit 81 as a processor 82 reading and executing a program stored in a memory 83.

[0101] As described above, the processing circuitry 81 can realize each of the above-mentioned functions by hardware, software, or a combination of these.

[0102] The vulnerability analysis device described above can also be applied to a vulnerability analysis system constructed as a system by appropriately combining a personal computer, a communication terminal including a mobile terminal such as a mobile phone, a smartphone, and a tablet, the functions of an application installed in at least one of the personal computer and the communication terminal, and a server. In this case, each function or each component of the vulnerability analysis device described above may be distributed and disposed in each device that constructs the system, or may be centrally disposed in one of the devices. The above also applies to the vulnerable software (library) utilization determination unit 13.

[0103] It should be noted that the embodiments and modifications may be freely combined, and the embodiments and modifications may be modified or omitted as appropriate.

[0104] The above description is illustrative in all respects and is not restrictive. It is understood that countless variations not illustrated can be envisioned. [Explanation of symbols]

[0105] 1 Vulnerable software usage determination unit, 4 Usage source code identification unit, 8 Source code matching unit, 10 Structure analysis unit, 11 Priority determination unit, 12 Countermeasure impact confirmation unit, 13 Vulnerable software (library) usage determination unit.

Claims

1. a first determination unit that determines whether or not the product uses one or more pieces of vulnerable software; an identification unit that identifies source code used by the product as a used source code from among source codes included in the vulnerable software determined to be used by the product; a matching unit for matching the exploited source code with the vulnerable source code; Equipped with A vulnerability analysis device that determines vulnerabilities of the product caused by the use of the vulnerable software based on a comparison result between the utilized source code and the vulnerable source code.

2. The vulnerability analysis device according to claim 1 , A vulnerability analysis device, wherein the vulnerable software is open source software whose vulnerabilities have been made public.

3. The vulnerability analysis device according to claim 1 or 2, The first determination unit is A vulnerability analysis device that determines whether or not the product uses the vulnerable software based on the name and version of the vulnerable software and the name and version of software used by the product.

4. A vulnerability analysis device according to any one of claims 1 to 3, The butt portion is A vulnerability analysis device that compares the exploited source code with the vulnerable source code on a file-by-file basis.

5. A vulnerability analysis device according to any one of claims 1 to 3, The butt portion is A vulnerability analysis device that compares the exploited source code with the vulnerable source code on a function-by-function basis.

6. The vulnerability analysis device according to claim 5, An analysis unit that analyzes a function call structure from an external interface, A vulnerability analysis device that judges the vulnerability of the product based on a result of matching the utilized source code with the vulnerable source code and a result of analyzing the function call structure.

7. The vulnerability analysis device according to claim 5 or 6, The one or more pieces of vulnerable software are a plurality of pieces of vulnerable software, A vulnerability analysis device further comprising a second determination unit that, when it is determined that a vulnerability exists in the product caused by the use of the plurality of vulnerable software, determines the priority of implementing countermeasures against the vulnerabilities of the plurality of vulnerable software in the product.

8. The vulnerability analysis device according to claim 7, The second determination unit is A vulnerability analysis device that determines the priority based on a severity evaluation value of the vulnerable software.

9. A vulnerability analysis device according to any one of claims 1 to 6, A vulnerability analysis device further comprising a confirmation unit that confirms whether a predetermined function of the product is not impaired after it is determined that a vulnerability of the product exists due to the use of the vulnerable software and after measures are implemented in the product against the vulnerability of the vulnerable software.

10. The vulnerability analysis device according to claim 9, The confirmation unit is A vulnerability analysis device that, when it is determined that a vulnerability of the product exists due to the use of the vulnerable software, automatically obtains a countermeasure patch for the vulnerability of the vulnerable software, applies the countermeasure patch to the vulnerable software in the product, and performs regression testing of the product to which the countermeasure patch has been applied.

11. A vulnerability analysis device according to any one of claims 1 to 9, The butt portion is A vulnerability analysis device that applies a countermeasure patch to the vulnerable source code.

12. a first determination unit that determines whether or not the product uses one or more libraries of vulnerable software; an analysis part that analyzes the function call structure from the external interface; Equipped with A vulnerability analysis device that determines the vulnerability of the product based on the determination result of the use of the vulnerable software library and the analysis result of the function call structure.

13. The vulnerability analysis device according to claim 12, The vulnerability analysis device, wherein the vulnerable software library is an open source software library whose vulnerabilities have been made public.

14. The vulnerability analysis device according to claim 12 or 13, the one or more libraries of vulnerable software are a plurality of libraries of vulnerable software, A vulnerability analysis device further comprising a second determination unit that, when it is determined that a vulnerability of the product exists due to the use of the plurality of vulnerable software libraries, determines a priority of implementation of countermeasures against vulnerabilities in the plurality of vulnerable software libraries in the product.

15. The vulnerability analysis device according to claim 7, The second determination unit is A vulnerability analysis device that determines the priority based on whether or not a function of the vulnerable source code is called from an external interface using all possible combinations of parameters.

16. The vulnerability analysis device according to claim 7, The second determination unit is A vulnerability analysis device that determines the priority based on the number of external interfaces that are call sources.

17. The vulnerability analysis device according to claim 7, The second determination unit is A vulnerability analysis device that determines the priority order based on the presence or absence of an external interface having a predetermined risk level.

18. The vulnerability analysis device according to claim 7, The second determination unit is A vulnerability analysis device that determines the priority based on whether a function of the vulnerable source code is called from an external interface using all possible combinations of parameters, the number of external interfaces that are the call sources, and whether or not there is an external interface that has a predetermined level of risk.

19. The vulnerability analysis device according to claim 6, The analysis unit is A vulnerability analysis device that analyzes the function call structure from a function of the vulnerable source code toward a function of the external interface.

20. determining whether the product utilizes one or more pieces of vulnerable software; Identifying, as a used source code, a source code used by the product among source codes included in the vulnerable software determined to be used by the product; Matching the exploitation source code with the vulnerable source code; A vulnerability analysis method for determining vulnerabilities of the product caused by the use of the vulnerable software based on a comparison result between the utilized source code and the vulnerable source code.

Images