Ajouter un fichier SECURITY.md à vos dépôts Azure Repos

Cet article présente la bonne pratique n° 4 — ajouter un fichier SECURITY.md à vos dépôts — de notre série consacrée aux 8 bonnes pratiques de sécurité pour Azure Repos.

Ajouter un fichier SECURITY.md à vos dépôts Azure Repos

Il est naturel pour la plupart des responsables de projet et des responsables de maintenance d’ajouter un fichier README.md à leur dépôt. En fait, c’est aujourd’hui attendu, et l’absence d’un tel fichier est plutôt mal vue. De même, il est de plus en plus courant d’ajouter un fichier SECURITY.md qui présente les informations liées à la sécurité de votre projet. Non seulement il fournit aux utilisateurs de votre projet open source les informations de sécurité essentielles dont ils ont besoin, mais il oblige aussi les responsables de maintenance à réfléchir à la manière de gérer les signalements de vulnérabilités, les mises à jour et les bonnes pratiques générales de sécurité.

Voici un aperçu des sujets qu’il est recommandé d’aborder dans le fichier SECURITY.md :

• Politique de divulgation. Le rapport Snyk 2017 sur l’état de la sécurité open source révèle que seuls 21 % des responsables de maintenance qui n’ont pas de politique publique de divulgation ont été informés en privé d’une vulnérabilité. Ce chiffre passe à 73 % parmi ceux qui disposent d’une politique publique de divulgation. Cela montre combien il est important de définir la procédure permettant à une personne de signaler un problème et de divulguer de manière responsable des problèmes de sécurité. Il faut préciser qui contacter et comment. C’est essentiel, car cela vous permet de recueillir des commentaires importants de la part des utilisateurs de votre projet. En l’absence d’une procédure simple et clairement définie, on risque de ne pas s’en préoccuper du tout. D’autres peuvent signaler l’existence d’une vulnérabilité dans un ticket public, révélant involontairement son existence au monde entier avant qu’un correctif soit disponible. Veillez à fournir aux utilisateurs de votre projet toutes les indications nécessaires pour transmettre les bonnes informations aux responsables de maintenance lorsqu’ils découvrent des problèmes.

• 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 votre bibliothèque, vous avez la responsabilité d’en informer les utilisateurs de votre projet. Ils pourraient utiliser votre code open source en production sur des systèmes critiques. Vous devez mettre en place une procédure clairement définie pour leur communiquer les informations pertinentes, notamment la gravité de la vulnérabilité, les risques qu’elle présente et la manière de passer à une version corrigée de votre code. Définissez cette procédure à l’avance afin que les informations soient transmises aux utilisateurs de votre projet et qu’ils soient informés le plus tôt possible des nouvelles vulnérabilités de sécurité, dès leur découverte et leur correction. Cela peut être aussi simple qu’une liste de diffusion dédiée à la sécurité. Un fichier SECURITY.md est un bon endroit pour publier ces informations dans le dépôt. Si vous avez un site Web, pensez à créer une page distincte — prenez exemple sur la page de sécurité d’Express.js.

• Configuration liée à la sécurité. Les considérations de sécurité de votre projet ne se limitent pas à votre code. Les utilisateurs de votre projet open source doivent probablement ajouter des paramètres de configuration à votre projet pour qu’il fonctionne comme prévu dans leur environnement. Vous devriez leur recommander des paramètres qui renforcent leur posture de sécurité lors du déploiement du projet. Par exemple, activer HTTPS, ajouter une couche d’autorisation et, bien sûr, remplacer les mots de passe par défaut (voici des conseils que de nombreux utilisateurs de MongoDB auraient aimé recevoir). N’oubliez pas que beaucoup d’utilisateurs ont généralement une connaissance assez limitée de la sécurité : tout conseil que vous pouvez leur donner leur sera donc très utile.

• Lacunes de sécurité connues et améliorations à venir. Il faut trouver un équilibre entre fournir aux utilisateurs les informations dont ils ont besoin pour sécuriser leur environnement et donner à un attaquant des pistes pour mener ses attaques. Réfléchissez toujours à la manière dont les informations que vous partagez pourraient être utilisées par l’une ou l’autre partie. Il est très rare qu’un projet ait 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. Vos utilisateurs méritent de connaître tous les éléments pour prendre des décisions éclairées sur la façon d’utiliser votre projet. Qui sait, vous pourriez même recevoir de leur part des contributions visant à mettre en œuvre une mesure de sécurité figurant sur la liste !

Poursuivez votre lecture pour découvrir la liste des 8 bonnes pratiques de sécurité pour Azure Repos :

1. Ne stockez jamais d’identifiants sous forme de code ou de configuration dans Azure Repos

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

3. Contrôlez strictement les accès

4. Ajoutez un fichier SECURITY.md

5. Utilisez des jetons d’accès personnels

6. Attribuez aux utilisateurs des autorisations et des groupes précis

7. Ajoutez des tests de sécurité aux demandes de tirage (Pull Requests)

8. Renouvelez les clés SSH et les jetons d’accès personnels

Si ce n’est pas déjà fait, téléchargez cette fiche pratique dès maintenant et affichez-la : vos décisions futures seront ainsi plus sûres.