Gestion sécurisée des secrets
Gérer les secrets dans le SDLC
Il n'existe pas de solution miracle
Les secrets sont si largement utilisés dans les environnements DevOps qu'il ne peut tout simplement pas exister de solution universelle pour les gérer. Nous avons des secrets de développement utilisés par les développeurs, des secrets de build, des secrets d'application, des secrets d'infrastructure, etc.
Même pour les organisations ou équipes DevSecOps les plus matures, la gestion des secrets est très difficile à maîtriser, car il s'agit de trouver le juste équilibre entre sécurité et accessibilité. Ce second point est très important pour une raison simple : dans les équipes de développement modernes, tout le monde a besoin de secrets. Rendre l'utilisation des secrets difficile conduira inévitablement au contournement des couches de protection en place, et à des pratiques telles que leur codage en dur.
En pratique, il est facile de constater qu'il existe un écart entre la théorie et la pratique lorsqu'il s'agit de gérer et de partager des identifiants au sein d'une équipe, d'un département ou d'une organisation. Par exemple, l'organisation peut payer pour un gestionnaire de secrets basé sur le cloud, un coffre-fort (vault), ou même pour une équipe dédiée à l'administration de ces outils, ce qui lui fait croire à tort qu'elle a résolu ce problème. Mais après un examen plus approfondi, elle se rendrait compte que les identifiants à longue durée de vie sont également stockés sur les machines locales des développeurs pour plus de commodité.
Trouver votre voie vers une gestion sécurisée des secrets
Il existe différentes façons de gérer les secrets dans le cycle de vie du développement logiciel. Vous devriez explorer les options suivantes avec les équipes d'infrastructure et d'ingénierie avant de décider laquelle est la bonne approche pour votre organisation :
Codés en dur dans le code source et les templates(s'il vous plaît, ne le faites pas.)- Regrouper les secrets dans des fichiers de configuration communs et non chiffrés, tels que
.env(en dehors du dépôt git) - Chiffrer les secrets selon une approche GitOps ou sealed secrets, avec une clé de déchiffrement stockée dans un coffre-fort (vault)
- Stocker les secrets dans un coffre-fort (vault) et les distribuer via un service de gestion des secrets
- Générer des secrets dynamiques, via une infrastructure complexe de gestion des secrets
Le problème des secrets codés en dur
Les secrets codés en dur sont-ils une vulnérabilité ?
OWASP, la fondation Open Web Application Security Project qui œuvre à améliorer la sécurité des logiciels, répertorie les secrets codés en dur dans sa célèbre liste du Top 10 des risques de sécurité des applications web. Cette vulnérabilité s'est classée au 2e rang dans la dernière édition publiée en 2021, sous l'entrée Cryptographic Failures (A02:2021).
MITRE, célèbre pour sa base de connaissances ATT&CK sur les tactiques et techniques des adversaires, répertorie également l'utilisation d'identifiants codés en dur dans son CWE Top 25 des faiblesses logicielles les plus dangereuses. Cette vulnérabilité s'est classée au 15e rang dans l'édition 2022, sous CWE-798 – Use of Hard-coded Credentials.
Qu'est-ce qui rend les secrets codés en dur différents ?
Les secrets codés en dur constituent une vulnérabilité unique dans le code source par rapport aux autres vulnérabilités détectées par analyse statique ou dynamique. Que le code soit compilé et en cours d'exécution ou non, les secrets codés en dur représentent un risque en soi. Les attaquants qui obtiennent un accès initial à un dépôt peuvent parcourir toutes ses branches et son historique de commits pour rechercher des secrets valides. Peu importe qu'un secret soit trouvé sur la branche main déployée ou sur une branche de correction de bug à courte durée de vie, tant qu'il est valide et donne accès à une ressource (par exemple un serveur, une base de données, une API tierce).
La prolifération des secrets est un problème omniprésent
Les développeurs écrivent du code avec les meilleures intentions, mais ils finissent tout de même par compromettre des identifiants et des données sensibles. Avec 6 millions de secrets exposés sur le GitHub public en 2021 et bien plus encore dans les dépôts privés, nos recherches présentées dans le rapport State of Secrets Sprawl 2022 montrent que ce problème est beaucoup plus courant que ne le pensent les développeurs et les ingénieurs en sécurité.
La solution : la détection et la remédiation automatisées
Détecter des secrets dans le code source, c'est comme chercher des aiguilles dans une botte de foin : il y a beaucoup plus de brins que d'aiguilles, et vous ne savez pas combien d'aiguilles peuvent se trouver dans la botte de foin. Dans le cas des secrets, vous ne savez même pas à quoi ressemblent toutes les aiguilles !
Un scanner automatisé performant sera capable d'atteindre :
- Un faible nombre de fausses alertes soulevées. Nous appelons cela une haute précision. La précision répond à la question : « Quel est le pourcentage des secrets que vous détectez qui sont réellement des secrets ? ». Cette question est légitime, en particulier dans un contexte où les équipes de sécurité doivent faire face à la fatigue liée aux alertes.
- Un faible nombre de secrets manqués. C'est ce que nous appelons un rappel élevé. Étant donné qu'un seul identifiant non détecté peut avoir un impact important pour une organisation, certaines organisations préfèrent trier davantage de fausses alertes mais s'assurer de ne manquer aucun secret.
Équilibrer l'équation pour garantir que l'algorithme capture autant de secrets que possible sans signaler trop de faux résultats est un défi complexe et extrêmement difficile dont GitGuardian se charge pour ses utilisateurs. GitGuardian construit et maintient un moteur de détection des secrets couvrant plus de 600 types spécifiques de secrets, en plus de la prise en charge des motifs génériques et personnalisés.
