WO2024252676A1 - 検知装置、検知方法及び検知プログラム - Google Patents

検知装置、検知方法及び検知プログラム Download PDF

Info

Publication number
WO2024252676A1
WO2024252676A1 PCT/JP2023/021570 JP2023021570W WO2024252676A1 WO 2024252676 A1 WO2024252676 A1 WO 2024252676A1 JP 2023021570 W JP2023021570 W JP 2023021570W WO 2024252676 A1 WO2024252676 A1 WO 2024252676A1
Authority
WO
WIPO (PCT)
Prior art keywords
function
source code
software
patch
similarity
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/JP2023/021570
Other languages
English (en)
French (fr)
Inventor
玲佳 荒川
楊 鐘本
拓也 南
浩義 瀧口
高明 小山
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NTT Inc
Original Assignee
Nippon Telegraph and Telephone Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to PCT/JP2023/021570 priority Critical patent/WO2024252676A1/ja
Priority to JP2025525919A priority patent/JPWO2024252676A1/ja
Publication of WO2024252676A1 publication Critical patent/WO2024252676A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities

Definitions

  • the present invention relates to a detection device, a detection method, and a detection program.
  • the detection device of the present invention is characterized by having an acquisition unit that acquires at least one of the source code of a function of software having a vulnerability before application of a patch and the source code of the function after application of the patch, and a determination unit that uses feature vectors created from the function included in the source code acquired by the acquisition unit and the function included in the source code of the function of the software to be inspected by a set similarity calculation algorithm to calculate the similarity between the feature vectors, and determines whether the function included in the software to be inspected is vulnerable based on the similarity.
  • the present invention has the effect of being able to properly detect vulnerabilities in edited software.
  • FIG. 1 is a diagram showing an overview of a detection process performed by a detection device according to an embodiment.
  • FIG. 2 is a diagram showing software to be inspected that was used in a comparative experiment using the detection device according to the embodiment.
  • FIG. 3 is a diagram showing experimental results of a comparative experiment using the detection device according to the embodiment.
  • FIG. 4 is a diagram illustrating an example of the configuration of a detection device according to an embodiment.
  • FIG. 5 is a diagram illustrating an example of data stored in the detection device according to the embodiment.
  • FIG. 6 is a diagram illustrating a specific example of a feature vector according to the embodiment.
  • FIG. 7 is a diagram showing a specific example of the detection process according to the embodiment.
  • FIG. 1 is a diagram showing an overview of a detection process performed by a detection device according to an embodiment.
  • FIG. 2 is a diagram showing software to be inspected that was used in a comparative experiment using the detection device according to the embodiment.
  • FIG. 3 is a
  • FIG. 8 is a diagram showing a specific example of the detection process according to the embodiment.
  • FIG. 9 is a diagram showing a specific example of the detection process according to the embodiment.
  • FIG. 10 is a diagram showing a specific example of the detection process according to the embodiment.
  • FIG. 11 is a diagram showing a specific example of information output by the detection process according to the embodiment.
  • FIG. 12 is a flowchart illustrating an example of the flow of the detection process according to the embodiment.
  • FIG. 13 is a diagram illustrating an example of a computer that executes a detection program.
  • Non-Patent Documents 1 to 3 all involve three common processes. First, as a preprocessing of the source code, only the function description section is extracted from each of the three pieces of code - the software code to be inspected and the source code before and after the patch to be compared - and variable names, type names, etc. are abstracted. Next, each piece of code that has been preprocessed is converted into data such as hash values and signatures. The converted data are then compared, and if there is a certain percentage or more of match with the vulnerable code before the patch was applied, it is detected that a known vulnerability exists in the software to be inspected.
  • ReDeBug does not abstract variable names, but divides the source file into four lines, hashes the token strings within them, and stores them in a data structure called Bloom Filter. It then compares the stored bit strings and outputs a vulnerability detection result if the data matches.
  • VUDDY abstracts variable names and type names, and builds a database for each function with "key: string length of function body” and "value: hash value”. It then compares the "key” and "value” in the database and outputs a vulnerability detection result if the record in the function database of the target OSS matches the record in the function database before the patch was applied.
  • MOVERY then creates a "pre-patch signature" and a "post-patch signature” in advance for each function for which a vulnerability has been reported.
  • the "pre-patch signature” is created by taking the difference between the pre-patch state of the function at the time of the initial report and the pre-patch state at the time of the most recent report, and combining the common lines into a function-specific pre-patch signature.
  • the "post-patch signature” is created by combining the lines to which the patch has been applied.
  • MOVERY compares the lines of the software being inspected with the signature, and outputs a vulnerability detection result if the data matches.
  • function editing refers to code editing such as adding or deleting lines or changing the order, and survey results have shown that code editing occurs at a rate of over 90% when an SA developer updates the version of the SA itself, or when a developer of another software (SB) partially reuses an SA, edits it, and incorporates it into the SA.
  • SB software
  • the detection device 100 according to the present embodiment has been invented for the purpose of appropriately detecting vulnerabilities even when code edits such as those described above have been made, and has the effect of being able to appropriately detect vulnerabilities in software that has been edited.
  • FIG. 1 is a diagram showing an overview of the detection processing performed by the detection device according to the embodiment.
  • the detection device 100 is a server device that transmits and receives information via a network to, for example, an external database having data related to vulnerability information, or an external information processing device having software to be inspected, and stores vulnerability detection results, and is realized by a PC (Personal Computer), a cloud system, or the like.
  • PC Personal Computer
  • the detection device 100 acquires at least one of the source code of the function before the patch is applied and the source code of the function after the patch is applied for the function of the software having a vulnerability.
  • the detection device 100 uses feature vectors created from the function included in the acquired source code and the function included in the source code of the function of the software being inspected by a set similarity calculation algorithm to calculate the similarity between the feature vectors, and determines whether the function included in the software being inspected is vulnerable based on the similarity.
  • the detection device 100 first obtains at least one of the source code of the function before the patch is applied and the source code of the function after the patch is applied for the function of the software having a vulnerability.
  • the acquisition unit 121 of the detection device 100 obtains the latest CVE (Common Vulnerabilities and Exposures) number listed in the NVD database, and obtains at least one of the source codes of the function before or after the patch is applied from the vulnerability information linked to the CVE number.
  • CVE Common Vulnerabilities and Exposures
  • the detection device 100 extracts the portion of the acquired source code in which functions are written, and creates a feature vector for each function by applying the set similarity calculation algorithm described below to the extracted functions. The detection device 100 then determines whether the functions included in the test target are vulnerable by, for example, calculating the similarity between the feature vector of the function before or after patch application and the feature vector of the software to be tested, and comparing it with a threshold value.
  • FIG. 5(A) is a specific example of data stored in the function information storage unit 131, and shows that the source code before and after patch application are stored separately for each CVE number.
  • FIG. 5(B) is a specific example of data stored in the detection information storage unit 132, and shows that information about functions determined to be vulnerable, such as "function name: b_unpack”, “file name: sample”, “similarity (before application): 0.95312", “similarity (after application) 0.78125”, and "CVE number: CVE-2018-11219", is stored for each function.
  • control unit 120 is realized by a CPU (Central Processing Unit), MPU (Micro Processing Unit), etc., executing various programs stored in a storage device inside the device using RAM as a working area.
  • the control unit 120 is also realized by an integrated circuit such as an ASIC (Application Specific Integrated Circuit) or FPGA (Field Programmable Gate Array).
  • the control unit 120 has an acquisition unit 121 and a determination unit 122, and may have a preprocessing unit 123 and a storage unit 124 as necessary.
  • the acquisition unit 121 acquires at least one of the source code of the function before the patch is applied and the source code of the function after the patch is applied for a function of software having a vulnerability.
  • the acquisition unit 121 may also acquire the source code of the function before the patch is applied and the source code of the function after the patch is applied.
  • the determination unit 122 compares the calculated similarity with a preset threshold value and determines that the function included in the software being inspected is vulnerable if the similarity with the function before the patch is applied is equal to or greater than the threshold value, or if the similarity with the function after the patch is applied is equal to or less than the threshold value.
  • the determination unit 122 first compares the similarity between the feature vector of the function included in the software to be inspected and the feature vector of the function before the patch is applied with a preset threshold value. After that, for functions whose similarity is equal to or greater than the threshold value, the determination unit 122 compares the magnitude of the similarity between the feature vector of the function before the patch is applied and the feature vector of the function after the patch is applied, and if the similarity between the feature vector of the function before the patch is greater, it determines that the function included in the software to be inspected is vulnerable.
  • FIG. 6 is a diagram for explaining a specific example of a feature vector according to an embodiment.
  • the seed setting value is "128”
  • a feature vector is shown in which the lowest 1 bit of each hash value is used as an element.
  • the preprocessing unit 123 creates a feature vector by recording only the lowest "1 bit" of each function with the number of seed values "128".
  • the preprocessing unit 123 creates a set of elements each consisting of a logical block included in the portion of the source code in which the function is described, as a feature vector. For example, after performing the above-mentioned process from the extraction process to the standardization process of the function description unit, the preprocessing unit 123 creates a set of elements each consisting of a logical block included in the function, as a feature vector of the function.
  • a logical block refers to a certain number of lines or control statement blocks written in the function description unit in the source code.
  • Fig. 7 to Fig. 10 are diagrams showing a specific example of the detection process according to the embodiment.
  • a specific example of the process using b-bit minhash as the inter-set similarity calculation algorithm will be described with reference to Fig. 7. Note that in the example of Fig. 7, it is assumed that the feature vector is set to be created using the lowest 1 bit.
  • the similarity is calculated using the formula "(number of matching bits/length of feature vector of b-bitminhash-1/2) x 2".
  • the number of matching bits is expressed by subtracting the number of different bits from the length of the feature vector of b-bitminhash, and the length of the feature vector corresponds to the seed value.
  • the number of different bits is calculated using an XOR operation, and 1/2 in the above formula indicates the probability of an error of 0 or 1.
  • the determination unit 122 compares "similarity S: 95%” with "similarity S': 78%”. As a result, since similarity S is a higher value, the determination unit 122 determines that the function included in the software being inspected is a vulnerable function.
  • Fig. 12 is a flowchart showing an example of the flow of the detection process according to the embodiment. Note that the order of the processing steps described in the flowchart shown in Fig. 12 may be changed.
  • the acquisition unit 121 acquires the source code of a function before and after application of a patch for a known vulnerability code (step S101).
  • the preprocessing unit 123 accepts the software to be inspected (step S102). If the software to be inspected has been accepted (step S102; Yes), the preprocessing unit 123 creates feature vectors for the source code of the function before and after application of the patch and for the source code of the function of the software to be inspected (step S103). On the other hand, if the software to be inspected has not been accepted (step S102; No), the preprocessing unit 123 waits until the software to be inspected is accepted.
  • the determination unit 122 determines whether the similarity between the feature vector before application of the patch and the feature vector of the software to be inspected is equal to or greater than a threshold value (step S104). If the similarity between the feature vector before application of the patch and the feature vector of the software to be inspected is equal to or greater than the threshold value (step S104; Yes), the determination unit 122 determines whether the similarity before application of the patch is equal to or greater than the similarity after application of the patch (step S105). On the other hand, if the similarity between the feature vector before application of the patch and the feature vector of the software to be inspected is not equal to or greater than the threshold value (step S104; No), the detection device 100 ends the process.
  • the determination unit 122 uses feature vectors created from the functions included in the source code acquired by the acquisition unit 121 and the functions included in the source code of the software to be inspected by a set similarity calculation algorithm to calculate the similarity between the feature vectors, and determines whether the functions included in the software to be inspected are vulnerable based on the similarity.
  • the detection device 100 creates a set (feature vector) whose components are data based on part of the function for each of the functions to be inspected and the functions to be compared, and calculates the similarity between the sets, thereby achieving the effect of being able to appropriately detect vulnerabilities even in software that has been edited.
  • the acquisition unit 121 of the detection device 100 acquires the source code of the function before application of the patch and the source code of the function after application of the patch, and the determination unit 122 determines that the function included in the software to be inspected is vulnerable if the similarity between the feature vector of the function before application of the patch and the feature vector of the function of the software to be inspected is equal to or greater than a predetermined threshold value and the similarity between the feature vector of the function before application of the patch and the feature vector of the function of the software to be inspected is higher than the similarity between the feature vector of the function after application of the patch and the feature vector of the function of the software to be inspected.
  • the detection device 100 compares the magnitude of similarity before and after patch application only for functions whose similarity to vulnerable functions before patch application exceeds a threshold value, thereby preventing the detection device 100 from treating functions whose similarity to vulnerable functions after patch application is higher than a certain level as functions whose vulnerabilities have already been eliminated, and erroneously detecting them as vulnerable functions.
  • the detection device 100 creates a set (feature vector) with each line of a vulnerable function included in the software being inspected as an element, and applies b-bitminhash, a fast and lightweight algorithm for calculating similarity between sets, to appropriately detect vulnerabilities.
  • the preprocessing unit 123 of the detection device 100 creates a feature vector, which is a set of elements each of which is a token included in the portion of the source code where the function is written. In this way, the detection device 100 creates a set of elements each of which is a token (word unit) for each function, thereby calculating the degree of agreement of finer elements as the degree of similarity, which has the effect of enabling highly accurate vulnerability detection.
  • the preprocessing unit 123 of the detection device 100 also creates a feature vector, which is a set whose elements are the logical blocks contained in the portion of the source code where the function is written. This allows the detection device 100 to create a set whose elements are logical blocks (a certain number of lines or control statement blocks) for each function, thereby achieving the effect of being able to perform vulnerability detection under conditions where each set has a relatively small number of elements.
  • the detection device 100 further includes a storage unit 124.
  • the storage unit 124 stores information about functions that have been determined to be vulnerable by the determination unit in the memory unit 130. This allows the detection device 100 to provide an effect of allowing the user to easily grasp the detection results, etc., of functions that have been determined to have vulnerabilities among the functions included in the software to be inspected.
  • each component of each device shown in the figure is a functional concept, and does not necessarily have to be physically configured as shown in the figure.
  • the specific form of distribution and integration of each device is not limited to that shown in the figure, and all or part of it can be functionally or physically distributed and integrated in any unit depending on various loads and usage conditions.
  • each processing function performed by each device can be realized in whole or in part by a CPU and a program analyzed and executed by the CPU, or can be realized as hardware using wired logic.
  • Hardware Configuration 13 is a diagram showing an example of a hardware configuration of the detection device 100 according to the embodiment described above, which is realized by a computer 1000 having a configuration as shown in FIG.
  • FIG. 13 is a diagram showing an example of a computer that executes a detection program.
  • the computer 1000 has, for example, a memory 1010 and a CPU 1020.
  • the computer 1000 also has 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. Each of these components is connected by a bus 1080.
  • the memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM 1012.
  • the ROM 1011 stores a boot program such as a BIOS (Basic Input Output System).
  • 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 1041.
  • a removable storage medium such as a magnetic disk or optical disk is inserted into the disk drive 1041.
  • 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.
  • the hard disk drive 1090 stores, for example, an OS (Operating System) 1091, an application program 1092, a program module 1093, and program data 1094. That is, the programs that define each process of the detection device 100 are implemented as program modules 1093 in which code executable by the computer 1000 is written.
  • the program modules 1093 are stored, for example, in the hard disk drive 1090.
  • a program module 1093 for executing processes similar to the functional configuration of the detection device 100 is stored in the hard disk drive 1090.
  • the hard disk drive 1090 may be replaced by an SSD (Solid State Drive).
  • the setting data used in the processing of the above-mentioned embodiment is stored as program data 1094, for example, in memory 1010 or hard disk drive 1090.
  • the CPU 1020 reads the program module 1093 or program data 1094 stored in memory 1010 or hard disk drive 1090 into RAM 1012 as necessary and executes it.
  • the program module 1093 and program data 1094 are not limited to being stored in the hard disk drive 1090, but may be stored in, for example, a removable storage medium and read by the CPU 1020 via the disk drive 1041 or the like. Alternatively, the program module 1093 and program data 1094 may be stored in another computer connected via a network (LAN, WAN, etc.). 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.
  • Detection device 110 Communication unit 120 Control unit 121 Acquisition unit 122 Determination unit 123 Preprocessing unit 124 Storage unit 130 Memory unit 131 Function information storage unit 132 Detection information storage unit

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

本実施形態に係る検知装置（１００）は、取得部（１２１）と判定部（１２２）とを有する。取得部（１２１）は、脆弱性を有するソフトウェアの関数について、パッチの適用前の関数のソースコードと、パッチの適用後の関数のソースコードとのうち、少なくともいずれか一つを取得する。判定部（１２２）は、取得部（１２１）によって取得されたソースコードに含まれる関数と、検査対象のソフトウェアの関数のソースコードに含まれる関数とから集合間類似度算出アルゴリズムにより、それぞれ作成された特徴ベクトルを用いて、当該特徴ベクトル同士の類似度を算出し、当該類似度に基づき、検査対象のソフトウェアに含まれる関数が脆弱であるか否かを判定する。

Description

検知装置、検知方法及び検知プログラム
　本発明は、検知装置、検知方法及び検知プログラムに関する。
　近年のソフトウェア開発は、開発効率化のためにサードパーティのライブラリやＯＳＳ（Open　Source　Software）のソースコードの利用が進んでいる。ソースコードの再利用は複数の利点が存在するが、再利用を行う者は、コードの管理と保守について責任を負うことが求められる。
　また、ソフトウェアの複雑性の増加に伴い再利用元の最新の脆弱性情報を入手することが困難となっている。そのため、再利用元のソースコードについての修正パッチの情報が公開されたとしても、再利用先で修正されずに残存してしまい、それらの脆弱性を狙ったサイバー攻撃が増加している。
　そこで、検査対象のソフトウェアに既知の脆弱性が存在するか否かを、ＮＶＤ（National　Vulnerability　Database）の脆弱性情報データベースから収集した脆弱性情報のソースコードを用いて検査するという検査方式が存在する（例えば、非特許文献１～３参照）。非特許文献１～３の方式は、字句列特徴に基づく検査方式であり、検査対象のソフトウェアコードとパッチ適用前後のソースコードとから関数記述部を抽出・データ変換し、変換したデータを比較することにより、検査対象に存在する既知の脆弱性を検知する。
　しかし、上記の従来技術では、編集が行われたソフトウェアについて、適切に脆弱性を検知することができない場合があるという課題がある。例えば、上記の従来技術においては、検査対象のソフトウェアに、変数名の変更や行の追加等のコード編集が行われている場合に、検知漏れが発生することがある。また、従来技術では、検査対象のシグネチャと比較対象のシグネチャが一致しない場合には、検知漏れが発生することがあり、シグネチャが事前に作成されているＯＳＳしか検査を行うことができないという課題がある。
　上述した課題を解決し、目的を達成するために、本発明の検知装置は、脆弱性を有するソフトウェアの関数について、パッチの適用前の関数のソースコードと、パッチの適用後の関数のソースコードとのうち、少なくともいずれか一つを取得する取得部と、取得部によって取得されたソースコードに含まれる関数と、検査対象のソフトウェアの関数のソースコードに含まれる関数とから集合間類似度算出アルゴリズムにより、それぞれ作成された特徴ベクトルを用いて、当該特徴ベクトル同士の類似度を算出し、当該類似度に基づき、検査対象のソフトウェアに含まれる関数が脆弱であるか否かを判定する判定部とを有することを特徴とする。
　本発明によれば、編集が行われたソフトウェアについて、適切に脆弱性を検知することができるという効果を奏する。
図１は、実施形態に係る検知装置による検知処理の概要を示す図である。 図２は、実施形態に係る検知装置による比較実験に使用された検査対象ソフトウェアを示す図である。 図３は、実施形態に係る検知装置による比較実験の実験結果を示す図である。 図４は、実施形態に係る検知装置の構成例を示す図である。 図５は、実施形態に係る検知装置に記憶されるデータの一例を示す図である。 図６は、実施形態に係る特徴ベクトルの具体例について説明する図である。 図７は、実施形態に係る検知処理の具体例を示す図である。 図８は、実施形態に係る検知処理の具体例を示す図である。 図９は、実施形態に係る検知処理の具体例を示す図である。 図１０は、実施形態に係る検知処理の具体例を示す図である。 図１１は、実施形態に係る検知処理により出力される情報の具体例を示す図である。 図１２は、実施形態に係る検知処理の流れの一例を示すフローチャートである。 図１３は、検知プログラムを実行するコンピュータの一例を示す図である。
　以下に、本願に係る検知装置、検知方法及び検知プログラムの実施形態を図面に基づいて詳細に説明する。なお、この実施形態により本願に係る検知装置、検知方法及び検知プログラムが限定されるものではない。
〔１．はじめに〕
（１－１．先行技術の概要）
　まず、本実施例に係るソフトウェアの脆弱性検査技術における先行技術の概要について説明する。前述したように、ソフトウェアの脆弱性検査方式として、「ＲｅＤｅＢｕｇ」、「ＶＵＤＤＹ」、「ＭＯＶＥＲＹ」の３つの検査方式が知られている（非特許文献１～３参照）。
　非特許文献１～３の方式は、共通して３つの処理が行われる。まず、ソースコードの前処理として、検査対象のソフトウェアコードと、比較対象のパッチ適用前後のソースコードとである３つのコードそれぞれから関数記述部のみを抽出し、変数名や型名等の抽象化が行われる。次に、前処理が行われた各コードは、ハッシュ値やシグネチャ等のデータへ変換される。その後、変換したデータ同士が比較され、パッチ適用前の脆弱性コードと一定以上の割合で一致している場合には、検査対象のソフトウェアに既知の脆弱性が存在していると検知される。
　さらに、非特許文献１～３の方式は、データ変換の違いにより、ハッシュ値を用いるアプローチである「ＲｅＤｅＢｕｇ」及び「ＶＵＤＤＹ」と、脆弱性が報告されているＯＳＳの関数ごとにシグネチャを作成するアプローチである「ＭＯＶＥＲＹ」とに大別される。
　ここで、それぞれの先行技術の処理について順に説明する。まず、「ＲｅＤｅＢｕｇ」は、変数名の抽象化は行わず、ソースファイルを４行ごとに区切り、その中のトークン列をハッシュ化してＢｌｏｏｍ　Ｆｉｌｔｅｒというデータ構造で保持し、保持されたビット列の比較によって、データが一致している場合に脆弱性検知結果を出力する。
　次に、「ＶＵＤＤＹ」は、変数名や型名の抽象化を行い、関数ごとに「ｋｅｙ：関数本体の文字列長」、「ｖａｌｕｅ：ハッシュ値」としてデータベースを構築した後、データベースの「ｋｅｙ」と「ｖａｌｕｅ」の比較により、検知対象のＯＳＳの関数データベースのレコードが、パッチ適用前の関数データベースのレコードに一致している場合に脆弱性検知結果を出力する。
　そして、「ＭＯＶＥＲＹ」は、脆弱性が報告されている関数ごとに、「パッチ適用前のシグネチャ」と「パッチ適用後のシグネチャ」とを事前に作成する。ここで、「パッチ適用前のシグネチャ」は、初期の報告時のパッチ適用前状態の関数と最新の報告時のパッチ適用前状態で差分を取り、共通する行をまとめて関数固有のパッチ適用前のシグネチャとすることにより作成される。一方で、「パッチ適用後のシグネチャ」は、パッチが適用された行をまとめたものとして作成される。その後、「ＭＯＶＥＲＹ」は、検査対象のソフトウェアとシグネチャの行比較を行うことにより、データが一致した場合に脆弱性検知結果を出力する。
　しかし、前述の先行技術では、検査対象ソフトウェア内の関数が編集されることにより、脆弱性データベースに報告されている関数の記述状態と字句列的に同一でない場合には、検知漏れが発生する場合があるという課題がある。ここで、関数の編集とは、行の追加や削除、順序変更といったコード編集を指し、ＳＡ開発者によるＳＡ自体のバージョンアップデートや、別のソフトウェア（ＳＢ）開発者がＳＡを部分的に再利用し、編集してＳＡに組み込むことにより、約９０％以上の割合でコード編集が生じるという調査結果も報告されている。
　ここで、先行技術の課題についてそれぞれ具体的に説明する。まず、「ＲｅＤｅＢｕｇ」は、変数名の変更や、４行以上にわたる範囲でコード編集が存在する場合には、検知漏れが発生する。次に、「ＶＵＤＤＹ」は、一行でも行の追加や削除のコード編集が存在する場合には、検知漏れが発生する。そして、「ＭＯＶＥＲＹ」は、シグネチャが一致しない場合には、検知漏れが発生し、また、シグネチャが事前作成されているＯＳＳしか適用することができないという課題がある。
（１－２．本実施例に係る検知処理の概要）
　本実施例に係る検知装置１００は、前述したようなコード編集が存在する場合であっても適切に脆弱性検知を行うことを目的として発明されたものであり、編集が行われたソフトウェアについて、適切に脆弱性を検知することができるという効果を奏する。
　ここで、本実施例に係る検知装置１００による処理の概要について説明する。図１は、実施形態に係る検知装置による検知処理の概要を示す図である。検知装置１００は、例えば、脆弱性情報に関するデータを有する外部のデータベースや、検査対象のソフトウェアを有する外部の情報処理装置等と、ネットワークを介して情報の送受信を行い、脆弱性検知結果を記憶するサーバ装置であり、ＰＣ（Personal　Computer）やクラウドシステム等により実現される。
　検知装置１００は、脆弱性を有するソフトウェアの関数について、パッチの適用前の関数のソースコードと、パッチの適用後の関数のソースコードとのうち、少なくともいずれか一つを取得する。そして、検知装置１００は、取得されたソースコードに含まれる関数と、検査対象のソフトウェアの関数のソースコードに含まれる関数とから集合間類似度算出アルゴリズムにより、それぞれ作成された特徴ベクトルを用いて、当該特徴ベクトル同士の類似度を算出し、当該類似度に基づき、検査対象のソフトウェアに含まれる関数が脆弱であるか否かを判定する。
　検知装置１００は、まず、脆弱性を有するソフトウェアの関数について、パッチの適用前の関数のソースコードと、パッチの適用後の関数のソースコードとの少なくともいずれか一つを取得する。例えば、検知装置１００の取得部１２１は、ＮＶＤデータベースに掲載されている最新のＣＶＥ(Common　Vulnerabilities　and　Exposures)番号を取得し、ＣＶＥ番号に紐づく脆弱性情報から、パッチの適用前またはパッチ適用後の関数の少なくともいずれか一つのソースコードを取得する。
　次に、検知装置１００は、取得されたソースコードに含まれる関数と、検査対象のソフトウェアの関数のソースコードに含まれる関数とから集合間類似度算出アルゴリズムにより、それぞれ作成された特徴ベクトルを用いて、当該特徴ベクトル同士の類似度を算出し、当該類似度に基づき、検査対象のソフトウェアに含まれる関数が脆弱であるか否かを判定する。
　例えば、検知装置１００は、取得されたソースコードから関数が記述されている部分を抽出し、抽出された関数について後述する集合間類似度算出アルゴリズムを適用することにより、関数ごとに特徴ベクトルを作成する。その後、検知装置１００は、例えば、パッチ適用前またはパッチ適用後の関数の特徴ベクトルと、検査対象のソフトウェアの特徴ベクトルとの類似度を算出して閾値と比較することにより、検査対象に含まれる関数が脆弱であるか否かを判定する。
（１－３．先行技術と本実施例に係る検知装置との比較検証）
　次に、前述した３つの先行技術と、本実施例に係る検知装置１００との脆弱性検知精度の比較検証の実験について説明する。以下では、３つの先行技術と検知装置１００とにそれぞれ検査対象のＯＳＳを入力し、脆弱性の検知精度を適合率（パッチ適用前関数と検知したうち、正しく検知することができている割合）と、再現率（パッチ適用前関数と漏れなく検知したうち、正しく検知することができている割合）とにより評価した例について説明する。なお、前述の適合率と再現率とは、どちらも値が１に近いほど高精度に脆弱性を検知できていることが示される。
　なお、実験データの概要として、検査対象のＯＳＳは、「ＭＯＶＥＲＹ」により検査可能である８種のＯＳＳ（２０２３／２／１の最新バージョン）であり、各方式によりそれぞれ入力が行われた。また、脆弱と判定するための正解情報として、１９９９－２０２３／２／１３までのＣＶＥ、ＮＶＤに報告されている脆弱コード情報を取得することにより行われた。そして、取得された脆弱コード情報の内訳として、パッチ適用前の関数群（Ｇｉｔ　ｄｉｆｆ結果で［－］の行を含み、［＋］の行は含まない状態の関数）が９６８６個であり、パッチ適用後の関数群（Ｇｉｔ　ｄｉｆｆ結果で［－］の行を含まず、［＋］の行を含んだ状態の関数）が９９３３個であった。
　ここで、図２を参照し、前述の実験で検査対象となったＯＳＳについて説明する。図２は、実施形態に係る検知装置による比較実験に使用された検査対象ソフトウェアを示す図である。図２に示す通り、「Redis」、「OpenMVG」、「Git」、「Crown」、「Emscripten」、「OpenCV」、「FFmpeg」、「Arangodb」の８種類のＯＳＳが、検査対象となったOSSであり、それぞれのＯＳＳについて、「Ｄｏｍａｉｎ」、「Ｖｅｒｓｉｏｎ」、「Ｓｉｚｅ」、「ＬＯＣ（Ｌｉｎｅ　Ｏｆ　Ｃｏｄｅ）：ソースコードに含まれている行数」、「Ｆｉｌｅ」、「Ｆｕｎｃｔｉｏｎ」が記載されている。
　続いて、図３を参照し、実験結果について説明する。図３は、実施形態に係る検知装置による比較実験の実験結果を示す図である。図３に示す通り、本実施例に係る検知装置１００は、「適合率：（Ａｖｅ）０．９５６」であり、「再現率：（Ａｖｅ）０．６７０」である。そして、この結果は、比較対象である「ＭＯＶＥＲＹ」、「ＶＵＤＤＹ」、「ＲｅＤｅＢｕｇ」のそれぞれの結果よりも高い値であることを示している。つまり、検知装置１００は、前述の３つの先行技術よりも高精度にソフトウェアの脆弱性を検知することができるといえる。
〔２．検知装置１００の構成〕
　次に、図４を参照し、図１に示した検知装置１００の構成を説明する。図４は、実施形態に係る検知装置の構成例を示すブロック図である。検知装置１００は、通信部１１０と制御部１２０と記憶部１３０とを有し、検知装置１００は、ネットワークＮを介して、外部の装置とそれぞれ互いに通信可能に接続される。
　通信部１１０は、例えば、ＮＩＣ（Network　Interface　Card）等によって実現される。通信部１１０は、ネットワークＮと接続され、外部の装置やデータベースと情報の送受信を行う。通信部１１０は、例えば、ＮＶＤの脆弱性情報データベースに登録されている脆弱性が報告されている関数の情報の取得や、脆弱性が検知されたファイルや関数等の情報を外部の情報処理装置に出力することを仲介する。
　記憶部１３０は、例えば、ＲＡＭ（Random　Access　Memory）やハードディスク等の記憶装置によって実現される。記憶部１３０は、制御部１２０による各種処理に必要なデータ及びプログラムを格納する。そして、検知装置１００の記憶部１３０は、本発明に密接に関連するものとして、関数情報記憶部１３１と、検知情報記憶部１３２とを有する。
　関数情報記憶部１３１は、脆弱性が報告されているソースコードについての情報を記憶する。例えば、関数情報記憶部１３１は、ＮＶＤデータベースに掲載されているＣＶＥ番号に紐づく脆弱性情報から取得されたソースコードを、パッチ適用前とパッチ適用後に分類して、それぞれ記憶する。
　検知情報記憶部１３２は、後述する判定部１２２によって脆弱であると判定された関数についての情報を記憶する。例えば、検知情報記憶部１３２は、後述する判定部１２２により脆弱であると判定された関数名とそのファイル名、パッチ適用前後の類似度、ＣＶＥ番号等の情報を記憶する。
　ここで、図５を参照し、関数情報記憶部１３１及び検知情報記憶部１３２に記憶されるデータについて説明する。図５は、実施形態に係る検知装置に記憶されるデータの一例を示す図である。
　図５（Ａ）は、関数情報記憶部１３１に記憶されるデータの具体例であり、ＣＶＥ番号ごとに、パッチ適用前のソースコードとパッチ適用後のソースコードとが区別されて記憶されることが示されている。また、図５（Ｂ）は、検知情報記憶部１３２に記憶されるデータの具体例であり、「関数名：ｂ＿ｕｎｐａｃｋ」、「ファイル名：ｓａｍｐｌｅ」、「類似度（適用前）：０．９５３１２」、「類似度（適用後）０．７８１２５」、「ＣＶＥ番号：ＣＶＥ－２０１８－１１２１９」といった、脆弱であると判定された関数についての情報が、関数ごとに記憶されることが示されている。
　図４の説明に戻る。制御部１２０は、ＣＰＵ（Central　Processing　Unit）やＭＰＵ（Micro　Processing　Unit）等によって、装置内部の記憶装置に記憶されている各種プログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部１２０は、例えば、ＡＳＩＣ（Application　Specific　Integrated　Circuit）やＦＰＧＡ（Field　Programmable　Gate　Array）などの集積回路により実現される。制御部１２０は、取得部１２１と、判定部１２２とを有し、必要に応じて、前処理部１２３と、格納部１２４とを有してもよい。
　取得部１２１は、脆弱性を有するソフトウェアの関数について、パッチの適用前の関数のソースコードと、パッチの適用後の関数のソースコードとのうち、少なくともいずれか一つを取得する。また、取得部１２１は、パッチの適用前の関数のソースコードと、パッチの適用後の関数のソースコードとを取得するようにしてもよい。
　例えば、取得部１２１は、ネットワークＮを介して、ＮＶＤの脆弱性情報データベースから取得した最新のＣＶＥ番号から、ＣＶＥ番号に対応するＯＳＳ名を特定し、ＣＶＥ番号に紐づくコミット情報から脆弱性を有するコードをクローンすることによりソースコードを取得する。
　ここで、取得部１２１は、例えば、コミット情報から、パッチを適用する前後のどちらか一つ又はその両方のソースコードを抽出し、一つの関数ごとにパッチ適用前のソースコードと、パッチ適用後のソースコードとを区別して、関数情報記憶部１３１に格納する。
　判定部１２２は、取得部１２１によって取得されたソースコードに含まれる関数と、検査対象のソフトウェアの関数のソースコードに含まれる関数とから集合間類似度算出アルゴリズムにより、それぞれ作成された特徴ベクトルを用いて、当該特徴ベクトル同士の類似度を算出し、当該類似度に基づき、検査対象のソフトウェアに含まれる関数が脆弱であるか否かを判定する。
　例えば、判定部１２２は、関数情報記憶部１３１に記憶されている情報を参照し、それぞれのソースコードに含まれる関数から、集合間類似度算出アルゴリズムを適用することにより作成された特徴ベクトルを用いて、パッチ適用前の関数の特徴ベクトルまたはパッチ適用後の関数の特徴ベクトルと、検査対象のソフトウェアに含まれる関数の特徴ベクトルとの一致確率（共通要素の割合）を、特徴ベクトル同士の類似度として算出する。
　その後、判定部１２２は、例えば、算出された類似度と予め設定された閾値とを比較することにより、パッチ適用前の関数との類似度が閾値以上である場合、または、パッチ適用後の関数との類似度が閾値以下である場合に、検査対象のソフトウェアに含まれる関数が脆弱であると判定する。
　ここで、前述の集合間類似度算出アルゴリズムとは、２つの集合同士の類似度（一致度）を算出するアルゴリズムであり、例えば、Ｊａｃｃａｒｄ係数やｂ－ｂｉｔ　ｍｉｎｈａｓｈといった手法が挙げられる。本実施例において、集合間類似度算出アルゴリズムは、ソースコードに含まれる関数のトークンや論理ブロック、各行をハッシュ化したものの一部を要素とした集合を特徴ベクトルとして作成し、作成した特徴ベクトル同士の一致度を算出する。
　また、判定部１２２は、パッチ適用前の関数の特徴ベクトルと検査対象のソフトウェアの関数の特徴ベクトルとの類似度が所定の閾値以上であり、かつ、パッチ適用前の関数の特徴ベクトルと検査対象のソフトウェアの関数の特徴ベクトルとの類似度が、パッチ適用後の関数の特徴ベクトルと検査対象のソフトウェアの関数の特徴ベクトルとの類似度よりも高い場合に、検査対象ソフトウェアに含まれる関数が脆弱であると判定してもよい。
　例えば、判定部１２２は、まず、検査対象のソフトウェアに含まれる関数の特徴ベクトルについて、パッチ適用前の関数の特徴ベクトルとの類似度と予め設定された閾値とを比較する。その後、判定部１２２は、例えば、類似度が閾値以上となった関数に対して、パッチ適用前の関数の特徴ベクトルとの類似度と、パッチ適用後の関数の特徴ベクトルとの類似度との大小を比較し、パッチ適用前の関数の特徴ベクトルとの類似度の方が大きい場合に、検査対象のソフトウェアに含まれる関数が脆弱であると判定する。
　前処理部１２３は、ソースコードにおける関数が記述された部分の各行をハッシュ化し、予め設定されたシード値の数のハッシュ値それぞれにおける所定数の下位ビットを要素とする集合を特徴ベクトルとして作成する。
　例えば、前処理部１２３は、まず、関数情報記憶部１３１に記憶された情報を参照し、ソースコードにおける関数記述部を抽出する。そして、前処理部１２３は、例えば、関数内のパラメータをＰＡＲＡＭ、型名をＤＴＹＰＥ、変数名をＬＶＡＬに置換することにより抽象化を行う。続いて、前処理部１２３は、例えば、抽象化した関数記述部を空白、タブ、コメントを除去することにより、標準化する。
　その後、前処理部１２３は、例えば、関数記述部の各行と予め設定されたシード値とをハッシュ化し、最小ハッシュ値のみを記録することにより、シード値の数の最小ハッシュ値列を作成する。そして、前処理部１２３は、例えば、各ハッシュ値の下位ｂ（所定数）－ｂｉｔを要素とする集合であるｂ－ｂｉｔ　ｍｉｎｈａｓｈの特徴ベクトルを作成する。つまり、前処理部１２３は、前述の一連の処理を行うことにより、集合間類似度算出アルゴリズムであるｂ－ｂｉｔ　ｍｉｎｈａｓｈに対応する特徴ベクトルを作成する。
　ここで、図６を参照し、前処理部１２３により作成されたｂ－ｂｉｔ　ｍｉｎｈａｓｈの特徴ベクトルについて説明する。図６は、実施形態に係る特徴ベクトルの具体例について説明する図である。図６の例では、シードの設定値が「１２８」であり、各ハッシュ値の下位１ｂｉｔを要素とする特徴ベクトルが示されている。例えば、前処理部１２３は、図６に示すように、各関数をシード値の数「１２８」でそれぞれ下位「１ｂｉｔ」のみを記録することにより、特徴ベクトルを作成する。
　図４の説明に戻る。また、前処理部１２３は、ソースコードにおける関数が記述された部分に含まれるそれぞれのトークンを要素とする集合を特徴ベクトルとして作成する。例えば、前処理部１２３は、ソースコードについて、前述の関数記述部の抽出処理から標準化処理までを行った後、関数に含まれるトークンを要素とする集合を、関数の特徴ベクトルとして作成する。なお、本実施例において、前述のトークンは、ソースコードにおける最小単位の構成要素を指し、関数記述部に記載されたそれぞれの演算子やキーワードを指す。
　さらに、前処理部１２３は、ソースコードにおける関数が記述された部分に含まれるそれぞれの論理ブロックを要素とする集合を特徴ベクトルとして作成する。例えば、前処理部１２３は、前述の関数記述部の抽出処理から標準化処理までを行った後、関数に含まれる論理ブロックを要素とする集合を、関数の特徴ベクトルとして作成する。なお、本実施例において、論理ブロックは、ソースコードにおける関数記述部に記載された一定数の行や制御文ブロックを指す。
　格納部１２４は、判定部１２２によって脆弱な関数と判定された関数に関する情報を記憶部１３０に格納する。例えば、格納部１２４は、前述の判定部１２２によって脆弱と判定された関数の関数名やファイル名、パッチ適用前またはパッチ適用後のどちらか一方又はその両方の類似度の値、ＣＶＥ番号等を、検知情報記憶部１３２に格納する。
〔３．検知処理の具体例〕
　ここで、図７から図１０を参照し、検知装置１００による検知処理の具体例について説明する。図７から図１０は、実施形態に係る検知処理の具体例を示す図である。まず、図７を参照し、集合間類似度算出アルゴリズムとしてｂ－ｂｉｔ　ｍｉｎｈａｓｈを用いた場合の処理の具体例について説明する。なお、図７の例では、下位１ｂｉｔにより特徴ベクトルを作成すると設定されているものとする。
　まず、取得部１２１は、ＮＶＤの脆弱性情報データベースから、ＣＶＥ番号とそれに紐づくソースコードを取得して、パッチ適用前のソースコードとパッチ適用後のソースコードとを取得する。その後、前処理部１２３は、取得されたソースコードのそれぞれに対して、１－ｂｉｔｍｉｎｈａｓｈの特徴ベクトルを作成して、パッチ適用前の関数の特徴ベクトル［１，０，１，１・・・］を「脆弱な関数ＤＢ」に格納し、パッチ適用後の関数の特徴ベクトル［１，１，０，０・・・］を「パッチ適用済み関数ＤＢ」に格納することにより、比較対象の特徴ベクトルを事前に作成する。
　その後、前処理部１２３は、外部から入力された検査対象ＯＳＳについても、ソースファイルに含まれる関数（関数１、関数２・・・）ごとに特徴ベクトル（［１，０，１，１・・・］、［０，０，１，０・・・］・・・）を作成する。その後、判定部１２２は、検査対象のソフトウェアに含まれる各関数の特徴ベクトルについて、それぞれのＤＢの特徴ベクトルと総当たりで類似度（一致確率）を算出する。なお、脆弱な関数ＤＢの特徴ベクトルとの類似度をＳとし、パッチ適用済み関数の特徴ベクトルとの類似度をＳ´とする。
　具体的には、「（一致するビットの数／ｂ－ｂｉｔｍｉｎｈａｓｈの特徴ベクトルの長さ―１／２）×２」の式により類似度が求められる。なお、一致するビットの数は、ｂ－ｂｉｔｍｉｎｈａｓｈの特徴ベクトルの長さから異なるビットの数を引いた数で表され、特徴ベクトルの長さはシード値に該当する。また、異なるビットの数は、ＸＯＲ演算で求められ、上記式中の１／２は、０か１の誤り確率を示す。ここで、例えば、特徴ベクトルの長さであるシード値が「１２８」と設定され、検査対象のソフトウェアの関数に対し、脆弱な関数ＤＢ中に特徴ベクトルの一致するビット数が「１２５」となる関数が存在する場合には、類似度Ｓは「（１２５／１２８－１／２）×２＝０．９５３１２５」と算出される。
　同様に、検査対象のソフトウェアの関数に対し、パッチ適用済み関数ＤＢ中に特徴ベクトルの一致するビット数が「１１４」となる関数が存在する場合には、その類似度は（１１４／１２８－１／２）×２＝０．７８１２５と算出される。その後、判定部１２２は、「類似度Ｓ：９５％」が閾値である「８０％」よりも大きい値であるため、「類似度Ｓ：９５％」と、「類似度Ｓ´：７８％」とを比較する。その結果、類似度Ｓの方が高い値であるため、判定部１２２は、検査対象のソフトウェアに含まれる関数が脆弱な関数であると判定する。
　続いて、図８を参照し、集合間類似度算出アルゴリズムとしてｂ－ｂｉｔ　ｍｉｎｈａｓｈを用いて、下位２ｂｉｔにより特徴ベクトルを作成する場合の処理の具体例について説明する。図８の例についても、図７の例と同様に、関数の各行を要素とみなして、ｂ－ｂｉｔｍｉｎｈａｓを適用して特徴ベクトルを作成して類似度を算出するが、ハッシュ値の下位２ｂｉｔから特徴ベクトルを作成する点が図７の例と異なる。
　図８の例では、前処理部１２３は、入力された検査対象のソフトウェアに含まれる関数記述部について、「“redisReply　*r,　*parent;”」や、「“r=　createReplyObject(task->type);”」のように１行ごとにまとめる。その後、前処理部１２３は、まとめられた各行を要素とみなしてハッシュ化し、[２４，３６，１０，９０，３３，７８，５３,・・・]のように下位２ｂｉｔを記録することにより、特徴ベクトルを作成する。
　次に、図９を参照して、集合間類似度算出アルゴリズムとして、Ｊａｃｃａｒｄ係数を使用した場合の処理の具体例について説明する。図９の例では、前処理部１２３は、入力された検査対象のソフトウェアに含まれる関数記述部について、「“redisReply”」や、「“*r”」のようにトークンごとにまとめ、各トークンを要素とみなす集合である特徴ベクトルを作成する。
　その後、判定部１２２は、作成された特徴ベクトルについて、集合間類似度算出アルゴリズムの一つであるＪａｃｃａｒｄ係数を用いて、特徴ベクトル同士の類似度を算出する。ここで、Ｊａｃｃａｒｄ係数は、２つの集合間の積集合／和集合によって算出され、２つの集合間における要素の一致度を示す計算手法である。
　続いて、図１０を参照し、集合間類似度算出アルゴリズムとしてＪａｃｃａｒｄ係数を用いて、論理ブロックにより特徴ベクトルを作成する場合の処理の具体例について説明する。図１０の例についても、図９の例と同様に、Ｊａｃｃａｒｄ係数を用いて特徴ベクトルを作成して類似度を算出するが、関数記述部の論理ブロックを要素として特徴ベクトルを作成する点が図９の例と異なる。
　図１０の例では、前処理部１２３は、入力された検査対象のソフトウェアに含まれる関数記述部について、「“redisReply　*r,　*parent;”」や、「“if　(r　==　NULL)　return　NULL;”」のように論理ブロックごとにまとめ、各論理ブロックを要素とみなす集合である特徴ベクトルを作成する。
　次に図１１を参照し、判定処理の結果の出力例について説明する。図１１は、実施形態に係る検知処理により出力される情報の具体例について説明する図である。図１１に示す通り、検知装置１００は、脆弱と判定された関数について、関数名とファイル名とパッチ適用前後の類似度とＣＶＥ番号とを出力する。図１１の例では、「関数名：ｂ＿ｕｎｐａｃｋ」、「ファイル名：ｓａｍｐｌｅ」、「パッチ適用前の類似度：０．９５３１２」、パッチ適用後の類似度：０．７８１２５」、「ＣＶＥ番号：ＣＶＥ－２０１８－１１２１９」がそれぞれ示されている。
〔４．検知処理の一例〕
　次に、図１２を参照して、検知装置１００による検知処理の流れについて説明する。図１２は、実施形態に係る検知処理の流れの一例を示すフローチャートである。なお、図１２に示すフローチャートに記載された各処理工程は、処理の順番が前後してもよいものとする。まず、取得部１２１は、既知の脆弱性コードについて、修正パッチの適用前後の関数のソースコードをそれぞれ取得する（ステップＳ１０１）。
　次に、前処理部１２３は、検査対象のソフトウェアを受け付ける（ステップＳ１０２）。検査対象のソフトウェアを受け付けた場合には（ステップＳ１０２；Ｙｅｓ）、前処理部１２３は、修正パッチ適用前後の関数のソースコードと、検査対象のソフトウェアの関数のソースコードとについて、特徴ベクトルをそれぞれ作成する（ステップＳ１０３）。一方、検査対象のソフトウェアを受付けていない場合には（ステップＳ１０２；Ｎｏ）、前処理部１２３は、検査対象のソフトウェアを受付けるまで待機する。
　そして、判定部１２２は、パッチ適用前の特徴ベクトルと検査対象のソフトウェアの特徴ベクトルとの類似度が閾値以上であるか否かを判定する（ステップＳ１０４）。パッチ適用前の特徴ベクトルと検査対象のソフトウェアの特徴ベクトルとの類似度が閾値以上である場合には（ステップＳ１０４；Ｙｅｓ）、判定部１２２は、パッチ適用前との類似度がパッチ適用後との類似度以上であるか否かを判定する（ステップＳ１０５）。一方で、パッチ適用前の特徴ベクトルと検査対象のソフトウェアの特徴ベクトルとの類似度が閾値以上でない場合には（ステップＳ１０４；Ｎｏ）、検知装置１００は工程を終了する。
　そして、Ｓ１０５の処理の後、パッチ適用前との類似度がパッチ適用後との類似度以上である場合には（ステップＳ１０５；Ｙｅｓ）、判定部１２２は、類似度を比較した特徴ベクトルに対応する関数を脆弱な関数と判定する（ステップＳ１０６）。一方で、パッチ適用前との類似度がパッチ適用後との類似度以上でない場合には（ステップＳ１０５；Ｎｏ）、検知装置１００は工程を終了する。そして、Ｓ１０６の処理の後、格納部１２４は、脆弱な関数に関する情報を記憶部１３０に格納し（ステップＳ１０７）、検知装置１００は工程を終了する。
〔５．実施形態の効果〕
　前述してきたように、本実施形態に係る検知装置１００は、取得部１２１と判定部１２２とを有する。取得部１２１は、脆弱性を有するソフトウェアの関数について、パッチの適用前の関数のソースコードと、パッチの適用後の関数のソースコードとのうち、少なくともいずれか一つを取得する。
　判定部１２２は、取得部１２１によって取得されたソースコードに含まれる関数と、検査対象のソフトウェアの関数のソースコードに含まれる関数とから集合間類似度算出アルゴリズムにより、それぞれ作成された特徴ベクトルを用いて、当該特徴ベクトル同士の類似度を算出し、当該類似度に基づき、検査対象のソフトウェアに含まれる関数が脆弱であるか否かを判定する。
　これにより、検知装置１００は、関数の一部に基づくデータを構成要素とする集合（特徴ベクトル）を、検査対象の関数と比較対象の関数とについてそれぞれ作成して、集合同士の類似度を算出することにより、編集が行われたソフトウェアであっても、適切に脆弱性を検知することができるという効果を奏する。
　また、検知装置１００の取得部１２１は、パッチの適用前の関数のソースコードと、パッチの適用後の関数のソースコードとを取得し、判定部１２２は、パッチ適用前の関数の特徴ベクトルと検査対象のソフトウェアの関数の特徴ベクトルとの類似度が所定の閾値以上であり、かつ、パッチ適用前の関数の特徴ベクトルと検査対象のソフトウェアの関数の特徴ベクトルとの類似度が、パッチ適用後の関数の特徴ベクトルと検査対象のソフトウェアの関数の特徴ベクトルとの類似度よりも高い場合に、検査対象ソフトウェアに含まれる関数が脆弱であると判定する。
　これにより、検知装置１００は、パッチ適用前の脆弱な関数との類似度が閾値を上回ったもののみについて、パッチ適用前後で類似度の大きさを比較することにより、パッチ適用前との類似度が一定以上であっても、パッチ適用後との類似度の方が高い関数を、既に脆弱性が解消された関数とみなし、誤って脆弱な関数と検知することを防ぐことができるという効果を奏する。
　また、検知装置１００は、前処理部１２３をさらに有する。前処理部１２３は、ソースコードにおける関数が記述された部分の各行をハッシュ化し、予め設定されたシード値の数のハッシュ値それぞれにおける所定数の下位ビットを要素とする集合を特徴ベクトルとして作成する。
　これにより、検知装置１００は、検査対象のソフトウェアに含まれる脆弱性を有する関数について、関数の各行を要素とする集合（特徴ベクトル）を作成することにより、高速で軽量な集合間類似度算出アルゴリズムであるｂ-ｂｉｔｍｉｎｈａｓｈを適用して、適切に脆弱性を検知することができるという効果を奏する。
　さらに、検知装置１００の前処理部１２３は、ソースコードにおける関数が記述された部分に含まれるそれぞれのトークンを要素とする集合を特徴ベクトルとして作成する。これにより、検知装置１００は、それぞれの関数について、トークン（ワード単位）を要素とする集合を作成することにより、より細かい要素の一致度を類似度として算出するため、精度の高い脆弱性検知を行うことができるという効果を奏する。
　また、検知装置１００の前処理部１２３は、ソースコードにおける関数が記述された部分に含まれるそれぞれの論理ブロックを要素とする集合を特徴ベクトルとして作成する。これにより、検知装置１００は、それぞれの関数について、論理ブロック（一定数の行または制御文ブロック）を要素とする集合を作成することにより、各集合が有する要素の数が比較的少ない条件で脆弱性検知を行うことができるという効果を奏する。
　そして、検知装置１００は、格納部１２４をさらに有する。格納部１２４は、判定部によって脆弱な関数と判定された関数に関する情報を記憶部１３０に格納する。これにより、検知装置１００は、検査対象のソフトウェアに含まれる各関数の中で、脆弱性を有すると判定された関数の検知結果等をユーザに容易に把握させることができるという効果を奏する。
〔６．システム構成等〕
　上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の一部を手動的に行うこともできる。あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。
　また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部又は任意の一部が、ＣＰＵ及び当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
　例えば、図４に示した記憶部１３０の一部又は全部は、検知装置１００によって保持されるのではなく、ストレージサーバ等に保持されてもよい。この場合、検知装置１００は、ストレージサーバにアクセスすることで、各種情報を取得する。
〔７．ハードウェア構成〕
　図１３は、ハードウェア構成の一例を示す図である。上述してきた実施形態に係る検知装置１００は、例えば図１３に示すような構成のコンピュータ１０００によって実現される。
　図１３は、検知プログラムを実行するコンピュータの一例を示す図である。コンピュータ１０００は、例えば、メモリ１０１０、ＣＰＵ１０２０を有する。また、コンピュータ１０００は、ハードディスクドライブインタフェース１０３０、ディスクドライブインタフェース１０４０、シリアルポートインタフェース１０５０、ビデオアダプタ１０６０、ネットワークインタフェース１０７０を有する。これらの各部は、バス１０８０によって接続される。
　メモリ１０１０は、ＲＯＭ（Read　Only　Memory）１０１１及びＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic　Input　Output　System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１０４１に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブ１０４１に挿入される。シリアルポートインタフェース１０５０は、例えばマウス１１１０、キーボード１１２０に接続される。ビデオアダプタ１０６０は、例えばディスプレイ１１３０に接続される。
　ハードディスクドライブ１０９０は、例えば、ＯＳ（Operating　System）１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち検知装置１００の各処理を規定するプログラムは、コンピュータ１０００により実行可能なコードが記述されたプログラムモジュール１０９３として実装される。プログラムモジュール１０９３は、例えばハードディスクドライブ１０９０に記憶される。例えば、検知装置１００における機能構成と同様の処理を実行するためのプログラムモジュール１０９３が、ハードディスクドライブ１０９０に記憶される。なお、ハードディスクドライブ１０９０は、ＳＳＤ（Solid　State　Drive）により代替されてもよい。
　また、上述した実施の形態の処理で用いられる設定データは、プログラムデータ１０９４として、例えばメモリ１０１０やハードディスクドライブ１０９０に記憶される。そして、ＣＰＵ１０２０が、メモリ１０１０やハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して実行する。
　なお、プログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０９０に記憶される場合に限らず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ１０４１等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、プログラムモジュール１０９３及びプログラムデータ１０９４は、ネットワーク（ＬＡＮ、ＷＡＮ等）を介して接続された他のコンピュータに記憶されてもよい。そして、プログラムモジュール１０９３及びプログラムデータ１０９４は、他のコンピュータから、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。
　１００　検知装置
　１１０　通信部
　１２０　制御部
　１２１　取得部
　１２２　判定部
　１２３　前処理部
　１２４　格納部
　１３０　記憶部
　１３１　関数情報記憶部
　１３２　検知情報記憶部

Claims (8)

  1. 　脆弱性を有するソフトウェアの関数について、パッチの適用前の関数のソースコードと、前記パッチの適用後の関数のソースコードとのうち、少なくともいずれか一つを取得する取得部と、
    　前記取得部によって取得されたソースコードに含まれる関数と、検査対象のソフトウェアの関数のソースコードに含まれる関数とから集合間類似度算出アルゴリズムにより、それぞれ作成された特徴ベクトルを用いて、当該特徴ベクトル同士の類似度を算出し、当該類似度に基づき、前記検査対象のソフトウェアに含まれる関数が脆弱であるか否かを判定する判定部と、
    　を有することを特徴とする検知装置。
  2. 　前記取得部は、前記パッチの適用前の関数のソースコードと、前記パッチの適用後の関数のソースコードとを取得し、
    　前記判定部は、前記パッチの適用前の関数の特徴ベクトルと前記検査対象のソフトウェアの関数の特徴ベクトルとの類似度が所定の閾値以上であり、かつ、前記パッチの適用前の関数の特徴ベクトルと前記検査対象のソフトウェアの関数の特徴ベクトルとの類似度が、前記パッチの適用後の関数の特徴ベクトルと前記検査対象のソフトウェアの関数の特徴ベクトルとの類似度よりも高い場合に、前記検査対象のソフトウェアに含まれる関数が脆弱であると判定する、
    　ことを特徴とする請求項１に記載の検知装置。
  3. 　ソースコードにおける関数が記述された部分の各行をハッシュ化し、予め設定されたシード値の数のハッシュ値それぞれにおける所定数の下位ビットを要素とする集合を前記特徴ベクトルとして作成する前処理部をさらに有する
    　ことを特徴とする請求項１に記載の検知装置。
  4. 　ソースコードにおける関数が記述された部分に含まれるそれぞれのトークンを要素とする集合を前記特徴ベクトルとして作成する前処理部をさらに有する
    　ことを特徴とする請求項１に記載の検知装置。
  5. 　ソースコードにおける関数が記述された部分に含まれるそれぞれの論理ブロックを要素とする集合を前記特徴ベクトルとして作成する前処理部をさらに有する
    　ことを特徴とする請求項１に記載の検知装置。
  6. 　前記判定部によって脆弱な関数と判定された前記関数に関する情報を記憶部に格納する格納部をさらに有する
    　ことを特徴とする請求項１に記載の検知装置。
  7. 　検知装置によって実行される検知方法であって、
    　脆弱性を有するソフトウェアの関数について、パッチの適用前の関数のソースコードと、前記パッチの適用後の関数のソースコードとのうち、少なくともいずれか一つを取得する取得工程と、
    　前記取得工程によって取得されたソースコードに含まれる関数と、検査対象のソフトウェアの関数のソースコードに含まれる関数とから集合間類似度算出アルゴリズムにより、それぞれ作成された特徴ベクトルを用いて、当該特徴ベクトル同士の類似度を算出し、当該類似度に基づき、前記検査対象のソフトウェアに含まれる関数が脆弱であるか否かを判定する判定工程と、
    　を含んだことを特徴とする検知方法。
  8. 　脆弱性を有するソフトウェアの関数について、パッチの適用前の関数のソースコードと、前記パッチの適用後の関数のソースコードとのうち、少なくともいずれか一つを取得する取得手順と、
    　前記取得手順によって取得されたソースコードに含まれる関数と、検査対象のソフトウェアの関数のソースコードに含まれる関数とから集合間類似度算出アルゴリズムにより、それぞれ作成された特徴ベクトルを用いて、当該特徴ベクトル同士の類似度を算出し、当該類似度に基づき、前記検査対象のソフトウェアに含まれる関数が脆弱であるか否かを判定する判定手順と、
    　をコンピュータに実行させるための検知プログラム。
PCT/JP2023/021570 2023-06-09 2023-06-09 検知装置、検知方法及び検知プログラム Ceased WO2024252676A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/JP2023/021570 WO2024252676A1 (ja) 2023-06-09 2023-06-09 検知装置、検知方法及び検知プログラム
JP2025525919A JPWO2024252676A1 (ja) 2023-06-09 2023-06-09

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2023/021570 WO2024252676A1 (ja) 2023-06-09 2023-06-09 検知装置、検知方法及び検知プログラム

Publications (1)

Publication Number Publication Date
WO2024252676A1 true WO2024252676A1 (ja) 2024-12-12

Family

ID=93795820

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2023/021570 Ceased WO2024252676A1 (ja) 2023-06-09 2023-06-09 検知装置、検知方法及び検知プログラム

Country Status (2)

Country Link
JP (1) JPWO2024252676A1 (ja)
WO (1) WO2024252676A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008046695A (ja) * 2006-08-11 2008-02-28 Kobe Univ 類似度評価プログラム、類似度評価装置及び類似度評価方法
WO2017061270A1 (ja) * 2015-10-09 2017-04-13 日本電信電話株式会社 脆弱性発見装置、脆弱性発見方法、および、脆弱性発見プログラム
JP2023031614A (ja) * 2021-08-25 2023-03-09 株式会社東芝 変更度計測装置、方法及びプログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008046695A (ja) * 2006-08-11 2008-02-28 Kobe Univ 類似度評価プログラム、類似度評価装置及び類似度評価方法
WO2017061270A1 (ja) * 2015-10-09 2017-04-13 日本電信電話株式会社 脆弱性発見装置、脆弱性発見方法、および、脆弱性発見プログラム
JP2023031614A (ja) * 2021-08-25 2023-03-09 株式会社東芝 変更度計測装置、方法及びプログラム

Also Published As

Publication number Publication date
JPWO2024252676A1 (ja) 2024-12-12

Similar Documents

Publication Publication Date Title
US11693962B2 (en) Malware clustering based on function call graph similarity
Zhang et al. Libid: reliable identification of obfuscated third-party android libraries
Wang et al. Orlis: Obfuscation-resilient library detection for android
JP6088713B2 (ja) 脆弱性発見装置、脆弱性発見方法、及び脆弱性発見プログラム
CN108268777B (zh) 一种利用补丁信息进行未知漏洞发现的相似性检测方法
CN103473346B (zh) 一种基于应用程序编程接口的安卓重打包应用检测方法
US20170372068A1 (en) Method to identify known compilers functions, libraries and objects inside files and data items containing an executable code
US20180089430A1 (en) Computer security profiling
CN111222137A (zh) 一种程序分类模型训练方法、程序分类方法及装置
US20070152854A1 (en) Forgery detection using entropy modeling
US20130160125A1 (en) Method and system for rapid signature search over encrypted content
CN112651028B (zh) 基于上下文语义和补丁验证的漏洞代码克隆检测方法
US11960597B2 (en) Method and system for static analysis of executable files
CN117940894A (zh) 用于检测代码克隆的系统和方法
CN114936366A (zh) 基于混合分析的恶意软件家族标签更正方法及装置
Breitinger et al. Evaluating detection error trade-offs for bytewise approximate matching algorithms
JP7315023B2 (ja) ルール生成装置およびルール生成プログラム
Hubballi et al. Detecting packed executable file: Supervised or anomaly detection method?
Namanya et al. Evaluation of automated static analysis tools for malware detection in Portable Executable files
Chen et al. IHB: A scalable and efficient scheme to identify homologous binaries in IoT firmwares
WO2024252676A1 (ja) 検知装置、検知方法及び検知プログラム
JP2022522383A (ja) 既知及び／又は未知のサイバーセキュリティ脅威の形態素解析によりデータ異常を検出するシステム及び方法
Rowe Identifying forensically uninteresting files in a large corpus.
RU101223U1 (ru) Система для быстрого обнаружения похожих объектов с использованием сверток
Akram et al. DroidSD: An Efficient Indexed Based Android Applications Similarity Detection Tool.

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23940773

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2025525919

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE