DefectDojo DefectDojo | docs

アセット階層: 概要 (Open Source)

DefectDojoは、作業を整理するために5つの主要なデータクラスを使用します: 組織、アセット、エンゲージメント、テスト、検出事項です。

DefectDojoは、チームをツールに合わせるのではなく、ツールをチームに合わせて柔軟に運用できるように設計されています。これらのデータクラスを使って作業をどのように整理できるかを理解すれば、堅牢で柔軟なワークスペースを設計できるようになります。

アセット階層図

image

組織

DefectDojoでまず設定する必要があるデータのカテゴリは組織です。組織は、特定の方法でアセットを分類することを目的としています。例えば以下のような分類が考えられます。

  • 事業ドメイン別
  • 開発チーム別
  • セキュリティチーム別

image アセットは、それぞれの組織の下にグループ化されてネストされます。

組織にはロールベースアクセス制御のルールを適用でき、チームメンバーがそのデータ(配下のエンゲージメント、テスト、検出事項データを含むアセット)を閲覧・操作できる範囲を制限できます。ユーザーロールの詳細については、Introduction To Rolesの記事を参照してください。

組織は何を表すことができますか?

  • 特定のソフトウェアプロジェクトに多数の異なるデプロイやバージョンがある場合、プロジェクト全体のスコープをカバーする単一の組織を作成し、各バージョンを個別のアセットとして存在させる方法が有効な場合があります。 ​
  • また、ソフトウェア開発プロセスの各段階を表すために組織を使用することも考えられます。例えば「In Development」用の組織と「In Production」用の組織を分けるといった方法です。 ​
  • 最終的には、アセットをどのように整理し、組織に何を表現させたいかはあなた次第です。DefectDojoの階層は、セキュリティチームのニーズに合わせて変更する必要があるかもしれません。

アセット

DefectDojoにおけるアセットは、現在テストしているプロジェクト、プログラム、またはアプリケーションを表すことを目的としています。アセットは、その対象に関連するすべてのセキュリティ作業とテスト履歴を保持します。

image

  • 一意の名前
  • 説明
  • 組織
  • 割り当てられたSLA設定

アセットのスコープは、広範囲にも特定の範囲にも自由に設定できます。デフォルトでは、アセットは階層内で完全に独立したオブジェクトですが、組織によってグループ化することができます。

アセットは「壁で仕切られた」存在であり、他のアセットとは相互作用しません。重複排除などのDefectDojoのスマート機能は、単一のアセットの範囲内でのみ適用されます。

組織と同様に、アセットにもロールベースアクセス制御のルールを適用でき、チームメンバーがそのアセット(および配下のエンゲージメント、テスト、検出事項データ)を閲覧・操作できる範囲を制限できます。ユーザーロールの詳細については、Introduction To Rolesの記事を参照してください。

アセットは何を表すことができますか?

DefectDojoにおける「アセット」という概念は、あなたの組織が「製品」と呼ぶものと必ずしも1対1で対応するとは限りません。ソフトウェア開発は複雑であり、セキュリティ上のニーズは、単一のソフトウェアの範囲内であっても大きく異なる場合があります。

以下のようなシナリオは、別のDefectDojoアセットを作成することを検討すべき良い理由です。

  • 「ExampleAsset」にWindows版、Mac版、Cloud版がある場合
  • 「ExampleAsset 1.0」が「ExampleAsset 2.0」とはまったく異なるソフトウェアコンポーネントを使用しており、両方のバージョンが自社によって積極的にサポートされている場合
  • 「ExampleAsset version A」の担当チームが「ExampleAsset version B」を担当するアセットチームと異なり、その結果として異なるセキュリティ権限を割り当てる必要がある場合

単一のアセット内でのこうしたバリエーションは、エンゲージメントレベルで扱うこともできます。ただし、エンゲージメントにはアセットや組織のようなアクセス制御機能がない点に注意してください。

エンゲージメント

アセットを設定したら、エンゲージメントの作成とスケジュール設定を開始できます。エンゲージメントは、テストが実施される特定の期間を表すことを目的としており、1つ以上のテストを含みます。

エンゲージメントには常に以下が含まれます。

  • 一意の名前
  • 目標となる開始日と終了日
  • ステータス(Not Started、In Progress、Cancelled、Completedなど)
  • 割り当てられたテストリード
  • 関連付けられたアセット

エンゲージメントにはInteractiveとCI/CDの2種類があります。

  • Interactive Engagementは、通常はエンジニアによって実施されます。Interactive Engagementは、自動テスト、人間によるテスター、またはアプリケーションの機能と「対話する」その他の活動を用いて、アプリケーションが稼働している状態でのテストに重点を置きます。詳細はOWASPによるIASTの定義を参照してください。
  • CI/CD Engagementは、CI/CDパイプラインとの自動連携を目的としています。CI/CD Engagementは、リリースプロセスの一部としてトリガーされる自動アクションとしてデータをインポートすることを想定しています。

エンゲージメントは、DefectDojoのCalendarビューを使用して追跡できます。

エンゲージメントは何を表すことができますか?

エンゲージメントは、関連するテスト作業のグループを表すことを目的としています。テスト作業をどのようにグループ化するかは、あなたのアプローチ次第です。

計画されたテスト作業がスケジュールされている場合、エンゲージメントは関連するすべての結果を保存する場所を提供します。この種のエンゲージメントの例を以下に示します。

エンゲージメント: ExampleSoftware 1.5.2 - Interactive Testing Effort

この例では、セキュリティチームがソフトウェアリリースの一環として同じ日に複数のテストを実施しています。

  • テスト: Nessus Scan Results (3月12日)
  • テスト: NPM Scan Audit Results (3月12日)
  • テスト: Snyk Scan Results (3月12日) ​ CI/CDのテスト結果もエンゲージメント内で整理できます。この種のエンゲージメントは「オープンエンド」であり、日付を持たず、関連するCI/CDアクションが実行されるたびにデータが追加されていきます。

エンゲージメント: ExampleSoftware CI/CD Testing

この例では、新しいソフトウェアリリースが作成されるたびに、複数のCI/CDスキャンが自動的にテストとしてインポートされます。

  • テスト: 1.5.2 Scan Results (3月12日)
  • テスト: 1.5.1 Scan Results (3月3日)
  • テスト: 1.5.0 Scan Results (2月14日)

エンゲージメントは、チームにとって最適な方法で整理できます。アセットの下にネストされたすべてのエンゲージメントは、そのアセットの作業を担当するチームが閲覧できます。

テスト

テストは、アセット内の欠陥を発見するためにエンジニアが実施する活動のグループです。

テストには常に以下が含まれます。

  • 一意のテストタイトル
  • 特定のテストタイプ(API Test、Nessus Scanなど)
  • 関連付けられたテストの環境
  • 関連付けられたエンゲージメント

テストの作成方法にはいくつかの種類があります。スキャンデータがエンゲージメントに直接インポートされると、そのスキャンデータを含む新しいテストが自動的に作成されます。また、今後のエンゲージメントを計画する目的や、追跡・修復が必要な手動入力のセキュリティ検出事項のために、あらかじめテストを作成しておくこともできます。

テストタイプ

DefectDojoは2種類のテストタイプをサポートしています。

  1. パーサーベースのテストタイプ: XML、JSON、CSVなどの形式で出力を生成する特定のセキュリティスキャナーに対応しています。スキャン結果をインポートする際、DefectDojoは専用のパーサーを使ってスキャナーの出力を検出事項に変換します。

  2. 非パーサー型のテストタイプ: スキャンファイルからインポートされない、手動で作成された検出事項に使用されます。これらのテストタイプは、Generic Findings Import方式を使用して検出事項とメタデータを表示します。

新しいテストを作成する際、「Scan Type」ドロップダウンには以下のテストタイプが表示されます。

  • API Test
  • Static Check
  • Pen Test
  • Web Application Test
  • Security Research
  • Threat Modeling
  • Manual Code Review

非パーサー型のテストタイプは、修復が必要でありながら自動化されたスキャナーの出力に由来しない検出事項を手動で作成する必要がある場合に使用します。

パーサーベースのテストタイプ

パーサーベースのテストタイプは、テストタイプ名がどのように決定されるかによって分類できます。

  • 固定のテストタイプ名: テストタイプ名はあらかじめ定義されており、インポート前から判明しています(例:「ZAP Scan」、「Nessus Scan」)。

  • レポート定義のテストタイプ名: テストタイプ名は、インポート時にスキャンレポートの内容から抽出されます。

例としては以下のものがあります。

  • Generic Findings Import: JSONレポート内のtypeフィールドに基づいてテストタイプを作成します
  • SARIF: SARIFレポート内のツール名に基づいてテストタイプを作成します(例:「Dockle Scan (SARIF)」)
  • OpenReports: レポート内で見つかったソースごとに個別のテストタイプを作成します

レポート定義のテストタイプ命名ルール:

  • レポートのtypeフィールドがスキャンタイプと同じ場合 → スキャンタイプがそのまま使用されます(例:「Generic Findings Import」)
  • レポートのtypeフィールドが異なる場合 → 「{type} Scan ({scan_type})」という形式で作成されます(例:「Tool1 Scan (Generic Findings Import)」)
  • レポートのtypeフィールドがすでに「 ({scan_type})」というサフィックスで終わっている場合 → そのまま使用され、サフィックスが二重になることはありません(例:「Tool1 (Generic Findings Import)」は「Tool1 (Generic Findings Import)」のままです)
  • typeフィールドが指定されていない場合 → スキャンタイプがそのまま使用されます

重要な考慮事項:

  • レポート定義のテストタイプは、インポートまたは再インポート時に新しいタイプが検出されると自動的に作成されます。
  • 再インポートの場合、テストタイプ名は完全に一致している必要があります。一致しない場合は検証エラーが発生します
  • 重複排除設定(HASHCODE_FIELDS_PER_SCANNER)はテストタイプ名をキーとして使用するため、カスタムの重複排除の動作を求める場合は、レポート定義の名前もそれに合わせて設定する必要があります

テスト同士はどのように相互作用しますか?

テストはテストデータを取り込み、それを検出事項としてグループ化します。一般的に、セキュリティチームは同じテスト作業を繰り返し実施することになりますが、DefectDojoのテストはこのプロセスをうまく処理できるようにします。

以前にインポートしたテストは再インポートできます - 同じエンゲージメントの文脈で同種のテストを実行している場合、スキャンが完了するたびにテスト結果を再インポートできます。DefectDojoは再インポートされたデータを既存の結果と比較し、スキャンデータ内に重複が存在する場合は新しい検出事項を作成しません。

テストは個別にインポートすることもできます - 別々のエンゲージメント内で同じテストをアセットに対して実行した場合でも、DefectDojoはデータを以前のテストと比較して重複する検出事項を見つけます。これにより、以前に緩和済みまたはリスク受容済みとなった検出事項を追跡し続けることができます。

エンゲージメントを介さずにテストが直接アセットに追加された場合、そのテストを格納する汎用のエンゲージメントが自動的に作成されます。これにより、アドホックなデータインポートが可能になります。

テストの例:

  • 2015年10月29日から2015年10月29日までのBurp Scan
  • 2015年10月31日から2015年10月31日までのNessus Scan
  • 2015年10月15日から2015年10月20日までのAPI Test

検出事項

データがテストにアップロードされて追加されると、そのデータの結果は、レビュー対象の個々の検出事項としてテスト内に一覧表示されます。

検出事項は、テスト中に発見された特定の欠陥を表します。

検出事項には常に以下が含まれます。

  • 一意の検出事項名
  • 発見された日付
  • アクティブ、検証済み、誤検知など、複数の関連するステータス
  • 関連付けられたテスト
  • 深刻度レベル: 重大、高、中、低、情報(Info)

検出事項はデータのインポートを通じて追加できますが、テストに手動で追加することもできます。

検出事項の例:

  • OpenSSL ‘ChangeCipherSpec’ MiTM Potential Vulnerability
  • Web Application Potentially Vulnerable to Clickjacking
  • Web Browser XSS Protection Not Enabled

エンドポイント

スキャンデータには通常、特定の検出事項の影響を受けるホストやエンドポイントへの参照が含まれます。DefectDojoは検出事項をエンドポイントごとに自動的に集約するため、エンドポイントビューを使用して、特定のエンドポイントまたはホスト名に影響するすべての検出事項を確認できます。

例:

  • https://www.example.com
  • https://www.example.com:8080/products
  • 192.168.0.36
前へ
アセット階層
次へ
コンポーネント