ロケーション on DefectDojo Documentation

ロケーションの概要

Mon, 01 Jan 0001 00:00:00 +0000

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

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

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

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

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

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

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

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

エンドポイントからの移行

Mon, 01 Jan 0001 00:00:00 +0000

既存のDefectDojo Proインスタンスでロケーションを有効にすると、すでにエンドポイントとして保存されているデータを新しいロケーションモデルに引き継ぐ必要があります。このページでは、移行の内容、保持される情報、そして移行実行後にレガシーエンドポイントAPIがどのように動作するかについて説明します。

移行は一方向である点に注意してください。ロケーションからエンドポイントを再作成する自動ロールバック手段はありません。

移行が行うこと

既存の各エンドポイントに対して、移行では以下が行われます。

エンドポイントの protocol、userinfo、host、port、path、query、fragment の各フィールドを使用してURLロケーションを作成(または既存のものを再利用)します。新しいURLは自動的に親の Location オブジェクトに紐付けられます。
タグを引き継ぎます。 エンドポイントに付与されているすべてのタグが、ロケーションのタグセットに追加されます。
メタデータを引き継ぎます。 エンドポイントに紐付いている各 DojoMeta 行は、新しいロケーションを指すように再設定されます。
URLが正しいアセット(製品)の下に表示されるよう、LocationProductReference を作成します。
Endpoint_Status ごとに LocationFindingReference を作成します。

URLの利用

Mon, 01 Jan 0001 00:00:00 +0000

URLロケーションは、レガシーなエンドポイントモデルの機能的な後継です。使い慣れたURL形式のフィールド(protocol、host、port、path、query、fragment)を保持し、Webアプリケーションの検出事項がどこに存在するかを識別するという同じ役割を果たします。

このページでは、URLロケーションを日常的に使い始めた際に変わる点、新しいUIの画面、そしてレガシーエンドポイントAPIの代わりに使用するAPIエンドポイントについて説明します。

URLサブタイプ

すべてのURLはロケーションです。つまり、URLは次の両方を持ちます。

構造化されたURLフィールド(protocol、user_info、host、port、path、query、fragment、および重複排除に使用される hash)。
共有のロケーションフィールド(location_type="url"、表示・検索用の正規 location_value 文字列、タグ、継承タグ、メタデータ、アセットおよび検出事項へのReferenceリンク)。

URLを作成またはアップロードすると、DefectDojoはそれを構造化フィールドに解析し、URLの行とその親ロケーションの行を単一のトランザクションで書き込みます。URLの重複排除は構造化フィールド全体での完全一致で行われます。すべての構成要素が一致すれば同じURLとみなされ、標準的なデフォルトポートの畳み込みも適用されます(http://example.com:80/ と http://example.com/ は同じURLとして解決されます)。

Pro UIでの表示

ロケーション機能が有効になると、ナビゲーションに以下が表示されます。

ロケーション / すべて — URLと依存関係の両方のサブタイプにまたがる、すべてのロケーションの一覧です。種別、ステータス、アセット、検出事項、タグでフィルタできます。
ロケーション / URL — URLロケーションのみに絞った一覧です。これは旧エンドポイントページに最も近いものです。
新しいURL — 構造化フィールド、タグ、任意のアセット/検出事項の関連付けを指定して単一のURLを作成するフォームです。
アセットのロケーション — 任意のアセットで、ロケーションタブにはそのアセットに紐付くURLと依存関係が、ステータスごとの件数やクイックアクションとともに表示されます。

エンドポイントUIにあった一般的なワークフローは維持されています。

SBOMの利用

Mon, 01 Jan 0001 00:00:00 +0000

DefectDojo Proは、ソフトウェアライブラリを依存関係ロケーションとしてモデル化します。依存関係は、Package URL (pURL) によって識別されるロケーションのサブタイプであり、org.apache.logging.log4j:log4j-core@2.17.0、pypi/django@5.0.2、npm/react@18.2.0 などの単一のライブラリまたはパッケージを表すことを意図しています。

依存関係は、検出事項にのみ紐付いていた従来のコンポーネントモデルに代わるものです。ロケーションでは、ライブラリは脆弱性の有無にかかわらず独立して存在できます。SBOMをアセットにアップロードしておけば、スキャンが取り込まれるたびに検出事項が参照する依存関係へ自動的に紐付きます。

依存関係が保持する情報

すべての依存関係はpURLによって一意に識別され、検索・フィルタリング可能な原子的なフィールドに分解されます。

フィールド	意味	例
`purl_type`	ライブラリのエコシステム	`npm`、`pypi`、`maven`、`cargo`、`nuget`、`gem`
`namespace`	ベンダーまたは組織	`org.apache.logging`
`name`	ライブラリ名	`log4j-core`
`version`	特定のバージョン	`2.17.0`
`qualifiers` (オプション)	実装の詳細	`arch=amd64`
`subpath` (オプション)	アーカイブまたはモノレポ内のパス	`src/lib/foo`
`artifact_hashes` (オプション)	フィンガープリント	SHA256サム
`license_expression` (オプション)	SPDXライセンス表現	`Apache-2.0`、`MIT`
`file_path` (オプション)	プロジェクト内でライブラリが見つかった場所	`package-lock.json`

この原子的な分解こそが、pURLベースの検索を有用にしています。「django 名前空間にある、バージョン4.x系のすべての pypi パッケージ」といった問い合わせに対し、DefectDojoは自由記述の文字列を解析することなく回答できます。

ソースコードロケーション

Mon, 01 Jan 0001 00:00:00 +0000

ソースコードロケーションは、ロケーションモデルを静的解析にまで拡張します。URL(DAST)や依存関係(SCA)と並んで、コードロケーションは、SASTの検出事項がソースコード内のどこに存在するかをファイルパスと行番号によって示します。

ソースコードロケーションを利用するには、ロケーション機能(ベータ版)が必要です。お使いのインスタンスでロケーションを有効にするには、までご連絡ください。

モデル化する対象

ファイルパスを報告するすべての静的解析の検出事項には、コードロケーションが割り当てられます。ロケーションの正規値は path/to/file.py:42 です(ツールが行番号を報告しない場合はファイルパスのみになります)。他のすべてのロケーションと同様、コードロケーションは共有オブジェクトです。同じファイル・行にある2つの検出事項は同じロケーションを参照し、そのロケーションは検出事項ごと・アセットごとの参照ステータスを保持します。

コードロケーションはスキャン管理されます。手動ではなく、インポートおよび再インポートによって作成・更新されます。「新しいソースコードロケーション」という操作は存在しません。コードの検出事項がどこに存在するかについては、スキャナーが唯一の正しい情報源です。

確認できる場所

サイドバーのすべてのソースコードには、インスタンス内のすべてのコードロケーションが、URLや依存関係と同じフィルタリングおよびタグ付け機能とともに一覧表示されます。
アセットのロケーションメニューにあるソースコードを表示を使うと、一覧を1つのアセットに絞り込めます。
検出事項のページには、現在のコードロケーションと、検出事項が移動している場合はそのロケーション履歴が表示されます。

移動履歴

ソースコードは絶えず変化します。コミットによって行番号がずれ、リファクタリングによってファイル名が変わります。あるツールでロケーションドリフトマッチングが有効になっている場合、移動した検出事項もその同一性を保持し、コードロケーションの参照がその経路を記録します。

検出事項の旧ロケーションへの参照は緩和済みとなり、検出事項がどこへ移動したかとなぜその対応付けが行われたか(最も近い行、データフロー、ファイル名変更など)が記録されます。
新しいロケーションへの参照が作成され、アクティブなまま維持されます。

その結果、閲覧可能な履歴の連鎖ができあがります。「この検出事項は auth.py:42 にあり、次に auth.py:57、そして session.py:31 に移った」といった具合に、検出事項のページ上でタイムラインとして表示されます。同じ履歴の仕組みはURLの移動や依存関係のバージョンアップにも及ぶため、3種類すべてのロケーションが1つのタイムラインUIを共有します。