Was sind Webhooks?
Webhooks sind automatisierte HTTP-Callbacks. Damit sendet Corgea beim Eintreten bestimmter Events Benachrichtigungen in Echtzeit an externe Systeme. Statt die API kontinuierlich auf Änderungen abzufragen, erhalten Sie die Event-Daten unmittelbar an Ihrem konfigurierten Endpunkt.Zentrale Vorteile
- Echtzeit-Benachrichtigungen – Sofort über neue Security-Issues, Statusänderungen und abgeschlossene Scans informiert werden
- Automatisierung – Workflows in externen Tools wie Slack, Zapier oder eigenen Anwendungen auslösen
- Effizienz – Änderungen ohne wiederholte API-Abfragen direkt empfangen
- Flexibilität – Nur relevante Events abonnieren und nach Projekt, Status oder Scheduled Scan filtern
- Zuverlässigkeit – Integrierte Wiederholungslogik und Zustellungsverfolgung
Unterstützte Event-Typen
Corgea unterstützt Webhooks für die folgenden Events: Issue Events:issue.status_changed– Wird bei einer Änderung des Issue-Status ausgelöst, beispielsweiseopen→fixed.issue.assigned– Wird ausgelöst, wenn ein Issue einem Teammitglied zugewiesen wird.
sla.violation– Wird ausgelöst, wenn der tägliche SLA-Job mindestens ein SAST- oder SCA-Issue mit überschrittener Behebungs- oder Eskalationsfrist erkennt. Die Fristen werden je SLA unter SLA Management konfiguriert.
scan.started– Wird beim Start eines Security-Scans ausgelöst.scan.completed– Wird nach erfolgreichem Abschluss eines Scans ausgelöst.scan.failed– Wird ausgelöst, wenn bei einem Scan ein Fehler auftritt.scheduled_scan.daily_report– Wird täglich nach Abschluss der Scheduled-Scan-Läufe ausgelöst und fasst alle neuen Issues aus den vergangenen 24 Stunden zusammen. Das E-Mail- und Payload-Schema ist unter Benachrichtigungen beschrieben.
scan.started, scan.completed, scan.failed) enthalten in data.message eine kurze Klartextzusammenfassung für Slack, Zapier oder andere Chat-Tools. Außerdem enthalten sie die Triage-Felder pull_request_id, scan_url, true_positive_count, project_name und status.Für den Slack Workflow Builder (Type = Slack und hooks.slack.com/triggers/...) überträgt Corgea nur scan.started, scan.completed, scan.failed und webhook.test als Top-Level-Schlüssel. Ordnen Sie in Slack keine verschachtelten data.*-Felder zu, da dies HTTP 400 verursacht. Andere Event-Typen desselben Slack-Webhooks behalten die verschachtelte Struktur bei. Weitere Informationen finden Sie unter Slack.user.login– Wird bei einer erfolgreichen Benutzeranmeldung ausgelöst.user.login_failed– Wird bei einem fehlgeschlagenen Anmeldeversuch ausgelöst.
Wie Webhooks funktionieren
Webhook-Lifecycle
Event tritt ein
Webhook wird ausgelöst
Filter werden angewendet
Payload erstellt
Type = Slack und triggers/-URL) überträgt Corgea den HTTP-Body nur bei scan.* und webhook.test als flache Struktur; andere Events bleiben verschachtelt.HTTP-POST-Request
Wiederholungslogik
Zustellung wird protokolliert
Payload-Struktur
Webhook-Payloads verwenden standardmäßig eine einheitliche verschachtelte Struktur für Zapier und andere Ziele. Scan-Lifecycle-Events enthaltendata.message und zusätzliche Triage-Felder:
summary.total_issues zählt alle nicht gelöschten Issues einschließlich False Positives und Code-Quality-Issues. true_positive_count ist die für message und Scan-Event-Filter verwendete Triage-Anzahl.
true_positive_count zählt nicht gelöschte Security-Findings, die keine False Positives sind. Dies entspricht der Logik der Scan-Benutzeroberfläche und schließt status=false_positive, hold_reason=false_positive sowie detected_by=code-quality aus. Das optionale Suffix (N with fixes) in scan.completed-Meldungen zählt nur Fixes für diese True-Positive-Findings, nicht für sämtliche Issues des Scans.
Beispiel-Payload für sla.violation (aus dem täglichen SLA-Management-Job):
sla.violation unter Integrations → Webhooks oder verknüpfen Sie einen Webhook im Formular unter SLA Management. Vorhandene Webhooks werden automatisch für das Event registriert.
Beispiel-Payload für scheduled_scan.daily_report:
scheduled_scan.daily_report verwendet dieselbe äußere Struktur, aber ein eigenes data-Schema. Die vollständige Referenz finden Sie unter Payload-Beispiele.Sicherheitsfunktionen
HMAC-Signaturprüfung
HMAC-Signaturprüfung
- Corgea generiert beim Erstellen eines Webhooks automatisch einen Secret Key.
- Jede Anfrage enthält einen
X-Corgea-Signature-Header mit einem HMAC-SHA256-Hash der Payload - Verifizieren Sie die Signatur mit dem Secret Key, um die Herkunft des Webhooks von Corgea zu bestätigen.
Benutzerdefinierte Header
Benutzerdefinierte Header
- Fügen Sie die von Ihrem Endpunkt erforderlichen Header ein (z. B. Authentifizierungstoken)
- Konfigurieren Sie benutzerdefinierte Header während der Einrichtung des Webhooks
HTTPS erforderlich
HTTPS erforderlich
- Alle Webhook-URLs müssen HTTPS verwenden (nur Ports 443 oder 80)
- URLs dürfen keine Anmeldeinformationen enthalten
- Ziele, die auf private, Loopback-, Link-Local-, reservierte oder Multicast-Adressen auflösen, werden abgelehnt (SSRF-Schutz)
- Operatoren können Hosts optional mit der
WEBHOOK_ALLOWED_HOSTS-Einstellung einschränken
Automatische Wiederholungslogik
- Erster Versuch + 2 Wiederholungen = insgesamt 3 Versuche
- Exponentieller Backoff: 2 Sekunden und 4 Sekunden zwischen den Wiederholungsversuchen
- Timeout: 10 Sekunden pro Request
- Automatische Pause: Nach 10 aufeinanderfolgenden Fehlschlägen wird der Webhook automatisch pausiert
Mit jedem Webhook gesendete Header
Webhook einrichten

Voraussetzungen
Schritt-für-Schritt-Einrichtung
Integrations öffnen
- Öffnen Sie Integrations in Corgea.
- Öffnen Sie unter Automation Integrations den Eintrag Webhooks.

Grundlegende Einstellungen konfigurieren

- Name: Eine eindeutige Bezeichnung, beispielsweise „Slack Notifications“ oder „Production Scan Alerts“
- Webhook-URL: Ihr HTTPS-Endpunkt
- Type:
Slack— Slack Workflow Builder oder Incoming-WebhooksZapier— Zapier Catch HooksOther— benutzerdefinierte Endpunkte
Events abonnieren

- Issue Status Changed
- Issue Assigned
- SLA Violation (
sla.violation) - Scan Started / Completed / Failed
- User Login / User Login Failed
- Scheduled Scan Daily Report (
scheduled_scan.daily_report)
Filter konfigurieren (optional)

scan.*-Events)- Only pull request / merge request scans – Scans ohne
pull_request_idüberspringen - Only completed scans with true-positive findings –
scan.completedüberspringen, wenntrue_positive_countden Wert 0 hat;scan.failedundscan.startedsind nicht betroffen
- Deaktiviert lassen, um Events aus allen Projekten zu erhalten
- Filterung aktivieren, um den Webhook auf ausgewählte Projekte zu beschränken
- Bei
sla.violationwird der Webhook ausgelöst, wenn mindestens ein Projekt im Payload übereinstimmt
issue.status_changed)- Leer lassen für alle Statusänderungen
- Oder auf Status wie
fixedoderfalse_positivebeschränken
scan.*-Events)- Deaktiviert lassen, um alle Scans (manuell und geplant) zu erhalten
- Aktivieren, damit der Webhook nur für ausgewählte Scheduled Scans ausgelöst wird
Custom Header und Body hinzufügen (optional)
JIRA Automation
JIRA Automation
- Erstellen Sie in JIRA eine Automatisierungsregel mit dem Trigger Incoming webhook.
- Kopieren Sie das von JIRA bereitgestellte Secret Token.
- Tragen Sie es in Corgea als Header-Wert ein.
Slack
Slack
https://hooks.slack.com/triggers/...). Mit Type = Slack überträgt Corgea scan.* und webhook.test als flache Struktur. Ordnen Sie message, pull_request_id, scan_url, true_positive_count und company zu. Verschachtelte data.*-Felder dürfen nicht zugeordnet werden, da Slack HTTP 400 zurückgibt. Andere Event-Typen werden nicht abgeflacht. Weitere Informationen finden Sie unter Slack.Incoming-Webhooks (https://hooks.slack.com/services/...) benötigen einen Custom Body, dessen gerendertes JSON auf oberster Ebene das nicht leere String-Feld text enthält. Verwenden Sie {"text": "{{message}}"} nur für Scan-Lifecycle-Events und scheduled_scan.daily_report.Microsoft Teams
Microsoft Teams
https://xxx.webhook.office.com/webhookb2/xxx/IncomingWebhook/xxxBenutzerdefinierte API mit Bearer-Token
Benutzerdefinierte API mit Bearer-Token
Splunk HEC
Splunk HEC
Benutzerdefinierte API mit API-Key
Benutzerdefinierte API mit API-Key
PagerDuty
PagerDuty
routing_key im JSON-Payload zur Authentifizierung.Verwenden Sie den PagerDuty Events API-Endpunkt: https://events.pagerduty.com/v2/enqueuerouting_key im Request-Body.Zapier
Zapier
- Optional ein JSON-Objekt-Template für den Webhook-Request-Body angeben
- Lassen Sie es leer, um die Standard-Payload-Struktur von Corgea zu verwenden
- Unterstützte Platzhalter:
{{payload}}(vollständiges Standard-Payload-Objekt){{time}}(Unix-Sekunden){{timestamp}}(ISO-8601-Zeitstempel){{event_type}}{{event_id}}{{message}}(ausdata.message, sofern vorhanden – Scan-Lifecycle und täglicher Bericht)
- Ist das gerenderte Template kein gültiges JSON, schlägt die Zustellung fehl und der Fehler erscheint im Webhook-Verlauf.
Speichern und Aktivieren
- Klicken Sie auf Create Webhook.
- Kopieren Sie den Secret Key aus dem Popup. Corgea zeigt ihn nur einmal an.

- Klicken Sie auf I’ve saved the Secret Key.
- Der Webhook ist jetzt aktiv und empfängt Events.
Webhook testen
- Öffnen Sie den Webhook und klicken Sie auf Test Webhook.
- Prüfen Sie, ob Ihr Endpunkt eine 2xx-Response zurückgibt.
- Beim Slack Workflow Builder wird ein flacher Body mit dem nicht leeren Top-Level-Feld
messageund beispielhaften Triage-Schlüsseln wiepull_request_id,scan_urlundtrue_positive_countgesendet. Dadurch können Sie die Variablen beim Test zuordnen. Konfigurationen, die ausschließlich verschachtelte Felder verwenden, werden nicht unterstützt.
Webhook-Signaturen verifizieren
X-Corgea-Signature-Header jedes Requests mit dem bei der Erstellung angezeigten Secret Key.- Python
- Node.js
Anwendungsfälle
1. Echtzeit-Slack-Benachrichtigungen
Szenario: Das Security-Team bei neuen Issues mit hohem Schweregrad über Slack benachrichtigen Einrichtung:- Erstellen Sie in Ihrem Slack-Workspace eine Incoming-Webhook-URL.
- In Corgea erstellen Sie einen Webhook mit:
- Type:
Slack - URL: Ihre Slack-Webhooks-URL
- Events:
scan.completed - Project Filter: Kritische Produktionsprojekte
- Type:
2. Automatisches Ticketing für kritische Issues
Szenario: Bei kritischen Issues automatisch Tickets in JIRA oder Linear erstellen Einrichtung:- Erstellen Sie einen Zapier-Zap oder einen benutzerdefinierten Endpunkt, der Tickets erstellt
- In Corgea erstellen Sie einen Webhook mit:
- Events:
scan.completed,issue.status_changed - Status Filter: Nur Status
open, um doppelte Tickets zu vermeiden - Project Filter: Produktionsprojekte
- Events:
3. Integration eines Workflows zur Risikoakzeptanz
Szenario: Akzeptierte Risiken automatisch in JIRA oder Linear dokumentieren, sobald Security-Issues als Accepted Risk markiert werden Einrichtung:- Erstellen Sie einen Endpunkt oder eine Zapier-Integration, die Dokumentationstickets erstellt
- In Corgea erstellen Sie einen Webhook mit:
- Events:
issue.status_changed - Status Filter: Nur Status
accepted_risk - Project Filter: Alle Projekte oder ausgewählte Projekte mit hohen Compliance-Anforderungen
- Events:
- Konfigurieren Sie die Integration, um:
- Ein Ticket zur Dokumentation der Risikoakzeptanz zu erstellen
- Issue-Details wie Klassifizierung, Dateipfad und Dringlichkeit einzubeziehen
- das Label
risk-acceptancezu setzen - das Ticket dem Security Lead zur Prüfung zuzuweisen
4. Integration benutzerdefinierter Dashboards
Szenario: Security-Metriken in Echtzeit auf einem internen Dashboard darstellen Einrichtung:- Erstellen Sie einen Endpunkt, der Webhook-Daten empfängt und Ihr Dashboard aktualisiert
- In Corgea erstellen Sie einen Webhook mit:
- Events: Alle Scan und Issue Events
- Keine Filter (alles empfangen)
5. Routing an mehrere Teams
Szenario: Verschiedene Projektbenachrichtigungen an verschiedene Teams weiterleiten Einrichtung:- Erstellen Sie separate Webhooks für jedes Team:
- Backend-Team-Webhook: Projektfilter = Backend-Projekte, Slack-Kanal #backend-security
- Frontend-Team-Webhook: Projektfilter = Frontend-Projekte, Slack-Kanal #frontend-security
- DevOps-Team-Webhook: Projektfilter = Infrastrukturprojekte, Slack-Kanal #devops-security
6. Compliance-Reporting
Szenario: Alle Security-Findings automatisch in einem Compliance-System protokollieren Einrichtung:- Erstellen Sie einen Endpunkt, der in Ihre Compliance-Datenbank schreibt
- In Corgea erstellen Sie einen Webhook mit:
- Events:
scan.completed - Alle Projekte
- Zustellungsverlauf des Webhooks für den Audit-Trail speichern
- Events:
Fehlerbehebung
Webhook-Zustellungshistorie anzeigen
Webhook-Verlauf öffnen

Zustellungsprotokoll öffnen
Zustellungsdetails prüfen

- Ereignistyp und Zeitstempel
- HTTP-Statuscode
- Request- und Response-Details
- Fehlermeldungen (falls vorhanden)
- Wiederholungsversuche
Häufige Probleme und Lösungen
Webhook erhält keine Ereignisse
Webhook erhält keine Ereignisse
- Webhook ist pausiert oder inaktiv.
- Event-Abonnements sind nicht konfiguriert.
- Projekt-, Status- oder Scheduled-Scan-Filter schließen Events aus.
- Endpunkt gibt keinen 2xx-Statuscode zurück.
- Prüfen Sie, ob der Webhook aktiv und nicht pausiert ist.
- Prüfen Sie, ob Event-Abonnements ausgewählt sind.
- Entfernen Sie Projekt-, Status- oder Scheduled-Scan-Filter vorübergehend zum Testen.
- Prüfen Sie die Logs des Endpunkts auf eingehende Requests.
- Testen Sie den Webhook über Test Webhook.
Webhook automatisch pausiert
Webhook automatisch pausiert
- Prüfen Sie den Zustellungsverlauf auf Fehlerdetails.
- Prüfen Sie, ob die Endpunkt-URL korrekt und erreichbar ist.
- Stellen Sie sicher, dass der Endpunkt 2xx-Statuscodes zurückgibt.
- Prüfen Sie, ob Firewall- oder Security-Regeln Requests von Corgea blockieren.
- Beheben Sie die Ursache und reaktivieren Sie den Webhook manuell.
- Prüfen Sie die Funktion vor dem erneuten Aktivieren über Test Webhook.
Zu viele Webhook-Aufrufe
Zu viele Webhook-Aufrufe
- Statusfilter verwenden: Bei
issue.status_changednur relevante Status wiefixedundfalse_positiveauswählen - Projektfilter verwenden: Nur ausgewählte kritische Projekte abonnieren
- Scheduled-Scan-Filter verwenden: Für Scan-Events nur die Scheduled Scans auswählen, die den Webhook auslösen sollen
- Event-Abonnements reduzieren: Nicht benötigte Events abbestellen
- Rate Limiting implementieren: Am Endpunkt Rate Limiting oder eine Queue implementieren
Signaturprüfung schlägt fehl
Signaturprüfung schlägt fehl
- Falscher Secret Key
- Falsche Logik zur Signaturüberprüfung
- Probleme mit der Zeichencodierung
- Verwenden Sie exakt den von Corgea bereitgestellten Secret Key.
- Verwenden Sie den HMAC-SHA256-Algorithmus.
- Verifizieren Sie den unverarbeiteten Request-Body, nicht das geparste JSON.
- Prüfen Sie auf beiden Seiten die UTF-8-Codierung.
- Verwenden Sie
hmac.compare_digest()(Python) odercrypto.timingSafeEqual()(Node.js) für einen Timing-Attack-sicheren Vergleich.
Timeout am Endpunkt
Timeout am Endpunkt
- Sofort bestätigen: Unmittelbar
200 OKzurückgeben und anschließend asynchron verarbeiten - Queue verwenden: Webhook-Payloads zur Verarbeitung im Hintergrund in eine Queue einreihen
- Verarbeitung optimieren: Logik des Webhook-Handlers beschleunigen
- Ressourcen erhöhen: Infrastruktur des Endpunkts skalieren
Doppelte Ereignisse
Doppelte Ereignisse
- Mehrere Webhooks abonnieren dasselbe Ereignis
- Retry-Logik wird nach verzögertem Erfolg ausgelöst
- Prüfen Sie, ob Webhooks doppelt konfiguriert wurden.
- Verwenden Sie das Feld
event_idfür Idempotenz: Speichern Sie IDs bereits verarbeiteter Events und überspringen Sie Duplikate. - Implementieren Sie Idempotency Keys am Endpunkt.
Fehlende Daten im Payload
Fehlende Daten im Payload
- Prüfen Sie den vollständigen Payload im Zustellungsverlauf.
- Einige Felder können
nullsein, wenn keine Daten vorliegen, beispielsweise bei nicht zugewiesenen Issues. - Implementieren Sie Null-Prüfungen im Handler-Code.
- Prüfen Sie im Zustellungsverlauf die Payload-Struktur des jeweiligen Events.
Webhook-Statistiken abrufen
So rufen Sie Performance-Metriken für Ihre Webhooks auf:- Öffnen Sie Integrations → Webhooks.
- Prüfen Sie die Statistiken des jeweiligen Webhooks:
- Total Deliveries: Gesamtzahl der Webhook-Aufrufe
- Successful Deliveries: Aufrufe mit 2xx-Response
- Failed Deliveries: Fehlgeschlagene Aufrufe und Timeouts
- Success Rate: Anteil erfolgreicher Zustellungen
- Consecutive Failures: Aktuelle Anzahl aufeinanderfolgender Fehler
- Last Triggered: Zeitpunkt der letzten Auslösung
Manuelle Wiederholung
Fehlgeschlagene Webhook-Zustellungen können Sie manuell wiederholen:- Öffnen Sie Integrations → Webhooks → History.
- Suchen Sie die fehlgeschlagene Zustellung.
- Klicken Sie auf Retry.
- Corgea erstellt und sendet sofort einen neuen Zustellungsversuch.
Zustellungsverlauf exportieren
So exportieren Sie den Webhook-Zustellungsverlauf für Compliance- oder Debugging-Zwecke:- Öffnen Sie Integrations → Webhooks → History.
- Wenden Sie Filter für Datumsbereich, Event-Typ, Status oder Webhook an.
- Klicken Sie auf Export, um die CSV-Datei herunterzuladen.
- Verwenden Sie den Export für:
- Compliance-Audits
- Performance-Analysen
- Analyse von Fehlermustern
- Nachverfolgung der Issue-Behebung
Tipps zum Testen
Vor dem Produktivbetrieb
Vor dem Produktivbetrieb
- Verwenden Sie webhook.site oder RequestBin, um Payloads zu prüfen.
- Testen Sie zunächst mit Projekten mit geringem Volumen.
- Überwachen Sie in den ersten Tagen die Erfolgsquote der Zustellungen.
- Richten Sie im eigenen System Alerts für Webhook-Fehler ein.
Debug-Checkliste
Debug-Checkliste
- Webhook-URL ist korrekt und zugänglich
- Endpunkt gibt innerhalb von 10 Sekunden einen 2xx-Statuscode zurück
- Firewall erlaubt die Anfragen von Corgea
- Ereignisabonnements sind ausgewählt
- Filter sind korrekt konfiguriert (oder für Tests entfernt)
- Signaturprüfung funktioniert, sofern ein Secret verwendet wird
- Webhook ist aktiv (nicht pausiert)
Beispiel-Payloads
- Status des Problems geändert
- Scan gestartet
- Scan abgeschlossen
- Scan fehlgeschlagen
- Issue zugewiesen
- SLA-Verstoß
- Benutzeranmeldung
- Benutzeranmeldung fehlgeschlagen
- Täglicher Scheduled-Scan-Bericht
FAQ
Kann ich dieselbe Webhook-URL für mehrere Ereignistypen verwenden?
Kann ich dieselbe Webhook-URL für mehrere Ereignistypen verwenden?
X-Corgea-Event und das Feld event_type, anhand derer er das Event identifizieren kann.Wie viele Webhooks kann ich erstellen?
Wie viele Webhooks kann ich erstellen?
Was passiert, wenn mein Endpunkt ausfällt?
Was passiert, wenn mein Endpunkt ausfällt?
Kann ich Webhooks testen, ohne echte Ereignisse auszulösen?
Kann ich Webhooks testen, ohne echte Ereignisse auszulösen?
message sowie die Triage-Schlüssel pull_request_id, scan_url, true_positive_count und company. Für ältere Test-Consumer enthält er außerdem company_id mit demselben Wert.Kann ich nur bei PR-Scan-Fehlern / abgeschlossenen PR-Scans mit Befunden benachrichtigt werden?
Kann ich nur bei PR-Scan-Fehlern / abgeschlossenen PR-Scans mit Befunden benachrichtigt werden?
scan.failed und scan.completed. Der Findings-Filter gilt nicht für scan.failed.Unterstützen Webhooks Authentifizierung?
Unterstützen Webhooks Authentifizierung?
X-Corgea-Signature. Sie können außerdem Custom Header für zielspezifische Authentifizierungs-Tokens hinzufügen.Kann ich Webhooks auf bestimmte Branches filtern?
Kann ich Webhooks auf bestimmte Branches filtern?
Sind Webhook-Payloads verschlüsselt?
Sind Webhook-Payloads verschlüsselt?
Wie lange werden Webhook-Zustellungsprotokolle aufbewahrt?
Wie lange werden Webhook-Zustellungsprotokolle aufbewahrt?
Kann ich einen Webhook manuell erneut auslösen?
Kann ich einen Webhook manuell erneut auslösen?
Von welchen IP-Adressen sendet Corgea Webhooks?
Von welchen IP-Adressen sendet Corgea Webhooks?
Fragen oder Probleme? Kontaktieren Sie Corgea Support
