Close

Politique de correction des bugs de sécurité

Atlassian s'efforce (en priorité) de garantir que les systèmes des clients ne puissent pas être compromis en exploitant des failles dans les produits Atlassian.


Champ d'application

Les sections suivantes décrivent comment et à quel moment nous résolvons les bugs de sécurité dans nos produits. Elles n'expliquent pas l'intégralité du processus de divulgation ou de conseil que nous suivons.

Accord de niveau de service (SLA) sur la correction des bugs de sécurité

Nous avons défini les délais suivants pour corriger les problèmes de sécurité dans nos produits :

  • Bugs de sécurité critiques (score CVSS v2 >= 8, score CVSS v3 >= 9) à corriger dans les produits dans un délai de 4 semaines après leur signalement
  • Bugs de sécurité de criticité élevée (score CVSS v2 >= 6, score CVSS v3 >= 7) à corriger dans les produits dans un délai de 6 semaines après leur signalement
  • Bugs de sécurité de criticité moyenne (score CVSS v2 >= 3, score CVSS v3 >= 4) à corriger dans les produits dans un délai de 8 semaines après leur signalement

Vulnérabilités critiques

Lorsqu'une faille de sécurité critique est identifiée par Atlassian ou signalée par un tiers, Atlassian réalisera les tâches suivantes :

  • Publier une nouvelle version corrigée pour la version actuelle du produit affecté dès que possible.
  • Publier une nouvelle version de maintenance pour une version précédente comme suit :
Produit
Politique de rétroportage
Exemple

Jira Software Server et Data Center

Jira Core Server et Data Center

Jira Service Desk Server et Data Center

Publier de nouvelles versions de correction de bug pour :

  • toutes les versions désignées comme une version Enterprise qui n'ont pas encore atteint leur fin de vie ;
  • toutes les versions de fonctionnalités (p. ex., 7.1, 7.2) livrées dans un délai de 6 mois avant la date de publication de la correction.
Par exemple, si une correction de bug de sécurité critique est développée le 1er décembre 2017, les nouvelles versions de correction de bug suivantes devront être produites :
  • Jira 7.6.x, car il s'agit de la version actuelle
  • Jira 7.5.x, car la version 7.5.0 a été livrée le 6 septembre 2017
  • Jira 7.4.x, car la version 7.4.0 a été livrée le 29 juin 2017

Par exemple, si la version 7.1 a été désignée comme une version Enterprise, elle obtiendrait également la correction, car elle n'a pas encore atteint sa fin de vie à cette date.

Confluence Server et Data Center

Publier de nouvelles versions de correction de bug pour :

  • toute version désignée comme une version Enterprise qui n'a pas encore atteint sa fin de vie ;

  • toutes les versions de fonctionnalités livrées dans un délai de 6 mois avant la date de publication de la correction.

Par exemple, si une correction de bug de sécurité critique est développée le 1er décembre 2017, les nouvelles versions de correction de bug suivantes devront être produites :
  • Confluence 6.6.x, car il s'agit de la version actuelle

  • Confluence 6.5.x, car la version 6.5.0 a été livrée le 1er novembre 2017

  • Confluence 6.4.x, car la version 6.4.0 a été livrée le 6 septembre 2017

  • Confluence 6.3.x, car la version 6.3.0 a été livrée le 12 juillet 2017

  • Confluence 6.2.x, car la version 6.2.0 a été livrée le 15 mai 2017

Par exemple, si la version 5.10 a été désignée comme une version Enterprise, elle devra également recevoir la correction, car elle n'a pas encore atteint sa fin de vie à cette date.

Bitbucket Server et Data Center Publier de nouvelles versions de correction de bug pour toutes les versions de fonctionnalités livrées dans un délai de 6 mois avant la date de publication de la correction.

Par exemple, si une correction de bug de sécurité critique est développée le 1er décembre 2017, les nouvelles versions de correction de bug suivantes devront être produites :

  • Bitbucket 5.6.x, car il s'agit de la version actuelle

  • Bitbucket 5.5.x, car la version 5.5.0 a été livrée le 24 octobre 2017

  • Bitbucket 5.4.x, car la version 5.4.0 a été livrée le 19 septembre 2017

  • Bitbucket 5.3.x, car la version 5.3.0 a été livrée le 15 août 2017

  • Bitbucket 5.2.x, car la version 5.2.0 a été livrée le 11 juillet 2017

  • Bitbucket 5.1.x, car la version 5.1.0 a été livrée le 6 juin 2017

  • Bitbucket 5.0.x, car la version 5.0.0 a été livrée le 2 mai 2017

Tous les autres produits (Bamboo, CrucibleFisheye, etc) Nous ne publierons de nouvelles versions de correction de bug que pour les versions de fonctionnalités actuelle et précédente. Par exemple, si une correction de bug de sécurité critique est développée le 1er décembre 2017 pour Bamboo, les nouvelles versions de correction de bug suivantes devront être produites :
  • Bamboo 6.2.x, car il s'agit de la version actuelle
  • Bamboo 6.1.x, car la version 6.1.x est la précédente

Il est important d'installer la dernière version de correction de bug pour la version du produit que vous utilisez (c'est une bonne pratique). Par exemple, si vous utilisez Jira Software 7.5.0, vous devriez passer à Jira Software 7.5.3 de façon proactive. Si une nouvelle correction de bug de sécurité est livrée, par exemple Jira Software 7.5.4, le delta entre les deux versions est minime (c.-à-d. uniquement la correction de sécurité), ce qui la rend plus facile à appliquer. 

Le processus de résolution des vulnérabilités critiques ne s'applique pas aux produits Atlassian Cloud, car ces services sont toujours corrigés par Atlassian sans action supplémentaire de la part des clients.

 

Vulnérabilités non critiques

Lorsqu'un problème de sécurité de criticité élevée, moyenne ou faible est identifié, Atlassian inclut une correction dans la prochaine version planifiée. La correction peut donc être rétroportée aux versions Enterprise, le cas échéant. 

Vous devriez mettre à niveau vos installations lorsqu'une version de correction de bug est mise à disposition pour vous assurer que les dernières corrections de sécurité ont été appliquées.

 

Autres informations

Le degré de gravité des vulnérabilités est calculé en fonction des niveaux de gravité des problèmes de sécurité.

Nous évaluons en permanence nos politiques en fonction des commentaires des clients, et nous indiquerons toute mise à jour ou tout changement sur cette page. 

 

FAQ

Qu'est-ce qu'une « version Enterprise » ?

Les versions Enterprise s'adressent aux clients Data Center qui préfèrent s'accorder plus de temps pour se préparer aux mises à niveau vers de nouvelles versions futures, mais doivent tout de même recevoir les corrections de bug. Certains produits seront désignés comme une version donnée d'une version Enterprise, ce qui signifie que les corrections de bug de sécurité seront mises à disposition pour l'intégralité des deux années de support.

Qu'est-ce qu'une « version de fonctionnalités » ?

Une version de fonctionnalités est une version (par exemple, 4.3) qui contient de nouvelles fonctionnalités ou qui apporte des changements majeurs aux fonctionnalités existantes et qui n'a pas été désignée comme une version Enterprise. Pour en savoir plus sur notre terminologie relative aux versions, consultez la politique de correction des bugs Atlassian.

Pourquoi couvrez-vous seulement une période de 6 mois pour les versions de fonctionnalités de Bitbucket, Jira et Confluence ?

La livraison de versions pour Bitbucket Server est très fréquente. Par conséquent, cette période de 6 mois couvre cinq à six versions majeures. Depuis la mi-2017, Jira et Confluence sont passés à une cadence de livraison similaire, et cinq à six versions sont désormais livrées chaque année. 

Pourquoi les autres produits comme Bamboo et Fisheye/Crucible sont-ils uniquement rétroportés jusqu'à la version majeure précédente ?

Nos efforts se concentrent sur Jira, Confluence et Bitbucket Server, mais nous pourrions envisager de les étendre à Bamboo, Fisheye/Crucible et d'autres produits afin de couvrir des versions majeures supplémentaires en fonction de la demande.