検出事項の概要

検出事項(Findings)は、DefectDojoがセキュリティツールのレポートおよび修復プロセスを標準化し導くための主要な手段です。脆弱性がSonarQube、Acunetix、あるいはチーム独自のツールのいずれで報告された場合でも、検出事項を使うことですべての脆弱性を同じ方法で管理できます。

検出事項とは#

DefectDojoにおける検出事項は、以下の要素で構成されています。

• 報告された該当の脆弱性データ
• 検出事項の「ステータス」。修復状況、リスク受容、その他その脆弱性に関して下された判断を追跡するために使用されます
• 検出事項に関連するその他のメタデータ。例えば、ネットワーク内での検出事項の場所、ツールによる修復方法の提案、関連するCWEやEPSSスコアへのリンクなどが含まれます。

脆弱性データを保存し修復のためのフレームワークを提供することに加えて、DefectDojoは以下の方法でも検出事項を強化します。

• 悪用可能性を示す関連EPSSスコアを検出事項に自動的に追加する
• セキュリティツールの深刻度指標を各検出事項の深刻度スコアに自動的に変換し、製品のSLA設定に応じて検出事項にSLAを付与する

全体として、DefectDojoの検出事項は製品階層と連携して機能するよう設計されており、取り組みを標準化し、各製品に一貫した手法を適用します。

検出事項ページ#

検出事項ページにはさまざまな要素が含まれています。それぞれの要素は、検出事項の作成時に行われるインポート処理によって入力されます。

1. 検出事項のタイトル: 通常、検出された脆弱性や問題を識別するための簡潔な説明です。このセクションには、ユーザーが作成したタグが存在する場合、それも表示されます。 ​
2. 検出事項の概要: このセクションには、検出事項に関連する情報を記載した5つのページが含まれます。説明、緩和策、影響、参考情報、メモです。これらのフィールドは、取り込まれた脆弱性データに基づいて自動的に入力される場合もあれば、追加のコンテキストを提供するためにDefectDojoのユーザーが編集する場合もあります。 ​

• ​説明は、該当する検出事項についてのより詳細な要約と説明です。
• ​緩和策は、システムから検出事項を解消するために提案される対処方法です。
• ​影響は、脆弱性がセキュリティ体制に与える影響を説明します。このページには説明テキストが記載されている場合もあれば、CVSSベクター文字列が含まれる場合もあります。これは、脆弱性全体の悪用可能性と、悪用された場合に組織へもたらされる結果を簡潔に伝える表記法です。影響は検出事項の深刻度フィールドと密接に関連しています。
• ​参考情報には、この検出事項に関連するリンクやその他の情報が含まれている場合に一覧表示されます。
• ​メモは、この検出事項に関するその他の関連情報を記録できるページです。メモは「DefectDojo専用」のメタデータであり、インポート時に作成されるものではありません。このフィールドを使って、修復の進捗を追跡したり、検出事項により具体的な詳細を追加したりできます。 ​

3. 追加の詳細: 該当する場合、このセクションにはこの検出事項に関連するその他の詳細が一覧表示されます。

   • 脆弱性に関連するリクエスト/レスポンスのペア
   • 脆弱性を再現する手順
   • 検出事項の深刻度や影響についてより詳細な説明を記録できる深刻度の根拠 ​

4. メタデータ: このセクションには、検出事項に関連するフィルタ可能なメタデータが含まれます:

   • ID: DefectDojo内での検出事項のID値
   • 深刻度: 検出事項の深刻度の値。情報、低、中、高、重大のいずれかです。検出事項の深刻度は、検出事項が保存されている製品に基づいて計算されるSLAと直接関連しています。
   • ステータス: 検出事項のステータス。アクティブまたは非アクティブのいずれかです。これらに加えて、検出事項には重複、緩和済み、誤検知、対象外、リスク受容済み、または不具合レビュー中というステータスを設定することもできます。これらのステータスは、検出事項の状態をより詳細に説明します。
   • タイプ: このフィールドは、検出事項がどのように発見されたか、つまりソースコードの静的(SAST)評価によるものか、実行中の製品の動的(DAST)評価によるものかを示します。このフィールドはツールの種類によって定義されます。
   • 場所: 該当する場合、脆弱性に関連するファイルパスを示すフィールドです。
   • 行: 該当する場合、脆弱性を含むコードの行を示すフィールドです。
   • 発見日: 検出事項がDefectDojoにインポートされた日付、またはツールによって検出事項が発見された日付を示すフィールドです。
   • 経過日数: この計算フィールドは、検出事項がアクティブである日数を示します。
   • 報告者: この検出事項を作成したDefectDojoアカウントのユーザー名です。
   • CWE: この検出事項に該当する外部のCWE(共通脆弱性タイプ一覧)定義へのリンクとなるフィールドです。
   • 脆弱性ID: ツール自体の中でこの脆弱性に特定のID値がある場合、ここで追跡されます。
   • EPSSスコア / パーセンタイル: ソースデータにCWEの値がある場合、DefectDojoは自動的にEPSSスコアとパーセンタイル(Exploit Prediction Scoring System)を取得します。EPSSは、実際の悪用データに基づいて、ソフトウェアの脆弱性が悪用される可能性を表します。EPSSスコアは、First.orgの最新の悪用データを使用して継続的に更新されます。
   • 検出方法: この脆弱性の検出に使用されたスキャナーが一覧表示されます。 ​

メモと@メンション#

検出事項のメモページは、取り込まれたスキャンデータには含まれないコンテキスト、つまり修復の進捗状況、トリアージの判断、その他のコメントをチームが記録する場所です。メモはDefectDojo専用のメタデータであり、インポート時に作成されることはありません。

メモは新しい順のフィードとして表示され、古い順に並べ替えることもできます。各メモには、作成者、作成日時、メモの種類が表示され、メモが非公開の場合は非公開バッジが表示されます。非公開のメモは、それを書いた本人にのみ表示されます。

Markdownでメモを書く#

メモの項目はMarkdownをサポートしているため、見出し、太字や斜体のテキスト、箇条書きや番号付きリスト、引用ブロック、表、リンク、囲み(フェンス)コードブロックを使用できます。メモのエディタは検出事項の説明で使用されるものと同じで、よく使う書式オプション用のツールバーが付いています。メモを書式付きテキストではなく、入力したとおりの内容として読むには、メモ本文の右上にあるトグルを使用します。

編集、削除、履歴#

すべてのメモには編集、履歴を表示、削除を含むアクションメニューがあり、各項目はそれを使用する権限がある場合にのみ表示されます。

• 自分が書いたメモは、常に編集、削除、履歴の閲覧が可能です。
• 他のユーザーのメモを管理するには、そのメモが属するオブジェクトに対応するロール権限(メモの編集、メモの削除、またはメモの履歴閲覧)が必要です。
• メモの追加には「メモの追加」権限が必要で、これはリーダーより上のすべてのロール、およびリーダー自身も保有しています。

編集されたメモには**(編集済み)**というラベルが付き、誰がいつ変更したかが記録されます。履歴を表示では、メモのすべての改訂履歴が新しい順に一覧表示されるため、メモが書き直されても内容が失われることはありません。変更できるのは項目そのものだけです。メモの種類と非公開フラグは、メモが作成された時点で固定されます。

@でユーザーをメンションする#

メモを追加する際、他のDefectDojoユーザーを**@メンションして通知することができます。メモ内の任意の場所で @ の直後にユーザー名を続けて入力してください(例: @alice)。メモを保存すると、メンションされた各ユーザーに、そのメモへのリンクを含むuser-mentioned**通知が届きます。

知っておくべき点がいくつかあります。

• @ はメモの先頭にあるか、スペースの直後にある必要があります。これは意図的な仕様で、文中に書かれたメールアドレス(alice@example.comなど)が誤ってメンションとして扱われるのを防ぐためです。
• @ の後の名前は、既存かつアクティブなDefectDojoのユーザー名と一致する必要があります。存在しないユーザーや無効化されたユーザーへのメンションは無視されます。
• 末尾のピリオドは無視されるため、文を終える形のメンション(thanks @alice.)も正しく解決されます。
• 1つのメモの中で複数のユーザーをメンションすることもできます。

検出事項、テスト、エンゲージメント、リスク受容のメモでは、UIから@メンションを行うことができます。@ と入力すると一致するユーザーの一覧が表示されます。通知の検索が期待する形式でユーザー名が正確に挿入されるため、その一覧から選択するのが確実な方法です。

このメンションはuser_mentioned通知イベントを通じて配信されます。通知の配信方法と設定方法については通知を参照してください。特に、user_mentionedは、ユーザーが通知を全体的にオフにしている場合でも、システムレベルの設定によって配信され得るイベントの1つです(個別の上書き設定を参照)。

検出事項ワークフローの例#

DefectDojoでの検出事項の扱い方は、組織内でのチームの役割によって異なります。以下はそのプロセスの例と、DefectDojoがどのように役立つかを示したものです。

脆弱性の発見とレポート#

さまざまなコンテキスト、ソフトウェア製品、チームにわたるセキュリティレポートを担当している場合、DefectDojoは発見された脆弱性についてレポートを作成できます。製品階層を使うことで、検出事項のデータを適切なコンテキストに整理できます。例えば次のとおりです。

• DefectDojo内の各製品はそれぞれ異なるSLA設定を持つことができるため、本番環境やその他の機密性の高い環境で発見された検出事項に即座にフラグを立てることができます。
• 製品タイプ、製品、エンゲージメント、またはテストから直接レポートを作成し、セキュリティのコンテキストを「ズームイン・ズームアウト」できます。テストは単一のツールの結果を含み、エンゲージメントは複数のテストをまとめることができ、製品は複数のエンゲージメントを含むことができ、製品タイプは複数の製品を含むことができます。

レポートの作成に関する詳細は、**カスタムレポート**のガイドを参照してください。

検出事項のステータスを使った脆弱性のトリアージ#

チームが発見された検出事項を検証する必要がある場合、レビューの際に検出事項に手動で検証済みステータスを適用することでこれを行えます。その他にも、次のようなステータスを適用できます。

• 誤検知: ツールが脅威を検出しましたが、その脅威は環境内でアクティブではありません。
• 対象外: アクティブではあるものの、現在のテスト対象には関連がありません。
• リスク受容済み: アクティブではあるものの、リスク受容の期限が切れるまでは対応の優先度が低いと判断されたものです。
• レビュー中: アクティブかどうかはまだ分からず、チームが調査を続けています。
• 緩和済み: 検出事項が作成されて以降、この問題は解消されています。

ツールが以前にトリアージ済みの検出事項を後続のインポートで再度報告した場合、DefectDojoはその検出事項の以前のステータスを記憶し、それに応じて更新します。誤検知、対象外、リスク受容済み、レビュー中のステータスを持つ検出事項はそのままのステータスを維持しますが、緩和済みになっていた検出事項は、それがテスト環境に再び現れたことを知らせるために再アクティブ化されます。

リスク受容によるチーム全体の合意形成と説明責任の確保#

セキュリティチームの責務の一部には、開発者と協力してセキュリティ問題の修復に優先順位をつけたり、優先度を下げたりすることが含まれます。ここでリスク受容の出番です。検出事項にリスク受容を追加すると、次のことが可能になります。

• DefectDojoに記録や「証跡」ファイルを保存する。これには、リスク受容を承認する同僚からのメール、会議の議事録、あるいは自分のセキュリティチームによるリスク受容の根拠を記した文書などが含まれます。
• リスク受容に有効期限を設定し、一定期間後にその脆弱性を再検討できるようにする。

Appsecチームのメンバーであれば誰もが、問題の修復を開発チームだけの優先順位付けに委ねることはできないと理解しています。そのため、リスク受容はこうした重要な判断が下された際にそれを記録する助けとなります。

CVEとEPSSスコアを使った現在の脆弱性の監視(Proの機能)#

既知の脆弱性がもたらす悪用可能性や脅威は、新しいデータに基づいて変化することがあります。作業を最新の状態に保つため、DefectDojo Proは First.org と提携し、検出事項に関連する最新のEPSSスコアのデータベースを維持しています。DefectDojo Pro内の検出事項は、その検出事項のCVEに直接基づくEPSSに従って自動的に最新の状態に保たれます。

検出事項のEPSSスコアが変化した場合(つまり、関連する検出事項の悪用可能性が高くなったり低くなったりした場合)、検出事項の深刻度もそれに応じて調整されます。