Politique de sécurité et réponse aux incidents d'Impediment Ledger for Jira

Dernière mise à jour : 2026-10-12

1. Champ d'application

La présente politique couvre l'application Atlassian Forge Impediment Ledger for Jira (l'« Application ») ainsi que les comptes, le poste de travail et les dépôts utilisés pour la développer et la publier. Elle est tenue à jour par PR Flow, nom commercial d'Árpád Kozma, entrepreneur individuel (egyéni vállalkozó) (l'« Éditeur », « nous »).

PR Flow est une entreprise d'une seule personne. Cette politique décrit les mesures réellement en place et les étapes que nous suivons en cas de problème. Elle a été adoptée le 2026-10-13 et est revue au moins une fois par an ainsi qu'après chaque incident de sécurité.

Le traitement des données par l'Application est décrit dans l'avis de confidentialité ; les obligations de sécurité envers les clients figurent à la section 11 du Contrat de licence utilisateur final.

La présente politique est rédigée en anglais, et la version anglaise prévaut. Les traductions sont fournies uniquement pour des raisons de commodité.

2. Signaler une vulnérabilité

Merci de signaler les vulnérabilités en privé à [email protected] plutôt que sur un canal public. C'est aussi le contact de sécurité indiqué sur la fiche Marketplace de l'Application.

3. Comptes et accès

  • Chaque compte utilisé pour l'Application est protégé par une authentification multifacteur : GitHub, Google Workspace, le compte Atlassian et le compte d'hébergement du site web.
  • Les mots de passe sont uniques et conservés dans un gestionnaire de mots de passe.
  • Seul le propriétaire a accès au code source, à l'application Forge, au Developer Space et au compte partenaire Marketplace. Les accès sont revus chaque trimestre (contributeurs, membres du Developer Space, collaborateurs GitHub et jetons de déploiement) et tout ce qui n'est pas nécessaire est supprimé.
  • Le jeton de déploiement Forge est conservé uniquement dans un environnement GitHub protégé. Il est renouvelé une fois par an, ou immédiatement en cas de soupçon d'exposition.

4. Poste de travail

  • Le poste de développement utilise le chiffrement intégral du disque, les mises à jour automatiques du système d'exploitation et des applications, et une protection contre les logiciels malveillants.
  • Aucune version de système d'exploitation non prise en charge n'est utilisée pour le développement ou le déploiement.

5. Développement et gestion des changements

  • Chaque modification passe, avant d'être poussée, les vérifications de types, le lint (y compris des règles de sécurité et de détection de secrets), les suites de tests unitaires, basés sur les propriétés et système, ainsi qu'un audit des dépendances. Les vérifications plus longues (tests approfondis, exécution complète des tests de mutation, audits) sont lancées avant chaque version.
  • Les déploiements en production se font uniquement depuis une étiquette de version sur la branche principale, via un workflow de déploiement automatisé.
  • Le OWASP Top 10 et l'OWASP Application Security Verification Standard (ASVS) 5.0 servent de référence au modèle de menaces de l'Application.
  • Les dépendances sont installées uniquement depuis un fichier de verrouillage, avec un âge minimal de publication pour les nouveaux paquets. Les mises à jour sont gérées par Renovate et Dependabot, la CI échoue en cas de vulnérabilité connue de gravité élevée ou supérieure dans les dépendances livrées avec l'Application, et chaque version dispose d'une nomenclature logicielle (SBOM) CycloneDX.
  • L'Application n'a besoin d'aucun secret propre ; aucun n'est stocké dans le code ou le dépôt.

6. Données

  • L'Application fonctionne sur Atlassian Forge sans aucun trafic sortant externe (external egress). Les données des clients restent dans le stockage Forge hébergé du site Atlassian du client ; l'Éditeur n'y a pas accès.
  • Les actions d'un utilisateur dans l'Application s'exécutent avec ses propres permissions Jira, et chaque résultat qui lui est présenté est filtré selon ce qu'il est autorisé à consulter.
  • Les journaux ne contiennent ni données personnelles, ni identifiants, ni jetons ; seuls des champs structurés autorisés sont journalisés.
  • Le code source et son historique sont conservés sur GitHub ; l'Application peut être reconstruite et redéployée à partir de n'importe quelle étiquette de version.

7. Réponse aux incidents

Nous suivons les app security incident management guidelines d'Atlassian :

  • Détecter et consigner. Noter ce qui a été observé, quand, et ce qui peut être concerné (l'Application, les comptes, les jetons, les sites clients).
  • Contenir. Révoquer ou renouveler les jetons et mots de passe exposés, désactiver la fonction concernée ou revenir à la dernière version saine, et suspendre les déploiements jusqu'à ce que la cause soit connue.
  • Notifier. Informer Atlassian via le portail de support Developer and Marketplace dans les 48 heures suivant la prise de connaissance d'un incident affectant des clients ou leurs données, et informer les clients concernés dans les meilleurs délais, à l'aide du modèle de communication d'incident d'Atlassian.
  • Corriger et vérifier. Corriger la cause, ajouter un test de non-régression et publier en passant par les vérifications habituelles.
  • Analyser. Consigner ce qui s'est passé et ce qui change, et mettre à jour la présente politique.

Le plan est déroulé une fois par an sous forme d'exercice sur table, avec comme scénarios un jeton exposé et un signalement de vulnérabilité.

8. Continuité

  • L'Application fonctionne sur Atlassian Forge ; il n'y a aucun serveur PR Flow à restaurer.
  • En cas de perte du poste de travail, le code est restauré depuis GitHub, les comptes sont récupérés grâce aux codes de récupération multifacteur conservés hors ligne, et le jeton de déploiement est renouvelé.

9. Contact

Signalements de sécurité : [email protected]. Autres questions : support.