Politique de sécurité
SPHIOR Ledger for Jira
Cette Politique de sécurité décrit comment SPHIOR (« nous ») sécurise SPHIOR Ledger for Jira (l'« Application ») et les systèmes qui soutiennent son développement et son exploitation. Pour la manière dont nous traitons les données, consultez notre Politique de confidentialité à l'adresse https://ledger.sphior.com/privacy.
1. Architecture et protection des données
SPHIOR Ledger est bâtie sur Atlassian Forge et est éligible au programme Runs on Atlassian. · Zéro egress réseau sortant. Le manifest de l'Application ne déclare aucun hôte externe ; tout le traitement a lieu dans le runtime Forge géré par Atlassian. · Stockage isolé par tenant. Toutes les données persistantes résident dans Forge Storage (per-install SQL), à l'intérieur de votre tenant Atlassian. Nous n'exploitons aucune base de données externe, log shipper ni endpoint d'analytics. · Aucun sous-traitant tiers. L'Application n'en a aucun. · Chiffrement en transit : TLS 1.2+ pour chaque appel API, imposé par la plateforme Forge d'Atlassian. · Chiffrement au repos : Forge Storage est chiffré par Atlassian. Voir le Trust Centre d'Atlassian à https://www.atlassian.com/trust pour les contrôles au niveau plateforme.
2. Registre infalsifiable
Le registre d'audit propre à l'Application est protégé par une chaîne de hachages SHA-256. Chaque snapshot référence le hachage de l'enregistrement précédent ; toute édition silencieuse du registre brise la chaîne et est exposée dans le vérificateur d'intégrité in-app. Les clients peuvent vérifier indépendamment le contenu d'un pack via les signatures incluses dans chaque evidence pack exporté.
3. Gestion des vulnérabilités et développement sécurisé
· Analyse de sécurité automatisée. L'audit de sécurité web (DAST/SAST/SCA authentifié) étant le cœur de métier de SPHIOR, nous exécutons régulièrement du SAST (analyse statique du code), du SCA (analyse des dépendances / composants open source) et du DAST authentifié contre les surfaces accessibles de l'Application (au moins chaque trimestre et avant chaque release significative). · Software bill of materials (SBOM). Les dépendances sont épinglées via des lockfiles ; un SBOM est maintenu et revu à chaque release. · Délais de remédiation. Les découvertes issues des analyses sont triées et corrigées selon des délais définis, alignés sur la Atlassian Marketplace Security Bug Fix Policy (les problèmes critiques sont priorisés pour la release la plus précoce possible). · Patching du runtime. Le runtime Forge, le moteur Forge SQL et Forge Storage sont maintenus par Atlassian ; nous adoptons rapidement les mises à jour de runtime recommandées par Atlassian et n'exécutons aucune version de runtime non supportée. · Analyse statique et revue. TypeScript en mode strict, ESLint et forge lint sont exécutés à chaque commit ; les changements sont revus par les pairs avant le merge sur la branche main. · Aucun secret dans la source. Les dépôts ne contiennent ni identifiants, ni tokens, ni secrets partagés ; l'Application ne demande aucun PAT ni mot de passe utilisateur, et Forge gère tous les tokens de plateforme. · Tests de pénétration. Nous réalisons des tests de sécurité authentifiés en interne ; un test de pénétration indépendant par un tiers est dans notre roadmap.
4. Réponse aux incidents de sécurité
En cas d'incident de sécurité confirmé affectant l'Application : 1. Le tri est initié dans les 24 heures suivant la confirmation. 2. Une notification client est envoyée par email à l'adresse contact-for-security-issues enregistrée pour les installations affectées, dans les 72 heures suivant la confirmation d'un impact matériel, alignée sur les attentes de l'Article 33 du RGPD. 3. Une analyse des causes profondes est menée et un plan de remédiation est préparé. Les correctifs impactant les clients sont publiés sur Atlassian Marketplace via le pipeline de mise à jour standard. 4. Un rapport post-incident est partagé avec les clients affectés et résumé publiquement sur cette page lorsque pertinent. Les événements de sécurité suspects peuvent être signalés à security@sphior.com à tout moment. Nous accusons réception sous 1 jour ouvré.
5. Contrôles d'accès (interne)
· Moindre privilège. L'accès aux dépôts source, à l'Atlassian Developer Console et au déploiement en production est restreint aux mainteneurs de l'Application selon le principe du besoin d'en connaître. Nous n'utilisons aucun compte partagé ni identifiant de production partagé. · Dépôt source. La branche main est protégée par des status checks requis (TypeScript, lint et tests doivent passer avant le merge). · Developer Console. L'accès est restreint au compte publisher (founder@sphior.com) et utilise l'authentification au niveau du compte Atlassian avec l'authentification multifacteur (MFA) activée. · Authentification multifacteur. Le MFA est imposé sur tous les comptes ayant accès au code source, à la Developer Console et aux outils de déploiement. · Revue d'accès périodique. La liste des comptes ayant accès aux systèmes de développement et de déploiement est revue au moins chaque trimestre, et les accès sont révoqués sans délai dès qu'ils ne sont plus nécessaires. · Le déploiement en production est effectué via l'Atlassian Forge CLI ; aucun identifiant de production partagé n'est utilisé.
6. Conformité et certifications
État de conformité : · Obligations de Data Processor RGPD : adoptées (voir Politique de confidentialité §10). · Obligations de Service Provider CCPA : adoptées (pas de vente d'informations personnelles ; traitement limité aux fins commerciales). · Programme Runs on Atlassian : éligible. · SOC 2 Type II : roadmap (post-lancement). · ISO 27001 : roadmap (post-lancement). · HIPAA : non certifiée — l'Application n'est pas destinée au stockage de PHI. Nous ne détenons pas actuellement de certifications SOC 2 ou ISO 27001. L'éligibilité de l'Application au programme Runs on Atlassian hérite des certifications au niveau plateforme d'Atlassian pour l'infrastructure sous-jacente ; les clients nécessitant nos propres certifications peuvent nous contacter au sujet du calendrier roadmap.
7. Divulgation responsable
Nous accueillons favorablement la recherche en sécurité sur l'Application. Veuillez signaler les découvertes en privé à security@sphior.com en incluant : · Une description du problème · Les étapes de reproduction · Une évaluation de l'impact · Toute mitigation suggérée Nous nous engageons à : · Accuser réception de votre signalement sous 1 jour ouvré · Fournir une décision initiale de tri sous 5 jours ouvrés · Ne pas engager de poursuites légales contre les chercheurs de bonne foi qui suivent cette politique La participation au Atlassian Marketplace Security Bug Bounty Program est un élément roadmap ; jusqu'à notre inscription, veuillez divulguer directement auprès de nous.
8. Contrôles de sécurité côté client
L'Application est administrée via l'interface admin existante de Jira et hérite de l'authentification, de l'autorisation et de l'audit-log de Jira. Nous recommandons vivement : · Restreindre les permissions admin Jira à un ensemble minimal de personnes de confiance. · Activer l'authentification à deux facteurs sur tous les comptes Atlassian. · Revoir périodiquement la table Recent activity in-app pour confirmer que le pipeline snapshots fonctionne comme prévu. · Générer et archiver des evidence packs dans le cadre de votre routine d'audit — les packs contiennent des signatures indépendantes vérifiables hors de l'Application.
9. Sécurité des postes de travail et des développeurs
· Chiffrement intégral du disque. Les postes de travail de développement utilisent le chiffrement intégral du disque (par ex. FileVault). · Verrouillage de l'écran et MFA. Les postes se verrouillent automatiquement en cas d'inactivité et exigent une authentification ; l'accès aux comptes requiert le MFA. · Patching. Les systèmes d'exploitation et les outils de développement sont maintenus à jour avec les mises à jour de sécurité des éditeurs. · Protection des endpoints. Les postes de travail exécutent une protection anti-malware d'endpoint supportée par l'éditeur. · Hygiène des identifiants. Les secrets et tokens ne sont jamais committés dans le contrôle de version ; les tokens de plateforme sont gérés par Forge.
10. Journalisation et surveillance
· Logs de la plateforme Forge. Les logs d'exécution de l'Application sont accessibles via la plateforme Atlassian Forge (forge logs) et la Developer Console ; nous ne transférons aucun log vers un système externe. · Aucune donnée client dans les logs. La journalisation de l'Application est conçue pour éviter d'enregistrer des données personnelles ou la configuration brute du client ; les identifiants sont minimisés. · Observabilité in-app. L'Application expose son propre état opérationnel — taux de réussite des captures, intégrité de la chaîne de hachages et activité récente — directement dans l'interface admin, afin que les administrateurs puissent confirmer le bon fonctionnement sans outillage externe.
11. Continuité d'activité et reprise après sinistre
· Durabilité assurée par la plateforme. Les données persistantes résident dans Forge Storage géré par Atlassian, qui hérite des contrôles de sauvegarde, de réplication et de durabilité au niveau plateforme d'Atlassian. Voir le Trust Centre d'Atlassian à https://www.atlassian.com/trust. · Aucune infrastructure distincte. Comme l'Application s'exécute entièrement à l'intérieur du runtime Forge, il n'existe aucun serveur, base de données ni service exploité par SPHIOR susceptible de tomber en panne indépendamment de la plateforme Atlassian. · Récupérabilité de la source. La source de l'Application est versionnée et peut être redéployée sur l'Atlassian Marketplace via le pipeline de publication standard. · Export côté client. Les administrateurs peuvent générer et archiver des evidence packs à tout moment, fournissant une copie du registre vérifiable indépendamment en dehors de l'Application.
12. Intelligence artificielle
SPHIOR Ledger n'utilise aucune intelligence artificielle ni modèle de machine learning dans ses fonctionnalités principales. La capture de configuration, le calcul des diffs, le chaînage de hachages, l'attribution et le mapping de conformité sont entièrement déterministes. Aucune donnée client n'est envoyée à un service d'IA/ML — conformément à l'architecture zéro egress de l'Application.
13. Revue et communication de la politique
Cette Politique de sécurité ainsi que nos pratiques de sécurité internes sont revues au moins une fois par an, et à chaque changement significatif de l'Application ou de son environnement d'exploitation. Les pratiques pertinentes sont communiquées à tout sous-traitant ou tiers impliqué dans le développement ou l'exploitation. La date de « Dernière mise à jour » ci-dessus reflète la revue la plus récente.
14. Contact
Événements de sécurité : security@sphior.com Contact général : support@sphior.com Demandes de confidentialité : voir la Politique de confidentialité à https://ledger.sphior.com/privacy
Dernière mise à jour : 2026-06-29