Politique de sécurité — Canopy Access Review

Canopy Access Review est une application Atlassian Forge en lecture seule et sans flux sortant. Elle s'exécute intégralement au sein du cloud d'Atlassian : elle n'effectue aucun appel réseau externe, et SR Consulting n'exploite aucun serveur, aucune base de données et aucun service tiers susceptible de recevoir, traiter ou stocker vos données Jira. Il n'existe aucune copie de vos données côté éditeur qui pourrait être compromise.

Cette architecture constitue le cœur de la présente politique de sécurité : l'essentiel de la surface de risque que sonde habituellement un questionnaire de sécurité fournisseur (infrastructure de l'éditeur, transferts de données, sous-traitants, hébergeurs, sauvegardes détenues par l'éditeur) n'existe pas pour cette application, par conception. Les sections ci-dessous décrivent les mesures qui, elles, s'appliquent : comment l'application est développée et revue, comment nous traitons les vulnérabilités et les incidents de sécurité, et comment nous sécurisons les comptes et systèmes servant à la développer et à la publier.

La présente politique complète — sans la remplacer — la politique de confidentialité de Canopy Access Review, qui décrit les données lues et stockées par l'application.

2.1 Runs on Atlassian — aucun flux sortant

L'application repose sur Atlassian Forge et remplit les critères du programme Runs on Atlassian. Concrètement :

• Aucun flux sortant. Le manifeste de l'application ne déclare aucune permission externe ni domaine de sortie. La plateforme Forge impose cette contrainte à l'exécution : un appel sortant vers un domaine non déclaré est bloqué par la plateforme, et non simplement déconseillé par une règle interne. Les clients peuvent le vérifier dans le manifeste de l'application au moment de l'installation, ainsi que sur la fiche Marketplace.
• Aucune infrastructure éditeur. L'intégralité du code s'exécute dans des fonctions Forge gérées par Atlassian (« FaaS »). SR Consulting n'héberge rien, ne termine aucune connexion TLS et ne détient aucun identifiant d'infrastructure susceptible d'exposer des données client.
• Aucun service tiers. Aucun service d'analytique, de télémétrie, de remontée d'erreurs, aucun CDN, aucune régie publicitaire, aucun service d'IA/LLM ni aucun sous-traitant ne reçoit de données client.

2.2 Accès en lecture seule et moindre privilège

• Chaque habilitation Jira demandée par l'application est une habilitation en lecture. L'application ne détient aucune habilitation en écriture sur les contenus Jira et est techniquement incapable de modifier, supprimer ou faire transitionner des tickets, projets, permissions ou utilisateurs.
• Les habilitations sont granulaires et énumérées dans le manifeste, demandées uniquement lorsqu'un point d'accès REST précis l'exige (schémas de permissions, permissions, rôles de projet, groupes, utilisateurs, projets et les habilitations de lecture associées), auxquelles s'ajoutent storage:app pour le stockage des instantanés au sein d'Atlassian et report:personal-data pour le reporting des données personnelles au titre du RGPD.
• Les clients consultent et acceptent la liste complète des habilitations à l'installation, ainsi qu'à chaque mise à jour qui en ajoute.

2.3 Stockage et chiffrement des données

• Les instantanés de rapport et le journal d'audit de l'application sont stockés dans le Forge Key-Value Store (KVS) — un stockage opéré par Atlassian, au sein du cloud Atlassian, chiffré au repos et en transit par Atlassian, et soumis aux règles de résidence des données d'Atlassian applicables au site du client.
• Les données en transit entre le navigateur de l'utilisateur, Jira et l'application circulent sur des connexions TLS gérées par Atlassian ; aucune connexion ne sort du périmètre Atlassian.
• Les données stockées se limitent à ce dont les rapports ont besoin. Un administrateur peut supprimer les instantanés à tout moment depuis l'application (« effacer toutes les données »), et l'ensemble du stockage de l'application est détruit par Atlassian lors de la désinstallation.

2.4 Autorisation au sein de l'application

• L'interface de l'application est une page d'administration, et chaque resolver côté serveur effectue son propre contrôle d'autorisation en mode fail-closed sur la permission Jira ADMINISTER. L'emplacement du module est considéré comme un confort d'interface, non comme une frontière de sécurité : un appel forgé vers un point d'accès serveur par un non-administrateur est rejeté.
• Les opérations privilégiées modifiant l'état (lancement d'une analyse, effacement des données, export de preuves) sont consignées dans un journal d'audit inaltérable, en ajout seul, doté d'un numéro de séquence monotone : un administrateur peut ainsi savoir qui a fait quoi et quand.

2.5 Sécurité des sorties

• Les exports CSV sont conformes à la RFC 4180 et durcis contre l'injection de formules (injection CSV/tableur) : un objet Jira dont le nom aurait été forgé de façon malveillante ne peut pas transformer un fichier de preuve exporté en charge exécutable dans Excel ou Sheets.
• Les journaux de diagnostic produits par l'application respectent un contrat sans données personnelles : des identifiants et des compteurs, jamais de noms, d'adresses e-mail ni de contenus de rapport.

2.6 La sincérité des rapports comme propriété de sécurité

Pour un outil de revue d'accès, une réponse fausse mais affirmative est une faille de sécurité. L'application recoupe ses résultats calculés avec l'évaluateur de permissions de Jira lui-même sur un échantillon à chaque analyse, et signale les angles morts, les attributions conditionnelles, les troncatures et les limites méthodologiques, à la fois dans l'interface et dans l'en-tête des exports. Une analyse partielle n'est jamais présentée comme complète.

• Langage et typage. L'application est écrite en TypeScript en mode strict ; la compilation échoue en cas d'erreur de typage. Les frontières (réponses REST, enregistrements stockés, charges utiles des resolvers) sont explicitement typées et validées.
• Tests automatisés. Une suite de tests unitaires et d'intégration couvre le moteur de résolution des permissions, la couche de stockage, le comportement en concurrence, la génération des exports et les contrats d'autorisation ; elle s'exécute à chaque modification. Les primitives de la plateforme sont simulées de façon à modéliser ses refus, et pas seulement son chemin nominal, afin que les tests ne valident pas un comportement que le runtime réel refuserait.
• Revue de code adverse obligatoire. Aucune modification n'atteint la branche de publication sans avoir passé une revue adverse indépendante, menée avec pour consigne de présumer le code défaillant et d'y traquer les conditions de course, les cas limites, les failles d'autorisation, les injections et les mauvais usages de la plateforme. Les constats doivent être corrigés, ou explicitement écartés avec une justification écrite, avant fusion. Toute modification du manifeste (modules, habilitations, flux sortants) déclenche systématiquement ce contrôle.
• Audit de sécurité avant publication. Avant sa publication sur le Marketplace, l'application a fait l'objet d'un audit adverse complet sur l'ensemble de ses sous-systèmes (moteur d'analyse, stockage, autorisation, exports, interface, surface de conformité), chaque constat étant revérifié dans le code. Tous les constats classés HIGH ont été corrigés avant soumission ; les éléments restants font l'objet d'un suivi jusqu'à clôture dans une feuille de route de remédiation publiée en interne.
• Moindre privilège par la revue. Tout ajout d'habilitation doit être justifié par l'exigence d'un point d'accès précis et est réexaminé à chaque version.
• Gestion des dépendances. Les dépendances d'exécution sont volontairement minimales : les paquets Forge d'Atlassian eux-mêmes, plus le framework d'interface. Les dépendances sont revues et mises à jour à chaque version et en réaction aux avis de sécurité ; la version du runtime Forge est maintenue sur une version encore supportée.
• Gestion des sources et intégrité. L'intégralité du code source est conservée dans un dépôt privé sous gestion de version, avec l'historique complet. Chaque version publiée est traçable jusqu'à un commit précis. Le déploiement en production est une action manuelle et authentifiée, effectuée par le responsable nommé via la CLI Atlassian Forge.
• Aucun secret dans l'application. L'application n'a besoin d'aucune clé d'API, d'aucun jeton ni d'aucun identifiant propre ; elle s'authentifie auprès de Jira exclusivement via l'authentification applicative gérée par la plateforme Forge. Il n'y a aucun secret à fuiter, à faire tourner ou à coder en dur.

4.1 Comment signaler une vulnérabilité

Signalez toute vulnérabilité suspectée à security@sr-consulting.fr.

Merci d'y préciser : l'application et la version concernées, une description du problème, les étapes ou la preuve de concept permettant de le reproduire, ainsi que l'impact que vous lui attribuez. Vous pouvez également passer par les programmes Marketplace Security Bug Bounty et de divulgation de vulnérabilités d'Atlassian, qui nous transmettent les constats via le projet Atlassian Marketplace Security (AMS).

Nous demandons aux personnes qui signalent une faille de pratiquer une divulgation coordonnée : nous laisser un délai raisonnable pour corriger avant toute publication, ne pas accéder aux données de tiers, ne pas les modifier ni les exfiltrer, et ne dégrader le service d'aucun client pendant les tests. Nous n'engagerons aucune action en justice contre les chercheurs qui signalent de bonne foi dans ce cadre.

4.2 Nos engagements envers les personnes qui signalent

4.3 Délais de remédiation

Nous corrigeons les vulnérabilités confirmées dans les délais de la Security Bug Fix Policy d'Atlassian pour les applications du Marketplace (applications cloud), ou plus rapidement :

Parce qu'il s'agit d'une application cloud Forge, les clients n'ont aucune action à effectuer pour recevoir un correctif de sécurité : nous déployons une nouvelle version majeure dans l'environnement de production d'Atlassian, que la plateforme diffuse ensuite. Aucun client ne reste sur une version vulnérable pendant qu'une mise à jour attend dans son backlog.

4.4 Évaluation continue

• L'application est soumise à la revue de sécurité d'approbation des applications d'Atlassian ainsi qu'à EcoScanner, l'analyse automatisée des applications du Marketplace par Atlassian ; les constats remontés dans le projet AMS sont traités selon les engagements ci-dessus.
• Nous maintenons un contact sécurité nommé dans l'Atlassian Marketplace Partner Portal, afin qu'Atlassian et les chercheurs puissent toujours joindre une personne.
• Nous suivons les avis de sécurité et le changelog de la plateforme Forge d'Atlassian et réagissons aux dépréciations et aux évolutions de sécurité de la plateforme dans le cadre de la maintenance courante.
• Nous ne commanditons pas à ce jour de test d'intrusion indépendant réalisé par un tiers. L'application s'exécutant intégralement sur une infrastructure opérée par Atlassian, sans surface d'attaque côté éditeur, notre assurance repose sur le modèle de sécurité de la plateforme Forge, sur la revue et l'analyse effectuées par Atlassian, sur la revue de code adverse obligatoire et sur l'audit préalable à la publication décrit plus haut.

5.1 Ce qui constitue un incident

Tout événement confirmé ou suspecté portant atteinte à la confidentialité, à l'intégrité ou à la disponibilité des données client traitées par l'application, ou des systèmes et comptes servant à la développer, la publier et la déployer — y compris la compromission du compte partenaire Atlassian ou du compte Forge du développeur.

5.2 Processus

1. Détecter et déclarer. Un incident peut être révélé par un signalement client, un chercheur, Atlassian ou notre propre surveillance. Tout signalement crédible est traité comme un incident jusqu'à ce qu'il soit écarté.
2. Investiguer. Établir la cause racine, déterminer si des données ont été consultées ou exfiltrées, quels clients sont concernés et sur quelle période.
3. Contenir. Appliquer la mesure de confinement efficace la plus rapide — ce qui peut inclure la révocation d'identifiants, le retour arrière ou le retrait d'une version déployée, ou la demande de retrait temporaire de l'application du Marketplace.
4. Notifier Atlassian. Nous ouvrons un ticket P1 auprès d'Atlassian sans délai et au plus tard sous 24 heures après avoir eu connaissance d'un incident de sécurité, conformément aux app security incident management guidelines d'Atlassian, et nous maintenons le contact avec des points de remédiation au moins toutes les 6 heures tant que l'incident est actif.
5. Notifier les clients. Les clients concernés sont informés sous 72 heures après confirmation : ce qui s'est passé, quelles données étaient concernées, ce que nous avons fait et ce qu'ils doivent faire, le cas échéant. Lorsque le RGPD s'applique, SR Consulting satisfait également à ses obligations de responsable de traitement ou de sous-traitant en matière de notification à l'autorité de contrôle compétente (art. 33) et aux personnes concernées (art. 34).
6. Remédier. Publier le correctif ainsi que les mesures qui préviennent une récidive.
7. Revoir. Conduire une revue post-incident et mettre à jour en conséquence la présente politique, le code et le processus.

5.3 Contacts en cas d'incident

• Contact sécurité : security@sr-consulting.fr
• Contact général : contact@sr-consulting.fr
• Les contacts d'incident de sécurité principal et secondaire (e-mail et téléphone) sont tenus à jour dans l'Atlassian Marketplace Partner Portal, comme l'exige le Marketplace Partner Agreement.

Nous nous efforçons d'accuser réception des signalements de sécurité entrants sous un jour ouvré et de répondre aux communications d'Atlassian pendant un incident actif dans les délais indiqués ci-dessus.

SR Consulting est une entreprise individuelle française. L'application est développée et publiée par une seule personne, nommément identifiée ; aucun autre salarié, prestataire ou équipe offshore n'y a accès.

• Aucun accès permanent aux données client. Nous ne pouvons pas lire vos données Jira. L'application fonctionne sous l'authentification applicative d'Atlassian au sein de votre tenant ; il n'existe ni console éditeur, ni porte dérobée de support, ni mécanisme nous permettant d'extraire vos données de permissions de votre site. Les seules données dont nous disposons pour le support sont celles que vous choisissez de nous transmettre.
• Sécurité des comptes. Les comptes servant à développer, déployer et publier l'application — compte développeur/partenaire Atlassian, hébergeur du code source et domaine de messagerie — sont protégés par une authentification multifacteur et des identifiants uniques à forte entropie, conservés dans un gestionnaire de mots de passe.
• Sécurité du poste de travail. La machine de développement utilise le chiffrement intégral du disque, un verrouillage automatique de session, un système d'exploitation activement maintenu avec ses mises à jour de sécurité appliquées, et le pare-feu du système activé.
• Autorisation de déploiement. Le déploiement en production et la publication sur le Marketplace exigent un accès authentifié au compte développeur Atlassian et ne sont effectués que par le responsable.
• Moindre privilège et fin d'accès. Aucun accès tiers n'est accordé. Si cela devait changer, l'accès serait limité au strict nécessaire et révoqué à l'issue de la mission, et la présente politique serait mise à jour.
• Traitement des données de support. Les échanges de support se font par e-mail. Nous demandons aux clients de ne pas transmettre d'exports de permissions, de listes d'utilisateurs ni d'autres données de production dans leurs demandes de support ; lorsqu'un client choisit malgré tout d'envoyer un export, celui-ci sert uniquement à traiter sa demande et est supprimé ensuite.

• La disponibilité de l'application dépend de la plateforme Atlassian Forge ; aucun service côté éditeur ne peut tomber indépendamment. L'état de la plateforme est publié sur status.atlassian.com.
• Les données client résident dans votre tenant Atlassian et sont couvertes par les garanties de sauvegarde et de durabilité d'Atlassian. N'en détenant aucune copie, nous n'avons rien à perdre et n'effectuons donc aucune sauvegarde distincte de vos données.
• Continuité de l'application elle-même. Le code source complet est conservé sous gestion de version avec l'historique intégral : l'application peut être reconstruite, corrigée et redéployée à partir des sources. Si SR Consulting devait un jour ne plus être en mesure de maintenir l'application, les clients en seraient informés via la fiche Marketplace et par e-mail afin de pouvoir la désinstaller sereinement ; la désinstallation supprime toutes les données stockées par l'application et laisse votre configuration Jira intacte, puisque l'application ne l'a jamais modifiée.

• Sous-traitants : aucun. Atlassian est l'unique sous-traitant et hébergeur des données de l'application. Aucun sous-traitant d'analytique, d'hébergement, d'IA ou d'outillage de support ne reçoit de données client. Si cela devait changer, l'information serait publiée ici et dans la politique de confidentialité avant l'entrée en vigueur du changement.
• Résidence des données. Le stockage reposant sur le Forge KVS, les données de l'application suivent les règles de résidence appliquées au site Atlassian du client.
• RGPD. SR Consulting est établie en France et opère sous le régime du RGPD. L'application implémente l'API Personal Data Reporting d'Atlassian, de sorte que les demandes de reporting et d'effacement de données personnelles relayées par Atlassian sont honorées en continu, indépendamment du statut de facturation. Les demandes d'exercice de droits peuvent être adressées via la page de support ou à contact@sr-consulting.fr. Voir la politique de confidentialité pour le détail complet.
• Certifications. SR Consulting ne détient pas elle-même de certification SOC 2 ou ISO 27001 — nous le disons clairement plutôt que de laisser entendre le contraire. L'infrastructure sur laquelle s'exécute l'application est celle d'Atlassian, couverte par le programme de conformité d'Atlassian (SOC 2, ISO 27001, ISO 27018 et autres). Les clients qui utilisent Canopy comme élément de preuve dans leurs propres revues d'accès SOC 2, ISO 27001 ou RGPD s'appuient sur les exports de l'application et sur les mesures sous-jacentes d'Atlassian.

Un point mérite d'être souligné : les exports CSV de l'application quittent le périmètre Atlassian dès qu'un administrateur les télécharge. Un export est un document sensible : il décrit qui peut faire quoi sur l'ensemble de votre site. Stockez-le, transmettez-le et conservez-le selon vos propres règles de classification et de rétention, comme tout autre élément de preuve de revue d'accès.

Toute modification substantielle de la présente politique est publiée ici avec une date de « dernière mise à jour » actualisée. Les changements affectant la posture de sécurité de l'application — une nouvelle habilitation, l'introduction d'un flux sortant ou le recours à un sous-traitant — sont en outre signalés sur la fiche Marketplace et dans les notes de version de l'application.

Une question, un signalement de sécurité ou un questionnaire de sécurité à remplir ? Écrivez à security@sr-consulting.fr.