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 でライブラリが分離され、個別のトリアージが可能になります。