リスク受容 (Open Source)

リスク受容は、検出事項に適用できる特別なステータスで、直ちに修復せずに検出事項を承認するという判断を正式に文書化し、運用に反映させるためのものです。

DefectDojo Pro とは異なり、OS 版 DefectDojo のリスク受容は独立したオブジェクトではありません。リスク受容はエンゲージメントにのみ紐づいており、そのため、リスク受容が属するエンゲージメント内の検出事項のみを含めることができます。同じ検出事項が3つの異なるエンゲージメントのテストにそれぞれ出現する場合、それらの検出事項をすべて受容するには3つの異なるリスク受容が必要になります。

Accessing Risk Acceptances#

リスク受容には、各エンゲージメント内の特定のテストに関連する検出事項が含まれます。そのため、それらの検出事項の元になったテストを含むエンゲージメントからアクセスできます。

リスク受容された個々の検出事項の全リストは、サイドバーの検出事項セクション内のリスク受容済み検出事項サブメニューで確認できます。

Creating Risk Acceptances#

検出事項がリスク受容されると、以下のことが発生します。

• 検出事項のステータスは「アクティブ」ではなくなりますが、引き続き検索、レポート作成、監査の対象となります。
• 検出事項のステータスは「リスク受容済み」に変更されます。
• 検出事項はメトリクスに含まれなくなりますが、元になったテスト内には引き続き表示されます。

検出事項をリスク受容する方法は2通りあります。完全リスク受容に手動で追加する方法と、簡易リスク受容ワークフローを使用する方法です。

Full Risk Acceptances#

完全リスク受容を使用すると、ユーザーはエンゲージメント内の複数の検出事項のリスクを受容し、それらを1つの単位にまとめることができます。組織のポリシーで正式な文書化されたリスク受容が求められる場合や、リスク受容の期限が切れた際に特定のアクションをトリガーしたい場合には、完全リスク受容が最適です。社内の意思決定プロセスを記録し、信頼できる情報源として機能させることができるためです。

各完全リスク受容には、以下のような追加のコンテキストが付加されます。

• リスク受容の名前。
• リスク受容の所有者。
• 検出事項の扱いに関するセキュリティ上の推奨事項および決定事項。
• 推奨事項または決定に関連する証跡。
• 推奨事項または決定に関する詳細。
• その決定に関連するリスクを受容するユーザー。
• 有効期限。
  • 期限切れ時に検出事項のステータスを「アクティブ」に戻すかどうか。
  • 期限切れ時にSLAを再開するかどうか。

有効期限は完全リスク受容に固有の機能で、リスク受容された検出事項を適切なタイミングで再検討できるようにします。完全リスク受容の期限が切れると、検出事項は再びアクティブに設定されます。日付を指定しない場合、システム設定ページのデフォルトのリスク受容/デフォルトのリスク受容期限が使用されます。

重要な点として、完全リスク受容は個々のエンゲージメントに限定されるため、すべての完全リスク受容を一覧表示する単一のセクションはありません。完全リスク受容は、それに含まれる検出事項を持つ該当のエンゲージメント内でのみ表示できます。

How to Create a Full Risk Acceptance#

完全リスク受容を作成するには、エンゲージメントビューに移動し、リスク受容ボックス内の**+**記号をクリックします。

そこから、完全リスク受容の詳細を入力し、含める検出事項を選択します。受容された検出事項には、リスク受容に追加できるすべての検出事項のドロップダウンリストが含まれます。エンゲージメント内の検出事項のリストは深刻度の降順(重大な検出事項が上、低の検出事項が下)で表示されます。検出事項が以前にリスク受容されている場合、ドロップダウンリストには表示されません。

完了すると、完全リスク受容はエンゲージメントビューのリスク受容ボックス内に表示されます。

リスク受容は、個々の検出事項の⋮ケバブメニューからリスク受容を追加ボタンをクリックして作成することもできます。

Interacting with Full Risk Acceptances#

完全リスク受容が作成されると、それを開いて、追加された検出事項や作成時に入力された詳細情報(日付、所有者、決定内容、有効期限など)を確認できます。

完全リスク受容から検出事項を削除するには、受容された検出事項のテーブル内の削除ボタンをクリックします。

完全リスク受容のビューには、そのエンゲージメント内のテストにある他のすべての検出事項を表示するテーブルも下部に含まれています。そこから、追加の検出事項を選択してその完全リスク受容に追加できます。

さらに、ユーザーが完全リスク受容に追加のコンテキストを含めることができるメモ機能があります。公開メモはすべて、その完全リスク受容に対して生成されるレポートに表示されます。非公開に設定されたメモは、作成者とスーパーユーザーのみが閲覧でき、レポートには含まれません。

重要な点として、完全リスク受容が完全に削除されると、その中の検出事項のステータスは自動的に「アクティブ」に戻ります。

Simple Risk Acceptances#

完全リスク受容はデフォルトで有効になっていますが、簡易リスク受容はアセットの作成時、またはアセットの設定内で手動で有効にする必要があります。

簡易リスク受容は、以下の2つの方法のいずれかで実行できます。

1. テストビュー内で、検出事項テーブルから1つ以上の検出事項を選択した後に表示される一括編集メニューを使用する。

2. 個々の検出事項の⋮ケバブメニューからリスクを受容をクリックする。

検出事項が簡易リスク受容されると、テストの検出事項テーブルには引き続き表示されますが、ステータスは非アクティブ、リスク受容済みに変更されます。リスク受容された個々の検出事項の全リストは、サイドバーの検出事項セクション内のリスク受容済み検出事項サブメニューで確認できます。

検出事項を簡易リスク受容した後で完全リスク受容に追加したい場合は、完全リスク受容に追加する前にリスクの受容を解除する必要があります。

When a Risk Acceptance Expiration Date is Changed#

完全リスク受容の有効期限は、作成後いつでも編集できます。DefectDojo の動作は、そのリスク受容が現在有効か、すでに期限切れになっているかによって異なります。

Editing the date on an active Risk Acceptance#

リスク受容がまだ期限切れになっていない場合(有効期限が未来の日付である、またはちょうど過ぎたばかりで定期的な期限切れジョブがまだ処理していない場合)、日付の編集は単純です。

• 新しい日付がそのまま保存されます。
• 関連付けられた検出事項はリスク受容済みのままです。
• リスク受容オブジェクトは有効なままです。

Pushing the date forward on an already-expired Risk Acceptance#

リスク受容がすでに期限切れになっている場合(つまり、定期的な期限切れジョブがその期限切れを処理し、関連付けられた検出事項がアクティブに戻されている場合)、有効期限を未来の日付に編集すると復元ワークフローがトリガーされます。

• リスク受容は復元され、期限切れの状態ではなくなります。
• そのリスク受容に関連付けられ、現在アクティブになっているすべての検出事項が再度受容されます(リスク受容済み/非アクティブに戻されます)。
• 関連付けられたJira課題には、復元を記録するコメントが投稿されます。

入力した日付がそのまま保存されます。システム設定のリスク受容フォームのデフォルト日数(デフォルト: 180)は、特定の日付を指定しなかった場合にのみ使用されます。例えば、復元アクションを使用した場合です。このアクションは有効期限を編集せずにリスク受容を復元するため、日付は今日からN日後に設定されます。

Moving the date backwards or to a date still in the past#

有効期限を、より早いがまだ未来の日付に変更しても特別な動作はありません。リスク受容は有効なままとなり、新しい日付が保存されます。

日付を過去の日付に変更しても、編集フォームからリスク受容が直ちに期限切れになるわけではありません。次の定期的な期限切れジョブがそれを検出し、標準の期限切れ処理を適用します。これはすでに期限切れのリスク受容にも当てはまります。過去の日付であっても、それはあなたが選択した日付であるため、そのまま保存され、次の期限切れ実行時に再びリスク受容が失効します。

What the API exposes#

APIの利用者は、expiration_date、expiration_date_handled、expiration_date_warnedの各フィールドを通じて、リスク受容オブジェクトの期限切れ状態を確認できます。リスク受容はexpiration_date_handledが非nullの場合に限り「期限切れ」です。復元が行われると、expiration_date_handledとexpiration_date_warnedの両方がnullにクリアされ、expiration_dateには送信した日付(日付を指定しなかった場合は今日からN日後)が保持されます。

期限切れ処理と復元は直接実行することもでき、expiration_dateを編集することで操作する必要はありません。

• POST /api/v2/risk_acceptance/{id}/expire/ は今すぐ期限切れにします。すでに期限切れの場合は400を返します。
• POST /api/v2/risk_acceptance/{id}/reinstate/ は期限切れのものを復元し、対象の検出事項を再度受容します。期限切れになっていない場合は400を返します。期間を指定するにはexpiration_dateを送信します。省略した場合は今日からN日後が使用されます。

どちらもオプションのreasonを受け付け、実行者とともにリスク受容へのメモとして記録されます。どちらも、リスク受容を編集する場合と同じ権限が必要です。

Risk Acceptance Best Practices#

標準的な運用として、一般的には完全リスク受容と簡易リスク受容の両方を併用するのではなく、どちらか一方のみを使用することが望ましいとされています。

例えば、完全リスク受容がデフォルトの方式である場合に、ある検出事項が簡易リスク受容されると、その検出事項を含む関連の完全リスク受容が存在しないために混乱を招くことがあります。同様に、通常は検出事項が簡易リスク受容されている場合に、一部の検出事項だけを完全リスク受容に追加すると、他の大半の検出事項にはそのようなオブジェクトが存在しないため、これも混乱を招く可能性があります。