誤検知履歴

誤検知履歴は、チームが同じ誤検知を何度も繰り返しトリアージする手間を省きます。この機能が有効になっている状態で検出事項がインポートされると、DefectDojoは同じ製品内に一致する既存の検出事項がないかを探し、それらのいずれかがすでに誤検知としてマークされている場合、受信した検出事項も誤検知としてマークされます。

この機能は製品内で実験的機能としてマークされており、重複排除と同時に使用することはできません。 有効にする前に、使用できる場合をお読みください。

この機能の動作#

スキャナーがある検出事項を報告し、チームがそれを調査して誤検知としてマークしたとします。その後のすべてのスキャンで、同じ検出事項が再び現れます。通常であれば、そのたびに誰かがそれを却下する必要があります。誤検知履歴が有効になっていると、DefectDojoは再発した検出事項を認識し、自動的に誤検知としてマークします。

このようにマークされた検出事項は、誤検知だけでなく非アクティブおよび未検証にも設定されます。これは意図的な動作であり、検出事項はアクティブなキューから完全に外れることになりますが、誤検知フラグだけが変わると考えている人にとっては驚きになることがあります。

DefectDojoが維持しているルールは次の通りです: 製品内で、ある検出事項が誤検知であれば、一致するすべての検出事項も誤検知である。

遡及モード#

遡及的誤検知履歴は、同じルールを逆方向にも適用します。ある検出事項を誤検知としてマークすると、その製品内で一致する他のアクティブな検出事項もすべて誤検知としてマークされます。

これは既存のデータを書き換える動作です。プレビューや確認プロンプトはなく、変更は製品全体にわたって即座に適用されます。この機能は慎重に判断した上で有効にしてください。

使用できる場合#

誤検知履歴と重複排除は相互に排他的です。 この2つは重複する問題を解決するものであるため、DefectDojoは両方を同時に実行することを許可していません。システム設定では、一方を有効にするともう一方はグレーアウトされ、重複排除を有効にすると誤検知履歴の設定はクリアされます。

これはこの機能について理解すべき最も重要な点です。ほとんどのインスタンスは重複排除を実行しており、その場合、誤検知履歴は利用できません。この機能は、意図的に重複排除を行わないことを選択したインスタンス向けのものです。

有効化する#

両方の設定はシステム設定の重複排除ブロックにあり、どちらもデフォルトではオフになっています。

これらはインスタンス全体に適用される設定です。製品ごとやツールごとの上書きはできません。有効にすると、インスタンス上のすべての製品に影響します。

何が一致とみなされるか#

誤検知履歴は、2つの検出事項が「同じ」であるかどうかを、重複排除機能自体はオフにする必要があるにもかかわらず、それらを報告したツールに設定されている重複排除アルゴリズムを使って判定します。

したがって、この機能の精度は、そのツールの重複排除がどれだけ適切に設定されているかによって完全に決まります。誤検知履歴を有効にする前に、ツールのアルゴリズムとハッシュフィールドを調整してください。 重複排除のチューニング(Pro)または重複排除のチューニング(Open Source)を参照してください。

照合は製品内に範囲が限定されます。製品をまたいで及ぶことはなく、インスタンス全体に適用されることもありません。

セットベースの照合(Pro)#

DefectDojo Proでは、照合はセットベースのハッシュコードフィールドも考慮します。これは脆弱性IDとCWEのマッチャー(vulnerability_ids_partial、vulnerability_ids_subset、cwes_partial、cwes_subset、およびそれらの完全一致形式)であり、重複排除におけるものと同じ意味を持ちます。

これにより、Proの照合はOpen Sourceよりも狭くなりますが、それこそがポイントです。この仕組みがなければ、誤検知履歴は、同一ツールの重複排除では重複とすら見なされなかったはずの検出事項にまで誤検知を複製してしまう可能性があります。この絞り込みは、マークされる検出事項の集合を減らす方向にしか働きません。Proを有効にしても、自動的にマークされる検出事項が増えることは決してありません。

Open Sourceでは、照合はハッシュコードのみを使用するため、より広範囲になります。チューニングの際はこの点に留意してください。

有効にする前に理解しておくべきリスク#

この機能は、人間が確認することなく検出事項を誤検知としてマークします。その影響範囲は重複排除の設定によって決まるため、設定が緩いと危険です。

• 照合キーが緩いと、関係のない検出事項が気づかないうちに却下されることがあります。 レガシーアルゴリズムはタイトルと深刻度だけで一致を判定するため、1回の誤検知判定によって、製品内の同じタイトル・同じ深刻度を持つすべての検出事項が、本物の脆弱性を含めて誤検知としてマークされる可能性があります。ハッシュコードフィールドの範囲が広すぎる場合も同様です。まずアルゴリズムを厳密にしてください。
• 遡及モードは、プレビューもプロンプトも、変更内容の要約もないまま既存の検出事項を書き換えます。
• 検出事項は単にフラグが立てられるだけでなく、非アクティブ化かつ未検証にされます。
• この一括更新は通常の保存時処理をバイパスするため、検出事項の更新に反応する自動化処理が、この方法で変更された検出事項に対しては発火しないことがあります。
• DefectDojo自体において、この機能は依然として実験的機能とラベル付けされています。

ほとんどのチームにとってより安全なパターンは、誤検知履歴に切り替えるのではなく、重複排除を有効なままにして、重複した検出事項がオリジナルの検出事項からステータスを引き継ぐようにすることです。重複排除についてを参照してください。