実行 (Pro)

注: Rules Engine 2.0はDefectDojo Pro限定機能です。

**実行（run）**とは、1つのルールの1回分の実行のことです。成功したか失敗したかにかかわらず、すべての実行が記録され、その内部の各ノードも痕跡を残します。Rules Engine 2.0 > Runsにその一覧が表示されます。

実行が記録する内容#

ノードトレース#

実行内では、各ノードが自身の行を記録します。

トレースは、ルールが期待通りに動作しなかったときに確認するものです。If / Filterノードが400件のitems inを報告し、trueブランチへの出力が0件であれば、推測することなく条件が誤っていることが分かります。

実行モデル#

ノードはトポロジカル順序で実行されます。あるノードは、そこに入力を供給するすべてのノードが実行を終えた時点で実行されます。複数の入力エッジを持つノードは、それらすべての出力を連結して受け取ります。何も入力を供給されないノードも、空の入力リストで実行されます。

失敗した実行は何も変更しない#

実行はアトミックです。いずれかのノードがエラーを発生させた場合、その実行が行ったFindingへの変更はすべてロールバックされます。

トレースはロールバックの対象にはなりません。ノードの行とErrorステータスは事後に書き込まれるため、失敗した実行は、中途半端に適用された変更を一切残すことなく、どのノードが壊れたのかを正確に伝えてくれます。これは、Runsページを読む際に念頭に置くべき最も重要な保証です。エラーになった実行とは、何も行わなかった実行のことです。

Egress（送出）についても同じ規則が適用されます。配信は実行のトランザクション内で記録され、コミット後にのみディスパッチされるため、ロールバックされた実行は何も送信しません。

1ルールにつき同時に実行できるのは1件のみ#

1つのルールが進行中に持てる実行は1件のみです。同じルールに対して実行中に2回目のトリガーが発生しても、競合することはありません。待機してからリトライします。

異なるルール同士は完全に並行して実行されるため、動作の遅いルールが他のルールを妨げることはありません。

実行を行っていたワーカーが強制終了されるなどして実行が放棄された場合、ルールが永久に止まったままにならないよう、停滞ウィンドウ（デフォルトで30分）の経過後にロックが解放されます。このウィンドウに近づいた実行はその前に自ら停止し、正しく巻き戻しを行うため、単に遅いだけの実行がその後継の実行と同時に動いてしまうことは決してありません。

カスケード#

Findingを変更するルールは、まさに他のルールがトリガーとして利用できる種類のイベントを生成します。Rules Engine 2.0はこれを許可しており、A -> B -> Cのような連鎖が機能します。ただし、これを2つの独立した方法で制限しています。

• Depth（深さ）。 イベントは、それを発生させた変更から最大3回のカスケードホップまでしか伝播できません。
• Chain membership（チェーン所属）。 すべてのイベントは、そのチェーン内で既に通過したルールの一覧を保持しており、同じルールが同じチェーン内で2回実行されることはありません。そのため、ルールが自分自身を再トリガーすることも、2つのルールが互いにやり取りを繰り返すこと（ピンポン）もできません。

実行のDepthフィールドとSource runフィールドを使うと、チェーンを遡ってそれを開始した変更まで追跡できます。Triggered byはチェーン全体を通じて引き継がれるため、ある人が発生させたカスケードは、どのホップにおいてもその人物に帰属したままになります。

実行中のルールによって行われた変更は、新規のユーザー操作のように見えるのではなく、そのルール自身のカスケードに帰属します。そのため、内部的に作業を委譲するルールがチェーンを膨張させることはありません。

スケールと制限#

実行には上限がありません。 ルールは、そのスコープに一致するものをすべて処理します。どれほど件数が多くてもです。最初のN件のFindingで黙って処理を止めてしまうルールは、信頼できるルールとは言えません。

その代わりに、実行はデフォルトで一度に1,000件のFinding単位のチャンクで処理されます。メモリ上に保持されるのはそのチャンクのみであるため、非常に大きなスコープに対する処理も、カバー範囲ではなくメモリ使用量の面で制限されます。唯一の例外はPreviewで、こちらは件数に上限があり、切り詰めが発生した場合はトレースにその旨が表示されます。

作業の分割方法を決める他の2つの数値があります。

• イベントあたりのFinding数、デフォルトで500件。一括変更は複数のイベントに分割され、それぞれが独自の実行になります。大規模なインポートにおける実際の効果は、Finding1件ごとに実行が1件発生するのではなく、管理可能な件数の実行に収まることです。
• Findingごとの送信上限、デフォルトで1,000件。Finding1件につき1件のメッセージを送信するよう設定されたegressノードは、1回の実行につきこの件数で停止し、何件を送信しなかったかを示す明示的なスキップを記録します。これにより、チャンク処理された実行だけではもはや制限されなくなった配信の行数とキュー投入されたタスクの数が制限されます。

これら3つはいずれもデプロイメント設定であり、Configurationに記載されています。

実行にかかる時間の上限#

実行は各チャンクの後にハートビートを記録します。停滞検出は開始時刻ではなくこのハートビートを参照するため、進捗し続けている長時間のスイープがクラッシュしたワーカーと誤認されることはありません。

2つのウィンドウが適用され、どちらも設定可能です。

• ハートビートが30分間ない実行は放棄されたものとみなされ、エラー扱いとなり、ロックが解放されます。
• 決して終わらない実行に対する保護として、実行は6時間経過すると強制終了されます。

保持期間#

実行は、そのノードごとの行やFindingの来歴とともに、デフォルトで180日間保持されます。配信は別途180日間保持されます。

この点は暗黙のままにせず、製品側が明示します。実行の詳細には保持期間と、その実行が削除される日付が表示されます。配信をまだ保持している実行は、それらが削除されるまで保持されます。

どちらのウィンドウも設定可能で、いずれも無期限に記録を保持するよう設定できます。Configurationを参照してください。

ルールを手動で実行する#

トリガーがManual Runであるルールは、ルール一覧のRunアクションで実行されます。それ以外のトリガーを持つルールは、そのトリガーが発生したときに実行されます。

エディタ内のPreviewは、グラフを実行するもう一つの方法です。実際のエンジンを実行した上ですべてをロールバックし、実行の記録は残さず、egressはシミュレーションを強制されます。作成中はPreviewを使用し、実際に何が起きたかを確認する際は実行（run）を使用してください。

Findingの来歴#

実行（Runs）は「このルールは何をしたのか」という問いに答えます。来歴（Provenance）は、その逆の問い、「このFindingはなぜ変更されたのか」に答えます。

ルールが行うすべての変更は、責任を持つルール、実行、ノードとともにFindingに対して記録され、Finding自体のタイムラインとして表示されます。記録されるアクションは次のとおりです。

フィールドの編集では、各フィールドの変更前と変更後の値を含め、何が変更されたかが記録されます。非常に長い値は記録内で切り詰められるため、タイムラインはFindingの複製ではなく、あくまで変更の記録として保たれます。

通知や配信もここに記録されます。これは意図的なものです。メッセージを送信したもののフィールドを何も変更しなかったルールが、そうしなければFindingに何の痕跡も残さないことになってしまうためです。

来歴はルールが削除された後も残ります。ルールや実行を削除しても、タイムラインの項目は保持されたまま単にリンクが解除されるだけなので、誰かが整理を行っても履歴が消えることはありません。

履歴を持つルールの削除#

配信を生成したルールは、その配信を残したまま削除することはできません。先に配信を削除するか、ルールをそのまま残して無効化してください。これは意図的な仕様です。配信は外部システムに実際に何が送信されたかの記録を保持しており、カスケード削除を行うと進行中の送信までも失われてしまうためです。