Intégration Jira

Pourquoi c’est important

Les personnes qui trient un rapport de vulnérabilité ne sont presque jamais celles qui le corrigent. Le triage se fait dans Kit ; la correction se fait sur un tableau d’ingénierie. Sans lien entre les deux, quelqu’un recopie le rapport dans Jira à la main — et à partir de là, les deux systèmes divergent. Le ticket indique « In Review » alors que le rapport indique « Validé », personne ne sait répondre à la question « est-ce vraiment corrigé ? », et le chercheur attend.

Connecter Jira met fin à cette dérive. Un clic sur un rapport crée le ticket d’ingénierie, et le lien entre les deux est une relation que Kit tient à jour — pas une URL que quelqu’un a collée dans un commentaire.

Cela règle aussi un problème plus discret : la recopie manuelle a tendance à coller tout, y compris les étapes de reproduction et l’e-mail du chercheur, dans un projet dont personne n’a vérifié l’audience réelle. L’intégration de Kit transmet à la place un ticket volontairement minimal.

Ce dont vous avez besoin

• Un compte Kit avec le module complémentaire VDP activé
• Un site Jira Cloud (Jira Data Center et Jira Server ne sont pas pris en charge)
• Un compte Atlassian qui a accès au projet cible
• Les droits d’administrateur de module dans Kit — connecter un outil de suivi est une décision qui engage toute l’organisation

Configuration

1. Connectez votre compte Atlassian

1. Rendez-vous sur VDP > Paramètres > Suivi des tickets
2. Cliquez sur Connecter Jira
3. Connectez-vous à Atlassian et approuvez l’accès demandé
4. Choisissez le site Jira à utiliser, si votre compte Atlassian en possède plusieurs

L’autorisation appartient à la personne qui l’a accordée. Kit garde la trace de son identité, car lorsque cette personne quitte l’organisation, la connexion cesse de fonctionner et vous devez savoir quel accès renouveler.

2. Choisissez un projet et un type de ticket

1. Sur la page des paramètres, cliquez sur Choisir le projet
2. Choisissez le projet qui doit recevoir le travail de correction des vulnérabilités
3. Choisissez le type de ticket avec lequel les nouveaux tickets sont créés (généralement Bug ou Task)

Kit lit le type de projet pendant que vous faites ce choix. S’il s’agit d’un projet Jira Service Management, les commentaires sur les changements de statut sont désactivés par défaut : JSM impose que les commentaires créés via l’API de la plateforme soient publics, ce qui les exposerait aux demandeurs externes de votre service desk.

Kit lit également les noms de priorité que votre projet et votre type de ticket acceptent, et y fait correspondre les niveaux de sévérité des rapports (critique → Highest, élevée → High, et ainsi de suite). Deux cas méritent d’être connus, et la page des paramètres vous signale lorsque l’un ou l’autre s’applique :

• Votre projet utilise ses propres noms de priorité, ou fonctionne dans une autre langue que l’anglais. Kit n’invente pas une priorité qu’il ne peut pas faire correspondre : ces rapports reçoivent donc la priorité par défaut du projet. Le niveau de sévérité est de toute façon toujours inscrit dans la description du ticket.
• Votre projet n’a pas de champ Priorité sur son écran de création, ce qui est courant dans les projets gérés par l’équipe. Kit n’envoie alors aucune priorité.

Pour maîtriser vous-même cette correspondance, définissez une surcharge priority_map sur la connexion — il n’existe pas encore d’écran dédié.

3. Vérifiez que tout fonctionne

Cliquez sur Tester la connexion. Kit effectue un aller-retour authentifié vers votre site et affiche le résultat.

Transmettre un rapport

Ouvrez n’importe quel rapport. Dans la colonne de droite, vous trouverez une carte Suivi des tickets.

1. Cliquez sur Créer un ticket
2. Lisez le panneau qui indique ce qui est transmis et ce qui reste dans Kit
3. Cliquez sur Créer le ticket

La carte affiche un indicateur de chargement pendant la création du ticket, puis la clé du ticket, son statut et un lien qui ouvre Jira dans un nouvel onglet.

Tout membre de l’équipe qui peut voir le rapport peut le faire — c’est du triage courant, au même niveau d’autorisation que joindre un lien. Seule la configuration de la connexion est réservée aux administrateurs.

Ce qui sort de Kit

C’est la partie qui mérite une lecture attentive. Par défaut, un ticket transmis est minimal : de quoi permettre à un ingénieur de planifier le travail, rien de plus.

Transmis à Jira	Reste dans Kit
Titre du rapport et référence Kit	La description de la vulnérabilité
Gravité et score CVSS	Les étapes de reproduction
Type de vulnérabilité	Le point de terminaison concerné
Domaine concerné	Les fichiers de preuve de concept et les captures d’écran
Échéance de correction	Le nom, l’e-mail et les informations de versement du chercheur
Un lien de retour vers le rapport dans Kit	Les notes internes et le fil de discussion

Ce choix n’est pas de la prudence gratuite. Depuis Kit, il est impossible de savoir qui voit réellement Jira : autorisations de projet à l’échelle de l’organisation, applications de la place de marché disposant d’un droit de lecture sur les tickets, exports CSV et sauvegardes qui survivent au ticket. Les champs que Kit retient sont ceux-là mêmes qu’il chiffre au repos ; les transmettre reviendrait donc à déplacer vos données les plus protégées vers votre système le moins maîtrisé.

L’identité du chercheur et les montants des primes ne disposent d’aucun réglage. L’absence même de l’option constitue la garantie.

Partager malgré tout les détails complets

Certaines équipes tiennent à avoir la description dans le ticket. Cela exige deux conditions indépendantes :

1. Un administrateur active Autoriser les détails complets de la vulnérabilité dans VDP > Paramètres > Suivi des tickets
2. La personne qui transmet le rapport coche la case pour ce ticket précis

Les deux sont désactivés par défaut. Lorsque le réglage au niveau du programme est désactivé, les cases ne s’affichent même pas — et une requête forgée à la main ne peut pas les contourner, car Kit revérifie le réglage du programme au moment de construire les données à transmettre.

Lorsque le texte du rapport est inclus, il est placé dans un bloc de code : Jira l’affiche donc exactement tel que le chercheur l’a rédigé, au lieu de l’interpréter comme du balisage.

Statut de la correction

La carte affiche le libellé de statut du ticket tel que votre tableau le formule (« In Review », « Ready for QA »), parce que c’est ce que voit l’ingénieur. Kit le fait correspondre en interne à l’un de cinq états — Non commencé, En cours, Corrigé, Ne sera pas corrigé, Inconnu — en s’appuyant sur les catégories de statut fixes de Jira plutôt que sur les noms de statut ; aucune correspondance de flux de travail par projet n’est donc nécessaire.

Kit ne résout jamais un rapport au motif que Jira affiche « Done ». Sur un tableau d’ingénierie, « Done » signifie couramment « fusionné, pas déployé », et résoudre un rapport entraîne des conséquences que la personne qui déplace une carte n’a pas forcément voulues : le chercheur est notifié, le processus de prime s’ouvre et les compteurs de divulgation avancent. Kit met le ticket terminé en évidence et laisse la décision à un humain.

Dissociation et nouvelles tentatives

• Dissocier ne supprime le lien que dans Kit. Le ticket reste dans Jira, où il porte peut-être déjà les commentaires d’un ingénieur et une branche de correction — Kit n’est pas le système de référence de ce côté-là.
• Réessayer relance une transmission qui a échoué. Vous pouvez appuyer deux fois sans risque : Kit marque chaque ticket avec une clé unique et cherche cette marque avant de créer quoi que ce soit ; une requête expirée alors que Jira avait déjà créé le ticket reprend donc le ticket existant au lieu d’en créer un second.
• Déconnecter l’intégration supprime la copie de l’autorisation détenue par Kit ainsi que ses lignes de suivi. Tous les tickets déjà créés restent dans Jira.

Dépannage

Symptôme	Cause	Solution
« L’accès à Jira a été révoqué »	L’autorisation a été révoquée dans Atlassian, ou l’utilisateur qui l’avait accordée a été désactivé	Reconnectez-vous depuis la page des paramètres ; un autre administrateur peut réautoriser l’accès
« Ce projet n’a aucun type de ticket utilisable »	Le projet n’expose que des types de sous-tâche	Choisissez un autre projet, ou ajoutez un type de ticket standard dans Jira
Le ticket a été refusé à cause d’un champ	Un champ personnalisé obligatoire que le ticket minimal ne remplit pas	Consultez l’erreur affichée sur la carte, puis ajustez la configuration des champs du projet pour que ce champ soit facultatif à la création
Aucun bouton Créer un ticket n’apparaît	Aucun outil de suivi n’est connecté, ou le module complémentaire VDP n’est pas actif	Connectez-en un dans VDP > Paramètres > Suivi des tickets

En bref

• Le module complémentaire VDP est actif sur le compte
• Le compte Atlassian est connecté, et vous savez qui a accordé l’autorisation
• Le projet cible et le type de ticket sont choisis
• Le test de connexion réussit
• Vous avez vérifié sur la page des paramètres si un avertissement sur la correspondance des priorités s’affiche pour le projet choisi
• Vous avez décidé, en connaissance de cause, si les détails complets de la vulnérabilité peuvent être partagés
• S’il s’agit d’un projet Jira Service Management, vous avez vérifié que les commentaires sur les changements de statut sont désactivés