Identification device, identification method, and identification program

Abstract

To easily identify a correction part of vulnerability in a patch cord.SOLUTION: The identification device acquires vulnerability information, which is explanatory information regarding the vulnerability designated by the user, and patch information regarding the vulnerability from a published vulnerability information database. Then, the identification device acquires the patch code indicated in the acquired patch information, and divides the patch code into difference blocks for each correction part by the patch code by lexical analysis of the acquired patch code. Next, the identification device inputs the divided difference blocks and the vulnerability information to LargeLanguageModels (LLM) to identify whether each of the difference blocks is a block related to correction of the designated vulnerability. Thereafter, the identification device outputs an identification result for each block of the patch cord.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present invention relates to an identification device, an identification method, and an identification program for identifying a portion of a patch code where a vulnerability has been fixed. [Background technology]

[0002] In order for software to operate securely, it is important to fix vulnerabilities that pose potential security risks and eliminate the risks. One method of fixing vulnerabilities is to refer to publicly available patch codes and fix the code in which the vulnerabilities were found. However, patch codes often include fixes such as adding new features that are unrelated to the vulnerability fix, making it difficult to identify the parts that have been fixed.

[0003] Existing patch code technologies include techniques for automatically collecting and labeling vulnerable code data and patch codes to provide vulnerable code datasets. Using such techniques, it is conceivable to identify the locations of vulnerabilities that need to be fixed within patch codes. [Prior art documents] [Non-patent literature]

[0004] [Non-Patent Document 1] R. Russell, et al. “Automated Vulnerability Detection in Source Code Using Deep Representation Learning.” IEEE International Conference on Machine Learning and Applications, 2018, pp. 757-762. [Non-patent document 2] R. Raducu, et al. “Collecting Vulnerable Source Code from Open-Source Repositories for Dataset Generation.” Applied Sciences 10.4 (2020), p. 1270. [Non-Patent Document 3] Y. Zhou, et al. “Devign: Effective Vulnerability Identification by Learning Comprehensive Program Semantics via Graph Neural Networks.” NeurIPS 2019 [Non-Patent Document 4] Y. Zheng, et al. “D2A: A Dataset Built for AI-Based Vulnerability Detection Methods Using Differential Analysis.” the 43rd International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP '21), pp. 111-120. [Non-Patent Document 5] H. Alves, et al. “Software Metrics and Security Vulnerabilities: Dataset and Exploratory Study.” 2016 12th European Dependable Computing Conference, pp. 37-44. [Non-Patent Document 6] Bhandari, Guru, Amara Naseer, and Leon Moonen. "CVEfixes: Automated Collection of Vulnerabilities and Their Fixes from Open-Source Software." Proceedings of the 17th International Conference on Predictive Models and Data Analytics in Software Engineering. 2021. Summary of the Invention [Problem to be solved by the invention]

[0005] However, the above-mentioned technique has the following limitations, making it difficult to identify the location of the vulnerability in the patch code.

[0006] The types of OSS (Open Source Software) that are covered are limited. - Static analysis-based testing is limited to target languages ​​such as C / C++. Labeling based on before and after commit code fixes may result in the inclusion of fix commit code that is not related to the vulnerability. Labeling based on vulnerability type only works for specific types of patch codes.

[0007] Therefore, an object of the present invention is to solve the above-mentioned problems and to make it easier to identify the location of the vulnerability repaired in the patch code. [Means for solving the problem]

[0008] In order to solve the above-mentioned problems, the present invention is characterized by comprising an information acquisition unit that acquires vulnerability information, which is explanatory information regarding a vulnerability specified by a user, and patch information for the vulnerability from a vulnerability information database; a code acquisition unit that acquires code related to the vulnerability using the patch information; an identification unit that inputs the code and the vulnerability information into an inference model using natural language processing, thereby causing the inference model to identify correction locations in the code related to the vulnerability; and an identification result output unit that outputs the results of the identification. [Effects of the Invention]

[0009] According to the present invention, it is possible to easily identify the location of a vulnerability repaired in a patch code. [Brief explanation of the drawings]

[0010] [Figure 1] FIG. 1 is a diagram for explaining an overview of the identification device. [Figure 2] FIG. 2 is a diagram for explaining an outline of the identification device. [Figure 3] FIG. 3 is a diagram illustrating an example of the configuration of the identification device. [Figure 4] FIG. 4 is a diagram illustrating an example of vulnerability information. [Figure 5] FIG. 5 is a diagram illustrating an example of patch information. [Figure 6] FIG. 6 is a diagram showing an example of obtaining a patch code. [Figure 7] FIG. 7 is a diagram showing an example of division of a patch cord. [Figure 8] FIG. 8 is a diagram for explaining division of a patch cord. [Figure 9] FIG. 9 is a diagram showing an example of a prompt. [Figure 10] FIG. 10 is a diagram showing an example of an output of the classification result. [Figure 11] FIG. 11 is a flowchart illustrating an example of a processing procedure executed by the identification device. [Figure 12] FIG. 12 shows the CVE numbers that were evaluated. [Figure 13] Figure 13 shows the verification results (evaluation results) of CVE-2020-15121[radare2]. [Figure 14] Figure 14 shows the verification results (evaluation results) of CVE-2019-15139 [ImageMagick]. [Figure 15A] Figure 15A shows the evaluation results for vulnerabilities other than CVE-2020-15121 and CVE-2019-15139. [Figure 15B] Figure 15B shows the evaluation results for vulnerabilities other than CVE-2020-15121 and CVE-2019-15139. [Figure 16] FIG. 16 is a diagram illustrating a computer that executes an identification program. DETAILED DESCRIPTION OF THE INVENTION

[0011] Hereinafter, with reference to the drawings, modes for carrying out the present invention (embodiments) will be described in two parts, a first embodiment and a second embodiment, but the present invention is not limited to each embodiment.

[0012] [First embodiment] [overview] First, an overview of the identification device 10 of the first embodiment will be described with reference to Figures 1 and 2. As shown in Figure 1, the identification device 10 identifies portions of publicly available patch codes for fixing vulnerabilities that directly fix vulnerabilities and portions that do not fix vulnerabilities.

[0013] 2, when the identification device 10 receives a specification of a CVE (Common Vulnerabilities and Exposures) number of a vulnerability to be fixed from a user, the identification device 10 acquires vulnerability-related information and patch information for the specified CVE number from an external vulnerability information database (external information acquisition). For example, the identification device 10 acquires text data explaining the vulnerability with the specified CVE number and a URL of a patch code for the vulnerability (patch URL).

[0014] Thereafter, the identification device 10 acquires a patch code (.diff) based on the acquired patch information (acquiring a code).

[0015] Next, the identification device 10 uses the vulnerability-related information and LLMs (Large Language Models) to distinguish between fixes for vulnerabilities with the specified CVE numbers and other fixes for the acquired patch code (fix location identification). The identification device 10 then outputs the identification result of the fix locations for vulnerabilities in the patch code (see the identification result). This allows the user to check the fix locations for vulnerabilities in the patch code.

[0016] [Configuration example] Next, an example configuration of the identification device 10 will be described with reference to FIG. 3. The identification device 10 includes, for example, an input / output unit 11, a communication unit 12, a storage unit 13, and a control unit 14. As shown in FIG. 3, the identification device 10 is connected to a vulnerability information database and a client terminal via a network. The vulnerability information database is a database that stores vulnerability-related information and vulnerability patch information. The client terminal is a terminal device of a user of the identification device 10.

[0017] The input / output unit 11 is an interface that controls the input and output of various data. The input / output unit 11 receives input of various settings for the identification device 10, for example.

[0018] The communication unit 12 is a communication interface used when the identification device 10 communicates with external devices via a network. The communication unit 12 receives, for example, the CVE number of a vulnerability to be fixed from a user (client terminal) and transmits the identification result of the part of the patch code where the vulnerability needs to be fixed. The communication unit 12 also obtains, for example, vulnerability-related information and patch information for the vulnerability with the specified CVE number from a vulnerability information database.

[0019] The storage unit 13 stores data, programs, etc. that are referenced when the control unit 14 executes various processes. The storage unit 13 is realized by a semiconductor memory element such as a RAM (Random Access Memory) or a flash memory, or a storage device such as a hard disk or an optical disk. For example, the storage unit 13 stores vulnerability-related information, patch information, etc. obtained from a vulnerability information database.

[0020] The control unit 14 controls the entire identification device 10. The functions of the control unit 14 are realized by, for example, a CPU (Central Processing Unit) executing a program stored in the storage unit 13.

[0021] The control unit 14 includes, for example, an information acquisition unit 141, a code acquisition unit 142, an identification unit 143, and an identification result output unit 144. A division unit 145 indicated by a dashed line may or may not be provided, and the cases in which it is provided will be described later.

[0022] [Information acquisition department] The information acquisition unit 141 acquires, from the vulnerability information database, vulnerability-related information (vulnerability information) that is explanatory information about a vulnerability designated by a user, and patch information about the vulnerability.

[0023] For example, the information acquisition unit 141 first accepts a CVE number from a user. Then, for example, if the vulnerability information database is the National Vulnerability Database (NVD), the information acquisition unit 141 acquires vulnerability information for the specified CVE number from the NVD (for example, Description of CVE-2020-15121, see FIG. 4). The information acquisition unit 141 also acquires patch information for the specified CVE number from the NVD (for example, patch information for CVE-2020-15121, see FIG. 5). To acquire vulnerability information and patch information from the NVD, for example, the NVD REST API or JSON Data Feeds, which are search APIs, is used.

[0024] [Code Acquisition Section] Returning to the explanation of FIG. 3, the code acquisition unit 142 acquires code related to a vulnerability (e.g., a patch code) from the patch information acquired by the information acquisition unit 141. For example, the code acquisition unit 142 creates a new URL by adding .diff to the end of the patch information. Then, the code acquisition unit 142 specifies the created URL to a web search API, for example, by using a request module in Python, and acquires HTML data of the search results. Thereafter, the code acquisition unit 142 outputs the acquired data to a file and acquires the patch code. For example, the code acquisition unit 142 acquires the patch code from the patch information for CVE-2020-15121 shown in FIG. 6.

[0025] [Identification section] Returning to the explanation of Fig. 3, the identification unit 143 inputs the patch code and vulnerability information acquired by the code acquisition unit 142 to the LLM, causing the LLM to identify the correction portion in the patch code that corresponds to the vulnerability information. For example, the identification unit 143 inputs the vulnerability information and the patch code in a prompt to the LLM, and instructs the LLM to classify (identify) some or all of the patch code that corresponds to the vulnerability information and output it in a specified format. Note that the identification unit 143 includes the following content in the prompt when causing the LLM to execute processing:

[0026] Where in the patch code are the file names and parts to be corrected described? Also, if the part to be corrected is a function, where in the patch code is the function to be corrected described? -If it is determined that the correction content of the correction part (difference block) is related to the vulnerability described in the vulnerability information, the instruction to identify the difference block as a difference block related to the correction of the vulnerability and output it.

[0027] That is, the identification unit 143 prompts the LLM to input vulnerability information and patch codes, classify them, and output them in a specified format in order to have the LLM interpret the information provided to it.

[0028] For example, the identification unit 143 inputs the system_message shown in Fig. 9 as a prompt to the LLM. Note that in the example shown in Fig. 9, the identification of the differential block in the LLM is one of three values, "directly related", "unrelated", and "undeterminable", with respect to the vulnerability with the specified CVE number, but it may also be two values, "directly related" and "unrelated".

[0029] Furthermore, the identification unit 143 may include an instruction to briefly explain the reason for classifying (identifying) the differential block in the prompt to the LLM, as shown in Fig. 9. This allows the user to confirm the reason why the LLM identified the vulnerable repair location.

[0030] [Classification result output section] Returning to the explanation of Fig. 3, the identification result output unit 144 outputs the identification result of each differential block by the identification unit 143. For example, in response to a request from a user, the identification result output unit 144 outputs information on a differential block related to vulnerability repair (a differential block directly related to a vulnerability).

[0031] In addition, the identification result output unit 144 may output information on differential blocks of modifications other than vulnerability modifications (differential blocks unrelated to vulnerabilities) in addition to information on differential blocks of vulnerability modifications (differential blocks directly related to vulnerabilities).

[0032] For example, consider a case where the vulnerability specified by the user is CVE-2014-9659. In this case, the identification result output unit 144 displays, for example, the correction parts identified as being directly related to the vulnerability of CVE-2014-9659, the correction parts identified as being unrelated, and the correction parts identified as being undeterminable, along with the basis for each identification, as shown in FIG.

[0033] This allows users to check the patch code modifications that are directly related to the vulnerability and the reason for their identification. As a result, users can shorten the time it takes to understand the patch code modifications. Users can also understand how the patch code modifications affect the software code.

[0034] This allows developers, for example, to understand how patch code modifications will affect the operation of their products when fixing vulnerabilities in their own products. Also, since there is a concern that applying a published patch code as is may cause malfunctions, developers can carefully apply the patch code after checking its contents.

[0035] Furthermore, in research into vulnerability detection, published patch codes are often used as is, but since they contain noise code (code unrelated to vulnerabilities), this can lead to false detection. In such cases, the noise code can be removed from the patch code by identifying the noise code portion of the patch code using the identification device 10.

[0036] [Example of processing procedure] Next, an example of a processing procedure executed by the identification device 10 will be described with reference to Fig. 11. First, the information acquisition unit 141 receives an input of the CVE number of a vulnerability to be fixed from a user (S1). Then, the information acquisition unit 141 acquires external information (vulnerability information and patch information for the vulnerability) required to identify the part to be fixed for the vulnerability with the CVE number received in S1 (S2).

[0037] After S2, the code acquisition unit 142 acquires a patch code from the patch information acquired in S2 (S3).

[0038] After S3, the identification unit 143 reads the patch code acquired in S3 and the vulnerability information acquired in S2 into the LLM, and causes the LLM to identify whether the modification content of each differential block of the patch code is related to the modification of a vulnerability (S5: Identify the location of the vulnerability modification). After that, the identification result output unit 144 notifies the user of the identification result in S5 (S6).

[0039] By executing the above process, the identification device 10 can notify the user of the identification result of the vulnerability repair part in the vulnerable patch code.

[0040] [Second embodiment] Next, a description will be given of the identification device 10 of the second embodiment. The identification device 10 of the second embodiment divides a patch code related to a vulnerability into blocks (difference blocks) for each correction location, and distinguishes between a correction for a vulnerability and a correction for another vulnerability by LLM for each divided difference block.

[0041] [Divided part] The identification device 10 of the second embodiment further includes a dividing unit 145 shown in Fig. 3. The dividing unit 145 divides the patch code acquired by the code acquiring unit 142 into blocks (difference blocks) for each correction location by lexical analysis of the patch code.

[0042] For example, the dividing unit 145 divides the patch code into blocks (difference blocks) separated by lines of @@. The reason for dividing the patch code as described above is that dividing the patch code into correction locations separated by lines of @@ and inputting the divided patch code into the LLM makes it easier for the LLM to digest the input information, improving the accuracy of identifying the correction locations.

[0043] The patch code above is the result of a git commit, for example, and is separated into files by diffs. Within each diff, a chunk of modifications (such as a function or declaration) is represented by "@@ -a,b +c,d @@".

[0044] For example, in the above "@@ -a,b +c,d @@", a indicates the starting line of the original file, b indicates the number of diff chunk lines in the original file, c indicates the starting line of the new file, and d indicates the number of diff chunk lines in the new file. The dividing unit 145 identifies diff and @@ in units of lines separated by line breaks in the patch code, and divides it into difference blocks.

[0045] For example, the dividing unit 145 obtains the file name from the diff line (see reference numeral 701) of the patch code for CVE-2020-15121 shown in FIG. 7, and treats the code lines up to the line @@ it recognizes (for example, from the code line shown by reference numeral 702 to the code line immediately preceding the code line shown by reference numeral 703) as one difference block. The dividing unit 145 divides the patch code into multiple difference blocks by repeating the above process. Then, the dividing unit 145 includes a sequential number (a number starting from 1), a file name, and a function name, if any, in each divided difference block.

[0046] For example, in the case of the patch code for CVE-2020-15121, there are 32 lines separated by @@ lines, so the dividing unit 145 creates 32 difference blocks (see FIG. 8).

[0047] [Identification section] Returning to the explanation of Fig. 3, the identification unit 143 in the identification device 10 of the second embodiment inputs the difference blocks divided by the division unit 145 and vulnerability information to the LLM, causing the LLM to identify whether each difference block is a difference block related to vulnerability repair.

[0048] For example, the identification unit 143 provides the LLM with all the difference blocks processed by the division unit 145 and the vulnerability information acquired by the information acquisition unit 141. The identification unit 143 includes the following content in the prompt when causing the LLM to execute processing.

[0049] Where in the difference block are the file names and corrections to be made listed? Also, if the correction to be made in the difference block is a function, where in the difference block is the function to be corrected listed? - If it is determined that the correction content of the differential block is related to the vulnerability described in the vulnerability information, the instruction to identify and output the differential block as a differential block related to the correction of the vulnerability.

[0050] According to the above-described identification device 10, it is possible to more accurately identify, in a patch code, a correction portion related to a vulnerability described in the vulnerability information.

[0051] [Other embodiments] The identification device 10 of each embodiment may use, instead of the LLM, other inference models based on, for example, generative AI (Artificial Intelligence) or natural language processing technology.

[0052] Furthermore, the lexical analysis performed by the identification device 10 of the second embodiment when dividing a patch code into differential blocks can be replaced by semantic understanding using, for example, pattern matching, search processing, or natural language processing technology.

[0053] The identification device 10 of each embodiment may further include an output processing unit that generates and outputs a patch code using only differential blocks corresponding to the vulnerability information specified by the user from the acquired patch code. The output processing unit may also delete parts of the acquired patch code that are not related to the vulnerability information specified by the user and output the resulting patch code.

[0054] Furthermore, the identification device 10 of each embodiment may use the target source code to create modified source code, and may further use the modified source code to generate or replace executable code.

[0055] The identification unit 143 may input comments, messages, etc. of code acquired from an external device (e.g., a repository) as input information to the LLM, in addition to vulnerability information of a CVE number designated by the user. For example, the following text data (1) and (2) may be input.

[0056] (1) Issue comments that can be obtained from the commit hash value of the patch code for the CVE number specified by the user (2) A commit message that can be obtained from the commit hash value of the patch code for the CVE number specified by the user.

[0057] (1) Method of acquiring issue comments: The identification unit 143 identifies the issue number of the patch code from the commit number of the patch code (SHA (Secure Hash Algorithm), the last data of the URL of the patch information) using the GitHub API. Next, the identification unit 143 acquires the body part from the identified issue number and acquires the issue message (issue comment).

[0058] (2) Method of acquiring a commit message: The identification unit 143 acquires the commit message of the patch code from the commit number of the patch code by using the API of GitHub.

[0059] By inputting the above information (1) and (2) into the LLM in addition to the vulnerability information of the CVE number specified by the user, the identification unit 143 can more accurately identify the vulnerability fix locations in the patch code.

[0060] Furthermore, the identification unit 143 may add the following content to the prompt as a definition or example of the identification:

[0061] -Fixes related to vulnerability fixes: Fixes related to vulnerability keywords, function names, and file names that appear in the vulnerability information description -Fixes unrelated to vulnerability fixes: Change Log fixes, comment text fixes, copyright fixes Undetermined: Fixes that do not fall into either of the above two categories

[0062] By having the identification unit 143 add the above content to the prompt to the LLM, the LLM can more accurately identify the location of the vulnerability to be fixed in the patch code.

[0063] Furthermore, although the identification device 10 divides the patch code for the specified vulnerability into difference blocks and causes the LLM to read the code, the LLM may read the code without dividing the code into difference blocks.

[0064] [Evaluation results] Next, the evaluation results of the accuracy of identifying the vulnerability repair locations in the patch code by the identification device 10 of the second embodiment will be described.

[0065] The CVE numbers of the vulnerabilities evaluated are shown in Figure 12. The number of difference blocks generated from the era, vulnerability type (CWE), and vulnerability patch code was made as different as possible between the vulnerabilities evaluated. The identification device 10 received the vulnerability description and patch code for each CVE number shown in Figure 12 as input.

[0066] The evaluation results (verification results) for CVE-2020-15121[radare2] are shown in Figure 13. The first column of the table in Figure 13 shows the number of the correction, the second column shows the line in the Diff file of the patch code corresponding to that correction, the third column shows the results of a human evaluation of whether the vulnerability description is related to the output (the output content of the identification result for that correction by LLM), and the fourth column shows the output content of the identification result for that correction by LLM. Note that the text after the arrow in the output content column is a comment made by a human when assessing whether the output content by LLM written before the arrow is actually related to the vulnerability description.

[0067] 13, the identification device 10 identified seven locations #1 to #7 from among the 32 differential blocks of CVE-2020-15121[radare2] as modification locations directly related to the vulnerability fix. All seven locations were related to the description of CVE-2020-15121[radare2].

[0068] The evaluation results for CVE-2019-15139 [ImageMagick] are shown in Figure 14. As shown in Figure 14, the identification device 10 identified three locations, #1 to #3, from among the five difference blocks of CVE-2019-15139 [ImageMagick] as modification locations directly related to the fix for the vulnerability. Of these three locations, #2 was actually unrelated to the description of CVE-2019-15139 [ImageMagick], but #1 and #3 were related to the description of CVE-2019-15139 [ImageMagick].

[0069] Furthermore, the identification device 10 identified two locations, #1 and #2, among the five difference blocks of CVE-2019-15139 [ImageMagick], as modification locations that are not directly related to the vulnerability fix. Neither of these two locations is related to the description of CVE-2019-15139 [ImageMagick].

[0070] Furthermore, for vulnerabilities other than CVE-2020-15121 and CVE-2019-15139, the identification results shown in Figures 15A and 15B were obtained. As shown in Figures 15A and 15B, it was confirmed that the identification device 10 can generally correctly identify the repair locations of vulnerability in patch codes. Note that "FP" in Figures 15A and 15B indicates a false positive, and "duplicate" indicates that the judgment results (identification results) were duplicated.

[0071] [System configuration, etc.] Furthermore, the components of each unit shown in the figure are conceptual functional units and do not necessarily have to be physically configured as shown. In other words, the specific form of distribution and integration of each device is not limited to that shown, and all or part of them can be functionally or physically distributed and integrated in any unit depending on various loads, usage conditions, etc. Furthermore, all or any part of the processing functions performed by each device can be realized by a CPU and a program executed by the CPU, or can be realized as hardware using wired logic.

[0072] Furthermore, among the processes described in the above embodiments, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically using a known method.In addition, the information including the processing procedures, control procedures, specific names, various data and parameters shown in the above documents and drawings can be changed as desired unless otherwise specified.

[0073] [program] The above-described identification device 10 can be implemented by installing a program (identification program) as package software or online software on a desired computer. For example, by executing the above-described program on an information processing device, the information processing device can function as the identification device 10. The information processing device referred to here includes mobile communication terminals such as smartphones, mobile phones, and PHS (Personal Handyphone Systems), as well as terminals such as PDAs (Personal Digital Assistants).

[0074] 16, a computer 1000 that executes an identification program includes, for example, a memory 1010 and a CPU 1020. The computer 1000 also includes a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. These components are connected by a bus 1080.

[0075] The memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM (Random Access Memory) 1012. The ROM 1011 stores a boot program such as a BIOS (Basic Input Output System). The hard disk drive interface 1030 is connected to a hard disk drive 1090. The disk drive interface 1040 is connected to a disk drive 1100. A removable storage medium such as a magnetic disk or optical disk is inserted into the disk drive 1100. The serial port interface 1050 is connected to a mouse 1110 and a keyboard 1120, for example. The video adapter 1060 is connected to a display 1130, for example.

[0076] The hard disk drive 1090 stores, for example, an OS 1091, an application program 1092, a program module 1093, and program data 1094. That is, the program that defines each process executed by the above-mentioned identification device 10 is implemented as a program module 1093 in which computer-executable code is written. The program module 1093 is stored, for example, in the hard disk drive 1090. For example, a program module 1093 for executing processes similar to those of the functional configuration of the identification device 10 is stored in the hard disk drive 1090. Note that the hard disk drive 1090 may be replaced by an SSD (Solid State Drive).

[0077] Data used in the processing of the above-described embodiment is stored as program data 1094 in, for example, the memory 1010 or the hard disk drive 1090. The CPU 1020 then reads the program module 1093 or the program data 1094 stored in the memory 1010 or the hard disk drive 1090 into the RAM 1012 as needed and executes them.

[0078] The program module 1093 and program data 1094 are not limited to being stored in the hard disk drive 1090, but may also be stored in, for example, a removable storage medium and read by the CPU 1020 via the disk drive 1100 or the like. Alternatively, the program module 1093 and program data 1094 may be stored in another computer connected via a network (such as a LAN (Local Area Network) or WAN (Wide Area Network)). The program module 1093 and program data 1094 may then be read by the CPU 1020 from the other computer via the network interface 1070. [Explanation of symbols]

[0079] 10 Identification device 11 Input / output section 12 Communications Department 13 Storage section 14 Control Unit 141 Information Acquisition Department 142 Code Acquisition Department 143 Identification Unit 144 Classification result output unit 145 Division

Claims

1. an information acquisition unit that acquires vulnerability information, which is explanatory information about a vulnerability designated by a user, and patch information for the vulnerability from a vulnerability information database; a code acquisition unit that acquires a code related to the vulnerability using the patch information; an identification unit that inputs the code and the vulnerability information into an inference model using natural language processing, thereby causing the inference model to identify a correction portion in the code related to the vulnerability; an identification result output unit that outputs the result of the identification; An identification device comprising:

2. a dividing unit that divides the code into blocks for each modification portion by the code based on a lexical analysis of the code related to the vulnerability; The identification unit The divided blocks and the vulnerability information are input to the inference model, and the inference model is made to identify whether each of the blocks is a block related to the correction of the vulnerability.

2. The identification device according to claim 1.

3. The identification unit The instructions to the inference model include: A description of the file name to be corrected, the part to be corrected, and the part of the code where the function to be corrected is described; an instruction to identify the modified portion of the code as a modified portion related to the fix for the vulnerability if the content of the modification in the modified portion of the code is related to the vulnerability described in the vulnerability information; and, An instruction to output the result of the identification including the basis for the identification.

2. The identification device according to claim 1, further comprising at least one of:

4. The identification unit In addition to the vulnerability information of the vulnerability, at least one of a code comment and a message related to the vulnerability acquired from an external device is input to the inference model.

2. The identification device according to claim 1, wherein:

5. an output processing unit that generates and outputs code using the correction portion identified as the correction portion related to the vulnerability information from the acquired code, or code from which the correction portion related to the vulnerability information has been deleted; The identification device according to claim 1 , further comprising:

6. 1. An identification method performed by an identification device, comprising: a step of acquiring vulnerability information, which is explanatory information regarding a vulnerability designated by a user, and patch information for the vulnerability, from a vulnerability information database; obtaining code related to the vulnerability using the patch information; inputting the code and the vulnerability information into an inference model using natural language processing to allow the inference model to identify fixes related to the vulnerability in the code; outputting the results of said identification; 10. A method for identifying a target object, comprising:

7. a step of acquiring vulnerability information, which is explanatory information regarding a vulnerability designated by a user, and patch information for the vulnerability, from a vulnerability information database; obtaining code related to the vulnerability using the patch information; inputting the code and the vulnerability information into an inference model using natural language processing to allow the inference model to identify fixes related to the vulnerability in the code; outputting the results of said identification; An identification program for causing a computer to execute the above.

Images