ロケーションの概要 (Pro)

ロケーションは、DefectDojo Proにおける新しいアセットモデリングツールです。従来のエンドポイントモデルを置き換え、それまでのコンポーネント(ライブラリ)データを統合することで、検出事項がどこに存在するか — URLであれ、SBOM由来のソフトウェア依存関係であれ、あるいは将来的にはクラウドリソースIDコンテナイメージコードリポジトリであれ — を記述するための、単一の多態的な方法をDefectDojoにもたらします。

ロケーションを使用するには、事前にインスタンスで有効化しておく必要があります。フィーチャーフラグページからご自身でロケーションを有効にでき、サポートへの依頼は不要です。ロケーションは一度有効にすると、再度無効に戻すことはできない点に注意してください。

なぜエンドポイントを置き換えるのか?

従来のエンドポイントモデルはURLとIPアドレスを中心に構築されており、protocolhostportpathといったWebアプリ向けのフィールドと、検出事項と密結合した固定のステータステーブルを備えていました。これには3つの問題がありました。

  1. 忠実度の限界。 エンドポイントは、サードパーティライブラリ、コンテナイメージ、クラウドリソースなど、URL以外のアセットをきれいに記述することができませんでした。スキャナーがこうした対象に関する検出事項をますます多く生成するようになっているにもかかわらずです。
  2. パフォーマンスの上限。 検出事項ごとのEndpoint_Statusレコードと、URL形式のスキーマは、大規模な顧客ボリュームにおいてうまくスケールしませんでした。
  3. コンポーネントは二級市民でした。 ソフトウェアライブラリは検出事項上の非正規化フィールドとしてのみ存在していたため、ライブラリが脆弱性から独立して存在することができず、真のSBOM管理が不可能でした。

ロケーションは、型付きペイロードを持つ基本のLocationオブジェクトと、各アセット形状に対応する専用のサブタイプを導入することで、これら3つの問題をすべて解決します。

  • URLロケーション — 従来のエンドポイントと機能的に同等で、同じprotocol/host/port/path/query/fragmentフィールドを持ちます。
  • 依存関係ロケーションPackage URL(pURL)によって識別されるソフトウェアライブラリで、SBOMの内容をモデル化するために使用されます。
  • ソースコードロケーション — 静的解析による検出事項がソースコード内のどこに存在するかを、ファイルパスと行番号によって識別します。スキャンによって管理され、コードの移動に伴う検出事項の追跡の基盤となります。

今後検討されているロケーションタイプには、クラウドプロバイダーのリソースID(AWS ARN、Azureリソース ID、GCPフルリソース名)やコンテナイメージ(registry/repository:tagおよびSHA256フィンガープリント)が含まれます。

主要な概念

ロケーションとサブタイプ

ロケーションは共有される親要素です。以下を保持します。

  • Location Type(例:"url""dependency")
  • 表示、検索、重複排除に使用される正規のLocation Value文字列
  • Tagsおよび親アセットから継承されたタグ
  • メタデータ(カスタムのキー/値ペア)

サブタイプ(URLまたは依存関係)は、その種類のロケーションに固有の構造化されたフィールドを保持します。URLと依存関係は常に親のロケーションオブジェクトとともに存在し、サブタイプのLocation Valueはその構造化フィールドから生成されます。

参照

ロケーションは製品や検出事項に直接紐づけられるわけではありません。代わりに、2種類の参照オブジェクトがそれらをリンクします。

  • アセット参照 — ロケーションがアセットに対して持つ関係(例:libFooはアセット6に所有され、アセット9に使用される)。各参照はステータス(ActiveまたはMitigated)と任意の関係(「使用元」または「所有元」)を持ちます。
  • 検出事項参照 — ロケーションが検出事項に対して持つ関係。各参照は、より詳細なステータス(ActiveMitigatedFalse PositiveRisk AcceptedOut of Scope)に加え、監査者と監査日時を持ちます。

この分離により、ライブラリは検出事項を必要とせずに製品上に存在できるようになります。これは従来のコンポーネントモデルにはできなかったことです。

インポート時の自動関連付け

パーサーがURLまたはライブラリを参照する検出事項を生成すると、インポーターは以下を行います。

  1. URLまたはpURLに一致する既存のロケーションを検索します。存在しない場合は新規に作成します。
  2. 検出事項をステータスActiveでロケーションにリンクする検出事項参照を作成します。
  3. アセット参照を作成(または再利用)し、ロケーションが親アセット上にも存在するようにします。

既存のパーサーは、フィーチャーフラグが有効な場合にロケーションデータを出力し、無効な場合は従来のエンドポイントモデルにフォールバックするよう更新されています。ロケーションを有効にしても再設定は不要です。次回のインポートから自動的にロケーションパイプラインを経由します。

MVPに含まれるもの

CapabilityStatus
基盤となるLocationURLDependencyモデル提供済み
ロケーションおよび参照用のREST API提供済み(Locationは読み取り専用、参照は完全なCRUDに対応)
エンドポイントAPIとの読み取り互換シム提供済み
エンドポイント → URLの一方向移行コマンド提供済み
パーサーの更新(URLおよび依存関係)主要なパーサーで提供済み
SBOMアップロード(CycloneDX、SPDX v2/v3)/api/v2/sbom-import/経由で提供済み
ロケーション、URL、依存関係向けのPro UI提供済み
pURLの検索/フィルタリング提供済み
依存関係のライセンス追跡部分的(license_expressionフィールド)
SWID TagのSBOM形式MVP未対応

次のステップ

  • 機能を有効にする — インスタンスでロケーションを有効にするには、までご連絡ください。
  • エンドポイントからの移行 — 移行によって何が保持されるか、また移行後に従来のエンドポイントAPIがどのように動作するかについては、エンドポイントからの移行を参照してください。
  • 日常のURLワークフローURLの操作を参照してください。
  • SBOMと依存関係SBOMの操作を参照してください。