過剰な重複を避ける

DefectDojoの強みの1つは、データモデルがさまざまなユースケースやアプリケーションに対応できることです。ソフトウェアを使いこなし、ワークフローを最適化する方法を見つけるにつれて、アプローチを変えていくことになるでしょう。

デフォルトでは、DefectDojoは作成された重複した検出事項を削除しません。各検出事項は、脆弱性の個別のインスタンスと見なされます。そのため、重複した検出事項は、ワークフローのプロセス変更が必要であることを示すサインになり得ます。

重複した検出事項が許容されるのはどのような場合か#

重複した検出事項が必ずしも問題を示しているとは限りません。重複を保持することが望ましいアプローチとなるケースも数多くあります。たとえば:

• チームがインタラクティブエンゲージメントを使用し、それについてレポートを作成している場合。特定の単一のテストに関する個別のレポートを作成したい場合、以前にすでに発見された検出事項の再発があるかどうかを知りたいはずです。
• コンテキストが分離されているエンゲージメント(たとえば異なるリポジトリを対象としている場合など)がある場合、両方の場所で発生している検出事項にフラグを立てられるようにしたいはずです。

冗長なインポートの確認#

ステップ1: 過剰な重複をクリーンアップする#

幸いなことに、DefectDojoの重複排除設定を使用すると、一定のしきい値を超えた時点で重複を一括削除できます。この機能により、クリーンアップ作業が容易になります。このプロセスについて詳しくは、検出事項の重複排除に関する記事を参照してください <-link will go here.

ステップ2: エンゲージメントの冗長性を評価する#

重複した検出事項をクリーンアップしたら、それらを含んでいた製品を確認し、明確な原因があるかどうかを調べることをお勧めします。その中に、コンテキストが冗長になっているエンゲージメントが見つかるかもしれません。

重複または再利用されているエンゲージメント#

エンゲージメントは、特定のテストコンテキストのために1つ以上のテストを保存します。そのコンテキストを最終的にどう定義するかはあなた次第ですが、製品内に同じコンテキストを共有すべき複数のエンゲージメントがある場合は、それらを1つのエンゲージメントに統合することを検討してください。 ​

エンゲージメントのコンテキストを定義する際に問うべき質問:#

• この作業についてレポートを作成したい場合、そのエンゲージメントには必要な関連情報がすべて含まれているか?
• エンゲージメントは事前に計画的に作成しているか、それともインポートプロセスによって「アドホック」に作成されているか?
• 適切な種類のエンゲージメント - インタラクティブまたはCI/CD - を使用しているか?
• テストが対象としているコードベースのどの部分か: 各リポジトリは個別のコンテキストなのか、それとも複数のリポジトリがテストの共有コンテキストを構成しうるのか?
• その製品に関わるステークホルダーは誰で、結果をどのように共有するか?

ステップ3: 冗長なテストを確認する#

同じテストコンテキストを捉えている別々のテストが作成されていることに気づいた場合、それらのテストを単一の再インポートに統合できる可能性を示すサインかもしれません。

DefectDojoには、検出事項を作成するためにテストデータをインポートする方法が2つあります: インポートと再インポートです。この2つの方法は非常によく似ていますが、重要な違いは、インポートは常に新しいテストを作成するのに対し、再インポートは既存のテストに新しいデータを追加できる点です。また、再インポートはそのテスト内で重複した検出事項を作成しないことにも注意してください。

新しい脆弱性レポートをDefectDojoにインポートするたびに、そのレポートはテストオブジェクトに保存されます。テストオブジェクトは、将来のインポートを保持するために、ユーザーが事前に作成しておくことができます。ユーザーがインポート先のテストを指定せずにデータをインポートしたい場合は、受信したレポートを保存するために新しいテストが作成されます。

テストは柔軟なオブジェクトであり、1種類のレポートしか保持できませんが、再インポートの方法を通じて同じレポートの複数のインスタンスを扱うことができます。再インポートについて詳しくは、こちらの**記事**を参照してください。

継続的なテストに再インポートを使用する#

CI/CDパイプライン、日次スキャンプロセス、またはその他の繰り返し発生する受信レポートがある場合、過剰な重複を避けるためには、あらかじめ再インポートプロセスを設定しておくことが重要です。再インポートは、繰り返されるテストに関連するコンテキストと検出事項を単一のテストページに集約し、インポート履歴を確認したり、スキャン間の脆弱性の変化を追跡したりできるようにします。

1. CI/CDを実行しているオブジェクトのCI/CD結果を保存するためのエンゲージメントを作成します。これは、CI/CDアクションを実行するように設定したコードリポジトリである場合があります。一般的には、検出事項の結果がどこから来ているかを素早く把握できるように、パイプラインごとに個別のエンゲージメントを設定することをお勧めします。 ​
2. 各CI/CDアクションは、別々のステップでDefectDojoにデータをインポートするため、それぞれを個別のテストにマッピングする必要があります。たとえば、各パイプライン実行がNPM-auditと依存関係スキャンの両方を実行する場合、各スキャン結果は(エンゲージメントの配下にネストされた)テストに流し込む必要があります。 ​
3. CI/CDアクションが実行されるたびに新しいテストを作成する必要はありません。代わりに、同じテストの場所にデータを再インポートできます。

再インポートの実際の動作#

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

検出事項の作成#

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

既存の検出事項の無視#

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

検出事項のクローズ#

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

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

• UIを使用している場合は、古い検出事項をクローズするチェックボックスのチェックを外してください
• APIを使用している場合は、close_old_findingsをFalseに設定してください ​

検出事項の再オープン#

• クローズ済みの検出事項が再インポートで再び現れた場合、それらは自動的に再オープンされます。これは、以前に緩和されたにもかかわらず、その脆弱性が再発したという前提に基づきます。テストページでは、これらの検出事項は再アクティブ化として追跡されます。

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

• APIを使用している場合は、do_not_reactivateをTrueに設定してください
• UIを使用している場合は、再アクティブ化しないチェックボックスをオンにしてください

インポート履歴の利用#

特定のテストのインポート履歴は、テストページのテスト概要ヘッダーの下に一覧表示されます。

このテーブルには、各インポートまたは再インポートがタイムスタンプとともに1行で表示され、指定されている場合はブランチタグ、ビルドID、コミットハッシュ、バージョンの列も表示されます。

アクション#

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

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

なぜ単純にインポートを使わないのか#

どちらの方法も使用可能ですが、インポートは検出事項やデータの新規発生のために取っておくべきであり、再インポートは同じデータのさらなる反復に対して適用すべきです。

CI/CDパイプラインが毎回インポートを実行して新しいテストオブジェクトを作成する場合、各インポートによって個別の検出事項の集合が生成され、それらを別々のオブジェクトとして管理する必要が生じます。再インポートを使用すると、この問題が緩和され、脆弱性が解決されたときに必要となる「クリーンアップ」の量がなくなります。

再インポートを使用すると、繰り返し発生するレポートを同じページに保存でき、テストに新しいデータが追加されるたびの連続性を維持できます。

ただし、同じスキャンツールを複数の場所やコンテキストで使用している場合は、それぞれの場所やコンテキストごとに別々のテストを作成する方が適切な場合があります。これはあなたが好む整理方法によって異なります。