DefectDojo DefectDojo | docs

配信 (Pro)

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

ルールが生成するすべての送信(アウトバウンド)側の副作用は、配信台帳の1行になります。Rules Engine 2.0 > Deliveries にその一覧が表示されます。

この行はネットワーク呼び出しが発生する前に書き込まれ、送信される(または送信された)内容を正確に保持します。これにより、送信(egress)は「誰かが保存していることを願うログ行」ではなく、監査可能なものになります。また、これが Simulate が別のコードパスではない理由でもあります。シミュレーション送信は、ディスパッチ手順が省略されただけの、同じ行なのです。

配信が記録する項目

フィールド意味
Run と Nodeどの実行(Run)とどの送信ノード(Node)がこれを生成したか。
Finding検出事項単位の送信の場合、対象となる検出事項。バッチ送信の場合はグループを記録します。
Channel送信の種類。
Target解決済みの送信先: JIRAプロジェクトキー、チャネル、URL、アドレスなど。
Title送信内容の一行説明。
Payload送信される(または送信された)内容そのもの。
Modesimulate または live。
Status配信がどこまで到達したか。
Attemptsこれまでに試行された送信回数と、許容される最大回数。
Last error直前の試行が失敗した理由、または配信がスキップされた理由。
Response送信先から返された応答。
External reference と URL送信先が返したチケットキー、メッセージID、ファイルパスと、存在する場合はそこへのリンク。

チャネル

チャネル生成元
JIRAJIRA課題を作成
Downstream connectorダウンストリームチケットを作成
SlackSlackメッセージを送信、およびSlackへ送信されるレポート通知
Microsoft TeamsMicrosoft Teamsメッセージを送信
Emailメールを送信、およびメールで送信されるレポート通知
WebhookWebhookを呼び出す
Reportレポートを生成
In-app alertアプリ内アラートを発行

ステータス

ステータス意味
simulatedルールが Simulate モードだったことを示します。何も送信されておらず、今後も送信されません。
skipped既に何かがこの送信をカバーしていたか、ゲーティングによって拒否されたことを示します。理由は last error フィールドに記載されます。
pendingLive モードで記録され、配信タスクの実行を待っている状態です。
dispatched統合サービスに引き渡され、確認を待っている状態です。
sent配信が確認された状態です。
failed4xxエラーやベンダー側のエラーなど、恒久的に拒否された状態です。再送可能です。
dead再試行が尽きたか、確認が一度も届かなかった状態です。再送可能です。

skipped については詳しく説明する価値があります。スキップは黙って無視されるのではなく記録されます。なぜなら「ルールは何もしなかった」ことと「この検出事項には既にチケットがあったためルールは何もしなかった」ことは異なる答えであり、そのうち一方だけが問題だからです。

スキップにはよくある理由が3つあり、last error フィールドには常にそのどれであるかが記載されます。

  • Idempotency(べき等性)。 何かが既にこの送信をカバーしていました。
  • チャネルが無効化されている。 Slackが無効化されているインスタンスでSlackノードを持つルールは、失敗するのではなく、その旨を説明するスキップを記録します。チャネルが有効な状態で保存されたルールは、誰かがそのチャネルを無効化したときにエラーを出し始めるべきではありません。ノードの利用可否を参照してください。
  • 検出事項単位の送信上限に達した。 検出事項ごとに1件のメッセージを送信するノードは、デフォルトでは1回の実行につき1,000件で停止し、送信されなかった件数を記録します。

ペイロードの忠実度

台帳は、記録されたペイロードが実際に送信されるボディにどれだけ近いかについて正直です。これはチャネルによって異なるためです。

忠実度意味
exact実際に送信された内容とバイト単位で同一です。
rendered実際のヘルパーによってレンダリングされていますが、送信時のゲーティングによって内容が削られる場合があります。
dojo request統合サービスに渡された正確なリクエストです。ベンダー固有のペイロードは下流で組み立てられます。
summary送信内容そのものの再現ではなく、送信内容の説明です。生成されたレポートがその例です。ファイルは送信時点のライブデータから作成されるため、保存されたコピーは何かが変更された瞬間に不正確になってしまいます。

二重送信防止機構

べき等性キーごとに存在できるアクティブな配信は1件のみであり、これは慣習ではなくデータベースによって強制されます。アクティブとは pending、dispatched、または sent を意味します。

アクティブな配信と衝突する2件目の送信は、理由が記録された skipped 行になります。これは決して黙った無処理にはならず、重複したチケットにもなりません。

simulated、skipped、failed、dead の各行は権利を保持しないため、失敗した配信はその場で再送でき、同じキーを巡って2件目の行が競合することはありません。

再試行

Live状態の配信は自動的に再試行されます。各行はそれぞれ独自の試行回数と上限(デフォルトでは6回)を持つため、失敗している送信先が他の行を道連れにすることはありません。再試行の間隔は徐々に広がります(バックオフ)。

最後の再試行を使い切ると、その行は pending のまま放置されるのではなく dead としてマークされます。使い果たしたことは黙って隠されるのではなく、可視化されます。

ワーカーが送信途中で強制終了された場合、メッセージは再配信されます。再送信される前に行がロックされ、ステータスが再確認されるため、再配信が二重送信になることはありません。

統合サービスに引き渡された配信は dispatched に移行し、確認コールバックを待ちます。6時間以内にコールバックが届かない場合、その行は再送可能となるよう dead としてマークされます。この時間枠は意図的に余裕を持たせてあります。下流のキューが1時間程度滞留するのは正常なことであり、行を急いで打ち切ってしまうと、再送が重複チケットを生んでしまうためです。

配信の再送

failed または dead の配信は、Deliveriesページから再送できます。台帳には、いつ、誰によって再送されたかが記録されます。

再送には Rule Edit 権限が必要です。

再送は記録されたペイロードを再送信します。レポートの場合、ペイロードはファイルそのものではなく生成すべき内容の説明であるため、現在のデータからレポートを再生成することになります。

Simulate

Simulate モードでは、すべての送信ノードがステータス simulated、完全なペイロード、解決済みのターゲットを持つ配信行を書き込んだ後、停止します。ディスパッチは登録されないため、実行がどのように展開しても後から送信されることはありません。Previewも同様に動作しますが、行の挿入すら行いません。

これは、ルールを公開する前にレビューするために意図された方法です。Simulateで有効化し、実際の検出事項に対して実行させ、記録されたペイロードを確認します。

Simulateが差し止めるのは送信のみであることを忘れないでください。検出事項ノードは引き続き検出事項を変更します。

保持期間

配信はデフォルトで180日間保持され、その後は保持ジョブによって削除されます。

これはこの機能の中で最も急速に増加するテーブルです。検出事項ごとに1件のメッセージを送信するノードは、SimulateモードでもLiveモードでも検出事項ごとに1行を書き込むためです。デフォルトは「すべて保持する」ではなく実際の期間となっているため、増加が知らぬ間に問題化することはありません。

発見を強いられるのではなく、あらかじめ通知されます。配信の詳細には保持期間とその行が削除される日付が表示され、この日付は読み込み時に再計算されるため、期間を変更するとすぐに反映されます。

より長い送信監査証跡が必要な場合は期間を長く設定し、すべて保持したい場合は 0 に設定してください。設定を参照してください。

前へ
実行
次へ
Rules Engine からの移行