Les secrets dans le code source (identifiants codés en dur, clés API, chaînes de connexion aux bases de données, clés privées et jetons d’authentification committés dans des dépôts de gestion de versions) constituent l’une des vulnérabilités de la chaîne d’approvisionnement logicielle les plus répandues et les plus lourdes de conséquences. Elles sont répandues parce que les développeurs, sous la pression des délais, prennent souvent des raccourcis qui consistent à placer des identifiants directement dans le code ou dans des fichiers de configuration. Elles sont lourdes de conséquences parce qu’une fois committés dans un dépôt, les identifiants deviennent accessibles à toute personne ayant accès au dépôt et, dans les dépôts publics ou semi-publics, à quiconque peut accéder au dépôt ou le cloner, même après leur retrait de la base de code actuelle.
Le problème de l’historique git est le mécanisme de persistance précis qui rend insuffisante la réponse « retirer les identifiants du code ». Les systèmes de gestion de versions git conservent un historique complet de chaque commit effectué dans un dépôt. Un identifiant committé puis retiré lors d’un commit ultérieur reste présent dans l’historique git du dépôt, accessible à quiconque clone le dépôt et examine les commits passés. L’identifiant a peut-être été retiré de la pointe de la branche actuelle, mais il demeure dans l’historique immuable des commits. Une remédiation correcte exige non seulement de retirer l’identifiant du code actuel, mais aussi soit de réécrire l’historique git pour en effacer le commit (opération destructrice et perturbatrice), soit de renouveler immédiatement l’identifiant exposé.
La menace de l’analyse des dépôts publics est le mécanisme de découverte automatisé. Des outils automatisés analysent en permanence les dépôts publics GitHub, GitLab et Bitbucket à la recherche de motifs d’identifiants, en parcourant les historiques de commits, y compris les commits anciens, pour y trouver des formats de clés API, des en-têtes de clés privées, des chaînes de connexion et d’autres motifs d’identifiants. Un identifiant committé dans un dépôt public en 2021 puis « retiré » par un commit ultérieur en 2021 reste découvrable en 2024 par quiconque analyse le dépôt. Le temps écoulé ne réduit pas la validité de l’identifiant tant qu’il n’a pas été renouvelé.
Pourquoi c’est important
Les secrets dans le code source sont importants pour le TPRM parce que les dépôts de développement de vos fournisseurs peuvent contenir des identifiants donnant accès à des systèmes qui traitent vos données : identifiants de bases de données de production, clés de fournisseurs cloud, jetons API de services qui traitent vos données. Un identifiant compromis dans le dépôt d’un fournisseur est un vecteur d’attaque de la chaîne d’approvisionnement qui ne nécessite l’exploitation d’aucune vulnérabilité des logiciels en production du fournisseur.
- Confirmation de la politique acceptée sans vérification technique
- Historique git non inclus dans le périmètre de l’analyse des secrets
- Analyse des dépôts publics non réalisée dans le cadre de l’évaluation du fournisseur
- Renouvellement des identifiants non confirmé en réponse à une exposition passée
- Contrôle d’accès aux dépôts non évalué en parallèle de la gestion des secrets
À quoi ressemblent les bonnes pratiques
Les programmes de gestion des secrets matures mettent en place des hooks de détection des secrets en pré-commit qui empêchent les secrets d’atteindre la gestion de versions, une analyse continue de l’historique des dépôts à la recherche de motifs d’identifiants, le renouvellement immédiat comme réponse obligatoire à toute exposition d’identifiant découverte, et une revue explicite de l’historique git dans le cadre de l’évaluation des fournisseurs.
- Hooks de pré-commit empêchant les secrets d’atteindre la gestion de versions
- Analyse continue des dépôts, y compris de l’historique git
- Renouvellement immédiat des identifiants comme réponse obligatoire à toute exposition
- Revue de l’historique git à la recherche d’identifiants exposés, et pas seulement du code actuel
- Analyse des dépôts publics dans le cadre de l’évaluation de la chaîne d’approvisionnement logicielle des fournisseurs
Outils
Détection des secrets : GitLeaks, TruffleHog, GitHub Secret Scanning pour l’analyse des dépôts et de leur historique
Les outils de détection des secrets peuvent analyser l’intégralité de l’historique d’un dépôt, et pas seulement le code actuel, à la recherche de motifs d’identifiants. GitLeaks et TruffleHog prennent tous deux en charge l’analyse de l’historique des commits. Les alertes d’analyse des secrets de GitHub sont disponibles pour les dépôts publics. Pour les praticiens TPRM, lancer GitLeaks ou TruffleHog sur les dépôts publics d’un fournisseur dans le cadre de l’évaluation de la chaîne d’approvisionnement logicielle constitue une vérification précise de l’exposition des identifiants qu’une confirmation par questionnaire ne peut pas remplacer.
Hooks de pré-commit : detect-secrets, git-secrets pour la détection des identifiants en pré-commit
Les hooks de pré-commit qui analysent les modifications indexées à la recherche de motifs d’identifiants avant leur commit fournissent le mécanisme de prévention qui empêche les identifiants d’atteindre la gestion de versions. Pour les praticiens TPRM, demander si les fournisseurs utilisent des hooks de détection des secrets en pré-commit en complément d’une analyse post-commit constitue une question précise sur la prévention par rapport à la détection.
Enjeux de gouvernance
Le défi de gouvernance des secrets dans le code source tient à la complexité de la remédiation de l’historique git. Une fois qu’un identifiant a été committé dans un dépôt comptant plusieurs contributeurs, réécrire l’historique git pour le supprimer est perturbateur : tous les contributeurs doivent effectuer un rebase ou recloner le dépôt. La solution pragmatique est le renouvellement immédiat de l’identifiant, qui rend inutilisable l’identifiant committé dans l’historique, que celui-ci ait été nettoyé ou non, combiné à des hooks de pré-commit pour empêcher de futurs commits.
- Mettre en place une détection des secrets en pré-commit : prévention avant la gestion de versions
- Analyser l’intégralité de l’historique du dépôt, et pas seulement le code actuel
- Exiger le renouvellement immédiat des identifiants pour toute exposition découverte
- Analyser les dépôts publics des fournisseurs de logiciels critiques
- Inclure le périmètre de l’historique git dans l’évaluation de la gestion des secrets des fournisseurs
Si vous êtes une petite équipe
Lancez GitLeaks sur les dépôts GitHub publics de vos trois fournisseurs de logiciels les plus critiques. La commande prend quelques minutes par dépôt et recherche des motifs d’identifiants dans l’intégralité de l’historique git. Examinez les résultats : tout motif d’identifiant trouvé dans l’historique doit être traité comme une exposition potentielle et vérifié auprès du fournisseur pour savoir si l’identifiant a été renouvelé. Cette analyse vous en dira davantage sur l’hygiène historique des identifiants du fournisseur que n’importe quelle confirmation par questionnaire.
- Lancer GitLeaks sur les dépôts publics des fournisseurs critiques
- Examiner les résultats et vérifier le renouvellement des identifiants pour toute exposition découverte
- Interroger le fournisseur sur la mise en place de hooks de pré-commit pour les dépôts de développement
- Exiger la communication des renouvellements d’identifiants dans le cadre de l’évaluation des fournisseurs
Ce qu’il faut exiger
Demandez directement :
« Utilisez-vous des hooks de détection des secrets en pré-commit dans l’ensemble de vos dépôts de développement, et avez-vous analysé l’historique de vos dépôts, y compris les commits historiques, à la recherche d’identifiants exposés ? Et pouvez-vous confirmer que tous les identifiants découverts dans l’historique des dépôts ont été renouvelés ? »
Preuves attendues
- Mise en place de hooks de détection des secrets en pré-commit
- Couverture de l’analyse de l’historique des dépôts
- Confirmation du renouvellement des identifiants pour toute exposition historique
- Politique de gestion des secrets et application
Il convient d’interroger précisément un fournisseur qui confirme l’absence d’identifiants codés en dur sur le périmètre de l’historique git et la mise en place de hooks de pré-commit. La politique interdit. Les hooks de pré-commit préviennent. L’analyse de l’historique détecte. Le renouvellement corrige. Les quatre sont nécessaires pour une couverture complète de la gestion des secrets.
Comment le prouver
- Traces d’analyse des dépôts publics des fournisseurs critiques
- Vérification de la mise en place des hooks de pré-commit
- Processus de confirmation du renouvellement des identifiants
- Couverture de l’analyse de l’historique des dépôts
À retenir
Politique : aucun identifiant codé en dur. Code : identifiants retirés. Historique git : clé AWS, chaîne de connexion à une base de données, clé privée RSA, depuis 31 mois, toujours accessibles à quiconque clone le dépôt. La politique était réelle. Le retrait était incomplet. Retirer les identifiants du code actuel les laisse dans l’historique git. L’analyse de l’historique git les trouve. Les hooks de pré-commit empêchent le prochain commit. Le renouvellement immédiat rend l’identifiant historique inutilisable, que l’historique ait été nettoyé ou non. Politique, prévention, détection et renouvellement : c’est la couverture complète de la gestion des secrets. Politique et retrait du code actuel : c’est incomplet.