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 も参照できないことを忘れずに、有効化する前に所有者を割り当ててください。
推奨される手順
- Rules Engine 2.0 を有効にし、既存のルールはそのまま稼働させておきます。
--dry-runを付けて converter を実行し、レポートを確認します。- 変換します。すべて無効な状態になります。
- 変換された各ルールを開き、グラフを確認し、モードは Simulate のままにしておきます。
- 変換されたルールを有効化し、しばらくの間、元のルールと並行して実行させます。Simulate では Finding は変更されますが何も送信されないため、その Run の内容を元のルールが行っていたことと比較します。
- 問題がないことを確認できたら、元のルールを無効化し、変換されたルールを Live に切り替えます。
- 古いルールがもう何も実行しなくなったら、最後にスケジュールをコピーします。
手順5は省略しない価値があります。両方のエンジンが同じ Finding を編集すること自体は観察する分には問題ありませんが、送信をいつ開始するかを決めるのはあなた自身であるべきです。