こんにちは。今日は オープンソースコンポーネントの脆弱性とライセンスの管理を行うツール 「WhiteSource」のお話です。 WhiteSourceをご利用されているお客様から 「スキャンしたのに結果が表示されない。」「設定したはずなのにソースコードがスキャンされない。」などのご質問がありました。 原因の多くは 「目的にあったスキャン設定がされていないため。」ではあるものの、これをご理解頂くためには WhiteSourceがどのようなルールで、みなさんのプロジェクトで利用されている オープンソースコンポーネントを特定しているのかを知ることが大事です。

そこで、WhiteSourceを仕組みを理解して正しく効果的に利用するために、2回に分けて WhiteSourceが オープンソースコンポーネントの特定と脆弱性の有無をレポートする仕組みを説明します。

WhiteSouceは何を行うツールか？

初めに「WhiteSource」について簡単に紹介すると、プロジェクト内のファイル(ソースファイル、実行ファイル、ライブラリファイル)を検索し、利用しているオープンソースコンポーネントを特定することができるツールとなります。
また特定したオープンソースコンポーネントは、以下の2つの情報を付加してユーザーに通知します。

• メタ情報（ライブラリの名称、ファイルの名称、バージョン、ライセンスの種類）
• 既知の脆弱性情報 (CVE-YYYY-ZZZZ など)

WhiteSourceが特定するオープンソースコンポーネントの定義は次の通りです。

• オープンソースとして、ライセンスされているライブラリやソースファイルで、一般的に、ソフトウェアのソースコードあるいはコンテナ化されたOSイメージなどが対象です。
• 公開されているリポジトリ（GitHub, nuget, Maven Central, RubyGems など）によって、ホストされているファイルが対象となります。

また次のようなコンポーネントはWhiteSourceでは管理対象外となります。

• ハードウェア（チップセット、ネットワーク機器など）に組み込まれるオープンソースコンポーネントは対象外としている。
• オープンソースコンポーネントのソースコードの一部を切り取って流用しているファイル。

WhiteSourceがファイルをスキャンして、オープンソースコンポーネントを特定し、結果の集計・分析を行う過程は、3つのモジュールが基本となります。

1. 脆弱性データベース : オープンソースコンポーネントの "SHA-1チェックサム" / "メタ情報" / "脆弱性情報" を WhiteSourceが独自に収集し管理しているデータベースです。
2. Unified-Agent (UA) : ユーザーの開発プロジェクトのファイルを検索して、ファイルの "SHA-1 チェックサム"を計算し、その"SHA-1 チェックサム"と"ファイル名"を WhiteSource UI に送信する、エージェントツールです。
3. WhiteSource UI : Unified-Agentから送信されたスキャン結果と脆弱性データベースとを突き合わせ、特定したオープンソースコンポーネントの情報をInventoryに保存します。保存した情報の 統計・分析結果はWebブラウザから閲覧できます。

本ブログでは、オープンソースコンポーネントの特定にフォーカスを当てていますので、"脆弱性データベース" と "Unified-Agent" の仕組みについて説明します。

脆弱性データベースが管理している情報

脆弱性データベースでは、発見された脆弱性を識別する CVE について NVDを中心としたアドバイザリーから詳細な情報を収集・登録しています。更にはまだCVE で識別されていない脆弱性や WhiteSourceで独自に識別した脆弱性が管理される場合もあります。オープンソースコンポーネントは、ファイル単位に "SHA-1 チェックサム"、 "メタ情報"、"脆弱性情報" を収集します。これらのファイルは、ベンダー公式のダウンロードサイトやGithubなどの公開リポジトリから取得します。

一般的に「脆弱性データベース」と呼ばれていますが、脆弱性を持たない オープンソースコンポーネントの"SHA-1 チェックサム" / "メタ情報"も管理しています。

WhiteSourceでは、NVD などのアドバイザリーを常時監視しており、CVEの公開や更新が行われると 即座に脆弱性データベースにその脆弱性情報を登録します。また これとは別に オープンソースコンポーネント も前述の公開リポジトリを監視しており、ファイルの追加や更新を検知してSHA-1 チェックサムやメタ情報を取得します。

このようにして登録された 脆弱性情報とオープンソースコンポーネントの関連付けは、WhiteSource独自の機械学習アルゴリズム と WhiteSource社のリサーチチームのレビューによって検証し登録されます。

ちなみに この脆弱性データーベースは GitHub のリポジトリ内の脆弱性検知にも利用されているそうです。

Unified-Agent がスキャンしているもの

WhiteSourceが みなさんのプロジェクトに含まれる オープンソースコンポーネントをスキャンするときは、通常 Unified-Agentと呼ばれる wss-unified-agent-x.y.z.jar を実行することから始めます。 この Unified-Agent (以下、UA) が行っていることは プロジェクトが利用しているオープンソースコンポーネントを特定するために、プロジェクト配下にあるファイルを順番に検索して、そのファイルから読み取れる "SHA-1 チェックサム" や "ファイル名" などのファイルのメタ情報の収集となります。（オープンソースコンポーネントのメタ情報ではありません。）

UAは収集した情報をユーザーが利用する WhiteSourceサーバーの指定プロジェクトに送信します。その後は WhiteSourceが受信した"SHA-1 チェックサム" を使って 脆弱性データベースの"SHA-1 チェックサム" と突き合わせてオープンソースコンポーネントを特定します。

"SHA-1 チェックサム" のひとつの特徴として、同じファイルであれば常に同じ値が算出できますので、、プロジェクトがダウンロードしたオープンソースコンポーネントと、脆弱性データベースが取得していたオープンソースコンポーネントのファイルと同じであれば、"SHA-1 チェックサム"が一致します。これを基に一致した "SHA-1 チェックサム" をキーに脆弱性データベースに登録されたオープンソースコンポーネントのメタ情報や脆弱性情報を特定していきます。（尚、WhiteSourceの "SHA-1 チェックサム" は、独自の値を付加して計算するため、通常求められる値とは異なります。）

UA がファイルの中身をスキャンするケース

オープンソースコンポーネントを特定する過程で UAがプロジェクトのファイルの内容をスキャンする場合があります。これは次のような場合ですが、オープンソースコンポーネントを特定するための 前処理や後処理として実施されます。ここでスキャンしたコード情報および ソースコードファイルは、WhiteSourceのサーバーを含む外部に送信されることはありません。

• パッケージマネージャーの定義ファイル (.pom, .gradle, .projct などの設定ファイル)
  
• コード内で、外部ライブラリの参照を宣言するソースファイル。
  例えば、HTMLファイル (.html) はコード内でインポート宣言している Javascriptライブラリがありますので、このライブラリ探すためにファイルの中身をスキャンします。
• Prioritize オプションを有効にした場合に、検索対象となるファイル。
  このオプション機能は、脆弱性を持つオープンソースライブラリが特定された後、そのライブラリを参照しているファイルと参照している箇所として行番号を検出する機能で、 Java, Javascript, Python で書かれたコードのみが対象です。

オープンソースコンポーネントが特定できない場合

このようにWhiteSourceは、オープンソースコンポーネントのファイルの"SHA-1 チェックサム"を 脆弱性データベース と Unified-Agent で計算し、突き合わせることでプロジェクトが利用しているオープンソースコンポーネントを特定しています。
この仕組みの中で、オープンソースコンポーネント および 脆弱性が特定できない場合「脆弱性データベース」と「Unified-Agent」のそれぞれの視点で原因が考えられます。

（原因１） 脆弱性データベースで特定できていない

これは 「オープンソースコンポートネントの当該ファイルがデータベースに登録されていない」ためで、UAで検索したファイルの "SHA-1 チェックサム" とマッチする ファイルが存在しないためです。
ファイルが脆弱性データベースに登録されていない要因としては次のようなケースがあります。

1. WhiteSourceの管理対象外のファイルである。
   例えば、ハードウェアに組み込んで利用されるオープンソースコンポーネントや オープンソースに該当しないライブラリなどです。
2. WhiteSource社 の 検証結果により管理対象外と判定したファイル。
   No.1に該当するものもあれば、脆弱性の内容や影響などを加味して判断されるようです。
3. WhiteSourceが監視していないリポジトリから配布されているファイル。
   例えばディストリビューターによって、アップストリームからフォークし独自の改変を加えて 配布されているライブラリなどは、"SHA-1 チェックサム" が変わってしまいますが脆弱性データベースには登録されないものもあります。
4. 登録プロセス上のエラーによるもの。
   これはファイルの検知処理やヒューマンエラーなどが挙げられます。

（原因２）Unified-Agentで特定できていない

これは「プロジェクト内の当該ファイルの "SHA-1 チェックサム" が計算できなかった」ためです。つまり、当該ファイルが検索できなかったことで起こります。
その理由としては以下のような事象が該当します。

1. 特定の拡張子やフォルダ配下のファイルのスキャンをスキップする設定となっている。
2. ディレクトリやファイルのアクセス権限によってUAが そのファイルにアクセスすることが出来なかった。
3. スキャン処理中に Unified-Agent に実行エラーが発生し異常終了している。
4. その他、Unified-Agent の未知の不具合によるもの。

それでも特定できない場合の対応

WhiteSourceの脆弱性データベース および Unified-Agent は定期的に 改善されていますが、それでも漏れを0にすることは出来ません。そのため 原因が特定できない場合は WhiteSourceに問い合わせて 調査を依頼することが必要となります。
更にはWhiteSourceの設定を変更して、スキャン対象を見直したり、詳細なスキャン結果を出力することができます。

この方法については、次回 のブログで説明したいと思います。