BDBA (Black Duck Binary Analysis) トリアージ範囲が誤解を招く

BDBA (Black Duck Binary Analysis) トリアージ範囲が誤解を招く

Black Duck Binary Analysis(別名Protecode)ツールには、脆弱性トリアージのためのいくつかのオプションがあります。

ヘルプから:

トリアージ範囲

サードパーティ コンポーネント内のトリアージされた脆弱性にスコープを適用できます。既知の脆弱性をトリアージするときは、次のオプションから選択できます。

アカウント: 企業アカウント内のコンポーネントのすべての使用に適用されます

グループ: グループ内のコンポーネントのすべての使用に適用されます

応用: 同じアプリケーション内でのコンポーネントの使用にのみ適用されます

アプリケーション名: 同じアプリケーション名を持つスキャンされたアプリケーション内でのコンポーネントの使用に適用されます

ファイルハッシュ: 同じファイルハッシュを持つスキャンされたアプリケーション内でのコンポーネントの使用に適用されます

私が望んでいるのは、ライブラリ内の CVE をトリアージして、トリアージの結果が次のスキャンに引き継がれるようにすることです。「ファイル ハッシュ」オプションでまさにこれが実行されることを期待していますが、次回アーカイブをアップロードすると、同じ CVE がトリアージされていないものとして表示されます。何が問題なのでしょうか?

答え1

TL;DR - 「グループ」スコープを使用します。

詳細

APIドキュメントではもう少し明確に説明されています

PUT /api/triage/vulnerability/

component - Component name
version - Component version
vulns - List of vulnerability ids
scope - Scope in which the triage affects. Possible values:

- CA - Account wide
- FN - Filename
- FH - File hash
- R - Result
- G - Group

product_id - In FN, FH and R scopes the related product

group_id - In G scope the related group

実際にツール内でのトリアージはファイルに反対ではない、 しかしライブラリのバージョンに対して(コンテキスト内のライブラリ === コンポーネント)。バージョンをトリアージするため、ファイルをトリアージすることは理論的には不可能です。これを念頭に置くと、残りの考えはシンプルです。

では、「ファイル ハッシュ」とは何でしょうか?

「FH」を使用する場合は product_id が必要であり、product はバイナリを含むアップロードされたアーカイブと同義語 (現在のコンテキストでは) であることが明確に記述されています。したがって、すべての製品には、アップロードされたアーカイブのハッシュである「ファイル ハッシュ」が 1 つだけあります。つまり、このオプションは完全に役に立ちません。なぜなら、100 個のファイルを個別にアップロードするのではなく、複数のバイナリを含むソフトウェアを含むアーカイブ\zip\tar.gz をアップロードするからです。また、アーカイブのハッシュは、readme ファイルに変更があったとしても、再パッケージ化のたびに変更されます。

私が望んでいるのは、ライブラリ内の CVE をトリアージして、トリアージの結果が次のスキャンに引き継がれるようにすることです。

「ファイル ハッシュ」はこの目的には適していないため、他の利用可能なスコープ オプションを調べて、ここで何ができるかを確認しましょう。

結果

最も単純でデフォルトのオプション。同時に、最も役に立たないオプション。Applicationヘルプに記載されているスコープに直接マップしますApplies to uses of the component within the same application only。つまり、繰り越しはありません。

ファイル名

個人的には、ヘルプの対応する行よりも「ファイル名」の方が明確だと思いますApplication name。いずれにしても、これもかなり明確です。トリアージは、アーカイブの名前が同じ場合にのみ引き継がれます。これで何とか問題が解決すると、新しい問題、つまり異なるビルドを区別するという問題が発生します。通常、私たちは zip に という名前を付けて、MyCoolBuild_942_ab4e3f過去のビルドの結果を簡単に見つけて確認できるようにします。気にしない場合は、 という名前を zip に付ければ、このスコープはオプションになりますMyCoolBuild.zip

グループ

ご想像のとおり、これはグループ全体のトリアージにすぎません。チームに独自のグループがある場合は、それを使用すれば問題ありません。

私の場合、会社全体でファイルを1つのグループにアップロードしているので、5月いくつかの競合がありますが、ツールのマニュアルには、このライブラリのカスタム ビルドを作成する場合 (たとえば、一部の CVE を自分で修正する場合) はバージョン サフィックスを使用する必要があると記載されています。全員がこのルールに従い、カスタム ライブラリに but という名前を付けると、1.0.2異なる1.0.2_company_buildチームのトリアージ間で競合は発生しません。

アカウント

BDBA インスタンスにはこのオプションがないのでわかりません -_-

上記の仮定の正しさを検証する

上記のすべては、テストアップロードを数回行うことで簡単に確認できます。

ファイルハッシュ- 同じファイルを異なる名前で 2 回アップロードし、「FH」スコープで CVE をトリアージします。その後、トリアージは引き継がれます。

ファイル名- 一度アーカイブをアップロードし、その後アーカイブを少し変更して(内部に空のテキスト ファイルを追加して)、再度アップロードします。トリアージは引き継がれます。

グループ- 自動検出されたバージョンで 1 つのライブラリをアップロードし、バイナリを変更して別の名前でアップロードします - トリアージは引き継がれます。

追加のテストとして、2 つのライブラリを含むアーカイブをアップロードし、そのうちの 1 つのバージョンをオーバーライドすることもできます。これにより、UI でライブラリが分離され、個別のトリアージが可能になります。

関連情報