再インポート

DefectDojo でテストが作成されると(事前に作成する場合でも、スキャンファイルをインポートする場合でも)、そのテストに新しい検出事項データを追加して拡張することができます。

例えば、毎日 DefectDojo に新しいレポートを送信するように設計された CI/CD パイプラインがあるとします。パイプラインの「実行」ごとに新しいテストやエンゲージメントを作成するのではなく、再インポートを使用して各レポートを同じテストに流し込むことができます。

再インポート: 処理の概要#

データを再インポートしても、テスト内の古いデータが置き換えられることはありません。代わりに、受信したスキャンファイルをテスト内の既存のスキャンデータと比較し、以下のような判断を行います。

• 最新のファイルに基づくと、どの脆弱性がまだ存在しているか?
• どの脆弱性が存在しなくなったか?
• 以前に解決されたが、その後再び発生した脆弱性はどれか?

テストは、Import History を通じて各スキャンバージョンを追跡・区別するため、時間の経過に伴うテスト内の検出事項の変化を確認できます。

再インポートのロジック: 作成、無視、クローズ、再オープン#

再インポートを使用すると、DefectDojo は受信したスキャンデータを既存のスキャンデータと比較し、以下のようにテスト内の検出事項に変更を適用します。

検出事項の作成#

前回のインポートに含まれていなかった脆弱性は、新しい検出事項として自動的にテストに追加されます。

既存の検出事項の無視#

受信した検出事項がすでに存在する検出事項と一致する場合、その検出事項は重複として記録されるのではなく破棄されます。これらの検出事項はすでに記録済みであり、新しい検出事項オブジェクトを追加する必要はありません。テストページでは、これらの検出事項はLeft Untouchedと表示されます。

fix_available および fix_version フィールド#

受信した検出事項がすでに存在する検出事項と一致する場合、受信した検出事項の fix_available フィールドと fix_version フィールドが異なるかどうかがチェックされ、異なる場合は更新されます。これらの検出事項はすでに記録済みであり、新しい検出事項オブジェクトを追加する必要はありません。テストページでは、これらの検出事項はLeft Untouchedと表示されます。

検出事項のクローズ#

テストにすでに存在する検出事項が受信したレポートに存在しない場合、それらの検出事項を自動的に非アクティブおよび緩和済みに設定することを選択できます(前回のインポート以降にそれらの脆弱性が解決されたと想定します)。テストページでは、これらの検出事項はClosedと表示されます。

古い検出事項をクローズしたくない場合は、再インポート時にこの動作を無効にできます。

• UI を使用している場合は Close Old Findings チェックボックスのチェックを外す
• API を使用している場合は close_old_findings を False に設定する(このエンドポイントでは close_old_findings はデフォルトで True です)

スコープに関する注記: インポートとは異なり、再インポートはクローズ対象の検出事項を検討する際に、エンゲージメント内の他のテストを参照することはありません。検出事項のクローズのスコープは常に対象のテストに限定されます。

close_old_findings 機能は service フィールドも考慮します。同一の service 値を持つ検出事項(または指定がなかった場合は service 値を持たない検出事項)のみがクローズの対象となります。

検出事項の再オープン#

• クローズされた検出事項が再インポートで再び出現した場合、それらは自動的に再オープンされます。これは、前回の緩和にもかかわらず、これらの脆弱性が再び発生したと想定するためです。テストページでは、これらの検出事項はReactivatedとして追跡されます。

トリアージ機能のないスキャナーを使用している場合、またはクローズされた検出事項を再アクティブ化したくない場合は、再インポート時にこの動作を無効にできます。

• API を使用している場合は do_not_reactivate を True に設定する
• UI を使用している場合は Do Not Reactivate チェックボックスをオンにする

Force Active と Force Verified の動作#

再インポートで active=true(UI: Force Active)または verified=true(UI: Force Verified)を設定すると、一致したすべての検出事項に対応するステータスが設定されます。これには、緩和済みであるために本来は非アクティブになるはずの検出事項も含まれます。これは上記で説明した再アクティブ化の動作と同じものであり、受信するすべての検出事項に対して明示的に適用されるだけです。

Force Active と Force Verified は、検出事項をアクティブにすべきでない理由に関するユーザーまたはシステムの明示的な判断を表すステータスを上書きしません。

Risk Accepted または Duplicate の検出事項を再びアクティブにしたい場合は、まずリスク受容または重複のマーカーを削除する必要があります。Force Active だけではアクティブになりません。

再インポートフォームを開く#

Re-Import Findings フォームには、任意のテストページの ⚙️Gear ドロップダウンメニューからアクセスできます。

Re-import Findings Form では、別のスキャンタイプをインポートしたり、アップロードしようとしている検出事項の保存先を変更したりすることはできません。そのいずれかを行いたい場合は、Import Scan Form を使用する必要があります。

Import History の利用#

特定のテストの Import History は、Test ページの Test Overview ヘッダーの下に一覧表示されます。

このテーブルには、各インポートまたは再インポートが Timestamp とともに1行で表示され、指定されていれば Branch Tag、Build ID、Commit Hash、Version の各列も表示されます。

Actions#

このヘッダーは、インポート/再インポートによって行われたアクションを示します。

• # created は、インポート/再インポート時に作成された新しい検出事項の数を示します
• # closed は、再インポートによってクローズされた検出事項の数を示します(受信したレポートに存在しなかったため)。
• # left untouched は、再インポートによって変更されなかったオープンな検出事項の数を示します(受信したレポートにも存在していたため)。
• # reactivated は、受信した再インポートによって再オープンされたクローズ済み検出事項を示します。

再インポートの重複排除#

再インポートは、受信した項目が既存の検出事項と一致するかどうかを Reimport Deduplication の設定を使用して判断します。これは、検出事項が存在した後に動作する「Same Tool Deduplication」や「Cross Tool Deduplication」とは別のものです。

わずかな属性の変更(例えば行番号のずれ)だけで、再インポートが古い検出事項をクローズして新しい検出事項を作成してしまう場合は、そのツールの Reimport Deduplication を調整し、そうした属性を無視する安定した識別子(Unique ID From Tool など)を使用するようにしてください。

DefectDojo Pro は、信頼できる一意の ID を持たないツールについて、これを直接解決できます。Location Drift Matching を有効にすると、行のずれ、ファイル名の変更、URL の移動、依存関係のバージョンアップなど、場所が変わった検出事項を再インポートが同一の検出事項として認識し、その場で更新しながら位置の履歴を保持するようになります。

API 経由の再インポート - 特記事項#

/reimport API エンドポイントは、既存のテストを拡張する(この記事で説明した方法を適用する)ことも、新しいデータで新しいテストを作成することもできることに注意してください。事前に /import を呼び出したり、テストを事前にセットアップしたりする必要はありません。

DefectDojo を使用した自動化された CI/CD パイプラインの作成について詳しく知るには、こちら のガイドを参照してください。