Qu’est-ce qu’un webhook ?
Les webhooks sont des callbacks HTTP automatisés qui permettent à Corgea d’envoyer des notifications en temps réel à vos systèmes externes lorsque des événements précis se produisent. Au lieu d’interroger continuellement l’API, les données sont envoyées directement à l’endpoint configuré.Principaux avantages
- Notifications en temps réel — recevez immédiatement les mises à jour lorsqu’un problème de sécurité est détecté, qu’un statut change ou qu’un scan se termine
- Automatisation — déclenchez des workflows dans des outils externes tels que Slack, Zapier ou des applications personnalisées
- Efficacité — évitez d’interroger l’API : les données vous sont envoyées dès qu’un événement se produit
- Flexibilité — abonnez-vous uniquement aux événements qui vous intéressent et filtrez-les par projet, statut ou scan planifié
- Fiabilité — bénéficiez d’une logique de réessai intégrée et du suivi des livraisons
Types d’événements pris en charge
Corgea prend en charge les webhooks pour les événements suivants : Événements liés aux problèmes :issue.status_changed- Déclenché lorsque le statut d’un problème est mis à jour (par exemple, ouvert → corrigé)issue.assigned- Déclenché lorsqu’un problème est attribué à un membre de l’équipe
sla.violation- Déclenché lorsque la tâche SLA quotidienne trouve un ou plusieurs problèmes SAST ou SCA ayant dépassé leur échéance de remédiation ou d’escalade (configurée par SLA dans Gestion des SLA)
scan.started- Déclenché lors du début d’un scan de sécuritéscan.completed- Déclenché lorsqu’un scan se termine avec succèsscan.failed- Déclenché lorsqu’un scan rencontre une erreurscheduled_scan.daily_report- Déclenché chaque jour à la fin des scans planifiés ; récapitule les nouveaux problèmes détectés pendant toutes les exécutions des 24 dernières heures. Consultez Notifications pour le schéma de l’e-mail et du payload.
scan.started, scan.completed, scan.failed) incluent data.message, un court résumé en texte brut utilisable dans Slack, Zapier ou un autre outil de messagerie. Ils incluent également les champs de triage pull_request_id, scan_url, true_positive_count, project_name et status.Pour Slack Workflow Builder (Type = Slack + hooks.slack.com/triggers/...), Corgea aplatit uniquement scan.started, scan.completed, scan.failed et webhook.test en champs de premier niveau. Ne mappez pas l’objet imbriqué data.* dans Slack : cela provoque une erreur HTTP 400. Les autres types d’événements envoyés au même webhook Slack conservent leur enveloppe imbriquée. Voir Slack.user.login- Déclenché lorsqu’un utilisateur se connecte avec succèsuser.login_failed- Déclenché lorsqu’une tentative de connexion utilisateur échoue
Fonctionnement des webhooks
Cycle de vie d’un webhook
Événement survenu
Webhook déclenché
Filtrage appliqué
Construction du payload
Type = Slack et URL triggers/), Corgea aplatit le corps HTTP uniquement pour scan.* et webhook.test ; les autres événements restent imbriqués.Requête HTTP POST
Logique de réessai
Livraison enregistrée
Structure du payload
Par défaut, les payloads des webhooks utilisent une enveloppe imbriquée normalisée (Zapier / Autre). Les événements du cycle de vie d’un scan incluentdata.message ainsi que les champs de triage :
summary.total_issues compte tous les problèmes non supprimés, y compris les faux positifs et les problèmes de qualité du code. true_positive_count correspond au nombre issu du triage utilisé dans message et dans les filtres d’événements de scan.
true_positive_count compte les résultats de sécurité non supprimés qui ne sont pas des faux positifs, selon la même logique que l’interface du scan : les valeurs status=false_positive, hold_reason=false_positive et detected_by=code-quality sont exclues. Le suffixe facultatif (N with fixes) des messages scan.completed ne compte les correctifs que parmi ces vrais positifs, et non parmi tous les problèmes du scan.
Exemple de payload sla.violation (issu de la tâche quotidienne de gestion des SLA) :
sla.violation sous Intégrations → Webhooks, ou associez un webhook depuis le formulaire Gestion des SLA ; les webhooks existants sont automatiquement abonnés.
Exemple de payload scheduled_scan.daily_report :
scheduled_scan.daily_report utilise la même enveloppe, mais possède son propre schéma data. Consultez les exemples de payloads pour la référence complète.Fonctionnalités de sécurité
Vérification de la signature HMAC
Vérification de la signature HMAC
- Corgea génère automatiquement une clé secrète lorsque vous créez un webhook
- Chaque requête contient un en-tête
X-Corgea-Signatureavec un hash HMAC-SHA256 du payload - Vérifiez la signature avec votre clé secrète pour vous assurer que le webhook vient de Corgea
En-têtes personnalisés
En-têtes personnalisés
- Incluez les en-têtes requis par votre endpoint, par exemple les tokens d’authentification
- Configurez des en-têtes personnalisés lors de la configuration du webhook
HTTPS obligatoire
HTTPS obligatoire
- Toutes les URL de webhook doivent utiliser HTTPS (ports 443 ou 80 uniquement)
- Les URL ne doivent pas contenir d’identifiants
- Les destinations résolues vers des adresses privées, loopback, link-local, réservées ou multicast sont rejetées afin de protéger contre les SSRF
- Les opérateurs peuvent restreindre les hôtes avec le paramètre
WEBHOOK_ALLOWED_HOSTS
Logique de réessai automatique
- Tentative initiale + 2 nouvelles tentatives = 3 tentatives au total
- Backoff exponentiel : 2 secondes, puis 4 secondes entre les tentatives
- Timeout : 10 secondes par requête
- Mise en pause automatique : après 10 échecs consécutifs, le webhook est automatiquement mis en pause
En-têtes envoyés avec chaque webhook
Mise en place d’un webhook

Prérequis
Mise en place étape par étape
Accéder aux intégrations
- Ouvrez Intégrations dans Corgea
- Sous Intégrations d’automatisation, ouvrez Webhooks

Configurer les paramètres de base

- Nom : libellé explicite, par exemple « Notifications Slack » ou « Alertes de scan de production »
- URL du webhook : votre endpoint HTTPS
- Type :
Slack— destinations Slack Workflow Builder ou Incoming WebhookZapier— Catch Hooks ZapierOther— endpoints personnalisés
S’abonner aux événements

- Statut du problème modifié
- Problème attribué
- Violation de SLA (
sla.violation) - Scan démarré / terminé / en échec
- Connexion utilisateur / Échec de la connexion utilisateur
- Rapport quotidien des scans planifiés (
scheduled_scan.daily_report)
Configurer les filtres (facultatif)

scan.*)- Uniquement les scans de pull request ou de merge request — ignore les scans sans
pull_request_id - Uniquement les scans terminés comportant de vrais positifs — ignore
scan.completedlorsquetrue_positive_countvaut 0, sans affecterscan.failedniscan.started
- Laissez le filtre désactivé pour recevoir les événements de tous les projets
- Activez le filtrage pour limiter le webhook à des projets sélectionnés
- Pour
sla.violation, le webhook se déclenche si au moins un projet du payload correspond au filtre
issue.status_changed)- Laissez vide pour tous les changements de statut
- Vous pouvez aussi limiter le filtre à des statuts tels que
fixedoufalse_positive
scan.*)- Laissez ce filtre désactivé pour recevoir tous les scans, manuels et planifiés
- Activez-le pour ne déclencher le webhook que pour certains scans planifiés
Ajouter des en-têtes et un corps personnalisés (facultatif)
Jira Automation
Jira Automation
- Dans Jira, créez une règle d’automatisation avec un déclencheur « Incoming webhook »
- Copiez le token secret fourni par Jira
- Ajoutez-le comme valeur d’en-tête dans Corgea
Slack
Slack
https://hooks.slack.com/triggers/...). Avec Type = Slack, Corgea aplatit scan.* et webhook.test : mappez message, pull_request_id, scan_url, true_positive_count et company. Ne mappez pas les champs imbriqués data.*, car Slack renvoie alors une erreur HTTP 400. Les autres types d’événements ne sont pas aplatis. Consultez Slack.Les Incoming Webhooks (https://hooks.slack.com/services/...) nécessitent un corps personnalisé dont le JSON rendu contient un champ text non vide de premier niveau. Utilisez {"text": "{{message}}"} uniquement avec les événements du cycle de vie des scans et scheduled_scan.daily_report.Microsoft Teams
Microsoft Teams
https://xxx.webhook.office.com/webhookb2/xxx/IncomingWebhook/xxx.API personnalisée avec token Bearer
API personnalisée avec token Bearer
Splunk HEC
Splunk HEC
API personnalisée avec clé d’API
API personnalisée avec clé d’API
PagerDuty
PagerDuty
routing_key du payload JSON pour l’authentification.Utilisez l’endpoint de l’API PagerDuty Events : https://events.pagerduty.com/v2/enqueuerouting_key dans le corps de la requête.Zapier
Zapier
- Vous pouvez fournir un modèle d’objet JSON pour le corps de la requête webhook
- Laissez ce champ vide pour utiliser la structure de payload par défaut de Corgea
- Variables de substitution prises en charge :
{{payload}}(payload complet par défaut){{time}}(secondes Unix){{timestamp}}(horodatage ISO 8601){{event_type}}{{event_id}}{{message}}(valeur dedata.messagelorsqu’elle existe, pour le cycle de vie des scans et le rapport quotidien)
- Si le modèle produit un JSON non valide, la livraison échoue et l’erreur apparaît dans l’historique du webhook
Sauvegarder et activer
- Cliquez sur Create Webhook
- Copiez la clé secrète depuis la fenêtre — Corgea ne l’affiche qu’une seule fois

- Cliquez sur I’ve saved the Secret Key
- Le webhook est actif et commence à recevoir des événements
Tester le webhook
- Ouvrez le webhook et cliquez sur Test Webhook
- Confirmez que votre endpoint renvoie une réponse 2xx
- Pour Slack Workflow Builder, le corps est plat et contient un champ
messagenon vide de premier niveau, ainsi que des exemples de clés de triage (pull_request_id,scan_url,true_positive_count, etc.) afin de mapper les variables pendant le test. Les configurations Workflow Builder qui utilisent uniquement des champs imbriqués ne sont pas prises en charge.
Vérification des signatures de webhooks
X-Corgea-Signature de chaque requête.- Python
- Node.js
Cas d’utilisation
1. Notifications Slack en temps réel
Scénario : prévenez votre équipe de sécurité dans Slack lorsque des problèmes de sévérité élevée sont détectés Configuration :- Créez une URL de webhook entrant dans votre espace de travail Slack
- Dans Corgea, créez un webhook avec :
- Type :
Slack - URL : URL de votre webhook Slack
- Événements :
scan.completed - Filtre de projet : Projets de production critiques
- Type :
2. Création automatisée de tickets pour les problèmes critiques
Scénario : créez automatiquement des tickets dans Jira ou Linear lorsque des problèmes critiques sont détectés Configuration :- Créez un Zap ou un endpoint personnalisé qui génère des tickets
- Dans Corgea, créez un webhook avec :
- Événements :
scan.completed,issue.status_changed - Filtre de statut : statut
openuniquement, afin d’éviter les doublons - Filtre de projet : Projets de production
- Événements :
3. Intégration du flux de travail d’acceptation des risques
Scénario : documentez automatiquement les risques acceptés dans Jira ou Linear lorsque des problèmes de sécurité sont marqués comme « Risque accepté » Configuration :- Créez un endpoint ou une intégration Zapier qui génère des tickets de documentation
- En Corgea, créez un webhook avec :
- Événements :
issue.status_changed - Filtre de statut : statut
accepted_riskuniquement - Filtre de projet : tous les projets ou certains projets soumis à de fortes exigences de conformité
- Événements :
- Configurez l’intégration pour :
- Créer un ticket documentant l’acceptation du risque
- Inclure les détails du problème (classification, chemin du fichier, sévérité)
- Ajouter le libellé « acceptation du risque »
- Attribuer le ticket au responsable de la sécurité pour examen
4. Intégration personnalisée de tableau de bord
Scénario : affichez les métriques de sécurité en temps réel sur votre tableau de bord interne Configuration :- Créez un endpoint qui reçoit les données du webhook et met à jour votre tableau de bord
- Dans Corgea, créez un webhook avec :
- Événements : tous les événements de scan et de problème
- Pas de filtres (recevoir tout)
5. Routage multi-équipes
Scénario : acheminez les notifications de chaque projet vers l’équipe concernée Configuration :- Créez des webhooks séparés pour chaque équipe :
- Webhook de l’équipe backend : filtre de projet = projets backend, canal Slack #backend-security
- Webhook de l’équipe frontend : filtre de projet = projets frontend, canal Slack #frontend-security
- Webhook de l’équipe DevOps : filtre de projet = projets d’infrastructure, canal Slack #devops-security
6. Rapports de conformité
Scénario : consignez automatiquement tous les résultats de sécurité dans un système de conformité Configuration :- Créez un endpoint qui écrit dans votre base de données de conformité
- Dans Corgea, créez un webhook avec :
- Événements :
scan.completed - Tous les projets
- Conserver l’historique des livraisons du webhook à des fins d’audit
- Événements :
Dépannage
Consulter l’historique des livraisons du webhook
Accéder à l’historique du webhook

Ouvrir le journal des livraisons
Examiner les détails des livraisons

- Type d’événement et horodatage
- Code de statut HTTP
- Détails de la requête et de la réponse
- Messages d’erreur (s’il y en a)
- Tentatives de réessai
Problèmes et solutions courants
Webhook ne reçoit pas d’événements
Webhook ne reçoit pas d’événements
- Le webhook est en pause ou inactif
- Les abonnements aux événements ne sont pas configurés
- Les filtres de projet, de statut ou de scan planifié excluent les événements
- L’endpoint ne renvoie pas de code de statut 2xx
- Vérifiez le statut du webhook et assurez-vous qu’il est actif
- Vérifiez que les abonnements aux événements sont sélectionnés
- Supprimez temporairement les filtres de projet, de statut ou de scan planifié pour effectuer un test
- Vérifiez les requêtes entrantes dans les logs de votre endpoint
- Testez le webhook en utilisant le bouton « Test Webhook »
Webhook mis en pause automatiquement
Webhook mis en pause automatiquement
- Vérifiez l’historique des livraisons pour les détails des erreurs
- Vérifiez que l’URL de votre endpoint est correcte et accessible
- Assurez-vous que votre endpoint renvoie un code de statut 2xx
- Vérifiez la présence de règles de pare-feu ou de sécurité bloquant les requêtes de Corgea
- Corrigez le problème sous-jacent, puis réactivez manuellement le webhook
- Utilisez « Test Webhook » pour vérifier son fonctionnement avant de le réactiver
Recevoir trop d’appels Webhook
Recevoir trop d’appels Webhook
- Utiliser des filtres de statut : pour
issue.status_changed, conservez uniquement les statuts qui vous intéressent, par exemplefixedetfalse_positive - Utiliser des filtres de projet : abonnez-vous uniquement aux projets critiques concernés
- Utiliser des filtres de scan planifié : sélectionnez les scans planifiés qui doivent déclencher le webhook
- Réduire les abonnements aux événements : désabonnez-vous des événements inutiles
- Mettre en place une limitation de débit : ajoutez une limitation de débit ou une file d’attente sur votre endpoint
Échec de la vérification de la signature
Échec de la vérification de la signature
- Mauvaise clé secrète
- Logique incorrecte de vérification de signature
- Problèmes d’encodage des caractères
- Vérifiez que vous utilisez exactement la clé secrète de Corgea
- Assurez-vous d’utiliser l’algorithme HMAC-SHA256
- Utilisez le corps brut de la requête, et non le JSON parsé, pour la vérification
- Vérifiez l’encodage UTF-8 des deux côtés
- Utilisez
hmac.compare_digest()(Python) oucrypto.timingSafeEqual()(Node.js) pour effectuer une comparaison à temps constant
Timeout de l’endpoint
Timeout de l’endpoint
- Accuser réception immédiatement : renvoyez tout de suite 200 OK, puis effectuez le traitement de manière asynchrone
- Utiliser une file d’attente : placez les payloads des webhooks dans une file d’attente pour les traiter en arrière-plan
- Optimiser le traitement : accélérez la logique de votre handler de webhook
- Augmenter les ressources : adaptez les ressources de l’infrastructure de votre endpoint
Événements en double
Événements en double
- Plusieurs webhooks se sont abonnés au même événement
- Réessai déclenché après une réponse tardive pourtant réussie
- Vérifiez la présence de configurations de webhook en double
- Utilisez le champ
event_idpour garantir l’idempotence : stockez les identifiants traités et ignorez les doublons - Implémentez des clés d’idempotence dans votre endpoint
Données manquantes dans le payload
Données manquantes dans le payload
- Vérifiez le payload complet dans l’historique de livraison du webhook
- Certains champs peuvent valoir
nullsi les données n’existent pas, par exemple pour les problèmes non attribués - Gérez les valeurs nulles dans le code de votre handler
- Consultez dans l’historique de livraison la structure du payload propre à chaque événement
Consulter les statistiques des webhooks
Consultez les métriques de performance de vos webhooks :- Accédez à Intégrations → Webhooks
- Consultez les statistiques de chaque webhook :
- Total des livraisons : nombre total d’appels du webhook
- Livraisons réussies : appels ayant obtenu une réponse 2xx
- Livraisons en échec : appels ayant échoué ou expiré
- Taux de réussite : pourcentage de livraisons réussies
- Échecs consécutifs : nombre actuel d’échecs successifs
- Dernier déclenchement : date du dernier déclenchement du webhook
Réessai manuel
Si une livraison webhook a échoué, vous pouvez la réessayer manuellement :- Accédez à Intégrations → Webhooks → History
- Repérez la livraison en échec
- Cliquez sur Retry
- Une nouvelle tentative de livraison est créée et envoyée immédiatement
Exporter l’historique des livraisons
Pour la conformité ou le débogage, exportez l’historique de livraison du webhook :- Accédez à Intégrations → Webhooks → History
- Appliquez les filtres voulus (plage de dates, type d’événement, statut, webhook)
- Cliquez sur Export pour télécharger le fichier CSV
- Utilisez l’export pour :
- Audits de conformité
- Analyse des performances
- Analyse des schémas d’erreur
- Suivi de la résolution des problèmes
Conseils pour les tests
Avant la mise en production
Avant la mise en production
- Utilisez webhook.site ou RequestBin pour inspecter les payloads
- Commencez les tests avec des projets à faible volume
- Surveillez le taux de réussite des livraisons pendant les premiers jours
- Configurez des alertes pour les défaillances de webhook dans votre propre système
Liste de contrôle du débogage
Liste de contrôle du débogage
- L’URL du webhook est correcte et accessible
- L’endpoint renvoie un code d’état 2xx dans les 10 secondes
- Le pare-feu autorise les requêtes de Corgea
- Les abonnements aux événements sont sélectionnés
- Les filtres sont correctement configurés (ou retirés pour les tests)
- La vérification de signature fonctionne, si vous utilisez une clé secrète
- Le webhook est actif et n’est pas en pause
Exemples de payloads
- Statut du problème modifié
- Scan lancé
- Scan terminé
- Scan échoué
- Issue attribuée
- SLA Violation
- Connexion utilisateur
- Échec de la connexion utilisateur
- Rapport quotidien de scan planifié
FAQ
Puis-je utiliser la même URL de webhook pour plusieurs types d’événements ?
Puis-je utiliser la même URL de webhook pour plusieurs types d’événements ?
X-Corgea-Event et un champ event_type permettant d’identifier l’événement.Combien de webhooks puis-je créer ?
Combien de webhooks puis-je créer ?
Que se passe-t-il si mon endpoint est hors service ?
Que se passe-t-il si mon endpoint est hors service ?
Puis-je tester des webhooks sans déclencher de réels événements ?
Puis-je tester des webhooks sans déclencher de réels événements ?
message non vide ainsi que les clés de triage pull_request_id, scan_url, true_positive_count et company. company_id est également inclus avec la même valeur pour assurer la compatibilité avec les anciens consommateurs des événements de test.Puis-je limiter les notifications aux échecs de scans de pull request et aux scans terminés comportant des résultats ?
Puis-je limiter les notifications aux échecs de scans de pull request et aux scans terminés comportant des résultats ?
scan.failed et scan.completed. Le filtre des résultats ne s’applique pas à scan.failed.Les webhooks prennent-ils en charge l’authentification ?
Les webhooks prennent-ils en charge l’authentification ?
X-Corgea-Signature). Vous pouvez aussi ajouter des en-têtes personnalisés pour les tokens d’authentification propres à la destination.Puis-je filtrer les webhooks selon des branches spécifiques ?
Puis-je filtrer les webhooks selon des branches spécifiques ?
Les payloads des webhooks sont-ils chiffrés ?
Les payloads des webhooks sont-ils chiffrés ?
Combien de temps les journaux de livraison de webhook sont-ils conservés ?
Combien de temps les journaux de livraison de webhook sont-ils conservés ?
Puis-je réessayer un webhook manuellement ?
Puis-je réessayer un webhook manuellement ?
À partir de quelles adresses IP Corgea envoie-t-il les webhooks ?
À partir de quelles adresses IP Corgea envoie-t-il les webhooks ?
Une question ou un problème ? Contactez le support Corgea.
