DefectDojo DefectDojo | docs

エンドポイントからの移行 (Pro)

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

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

移行が行うこと

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

  1. エンドポイントの protocol、userinfo、host、port、path、query、fragment の各フィールドを使用してURLロケーションを作成(または既存のものを再利用)します。新しいURLは自動的に親の Location オブジェクトに紐付けられます。

  2. タグを引き継ぎます。 エンドポイントに付与されているすべてのタグが、ロケーションのタグセットに追加されます。

  3. メタデータを引き継ぎます。 エンドポイントに紐付いている各 DojoMeta 行は、新しいロケーションを指すように再設定されます。

  4. URLが正しいアセット(製品)の下に表示されるよう、LocationProductReference を作成します。

  5. Endpoint_Status ごとに LocationFindingReference を作成します。

    Endpoint_Status フラグ結果として得られるロケーションステータス
    risk_accepted=Trueリスク受容済み
    false_positive=True誤検知
    out_of_scope=True対象外
    mitigated=True緩和済み
    (上記のいずれにも該当しない場合)アクティブ

    このマッピングは順序に依存します。最初に一致したフラグが優先されます。これは、従来の複数フラグの組み合わせを、ロケーションが使用する単一の正規ステータスに意図的に集約するためです。

移行が行わないこと

  • 依存関係ロケーションを作成することはありません。SBOMおよびライブラリデータはこれまでエンドポイントとして存在したことがないため、移行が変換すべき対象がありません。依存関係を取り込むには、SBOMをアップロードするか(SBOMの利用を参照)、依存関係データを出力するパーサーでスキャンを再実行してください。
  • 元のエンドポイントおよびEndpoint_Statusの行を削除することもありません。これらはデータベースに残り、読み取り専用のレガシーAPIを支えます。この機能が有効になった後は、新しいUIやインポート処理では使用されません。

移行後のエンドポイントAPI

ロケーションが有効になると、レガシーエンドポイントAPIは読み取り互換モードに入ります。これは、コードを変更することなく既存の自動化を動作させ続けるために設計されていますが、対象は読み取りトラフィックのみです。

引き続き動作するもの

  • GET /api/v2/endpoints/ — エンドポイントのように見える行を返しますが、実際にはURLロケーションと結合したLocation Product Referenceの行から投影されたものです。おなじみのフィールド(protocol、host、port、path、query、fragment、tags、product、active_finding_count)はすべて存在します。
  • GET /api/v2/endpoints/{id}/ — 単一エンドポイントの取得も同様に動作します。id は元のエンドポイントIDであり、Asset Referenceのマッピングを通じて移行後も保持されます。
  • GET /api/v2/endpoint_status/ および GET /api/v2/endpoint_status/{id}/ — LocationFindingReference から投影された行を返します。レガシーの mitigated、false_positive、out_of_scope、risk_accepted の各ブールフィールドが再構築されます。
  • protocol、host、port、path、query、fragment、product、tag(s) によるフィルタリングは引き続き機能します。
  • 個々のエンドポイントに対する generate_report アクションは引き続き機能します。

403が返されるもの

  • /api/v2/endpoints/ および /api/v2/endpoint_status/ に対する POST、PUT、PATCH、DELETE は、すべて次の本文とともに HTTP 403 を返します。

    Writes to this endpoint are deprecated when V3_FEATURE_LOCATIONS is enabled

    エンドポイントデータを書き込むクライアントは、新しいReferenceエンドポイント(POST /api/v2/location_findings/、POST /api/v2/location_products/)およびURLエンドポイント(POST /api/v2/urls/)に移行する必要があります。

注意すべき挙動の違い

元のエンドポイントAPIとはいくつかの点で動作が異なります。

  • フラグではなく単一ステータス。 ロケーションは一度に1つのステータスしか持ちません。検出事項がEndpoint_Status上で mitigated=True と false_positive=True を同時に持つことに依存したコードがある場合、それはもはや表現できません。移行では、優先度が最も高いフラグ(上記の表に示した順序)が選択されます。
  • Endpoint_Statusの endpoint フィールド。 レガシーの endpoint フィールドは、一致するAsset Referenceを検索することで再構築されます。まれに検出事項のアセットがそのロケーションのAsset Referenceと一致しなくなっている場合、このフィールドはnullになることがあります。
  • ページネーションと並べ替え。 読み取り互換シムで利用可能な並べ替えフィールドは host、product、id、active_finding_count です。クライアントが他のフィールドで並べ替えを行っている場合は、これらのいずれかに切り替えるか、新しいロケーションエンドポイントに移行してください。

タグとメタデータ

エンドポイントに付与されたタグは、(URLサブタイプではなく)ロケーションオブジェクトのタグになります。レガシーAPIにおけるタグベースのフィルタは引き続き一致します。

エンドポイントのメタデータは、移行時にロケーションを指すように再設定されます。/api/v2/endpoint_meta/ 経由でメタデータを読み取る既存の自動化は引き続き動作するはずです。新しいメタデータは、ロケーションエンドポイントを通じて書き込んでください。

前へ
エンゲージメント
次へ
URLの利用