テスト (Open Source)
組織 → アセット → エンゲージメント → テスト → 検出事項
概要
テストとは、1つ以上のスキャン実行を格納するコンテナであり、製品内の欠陥を発見するために使用されます。テストはDefectDojoの製品階層における最終的かつ最も詳細な粒度のコンポーネントであり、セキュリティツールの実行または手動評価の結果として得られる検出事項を格納するコンテナとして機能するとともに、その検出事項がどのような文脈で発見されたか(どのツールが報告したか、そのツールが最後に実行されたのはいつかなど)という情報も付加します。
テストの例には、以下のようなものがあります。
- 静的アプリケーションセキュリティテスト(SAST)
- 動的アプリケーションセキュリティテスト(DAST)
- ソフトウェア構成分析(SCA)
- コンテナセキュリティスキャン
- インフラストラクチャ/ネットワークスキャン
- 手動ペネトレーションテスト
- CI/CDパイプラインスキャン
テストの種類
DefectDojoでテストを作成する主な方法は2つあります。
- ベンダー固有のパーサー(例: Burp、OWASP ZAP、Acunetix、Invicti)
- 汎用検出事項インポート
各方式は、設定や重複排除戦略に応じて、新しいテストを作成することも、既存のテストに検出事項を再インポートすることも可能です。
各方式は主にスキャンデータの解析および取り込み方法が異なりますが、最終的にはいずれも検出事項がテストに関連付けられる結果となります。
パーサー
パーサーとは、特定のスキャン出力形式(XML、JSON、CSVなど)を処理し、DefectDojo内部の検出事項モデルにマッピングするコンポーネントです。スキャン結果がインポートされると、DefectDojoは選択されたパーサーを使用して検出事項を抽出し、新規作成または既存のテストに関連付けます。
汎用検出事項インポート
特定のツールに対応するネイティブパーサーが存在しない場合、汎用検出事項インポートを使用すると、元のソースにかかわらず、標準化されたJSONまたはCSVスキーマを使用して検出事項をインポートできます。
DefectDojoは提供されたデータを解析し、新しいテストを作成する(または既存のテストにインポートする)とともに、検出事項を関連付けます。レポートの任意フィールドであるtypeに基づいて、対応するテストタイプも作成されます。typeが省略されている場合(またはスキャンタイプと同じ場合)、テストタイプは「Generic Findings Import」になります。typeが指定されている場合は「{type} Scan (Generic Findings Import)」になります(すでに「(Generic Findings Import)」という接尾辞で終わっているtypeは、そのまま使用されます)。
| ネイティブパーサー | 汎用検出事項インポート | |
|---|---|---|
| 主な目的 | サポートされているツールの出力を取り込む | 固定スキーマを使用して非対応/カスタムデータを取り込む |
| 入力形式 | ツール固有(例: ZAP XML、SARIF) | 厳密なJSON/CSVスキーマ |
| 正規化を行う主体 | DefectDojo(組み込みパーサー) | ユーザー(スキーマに準拠する必要あり) |
| テスト作成のトリガー | 手動アップロードまたはAPIインポート | 手動アップロードまたはAPIインポート |
| テストタイプ | 事前定義済み(例:「ZAP Scan」) | 自動作成される「Generic」タイプ |
| セットアップの手間 | 低 | 中程度(データ変換が必要) |
| 柔軟性 | 低(対応ツールのみ) | 中 |
| 自動化レベル | 低~中 | 低~中 |
| 典型的な用途 | 標準的なスキャナー(SAST、DAST、SCA) | カスタムスクリプト、非対応ツール |
取り込み方法にかかわらず、DefectDojo内のすべてのスキャンデータは、最終的にテストに関連付けられた検出事項として表現されます。テストは、実行単位およびライフサイクル追跡の単位として機能します。
テストデータ
テストは、各テスト活動のさまざまな要素を記録するのに役立つ、多様なメタデータを保存します。例えば以下のとおりです。
- テストのタイトル/名前
- テストタイプ
- テストの説明/メモ
- 開始日と終了日
- テストが実行された環境(開発、ステージング、本番前、本番など)
- バージョン/ブランチ/ビルドID/コミットハッシュ
- APIスキャン設定
- 後の監査や再インポートに使用できる追加ファイル
- 親となるエンゲージメント、アセット、組織
- インポートおよび再インポートの履歴
各テストはインポート履歴を保持しており、そのテストに関連するすべてのスキャンのインポートおよび再インポートが記録されます。これには、スキャン日、バージョン、ブランチ、コミットハッシュ、ビルドIDなどのメタデータが含まれます。
この履歴により、同一テスト内で実行された複数回のスキャンにわたるトレーサビリティが確保されます。
権限
1つのエンゲージメント内に複数のテストを格納でき、エンゲージメントは製品内に格納されます。そのため、ある製品へのアクセス権を持つと、その製品内のすべてのテスト(およびエンゲージメント)へのアクセス権が自動的に付与されます。テストは独自のアクセス制御リストを持ちません。
テストへのアクセス
テストはDefectDojo OSにおいて独立したオブジェクトとして存在しますが、UI内に専用のセクションはありません。そのため、各テストは主に、それを含む製品またはエンゲージメント(あるいはその両方)を通じてアクセスします。
テストビュー
テストビューには、親エンゲージメント、インポートおよび再インポートの履歴、テスト内に含まれる検出事項の一覧、検出事項グループなど、さまざまな表が表示されます。
また、潜在的検出事項、ファイル、メモの表もあり、いずれも手動で追加できます。
テスト設定
各テストビューでは、以下の設定を利用できます。
- テストを編集
- タイトル、スケジュール、環境などのテストデータの各種詳細を編集できます。
- テストをコピー
- テストを関連するすべてのメタデータおよび検出事項とともに複製し、別のエンゲージメントに割り当てることができます。
- スキャンを再アップロード
- 再インポートのプロセスを開始します。再インポートの詳細については、この記事の後半で説明します。
- メモを追加
- ユーザーがメモを追加できます。ページ下部にはメモの表も表示されます。
- メモは非公開に切り替えることができ、その場合、Jiraへのプッシュ、レポート、検出事項のエクスポートには反映されなくなります。
- ユーザーがメモを追加できます。ページ下部にはメモの表も表示されます。
- レポート
- レポート生成のプロセスを開始します。さまざまなフィルターを適用して、フィルタリングされた検出事項のみを含むレポートを作成できます。
- カレンダーに追加
- 選択したテストの.icsファイルをダウンロードし、サードパーティ製のカレンダーアプリケーションに追加できます。
- 履歴を表示
- 追跡、レポート、監査を目的として、テストに対して行われた編集の履歴を表示します。
テストの操作
テストの作成
スキャンデータがエンゲージメントに直接インポートされると、そのスキャンデータを含む新しいテストが自動的に作成されます。また、将来のエンゲージメントを計画する目的や、追跡と修復が必要な手動入力のセキュリティ検出事項のために、テストを事前に作成することもできます。
手動ワークフロー
OS版でテストを作成する方法はいくつかあります。
- 製品を選択し、ナビゲーションバーの検出事項メニューから「スキャン結果をインポート」をクリックします
- この操作により、テストを格納するためのアドホックなエンゲージメントが作成されます
- 製品内のエンゲージメントを選択し、テストサブセクションのドロップダウンメニューをクリックして、「テストを追加」または「スキャン結果をインポート」のいずれかをクリックします
- この操作により、選択したエンゲージメント内に直接テストが作成されます
- エンゲージメントの作成中
上記3番目の方法を使用すると、エンゲージメントの作成中に以下の操作を行うことができます。
- すぐにスキャン結果をインポートする
- テストシェルを作成する(後でスキャンをインポートする)
- どちらも行わず、「完了」をクリックしてエンゲージメントのみを作成する
スキャンのインポート時、またはテストシェルの作成時に、メタデータを追加することができます。追加したメタデータは、テストビューのインポート履歴セクションに反映されます。
自動化されたワークフロー
自動化されたワークフローでは、スキャンのインポート処理の一環としてテストをプログラムで作成できるため、パイプラインは事前に手動でテストを作成することなく結果をアップロードできます。
APIを使用してスキャン結果をインポートする場合、テストの代わりにエンゲージメントを指定することで、新しいテストを自動的に作成できます。
API
curl -X POST "https://<your-instance>/api/v2/import-scan/"
-H "Authorization: Token <api_key>"
-F "engagement=45"
-F "scan_type=ZAP Scan"
-F "file=@report.xml"
上記の例では、指定したエンゲージメントの下に新しいテストが作成され、スキャン結果がそのテストに関連付けられます。
代わりにtestのIDが指定された場合、スキャン結果は既存のテストに追加されます。これは再インポートのワークフローでよく見られるパターンです。
テストの編集
テストは、親エンゲージメントビューのテスト表にある⋮(縦三点)メニューからテストを編集をクリックするか、テストビュー内の設定メニューから編集できます。編集可能な各フィールドは、テストの作成時にも同様に利用できます。
テストへの検出事項の手動追加
検出事項は、親エンゲージメントビューでテストの隣にある⋮(縦三点)メニューから検出事項をテストに追加をクリックするか、テストビューの検出事項表の設定から、テストに手動で追加できます。
テストの削除
テストは、親エンゲージメントビューでテストの隣にある⋮(縦三点)メニューからテストを削除を選択するか、テストビュー内の設定メニューから削除できます。この操作は元に戻せません。
テストを削除すると、そのテストに含まれるすべての検出事項も削除されます。
再インポート
テスト内でスキャンを再インポートすることは、効果的な重複排除の基本です。同じテストにスキャン結果が再インポートされると、以下のようになります。
- 既存の検出事項が更新される場合があります
- 重複する検出事項が抑制される場合があります
- 一致するものが見つからない場合は、新しい検出事項が作成されます
この挙動は、設定されている重複排除ルールとスキャンタイプによって異なります。
既存のテストに再インポートする代わりに新しいテストを作成すると、検出事項が更新されるのではなく、重複して作成される可能性があります。
再インポートとインポートの違い
再インポートは通常、以下のような場合に使用されます。
- 同じ対象に対して繰り返しスキャンを実行する場合
- 検出事項が時間の経過とともにどのように変化するかを追跡する場合
- アプリケーションのセキュリティ体制を継続的に把握する場合
一方、インポート(新しいテストの作成)は、単発または独立したスキャン実行により適しています。
スキャン結果の再インポート(UI)
既存のテストに新しいデータを追加するには、親エンゲージメントビューでテストの隣にある⋮(縦三点)メニューからスキャン結果を再アップロードをクリックするか、テストビュー内の設定メニューでスキャンを再アップロードをクリックします。
再インポートスキャンフォームに入力する際、再インポートするスキャンのメタデータ(バージョン、ブランチタグ、コミットハッシュ、ビルドIDなど)を更新するオプションがあります。
これらの変更は、テストビューのインポート履歴セクションに反映され、そこには過去のスキャンインポート時と同じメタデータも含まれます。
たとえば、以下のスクリーンショットでは、最初のインポートとその後の再インポートの間に、ブランチタグ、ビルドID、コミットハッシュ、バージョンがすべて手動で更新されています。
直近に再インポートされたスキャンのメタデータを編集するには、前述の「テストの編集」セクションの手順に従い、必要に応じてメタデータを更新してください。編集できるのは、最も新しいインポートのメタデータのみです。
スキャン結果の再インポート(API)
CI/CDパイプラインを通じてテストが作成または更新される場合、パイプライン実行時のメタデータを含めることで、テストをスキャン対象のコードと適切に関連付けることができます。これにより、以下が可能になります。
- スキャン結果を特定のコミットまたはブランチに関連付ける
- コードの変更にともなって検出事項がどのように変化するかを追跡する
- 2つのスキャンがコードの同一バージョンまたは異なるバージョンに対するものかを把握することで、重複排除を改善する
- どのコードがいつスキャンされたかを正確に示すことで、監査可能性を高める
DefectDojoのAPIは、インポートまたは再インポート時にこれらの値を受け付け、スキャンインポートの一部として保存し、テストのインポート履歴に反映します。このメタデータは、コミットハッシュや、CI/CD実行に関連するリポジトリ情報の特定に利用できます。
サポートされているメタデータフィールド
APIは、再インポート時に含めることができる、定義済みのメタデータフィールドのセットをサポートしています。具体的には以下のとおりです。
tagsversionbuild_idbranch_tagcommit_hashscan_dateminimum_severityactive / verifiedフラグ
これらのフィールドは、再インポート操作時にコンテキストメタデータを付加するための主要な手段です。
自動化されたパイプラインでは、最も一般的に指定されるメタデータには以下が含まれます。
- build_id(CIジョブの識別子)
- commit_hash(ソースコード管理の参照情報)
- branch_tag(ブランチまたは環境のコンテキスト)
- tags(例: nightly、staging、production)
これらのフィールドにより、手動の介入を必要とすることなく、スキャン間のトレーサビリティが確保されます。
メタデータは再インポートスキャンフォームから手動で更新することもできますが、ほとんどの自動化環境では/api/v2/reimport-scan/エンドポイントを直接呼び出すことでこれを処理します。この方法により、パイプラインは再インポート時にメタデータを自動的に付加できます。
メタデータを使用したAPI再インポート
curl -X POST "https://<your-instance>/api/v2/reimport-scan/"
-H "Authorization: Token <api_key>"
-F "test=123"
-F "scan_type=ZAP Scan"
-F "file=@report.xml"
-F "tags=nightly,api-scan"
-F "version=1.4.2"
-F "build_id=jenkins-842"
-F "branch_tag=main"
-F "commit_hash=a1b2c3d4"
メタデータ、再インポート、およびスケジュールされたスキャン
スキャンは、cronジョブなどによってトリガーされる定期的な間隔で実行されるようスケジュールすることもできます。スケジュールされたスキャンはリポジトリの活動と結び付いていないため、スクリプト自体が明示的に注入しない限り、コミットハッシュやブランチ名といったメタデータは意味を持ちません。それでも、単一のテスト内でセキュリティ体制の継続的な記録を保持したい場合には、再インポートを使用することが依然として有用な場合があります。