MtoM Mag - Le journal de l'MtoM.

Le Rapport de GitGuardian estime qu’un seul ingénieur AppSec aurait eu à traiter en moyenne 3400 occurrences de secrets*, sur l’année 2021. Les équipes AppSec ne peuvent plus gérer à elles seules la fuite des secrets et ont besoin de l’implication des équipes de développement.

GitGuardian, la plateforme de détection de secrets* numéro un, présente les résultats de son rapport « State of Secrets Sprawl 2022 ». Le rapport étend sa précédente édition axée sur GitHub public en dépeignant une vue réaliste de l’état de la fuite des secrets dans les dépôts de code privés des entreprises.

 Les données révèlent qu’en moyenne, en 2021, une entreprise type comptant 400 développeurs découvrirait 1 000 secrets uniques exposés lors de l’analyse de ses dépôts et commits.

 Chaque secret étant en fait détecté à 13 endroits différents, la quantité de travail nécessaire pour y remédier dépasse de loin les capacités des équipes actuelles d’AppSec (1 ingénieur AppSec pour 100 développeurs).

Par rapport aux dépôts d’entreprise open-source, les dépôts privés sont également 4 fois plus susceptibles d’exposer un secret, ce qui conforte l’idée qu’ils génèrent un faux sentiment de sécurité menaçant les postures de sécurité.

Le volume historique des secrets codés en dur, associé à leur croissance constante, met en péril la capacité de remédiation des équipes de sécurité, principalement des ingénieurs sécurité applicative. Ceci, à son tour, impacte négativement l’ensemble du processus de transition vers le DevSecOps. Un plan d’action est donc nécessaire pour résoudre cette situation au plus vite.

Le rapport souligne également que le phénomène de la fuite des secrets n’en est encore qu’à ses débuts.

Tout d’abord, améliorant ses résultats antérieurs, la surveillance de GitHub public par GitGuardian a signalé un doublement du nombre de secrets exposés, atteignant un peu plus de 6 millions en 2021. En moyenne, 3 commits sur 1 000 ont exposé au moins un secret, +50% par rapport à 2020.

Deuxièmement, une étude approfondie menée sur une autre plateforme open-source populaire, Docker Hub, révèle que 4,6% des images disponibles publiquement exposent au moins un secret.

Étant donné que le nombre d’éléments constitutifs d’une application augmente (infrastructure Cloud, bases de données gérées, applications SaaS, composants open-source, microservices internes, etc.), il ne faut pas s’étonner de voir des secrets exposés dans toujours plus d’endroits différents.

Les recommandations de GitGuardian

Pour éviter que lecode source ne deviennent un terrain de jeu pour les pirates sans submerger les équipes de sécurité, l’accent doit être mis sur la prévention proactive.

Les fuites de secrets dans le code source sont inévitables, mais contrairement aux autres vulnérabilités, elles sont entièrement déterminées par des facteurs endogènes : plus de développeurs, nécessitant l’accès à plus de ressources, construisant et déployant à un rythme plus rapide. Cela signifie qu’avec suffisamment de discipline et d’éducation, associées aux bons outils, il est possible d’améliorer radicalement la situation, comme pour toute dette technique.

La détection des incidents et la remédiation peuvent être déplacées à différents niveaux pour construire une défense en couches tout au long du cycle de développement. Voici une approche progressive pour passer à une politique de "zéro secret dans le code" :

 Commencer par surveiller les commits et les demandes de merge/pull en temps réel pour tous les dépôts avec une intégration VCS native, et tirer parti des gains rapides pour mobiliser ses équipes (shift left niveau de l’équipe).

 Activer progressivement les contrôles pre-receive pour protéger les dépôts centralisés contre les fuites et "arrêter l’hémorragie".

 Dans l’intervalle, sensibiliser les utilisateurs à l’utilisation des contrôles pre-commit comme ceinture de sécurité. (shift left au niveau du développeur).

 Planifier une stratégie à plus long terme pour traiter les incidents plus anciens découverts par l’analyse de l’historique git (qui peuvent ou non représenter une menace réelle).

 Mettre en œuvre un programme de champion “sécurité des secrets”.

En intégrant l’analyse des vulnérabilités dans le flux de travail de développement, il est possible de faire en sorte que les ingénieurs sécurité applicative continuent à travailler sur des tâches à plus forte valeur ajoutée. Cela est encore plus vrai pour la détection des secrets, qui est très sensible à la prolifération (dès qu’un secret entre dans un système de contrôle de version, il doit être considéré comme compromis et nécessite donc un effort de remédiation). D’un autre côté, il est possible de réduire le nombre de secrets entrant dans ses VCS en éduquant mieux les développeurs tout en préservant leur flux de travail.

Jérémy Thomas, CEO de GitGuardian explique : "Le développement et la mise à disposition d’applications sécurisées doivent être une responsabilité partagée entre les équipes Dev, Sec et Cloud Ops. Les développeurs, en particulier, veulent avoir “un allié” à chaque étape du cycle de développement pour les aider à écrire un code plus sûr sans nuire à leur productivité. Et comme définir les menaces et suivre le rythme des technologies utilisées par les développeurs sera toujours une bataille sans fin, nous avons déjà posé les bases d’un cadre de sécurité du code puissant et flexible qui peut être étendu rapidement pour adresser une grande variété de vulnérabilités."

*Secret : Dans le contexte du développement de logiciels, les secrets font généralement référence à des clés d’authentification numérique qui permettent d’accéder à des systèmes ou à des données. Il s’agit le plus souvent de clés API, de noms d’utilisateur et de mots de passe, ou de certificats de sécurité.

https://www.gitguardian.com/