Aide-mémoire : 10 bonnes pratiques de sécurité pour Bitbucket

Dans cet aide-mémoire, nous vous expliquons comment renforcer votre sécurité en tant qu’utilisateur ou contributeur Bitbucket. Certains conseils sont propres à Bitbucket, mais beaucoup s’appliquent aussi à d’autres dépôts Git ou non-Git.

Télécharger l’aide-mémoire

Commençons par notre liste de 10 bonnes pratiques de sécurité pour Bitbucket, en commençant par l’erreur classique qui consiste à ajouter ses mots de passe aux dépôts Bitbucket !

1. Ne stockez jamais d’identifiants dans le code ou la configuration de Bitbucket

Il existe d’excellents outils, comme git-secrets, qui analysent statiquement vos commits via un hook Git pre-commit afin de vérifier que vous n’essayez pas d’envoyer des mots de passe ou des informations sensibles dans votre dépôt Bitbucket. Les commits sont rejetés si l’outil détecte l’un des motifs d’expression régulière configurés, indiquant que des informations sensibles ont été stockées de manière inappropriée. Cela peut légèrement ralentir les envois, mais le jeu en vaut largement la chandelle.

Mettre en place des règles à l’échelle de l’équipe pour empêcher le stockage d’identifiants dans le code est un excellent moyen de prévenir les mauvaises pratiques dans le flux de travail existant des développeurs. En production, utilisez un outil comme Vault pour gérer vos secrets. Enfin, envisagez d’utiliser une chaîne d’outils de gestion des identités et des utilisateurs, comme Keycloak (actuellement maintenu par plusieurs développeurs de Red Hat), ou d’autres solutions.

Atlassian permet d’injecter des identifiants dans les pipelines Bitbucket au moyen de variables d’environnement. Une approche plus sûre consiste toutefois à utiliser ScriptRunner d’Adaptavist comme intergiciel pour connecter des systèmes de gestion des identifiants et de l’authentification, tels que Vault et Keycloak.

Il existe de nombreux moyens d’éviter d’ajouter des identifiants à votre dépôt dès le départ, et vous devriez en mettre en œuvre autant que possible. Il reste toutefois toujours possible que des informations sensibles s’y glissent. Pensez également à auditer régulièrement vos dépôts à l’aide d’outils comme GitRob ou truffleHog, qui analysent votre base de code à la recherche d’informations sensibles en faisant correspondre des motifs.

2. Supprimez les données sensibles de vos fichiers et de l’historique Bitbucket

Si vous trouvez des données sensibles dans votre dépôt Bitbucket, vous devez prendre plusieurs mesures pour remédier à la situation. Vous devez tout d’abord invalider les jetons et mots de passe qui ont été exposés. Dès qu’un secret est publié sur Internet, partez du principe qu’il est entre les mains d’attaquants et agissez en conséquence.

Bien sûr, vous devrez également supprimer ces mêmes données sensibles de votre dépôt. Mais n’oubliez pas que Bitbucket conserve très bien l’historique complet de tous vos commits, y compris les journaux des modifications qui contiennent vos informations sensibles. Lorsque vous supprimez des données sensibles d’un dépôt, il est important d’effacer l’historique Bitbucket. Pour en savoir plus, consultez la suppression de fichiers de l’historique de votre dépôt. Notez que, bien qu’il s’agisse d’un lien vers GitHub, ces conseils généraux s’appliquent à tous les dépôts Git et peuvent donc aussi être suivis dans Bitbucket. Vous pouvez également utiliser ScriptRunner pour simplifier ces intégrations.

3. Contrôlez rigoureusement les accès

Ici, au Royaume-Uni, quand il fait vraiment, vraiment chaud (comprenez : agréablement doux), nous, les Britanniques, avons tendance à ouvrir toutes les fenêtres de la maison pour éviter qu’elle ne se transforme en sauna. Mais lorsque nous sortons, nous verrouillons la porte d’entrée à double tour, tout en laissant souvent plusieurs fenêtres entrouvertes pour faire circuler l’air. Bien sûr, cela n’a aucun sens : quiconque voudrait s’introduire chez nous ne passerait pas par la porte d’entrée ! La personne chercherait un accès moins évident, par exemple en grimpant par l’une des fenêtres laissées opportunément ouvertes. Nous adoptons souvent la même approche pour sécuriser nos applications. Nous nous concentrons beaucoup sur les vecteurs d’attaque les plus complexes, mais échouons lamentablement face à certaines des menaces les plus simples. Il suffit par exemple qu’un seul développeur laisse son mot de passe sur un pense-bête collé à son écran pour qu’un attaquant puisse accéder au système. Nous devons veiller à respecter les paramètres et pratiques de base, sur la plateforme Bitbucket comme en général. Imposez les pratiques de base suivantes à vos contributeurs :

1. Exigez l’authentification à deux facteurs pour le compte Bitbucket de chaque contributeur.

2. Ne laissez jamais les utilisateurs Bitbucket partager des comptes ou des mots de passe.

3. Tous les ordinateurs portables et appareils ayant accès à votre code source doivent être correctement sécurisés.

4. Les administrateurs de dépôt doivent gérer les accès de l’équipe aux données. N’accordez aux contributeurs que les accès aux données nécessaires à leur travail.

5. Les comptes Bitbucket peuvent être personnels et ne sont pas automatiquement supprimés lorsque leurs utilisateurs quittent l’entreprise. Veillez à révoquer rigoureusement les accès Bitbucket des personnes qui ne travaillent plus avec vous.

Le modèle d’autorisations de branche de Bitbucket vous permet de contrôler qui peut envoyer des commits vers quelles branches.

Vous pouvez programmer une tâche ScriptRunner pour désactiver certains utilisateurs Bitbucket à une date et une heure précises, afin de leur interdire tout accès ultérieur à Bitbucket Server. Dans l’exemple ci-dessous, nous désactivons les utilisateurs User et Contractor le 17 août 2018 à 9 h. Dans la section Notes, une clé de ticket JIRA, ACCESS-1234, est indiquée pour identifier la personne qui a signalé le changement.

4. Ajoutez un fichier SECURITY.md

Il est naturel pour la plupart des propriétaires et responsables de projets d’ajouter un fichier README.md à leur dépôt. En fait, c’est devenu la norme et l’absence d’un tel fichier est assez mal perçue. De même, il est de plus en plus courant d’ajouter un fichier SECURITY.md présentant les informations de sécurité relatives au projet. Celui-ci fournit aux utilisateurs de votre projet open source les informations de sécurité importantes dont ils ont besoin, tout en incitant les responsables à réfléchir à la manière de traiter les signalements de vulnérabilités, les mises à jour et les pratiques générales de sécurité.

Voici un aperçu des thèmes à aborder dans le fichier SECURITY.md :

Politique de divulgation

Le rapport 2017 Snyk State of Open Source Security montre que seuls 21 % des responsables qui n’ont pas de politique publique de divulgation ont été informés en privé d’une vulnérabilité. Ce chiffre passe à 73 % pour les responsables qui ont une politique publique de divulgation. Cela montre combien il est important de définir la procédure permettant de signaler de manière responsable les problèmes de sécurité. Précisez notamment qui contacter et comment. C’est essentiel pour recueillir de précieux retours des utilisateurs de votre projet. S’il n’existe pas de procédure claire et simple, il est facile de renoncer à signaler un problème. D’autres pourraient publier la vulnérabilité comme un problème ouvert, la rendant ainsi connue de tous avant qu’un correctif soit disponible. Donnez aux utilisateurs de votre projet toutes les indications nécessaires pour transmettre les bonnes informations aux responsables lorsqu’ils découvrent un problème.

Politique de mise à jour de sécurité

Des vulnérabilités logicielles sont découvertes chaque jour. Lorsqu’une vulnérabilité est détectée dans votre application ou bibliothèque, vous devez en informer les utilisateurs de votre projet. Ils pourraient utiliser votre code open source en production sur des systèmes critiques. Vous devez définir un processus clair pour leur communiquer les informations utiles, notamment la gravité de la vulnérabilité, les risques associés et la façon de passer à une version corrigée de votre code. Définissez ce processus à l’avance afin que les informations soient transmises aux utilisateurs de votre projet, qui pourront être informés au plus tôt des nouvelles vulnérabilités de sécurité dès leur découverte et leur correction. Une liste de diffusion dédiée à la sécurité peut suffire. Le fichier SECURITY.md est un bon endroit pour publier ces informations dans le dépôt. Si vous avez un site Web, envisagez de créer une page dédiée : consultez par exemple la page de sécurité d’Express.js.

Configuration liée à la sécurité

La sécurité de votre projet ne dépend pas uniquement de votre code. Les utilisateurs de votre projet open source doivent probablement ajouter une configuration et créer des paramètres pour qu’il fonctionne comme prévu dans leur environnement. Fournissez-leur des paramètres recommandés pour renforcer la sécurité lors du déploiement du projet. Vous pouvez par exemple leur conseiller d’activer HTTPS, d’ajouter une couche d’autorisation et, bien sûr, de remplacer les mots de passe par défaut (voici des conseils que de nombreux utilisateurs de MongoDB auraient aimé recevoir). N’oubliez pas que de nombreux utilisateurs ont une connaissance assez limitée de la sécurité : tout conseil que vous leur donnerez leur sera donc très utile.

Failles de sécurité connues et améliorations à venir

Il faut trouver un équilibre entre fournir aux utilisateurs les informations nécessaires pour sécuriser leur environnement et donner aux attaquants des pistes d’attaque. Réfléchissez toujours à la manière dont les informations communiquées pourraient être utilisées par les uns et les autres. Rares sont les projets qui ont déjà mis en œuvre toutes les améliorations de sécurité souhaitées. Il est important d’informer les utilisateurs de votre projet des mesures de sécurité qui ne sont pas encore en place. Ils méritent de connaître toute la situation afin de prendre des décisions éclairées sur l’utilisation de votre projet. Qui sait, vous recevrez peut-être même des contributions de la part d’utilisateurs souhaitant mettre en œuvre l’une des mesures de sécurité mentionnées !

5. Intégrez des conseils de sécurité à votre flux de travail grâce à Code Insights

Code Insights est conçu pour faire remonter les informations pertinentes dans une pull request, afin que son auteur et les personnes chargées de la révision puissent prendre des décisions éclairées. Snyk propose une intégration qui analyse toutes les pull requests ouvertes pour vérifier qu’elles n’introduisent pas de nouvelles vulnérabilités open source. Elle peut également empêcher la fusion des pull requests qui contiennent de nouvelles vulnérabilités.

Si une nouvelle vulnérabilité est détectée, Snyk vous en informe et ouvre une pull request de correction, avec des mises à niveau suggérées ou des correctifs Snyk pour la corriger.

Dans l’interface des pull requests de Bitbucket, les modifications sont analysées et les résultats s’affichent sous forme d’annotations détaillées en ligne, à côté des changements à l’origine de nouveaux problèmes. Ces annotations facilitent la compréhension des résultats de l’analyse Snyk et favorisent la prise de décisions éclairées.

Pour en savoir plus sur l’installation et l’utilisation, consultez cet article de blog sur Code Insights pour Bitbucket et Snyk, qui comprend une vidéo de démonstration !

6. Évaluez soigneusement vos applications Bitbucket

Toutes les plateformes performantes peuvent être étendues, et Bitbucket ne fait pas exception avec sa marketplace d’applications. Ces applications sont développées par des organisations et des développeurs tiers : gardez-le à l’esprit lorsque vous en ajoutez à votre dépôt. Tenez compte des points suivants lorsque vous sélectionnez et installez des applications Bitbucket :

• N’accordez pas aux applications plus de droits d’accès que nécessaire.

• Demandez-vous pourquoi une application requiert le niveau d’accès demandé et réfléchissez aux dommages qu’elle pourrait causer avec ces droits.

• Avant de donner à une application accès à vos dépôts, vérifiez la légitimité et la crédibilité de son auteur ou de l’organisation qui la propose, comme vous le feriez avant d’intégrer un nouveau contributeur à votre projet.

Votre sécurité dépend de votre maillon le plus faible. Si une application à laquelle vous accordez l’accès présente un niveau de sécurité insuffisant, une compromission de son code donnera aux attaquants accès au vôtre : l’un de vos actifs les plus sensibles.

Enfin, veillez à surveiller ou à auditer régulièrement vos applications et leurs contributeurs afin de vérifier que vous en avez toujours besoin, que vous leur faites toujours confiance et que les droits demandés restent justifiés. Gérez correctement vos applications et supprimez celles dont vous n’avez plus besoin ou qui exigent des droits que vous ne souhaitez pas accorder.

7. Ajoutez des tests de sécurité aux pull requests

Bitbucket dispose d’un puissant framework de hooks Git événementiels qui vous permet d’envoyer des requêtes HTTP POST au service de votre choix lorsqu’un événement se déclenche. Vous pouvez choisir parmi un grand nombre d’événements, mais l’un des plus utiles pour tester les modifications incrémentales de votre code est l’événement pull_request. De nombreux outils d’analyse statique du code prennent en charge les hooks Git : lorsqu’une PR est créée, une requête HTTP POST est envoyée pour lancer le test de vos dernières modifications. C’est le moment idéal pour vérifier que les modifications apportées au code et à la configuration respectent vos exigences de sécurité.

Snyk, par exemple, analyse statiquement votre dépôt pour repérer les dépendances vulnérables que vous pourriez utiliser et vous aide à les corriger. Vous pouvez analyser vos dépôts depuis l’interface de Snyk pour détecter les problèmes, mais aussi empêcher les développeurs d’ajouter de nouvelles bibliothèques vulnérables en testant les pull requests et en faisant échouer le test si une nouvelle vulnérabilité a été introduite.

En plus de s’intégrer facilement à Bitbucket, les pull requests sont préférables au fait de « casser le build » : elles ne bloquent pas nécessairement une fusion (elles sont d’ailleurs informatives par défaut) et permettent de tester les modifications, pas seulement le résultat (par exemple, faire échouer le test uniquement si vous avez introduit une bibliothèque vulnérable, et non s’il y en avait déjà une).

En plus de Snyk, pensez à utiliser SonarCloud ou CodeClimate pour effectuer des revues de code de sécurité automatisées. Vous pouvez également ajouter un script ScriptRunner pour éviter d’envoyer des secrets dans votre dépôt.

8. Ajoutez des tests de sécurité dans vos pipes Bitbucket

Bitbucket Pipes vous permet de personnaliser et d’automatiser un workflow CI/CD à partir d’un ensemble de tâches prêtes à l’emploi. Snyk propose un pipe prêt à l’emploi qui analyse les dépendances de votre application et les images Docker à la recherche de vulnérabilités de sécurité connues dans l’open source, dans le cadre du workflow d’intégration et de livraison continues (CI/CD).

Pour ajouter le pipe Snyk à votre workflow, il vous suffit de le copier et de le coller dans le pipeline.

Une fois intégré au workflow Bitbucket Pipeline, le pipe Snyk analyse vos dépendances à la recherche de vulnérabilités dans l’open source, dans le cadre du workflow CI/CD. Si des vulnérabilités sont détectées, le pipe Snyk bloque le processus selon la configuration que vous avez définie. Il peut, par exemple, empêcher les vulnérabilités de gravité élevée de passer l’étape de build. Pour en savoir plus, consultez la documentation.

Un autre pipe à envisager pour renforcer votre résilience en matière de sécurité est SonarCloud.

9. Choisissez l’offre Bitbucket adaptée à vos besoins de sécurité

Selon votre projet ou les réglementations de votre organisation, vous pouvez être limité aux logiciels qui s’exécutent uniquement en local. Il se peut aussi que des restrictions s’appliquent à l’emplacement de stockage de votre code source ou aux autres organisations qui peuvent y accéder. Ces restrictions sont courantes dans les établissements financiers, les administrations et les autres secteurs fortement réglementés. Cela ne signifie toutefois pas que vous ne pouvez pas utiliser Bitbucket !

Découvrez l’offre Bitbucket Server entièrement sur site, qui vous permet d’héberger vos dépôts Bitbucket au sein de votre organisation. Vous pouvez ainsi rester déconnecté d’Internet tout en conservant un accès interne à vos projets dans vos dépôts Bitbucket Server.

10. Renouvelez vos clés SSH et vos jetons d’accès personnels

L’accès à Bitbucket se fait généralement à l’aide de clés SSH ou de jetons utilisateur personnels (à la place d’un mot de passe, car vous avez activé l’authentification à deux facteurs !). Mais que se passe-t-il si ces jetons sont volés sans que vous le sachiez ? Pensez à renouveler régulièrement vos clés et vos jetons afin de limiter les dommages causés par d’éventuelles fuites.

Pour en savoir plus sur la sécurité de Bitbucket, consultez également les avis de sécurité Bitbucket. Et si ce n’est pas déjà fait, téléchargez cette fiche pratique et affichez-la : vous prendrez ainsi des décisions plus sûres à l’avenir !