重複排除 on DefectDojo Documentation

重複排除について

Mon, 01 Jan 0001 00:00:00 +0000

DefectDojoは、ツールから一括レポートを取り込み、レポートの内容に基づいて1つ以上の検出事項を作成するように設計されています。DefectDojoを使用する際は、同じツールから定期的にレポートを取り込むことがほとんどであるため、重複した検出事項が発生する可能性が非常に高くなります。

ここで役立つのが重複排除機能です。これは、重複した検出事項を自動的に管理できるように設定できるスマートな機能です。

DefectDojoが重複をどのように処理するか

まず、テスト1. をインポートします。レポートには脆弱性が含まれており、これは検出事項Aとして記録されます。
その後、同じ脆弱性を含むテスト2をインポートします。これは検出事項Bとして記録され、検出事項Bは検出事項Aの重複としてマークされます。
さらにその後、同じ脆弱性を含むテスト3をインポートします。これは検出事項Cとして記録され、検出事項Aの重複としてマークされます。

このように重複を作成・マークすることで、DefectDojoは「オリジナル」の脆弱性に関するすべての作業がオリジナルの検出事項ページに集約されるようにし、別々のコンテキストが作られたり、対応が必要な複数の独立した脆弱性が存在するかのような印象をチームに与えたりすることを防ぎます。

どの検出事項がオリジナルになるか

重複排除は、重複チェーンの中で最初に作成された検出事項を常に正規のオリジナルとして扱います。そのため、以前のインポートによる検出事項が、より新しい検出事項の重複に格下げされることはありません。すでに確立されたオリジナルの地位が移ることはありません。

単一のレポート内では、スキャナーが検出事項を列挙する順序によって「勝者」が決まるわけではありません。1回のインポートで作成される検出事項は、内容に基づく安定した順序で作成されるため、同じ重複排除キーで衝突する複数の検出事項を含むレポートは、インポートするたびに同じオリジナルを生成します。同じ結果を再スキャンして再インポートしても、チームが対応してきた検出事項が入れ替わることはありません。

デフォルトでは、重複排除を適用するには、これらのテストが同じ製品の配下にネストされている必要があります。必要に応じて、重複排除の範囲を単一のエンゲージメントにさらに限定することもできます。

重複した検出事項は、デフォルトで非アクティブに設定されます。これは重複した検出事項自体が非アクティブであるという意味ではありません。むしろ、チームが対応・修正すべきアクティブな検出事項が1つだけになるようにするためのものであり、オリジナルの検出事項が緩和済みになると、重複した検出事項も緩和済みになることを意味します。

再インポートにおける重複排除

重複排除と再インポートは似たプロセスですが、検出事項の一致を識別するために異なるアルゴリズムを使用します。

テストに再インポートすると、再インポートのプロセスは受信した検出事項を確認し、ハッシュコードを比較して、一致するものを破棄します。これらの一致した検出事項は、検出事項としても重複検出事項としても作成されることはありません。

ただし、再インポートの重複排除後に残った検出事項も、引き続き同一ツール重複排除の対象となります。そのため、同一ツール重複排除の範囲をより狭く設定していると、再インポートのパイプライン内で重複が発生することがあります。

例

ここでは、再インポートの重複排除アルゴリズムが同一ツール重複排除アルゴリズムと異なるツールを例に説明します。

Deduplication Algorithm	Hash Code Fields
再インポート	タイトル、CWE、深刻度、説明、行番号
同一ツール	タイトル、CWE、深刻度、説明

DefectDojo内に、ある行番号を持つ検出事項があったとします。環境を再スキャンしたところ、その脆弱性の行番号が変わりました。同じテストに再インポートします。この場合、再インポートと重複排除の際に何が起こるかを説明します。

重複排除の有効化

Mon, 01 Jan 0001 00:00:00 +0000

重複排除は、Product全体に対して適用することも、単一のEngagementに絞って適用することもできます。

Productに対する重複排除

サイドバーのSettings > System > ⚙️ System SettingsからSystem Settingsページに移動します(以前のメニュー構成を使用しているインスタンスではSettings > Pro Settings > System Settings)。

Deduplication and Finding Settingsカードは、System Settingsページの一番上にあります。

類似の検出事項

Mon, 01 Jan 0001 00:00:00 +0000

重複排除がインポート時に自動的に実行されるのに対し、類似の検出事項は検出事項の表示ページにある手動・対話型のツールです。現在見ている検出事項に似た、同じアセット内の他の検出事項を表示し、それらを手動で重複クラスターにリンクできるようにします。

自動的な重複排除では、本来まとめられるべきだと思う検出事項がグループ化されなかった場合や、アセット内に現在の脆弱性と似たものが他にないかを調べたい場合に使用します。

使用場所

任意の検出事項を開き、その検出事項の表示ページに移動します。下にスクロールして類似の検出事項パネルを表示します。見出しに表示されている数字は、現在の検出事項の値と一致するアセット内の検出事項の件数です。

このパネルはデフォルトで折りたたまれています。パネルの見出し(または右側のシェブロン/フィルターボタン)をクリックすると展開され、クエリが実行されます。

検出事項の照合方法

パネルを開くと、DefectDojoは現在の検出事項の値をあらかじめフィルターに入力し、同じアセット内で一致する他の検出事項を検索します。照合の初期値として使用されるフィールドは次のとおりです。

脆弱性ID(例: CVE識別子)
CWE
ファイルパス
行番号
Unique ID from tool
テストタイプ
アセット(およびアセットタイプ)

現在の検出事項は、常にそれ自身の結果から除外されます。照合の範囲はアセット単位であるため、類似の検出事項がアセットをまたいで結果を返すことはありません。いずれかのエンゲージメントでエンゲージメントレベルの重複排除が有効になっている場合、エンゲージメントの境界をまたぐ一致はリンクできません(下記のアクションを参照してください)。

これは、hash_code(またはUnique ID from tool)を比較して一致を判定する自動重複排除アルゴリズムとは異なります。類似の検出事項は意図的に広い範囲を対象とすることで、厳密なハッシュ照合では見逃してしまう関連の検出事項を発見できるようにしています。

類似の検出事項

Mon, 01 Jan 0001 00:00:00 +0000

重複排除がインポート時に自動的に実行されるのに対し、類似の検出事項はView Findingページ上の手動・対話型のツールです。現在表示している検出事項に似た、同じAsset内の他の検出事項を表示し、手動で重複クラスタにリンクできるようにします。

自動的な重複排除では、本来まとめられるべきだと思われる検出事項がグループ化されなかった場合や、現在の脆弱性に似た他の検出事項がAsset内にないか調べたい場合に使用します。

確認方法

任意の検出事項を開き、Duplicate & Similar Findingsカードまでスクロールします。このカードには2つのタブがあります。

Duplicate Findings – この検出事項に既に重複としてリンクされている検出事項(自動生成されたクラスタ)。
Similar Findings – 現在の検出事項の値と一致するものの、まだそのクラスタに含まれていないAsset内の他の検出事項。

Similar Findingsタブを選択すると、検索が実行されます。

Deduplication Tuning (Pro)

Mon, 01 Jan 0001 00:00:00 +0000

Deduplication Tuning は、検出事項の重複排除方法をきめ細かく制御できる DefectDojo Pro の機能で、特定のセキュリティテストワークフローに合わせて重複検出を最適化できます。

Deduplication Settings

DefectDojo Pro では、次の場所から Deduplication Tuning にアクセスできます。 Settings > Finding Workflow(以前のメニュー構成を使用しているインスタンスでは Settings > Pro Settings > Deduplication Settings)

過剰な重複を避ける

Mon, 01 Jan 0001 00:00:00 +0000

DefectDojoの強みの1つは、データモデルがさまざまなユースケースやアプリケーションに対応できることです。ソフトウェアを使いこなし、ワークフローを最適化する方法を見つけるにつれて、アプローチを変えていくことになるでしょう。

デフォルトでは、DefectDojoは作成された重複した検出事項を削除しません。各検出事項は、脆弱性の個別のインスタンスと見なされます。そのため、重複した検出事項は、ワークフローのプロセス変更が必要であることを示すサインになり得ます。

重複した検出事項が許容されるのはどのような場合か

重複した検出事項が必ずしも問題を示しているとは限りません。重複を保持することが望ましいアプローチとなるケースも数多くあります。たとえば:

チームがインタラクティブエンゲージメントを使用し、それについてレポートを作成している場合。特定の単一のテストに関する個別のレポートを作成したい場合、以前にすでに発見された検出事項の再発があるかどうかを知りたいはずです。
コンテキストが分離されているエンゲージメント(たとえば異なるリポジトリを対象としている場合など)がある場合、両方の場所で発生している検出事項にフラグを立てられるようにしたいはずです。

冗長なインポートの確認

ステップ1: 過剰な重複をクリーンアップする

幸いなことに、DefectDojoの重複排除設定を使用すると、一定のしきい値を超えた時点で重複を一括削除できます。この機能により、クリーンアップ作業が容易になります。このプロセスについて詳しくは、検出事項の重複排除に関する記事を参照してください <-link will go here.

ステップ2: エンゲージメントの冗長性を評価する

重複した検出事項をクリーンアップしたら、それらを含んでいた製品を確認し、明確な原因があるかどうかを調べることをお勧めします。その中に、コンテキストが冗長になっているエンゲージメントが見つかるかもしれません。

重複または再利用されているエンゲージメント

エンゲージメントは、特定のテストコンテキストのために1つ以上のテストを保存します。そのコンテキストを最終的にどう定義するかはあなた次第ですが、製品内に同じコンテキストを共有すべき複数のエンゲージメントがある場合は、それらを1つのエンゲージメントに統合することを検討してください。

エンゲージメントのコンテキストを定義する際に問うべき質問:

この作業についてレポートを作成したい場合、そのエンゲージメントには必要な関連情報がすべて含まれているか?
エンゲージメントは事前に計画的に作成しているか、それともインポートプロセスによって「アドホック」に作成されているか?
適切な種類のエンゲージメント - インタラクティブまたはCI/CD - を使用しているか?
テストが対象としているコードベースのどの部分か: 各リポジトリは個別のコンテキストなのか、それとも複数のリポジトリがテストの共有コンテキストを構成しうるのか?
その製品に関わるステークホルダーは誰で、結果をどのように共有するか?

ステップ3: 冗長なテストを確認する

同じテストコンテキストを捉えている別々のテストが作成されていることに気づいた場合、それらのテストを単一の再インポートに統合できる可能性を示すサインかもしれません。

Global Component Deduplication (Pro)

Mon, 01 Jan 0001 00:00:00 +0000

Global Component Deduplication は、参照しているコンポーネント名とバージョンに基づいてすべての Product にわたる重複した検出事項を識別する DefectDojo Pro のアルゴリズムです。これは Software Composition Analysis(SCA)ツール向けで、同じ脆弱な依存関係(例えば timespan@2.3.0)が多数の Product に登場する場合に、DefectDojo にそれらの出現を単一の元の検出事項の重複として扱わせたいときに使用します。

他の重複排除アルゴリズムとは異なり、Global Component のマッチングは単一の Product や Engagement に限定されません。Product B にインポートされた検出事項が、たとえ 2 つの Product に関連がなくても、Product A にある古い検出事項の重複としてマークされることがあります。

重複排除のチューニング(オープンソース)

Mon, 01 Jan 0001 00:00:00 +0000

DefectDojoのOpen Source版では、設定ファイルと環境変数を使用して重複排除を調整します。

関連情報: 環境変数とlocal_settings.pyによるオーバーライドの詳細については、オープンソースの設定を参照してください。

設定可能な項目

パーサーごとのアルゴリズム: Unique ID From Tool、Hash Code、Unique ID From Tool or Hash Code、Legacy(OS版のみ)のいずれかを選択します。
スキャナーごとのハッシュフィールド: 各パーサーでハッシュの計算に使用するフィールドを決定します。
null CWEの許可: ハッシュ計算時に、CWEが未設定/ゼロであることを許容するかどうかを制御します。
エンドポイントの考慮: エンドポイントがハッシュに含まれていない場合でも、任意でエンドポイントを重複排除に使用できます。
常に含めるフィールド: スキャナーごとの設定に関わらず、すべてのハッシュにフィールド(例: service)を追加します。

主要な設定項目(デフォルト値を表示)

デフォルト値はすべてdojo/settings/settings.dist.pyで定義されています。環境変数またはlocal_settings.pyで上書きできます。

Global Locations Deduplication (Pro)

Mon, 01 Jan 0001 00:00:00 +0000

Global Locations Deduplication は、共有される場所――URL、または(Package URL によって識別される)依存関係――のみに基づいて、すべての Product にわたる重複した検出事項を識別する DefectDojo Pro のアルゴリズムです。選択した種類の場所を共有する 2 つの検出事項は、タイトル、深刻度、CWE、脆弱性 ID にかかわらず重複として扱われます。場所そのものが識別子になります。

これは Global Component Deduplication の位置情報を意識した対応版であり、DefectDojo の Locations データモデルに適用されます。Global Component がコンポーネント名とバージョンのみでマッチングするのに対し、Global Locations は同じ依存関係を完全な Package URLでマッチングし、さらに共有される URL でもマッチングします。そのため、Global Component にはできない、Product をまたいだ DAST/Web の検出事項の重複排除が可能です。

ロケーションドリフトマッチング (Pro)

Mon, 01 Jan 0001 00:00:00 +0000

ロケーションドリフトマッチングを使うと、再インポート時にロケーションが変化した検出事項を同一の検出事項として認識できます。この機能がない場合、再インポートはロケーションフィールドを含む完全一致のアイデンティティハッシュで検出事項を照合するため、ロケーションが変化するたびに古い検出事項がクローズされ、同一内容の新しい検出事項が作成されてしまいます。

コミットによってコードがシフトし、検出事項の行番号が変わる。
リファクタリングによってファイルがリネームまたは移動される。
DASTスキャンの間にWebアプリケーションのURL、ポート、またはホストが変わる。
依存関係のバージョンアップにより、SCAツールが報告する脆弱なパッケージのバージョンが変わる。

これらはいずれも従来、クローズされた検出事項と「新規」検出事項の両方を生み出していました。元の検出事項が持っていたステータス、メモ、SLAクロック、リスク受容、JIRA連携が失われ、誤った「新規の重大な検出事項」というノイズが発生していたのです。ロケーションドリフトマッチングを有効にすると、検出事項は1件のまま維持されます。ロケーションは最新のスキャンで更新され、履歴は保持されます。

ロケーションドリフトマッチングはDefectDojo Proの機能です。デフォルトでは無効になっており、セキュリティツールごとに有効化します。

ロケーション追跡の有効化

ロケーション追跡はツールごとに以下の場所で設定します。 Settings > Finding Workflow > Reimport Deduplication(以前のメニュー構成を使用しているインスタンスではSettings > Pro Settings > Deduplication Settings > Reimport Deduplication)