Aperçu de la sécurité

En vigueur le 28 octobre 2026

Signaler une vulnérabilité

Si vous pensez avoir trouvé un problème de sécurité dans TreeCraft, suivez notre Politique de divulgation des vulnérabilités. Elle explique comment signaler, ce qui est visé, comment nous protégeons les chercheurs de bonne foi, et ce que vous pouvez attendre de nous et quand.

• Écrivez à info@plugincraft.ca. Utilisez des données fictives.
• Pour une question urgente, par exemple des données exposées en ce moment, mettez « URGENT » au début de l’objet du message.
• Heures de la personne-ressource en sécurité : de 8 h à 17 h, heure de l’Est, du lundi au vendredi.

Une fois TreeCraft inscrite au Marketplace d’Atlassian, vous pourrez aussi signaler par l’entremise d’Atlassian : le programme de primes aux bogues de sécurité du Marketplace et le programme de divulgation des vulnérabilités (en anglais).

Engagements de réponse

Voici les délais auxquels Plugincraft s’engage. Ils correspondent aux minimums qu’Atlassian fixe aux partenaires du Marketplace dans le programme Atlassian Enterprise Certified, ou les améliorent. Les jours ouvrables vont du lundi au vendredi, et les heures ouvrables sont les heures de soutien : de 8 h à 17 h, heure de l’Est. Un message reçu en dehors des heures ouvrables compte à partir du début de la période ouvrable suivante.

Les signalements de sécurité vont à info@plugincraft.ca. Cette adresse reçoit des messages en tout temps et est consultée chaque jour ouvrable.

Délais de correction

Nous évaluons une vulnérabilité selon son score CVSS et la corrigeons dans le délai de la politique de correction des bogues de sécurité d’Atlassian (en anglais) pour les applications Cloud. Le délai court à partir du jour où nous recevons le signalement, ou du jour où Atlassian nous signale la vulnérabilité par le Marketplace, selon le premier des deux. Nous avons vérifié la politique le 27 octobre 2026. Atlassian peut la modifier, et c’est la politique publiée sur le site d’Atlassian qui s’applique.

Ce sont les délais auxquels Plugincraft s’engage. Nous n’en demandons pas de plus longs. La politique d’Atlassian n’accepte une prolongation que dans des cas limités, par exemple lorsque le correctif dépend d’un changement de la plateforme Atlassian. Si nous devions en demander une, nous le dirions à la personne qui a signalé le problème. Un incident de sécurité a aussi une gravité et des objectifs dans Réponse aux incidents. Lorsque les deux s’appliquent, nous respectons le délai le plus court.

Pratiques de sécurité

Cette section décrit comment nous concevons, exploitons et vérifions TreeCraft. Ce qu’elle dit de l’application vient du code source et de la documentation de l’application. Ce qu’elle dit de la plateforme d’Atlassian vient de la documentation d’Atlassian, avec un lien là où elle est utilisée.

Cycle de développement sécurisé

• Code source privé, demandes de fusion seulement. Le code source est privé. Chaque changement est fait dans sa propre branche et n’atteint la branche principale que par une demande de fusion. Personne ne dépose directement dans la branche principale.
• Révision indépendante. Chaque demande de fusion est révisée par un réviseur qui n’en est pas l’auteur. Le réviseur est un agent de révision d’IA qui suit des règles écrites (voir la Politique d’utilisation de l’IA). Il lit le changement à la lumière de ces règles, vérifie que les tests automatisés réussissent et consigne dans la demande de fusion ce qu’il a exécuté et ce qu’il a trouvé. L’approbation d’une personne ne le remplace pas, et les auteurs ne fusionnent jamais leurs propres demandes. Pas de révision, pas de fusion.
• Tests automatisés à chaque changement. À chaque demande de fusion et à chaque dépôt dans la branche principale, la compilation exécute la vérification des types, des tests unitaires et de volume qui doivent couvrir au moins 90 % des lignes, des branches, des fonctions et des instructions, une compilation de production et des tests de bout en bout de l’interface dans un vrai navigateur. Une fonction visible par les gens est livrée avec ses tests de bout en bout dans la même demande de fusion.
• Des tests qui protègent les engagements de cette page. Un test fait échouer la compilation si l’application ajoute un accès réseau externe. Un autre la fait échouer si du code journalise du contenu de clients. Un troisième protège les migrations de base de données publiées, auxquelles on ne peut qu’ajouter, jamais les modifier ni les retirer.
• Recherche de secrets. Une analyse de recherche de secrets s’exécute à chaque demande de fusion et à chaque dépôt dans la branche principale. Elle lit le code et tout son historique, avec les règles par défaut de l’outil et une règle pour les clés de licence Atlassian.
• Analyse des dépendances et analyse statique (en cours d’ajout). L’analyse des dépendances de l’application pour y détecter les vulnérabilités connues, et l’analyse statique de son code source, sont en cours d’ajout aux vérifications automatisées. Cette page sera mise à jour lorsqu’elles s’exécuteront à chaque changement.
• Ce que nous faisons des constats. Nous corrigeons une vulnérabilité dans une dépendance livrée avec l’application dans les délais ci-dessus. Tant que les analyses ci-dessus ne s’exécutent pas, nous en prenons connaissance par des avis et des signalements, pas par une vérification automatisée.
• Livraisons. Seules les personnes à qui le propriétaire a donné accès à l’application peuvent la déployer.
• Environnement d’exécution à jour. L’application fonctionne sur l’environnement Node.js 22 de Forge.

Contrôle d’accès

• Jira décide qui voit un ticket. Les pages de l’application lisent les tickets dans Jira au nom de la personne qui regarde, si bien que Jira exclut ce qu’elle ne peut pas consulter. Les lectures qui ne partent pas d’une page (l’agent Rovo, les gadgets de tableau de bord et la liste des hiérarchies du panneau de ticket) demandent à Jira, au nom de l’appelant, quels tickets il peut voir. Une vérification qui échoue ou qui expire cache le ticket.
• La structure, pas le contenu. L’application garde la structure de chaque hiérarchie sous forme d’identifiants de tickets et de positions. Une personne qui peut ouvrir une hiérarchie peut recevoir les identifiants et les positions de tickets qu’elle ne peut pas consulter, et jamais les clés, les résumés ni les valeurs de champs de ces tickets. L’API REST et les outils MCP fonctionnent de la même façon : ils retournent des identifiants et les propres mots de l’application, et l’appelant lit les tickets dans Jira avec son propre jeton, où Jira applique les permissions de cette personne.
• Les changements sont faits au nom de la personne. Les modifications, transitions et écritures partent vers Jira depuis le navigateur de la personne, en son nom, si bien que Jira applique ses permissions. L’application n’écrit pas dans Jira en son propre nom, sauf pour une exception : les jetons de recherche ci-dessous.
• Les jetons de recherche sont écrits au nom de l’application. Lorsqu’une personne ayant Contrôler active la recherche Jira pour une hiérarchie, l’application écrit sur chaque ticket de la hiérarchie, en son propre nom, une petite propriété (craftline-search) qui contient des jetons aléatoires sans aucun contenu. Elle met aussi à jour les réponses enregistrées de sa propre fonction JQL. Les personnes qui peuvent modifier un ticket peuvent modifier ses propriétés : l’application ne se sert donc jamais de la propriété pour décider qui voit quoi. Toute personne qui peut chercher dans Jira peut utiliser la fonction et savoir lesquels des tickets qu’elle peut consulter font partie de la hiérarchie, ce qui explique que la recherche reste désactivée tant qu’une personne ayant Contrôler ne l’active pas. L’application retire les jetons d’une hiérarchie lorsque sa recherche est désactivée ou que la hiérarchie est supprimée.
• L’application n’agit en son propre nom que lorsqu’elle le doit. Elle lit en son propre nom les noms et les listes de champs du site, les personnes et les groupes des règles d’accès, les objets Assets et le journal d’audit du site, et elle n’écrit jamais dans Jira en son propre nom, sauf comme décrit ci-dessus.
• Chaque requête est vérifiée sur le serveur. Une personne sans accès Consulter à une hiérarchie reçoit « introuvable », si bien que les identifiants de hiérarchies ne sont pas divulgués. Si l’application ne peut pas confirmer qu’une personne peut voir un ticket ou une hiérarchie, elle le cache.
• Des niveaux qui ne font que restreindre. Chaque hiérarchie a sa propre liste d’accès (Aucun accès, Consulter, Modifier, Automatiser, Contrôler) en plus des permissions de Jira. Les administrateurs Jira peuvent aussi limiter qui peut utiliser l’application, qui peut utiliser l’automatisation et les écritures, et qui administre l’application. Ces listes retirent de l’accès. Elles n’accordent jamais un niveau.
• Des API authentifiées seulement. L’application n’a aucun déclencheur Web. L’API REST et les outils MCP passent par la passerelle d’API d’Atlassian, qui vérifie un jeton OAuth et ses portées avant que l’application s’exécute. L’application vérifie ensuite l’accès de la personne à chaque hiérarchie, un interrupteur du site et ses limites (120 appels par minute par personne et 1 000 par site).
• Moindre privilège. Les portées que l’application demande, et pourquoi, sont listées plus bas.
• Aucun identifiant de connexion. L’application ne demande ni mot de passe ni jeton d’API personnel et n’en garde aucun.

Minimisation des données

• Aucune copie de vos tickets. Les pages lisent les tickets dans Jira quand elles en ont besoin. Le serveur garde les identifiants et les positions des tickets de chaque hiérarchie et, pendant un jour, l’heure à laquelle Jira a dit qu’un ticket avait changé.
• Des identifiants, pas des personnes. L’application stocke des identifiants de comptes Atlassian pour savoir à qui appartient une hiérarchie, qui y a accès et qui a fait un changement. Elle ne stocke ni noms ni adresses courriel : elle les demande à Jira quand elle les affiche. Les absences ne contiennent que des jours et des heures, sans motif, et sont effacées deux ans après leur fin.
• Seulement ce qu’une fonction exige. Les objets Assets sont gardés sous forme de noms, de clés, de types et d’attributs choisis, avec un texte coupé à 100 caractères et jamais d’adresse courriel ni d’attribut masqué. Les données de courte durée sont retirées selon le calendrier de Traitement des données, et l’historique des changements est supprimé après un an, sauf si un administrateur désactive cette suppression.
• Des journaux sans contenu. Les journaux de l’application contiennent des identifiants, des nombres, des statuts et des codes d’erreur. Voir Journalisation des données.
• Un paquet de soutien sur demande. Le paquet de soutien contient des versions, des paramètres, des nombres et des identifiants. Un administrateur voit tout le fichier avant de décider de l’envoyer.
• Aucun suivi. L’application n’utilise aucun service d’analyse. Ce site Web n’utilise aucune analyse et ne dépose aucun témoin.

Fonctionne sur Atlassian (aucune sortie de données)

• L’application ne déclare aucune permission d’appel externe, aucun serveur distant, aucun module Connect, aucun déclencheur Web ni aucune adresse externe, et elle n’utilise ni script, ni police, ni image, ni service d’analyse ou de journalisation extérieurs. Un test fait échouer la compilation si l’un d’eux est ajouté. Elle est conçue pour rester admissible au programme Runs on Atlassian d’Atlassian (en anglais).
• Plugincraft n’a aucun serveur à elle. Le seul sous-traitant des données de l’application est Atlassian (voir Sous-traitants), et toutes les données que l’application stocke restent à l’emplacement de résidence des données de votre site Jira.
• Atlassian indique que la plateforme Forge est attestée SOC 2 et certifiée ISO 27001, et qu’une application qui utilise l’environnement d’exécution et le stockage hébergé de Forge, sans sortie de données, peut s’appuyer sur les contrôles hérités de la plateforme. Cela vaut pour la plateforme. Ce n’est pas une certification de Plugincraft. Atlassian dit aussi que, lorsqu’une application fonctionne entièrement sur sa plateforme, elle peut pleinement appuyer l’enquête, le confinement et le partage des journaux lors d’un incident.

Chiffrement au repos et en transit

• Au repos. TreeCraft ne stocke les données de clients que dans le stockage hébergé de Forge (Forge SQL et le stockage clé-valeur) et, pour les jetons de recherche, dans Jira. Elle ne garde rien sur un serveur à elle. Atlassian indique que la plateforme Forge utilise AES-256 pour chiffrer au repos les données stockées dans le stockage des applications Forge, et que les données du stockage clé-valeur sont « transférées, chiffrées et stockées sur disque conformément aux politiques de chiffrement des données du nuage Atlassian » (traduction libre). Forge SQL et le stockage clé-valeur font tous deux partie du stockage hébergé de Forge, couvert par la même documentation sur le cycle de vie des données Forge.
• En transit. Atlassian indique que la plateforme Forge utilise TLS 1.2 ou une version supérieure pour chiffrer les données en transit. L’application n’établit aucune autre connexion. Ce site Web redirige le HTTP simple vers HTTPS et demande aux navigateurs de n’utiliser que HTTPS.
• Secrets. L’application ne garde aucun identifiant de connexion : elle n’a donc aucun secret à chiffrer.

Sauvegardes et reprise

• Atlassian sauvegarde le stockage. Atlassian indique que les bases de données provisionnées et gérées par Forge SQL sont sauvegardées périodiquement, et que le nuage Atlassian sauvegarde tout le stockage persistant de Forge pour la reprise après sinistre. Si une application supprime des données par erreur, Atlassian peut les restaurer lorsqu’un billet de soutien est ouvert dans les 21 jours suivant la suppression.
• Plugincraft ne garde aucune copie. Nous ne gardons aucune copie ni sauvegarde des données de clients. Le code de l’application est dans un dépôt de code source privé, d’où une nouvelle version peut être déployée sur Forge.
• Les administrateurs peuvent enregistrer leur propre sauvegarde. Un administrateur Jira peut enregistrer un fichier de sauvegarde des données de l’application (hiérarchies, règles, notes, accès, paramètres et, s’il le choisit, historique) et le restaurer sous forme de nouvelles hiérarchies à côté de celles qui existent. Le fichier est enregistré là où l’administrateur le choisit, et Plugincraft ne le reçoit jamais. La sauvegarde et la restauration sont couvertes par des tests automatisés.

Test d’intrusion et primes aux bogues (prévus)

• Test d’intrusion. Aucun test d’intrusion de TreeCraft n’a encore été réalisé. Après l’inscription de l’application au Marketplace d’Atlassian, nous prévoyons la faire tester une fois par an, par le programme de tests d’intrusion d’Atlassian ou par un fournisseur accrédité CREST. Une fois un test réalisé, nous prévoyons de mettre le rapport ou une lettre d’attestation à la disposition des clients, sous entente de confidentialité.
• Primes aux bogues. TreeCraft ne participe pas encore à un programme de primes aux bogues, et Plugincraft ne verse pas encore de récompense pour les signalements. Après l’inscription de l’application, nous prévoyons de participer au programme de primes aux bogues de sécurité du Marketplace d’Atlassian.
• Ce sont des projets, pas des résultats. Nous mettrons cette page à jour quand un test sera réalisé ou que nous aurons joint le programme.

Permissions demandées par l’application

Voici les portées Forge du manifeste de l’application, et à quoi chacune sert.

Incidents et état du service

La façon dont nous traitons un incident est décrite dans Réponse aux incidents. Une page d’état sera publiée avec la fiche du Marketplace. Les problèmes de Jira ou de Forge eux-mêmes sont signalés sur la page d’état d’Atlassian.

Documents connexes

• Politique de divulgation des vulnérabilités
• Diagramme d’architecture et flux de données (protégé par mot de passe : demandez l’accès à info@plugincraft.ca)
• Journalisation des données
• Traitement des données : conservation et suppression
• Réponse aux incidents
• Sous-traitants
• Politique de confidentialité