Rules Engine からの移行 (Pro)

注: Rules Engine 2.0 は DefectDojo Pro 専用の機能です。

両方のエンジンは並行して動作します。Rules Engine 2.0 を有効にしても、既存の Rules Engine のルールには何の変更もなく、それらを移行しなければならない期限もありません。

実際に移行したくなったときのために、converter(変換ツール)が用意されています。これは、Rules Engine のルール(フィルターと順序付けられたアクションのリスト)を、それと同等の Rules Engine 2.0 のグラフに変換します。

Converter が保証すること

ルールは、きれいに変換されるか、まったく変換されないかのどちらかです。 すべての変換は、次の2種類の結果を報告します。

  • Problems は、ルールが書き込まれなかったことを意味します。部分的な保存は一切行われません。
  • Warnings は、ルールは変換されたものの、何かが変化したため確認すべき点があることを意味します。

何かが黙って近似されることはありません。この converter の価値の本質は、特に指摘なく変換されたルールは信頼でき、そうでなかったものは手動で確認できるという点にあります。

変換されたルールは常に無効な状態で作成されます。 両方のエンジンが稼働している状況で、同じ Finding に対して同じことを行う2つのルールが存在してしまうことは、converter が自ら引き起こしてはならない唯一の結果です。変換された各ルールを確認し、意図的に有効化してください。

ルールの変換は一度きりです。 変換された各ルールは、その変換元となったルールを記憶しているため、converter を2回実行しても、既に変換済みのものはスキップされ、重複が作成されることはありません。以前に変換したグラフを意図的に置き換えたい場合は、overwrite オプションを使用してください。

Converter の実行

UI から実行する

ルール一覧には変換用のアクションが用意されており、ルールごとに何が変換され、何がスキップされ、何が失敗したかが報告されます。

コマンドラインから実行する

python manage.py convert_rules_to_v2
オプション効果
--dry-run各ルールが生成するはずのグラフを表示し、何も書き込みません。
--rule-ids 1,2,3指定したルールのみを変換します。省略した場合はすべてのルールを変換します。
--overwrite変換済みルールのグラフをスキップする代わりに置き換え、そのバージョンを上げます。
--activate-schedules各スケジュールも変換後のルールにコピーします。デフォルトではオフです。
--drop-invalid-filtersルールを失敗させる代わりに、フィルターセットがもはや認識しないスコープフィルターを削除し、警告を出します。
--jsonレポートをテキストではなく JSON として出力します。

このコマンドは、ルールの変換に失敗した場合にのみ、非ゼロで終了します。スキップは報告されますが、失敗とはみなされません。

まずは全ルールに対して --dry-run を実行し、何が起きるかを確認してから、実際に変換してください。

変換によって生成されるもの

Rules Engine の概念変換後
ルールのフィルタートリガーノード上の Scope
スケジュールを持つルールOn a Schedule トリガー。
スケジュールを持たないルールManual Run トリガー。
各アクション(順序通り)同じ順序で連結された1つのノード。
条件で制御されたアクションそのノードの手前に配置される If / Filter ノード。

フィルターの語彙は両エンジン間で共有されているため、scope は変換の必要なくそのまま移行されます。これは意図的な設計であり、実装は1つでも、フィルターセット自体は同一だからです。

変換されたグラフは、手作業で構築したグラフと同じ方法で検証されます。これには、ノードごとの設定や、各ドロップダウンで許容される値も含まれます。製品側で既に廃止された深刻度や risk の値を保持しているルールは、実行時ではなく変換時に検出されます。

引き継がれないもの

計画しておくべき点が4つあります。converter は、これらを実行のたびに注記として報告します。

  • Run の履歴はそのままの場所に残ります。 既存の実行履歴、およびそれに関連する対象レコードとスキップされたレコードは、Rules Engine の UI に残ったままになります。これらはコピーされません。
  • スケジュールはデフォルトでは有効化されません。 スケジュールトリガーのルールは変換されますが、--activate-schedules を指定しない限り、そのスケジュールはコピーされません。これにより、両エンジンが稼働している間、稼働中のスケジュールの所有権は従来のエンジンだけが持つことになり、変換されたルールが気づかないうちに発火し始めることはありません。実際にスケジュールをコピーする場合、コピーには元のものと衝突しないよう別の名前が付けられます。
  • 並行実行モデルが異なります。 Rules Engine には、インスタンス全体で1つの実行ロックがあります。Rules Engine 2.0 はルールごとに直列化されるため、異なるルールは同時に実行されます。これまで順番に実行されていたルール群が、これからは重複して実行されるようになります。
  • 1つのアクションには相当するものがありません。 「false positive を false に設定する」アクションは Rules Engine 2.0 のノードとして表現できないため、手動で変換する必要があります。

所有者が設定されていないルールも、警告付きで変換されます。所有者のいないルールはどの Finding も参照できないことを忘れずに、有効化する前に所有者を割り当ててください。

推奨される手順

  1. Rules Engine 2.0 を有効にし、既存のルールはそのまま稼働させておきます。
  2. --dry-run を付けて converter を実行し、レポートを確認します。
  3. 変換します。すべて無効な状態になります。
  4. 変換された各ルールを開き、グラフを確認し、モードは Simulate のままにしておきます。
  5. 変換されたルールを有効化し、しばらくの間、元のルールと並行して実行させます。Simulate では Finding は変更されますが何も送信されないため、その Run の内容を元のルールが行っていたことと比較します。
  6. 問題がないことを確認できたら、元のルールを無効化し、変換されたルールを Live に切り替えます。
  7. 古いルールがもう何も実行しなくなったら、最後にスケジュールをコピーします。

手順5は省略しない価値があります。両方のエンジンが同じ Finding を編集すること自体は観察する分には問題ありませんが、送信をいつ開始するかを決めるのはあなた自身であるべきです。