web-dev-qa-db-ja.com

BDBA（Black Duck Binary Analysis）トリアージスコープの誤解を招く

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

ヘルプから：

トリアージスコープ

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

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

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

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

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

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

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

securityvulnerabilities
1
The Godfather

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個のファイルを個別にアップロードするのではなく、複数のバイナリを含むソフトウェアとともにarchive\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つのグループにファイルをアップロードしているため、mayで競合が発生する可能性がありますが、ツールのマニュアルには次のように記載されています。このライブラリのカスタムビルドを作成する場合は、バージョンサフィックスを使用する必要があります（たとえば、一部のCVEを自分で修正するため）。全員がこのルールに従い、カスタムライブラリに1.0.2ではなく1.0.2_company_buildという名前を付けると、異なるチームのトリアージ間で競合が発生しなくなります。

アカウント

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

上記の仮定の正しさをテストする

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

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

ファイル名-アーカイブを1回アップロードしてから、アーカイブを少し変更して（空のテキストファイルを中に追加して）、もう一度アップロードします。トリアージは引き継がれます。

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

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

1
The Godfather