特表 2024-502379 脆弱なソフトウェアパッケージを選択及び発見するためのシステム及び方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-01-18

(54)【発明の名称】脆弱なソフトウェアパッケージを選択及び発見するためのシステム及び方法

(51)【国際特許分類】

   G06F 21/57 20130101AFI20240111BHJP

【ＦＩ】

G06F21/57 370

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2023541893

(86)(22)【出願日】2022-01-06

(85)【翻訳文提出日】2023-07-10

(86)【国際出願番号】 IB2022050099

(87)【国際公開番号】W WO2022149088

(87)【国際公開日】2022-07-14

(31)【優先権主張番号】17/145,893

(32)【優先日】2021-01-11

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

(71)【出願人】

【識別番号】523261827

【氏名又は名称】ツイストロック，リミテッド

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎 修

(72)【発明者】

【氏名】レヴィン，リロン

(72)【発明者】

【氏名】アドラー，アローン

(72)【発明者】

【氏名】クレトセルマン，マイケル

(72)【発明者】

【氏名】ストーペル，ディーマ

(57)【要約】

ソフトウェアパッケージの脆弱性を発見するためのシステム及び方法である。方法は、複数のソフトウェアパッケージのうちの少なくとも１つの潜在的に脆弱なソフトウェアパッケージにおける少なくとも１つの脆弱性の潜在的な発生源を識別することであって、各脆弱性の潜在的な発生源は、少なくとも１つの潜在的に脆弱なソフトウェアパッケージのうちの１つに対する変更である、ことと、少なくとも１つの潜在的に脆弱なソフトウェアパッケージの各々のデータに対して少なくとも１つの脆弱性識別ルールを選択及び適用することによって、複数のソフトウェアパッケージにおける少なくとも１つの脆弱性を識別することであって、少なくとも１つの潜在的に脆弱なソフトウェアパッケージの各々に対する少なくとも１つの脆弱性識別ルールは、潜在的に脆弱なソフトウェアパッケージに対するバージョン識別子の利用可能性に基づいて選択される、ことと、を含む。

【特許請求の範囲】

【請求項1】

ソフトウェアパッケージの脆弱性を発見するための方法であって、
複数のソフトウェアパッケージのうちの少なくとも１つの潜在的に脆弱なソフトウェアパッケージにおける少なくとも１つの脆弱性の潜在的な発生源を識別することであって、各脆弱性の潜在的な発生源は、前記少なくとも１つの潜在的に脆弱なソフトウェアパッケージのうちの１つに対する変更である、ことと、
前記少なくとも１つの潜在的に脆弱なソフトウェアパッケージの各々のデータに対して少なくとも１つの脆弱性識別ルールを選択及び適用することによって、前記複数のソフトウェアパッケージにおける少なくとも１つの脆弱性を識別することであって、前記少なくとも１つの潜在的に脆弱なソフトウェアパッケージの各々に対する前記少なくとも１つの脆弱性識別ルールは、前記潜在的に脆弱なソフトウェアパッケージに対するバージョン識別子の利用可能性に基づいて選択される、ことと、を含む、方法。

【請求項2】

ソフトウェアパッケージに対する前記選択された少なくとも１つの脆弱性識別ルールは、パッケージバージョンが前記ソフトウェアパッケージに対して利用可能であるときの第１のルールであり、前記第１のルールは、脆弱性を、前記ソフトウェアパッケージが、前記ソフトウェアパッケージに対する最新の変更命令に示されたバージョンよりも以前のバージョンであるパッケージバージョンを有することとして定義する、請求項１に記載の方法。

【請求項3】

ソフトウェアパッケージに対する前記選択された少なくとも１つの脆弱性識別ルールは、リリースバージョンが前記ソフトウェアパッケージに対して利用可能であるが、パッケージバージョンが前記ソフトウェアパッケージに対して利用可能でないときの第２のルールであり、前記第２のルールは、脆弱性を、前記ソフトウェアパッケージが、前記ソフトウェアパッケージに対する最新の変更命令の閾値期間内にないリリースバージョンを有することとして定義する、請求項２に記載の方法。

【請求項4】

ソフトウェアパッケージに対する前記選択された少なくとも１つの脆弱性識別ルールは、パッケージバージョンもリリースバージョンも前記ソフトウェアパッケージに対して利用可能でないときの第３のルールであり、前記第３のルールは、脆弱性を、前記ソフトウェアパッケージが、前記ソフトウェアパッケージに対するパッケージマネージャによって命令された最新の変更の閾値期間内にない作成時間を有することとして定義する、請求項３に記載の方法。

【請求項5】

前記少なくとも１つの脆弱性の潜在的な発生源を識別することは、変更命令メッセージを分析することと、少なくとも１つの所定のメッセージを追跡することと、セキュリティ関連キーワードのコードコメントを分析することと、リリース日のリリースノートを分析することと、バージョンインジケータを更新する変更後に発生するファイルの変更に基づいて脆弱性を推論することと、のうちの少なくとも１つをさらに含む、請求項１に記載の方法。

【請求項6】

複数のソフトウェアパッケージリポジトリの他の各ソフトウェアリポジトリに記憶されたソフトウェアパッケージと比較した、前記複数のソフトウェアパッケージリポジトリの各々に記憶されたソフトウェアパッケージの相対的な使用量に基づいて、前記複数のソフトウェアパッケージリポジトリの中から少なくとも１つのソフトウェアパッケージリポジトリを選択することであって、前記複数のソフトウェアパッケージは、前記選択された少なくとも１つのソフトウェアパッケージリポジトリに記憶されている、ことをさらに含む、請求項１に記載の方法。

【請求項7】

前記複数のソフトウェアパッケージリポジトリの中から前記少なくとも１つのソフトウェアパッケージリポジトリを選択することは、
ユーザデータを分析して、前記複数のソフトウェアパッケージリポジトリの各々に対するソフトウェアパッケージの使用頻度を決定することであって、前記少なくとも１つのソフトウェアパッケージリポジトリの各々は、前記複数のソフトウェアパッケージリポジトリの中から最も高いソフトウェアパッケージの使用頻度を有する、ことを含む、請求項６に記載の方法。

【請求項8】

前記複数のソフトウェアパッケージリポジトリの中から前記少なくとも１つのソフトウェアパッケージリポジトリを選択することは、
パッケージ依存性マニフェストのために前記複数のソフトウェアパッケージリポジトリを再帰的にクローリングすることと、
前記複数のソフトウェアパッケージリポジトリの各々に対して、前記ソフトウェアパッケージリポジトリに記憶された各ソフトウェアパッケージに依存するソフトウェアパッケージの数に基づいて、前記ソフトウェアパッケージリポジトリの相対的な使用量を決定することと、をさらに含む、請求項６に記載の方法。

【請求項9】

前記少なくとも１つの識別された脆弱性は、前記複数のソフトウェアパッケージの中からの少なくとも１つの脆弱なソフトウェアパッケージに関連付けられており、
前記識別された少なくとも１つの脆弱性に基づいて依存関係グラフを生成することであって、前記依存関係グラフは、ソフトウェアパッケージ間の複数の依存関係を示し、前記複数の依存関係は、前記少なくとも１つの脆弱なソフトウェアパッケージに対する少なくとも１つの依存関係を含む、ことをさらに含む、請求項１に記載の方法。

【請求項10】

処理回路にプロセスを実行させるための命令を記憶した非一時的なコンピュータ可読媒体であって、前記プロセスは
複数のソフトウェアパッケージのうちの少なくとも１つの潜在的に脆弱なソフトウェアパッケージにおける少なくとも１つの脆弱性の潜在的な発生源を識別することであって、各脆弱性の潜在的な発生源は、前記少なくとも１つの潜在的に脆弱なソフトウェアパッケージのうちの１つに対する変更である、ことと、
前記少なくとも１つの潜在的に脆弱なソフトウェアパッケージの各々のデータに対して少なくとも１つの脆弱性識別ルールを選択及び適用することによって、前記複数のソフトウェアパッケージにおける少なくとも１つの脆弱性を識別することであって、前記少なくとも１つの潜在的に脆弱なソフトウェアパッケージの各々に対する前記少なくとも１つの脆弱性識別ルールは、前記潜在的に脆弱なソフトウェアパッケージに対するバージョン識別子の利用可能性に基づいて選択される、ことと、を含む、非一時的なコンピュータ可読媒体。

【請求項11】

ソフトウェアパッケージの脆弱性を発見するためのシステムであって、
処理回路と、
メモリと、を含み、前記メモリは、前記処理回路によって実行されるときに、前記システムに、
複数のソフトウェアパッケージのうちの少なくとも１つの潜在的に脆弱なソフトウェアパッケージにおける少なくとも１つの脆弱性の潜在的な発生源を識別することであって、各脆弱性の潜在的な発生源は、前記少なくとも１つの潜在的に脆弱なソフトウェアパッケージのうちの１つに対する変更である、ことと、
前記少なくとも１つの潜在的に脆弱なソフトウェアパッケージの各々のデータに対して少なくとも１つの脆弱性識別ルールを選択及び適用することによって、前記複数のソフトウェアパッケージにおける少なくとも１つの脆弱性を識別することであって、前記少なくとも１つの潜在的に脆弱なソフトウェアパッケージの各々に対する前記少なくとも１つの脆弱性識別ルールは、前記潜在的に脆弱なソフトウェアパッケージに対するバージョン識別子の利用可能性に基づいて選択される、ことと、行わせる命令を含む、システム。

【請求項12】

ソフトウェアパッケージに対する前記選択された少なくとも１つの脆弱性識別ルールは、パッケージバージョンが前記ソフトウェアパッケージに対して利用可能であるときの第１のルールであり、前記第１のルールは、脆弱性を、前記ソフトウェアパッケージが、前記ソフトウェアパッケージに対する最新の変更命令に示されたバージョンよりも以前のバージョンであるパッケージバージョンを有することとして定義する、請求項１１に記載のシステム。

【請求項13】

ソフトウェアパッケージに対する前記選択された少なくとも１つの脆弱性識別ルールは、リリースバージョンが前記ソフトウェアパッケージに対して利用可能であるが、パッケージバージョンが前記ソフトウェアパッケージに対して利用可能でないときの第２のルールであり、前記第２のルールは、脆弱性を、前記ソフトウェアパッケージが、前記ソフトウェアパッケージに対する最新の変更命令の閾値期間内にないリリースバージョンを有することとして定義する、請求項１２に記載のシステム。

【請求項14】

ソフトウェアパッケージに対する前記選択された少なくとも１つの脆弱性識別ルールは、パッケージバージョンもリリースバージョンも前記ソフトウェアパッケージに対して利用可能でないときの第３のルールであり、前記第３のルールは、脆弱性を、前記ソフトウェアパッケージが、前記ソフトウェアパッケージに対するパッケージマネージャによって命令された最新の変更の閾値期間内にない作成時間を有することとして定義する、請求項１３に記載のシステム。

【請求項15】

前記システムは、変更命令メッセージを分析することと、少なくとも１つの所定のメッセージを追跡することと、セキュリティ関連キーワードのコードコメントを分析することと、リリース日のリリースノートを分析することと、バージョンインジケータを更新する変更後に発生するファイルの変更に基づいて脆弱性を推論することと、のうちの少なくとも１つを行うようにさらに構成されている、請求項１１に記載のシステム。

【請求項16】

前記システムは、
複数のソフトウェアパッケージリポジトリの他の各ソフトウェアリポジトリに記憶されたソフトウェアパッケージと比較した、前記複数のソフトウェアパッケージリポジトリの各々に記憶されたソフトウェアパッケージの相対的な使用量に基づいて、前記複数のソフトウェアパッケージリポジトリの中から少なくとも１つのソフトウェアパッケージリポジトリを選択することを行うようにさらに構成されており、前記複数のソフトウェアパッケージは、前記選択された少なくとも１つのソフトウェアパッケージリポジトリに記憶されている、請求項１１に記載のシステム。

【請求項17】

前記システムは、
ユーザデータを分析して、前記複数のソフトウェアパッケージリポジトリの各々に対するソフトウェアパッケージの使用頻度を決定することを行うようにさらに構成されており、前記少なくとも１つのソフトウェアパッケージリポジトリの各々は、前記複数のソフトウェアパッケージリポジトリの中から最も高いソフトウェアパッケージの使用頻度を有する、請求項１６に記載のシステム。

【請求項18】

前記システムは、
パッケージ依存性マニフェストのために前記複数のソフトウェアパッケージリポジトリを再帰的にクローリングすることと、
前記複数のソフトウェアパッケージリポジトリの各々に対して、前記ソフトウェアパッケージリポジトリに記憶された各ソフトウェアパッケージに依存するソフトウェアパッケージの数に基づいて、前記ソフトウェアパッケージリポジトリの相対的な使用量を決定することと、を行うようにさらに構成されている、請求項１６に記載のシステム。

【請求項19】

前記少なくとも１つの識別された脆弱性は、前記複数のソフトウェアパッケージの中からの少なくとも１つの脆弱なソフトウェアパッケージに関連付けられており、前記システムは、
前記識別された少なくとも１つの脆弱性に基づいて依存関係グラフを生成することを行うようにさらに構成されており、前記依存関係グラフは、ソフトウェアパッケージ間の複数の依存関係を示し、前記複数の依存関係は、前記少なくとも１つの脆弱なソフトウェアパッケージに対する少なくとも１つの依存関係を含む、請求項１１に記載のシステム。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、２０２１年１月１１日に出願された米国特許出願第１７／１４５，８９３号の利益を主張するものであり、その内容は参照により本明細書に組み込まれる。

【0002】

本開示は、一般に、ソフトウェア脆弱性の検出に関連し、より具体的には、ソフトウェア脆弱性検出における脆弱性カバレッジの増加に関連する。

【背景技術】

【0003】

ソフトウェアベースの技術が日常生活をますます支配するにつれて、ソフトウェア脆弱性を検出及び修正することは、システムが通常機能するために重要になってきた。いくつかの既存のソリューションは、潜在的な脆弱性を特定するために、そのようなソフトウェアを使用してソフトウェア及びプロセスをレビューするように訓練された人間のオペレータを利用する。これらのプロセスには、コードの手作業によるレビュー（例えば、脆弱なソフトウェアパッケージを探すためにソフトウェアライブラリを手作業でクローリングする）、又はユーザから報告された問題を伴うことがある。しかし、これらのプロセスは、自動化されたソリューションと比較して非常に非効率的であり、ヒューマンエラーを受けやすく、一貫性のない結果をもたらす脆弱性が存在するかどうかについて主観的な判断を必要とすることが多い。

【0004】

ソフトウェア脆弱性をスキャンすることを伴う自動化されたソリューションがいくつか存在する。しかし、これらのソリューションでは、ソフトウェア脆弱性を正確に識別する際の大きな課題に直面している。特に、いくつかの自動化されたソリューションは、既に既知の問題をチェックすることができるが、これらのソリューションは、これまでのところ未知のソフトウェア、既存のソフトウェアの未知のバージョン、又は標準化されたフォーマットの何らかの形態を他の方法で欠いているソフトウェアを識別することが困難である。オペレーティングシステムの脆弱性の場合、ほとんどのメジャーなベンダーが既存のソリューションで利用できる一貫性のある標準フィードを提供するが、他のソフトウェアプロバイダは、一貫性のある標準フィードを提供しないことがある。これは、オープンソースソフトウェアパッケージ、又は単一の情報源を持たない他の任意のソフトウェアにとって特に問題となる可能性がある。

【0005】

したがって、上述の課題を克服するソリューションを提供することが有利であろう。

【発明の概要】

【0006】

本開示のいくつかの例示的な実施形態の概要は、以下のようである。この発明の概要は、そのような実施形態の基本的な理解を提供するように読者の便宜のために提供され、開示の幅を完全に定義するものではない。この発明の概要は、全ての企図された実施形態の広範な概観ではなく、全ての実施形態の主要な又は重要な要素を識別することも、任意の又は全ての態様の範囲を線引きすることも意図するものではない。唯一の目的は、１つ以上の実施形態のいくつかの概念を、後に提示されるより詳細な説明への序文として単純化された形態で提示することである。便宜上、「いくつかの実施形態」又は「特定の実施形態」という用語は、本明細書において、本開示の単一の実施形態又は複数の実施形態を指すために使用されてもよい。

【0007】

本明細書に開示される特定の実施形態は、ソフトウェアパッケージの脆弱性を発見するための方法を含む。方法は、複数のソフトウェアパッケージのうちの少なくとも１つの潜在的に脆弱なソフトウェアパッケージにおける少なくとも１つの脆弱性の潜在的な発生源を識別することであって、各脆弱性の潜在的な発生源は、少なくとも１つの潜在的に脆弱なソフトウェアパッケージのうちの１つに対する変更である、ことと、少なくとも１つの潜在的に脆弱なソフトウェアパッケージの各々のデータに対して少なくとも１つの脆弱性識別ルールを選択及び適用することによって、複数のソフトウェアパッケージにおける少なくとも１つの脆弱性を識別することであって、少なくとも１つの潜在的に脆弱なソフトウェアパッケージの各々に対する少なくとも１つの脆弱性識別ルールは、潜在的に脆弱なソフトウェアパッケージに対するバージョン識別子の利用可能性に基づいて選択される、ことと、を含む。

【0008】

本明細書に開示される特定の実施形態はまた、命令を記憶した非一時的なコンピュータ可読媒体を含み、命令は、処理回路に、複数のソフトウェアパッケージのうちの少なくとも１つの潜在的に脆弱なソフトウェアパッケージにおける少なくとも１つの脆弱性の潜在的な発生源を識別することであって、各脆弱性の潜在的な発生源は、少なくとも１つの潜在的に脆弱なソフトウェアパッケージのうちの１つに対する変更である、ことと、少なくとも１つの潜在的に脆弱なソフトウェアパッケージの各々のデータに対して少なくとも１つの脆弱性識別ルールを選択及び適用することによって、複数のソフトウェアパッケージにおける少なくとも１つの脆弱性を識別することであって、少なくとも１つの潜在的に脆弱なソフトウェアパッケージの各々に対する少なくとも１つの脆弱性識別ルールは、潜在的に脆弱なソフトウェアパッケージに対するバージョン識別子の利用可能性に基づいて選択される、ことと、を行わせるプロセスを実行させる。

【0009】

本明細書に開示される特定の実施形態はまた、ソフトウェアパッケージの脆弱性を発見するためのシステムを含む。システムは、処理回路と、メモリと、を含み、メモリは、処理回路によって実行されるときに、システムが、複数のソフトウェアパッケージのうちの少なくとも１つの潜在的に脆弱なソフトウェアパッケージにおける少なくとも１つの脆弱性の潜在的な発生源を識別することであって、各脆弱性の潜在的な発生源は、少なくとも１つの潜在的に脆弱なソフトウェアパッケージのうちの１つに対する変更である、ことと、少なくとも１つの潜在的に脆弱なソフトウェアパッケージの各々のデータに対して少なくとも１つの脆弱性識別ルールを選択及び適用することによって、複数のソフトウェアパッケージにおける少なくとも１つの脆弱性を識別することであって、少なくとも１つの潜在的に脆弱なソフトウェアパッケージの各々に対する少なくとも１つの脆弱性識別ルールは、潜在的に脆弱なソフトウェアパッケージに対するバージョン識別子の利用可能性に基づいて選択される、ことと、を行うように構成する命令を含む。

【図面の簡単な説明】

【0010】

本明細書に開示される主題は、明細書の最後において特許請求の範囲に特に指摘され、明確に請求される。開示される実施形態の前述及び他の目的、特徴、及び利点は、添付図面と併せて解釈される以下の詳細な説明から明らかになるであろう。

【0011】

【図1】様々な開示される実施形態を説明するために利用されるネットワーク図である。

【0012】

【図2】一実施形態によるソフトウェアパッケージにおける知らないソフトウェア脆弱性を発見するための方法を例示するフローチャートである。

【0013】

【図3】一実施形態による脆弱性の潜在的な発生源を識別するための方法を例示するフローチャートである。

【0014】

【図4】一実施形態によるソフトウェアパッケージを標準脆弱性識別子にマッピングするための方法を例示する例示的なフローチャートである。

【0015】

【図5】一実施形態による、脆弱性検出器の例示的な概略図である。

【発明を実施するための形態】

【0016】

本明細書に開示される実施形態は、本明細書における革新的教示の多くの有利な使用の例にすぎないことに留意することが重要である。一般に、本出願の明細書においてなされる記述は、特許請求の範囲に記載された様々な実施形態のいずれかを必ずしも限定するものではない。さらに、いくつかの記述は、いくつかの発明的特徴に適用されるが、他のものには適用されなくてもよい。一般に、別段の指示がない限り、一般性を失うことなく、単数の要素は複数であってもよく、逆もまた同様である。図面において、同様の数字はいくつかの図を通して同様の部分を指す。

【0017】

様々な開示される実施形態は、ソフトウェア脆弱性を検出するための方法及びシステムを含む。１つ以上のリポジトリが、分析のために選択されてもよい。各リポジトリは、ソフトウェアパッケージを記憶する。ソフトウェアパッケージに関連するデータに基づいて、選択されたリポジトリにおけるソフトウェアパッケージに対する変更の中から、１つ以上の脆弱性の潜在的な発生源が分析のために選択される。脆弱性の潜在的な発生源は、使用頻度、作成日、ソフトウェアパッケージがオープンソースであると知られているかどうか、それらの組み合わせなどの要因であるが、それらに限定されない要因に基づいてもよいルールを使用して識別される。

【0018】

一実施形態では、脆弱性の潜在的な発生源を識別することは、変更命令の問い合わせ及び解析をすること、特定のデベロッパを追跡すること、コードコメントを分析すること、リリースノートを分析すること、及びバージョン識別子に基づいて潜在的な脆弱性を推論することのうちのいずれか又は全てを含んでもよい。各変更命令は、データの一部分を変更するための命令であり、したがって、最終決定又は確認される変更を表す。変更命令は、コミット記述（本明細書では「コミット」とも呼ばれる）を含んでもよいが、これに限定されない。

【0019】

これらのステップの結果に基づいて、脆弱性の潜在的な発生源であるソフトウェアパッケージに対するセキュリティ関連の変更が識別される。セキュリティ関連の変更に対して一意の識別子が作成されてもよい。一意の識別子は、脆弱性を引き起こした特定の変更を後で調べることを可能にしながら、変更を匿名にするために利用されてもよい。このような変更の匿名化は、機密情報を保存するために重要となることがある。

【0020】

これらの変更によって引き起こされた脆弱性を識別し、したがって、これらの変更によって生じた脆弱なソフトウェアパッケージを識別するために、脆弱性識別ルールが、セキュリティ関連の変更の各々のデータに対して選択及び適用される。脆弱性識別ルールは、ソフトウェアパッケージを記憶しているソフトウェアリポジトリに対するバージョン識別子の利用可能性に基づいて選択されてもよい。例えば、第１のルールは、ソフトウェアリポジトリが、パッケージバージョンを有するときに選択されてもよく、第２のルールは、リポジトリが、リリースバージョンを有するが、パッケージバージョンを有さないときに選択されてもよく、第３のルールは、リポジトリが、ソフトウェアパッケージに対する任意のバージョン識別子を有さないときに選択されてもよい。異なるルールは、ソフトウェアパッケージが脆弱であると考えられる状況を定義してもよい。したがって、そのような脆弱性識別ルールを適用することは、所与のソフトウェアパッケージが脆弱であるかどうかを客観的に決定することを可能にする。

【0021】

識別された脆弱性のうちの１つを有する各ソフトウェアパッケージは、標準ソフトウェアパッケージ命名スキームの知られた名前にマッピングされてもよい。そのようなソフトウェアパッケージ命名スキームは、ＣＰＥ（Ｃｏｍｍｏｎ Ｐｌａｔｆｏｒｍ Ｅｎｕｍｅｒａｔｉｏｎ）であってもよいが、これに限定されない。ＣＰＥは、ソフトウェア脆弱性に利用され得る構造化命名スキームである。ＣＰＥは、ＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）の一般的な構文を利用し、正式な名前フォーマット、システムに対して名前をチェックするための方法、及び名前にテキストとテストをバインドするための記述フォーマットを含む。ＣＰＥはまた、ＣＰＥのための名前の合意されたリストを定義する辞書を利用する。

【0022】

識別された脆弱性のうちの１つを有する各ソフトウェアパッケージは、さらに、標準化されたソフトウェア脆弱性識別子、例えば、ＣＶＥ（Ｃｏｍｍｏｎ Ｖｕｌｎｅｒａｂｉｌｉｔｉｅｓ ａｎｄ Ｅｘｐｏｓｕｒｅ）ごとに定義された識別子にマッピングされてもよい。標準化されたソフトウェア脆弱性識別子へのソフトウェアパッケージのマッピングは、標準ソフトウェアパッケージ命名スキームの名前へのソフトウェアパッケージのマッピングに基づいてもよい。

【0023】

いくつかの実施形態では、依存性グラフが、識別された脆弱性に基づいて作成又は更新されてもよい。依存性グラフは、ソフトウェアパッケージ間の依存性を表すエッジによって接続されたソフトウェアパッケージを表すノードを含む。依存関係グラフは、脆弱であるとして識別されたソフトウェアパッケージを表すノードに対するメタデータも含む。その結果、そのような依存性グラフは、ソフトウェアパッケージ間の依存性によって引き起こされる脆弱性を識別することを可能にする。例えば、それ自体では脆弱でない第１のソフトウェアパッケージは、脆弱である第２のソフトウェアパッケージに依存していることがあり、その結果、第１のソフトウェアパッケージの第２のソフトウェアパッケージへの依存が脆弱性を表すことがある。

【0024】

開示される実施形態は、コード又はコメントの手動評価に依存せず、また既知の脆弱性に基づいて作成されたルールを必要としない、ソフトウェア脆弱性を検出するための自動化されたプロセスを提供する。開示される実施形態は、未知の脆弱性又は報告されているが既知の脆弱性と明確には一致しない脆弱性を識別するために利用され得る。したがって、開示される実施形態は、ヒューマンエラー又は一貫性のない結果を生じ得る主観的分析を必要とすることなく、既存の自動化された解決策よりも多くのソフトウェア脆弱性を検出することを可能にする。

【0025】

さらに、開示される実施形態は、脆弱性が正式に報告される前に、又は脆弱性が不適切に報告された場合でも、脆弱性を検出することを可能にすることができる。さらに、開示される実施形態は、脆弱性検出の客観性を改善する所定の基準に従って選択される脆弱性ルールを使用する。したがって、開示される実施形態は、偽陽性の数を有意に増加させることなくより多くのソフトウェア脆弱性が検出されるように、ソフトウェア脆弱性検出の精度を改善することを可能にする。

【0026】

さらに、開示される実施形態は、適切に識別されていない脆弱なソフトウェアパッケージを既知のソフトウェアパッケージに正確に一致させることを可能にする。この点に関して、ソフトウェアパッケージ名の標準化されたバージョンは、ソフトウェアパッケージの実際の名前（例えば、ソフトウェアパッケージのメタデータに示される名前）と一致しないことが多いことに留意する。非限定的な例として、パッケージの実際の名前は、「ｏｒｇ．ａｐａｃｈｅ．ｈｔｔｐｃｏｍｐｏｎｅｎｔｓ）＿ｈｔｔｐｃｌｉｅｎｔ」として示され得、一方、パッケージのＣＰＥ名は「ａｐａｃｈｅ：ｈｔｔｐｃｌｉｅｎｔ」であり得る。既存の自動化されたソリューションでは、パッケージをそれぞれの標準化された名前にマッピングすることができないため、変更が異なる発生源に由来するときに、特定のソフトウェアパッケージに対する変更を正確に識別できないことが多い。

【0027】

図１は、様々な開示される実施形態を説明するために利用される例示的なネットワーク図１００を示す。例示的なネットワーク図１００では、ソースリポジトリ１２０－１～１２０－Ｎ（以下、単に簡略化のために、個々にソースリポジトリ１２０と称し、まとめてソースリポジトリ１２０と称する）、脆弱性検出器１３０、及びユーザデバイス１４０が、ネットワーク１１０を介して通信可能に接続されている。ネットワーク１１０は、無線、セルラ又は有線ネットワーク、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、メトロエリアネットワーク（ＭＡＮ）、インターネット、ワールドワイドウェブ（ＷＷＷ）、同様のネットワーク、及びこれらの任意の組み合わせとすることができるが、これらに限定されない。

【0028】

ソースリポジトリ１２０の各々は、脆弱であり得るソフトウェアパッケージ（図示せず）を記憶している。ソースリポジトリ１２０の少なくともいくつかは、オープンソースソフトウェアパッケージを記憶するオープンソースリポジトリであってもよい。オープンソースソフトウェアパッケージは、標準化されたフォーマットを使用していないため、ソフトウェアパッケージの異なるフォーマットに関連付けられた所定のルールを使用して既知のソフトウェア脆弱性をすぐに特定することが可能ではないことがある。この目的のために、脆弱性識別子１３０が、本明細書に説明されるように、ソフトウェア脆弱性を識別するように構成されている。このような脆弱性の識別により、未知の脆弱性、そうでなければ不適切に報告された脆弱性を識別することが可能となり、オープンソースソフトウェアパッケージ、又は既知のフォーマットを欠く他のソフトウェアパッケージにおける脆弱性を識別することができる。

【0029】

ユーザデバイス（ＵＤ）１４０は、パーソナルコンピュータ、ラップトップ、タブレットコンピュータ、スマートフォン、ウェアラブルコンピューティングデバイス、又は通知を受信及び表示することが可能な他の任意のデバイスであってもよいが、これらに限定されない。

【0030】

図２は、一実施形態によるソフトウェアパッケージにおける知らないソフトウェア脆弱性を発見するための方法を例示するフローチャート２００である。一実施形態では、この方法は、図１の脆弱性検出器１３０によって実行される。

【0031】

Ｓ２１０では、分析される脆弱性の潜在的な発生源が識別される。一実施形態では、Ｓ２１０は、潜在的に脆弱性を引き起こすものとして特定の変化を識別するために、ソフトウェアパッケージに関連する様々なデータを分析することを含む。この点に関して、ソフトウェアパッケージに対する変更の数が経時的に指数関数的に増加し、その結果、脆弱性に対する各変更及び全ての変更を分析することは、自動化されたソリューションであっても非現実的であることに留意する。本明細書に説明されるように変更を選択的に分析することによって、開示される実施形態は、全てではないにしてもほとんどの未発見の脆弱性を識別しながら、それらの変更を受けるソフトウェアパッケージを分析するために必要とされる過度のコンピューティングリソース消費を低減することを可能にする。

【0032】

さらなる実施形態では、Ｓ２１０はまた、ソフトウェアパッケージが分析されるリポジトリを選択することを含んでもよい。特定のリポジトリを選択することにより、分析しなければならないデータの範囲をさらに縮小することが可能になり、それによって分析に関するコンピューティングリソースの消費をさらに低減する。

【0033】

一実施形態では、脆弱性の潜在的な発生源の識別は、図３に示すフローチャートに従って実行される。図３は、一実施形態による脆弱性の潜在的な発生源を識別するための方法を例示するＳ２１０のフローチャートである。

【0034】

任意選択のＳ３１０において、リポジトリが分析のために選択される。リポジトリは、分析されるリポジトリが未知、そうでなければ未発見の脆弱なソフトウェアパッケージを有する可能性が高くなるように、分析のために選択される。例えば、オープンソースソフトウェアリポジトリは、メジャーなソフトウェアデベロッパのソフトウェアリポジトリよりも未知のソフトウェアパッケージを含む可能性が高い。別の例として、より頻繁にアクセスされたか、又は更新されたソフトウェアパッケージを有するリポジトリは、新たな及び出現しつつある脆弱性を分析するためにより重要であってもよい。

【0035】

未知又は未発見のソフトウェアパッケージを有する可能性に基づいて分析のためにリポジトリを選択することは、そのような分析に必要とされるコンピューティングリソースの使用を低減する。この点に関して、潜在的なリポジトリの総数は多く、自動化されたシステムであっても、脆弱性についてこれらのリポジトリの全てを分析することは非現実的であることに留意する。したがって、開示される実施形態は、走査される必要があるデータの量を低減し、したがって、分析の効率を改善する。

【0036】

一実施形態では、リポジトリは、他のリポジトリと比較して各リポジトリに記憶されたソフトウェアパッケージの相対的な使用量に基づいて選択される。さらなる実施形態では、リポジトリは、ユーザデータのフィードバックループ、推論された人気リポジトリ、パッケージダウンロード統計、又はそれらの組み合わせに基づいて選択される。

【0037】

ユーザデータは、フィードバックループを通して分析され、どのパッケージがより頻繁に使用されているか、したがって、どのリポジトリが頻繁に使用されるパッケージを含むかを決定する。ソフトウェアパッケージは、例えば、特定の期間（例えば、過去１週間）内のソフトウェアパッケージのダウンロード数が閾値を超える場合に、頻繁に使用されているとしてもよい。リポジトリは、例えば、１つ以上の頻繁に使用されるソフトウェアパッケージを有すること、閾値を超える数の頻繁に使用されるソフトウェアパッケージの数を有すること、閾値数のリポジトリの中から、閾値数のリポジトリの中から頻繁に使用されるソフトウェアパッケージの数が最も多いこと（例えば、最も頻繁に使用されるソフトウェアパッケージを有する上位１０のリポジトリ）などに基づいて、パッケージ使用の頻度に基づいて選択されてもよい。

【0038】

人気のあるリポジトリを推論することは、アプリケーションプログラミングインターフェース（ＡＰＩ）を使用し、パッケージ依存関係マニフェストのためにリポジトリを再帰的にクローリングし、どのパッケージが他のパッケージに最も頻繁に依存されているかを決定することによって達成されてもよい。ソフトウェアパッケージは、例えば、そのソフトウェアパッケージ上の他のソフトウェアパッケージの依存関係の数が敷値を超えている場合に人気があるとしてもよい。リポジトリは、例えば、１つ以上の人気のあるソフトウェアパッケージを有すること、閾値を超える数の人気のあるソフトウェアパッケージ有すること、閾値数のリポジトリの中から人気のあるソフトウェアパッケージの数が最も多いことなどに基づいて、パッケージの人気に基づいて選択されてもよい。

【0039】

パッケージダウンロード統計は、例えば、パッケージマネージャＡＰＩに問い合わせることによって取得されてもよい。最もダウンロードされたソフトウェアパッケージを有するリポジトリが選択されてもよい。

【0040】

ステップＳ３２０～Ｓ３６０において、セキュリティ関連の変更を識別するために、脆弱性の発生源となり得る変化を示すデータの様々な部分が分析される。セキュリティ関連の変更は、例えば、ステップＳ３２０～Ｓ３６０に関して以下にさらに説明するように、ソフトウェアパッケージに関連する変更命令、コメント、メモ、又は他のデータにおいて反映されてもよい。

【0041】

ステップＳ３２０～ステップＳ３６０までのステップは、任意の順序で又は並列に実行されてもよく、少なくともいくつかの実施形態ではこれらのステップの一部分のみが実行されてもよいことに留意されたい。Ｓ３１０に関して上述したように、リポジトリが選択されるときに、選択されたリポジトリにおけるソフトウェアパッケージのみが分析される。

【0042】

Ｓ３２０において、変更命令メッセージが問い合わせを介して取得され、分析される。変更命令は、例えば、コミットであってもよい。この目的のために、Ｓ３２０は、変更命令メッセージを問い合わせることと、その中に含まれるキーワードに基づいてメッセージを分析することと、を含んでもよい。さらなる実施形態では、Ｓ３２０は、履歴変更命令メッセージに基づいてセキュリティ関連キーワードを識別するように訓練された機械学習モデルを適用することをさらに含む。そのようなモデルは、テキスト分類に対してさらに訓練されてもよい。セキュリティ関連キーワードを含む変更命令は、脆弱性の潜在的な発生源として識別される。

【0043】

Ｓ３３０では、各ソフトウェアパッケージに関連するデータを分析し、そこに示された所定のデベロッパを追跡する。デベロッパは、セキュリティ研究者又はソフトウェアデベロッパであってもよく、特定のソフトウェアパッケージに対するセキュリティを所有することが知られているデベロッパであってもよく、その結果それらのデベロッパからのコミットが潜在的に未知のセキュリティフィックスに関連付けられる可能性が高い。この目的のために、そのような所定の疑わしいデベロッパがソフトウェアパッケージに対して識別されるときに、それらのデベロッパによる変更は、脆弱性の潜在的な発生源として識別される。

【0044】

Ｓ３４０において、各ソフトウェアパッケージに対するコードコメントが、セキュリティ関連キーワードに対して分析される。一実施形態では、Ｓ３４０は、履歴コードコメントに基づいてセキュリティ関連キーワードを識別するように訓練された機械学習モデルを適用することをさらに含む。そのようなモデルは、テキスト分類に対してさらに訓練されてもよい。セキュリティ関連キーワードを含むコメントによって示される変更は、脆弱性の潜在的な発生源として識別される。

【0045】

Ｓ３５０において、各ソフトウェアパッケージのリリースノートが、リリース日に対して分析される。より新しいソフトウェアパッケージ（例えば、現在の時刻より前に閾値期間未満でリリースされたソフトウェアパッケージ）を追加したか、又は修正した変更は、脆弱性の潜在的な発生源として識別される。

【0046】

Ｓ３６０において、各ソフトウェアパッケージのファイルにおけるバージョンインジケータが分析されて、脆弱性の潜在的な発生原となり得るソフトウェアパッケージに関連するファイルへの変更を推論する。例示的な実施形態では、バージョンインジケータは、マニフェストファイルに含まれてもよく、その結果、ソフトウェアパッケージをその現在のバージョン識別子に更新した変更後のマニフェストファイルへの変更は、脆弱性の潜在的な発生源として識別されるだろう。この目的のために、Ｓ３６０はさらに、変更命令を分析して、ソフトウェアパッケージをその現在のバージョンに更新した変更命令の後に何らかの変更命令が発生したかどうかを決定することを含んでもよい。

【0047】

Ｓ３７０では、Ｓ３２０からＳ３６０で実施された分析に基づいて、これらのステップに関して上述したように、１つ以上の潜在的な脆弱性の原因が特定される。

【0048】

任意選択のＳ３８０において、識別された脆弱性関連変更のうちのそれぞれの脆弱性関連変更に対して一意の識別子が作成され、割り当てられてもよい。変更は、変更命令によって永続的に行われた変更、コードコメントに示された変更、リリースノートに示された変更などであってもよい。一意の識別子は、脆弱性を引き起こした特定の変更を後で調べることを可能にするために利用されてもよく、さらに、変更を匿名化することを可能にしてもよい。このような変更の匿名化は、機密情報を保存するために重要となることがある。

【0049】

図２に戻って、Ｓ２２０において、脆弱性が識別される。識別された脆弱性は、未知のもの、不適切に報告されたもの、そうでなければ未発見の脆弱性であってもよい。このような脆弱性を識別することは、脆弱なソフトウェアパッケージを識別することにもつながる。

【0050】

一実施形態では、Ｓ２２０は、Ｓ２１０において識別された脆弱性の潜在的な発生源である変更を受けた各ソフトウェアパッケージに関連するデータに基づいて、脆弱性識別ルールを選択し適用することを含む。脆弱性識別ルールは、ソフトウェアパッケージを記憶しているソフトウェアリポジトリに対するバージョン識別子の利用可能性に基づいて選択されてもよい。さらに別の実施形態では、第１のルールは、ソフトウェアパッケージを記憶しているソフトウェアリポジトリがパッケージバージョンを有するときか、そうでなければパッケージバージョンがソフトウェアパッケージに対して利用可能であるときに選択され、第２のルールは、ソフトウェアパッケージに対するリポジトリがリリースバージョンを有するが、パッケージバージョンを有していないときか、そうでなければリリースバージョンが利用可能であるが、パッケージバージョンが利用可能でないときに選択され、第３のルールは、ソフトウェアパッケージに対するリポジトリがソフトウェアパッケージに対する任意のバージョン識別子を有しないときか、そうでなければパッケージバージョンもリリースバージョンもソフトウェアパッケージに対して利用可能でないときに選択される。

【0051】

一実施形態では、第１のルールは、脆弱なソフトウェアパッケージを、最新の変更命令（例えば、最新のコミット）に示されたバージョンの以前のバージョンバージョンであるパッケージバージョンを有するソフトウェアパッケージとして定義する。第２のルールは、脆弱なソフトウェアパッケージを、変更命令と時間的に相関していないリリースバージョンを有するソフトウェアパッケージとして定義する（例えば、ソフトウェアパッケージに対する最新のコミットのタイムスタンプによって示される日の閾値日数内にないリリース日に関連付けられたリリースバージョン）。リリースバージョンのリリース日は、利用可能な公開リポジトリに記憶されてもよい。第３のルールは、脆弱なソフトウェアパッケージを、公開リポジトリに記憶されたデータに示されたリリース時間と時間的に相関していないソフトウェアパッケージ（例えば、ＮＰＭ（Ｎｏｄｅ Ｐａｃｋａｇｅ Ｍａｎａｇｅｒ）などのパッケージマネージャによって示される最新の変更の閾値時間内にない作成時間を示すデータを有するソフトウェアパッケージ）として定義する。

【0052】

Ｓ２３０において、各脆弱ソフトウェアパッケージ（すなわち、識別された脆弱性を有する各脆弱ソフトウェアパッケージ）は、それぞれの脆弱性識別子にマッピングされる。一実施形態では、Ｓ２３０は、識別された各脆弱ソフトウェアパッケージを標準ソフトウェアパッケージ命名スキームの標準化された名前にマッピングすることと、識別された各脆弱ソフトウェアパッケージを、識別された各脆弱ソフトウェアパッケージの標準化された名前に基づく標準化されたソフトウェア脆弱性識別子にマッピングすることと、を含む。

【0053】

一実施形態では、各脆弱ソフトウェアパッケージは、図４によるプロセスを使用してそれぞれの脆弱性識別子にマッピングされる。図４は、一実施形態によるソフトウェアパッケージを標準脆弱性識別子にマッピングするための方法を例示するＳ２３０の例示的なフローチャートである。

【0054】

一実施形態では、図４に示すプロセスはさらに２つのサブプロセス４００－１及び４００－２を含む。第１のサブプロセスでは、ソフトウェアパッケージは、標準化されたソフトウェアパッケージ名にマッピングされ、その結果、そのマッピングを使用して正確に識別され得る。第２のサブプロセスにおいて、ソフトウェアパッケージは標準化された脆弱性識別子にマッピングされ、既知のタイプの脆弱性がそのソフトウェアパッケージに対して識別され得る。他の実施形態では、図４の方法は、第２のサブプロセス４００－２のみを含んでもよい。

【0055】

第１のサブプロセス４００－１では、Ｓ４１０において、ソフトウェアパッケージのデータに示されたパッケージ名がトークン化される。

【0056】

Ｓ４２０では、ソフトウェアパッケージに対する１つ以上の可能な標準化ソフトウェアパッケージ名が、１つ以上のソフトウェアパッケージリポジトリにおいて識別される。一実施形態では、Ｓ４２０は、ＣＰＥ（Ｃｏｍｍｏｎ Ｐｌａｔｆｏｒｍ Ｅｎｕｍｅｒａｔｉｏｎ）などの標準化された命名スキームにおいてソフトウェアパッケージの名前を示すデータを記憶している１つ以上のソフトウェアパッケージリポジトリを検索するように構成されているパッケージマネージャ又は他のプログラムに問い合わせることを含んでもよい。問い合わせは、ソフトウェアパッケージのトークン化された名前を利用してもよい。

【0057】

Ｓ４３０では、ソフトウェアパッケージリポジトリへの問い合わせから返された結果に基づいて、ソフトウェアパッケージが、標準化されたソフトウェアパッケージ名にマッピングされる。一実施形態では、Ｓ４３０は、Ｓ４２０で識別された可能な標準化されたソフトウェアパッケージ名をトークン化することと、ソフトウェアパッケージのトークン化された名前を、各トークン化された可能な標準化されたソフトウェアパッケージ名と比較することと、を含む。さらなる実施形態では、トークン化された名前の各ペア間の類似性の程度を表すスコアが生成されてもよく、ソフトウェアパッケージ名と最も高いスコアを有する標準化されたソフトウェアパッケージ名が適切なマッピングとして決定される。さらに別の実施形態では、閾値を超えるスコアを有する標準化されたソフトウェアパッケージ名のみが、適切なマッピングとして決定されてもよい。

【0058】

第２のサブプロセス４００－２では、Ｓ４４０において、ソフトウェアパッケージの既知のパッケージ名に基づいて、そのソフトウェアパッケージに対する既知の脆弱性が識別される。既知の脆弱性は、標準化された脆弱性識別子フォーマットの識別子を有しており、ソフトウェアパッケージに対する変更命令履歴を分析することによって識別されてもよい。そのような標準化されたフォーマットは、例えば、ＣＶＥ（Ｃｏｍｍｏｎ Ｖｕｌｎｅｒａｂｉｌｉｔｉｅｓ ａｎｄ Ｅｘｐｏｓｕｒｅｓ）であってもよい。

【0059】

Ｓ４５０において、ソフトウェアパッケージのソースコードが分析されて、ソフトウェアパッケージのデータに示されているソフトウェアパッケージの実際の名称を識別する。

【0060】

Ｓ４６０において、Ｓ４４０において識別された既知の脆弱性とＳ４５０において特定された実際の名前とに基づいて、ソフトウェアパッケージと標準化された脆弱性識別子との間のマッピングが作成される。一実施形態では、マッピングは、ＮＶＤ（Ｎａｔｉｏｎａｌ Ｖｕｌｎｅｒａｂｉｌｉｔｉｅｓ Ｄａｔａｂａｓｅ）などの標準データベースから抽出されてもよいが、これに限定されない。

【0061】

図２に戻ると、任意選択のＳ２４０において、依存関係グラフが、識別された脆弱なソフトウェアパッケージに基づいて作成又は更新されてもよい。依存関係グラフは、ソフトウェアパッケージ間の依存関係を定義し、識別された脆弱なソフトウェアパッケージを含むように作成又は更新される。したがって、依存関係グラフは、そうでなければ脆弱でないソフトウェアパッケージによる脆弱なソフトウェアパッケージへの依存関係を示す。脆弱なソフトウェアパッケージへのこのような依存性は、そうでなければ脆弱でないソフトウェアパッケージを、問題に対してより影響を受けやすくしてもよく、その結果、脆弱であるとも考えられる可能性がある。その結果、依存関係グラフは、これらの間接的な脆弱性、すなわち、ソフトウェアパッケージ自体のコードを分析することによって識別することができず、代わりに脆弱なソフトウェアパッケージに依存することによって継承される脆弱性を示す。

【0062】

Ｓ２５０では、識別された脆弱なソフトウェアパッケージに基づいて通知が生成される。通知は、特定された脆弱なソフトウェアパッケージ、依存関係グラフ、両方などを示すことができるが、これらに限定されない。

【0063】

図５は、一実施形態による、脆弱性検出器１３０の例示的な概略図である。脆弱性検出器１３０は、メモリ５２０、ストレージ５３０、及びネットワークインターフェース５４０に結合された処理回路５１０を含む。一実施形態では、脆弱性検出器１３０のコンポーネントは、バス５５０を介して通信可能に接続されてもよい。

【0064】

処理回路５１０は、１つ以上のハードウェア論理コンポーネント及び回路として実現されてもよい。例えば、限定するものではないが、使用することができる例示的なタイプのハードウェア論理コンポーネントは、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）、特定用途向け標準製品（ＡＳＳＰ）、システムオンチップシステム（ＳｏＣ）、グラフィック処理ユニット（ＧＰＵ）、テンソル処理ユニット（ＴＰＵ）、汎用マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ（ＤＳＰ）など、又は情報の計算又は他の操作を実行することができる他の任意のハードウェア論理コンポーネントを含む。

【0065】

メモリ５２０は、揮発性（例えば、ランダムアクセスメモリなど）、不揮発性（例えば、読み出し専用メモリ、フラッシュメモリなど）、又はそれらの組み合わせであってもよい。

【0066】

１つの構成では、本明細書に開示される１つ以上の実施形態を実装するためのソフトウェアは、記憶装置５３０に記憶されてもよい。別の構成では、メモリ５２０は、そのようなソフトウェアを記憶するように構成されている。ソフトウェアは、広義には、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語、又はその他と呼ばれるかを問わず、任意のタイプの命令を意味すると解釈されるものとする。命令は、コード（例えば、ソースコードフォーマット、バイナリコードフォーマット、実行可能なコードフォーマット、又は他の任意の好適なコードフォーマット）を含んでもよい。命令は、処理回路５１０によって実行されるときに、処理回路５１０に、本明細書で説明される様々な処理を実行させる。

【0067】

記憶装置５３０は、磁気記憶装置、光学記憶装置などとしてもよく、例えば、フラッシュメモリ又は他のメモリ技術、コンパクトディスク読み出し専用メモリ（ＣＤ－ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）、又は所望の情報を記憶するために使用され得る任意の他の媒体として実現されてもよい。

【0068】

ネットワークインターフェース５４０は、脆弱性検出器１３０が、例えば、ソースリポジトリ１２０、ユーザデバイス１４０、又はその両方と通信することを可能にする。

【0069】

本明細書で説明される実施形態は、図４に例示される特定のアーキテクチャに限定されるものではなく、開示される実施形態の範囲から逸脱することなく他のアーキテクチャも等しく使用されてもよいことを理解されたい。

【0070】

本明細書に開示される様々な実施形態は、ハードウェア、ファームウェア、ソフトウェア、又はそれらの任意の組み合わせとして実装され得る。さらに、ソフトウェアは、好ましくは、特定のデバイス及び／又はデバイスの組み合わせからなるか、又はこれらの部分からなるプログラム記憶ユニット又はコンピュータ可読媒体上に有形的に具現化されたアプリケーションプログラムとして実装される。アプリケーションプログラムは、任意の好適なアーキテクチャを含むマシンにアップロードされ、それによって実行されてもよい。好ましくは、マシンは、１つ以上の中央処理ユニット（ＣＰＵ）、メモリ、及び入出力インターフェースなどのハードウェアを有するコンピュータプラットフォーム上に実装される。コンピュータプラットフォームはまた、オペレーティングシステム及びマイクロ命令コードを含んでもよい。本明細書で説明される様々なプロセス及び機能は、マイクロ命令コードの一部若しくはアプリケーションプログラムの一部のいずれか、又はそれらの任意の組み合わせであってもよく、これらは、そのようなコンピュータ又はプロセッサが明示的に示されているかどうかにかかわらず、ＣＰＵによって実行されてもよい。追加的に、追加のデータ記憶ユニット、印刷ユニットなど、種々の他の周辺ユニットがコンピュータプラットフォームに接続されてもよい。さらに、非一時的なコンピュータ可読媒体は、一時的な伝搬信号を除く任意のコンピュータ可読媒体である。

【0071】

本明細書で記載された全ての例及び条件付き文言は、開示される実施形態の原理及び当該技術を促進するために発明者によって寄与される概念を読者が理解するのを支援する教育目的を意図しており、そのような具体的に記載された例及び条件に限定されないものとして解釈されるべきである。さらに、開示される実施形態の原理、態様、及び実施形態、並びにそれらの具体的な例を記載する本明細書における全ての記述は、それらの構造的及び機能的同等物の両方を包含することを意図している。追加的に、そのような等価物は、現在既知の等価物及び将来開発される等価物、すなわち構造に関係なく同じ機能を実行する開発される任意の要素の両方を含むことを意図している。

【0072】

「第１」、「第２」などの名称を使用して本明細書で要素に言及することは、一般に、これらの要素の量又は順序を制限しないことを理解されたい。むしろ、これらの名称は、一般に、本明細書において、２つ以上の要素又は要素のインスタンスを区別する便利な方法として使用される。したがって、第１及び第２の要素への言及は、２つの要素のみがそこで用いられてもよいこと、又は第１の要素が何らかの方式で第２の要素に先行しなければならないことを意味しない。また、特に明記しない限り、要素のセットは１つ以上の要素を含む。

【0073】

本明細書で使用される場合、語句「の少なくとも１つ」の後に項目のリストが続くということは、リストされた項目のいずれかが個別に利用され得ること、又はリストされた項目の２つ以上の任意の組み合わせが利用され得ることを意味する。例えば、システムが「Ａ、Ｂ、及びＣのうちの少なくとも１つ」を含むと説明される場合、システムは、Ａ単独、Ｂ単独、Ｃ単独、２Ａ、２Ｂ、２Ｃ、３Ａ、Ａ及びＢの組み合わせ、Ｂ及びＣの組み合わせ、Ａ及びＣの組み合わせ、Ａ、Ｂ及びＣの組み合わせ、２Ａ及びＣの組み合わせ、Ａ、３Ｂ及び２Ｃの組み合わせなどを含むことができる。

【図1】

【図2】

【図3】

【図4】

【図5】

【国際調査報告】