Notifications

Ctadel envoie chaque nouveau constat vers vos outils de messagerie ou d'astreinte. Le réglage se fait en deux temps : les canaux (où envoyer) dans « Intégrations », puis les règles d'alerte (quoi envoyer) dans « Notifications ». Lire demande read:settings, modifier demande update:settings.

Les canaux

Ouvrez « Paramètres », onglet « Intégrations », sous-onglet « Notifications ». La carte « Notifications configurées » liste vos canaux ; la carte « Catalogue » propose huit types.

Chaque canal porte un « Nom » et peut être activé, désactivé, modifié, testé ou supprimé. Le test envoie un événement fictif de sévérité HIGH intitulé « Test Notification » et répond « Test envoyé avec succès ». Lors d'une modification, les valeurs secrètes (secret de signature, clé PagerDuty, jeton Matrix) sont masquées ; les laisser masquées conserve la valeur enregistrée. Supprimer un canal entraîne : « Les règles de notification rattachées à ce canal cesseront de remonter. »

Le format du webhook

Le canal Webhook envoie une requête POST en JSON, avec l'en-tête User-Agent: Ctadel-Notifier/1.0 et vos en-têtes personnalisés :

{
  "finding_type": "cspm",
  "severity": "HIGH",
  "title": "CSPM: <NOM DE LA RÈGLE>",
  "details": "Resource: <RESSOURCE>, Category: <CATÉGORIE>",
  "resource_id": "<IDENTIFIANT>",
  "rule_key": "<CLÉ DE RÈGLE>",
  "project_id": "<PROJET>",
  "count": 1,
  "timestamp": "2026-10-10T08:00:00Z"
}

Avec un secret de signature, deux en-têtes s'ajoutent : X-Ctadel-Timestamp (horodatage Unix) et X-Ctadel-Signature sous la forme t=<HORODATAGE>,v1=<HMAC-SHA256 hexadécimal de "<HORODATAGE>.<CORPS>">. L'horodatage entre dans la signature, ce qui permet au récepteur de rejeter un rejeu.

Les règles d'alerte

Ouvrez « Paramètres », onglet « Notifications », carte « Règles d'alerte », puis « Ajouter une règle ». Sans canal, la carte affiche : « Configurez d'abord un canal dans Intégrations > Notifications, puis ajoutez des règles ici. »

L'évaluation suit cet ordre : si des règles spécifiques sont listées, seul leur nom compte, puis le projet ; sinon le type d'événement, la sévérité minimale, les types cochés et les projets.

Les types d'événements

Seuls les constats nouveaux sont notifiés : un constat déjà connu, rouvert ou résolu ne génère rien. Les messages sont rédigés en anglais.

Une règle qui doit recevoir les fins de parcours ou les messages des assistants doit donc cocher le type et laisser la sévérité minimale à « Toutes les sévérités » ou à LOW.

Les courriels

Il n'existe pas de canal courriel. Deux courriels seulement partent de l'instance en dehors de l'authentification :

• Le récapitulatif de fin de parcours complet, si l'interrupteur « Email à la fin d'un scan complet » de l'onglet « Général » est activé. Il est envoyé à chaque personne qui détient le rôle « Global Admin », dans sa langue.
• Les alertes d'infrastructure, décrites ci-dessous, qui vont à l'opérateur Ctadel.

Déduplication et livraison

• Un même événement (règle d'alerte, ressource, clé de règle, type) n'est envoyé qu'une fois par période de 5 minutes.
• Les envois sont cadencés. Lors d'un pic, un message qui ne peut pas partir est abandonné et sera renvoyé la prochaine fois que le constat est signalé.
• Un refus temporaire (HTTP 429, erreur 5xx, délai dépassé, connexion refusée) est retenté quelques fois. Un refus définitif (autre erreur 4xx, configuration invalide) abandonne le message, avec une trace dans les journaux techniques de l'instance.

Les alertes d'infrastructure

La carte « État du système » de l'onglet « Général » suit l'état des services internes de l'instance et le signe de vie de chaque composant. Un composant silencieux plus de 5 minutes passe à « Indisponible » ; son retour est signalé aussi. Ces deux transitions produisent un événement system.

Ces alertes sont destinées à l'équipe d'exploitation Ctadel, qui les reçoit par courriel et par webhook sur ses propres adresses. Elles ne sont jamais envoyées par courriel aux administrateurs de votre instance. Vous les recevez sur vos canaux uniquement si une règle d'alerte coche le type system, comme l'indique la carte : « Un composant silencieux plus de 5 minutes alerte automatiquement l'équipe d'exploitation Ctadel ; le rétablissement est notifié aussi. Ajoutez le type system à une règle de notification si vous voulez aussi ces événements sur vos propres canaux. »

Limites

• Pas de canal courriel pour les constats ; les courriels se limitent au récapitulatif de fin de parcours et aux alertes destinées à l'opérateur. La page « Préférences » renvoie vers ces réglages, mais il n'existe pas de notification personnelle.
• Le type cve figure dans la liste sans qu'aucun événement ne soit émis : une règle qui ne coche que ce type ne reçoit rien.
• Les secrets trouvés lors de l'analyse d'une pull request ne sont pas notifiés ; seuls ceux de la branche par défaut le sont.
• Rien n'est envoyé à la résolution ou à la réouverture d'un constat, et il n'existe pas de résumé périodique des constats.
• Les messages sont en anglais, quelle que soit la langue de l'instance.
• Les règles sont propres à l'instance ; aucune notification par utilisateur.
• Les destinations sur réseau privé sont refusées ; aucune option de l'interface ne lève cette règle.
• Aucun journal des envois dans l'application : un échec de livraison n'est visible que dans les journaux techniques de l'instance.
• La déduplication ne survit pas à un redémarrage de l'instance.
• Les événements system, scan et agent ne portent pas de projet ; le filtre « Projets » ne s'y applique pas.