根本原因相関 (Pro) (Pro)

40個のサービスに取り込まれた脆弱なライブラリは、40件の検出事項を生み出します。そのそれぞれが実在するものであり、それぞれが個別にトリアージされ、それぞれが同じ単一のバージョンアップによって修正されます。根本原因相関はこの関係を明示化します。DefectDojo Proは同じ根本原因を共有する検出事項を、ランク付けされた根本原因のリストにグループ化し、1つの修正とそれが解消するすべてのものを確認できるようにします。

相関は追加的で非破壊的です。すべての検出事項は個別に表示され続け、それぞれのステータスを保持し、これまでと全く同じようにトリアージされます。相関は検出事項間のリンク、そのリンクが集約されるクラスタノード、そして各リンクを生成した根拠を追加するだけです。

相関は重複排除ではありません。 重複排除 は、2件のレポートが同一の検出事項を記述していると判断し、一方を重複としてマークします。相関は 同じ原因を共有する異なる検出事項を関連付けるものであり、何かを重複としてマークすることは決して ありません。両者は独立して動作し、どちらも有効にできます。

根本原因相関の有効化#

根本原因相関はベータ版であり、機能フラグの背後に置かれ、デフォルトで無効になっています。 スーパーユーザーは、Cloud版とオンプレミス版の両方のインスタンスで設定 > 機能フラグからこれを 有効にできます。機能フラグを参照してください。

フラグが無効の間、エンジンは一切の処理を行いません。クラスタは構築されず、リンクも作成されず、 インポート後に何もディスパッチされません。

フラグを有効にした後も、既存の検出事項は次にインポートされるか、バックフィルを実行するまでは、 遡って相関付けされることはありません(既存の検出事項のバックフィルを参照)。

何が相関付けられるか#

相関は4つのシグナルに基づいてグループ化します。そのうち3つは完全一致であり、2件の検出事項が 本当に同じものを指している場合にのみリンクが作成されます。残る1つはヒューリスティックとして 明示されます。

検出事項は該当するすべてのクラスタに参加します。1つだけではありません。3つのCVEを含む log4j-core 2.14.1のSCA検出事項は、4つの根本原因に参加します。コンポーネントクラスタ1つと、 CVEごとのクラスタです。これにより、CVEのみを報告するコンテナイメージの検出事項が、コンポーネント を報告するSCA検出事項と相関付けられるのです。

コンポーネントの一致#

Locationsデータモデルが使用されている場合、コンポーネントは修飾子とサブパスを取り除いた **Package URL(purl)**でキー化されるため、異なるディストリビューションやアーキテクチャに対して 報告された同じパッケージは、複数ではなく1つのクラスタを形成します。従来のcomponent_name/ component_versionフィールドのみを持つ検出事項は、代わりにそれらのフィールドでキー化されます。

使用可能なコンポーネントを持たない検出事項は、グループ化されずにスキップされます。バージョンが 欠落している場合や、一部のSBOM形式が出力するunknown-packageというプレースホルダーをそのまま 扱うと、コンポーネントを持たないすべての行が1つの無意味なクラスタにまとめられてしまうためです。

CVEの一致#

CVE識別子は大文字化およびトリムされるため、cve-2021-44228とCVE-2021-44228は同じクラスタに 入ります。一致するのはCVE識別子のみです。GHSA、GO、RUSTSECなどの他のアドバイザリの接頭辞は、 DefectDojoの他の箇所では脆弱性IDとして認識されますが、まだ根本原因を形成しません。

リソースの一致#

クラウドポスチャー(CSPM)およびInfrastructure as Code(IaC)ツールは、パッケージではなく リソースを報告します。S3バケット、Kubernetesネームスペース、Terraformリソースブロックなど です。これらの検出事項は名前を持ちますがバージョンは持たないため、ソフトウェアコンポーネントで はなく、そのようには一致付けされません。

リソースの一致は、大文字小文字を統一したリソース識別子でグループ化するため、表記の異なるツール 間でも一致します。これは完全一致による結合であり、これによりaws_s3_bucket.logsに関するIaCの 検出事項が、デプロイ済みバケットに関するランタイムCSPM検出事項と同じ根本原因に含まれるように なります。

一致するのは修飾された識別子のみです。リソース名には型やパスの区切り文字(.、/、:)が 含まれます。単なる単語1つは無視されるため、スキャナーが単にコンポーネントのバージョンを省略した だけの検出事項が、無関係なリソースクラスタに巻き込まれることはありません。

エンドポイントの一致#

同じアプリケーションをスキャンする2つのDASTツールは、多くの場合、同じURLで同じ弱点を報告します。 エンドポイントの一致はこれらをグループ化します。根本原因は特定の場所における弱点クラスで あり、例えばCWE-79 at example.com/searchのようになります。

これは唯一のヒューリスティックなシグナルであり、表示されるすべての場所でその旨が明示されます。 共有されるpurlやCVEは同一性を示しますが、「同じCWE、同じURL」は判断であり、レビュー担当者はそれを 異なる重みで評価できるべきです。クラスタの詳細には、各メンバーにその一致方法が示されます。

CWEは必須です。URL単体は場所であって原因ではありません。何が問題であるかに関係なく/searchに あるすべての検出事項をグループ化すると、巨大で無意味なクラスタが生まれてしまいます。

URLを比較する際、クエリ文字列、フラグメント、ポートは無視されます。そのため/search?q=aと /search?q=bは同じ場所として扱われ、同じサービスであれば443番ポートと8443番ポートも同様に 扱われます。

これはSASTとDASTを相関付けるものではありません。 静的検出事項はソースファイルを特定し、 動的検出事項はURLを特定します。両者間のマッピングには、DefectDojoが持っていないルートマップが 必要です。エンドポイントの一致は動的検出事項同士を関連付けます。

CVEがすでにコンポーネントによってカバーされている場合#

検出事項はそのコンポーネント原因と各CVE原因の両方に参加するため、2つのCVEを含む log4j-core 2.14.1のSCA検出事項は、3つの根本原因を生み出します。そのままにしておくと、この3つ すべてがランク付けリストの上位を争うことになりますが、実際に対応すべき作業は1つだけです。 log4j-coreを修正済みバージョンに更新すれば、両方のCVEが完全に解消され、「CVE-2021-44228を 修正する」という別個の対応は必要ありません。

そのため、CVEの根本原因は、そのアクティブなメンバー検出事項のすべてが、単一のコンポーネント またはリソース原因のアクティブなメンバーでもある場合に、カバー済みとマークされます。カバー 済みの原因はデフォルトで根本原因ページから非表示になり、リストには実際に対応可能なものだけが 残ります。

1つでもメンバーがそのコンポーネントの外にある瞬間、CVEは再び独立したものとなります。これが まさに、コンポーネントを伴わずCVEのみを報告するコンテナイメージの検出事項です。コンポーネントの 修正はそこには及ばないため、そのCVEは実際に別個の作業となります。これはまさに、相関機能が明らか にするために存在するクロスドメインのケースであり、決して非表示にはなりません。

テーブルの上にあるカバー済みのCVEを表示をオンにすると、それらを確認できます。それぞれには、 カバーしている原因がラベル付けされているため、どの修正で解消されるかが明確です。カバー済みの 原因はデフォルトのリストから非表示になっているだけです。メンバー、根拠、フィードバックはそのまま 保持され、検出事項の根本原因パネルから引き続きアクセスでき、保存したリンクも問題なく開けます。

カバー状況は実行のたびに双方向で再評価されます。カバーされていない検出事項が出現すると、CVEは 直ちにカバー済みでなくなり、その検出事項が修正またはトリアージによって取り除かれると、再びカバー 済みになります。リンクを却下すると、そのメンバーも計算から除外されます。それは属していないと 判断したことになるためです。

コンポーネントおよびリソースの原因は、そのメンバーが他の原因と重複していても、決してカバー済み とはマークされません。それぞれに更新すべき独自のバージョンがあるため、それぞれが実際の作業と なります。

対象となる検出事項#

相関付けの対象となるのは、有効で対応可能な検出事項のみです。検出事項は、非アクティブ、緩和済み、 重複、誤検知、対象外、またはリスク受容済みの間は除外されます。検出事項はトリアージされると クラスタから外れるため、根本原因の件数は常に未対応の作業を表します。

根本原因ページの見方#

サイドバーの管理セクションで根本原因を開きます。このページには、アクセス権のあるすべての 根本原因が、最も大きくリスクの高いものから順に並べて一覧表示されます。

コンポーネントまたはリソースの原因によって完全にカバーされているCVE原因は、カバー済みのCVEを 表示がオンでない限り非表示になります。CVEがすでにコンポーネントによってカバーされている場合を参照してください。

行を選択するとクラスタが開き、各メンバー検出事項がその深刻度、製品、ドメイン、一致方法、 そしてそれをリンクさせている根拠とともに一覧表示されます。根拠はリンクごとに記録されるため、 クラスタは常に自らを説明できます。コンポーネントのリンクは一致したpurlを記録し、CVEのリンクは 識別子を記録し、エンドポイントのリンクはURLとCWEを記録します。一致列には、コンポーネント、 CVE、リソースのリンクにはexact、エンドポイントのリンクにはheuristicと表示されるため、判断が 同一性として提示されることは決してありません。

総合リスクは、アクティブなメンバーの深刻度(重大100、高70、中40、低10、情報1)を合計した決定論的 な値です。優先順位付けエンジンが有効かどうかには依存しません。

修正はメンバー自身の修正バージョンから取得され、報告しているすべてのメンバーが同じバージョン を報告している場合にのみ表示されます。スキャナー間で意見が一致しないことがあり、CVEクラスタは それぞれ異なるバージョンで修正されるコンポーネントにまたがることがあるため、単一の答えが存在 しない場合、この列は何かを選ぶのではなく空欄のままにされます。

表示される内容はアクセス権に応じて制限されます#

メンバー、件数、影響範囲は、閲覧を許可されている検出事項に絞り込まれ、ランキングはそのフィルタ リングの後に計算されます。そのため、製品へのアクセス権が異なる2人のユーザーは、同じ根本原因に 対して異なる件数を目にすることになり、メンバーを閲覧できないクラスタはそのユーザーには全く表示 されません。

相関が表示されるその他の場所#

検出事項上での表示#

検出事項自体のページには、それが属するすべてのクラスタを一覧表示する根本原因パネルがあり、 脆弱なコンポーネント(またはリソース)と共有するCVEに分けて表示されます。これは通常、相関が最も 役立つ場面です。すでに1件の検出事項をトリアージしている最中に、その修正が共有されていることが 分かるからです。却下したリンクはそこに再表示されません。

検出事項の優先順位での利用#

多くの製品にまたがる根本原因は、単一の修正がそのすべてを解消するため、そのメンバーである各検出 事項をより緊急性の高いものにします。したがって優先度は、検出事項が属する最も影響範囲の広い 根本原因の影響範囲に応じて上昇します。

• 1つの製品に限定されたクラスタは何も加算しません。「1つの修正で多くが解消される」という ストーリーが存在しないためです。
• 影響を受ける製品が追加されるごとに、上限まで少しずつ加算されるため、非常に広範な1つのクラスタ が深刻度を上回ることはありません。
• カウントされるのは最も広範なクラスタであり、すべての合計ではないため、多くのCVE IDを持っている というだけで検出事項の優先度が押し上げられることはありません。
• 却下したリンクはカウントされなくなります。ミュートされたクラスタは引き続きカウント されます。ミュートはランク付けリストから非表示にするだけであり、検出事項が無関係であることを 意味するものではありません。

この重みは、優先順位付けエンジンにおいて、深刻度、悪用可能性、エンドポイント、到達可能性と並ぶ 相関乗数として、製品ごとに調整可能です。機能フラグが無効の場合、この項全体が消えるため、 相関を使用しないインスタンスではスコアに変化はありません。

ダッシュボード上での表示#

上位の根本原因はダッシュボードウィジェットとして利用でき、最も上位にランクされたクラスタを、 検出事項数、影響を受ける製品、リスクとともに一覧表示します。ウィジェットピッカーから追加して ください。このウィジェットは機能が有効な間のみそこに表示されます。その件数は、ページと同様に アクセス権に応じて制限されます。

クラスタへのフィードバック#

相関はあなたのデータに関する判断であるため、それを修正することができます。

• メンバーを確認すると、そのリンクが正しいことを記録します。
• メンバーを却下すると、それが正しくないことを記録し、クラスタのアクティブなメンバーリスト から除外されます。
• 根本原因全体をミュートすると、ランク付けリストでの注目を集めなくなります。ミュート解除 で元に戻ります。

フィードバックは永続的です。通常の再インポートによる変動、例えば検出事項が緩和され後で再度 アクティブになるといったことでは、確認や却下が消えることはなく、ミュートされたクラスタは一時的 にメンバーがいなくなっても削除されることはありません。システムが自動的に作成したリンクのみが、 該当しなくなった時点で調整され取り除かれます。

相関の実行タイミングと方法#

相関は、インポートの影響を受けた検出事項に対して、すべてのインポートおよび再インポートの後に 自動的かつ非同期に実行されます。これはベストエフォートであり、相関処理内で発生した失敗はログに 記録された上で無視され、それを引き起こしたインポート自体を失敗させることはありません。

べき等であるため、同じ検出事項に対して再実行しても、何かが重複することなく同じ結果に収束します。 検出事項が変化すると、エンジンは調整も行います。コンポーネントのバージョンが更新されると、検出 事項は新しいクラスタに移動し、古いクラスタは空になった時点で削除されます。

既存の検出事項のバックフィル#

機能が有効になる前から存在する検出事項を相関付けるには、管理コマンドを実行します。引数を省略 するとポートフォリオ全体が再計算され、単一の製品に絞り込むこともできます。

python manage.py recompute_correlations
python manage.py recompute_correlations --product-id 42

APIが公開する内容#

根本原因は標準APIを通じて読み取り可能であるため、UIを経由せずにレポートに取り込んだり、そこから チケットを起票したり、メトリクスとして追跡したりできます。

• GET /api/v2/root_causes/ は、ページと同じ方法でランク付けされた一覧を返します。
• GET /api/v2/root_causes/{id}/ は、1つの根本原因とそのメンバー検出事項を返します。各検出事項 には、それをリンクさせる根拠と、一致が完全一致かヒューリスティックかが含まれます。

両方とも読み取り専用です。確認、却下、ミュートは現時点ではUIから行います。これらは機能がベータ版 である間は意図的に公開されておらず、後で追加してもすでに構築済みのものを壊さないようにするため です。

一覧に対するフィルタ: cause_type(exactまたはin)、muted、identity_key(exactまたは icontains)、display_name__icontains。

スクリプトを組む前に知っておくべき2つの挙動があります。

• 件数はトークンのアクセス権に応じて制限されます。これはUIと全く同じです。製品へのアクセス 権が異なる2つのトークンは、同じ根本原因に対して異なるactive_member_count、product_count、 risk_scoreを返します。これは意図的な動作です。これらの数値はその呼び出し元が閲覧できる 内容を表しているため、ポートフォリオ全体の合計として扱わないでください。
• カバー済みのCVE原因は一覧から除外されますが、常にIDによる取得は可能です。 ?include_subsumed=trueを渡すとそれらを含めることができます。以前に保存した根本原因のIDは、 カバー済みになった後でもGET /api/v2/root_causes/{id}/を通じて引き続き機能します。カバー済み の各原因にはsubsumed_by_idとsubsumed_by_nameが含まれており、どの修正で解消されるかを確認 できます。

機能フラグが無効の場合、両方のエンドポイントは404ではなく403を返します。エンドポイント自体 は存在しますが、単に有効になっていないだけです。

グローバルコンポーネント重複排除との連携#

グローバルコンポーネント重複排除 は、製品をまたぐSCA検出事項を重複としてマークし、重複は相関付けされません。そのため両方の機能を 有効にすると、根本原因のメンバー数は、すべての出現ではなく、残存するオリジナルを反映することに なります。この2つはキーとする対象も異なります。グローバルコンポーネントはコンポーネント名と バージョンで一致させるのに対し、相関は完全なPackage URLを使用します。そのため両方を有効にする ことはサポートされていますが、それぞれが算出する件数を直接比較することはできません。