Skip to main content
La gestion des SLA permet de définir des délais de remédiation et d’escalade par niveau d’urgence pour les résultats SAST (code) et SCA (dépendances). En cas de dépassement, Corgea peut avertir votre équipe par e-mail et/ou par webhook (événements sla.violation).

Public concerné

Les chefs de projet, les équipes de sécurité et les développeurs qui ont besoin de délais de traitement prévisibles pour les problèmes ouverts.

Principales fonctionnalités

  • SLA distincts pour les vulnérabilités du code (SAST) et les vulnérabilités des dépendances (SCA)
  • Délais de remédiation et d’escalade configurables par niveau d’urgence (critique, élevé, moyen ou faible)
  • Synthèses par e-mail en cas de dépassement (les destinataires dépendent du type de problème et du délai concerné)
  • Notifications par webhook Corgea (événement sla.violation) : utilisez un webhook d’intégration existant ou créez-en un depuis le formulaire du SLA
  • Vérifications automatisées quotidiennes pour les délais dépassés (overdue / escalated)
  • État de violation du SLA sur les problèmes et dans le rapport Ancienneté des problèmes, pour les résultats de code et de dépendances

Accès

Accédez à Politiques → Gestion des SLA. Cette fonctionnalité nécessite le forfait approprié et les autorisations Issue SLA.

Instructions de configuration

1

Ouvrir la gestion des SLA

Accédez à Politiques, puis ouvrez Gestion des SLA.
2

Créer un SLA de problème

Cliquez sur Créer un SLA de problème.
3

Choisir le type de problème

Sélectionnez Vulnérabilité du code (SAST) ou Vulnérabilité des dépendances (SCA). Chaque SLA s’applique uniquement au type choisi.
4

Définir l’urgence et les délais

Choisissez les niveaux d’urgence, puis définissez les délais de Remédiation et d’Escalade en jours.
5

Configurer les notifications

  • E-mail — facultatif ; envoie une synthèse quotidienne aux destinataires appropriés en cas de dépassement d’un délai (voir ci-dessous).
  • Webhook — facultatif ; choisissez un webhook existant dans la liste ou saisissez une nouvelle URL HTTPS, ce qui crée un webhook abonné à sla.violation. Voir Webhooks.
6

Enregistrer

Cliquez sur Enregistrer le SLA.

Fonctionnement des notifications

Corgea vérifie les problèmes ouverts une fois par jour. Les alertes sont envoyées uniquement après le dépassement d’un délai, et non pendant la période couverte par le SLA.

Notifications par e-mail

Activez E-mail lors de la création ou de la modification d’un SLA. Chaque destinataire reçoit une synthèse quotidienne des problèmes en retard par projet et par sévérité, et non un e-mail par problème. Il existe deux types de délais :
  • Remédiation — première alerte indiquant qu’un problème est en retard et doit être traité.
  • Escalade — une alerte ultérieure, généralement destinée aux chefs de projet lorsque le problème reste ouvert.
Qui reçoit l’e-mail ? Les destinataires dépendent du type de problème et du délai dépassé : Vulnérabilités de code (SAST) Vulnérabilités de dépendance (SCA) Affectez les problèmes de dépendances depuis leur page de détail, avec la liste Responsable, comme pour les problèmes de code.
Ajoutez des propriétaires du projet dans les Paramètres du projet afin que les e-mails de SLA parviennent à la bonne équipe. Sans propriétaire, les administrateurs de l’entreprise reçoivent les notifications.

Notifications par webhook

Lorsqu’un SLA comporte un webhook, Corgea lui envoie un événement sla.violation avec un payload JSON structuré (voir Webhooks). Vous pouvez :
  • sélectionner un webhook existant ; Corgea l’abonne automatiquement à sla.violation si nécessaire ;
  • saisir une nouvelle URL pour créer un webhook réservé aux alertes de SLA ; HTTPS est obligatoire.
Les webhooks utilisent le même pipeline d’envoi que les autres webhooks Corgea : nouvelles tentatives, signature et historique. Pour sla.violation, un filtre de projet correspond si au moins un projet du payload figure dans le filtre, ce qui est utile lorsqu’une notification couvre plusieurs projets.
Les SLA créés avant cette version peuvent encore proposer Slack comme mode de notification. Les SLA nouveaux ou modifiés utilisent désormais un webhook. Ajoutez un webhook entrant Slack sous Intégrations → Webhooks, puis sélectionnez-le dans le formulaire du SLA.

Modifier et gérer les SLA

  • Cliquez sur Modifier pour un SLA existant. Le formulaire préremplit le type de problème, l’urgence, les délais, la case E-mail et le webhook sélectionné, le cas échéant.
  • Le tableau des SLA affiche le Type (SAST ou SCA), les délais et les modes de notification configurés.

Reporting et état des problèmes

  • Reporting → Aging inclut les problèmes de code et de dépendances en retard : synthèse, répartition par urgence, projets, écosystèmes et tendances.
  • Les problèmes de code et de dépendances affichent leur état de SLA et, lorsqu’ils sont affectés, figurent dans la répartition par responsable du rapport d’ancienneté.
  • Dans les vues des dépendances d’un scan, filtrez les problèmes par état de SLA lorsqu’un SLA SCA s’applique.

Exemples

SLA pour les résultats critiques du code

1

Créer le SLA

Créez un SLA de type Vulnérabilité du code (SAST) avec l’urgence Critique.
2

Définir les délais

Fixez la remédiation à 2 jours et l’escalade à 3 jours.
3

Configurer les notifications

Activez E-mail et sélectionnez un webhook Slack ou Teams abonné à sla.violation.

SLA pour les dépendances de haute sévérité

1

Créer le SLA

Créez un SLA de type Vulnérabilité des dépendances (SCA) avec l’urgence Élevée, et éventuellement Critique.
2

Définir les délais

Définissez des fenêtres de remédiation et d’escalade adaptées à votre cadence de patchs.
3

Configurer les notifications

Utilisez E-mail pour les propriétaires des projets et/ou un webhook pour votre canal de sécurité.

Bonnes pratiques

  • Utilisez des délais de remédiation courts dans les environnements hors production pour valider l’envoi des e-mails et des webhooks.
  • Attribuez des propriétaires à tous les projets actifs soumis à un SLA.
  • Pour les canaux d’équipe, privilégiez les webhooks d’intégration (Slack, Zapier ou personnalisés) abonnés à sla.violation plutôt que les URL ponctuelles.
  • Définissez des SLA SAST et SCA distincts si les délais diffèrent entre les correctifs de code et les mises à niveau de dépendances.

Dépannage

  • Aucun e-mail — vérifiez que E-mail est activé sur le SLA, qu’un délai est réellement dépassé et que les destinataires prévus (responsable, propriétaires du projet ou administrateurs) disposent d’une adresse valide dans Corgea.
  • Aucun webhook — vérifiez qu’un webhook est sélectionné ou créé pour le SLA, qu’il est actif et que des problèmes ont effectivement enfreint le SLA. Consultez Intégrations → Webhooks → Historique.
  • Liste de destinataires vide — ajoutez des propriétaires au projet ou des administrateurs de l’entreprise disposant d’une adresse e-mail valide.
  • Aucune correspondance pour les problèmes SCA — vérifiez que le projet est associé par l’intermédiaire du scan et que le niveau d’urgence correspond à la règle du SLA.