Gestion sécurisée des secrets

Gérer les secrets dans le SDLC

Il n'existe pas de solution universelle

Les secrets sont si répandus dans les environnements DevOps qu'il ne peut y avoir de modèle unique pour les gérer. Il existe 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 difficile à maîtriser, car il s'agit de trouver le bon équilibre entre sécurité et accessibilité. Ce second point est crucial : dans les équipes de développement modernes, tout le monde a besoin de secrets. Rendre leur usage trop contraignant mène inévitablement à contourner les protections, par exemple en les codant en dur dans le code.

En pratique, on constate souvent un écart entre théorie et pratique pour le partage d'identifiants au sein d'une équipe, d'un service ou d'une organisation. Par exemple, l'organisation peut payer un gestionnaire de secrets cloud, un coffre-fort, voire une équipe dédiée à les administrer, et croire à tort que le problème est résolu. Un examen plus attentif montre souvent que des identifiants à longue durée de vie sont aussi stockés sur les postes des développeurs, par commodité.

Trouver votre voie vers une gestion sécurisée des secrets

Il existe plusieurs façons de gérer les secrets dans le cycle de vie du développement logiciel. Explorez les options suivantes avec les équipes infrastructure et ingénierie avant de choisir l'approche adaptée à votre organisation :

• Secrets codés en dur dans le code source et les templates (s'il vous plaît, non.)
• Regrouper les secrets dans des fichiers de configuration communs non chiffrés, comme .env (hors du dépôt git)
• Chiffrer les secrets dans une approche GitOps ou « sealed secrets », avec la clé de déchiffrement stockée dans un coffre
• Stocker les secrets dans un coffre et les distribuer via un service de gestion des secrets
• Générer des secrets dynamiques via une infrastructure de gestion des secrets plus complexe

Le problème des secrets codés en dur

Les secrets codés en dur sont-ils une vulnérabilité ?

OWASP, l'Open Web Application Security Project qui œuvre à améliorer la sécurité des logiciels, classe les secrets codés en dur parmi les 10 principaux risques de sécurité des applications web. Dans l'édition de 2021, la vulnérabilité est classée n°2 sous l'entrée Cryptographic Failures (A02:2021).

MITRE, connu pour sa base de connaissances ATT&CK sur les tactiques et techniques adverses, répertorie aussi l'usage d'identifiants codés en dur dans son CWE Top 25 des faiblesses logicielles les plus dangereuses. En 2022, la vulnérabilité est classée n°15 sous CWE-798 – Use of Hard-coded Credentials.

Qu'est-ce qui distingue les secrets codés en dur ?

Les secrets codés en dur constituent une vulnérabilité particulière dans le code source par rapport à d'autres failles trouvées par analyse statique ou dynamique. Que le code soit compilé et exécuté ou non, les secrets codés en dur représentent un risque en eux-mêmes. Un attaquant qui obtient un accès initial à un dépôt peut parcourir toutes les branches et l'historique des commits pour chercher des secrets valides. Peu importe qu'un secret soit sur la branche principale déployée ou sur une branche de correctif éphémère : tant qu'il est valide et donne accès à une ressource (serveur, base de données, API tierce, etc.), il compte.

La prolifération des secrets est un problème répandu

Les développeurs écrivent le code avec les meilleures intentions, mais compromettent tout de même des identifiants et des données sensibles. Avec 6 millions de secrets exposés sur GitHub public en 2021, et bien davantage dans les dépôts privés, nos recherches dans le State of Secrets Sprawl 2022 montrent que ce problème est plus courant que ne le pensent développeurs et ingénieurs sécurité.

La solution : détection et remédiation automatisées

Détecter les secrets dans le code source, c'est comme chercher des aiguilles dans une botte de foin : il y a beaucoup plus de paille que d'aiguilles, et vous ne savez pas combien d'aiguilles il peut y avoir. Pour les secrets, vous ne connaissez même pas la forme de toutes les aiguilles !

Un scanner automatisé performant doit permettre :

• Un faible nombre d'alertes erronées. Nous appelons cela une haute précision. La précision répond à : « Quel pourcentage des détections sont de vrais secrets ? » — une question légitime, surtout quand les équipes sécurité souffrent de fatigue d'alerte.
• Un faible nombre de secrets manqués. C'est ce que nous appelons une haut rappel (recall). Comme un seul identifiant non détecté peut avoir un fort impact, certaines organisations préfèrent trier plus de faux positifs plutôt que de manquer un secret.

Équilibrer l'algorithme pour capturer un maximum de secrets sans trop de faux positifs est un défi complexe et extrêmement difficile que GitGuardian prend en charge pour ses utilisateurs. GitGuardian construit et maintient un moteur de détection des secrets couvrant plus de 350 types spécifiques de secrets, en plus des motifs génériques et personnalisables.