En un mois seulement, le secteur de la cybersécurité a vu deux incidents majeurs faire la une des journaux. Mi-septembre, Uber, la société de transport de personnes, a confirmé qu’un attaquant avait accédé à plusieurs systèmes internes et critiques.
Le pivot du piratage était un script PowerShell qui contenait des informations d’identification d’administrateur codées en dur pour se connecter à la plateforme de gestion des accès privilégiés de l’entreprise. À partir de là, l’attaquant a pu récupérer un certain nombre d’informations d’identification ou de secrets parmi les plus précieux des systèmes informatiques de l’entreprise.
Quelques semaines plus tard, c’est Toyota, le géant de l’automobile, qui a révélé avoir accidentellement exposé un identifiant permettant d’accéder aux données des clients dans un dépôt public GitHub pendant près de cinq ans. Bien qu’ils aient été assurés que la clé avait été invalidée, tout expert en sécurité élargie qu’une exposition aussi longue pourrait signifier que de multiples acteurs défectueux avaient déjà acquis l’accès.
Ces deux incidents à fort impact ont eu une résonance particulière chez GitGuardian : depuis notre création, nous avons mis en garde contre l’état dangereux de la prolifération des secrets, à la fois dans les périmètres des entreprises et sur les services publics tels que GitHub . Ce problème fait l’objet d’une prise de conscience, mais la protection des secrets reste souvent sous-estimée par rapport à d’autres catégories de vulnérabilités du code.
Plus tôt cette année, dans notre recherche annuelle intitulée The State of Secrets Sprawl 2022, nous avons signalé que plus de 6 millions de secrets ont été poussés sur GitHub au cours de la seule année 2021. Ce chiffre a doublé par rapport à 2020.
En moyenne, 3 commits sur 1 000 contenaient un secret, ce qui est cinquante pour cent de plus que l’année dernière. Si la majorité des projets open source hébergés sur GitHub sont des dépôts personnels, il est important de comprendre qu’il est très facile pour un développeur professionnel de publier par inadvertance du code donnant accès aux ressources de l’entreprise.
Cela arrive régulièrement, tout comme dans le cas de Toyota. Et nous savons que cet espace est surveillé et exploité : nos recherches indiquent qu’un exposé secret public peut être exploité en quelques jours ou quelques heures.
La prolifération des secrets est le terme utilisé pour décrire le phénomène des secrets qui non seulement deviennent publiquement visibles mais plus généralement affichés en clair dans diverses sources : code source, scripts de construction, infrastructure-as-code, journaux, etc.
Contrairement aux informations d’identification traditionnelles, les secrets sont destinés à être distribués aux développeurs, aux machines, aux applications et aux systèmes d’infrastructure. L’ajout de ces facteurs augmente inexorablement le nombre de secrets utilisés dans le cycle de développement, ainsi que la probabilité d’une fuite.
Pour aggraver la situation, les secrets sont encore plus faciles à trouver dans des actifs d’entreprises non exposés au public, comme dans le cas d’Uber. Les secrets en clair dans le code s’apparentent à une dette de sécurité, qui s’accumule au fil du temps lorsque rien n’est fait pour empêcher leur fuite dans les référentiels internes ou d’autres infrastructures numériques. Lorsqu’elles recherchent des secrets, les organisations se rendent vite compte qu’il y a beaucoup plus de secrets codés en clair que ce que leurs équipes de sécurité des applications peuvent gérer.
Dans le même rapport, nous avons souligné le fait qu’en moyenne, en 2021, une entreprise type comptant 400 développeurs découvrirait 1 050 secrets codés en dur uniques lors de l’analyse de l’ensemble de sa base de code, chacun ayant 13 occurrences différentes. Cela représente 212 secrets uniques par ingénieur en sécurité en moyenne !
Enquêter sur ces secrets, les trier et les révoquer représente une quantité de travail considérable, sans parler de la recherche de mois ou d’années d’anciens incidents.
En supposant que le processus de correction typique d’un secret dure en moyenne deux heures, on peut estimer que pour un atelier de 400 développeurs, au moins 2 100 heures-homme seraient nécessaires pour atteindre le « zéro secret dans le code ». Et ce, uniquement si la fuite des secrets s’arrête complètement.
Le problème est aigu. Les équipes de cybersécurité prennent très au sérieux les secrets codés en dur dans le code source et les risques qu’ils comportent. Plus généralement, c’est le paradigme de la sécurité du code source qui est en train de changer. Les entreprises du monde entier, même celles dont l’activité principale n’est pas numérique, réalisent que le code source est l’un de leurs actifs les plus précieux.
Le protecteur n’est pas seulement une question de continuité de l’activité, c’est désormais aussi une question de réputation et de propriété intellectuelle, sans parler des coûts éventuels des procédures judiciaires en cas de violation.
Une chose est sûre, cette tendance n’est pas prête de disparaître. Le « tout-comme-code » et la banalisation des infrastructures et des services numériques signifiant que les logiciels, et donc le code et les secrets, continueront à être de plus en plus présents dans les activités quotidiennes des entreprises.
Par ailleurs, les campagnes de pirates se concentrent désormais sur la récupération des informations d’identification des professionnels du logiciel, car les systèmes de développement de logiciels sont moins protégés et surveillés que les systèmes de production. Cibler n’importe quel maillon de la chaîne d’approvisionnement logicielle est aujourd’hui le meilleur moyen d’obtenir un accès privilégié à l’infrastructure informatique globale.
Pour permettre à la sécurité des applications de s’adapter à ces nouveaux défis, il est essentiel de fournir une visibilité sur les vulnérabilités au niveau des individus, des équipes et de l’organisation. Pour sécuriser le code source, il faut aller au-delà des pratiques traditionnelles et explorer de nouvelles façons d’impliquer les développeurs, les ingénieurs en sécurité et les opérations plus fermées dans les actions de détection, de remédiation et de prévention.
Nous développons des outils non seulement pour favoriser cette collaboration, mais aussi pour innover autour des secrets – en les utilisant comme système de détection des intrusions – et aussi pour soutenir l’effacement des frontières entre la sécurité des applications et la sécurité du cloud avec l ‘infrastructure en tant que code (IaC).
Apprendre à vivre avec la prolifération des secrets et mettre les bons outils et les bonnes ressources en face de ce problème est maintenant une stratégie qui portera ses fruits à l’avenir. La question n’est pas « un de nos secrets d’entreprise pourrait-il être divulgué et exploité ? », mais « avons-nous tout mis en place pour détecter et détecter cette situation dans un délai raisonnable ? ».
Il est temps de passer à l’action !
