1. OWASP Dependency Check とは？

OWASP Dependency Check は、OWASP Top 10 - 2017 における

A9:2017-既知の脆弱性のあるコンポーネントの使用 (A9-Using Components with Known Vulnerabilities)

に関するスキャンを行うツールです。

この項目がどんなものかというと、といっても名前そのままで、

アプリケーションが、既知の脆弱性のあるコンポーネント（ライブラリ、フレームワーク、ソフトウェアモジュール etc.）を使っていると危険だよ

という内容です。

つまり OWASP Dependency Check は、アプリケーションに対して、脆弱性の存在しているライブラリを使っていないか検査するためのツールです。

正式に対応しているアプリケーションの種類

公式な情報によると、正式に対応しているアプリケーションは

• Java アプリケーション
• .NET アプリケーション

の2つだそうです。

実験的に対応しているとなると、もう少し増えます。

• Python アプリケーション
• Ruby アプリケーション
• PHP (Composer) アプリケーション
• Node.js アプリケーション

公式サイトには、こちらの4種をスキャンするには、「設定で有効にしないといけない」とありますが、コマンドラインツールのオプションを見る限りではデフォルトで有効になっていました。このあたり、どうなんでしょうか。

スキャンに利用する脆弱性データベース

NVD (National Vulnerability Database) の脆弱性データベースをローカルにコピーして利用します。

公式サイトなど

• OWASP Dependency Check - OWASP
• ドキュメント
  • dependency-check – About
• ソースコード
  • GitHub - jeremylong/DependencyCheck
• プレゼン資料（概要をつかむには、この資料がよいです）
  • Depending on Vulnerable Libraries (pdf)

2. 提供されていツールの種類

OWASP Dependency Check は、いろいろな形式で提供されています。

• Ant Task
• Command Line Tool
• Gradle Plugin
• Jenkins Plugin
• Maven Plugin
• SBT Plugin

本ページでは、Command Line Tool について説明します。

3. Command Line Tool の使い方

Command Line Tool の使い方について簡単に説明します。

1. ダウンロード

OWASP Dependency Check ページの「Quick Download」にある「Command Line」リンクをクリックしてダウンロードします。

このページを書いているタイミングだと、「dependency-check-4.0.1-release.zip」というファイルがダウンロードされました。

これを解凍すると「dependency-check」というフォルダが生成され、その内容は以下となります。このフォルダは任意のパスに配置しておきましょう。

更に「bin」フォルダ内には、以下の2つのファイルが格納されています。

• dependency-check.bat
• dependency-check.sh

これらは、スキャンを行う際に実行するファイルです。

Windows なら「dependency-check.bat」、Mac/Linux なら「dependency-check.sh」を実行します。

2. スキャンを実行する

本ページでは Windows 環境を想定し、PowerShell を使って以降の説明を行います。

基本的なスキャンを行うためのコマンドは以下です。

PS> dependency-check.bat --project "MyApp" --scan "path\to\project"

ここで指定しているオプションは以下の2つです。

必須オプション

オプション	説明
--project _<name>_	- スキャンされるプロジェクトの名前（必須） - 結果レポートに記載されます。
-s, --scan _<path>_	- スキャン対象となるフォルダパス（必須） - このオプションは複数指定することができます。

このコマンドを実行すればスキャンできます。

こんな感じです。

※ 最初のところで、ローカルの脆弱性データベース(NVDをコピーして作成しているらしい)を更新する処理が入っているようです。

毎回引数を指定するのが面倒であれば、PowerShell 用スクリプトファイル を作成して実行することもできます。

そのためには、例えば dependency-check-execute.ps1 といった名前のファイルを作成して（拡張子は .ps1）、以下を記述します。

dependency-check.bat `
  --project "MyApp" `
  --scan "path\to\project"

• ps1 ファイルでは、バッククォートを使って行を継続することができます。
• ps1 ファイルでは、バッチファイルをそのまま実行することができます。

あとは、PowerShell でこのファイルを実行するだけです。

PS> dependency-check-execute.ps1

3. レポートファイルが生成される

スキャンを実行すると、カレントフォルダ内に 「dependency-check-report.html」というレポートファイルが生成されます。

このHTMLファイルをウェブブラウザで開きます。

この画面の中の から は以下の内容になっています。

スキャン情報 脆弱性を持つライブラリ（概要） 脆弱性を持つライブラリ（詳細）

の部分から下の画面が以下です。

では、順番に見ていきます。

スキャン情報 (Scan Information)

実施されたスキャンに関する情報です。

スキャン情報 (Scan Information)

項目	説明
Report Generated On	レポートが生成された日時
Dependencies Scanned	スキャンされたライブラリの数
Vulnerable Dependencies	脆弱性が見付かったライブラリの数
Vulnerabilities Found	見付かった脆弱性の数
Vulnerabilities Suppressed	抑制された脆弱性の数
NVD CVE 20XX ※ 2002年から現在まで、年ごとに項目がある	NVD CVE データの最終更新日時？
NVD CVE Checked	NVD CVE がチェックされた日時
NVD CVE Modified	NVD CVE のデータが変更（更新？）された日時
VersionCheckOn	バージョンのチェックが行われた日時

脆弱性を持つライブラリ（概要）

発見された「脆弱性を持つライブラリ」が一覧表示されます。

 

項目	説明
Dependency	スキャンされたライブラリ名
CPE	見付かったCPE識別子
Coordinates	The Build Coordinates (?)
Highest Severity	紐付いた CVE の最も高い深刻度
CVE Count	CVE の数
CPE Confidence	特定されたCPEに対する確実性 (low, medium, high, and highest)
Evidence Count	CPEを特定するために収集されたエビデンスの数

脆弱性を持つライブラリ（詳細）

発見された「脆弱性を持つライブラリ」に関する詳細情報が表示されます。

今回の例では、「mustache.js:0.7.3」という1項目だけ表示されています。

Evidence

このレポート内にある Evidence とは、スキャンして収集された情報を意味しており、

• vendor
• product
• version

という3種類に分類されます。

何のために分類して収集しているのかというと、CPE という仕様で標準化された「ハードウェア、オペレーティングシステム、アプリケーションなどのプラットフォームを識別するための、構造化された名称」と一致させるためです。

CPE では、以下のフォーマットでプラットフォームを特定できるようにしており、ここに「ベンダ名(vendor)」「製品名(product)」「バージョン(version)」が入っています。

cpe：/{種別}：{ベンダ名}：{製品名}：{バージョン}：{アップデート}：{エディション}：{言語}

Identifier (識別子)

ここには、収集された情報から特定されたプラットフォーム (cpe) が表示されています。

今回の場合は、以下の1つだけです。

cpe:/a:mustache.js_project:mustache.js:0.7.3

それぞれの部分の意味を表にします。

 

値	説明
a	これはプラットフォームの「種別」を表す部分で、「a」は「アプリケーション」を意味しています。
mustache.js_project	ベンダ名
mustache.js	製品名
0.7.3	バージョン

※ 共通プラットフォーム一覧CPE概説：IPA 独立行政法人 情報処理推進機構 が参考になります。

これは、「今回スキャンしたライブラリの中に、この CPE で表されたソフトウェアが含まれており、そのソフトウェアには脆弱性が存在している可能性がある」ということを示しています。

どうやってこの特定を行っているのかというと、

ローカルに作成（コピー）された 脆弱性データベース (CVEのデータ) の中に記述されている CPE と、スキャンによって収集されたエビデンスが一致すると思われるものを探す

という処理を行っているようです。dependency-check アプリケーションの data フォルダには、dc.h2.db というファイルがあり、これがデータベースになっているようです（400MBくらいあります）。

CVE は脆弱性を一意に特定する識別子ですが、その情報の中には「その脆弱性を持つソフトウェアの一覧情報」が CPE を使って記述されています。そのため、CPE の部分でマッチングさせれば、CVE で表された脆弱性も特定できるという仕組みです。（詳しくは、dependency-check – How does dependency-check work? を参照してください）

Published Vulnerabilities

そうして特定された脆弱性が、次の「Published Vulnerabilities」という欄に表示されています。

今回の場合は、「CVE-2015-8862」という脆弱性が1つだけ表示されています。「CVE-2015-8862」に貼られているリンクをクリックすると、この脆弱性について書かれたウェブページに飛ぶことができますが、そのページの下の方にある「Vulnerable software and versions」という項目に、cpe の情報が載っています。今回検出された cpe と同じような識別子になっていることが分かります。

Published Vulnerabilities にはいろいろな情報が載っていますので、どんな脆弱性なのか確認しておきましょう。

ここに記載されているセキュリティ用語を改めて以下にまとめておきます。

脆弱性に関する用語

用語	概要	参考サイト
CWE	脆弱性の種類	共通脆弱性タイプ一覧CWE概説：IPA 独立行政法人 情報処理推進機構
CVE	脆弱性識別子（個別製品中の脆弱性に割り当てられた一意の識別番号）	共通脆弱性識別子CVE概説：IPA 独立行政法人 情報処理推進機構
CVSS	脆弱性の深刻度	共通脆弱性評価システムCVSS概説：IPA 独立行政法人 情報処理推進機構
CPE	ハードウェア、ソフトウェアなどを識別するための共通の名称基準	共通プラットフォーム一覧CPE概説：IPA 独立行政法人 情報処理推進機構

4. 誤検知があれば、その脆弱性項目を抑制するXMLファイルを作成する

スキャンしたアプリケーションが利用しているライブラリの中に、レポートに記載された CPE (ライブラリ)があるのか確認します。「ベンダ名」「製品名」「バージョン」は正しいでしょうか？ 特に Confidence が low であれば、しっかり確認しなければいけません。

また、CPE は正しくても CVE （脆弱性）が間違っていることもあります。

このような場合（誤検知）は、抑制XMLファイル (suppression XML file) を作成してスキャン対象から外す必要があります。このファイルを作成しておけば、特定の項目を除外したレポートが生成できます。

抑制XMLファイルでは、「特定のCPE」「特定のCVE」「特定のCVSSの値以下」など、いろいろな条件を指定することができます。

このうち、特定の CPE や CVE の抑制ファイルを生成する場合は、レポート上のボタンを利用する方法が簡単です。

特定の CPE を抑制する場合は、その CPE の横にある [suppress] ボタンをクリックします。

特定の CVE を抑制する場合は、その CVE の横にある [suppress] ボタンをクリックします。

どちらも同じなのですが、[suppress] ボタンをクリックして表示されるウィンドウの中に XMLコードが表示されますので、これをコピーして使用します。

但し、一番最初に 抑制ファイル自体を作成する必要がある場合は、[Complete XML Doc] ボタンを押し、表示されたXMLコードをコピーし、新規作成したファイルにペーストします。XMLファイルなので、拡張子は .xml としたファイル名にしてください。どんな名前でもよいです。

例えば、[Complete XML Doc] ボタンを押すと、以下のXMLコードが表示されます。

<?xml version="1.0" encoding="UTF-8"?>
<suppressions xmlns="https://jeremylong.github.io/DependencyCheck/dependency-suppression.1.2.xsd">
   <suppress>
      <notes><![CDATA[
      file name: mustache.js:0.7.3
      ]]></notes>
      <sha1>f7d375676a80ef77949c717566ad1d0a3d56395c</sha1>
      <cve>CVE-2015-8862</cve>
   </suppress>
</suppressions>

この中の の部分が、1つの抑制項目になっています。

2つ以上の項目を抑制したい場合は、この <suppress> のカタマリを追加していくことになります。

以下は 2つの項目を追加した XMLの例です。

<?xml version="1.0" encoding="UTF-8"?>
<suppressions xmlns="https://jeremylong.github.io/DependencyCheck/dependency-suppression.1.2.xsd">
    <suppress>
        <notes><![CDATA[
        This suppresses cpe:/a:csv:csv:1.0 for some.jar in the "c:\path\to" directory.
        ]]></notes>
        <filePath>c:\path\to\some.jar</filePath>
        <cpe>cpe:/a:csv:csv:1.0</cpe>
    </suppress>
    <suppress>
        <notes><![CDATA[
        This suppresses any jboss:jboss cpe for any test.jar in any directory.
        ]]></notes>
        <filePath regex="true">.*\btest\.jar</filePath>
        <cpe>cpe:/a:jboss:jboss</cpe>
    </suppress>
</suppressions>

このあたりの詳細は、dependency-check – Suppressing False Positives を参考にしてください。

5. 再度、スキャンを実行する

では、suppressions.xml という名前で抑制XMLファイルを作成したとしましょう。

この場合、再度スキャンするには、--suppression オプションで抑制XMLファイルを指定します。

PS> dependency-check.bat --project "MyApp" --scan "path\to\project" --suppression "path\to\suppressions.xml"

こうすれば、抑制された項目はレポートに出力されません。

4. その他のコマンドオプション

dependency-check.bat ファイルを実行する際に指定することのできるその他のオプションをいくつか紹介します。

その他のオプション

オプション	説明
--exclude _<pattern>_	- スキャンから除外されるパスのパターン - このオプションは複数個指定することができます。
-o, --out _<path>_	- レポートが出力されるフォルダー - デフォルトはカレントフォルダです。

その他の高度なオプション

オプション	説明	デフォルト
--disablePyPkg	- 実験的なPython Package Analyzerが使用されるかどうかをセットします。	false
--disableNodeJS	- retired Node.js Package Analyzer が使用されるかどうかをセットします。	false
--disableRubygems	- 実験的な Ruby Gemspec Analyzer が使用されるかどうかをセットします。	false
--disableComposer	- 実験的な PHP Composer Lock File Analyzer が無効にされるかどうかをセットします。	false

参考

• dependency-check-cli – Command Line Arguments
• dependency-check – File Type Analyzers

5. おわりに

OWASP Dependency Check は、主に何らかのツールの「プラグイン」という形で提供されていますが、「Command Line Tool」は汎用性が高く、簡単に使えるのが大きな利点だと思います。

ただ、「使用している脆弱性データベースの情報が古い」や、「NVD のデータに不完全なものがあるので、プラットフォームに紐付いている脆弱性情報がちゃんと取得できない」など問題点もあるようです。とはいえ、セキュリティに完全ということはそもそもないですし、やらないよりはやった方がいいでしょう。

それから、Node.js, PHP, Python, Ruby製のアプリケーションには「実験的」に対応していますが、早く正式に対応して欲しいところです。