Outils de tickets

Une alerte n’est utile que si quelqu’un la corrige, et celui qui corrige travaille souvent dans un autre outil : Jira ou GitLab pour les développeurs, GLPI ou ServiceNow pour l’équipe informatique. TechWatchAlert ouvre le ticket dans cet outil, avec tout ce qu’il faut pour agir, puis fait revenir son statut dans le dossier : plus de double saisie.

Les outils se configurent dans les réglages du projet, page Intégrations, section Outils de tickets (administrateurs du projet). Les tickets font partie de la gestion des dossiers (offres Pro et au-dessus).

Outils pris en charge

Outil	Où le ticket est créé	Retour du statut
Jira Cloud et Data Center	Le projet Jira choisi (type de ticket et étiquettes réglables)	Webhook signé, et relecture
GitLab (gitlab.com ou votre instance)	Le projet choisi	Webhook signé, et relecture
GitHub et GitHub Enterprise	Le dépôt choisi	Webhook signé, et relecture
GLPI 9.5 à 11	Assistance › Tickets	Relecture
ServiceNow	Incidents, ou éléments vulnérables du module Vulnerability Response	Règle métier signée, et relecture
ConnectWise, Autotask, HaloPSA (espace partenaire)	La company du client	Relecture

Plusieurs outils par projet

Un projet peut avoir jusqu’à cinq outils : par exemple Jira pour les développeurs et GLPI pour l’informatique. L’un d’eux est l’outil par défaut : c’est celui du bouton Ouvrir un ticket de la fiche d’alerte quand le projet n’en a qu’un, et celui des workflows qui n’en choisissent pas.

• Sur la fiche d’alerte, quand le projet a plusieurs outils, le bouton devient un menu : Ouvrir dans GLPI informatique, Ouvrir dans Jira des développeurs…
• La tuile de workflow Créer un ticket a un réglage Outil de tickets : l’outil par défaut, ou celui choisi. Un workflow « CVE exploitée sur un poste » peut ainsi ouvrir dans GLPI, et un workflow « dépendance d’un dépôt » dans GitHub.
• Il reste un seul ticket par CVE et par projet, quel que soit l’outil : deux tickets pour la même faille dans deux outils seraient deux vérités qui se contrediraient dans le dossier.

Ajouter un outil

1. Réglages du projet › Intégrations › Outils de tickets › Ajouter un outil.
2. Choisissez l’outil et, si vous le souhaitez, un nom affiché (« GLPI informatique »).
3. Renseignez la connexion (adresse, cible, identifiants) : voir ci-dessous pour chaque outil. Le pas-à-pas Créer ce compte dans…, replié sous la fiche, décrit les droits à donner.
4. Réglez le ticket créé (entité, catégorie, groupe, type…) et le retour de statut.
5. Tester et enregistrer : le test de connexion vérifie, étape par étape, la configuration, la réponse de l’outil, le compte puis l’accès à la cible, sans rien créer dans l’outil. Rien n’est enregistré si le test échoue ; l’étape en échec dit la cause et le réglage à corriger.

Les secrets (jetons, mots de passe, secrets OAuth) sont chiffrés et ne sont jamais réaffichés : un secret enregistré se lit « Enregistré », avec Remplacer. Changer l’adresse de l’outil, d’outil ou de mode d’authentification demande de ressaisir les secrets : un secret ne suit jamais vers une autre destination.

GLPI

Deux façons de se connecter :

• API REST (GLPI 9.5 à 11) : comme le connecteur d’inventaire GLPI. Dans GLPI, Configuration › Générale › API, activez l’API REST et la connexion par jeton ; créez un client d’API (jeton d’application) si votre instance l’exige ; sur un compte dédié, générez le jeton d’API dans ses préférences.
• API de haut niveau (GLPI 11) : dans Configuration › OAuth, créez un client autorisé à l’octroi « password » et à la portée « api », puis un compte de service. Saisissez le client, son secret, le compte et son mot de passe.

Le profil du compte doit pouvoir créer des tickets, des suivis et des solutions dans l’entité choisie.

Le ticket est créé dans Assistance › Tickets, avec, si vous les indiquez : l’entité, la catégorie ITIL, le demandeur, le groupe assigné (identifiants numériques, visibles dans l’adresse de leur fiche GLPI) et le type (incident ou demande).

ServiceNow

• Authentification : un compte d’intégration (utilisateur sans accès à l’interface web, rôle itil), ou un client OAuth (System OAuth › Application Registry, point d’accès pour clients externes avec l’octroi « client credentials » et un utilisateur associé portant le rôle itil).
• Créer dans : Incidents, ou Vulnerability Response si l’instance a ce module (le test de connexion le signale). Un élément vulnérable est rattaché à la fiche de la CVE de votre instance ; si la CVE n’y est pas encore, l’ouverture échoue avec un message clair.
• Groupe d’affectation et appelant : nom ou identifiant (sys_id). Catégorie, sous-catégorie et code de résolution utilisé à la fermeture (par défaut « Solution provided ») sont facultatifs.

Jira

• Jira Cloud : adresse https://…atlassian.net, clé du projet (SEC), e-mail d’un compte dédié et jeton d’API (id.atlassian.com › Sécurité › Jetons d’API).
• Jira Data Center : adresse de l’instance, clé du projet, e-mail vide et jeton d’accès personnel.
• Le compte doit pouvoir créer, commenter et faire avancer les tickets du projet.

GitLab et GitHub

• GitLab : chemin du projet (groupe/projet) et jeton d’accès de projet, portée api, rôle Reporter au minimum (Developer pour fermer les tickets).
• GitHub : dépôt (organisation/depot) et jeton à grain fin limité au dépôt, permission « Issues : lecture et écriture ». GitHub Enterprise : adresse de son API (https://…/api/v3).

Contenu du ticket et priorité

Chaque ticket porte le titre « [Sécurité] CVE… · produit — gravité », la gravité et le CVSS, l’EPSS, l’exploitation (KEV, EUVD, CERT-FR, exploit public), le composant, les versions corrigées, la description, une liste « À faire » et un lien vers l’alerte dans TechWatchAlert.

Pour GLPI et ServiceNow, l’urgence, l’impact et la priorité suivent la décision du dossier (palier BOD 26-04 / SSVC, voir Traiter une alerte) :

Décision du dossier	GLPI : urgence / priorité	ServiceNow : urgence
Corriger sous 3 jours, avec triage forensique	Très haute / Majeure	1 – Haute
Corriger sous 3 jours	Très haute / Très haute	1 – Haute
Corriger sous 14 jours	Haute / Haute	2 – Moyenne
Corriger sous 60 jours	Moyenne / Moyenne	2 – Moyenne
Différé	Basse / Basse	3 – Basse

L’impact est haut quand l’attaquant prend le contrôle total, moyen quand le composant est exposé à Internet, bas sinon. ServiceNow calcule ensuite la priorité avec sa propre matrice.

Retour du statut dans le dossier

Le statut du ticket revient dans TechWatchAlert, ramené à quatre états : ouvert, en cours, résolu, rejeté (« Won’t fix », « not planned », annulé, risque accepté…). Il arrive par webhook signé dès que l’outil l’envoie (Jira, GitHub, GitLab, ServiceNow), et par relecture régulière sinon (GLPI, outils PSA), ou en filet si un webhook se perd. Un quota de l’outil est respecté : la relecture attend et reprend plus tard.

Chaque changement ajoute une ligne à l’historique du dossier, et :

• Ticket résolu : le dossier ouvert passe « Corrigé », comme si un membre l’avait passé. Si une machine du parc porte encore la vulnérabilité, il reste en attente de vérification par l’inventaire ; il ne devient « Corrigé, vérifié » que quand l’inventaire le constate, et repasse « En remédiation » si rien ne bouge. Un ticket fermé ne vaut jamais vérification.
• Ticket rejeté : un commentaire, et la fiche propose de déclarer une exception (Atténuée, Risque accepté ou Non applicable). Le dossier n’est pas fermé : ne pas corriger est une décision qui se documente.
• Ouvert, en cours, rouvert : un commentaire seulement.

La fiche d’alerte montre, dans Corriger, le ticket, son statut dans l’outil, quand il y a changé et la dernière lecture, avec Relire maintenant (Analyste et plus).

Dans l’autre sens, quand un dossier devient « Corrigé, vérifié », TechWatchAlert commente le ticket une fois. Avec l’option Fermer le ticket quand la correction est vérifiée (désactivée par défaut), il le ferme aussi : transition vers « Terminé » dans Jira, ticket fermé dans GitHub et GitLab, solution ajoutée dans GLPI (le demandeur valide la clôture), incident résolu dans ServiceNow avec le code de résolution réglé. Un ticket qui couvre plusieurs CVE (ticket d’un geste de correction) attend qu’elles soient toutes vérifiées. Les éléments Vulnerability Response ne sont jamais fermés d’ici : le module les ferme sur sa propre détection.

Webhooks

Dans la fiche de l’outil, Créer l’adresse et le secret donne l’adresse à appeler et le secret de signature. Le secret n’est montré qu’une fois ; Renouveler le secret rend l’ancien inutilisable, Couper désactive l’adresse. Chaque appel non signé, mal signé, ou qui concerne un autre projet ou dépôt que celui de l’outil est ignoré.

Jira

1. Jira › Paramètres système › Webhooks › Créer un webhook (administrateur Jira).
2. URL : l’adresse donnée par TechWatchAlert. Secret : le secret de signature.
3. Événements : « Ticket » › mis à jour (et créé). Filtre JQL conseillé : project = SEC.
4. Enregistrez. Jira signe chaque appel (en-tête X-Hub-Signature).

GitHub

1. Dépôt › Settings › Webhooks › Add webhook.
2. Payload URL : l’adresse donnée par TechWatchAlert ; Content type : application/json ; Secret : le secret de signature.
3. Let me select individual events › Issues seulement.
4. Add webhook. GitHub signe chaque appel (en-tête X-Hub-Signature-256).

GitLab

1. Projet › Paramètres › Webhooks › Ajouter un nouveau webhook.
2. URL : l’adresse donnée par TechWatchAlert ; Jeton secret : le secret de signature.
3. Déclencheur : Événements de ticket seulement. Laissez la vérification SSL activée.
4. Enregistrez. GitLab envoie le jeton dans l’en-tête X-Gitlab-Token.

ServiceNow

ServiceNow n’a pas de webhook prêt à l’emploi : une règle métier envoie le statut. À faire par un administrateur ServiceNow :

1. System Definition › Business Rules › New. Table : Incident (ou Vulnerable Item pour Vulnerability Response). Advanced coché.
2. When : async, sur Update. Condition (incidents) : State changes AND Correlation display is TechWatchAlert (les incidents ouverts par TechWatchAlert portent cette valeur).
3. Onglet Advanced, collez le script ci-dessous et remplacez l’adresse et le secret.
4. Enregistrez, puis faites avancer un incident de test : la fiche de l’outil affiche « Dernier appel reçu ».

(function executeRule(current, previous) {
    // Adresse et secret donnés par TechWatchAlert (fiche de l'outil).
    var ADRESSE = 'https://…/webhooks/tickets/…';
    var SECRET = 'collez-ici-le-secret';
    var champ = function (nom) {
        return { value: current.getValue(nom), display_value: current.getDisplayValue(nom) };
    };
    var corps = JSON.stringify({
        table: current.getTableName(),
        sys_id: current.getUniqueValue(),
        number: current.getValue('number'),
        state: champ('state'),
        substate: champ('substate'),
        close_code: champ('close_code'),
        sys_updated_on: current.getValue('sys_updated_on')
    });
    // HMAC-SHA256 du corps avec le secret (clé passée en base64).
    var signature = new GlideCertificateEncryption().generateMac(
        GlideStringUtil.base64Encode(SECRET), 'HmacSHA256', corps);
    var requete = new sn_ws.RESTMessageV2();
    requete.setEndpoint(ADRESSE);
    requete.setHttpMethod('post');
    requete.setRequestHeader('Content-Type', 'application/json');
    requete.setRequestHeader('X-TWA-Signature', 'sha256=' + signature);
    requete.setRequestBody(corps);
    requete.executeAsync();
})(current, previous);

Attention

Gardez le secret hors des tables lisibles par tous : de préférence dans une propriété système chiffrée (type password2), lue par gs.getProperty. Sans cette règle métier, les incidents restent relus régulièrement : le webhook accélère le retour, il n’est pas indispensable.

Qui peut faire quoi

Action	Rôle dans le projet
Voir les outils, le ticket d’une alerte et son statut	Tous les membres
Ouvrir un ticket, relire son statut	Analyste et plus
Ajouter, modifier, tester, retirer un outil ; créer ou couper le webhook	Admin et Propriétaire

Retirer un outil n’efface pas les tickets déjà ouverts : ils restent liés aux alertes, mais leur statut ne revient plus.