Skip to main content

Webhookとは何ですか?

Webhookは、特定のイベントが発生した際にCorgeaが外部システムにリアルタイムで通知を送る自動化されたHTTPコールバックです。更新を確認するためにAPIを継続的にポーリングする代わりに、Webhookは何かが起きた瞬間に指定されたエンドポイントに直接イベントデータをプッシュします。

主な利点

  • リアルタイム通知 - セキュリティ上の問題が検出されたり、ステータス変更があったり、スキャン完了した際に即時の更新を受け取る
  • 自動化 - Slack、Zapier、カスタムアプリケーションなどの外部ツールでワークフローをトリガーします
  • 効率 - APIをポーリングする必要がなく、イベントが発生した際にデータをあなたにプッシュします
  • 柔軟性 - 関心のあるイベントのみを購読し、プロジェクト、ステータス、またはスケジュールされたスキャンで絞り込む
  • 信頼性 - 組み込みの再試行ロジックと配信追跡により通知が確実に届きます

サポートイベントタイプ

Corgeaは以下のイベントでWebhookをサポートしています: 問題イベント:
  • issue.status_changed - 問題のステータスが更新されたときにトリガー(例:オープン→修正済み)
  • issue.assigned - 問題がチームメンバーに割り当てられたときにトリガーされます
SLAイベント:
  • sla.violation - 日々のSLAジョブが、修復やエスカレーション期限を過ぎて1つ以上のSASTまたはSCAの問題を検出したときにトリガーされます( SLA管理のSLAごとに設定)
スキャンイベント:
  • scan.started - セキュリティスキャン開始時にトリガーされます
  • scan.completed - スキャンが成功裏に完了したときにトリガーされます
  • scan.failed - スキャン中にエラーが発生した場合にトリガーされます
  • scheduled_scan.daily_report - スケジュールされたスキャン実行が完了した際に毎日トリガーされ、過去24時間以内のすべての実行で新たな問題が要約されます。メールとペイロードスキーマについては 通知 を参照してください。
スキャンライフサイクルイベント(scan.startedscan.completedscan.failed)には data.message が含まれます。これはSlackやZapier、その他のチャットツールに入力できる短いプレーンテキストの要約です。また、トリアージフィールド( pull_request_idscan_urltrue_positive_countproject_namestatus)も含まれます。Slack Workflow Builder(Type = Slackhooks.slack.com/triggers/...)では、Corgeaがscan.startedscan.completedscan.failedwebhook.testのみをトップレベルのキーにフラット化します。Slackでネストされたdata.*をマッピングするとHTTP 400が発生します。同じSlack Webhookのその他のイベントタイプでは、ネストされたエンベロープが維持されます。詳細はSlackを参照してください。
ユーザー認証イベント:
  • user.login - ユーザーが正常にログインした際にトリガーされます
  • user.login_failed - ユーザーのログイン試行が失敗したときにトリガーされます

Webhookの仕組み

Webhookのライフサイクル

1

イベントが起こる

Corgeaで何かが起こる(例:スキャン完了、問題ステータスが変わるなど)
2

Webhookがトリガーされました

システムはそのイベントタイプに登録されているすべてのWebhookを識別します
3

フィルタリング適用

プロジェクト、ステータス、スケジュールスキャン、PRのみ、完了後フィルターがWebhookをトリガーさせるかどうかを判断します
4

ペイロード製造

デフォルトでは、標準化されたJSONエンベロープはイベント詳細で構築されます(設定されていればカスタムボディテンプレートが使われます)。Slack Workflow Builder(Type = Slack + triggers/ URL)では、Corgeaは scan.*webhook.test のみHTTPボディをフラット化します。他のイベントは入れ子状のままです。
5

HTTP POSTリクエスト

ペイロードはセキュリティヘッダーとともにWebhookのURLに送信されます
6

リトライロジック

リクエストが失敗した場合、指数関数的なバックオフで自動再試行が行われます
7

配信記録済み

すべての試みは配信履歴に記録され、トラブルシューティングが行われます

ペイロード構造

デフォルトでは、Webhookのペイロードは標準化されたネストされたエンベロープ(Zapier / その他)に従います。スキャンライフサイクルイベントには data.message およびトリアージフィールドが含まれます:
webhook-payload.json
summary.total_issues 、削除されていないすべての問題(誤検知やコード品質を含む)をカウントします。 true_positive_countmessage およびスキャンイベントフィルターで使用されるトリアージカウントです。 true_positive_countは誤検知でない削除されていないセキュリティ検出結果をカウントします(スキャンUIと同じ論理で、status=false_positivehold_reason=false_positivedetected_by=code-quality除外)。scan.completedメッセージのオプション(N with fixes)接尾辞は、誤検知でない検出結果の中でのみ修正をカウントします(スキャン上のすべての問題ではありません)。
Slack Workflow BuilderType = SlackでURLがhooks.slack.com/triggers/...の場合、Corgeaはscan.*webhook.testに対してフラットなボディをPOSTします(トップレベルのmessagepull_request_idscan_urltrue_positive_countcompanyなど)。Slackではネストされたdata.*のマッピングがサポートされず、HTTP 400が発生します。このWebhookのスキャン以外のイベントはフラット化されません。詳細はSlackを参照してください。
**ペイロードsla.violation**例(SLA管理の日次ジョブより):
sla-violation-payload.json
Integrations → Webhookssla.violationに登録するか、SLA管理フォームからWebhookを添付してください(既存のWebhookは自動で購読されます)。 **ペイロードscheduled_scan.daily_report**例:
scheduled-scan-daily-report-payload.json
企業管理者は、このイベントが設定→通知 →会社のデフォルトからWebhookに送信されるかどうかを制御できます。 Webhookの設定時にCustom Bodyを指定すると、Corgeaはデフォルトのペイロード構造ではなく、レンダリングされたJSONオブジェクトを送信します。
scheduled_scan.daily_report イベントは同じエンベロープを使用しますが、独自の data スキーマを持っています。詳細は ペイロードの例 を参照してください。

セキュリティ機能

  • CorgeaはWebhookを作成する際に自動的にシークレットキーを生成します
  • 各リクエストには、ペイロードのHMAC-SHA256ハッシュを含む X-Corgea-Signature ヘッダーが含まれています
  • シークレットキーで署名を確認し、WebhookがCorgeaから発信されているか確認する
  • エンドポイントに求められるヘッダー(例:認証トークン)を含める
  • Webhook設定時にカスタムヘッダーを設定する
  • すべてのWebhook URLはHTTPSを使用する必要があります(通常はポート443)
  • URLはURL内に認証情報を埋め込んではならない
  • プライベート、ループバック、リンクローカル、予約済み、またはマルチキャストアドレスに解決される宛先は拒否される(SSRF保護)
  • オペレーターはオプションでホストを制限 WEBHOOK_ALLOWED_HOSTS 設定

自動再試行ロジック

Webhookの配信が失敗した場合、Corgeaは自動的に次の戦略で再試行します:
  • 初回試行 + 2回の再試行 = 合計3回の試み
  • 指数的バックオフ:2秒、再試行間4秒
  • タイムアウト:リクエストごとに10秒
  • 自動一時停止:10回連続で失敗すると、Webhookは自動的に一時停止されます

各Webhookに送信されるヘッダー

webhook-headers.txt

Webhookのセットアップ

Webhook管理インターフェース:設定済みWebhookのリストを表示します

前提条件

Corgeaアカウントの管理者権限または統合管理権限
POSTリクエストを受け入れるWebhookエンドポイントURL
HTTPSエンドポイント(セキュリティに必要)

ステップバイステップのセットアップ

1

統合へナビゲーション

  • CorgeaでIntegrationsを開きます
  • Automation IntegrationsWebhooksを開きます
Webhookが有効で、 Slack と Zapier が非推奨マークされている自動化統合
単独のSlackZapierの項目は非推奨です。新しい設定ではWebhooksを使用してください。既存のSlack/Zapier連携は引き続き動作します。テストまたは削除するには、View Allを開きます。
2

基本設定の設定

名前、Webhook URL、Typeフィールドを表示するWebhookフォームを作成する
  • 名称:明確なラベル(例:「Slack通知」や「本番スキャンアラート」など)
  • Webhook URL:あなたのHTTPSエンドポイント
  • タイプ:
    • Slack — Slackワークフロービルダーまたは受信Webhookの送信先
    • Zapier — ザピア・キャッチフック
    • Other — カスタムエンドポイント
Slackでは、Workflow BuilderのURL(hooks.slack.com/triggers/...)を推奨します。Corgeaは、これらの送信先に対するscan.*webhook.testをフラット化します。ネストされたdata.*ではなく、トップレベルのmessageをマッピングしてください。スキャン以外のイベントはネストされたままです。Incoming Webhooks(hooks.slack.com/services/...)は、レンダリング後のJSONにトップレベルで空でない文字列のtextフィールドを含むCustom Bodyを設定しない限り拒否されます。{"text": "{{message}}"}は、スキャンライフサイクルイベントとscheduled_scan.daily_reportだけで使用できます。詳細はSlackを参照してください。
3

イベント購読

イベント購読フォームには、問題、SLA、スキャン、ユーザー、スケジュールされたスキャンイベントの切り替え機能付き
通知を受け取るイベントを有効にします。複数選択できます。
  • 問題ステータス変更
  • 割り当てられた問題
  • SLA違反(sla.violation)
  • スキャン開始/完了/失敗
  • ユーザーログイン / ユーザーログイン失敗
  • Scheduled Scan Daily Report(scheduled_scan.daily_report
4

フィルターの設定(オプション)

プロジェクトスコープ、スケジュールスキャンスコープ、カスタムヘッダー、カスタムボディセクション
スキャンイベントフィルター ( scan.* イベント用)
  • プルリクエスト/マージリクエストのみスキャンpull_request_idなしのスキャンはスキップ
  • 誤検知でない検出結果がある完了済みスキャンのみtrue_positive_countが0の場合はscan.completedをスキップします(scan.failedscan.startedには影響しません)
プロジェクトスコープ
  • 無効のままにすると、すべてのプロジェクトからイベントを受信
  • フィルターを有効にすると、Webhookを選択したプロジェクトに限定
  • sla.violationでは、ペイロード内のいずれかのプロジェクトが一致するとWebhookを送信
ステータス変更フィルター ( issue.status_changed用)
  • 空欄にすると、すべてのステータス変更を受信
  • または、fixedfalse_positiveなどのステータスに限定
スケジュールスキャンスコープscan.*イベント用)
  • 無効のままにすると、手動とスケジュールの両方を含むすべてのスキャンを受信
  • 有効にすると、選択したスケジュールスキャンだけを受信
5

カスタムヘッダーとボディの追加(オプション)

カスタムヘッダーWebhookの送信先で必要なヘッダーを追加してください。各サービスには異なる要件があります:
必要ヘッダー:
トークンの入手方法:
  1. Jiraで「Incoming webhook」トリガー付きの自動化ルールを作成します
  2. Jiraが提供したシークレットトークンをコピーする
  3. Corgeaのヘッダー値として追加する
Jira Webhookのドキュメント
カスタムヘッダーは 不要 — 認証はSlackのURLにあります。Workflow BuilderのURL(https://hooks.slack.com/triggers/...)を推奨します。Type = Slackでは、Corgeaがscan.*webhook.testをフラット化します。messagepull_request_idscan_urltrue_positive_countcompanyをマッピングしてください。ネストされたdata.*マッピングしないでください(SlackからHTTP 400が返されます)。その他のイベントタイプはフラット化されません。詳細はSlackを参照してください。受信Webhook(https://hooks.slack.com/services/...)には、レンダリングされたJSONがトップレベルの空でない文字列 text フィールドを持つカスタムボディが必要です。 {"text": "{{message}}"} はスキャンライフサイクルイベントや scheduled_scan.daily_reportにのみ使用してください。
カスタムヘッダーは不要 Teams Webhook URL自体に認証が含まれています。TeamsのWebhookURLを貼り付けるだけです(フォーマット: https://xxx.webhook.office.com/webhookb2/xxx/IncomingWebhook/xxx)
Teamsの受信Webhookはカスタムヘッダーを検証しません。セキュリティはWebhookのURLを非公開に保つことで提供されます。
Teams Webhook ドキュメント
ヘッダー:
JWTやOAuthトークンを使うREST APIでよく使われます。
ヘッダー:
Splunk HTTP Event Collector(HEC)エンドポイントにWebhookイベントを送信する場合に使用します。
ヘッダー(1つを選び):
または
シンプルなAPIキー認証にはよく使われます。
カスタムヘッダーは不要 PagerDuty Events API v2は認証にJSONペイロードの routing_key を使用しています。PagerDuty Events APIエンドポイントをご利用ください: https://events.pagerduty.com/v2/enqueue
PagerDutyはカスタムヘッダーを検証しません。認証はリクエスト本体のrouting_keyを通じて行われます。
PagerDuty Webhook ドキュメント
カスタムヘッダーは不要 - ZapierのWebhookURLはURL自体に認証が含まれています。「ZapierによるWebhooks」トリガーを作成し、提供されたURLを使います。
ZapierのCatch Hookはデフォルトでカスタムヘッダーを検証しません。セキュリティはWebhookのURLを非公開に保つことで提供されます。必要に応じてZap内にヘッダー検証ロジックを追加することもできます。
Zapier Webhookのドキュメント
もしサービスがここに記載されていない場合は、サービスのwebhookや受信webhookのドキュメントで必要なヘッダーを確認してください。
重要: Corgeaは設定したカスタムヘッダーを送信しますが、すべてのwebhook宛先がそれを検証するわけではありません。Slack、Teams、Zapierのようなサービスはヘッダー検証ではなくシークレットURLに依存しています。カスタムヘッダーは、目的のサービスが実際に必要または検証している場合(JiraやカスタムAPIなど)にのみ追加してください。
カスタムボディ
  • Webhookリクエストボディ用のJSONオブジェクトテンプレートをオプションで提供
  • 空欄のままにしてCorgeaのデフォルトのペイロード構造を使う
  • サポートされたプレースホルダー:
    • {{payload}} (完全なデフォルトペイロードオブジェクト)
    • {{time}} (Unixの秒)
    • {{timestamp}} (ISO 8601タイムスタンプ)
    • {{event_type}}
    • {{event_id}}
    • {{message}}(スキャンライフサイクルイベントと日次レポートで利用可能)
  • レンダリングされたテンプレートが無効なJSONの場合、配信が失敗し、webhook履歴にエラーが表示されます
6

保存して有効化

  • クリック Webhook作成
  • ポップアップからシークレットキーをコピーする — Corgeaは一度だけ表示します
WebhookのシークレットキーポップアップがWebhook作成後に一度表示されます
ダイアログを閉じる前にシークレットキーを保存してください。その後は再表示できません。ローテーションが必要ならサポートに連絡してください。
  • クリック シークレットキーを保存しました
  • Webhookがアクティブでイベントの受信を開始する
7

Webhookをテスト

  • Webhookを開き、「テスト・Webhook」 クリック
  • エンドポイントが2xxレスポンスを返すことを確認する
  • Slack Workflow Builderの場合:テスト中に変数をマッピングできるよう、トップレベル message が空でないフラットボディとサンプルトリアージキー(pull_request_idscan_urltrue_positive_countなど)を備えてください。ネストのみのワークフロービルダー設定はサポートされていません。

Webhook署名の検証

作成時に表示されたシークレットキーを使って、各リクエストの X-Corgea-Signature ヘッダーを検証します。
verify-signature.py

ユースケース

1.リアルタイムSlack通知

シナリオ:重大度の高い問題が見つかった場合はSlackのセキュリティチームに通知します セットアップ:
  • Slackワークスペース内でSlackの受信WebhookURLを作成する
  • Corgeaでは、以下のようなWebhookを作成します。
    • タイプ: Slack
    • URL:あなたのSlackWebhookURL
    • イベント: scan.completed
    • プロジェクトフィルター:重要な制作プロジェクト
結果:スキャン完了すると #security チャンネルに即時通知が届きます

2.重大な問題に対する自動チケット作成

シナリオ:重大な問題が検出された際にJira/Linearで自動的にチケットを作成します セットアップ:
  • チケットを作成するZapierのzapやカスタムエンドポイントを作成する
  • Corgeaでは、以下のようなWebhookを作成します。
    • イベント: scan.completedissue.status_changed
    • ステータスフィルター:ステータスのみ open (重複チケットを避けるため)
    • プロジェクトフィルター:制作プロジェクト
結果:重大な問題はプロジェクト管理ツールで自動的にチケットとして登録されます

3.リスク受容ワークフロー統合

シナリオ:セキュリティ問題が「承認済みリスク」とマークされている場合、JiraまたはLinearで自動的に承認済みリスクを記録する セットアップ:
  • ドキュメントチケットを作成するエンドポイントまたはZapier統合を作成する
  • Corgeaでは、以下のようなWebhookを作成します。
    • イベント: issue.status_changed
    • ステータスフィルター:状態のみaccepted_risk
    • プロジェクトフィルター:すべてのプロジェクトまたは特定の高コンプライアンスプロジェクト
  • 統合を以下に設定する:
    • リスク受容を文書化したチケットを作成する
    • 問題の詳細(分類、ファイルパス、緊急性)を含める
    • 「リスク受け入れ」ラベルが付いたタグ
    • セキュリティリードにレビューを割り当てる
結果:すべての承認済みリスクはプロジェクト管理システムに完全なコンテキストとともに自動的に記録され、コンプライアンスおよびリスク管理のレビューのための監査トレイルが作成されます

4.カスタムダッシュボード統合

シナリオ:内部ダッシュボードにリアルタイムのセキュリティ指標を表示する セットアップ:
  • Webhookデータを受け取りダッシュボードを更新するエンドポイントを構築する
  • Corgeaでは、以下のようなWebhookを作成します。
    • イベント:すべてのスキャンイベントと問題イベント
    • フィルターなし(すべて受信)
結果:ダッシュボードはリアルタイムのセキュリティスキャン結果と問題トレンドを表示します

5.マルチチームルーティング

シナリオ:異なるプロジェクト通知を異なるチームにルーティングする セットアップ:
  • 各チームごとに別々のWebhookを作成する:
    • バックエンドチーム Webhook: プロジェクトフィルター = バックエンドプロジェクト、Slackチャンネル #backend セキュリティ
    • フロントエンドチームのWebhook: プロジェクトフィルター = フロントエンドプロジェクト、Slackチャネル #frontend セキュリティ
    • DevOps Team Webhook: プロジェクトフィルター = インフラストラクチャプロジェクト、Slack チャンネル #devops セキュリティ
結果:各チームは自分たちのプロジェクトに関連するセキュリティ問題のみを確認できます

6.コンプライアンス報告

シナリオ:すべてのセキュリティ検出結果を自動的にコンプライアンスシステムにログ登録します セットアップ:
  • コンプライアンスデータベースに書き込みを行うエンドポイントを作成する
  • Corgeaでは、以下のようなWebhookを作成します。
    • イベント: scan.completed
    • 全プロジェクト
    • 監査トレイル用にWebhookの配信履歴を保存
結果:コンプライアンス目的ですべてのセキュリティスキャンの完全な監査記録が作成されます

トラブルシューティング

Webhook配信履歴の閲覧

1

Webhookの履歴を開く

IntegrationsWebhooksに移動します。
最近のWebhook試行を示すWebhookの配信履歴
2

配信ログにアクセス

HistoryまたはDelivery Logをクリックします。
3

配信の詳細を確認

リクエストとレスポンスを含む詳細なWebhook配信情報
次の情報を含む、すべてのWebhook配信試行を確認できます。
  • イベントの種類とタイムスタンプ
  • HTTPステータスコード
  • リクエスト/レスポンスの詳細
  • エラーメッセージ(あれば)
  • 再試行

よくある問題と解決策

可能な原因:
  • Webhookが一時停止または非アクティブ
  • イベントサブスクリプションが設定されていません
  • プロジェクト、ステータス、スケジュールスキャンのフィルターによってイベントが除外されている
  • エンドポイントが2xxステータスコードを返さない
解決方法:
  1. Webhookの状態を確認する - アクティブ(一時停止していない)を確認
  2. イベントのサブスクリプションが選ばれているか確認する
  3. フィルターのレビュー - プロジェクト、ステータス、またはスケジュールされたスキャンフィルターを一時的に解除してテストする
  4. エンドポイントログでリクエストの受信を確認する
  5. 「テストWebhook」ボタンを使ってWebhookをテストする
原因: 10回連続の配信失敗解決方法:
  1. 配信履歴でエラーの詳細を確認する
  2. エンドポイントのURLが正しく、アクセス可能であることを確認する
  3. エンドポイントが2xxステータスコードを返すことを確認する
  4. Corgeaのリクエストをブロックするファイアウォールやセキュリティルールがないか確認
  5. 根本原因を修正した後、Webhookを手動で再有効化する
  6. 「Test Webhook」を使って動作を確認し、再有効化する
解決方法:
  1. ステータスフィルターを使用します。issue.status_changedでは、必要なステータス(例:fixedfalse_positive)のみに絞り込みます
  2. プロジェクトフィルターを使う :特定の重要なプロジェクトのみ購読
  3. スケジュールスキャンフィルター:スキャンイベントでは、Webhookをトリガーするスケジュール済みスキャンを選択します
  4. イベント購読を減らす:不要なイベントの購読を解除する
  5. レート制限の実装:エンドポイントでレート制限またはキューイングを実装します
可能な原因:
  • 誤ったシークレットキー
  • 誤った署名検証ロジック
  • 文字エンコーディングの問題
解決方法:
  1. Corgeaのシークレットキーを正確に使っていることを確認する
  2. HMAC-SHA256アルゴリズムを使用していることを確認してください
  3. 検証には生のリクエストボディ(解析されていないJSON)を使用する
  4. 送信側と受信側の両方でUTF-8エンコーディングを確認する
  5. タイミング攻撃に耐性のある比較として、hmac.compare_digest()(Python)またはcrypto.timingSafeEqual()(Node.js)を使用する
受信した署名と計算した署名の両方をログに記録して比較
原因: エンドポイントのレスポンスに10秒以上かかる解決方法:
  1. 即時に応答:直ちに200 OKを返し、その後非同期で処理する
  2. キューを使用:バックグラウンド処理のためにWebhookペイロードをキューに追加する
  3. 処理を最適化:Webhookハンドラーの処理を高速化する
  4. リソースを増強:エンドポイントのインフラをスケールアップする
ベストプラクティスパターン:
webhook-handler.py
可能な原因:
  • 同じイベントに複数のWebhookがサブスクライブ
  • 遅延成功後の再試行ロジックのトリガー
解決方法:
  1. 重複したWebhook構成の確認
  2. 冪等性を確保するためにevent_idフィールドを使用し、処理済みのイベントIDを保存して重複をスキップする
  3. エンドポイントに冪等キーを実装する
冪等性パターン:
idempotency.py
解決方法:
  1. Webhookの配信履歴でペイロード全体を確認する
  2. データが存在しない場合(例:問題に担当者が割り当てられていない場合)、一部のフィールドがnullになることがあります
  3. ハンドラコードにnullチェックを実装する
  4. イベント固有のペイロード構造をデリバリー履歴で参照する

Webhook統計の取得

Webhookのパフォーマンス指標を見る:
  1. IntegrationsWebhooksに移動します
  2. 各Webhookの統計を見る:
    • 総配信数:Webhookコールの総数
    • 成功した配信:2xx回のレスポンスを返した呼び出し
    • 配信失敗:失敗またはタイムアウトした呼び出し
    • 成功率:成功した配信の割合
    • 連続失敗:現在の失敗記録
    • 最後のトリガー:Webhookが最後に送信した時刻

手動再試行

Webhookの配信に失敗した場合は、手動で再試行できます。
  1. WebhooksIntegrationsHistory
  2. 失敗した配信を見つける
  3. Retryをクリックする
  4. 新しい配信試行が作成され、直ちに送信されます

配信履歴のエクスポート

コンプライアンス対応やデバッグのために、Webhookの配信履歴をエクスポートできます。
  1. IntegrationsWebhooksHistoryに移動する
  2. フィルター(日付範囲、イベントタイプ、ステータス、Webhook)を適用する
  3. エクスポート をクリックしてCSVをダウンロードします
  4. エクスポートを以下に利用します:
    • コンプライアンス監査
    • パフォーマンス分析
    • デバッグパターン
    • 問題解決の追跡

テストのヒント

  1. ペイロードの検査に webhook.site または リクエストビン を使用します
  2. まず低ボリュームプロジェクトでテストします
  3. 最初の数日間の配信成功率を監視する
  4. 自社システム内でWebhookの障害に対するアラートを設定する
  • WebhookのURLが正確かつアクセス可能であること
  • エンドポイントが10秒以内に2xxステータスコードを返す
  • ファイアウォールはCorgeaのリクエストを許可しています
  • イベントのサブスクリプションが選定されます
  • フィルターが正しく設定されているか(またはテストのために取り外されている)
  • 署名検証が機能します(シークレットを使用する場合)
  • Webhookがアクティブ(一時停止されていない)

ペイロードの例

issue-status-changed.json

よくある質問

はい!エンドポイントにはイベントを識別するための X-Corgea-Event ヘッダーと event_type フィールドが表示されます。
明確な制限はありませんが、目的ごとに整理することをおすすめします(例:チームやツールごとに1つ)。
Corgeaは指数関数的なバックオフで3回再試行します。10回連続で失敗すると、Webhookは自動的に一時停止します。
はい!「Test Webhook」ボタンを使って、実際のイベントを待たずにサンプルペイロードを送信できます。Slack Workflow Builderの場合、サンプルはフラットで、空でない message とトリアージキー(pull_request_idscan_urltrue_positive_countcompany)が含まれています。 company_id も従来のテストクライアント向けに(同じ値で)含まれています。
はい。Scan Event Filtersで、Only pull request / merge request scansOnly completed scans with true-positive findingsを有効にします。scan.failedscan.completedを登録してください。検出結果のフィルターはscan.failedには適用されません。
はい!CorgeaはHMAC署名検証用のシークレットキーを自動的に生成します(X-Corgea-Signature)。宛先固有の認証トークン用のカスタムヘッダーも追加できます。
直接ではありませんが、プロジェクトごとに絞り込むことができます。また、エンドポイントで受信したペイロードをフィルタリングすることもできます。
ペイロードはHTTPS(TLS)経由で送信され、転送中の暗号化を提供します。認証にはHMAC署名を使用してください。
デリバリーログはコンプライアンスやデバッグのために保持されます。プランに具体的な保持期間を確認してください。
はい!webhookの配信履歴にアクセスし、失敗した配信があれば「再試行」をクリックしてください。
ファイアウォールでホワイトリストに登録すべき現在のIPアドレスリストについてはサポートに連絡してください。

ご質問や問題がある場合 連絡 Corgeaサポート