Le rapport State of Secrets Sprawl 2025 chiffre le phénomène : 28,65 millions de secrets compromis détectés l’an dernier sur GitHub, soit une hausse de 34 % en un an. Derrière ce volume, une réalité plus inquiétante encore — 66 % des secrets exposés en 2022 sont encore valides aujourd’hui. Jamais révoqués. Jamais remplacés.

L’essor des agents de code comme Claude Code ou Cursor joue un rôle dans cette accélération. En permettant à des non-développeurs de produire et pousser du code, ces outils démocratisent la création logicielle mais diffusent aussi des pratiques de sécurité défaillantes. Les erreurs de gestion des credentials ne viennent plus seulement des développeurs expérimentés qui vont trop vite — elles viennent aussi de profils qui n’ont jamais été formés à ces enjeux.

Le rapport pointe également un angle mort massif : les environnements internes. Le code privé des entreprises contient en moyenne six fois plus de secrets exposés que le code public. Ce qui était perçu comme un problème marginal, lié à GitHub, se révèle être un problème systémique, enfoui au cœur des infrastructures.

Face à ça, GitGuardian défend une posture de Zero Trust appliquée aux secrets : considérer que les systèmes internes seront compromis, et s’organiser pour détecter, contenir et remédier le plus vite possible. La levée de 50 millions de dollars annoncée récemment vise à étendre cette approche aux identités non humaines — ces 50 à 100 fois plus d’identités machines qu’humaines qui peuplent les systèmes d’entreprise, souvent sans aucune gouvernance.

La question n’est plus de savoir si une entreprise sera attaquée. C’est de savoir si elle sera capable de le voir à temps.

Transcription du podcast avec GitGuardian

GitGuardian : la fuite de secrets, nouvelle porte d’entrée des attaquants

Journaliste : On parle souvent de cyberattaque comme d’une course entre attaquants et défenseurs. Mais le dernier rapport de GitGuardian montre un changement plus discret : aujourd’hui, les attaquants ne forcent plus les portes, ils utilisent des accès qui existent déjà, parfois exposés depuis longtemps. Avec plus de 28 millions de secrets compromis en un an, ce n’est plus seulement une question de faille, mais d’accès laissés ouverts.

Pour en parler, à l’occasion de la publication du rapport State of Secrets Sprawl 2026, j’ai le plaisir d’accueillir Eric Fourrier, CEO de GitGuardian, en direct du Forum InCyber. Pour commencer, je vous propose de vous présenter, comme vous aimez le faire, et de nous présenter GitGuardian.

Eric Fourrier : Merci de me recevoir. Eric Fourrier, CEO et fondateur de GitGuardian, que j’ai créé il y a à peu près sept ans. Je suis développeur de formation, j’ai fait des études de machine learning — le machine learning dans le texte, avant les LLM, donc on n’était pas les gens cool du deep learning à l’époque. J’étais data scientist dans la Silicon Valley.

En rentrant en France, je me suis rendu compte que les data scientists faisaient beaucoup d’erreurs dans la gestion des identifiants et des secrets : ils en laissaient traîner un peu partout dans le code, notamment des clés AWS donnant accès à toute l’infrastructure cloud, ou des clés de base de données donnant accès à des données sensibles de leur entreprise. J’ai décidé d’explorer ce sujet, et en bon data scientist, j’ai choisi la base de données la plus riche sur le code : le code open source publiquement disponible sur GitHub.

GitGuardian a commencé comme un side project, qui tourne toujours aujourd’hui, avec cette idée simple : on crawle tout le code open source en temps réel. À l’époque, on avait un simple scanner capable de détecter 20 ou 30 types de secrets, dont les clés AWS, les clés SendGrid, des clés de base de données. À chaque fois qu’on trouvait un secret sur GitHub, on alertait le développeur — et on a eu beaucoup de soutien de la communauté open source. Très vite, ça a évolué : on envoyait 500 emails par jour, on recevait 50 à 60 inscriptions, ce qui était déjà beaucoup, et on trouvait très rapidement des identifiants donnant accès à des données très sensibles dans des entreprises. On a alors décidé d’en faire une entreprise, en voyant qu’il y avait un vrai problème non résolu : la fuite de credentials.

Depuis, GitGuardian a beaucoup grandi. Il y a quelques mois, on est devenus l’application la plus installée au monde sur GitHub — un demi-million de développeurs, on est même presque à 600 000 aujourd’hui, qui utilisent l’application gratuite, nos origines : on a toujours gardé un produit gratuit pour les développeurs et les petites entreprises. On a énormément grossi, en France comme à l’international : aujourd’hui on est 150 personnes, 120 en France, 30 aux États-Unis, 70 % de notre revenu vient des États-Unis, et on vend à des entreprises partout dans le monde, parmi les plus grandes — Snowflake, Bouygues, ING — dans la tech, la banque, les télécoms, et tous les secteurs qui font du logiciel.

Journaliste : Bravo, c’est bluffant. Et vous ne devez pas vous ennuyer, parce que le paysage change de visage : le dernier rapport montre que les attaquants ne rentrent plus dans les systèmes en les forçant, puisque les accès existent déjà. Est-ce qu’on change de modèle d’attaque aujourd’hui ?

Eric Fourrier : C’est très intéressant. En anglais, on a une formule qu’on aime beaucoup : « Attackers aren’t breaking in, they’re just logging in » — les attaquants ne forcent plus les portes, ils trouvent la clé tombée juste à côté et ils ouvrent avec.

C’est vraiment l’origine de GitGuardian : on trouve des secrets publiquement leakés sur GitHub, accessibles à n’importe qui dans le monde puisque le code y est destiné à être partagé et cloné. Avec ces accès, les attaquants peuvent atteindre une première partie des systèmes — par exemple un token GitHub donnant accès à des dépôts privés. Ils scannent ensuite ces dépôts pour trouver d’autres secrets : des clés de base de données internes, des clés SSH, des clés cloud en général. Ça leur permet de se déplacer latéralement — c’est exactement le problème qu’on essaie de résoudre.

Les attaquants peuvent entrer de diverses manières : ingénierie sociale, phishing, ou des attaques de chaîne d’approvisionnement logicielle — on en a vu plusieurs très importantes ces trois ou quatre derniers mois, comme Shai-Hulud, ou récemment à RSA Conference, où on a publié plusieurs articles de recherche sur des attaques touchant des packages open source largement utilisés. En compromettant ces packages, les attaquants accèdent à la machine du développeur, y trouvent des secrets, puis se déplacent latéralement pour voler et utiliser ces secrets comme s’ils étaient le développeur légitime — aspirer des données, faire des requêtes, se déplacer encore, ou déployer un ransomware pour immobiliser l’entreprise ou en tirer de l’argent.

Beaucoup de systèmes de sécurité historiques, type EDR, ont été conçus pour détecter des schémas d’attaque ou des comportements inhabituels qu’un humain ne ferait pas. Mais avec les secrets, c’est très difficile de différencier l’attaquant de l’utilisateur légitime, parce qu’il les utilise de la même manière. Notre grande hypothèse chez GitGuardian, c’est qu’aujourd’hui, presque toute attaque inclut un vol de secret — ce qu’on appelle le credential harvesting. C’est ce qu’on essaie de protéger : une des attaques les plus faciles à mener, que l’IA permet d’accélérer fortement, extrêmement rapide, et qui crée des dommages très importants.

Explosion des volumes

Journaliste : Ce changement de logique s’accompagne d’une explosion de volume — vous parlez de 28,65 millions de secrets exposés en 2025, une hausse de 34 % en un an. Cette accélération va-t-elle s’installer durablement ?

Eric Fourrier : C’est intéressant. Il y a aujourd’hui beaucoup plus d’acteurs sur ce sujet — ce n’était pas le cas quand j’ai créé GitGuardian, le problème des secrets était encore naissant, et on a été parmi les premiers, voire les premiers, à le traiter côté entreprise. Aujourd’hui, d’autres acteurs s’y attaquent, y compris GitHub lui-même, qui essaie tant bien que mal de limiter le nombre de secrets qui fuitent sur sa plateforme. On voit qu’il y a encore 28 millions de secrets qui fuitent, donc il reste beaucoup de travail — c’est un problème difficile à résoudre.

Mais en creusant les chiffres, ce qui est vraiment intéressant, et sans doute la statistique la plus marquante de l’année 2025, c’est que cette augmentation des secrets est majoritairement liée à une augmentation du nombre de commits. Depuis qu’on publie le State of Secrets Sprawl 2026, il y a quatre ou cinq ans, on avait historiquement une croissance du nombre de fuites de l’ordre de 20 à 25 %, corrélée à la croissance du nombre de commits. Cette année, on a une accélération beaucoup plus forte — plus de 30, voire plus de 40 % de nouveaux commits.

Ce phénomène, très intéressant et qui pose un vrai problème de sécurité, vient essentiellement de nouveaux entrants dans le monde du développement. Avec les nouveaux coding agents et le vibe coding — Claude Code, Cursor —, des gens qui ne codaient pas auparavant, des product managers, des personnes du marketing ou des opérations, ou des gens en apprentissage technique qui ne savaient pas encore coder, peuvent désormais produire du code sans l’écrire eux-mêmes, puisque c’est l’IA qui l’écrit pour eux, et le pousser sur GitHub.

C’est un vrai défi pour la sécurité : on a une nouvelle catégorie de contributeurs, non formés, qui poussent du code, et ce sont généralement eux qui commettent ces erreurs — des secrets rendus publics, une mauvaise gestion des identifiants, du code écrit avec pas mal de vulnérabilités. Je précise, parce que certains éditeurs cultivent l’idée que les LLM et les coding agents écriraient du code intrinsèquement vulnérable. C’était peut-être vrai il y a un an et demi, mais c’est de moins en moins le cas avec des acteurs comme Claude Code : les modèles sont de plus en plus performants, le niveau monte beaucoup. Au bout du compte, celui qui crée la vulnérabilité, c’est l’humain derrière, pas la machine — même si la machine n’aide pas toujours, parce qu’elle a tendance à être d’accord avec ce que dit l’humain, elle est un peu conçue pour ça. C’est le constat qu’on fait sur 2025.

Fuites de secrets : pourquoi les accès compromis restent actifs pendant des années

Journaliste : Au-delà du volume, la durée de vie des accès m’a beaucoup interpellée : 64 % des secrets exposés en 2022 sont encore valides aujourd’hui. Comment expliquer que ces accès compromis restent actifs pendant des années ?

Eric Fourrier : C’est sans doute la statistique la plus inquiétante — et c’est un trésor pour les attaquants. Même quand GitGuardian ou d’autres acteurs alertent, on constate que 66 % des secrets qui ont fuité en 2022 — on refait un contrôle de validité fin 2025, presque quatre ans plus tard — sont encore actifs. Ça veut dire qu’il n’y a pas eu de remédiation.

Ça témoigne de deux choses : d’abord que les gens ne résolvent pas le problème, ensuite un problème d’hygiène fondamental, très grave, qui est qu’énormément d’identifiants sont long-lived — sans durée d’expiration. On crée un mot de passe ou une clé, et elle reste active indéfiniment. C’est une pratique de sécurité qu’on essaie de faire évoluer depuis cinq ans : créer des jetons d’authentification et des identifiants à courte durée de vie, pour que si un attaquant les trouve, ils ne soient plus actifs au bout d’un certain temps. Le fait que ce problème persiste montre qu’il est encore plus important qu’il n’a pas été résolu, et ça crée des portes d’entrée très faciles pour les attaquants.

Journaliste : Concrètement, lorsqu’un secret fuite, qu’est-ce que ça permet à un attaquant, et quel type d’accès ou d’impact ça ouvre ?

Eric Fourrier : Très bonne question. On voit trois grands cas de figure ces derniers temps, en observant les malwares créés par les attaquants. Leurs premières cibles, ce sont les secrets liés à la chaîne de développement logiciel : les tokens GitHub qui donnent accès à des dépôts, les tokens Docker et Artifactory qui donnent accès à des binaires et des applications. Ils font des attaques par rebond, sachant que l’accès au code interne d’une entreprise permet de le scanner pour trouver d’autres secrets latéralement — c’est la base de beaucoup d’attaques, ce qu’on appelle l’élévation de privilèges : chercher plus d’accès pour pénétrer davantage de systèmes et faire plus de dommages.

Ensuite, ils ciblent les secrets donnant accès aux données de l’entreprise : les identifiants cloud, les clés AWS, les clés de base de données, qui donnent accès aux systèmes contenant des données clients. Là, ils peuvent installer des malwares et conserver un accès indéfiniment, voler des données et déployer un ransomware. L’objectif final, c’est d’avoir accès à un maximum de données, de persister dans l’entreprise pour continuer à en voler, et la conséquence, généralement, c’est un ransomware — chiffrer la base de données et exiger une rançon, ou menacer de divulguer des informations confidentielles, comme des données clients, en échange d’un paiement. C’est typiquement ce que font des groupes comme Lapsus$ en ce moment.

Journaliste : En résumé, un seul secret peut ouvrir toute une infrastructure et causer des dégâts majeurs.

Eric Fourrier : Exactement, il en suffit d’un.

Pourquoi l’IA fait exploser les fuites de secrets

Journaliste : Ce phénomène s’accélère avec l’IA — le rapport signale une hausse de 81 % des secrets liés à ces usages. Est-ce que l’IA crée un nouveau risque, ou amplifie-t-elle un problème déjà existant ?

Eric Fourrier : C’est intéressant, c’est un peu les deux. Pour préciser ce chiffre : on a pris des fournisseurs d’IA — OpenAI, Mistral, Perplexity — et on a observé les secrets créés pour ces différents acteurs. Sur 2025, on constate 80 % de clés en plus qui fuitent. Ça traduit d’abord un usage en pleine explosion : mathématiquement, on trouve plus de secrets liés à ces services sur GitHub public quand leur nombre d’utilisateurs grossit — typiquement, si un fournisseur multiplie ses utilisateurs par cinq en un an, on voit à peu près cinq fois plus de clés qui fuitent. C’est même un bon indicateur pour savoir quel fournisseur domine et progresse le plus vite.

Mais sur le fond, l’IA accentue vraiment le problème qu’on adresse historiquement — la dispersion des secrets. Les gens écrivent du code beaucoup plus vite, créent de l’infrastructure beaucoup plus vite, et font beaucoup moins attention. Les agents IA, notamment les coding agents comme Claude Code ou Cursor, poussent développeurs et non-développeurs à coder et livrer toujours plus vite, ce qui mathématiquement génère plus d’erreurs. Dans cet arbitrage entre sécurité et vélocité, la vélocité l’emporte très nettement.

Il y a un autre problème, structurel celui-là : les agents IA — qu’il s’agisse d’agents pour coder ou d’agents pour tous les employés — doivent, pour être performants, se connecter à de plus en plus de systèmes. On leur donne accès à notre boîte mail, à notre calendrier, au wiki interne de l’entreprise, pour qu’ils puissent lire nos derniers messages ou résumer ce qui s’est passé sur un canal Slack ou Teams. On provisionne donc des accès et des identifiants supplémentaires, ce qui crée encore plus d’accès de manière exponentielle. Si un attaquant compromet la machine, il peut, via l’agent, accéder à tous ces systèmes, y voler de l’information, y retrouver des secrets qui auraient fuité sur Jira, Confluence, Slack, et se déplacer encore latéralement.

En résumé, les agents IA augmentent énormément l’interconnexion entre les systèmes et cassent la segmentation des accès que les équipes sécurité ont essayé de construire ces dix dernières années. Plus un agent a de contexte et de données, plus il est performant — donc chacun cherche à lui donner le maximum de contexte, ce qui crée des points de vulnérabilité très importants, que les attaquants exploitent aujourd’hui à merveille.

Journaliste : Vous pensez que c’est la faute des outils ?

Eric Fourrier : Non, je ne pense pas. C’est un vrai arbitrage entre vélocité et productivité, que chaque entreprise doit gérer — y compris GitGuardian, qui cherche aussi à améliorer sa propre productivité tout en sécurisant les entreprises contre les fuites de secrets et en aidant à mieux gérer leurs identités non humaines et leurs agents. C’est une question presque existentielle pour beaucoup d’entreprises, qui ne veulent pas rater le virage de l’agentique et sont prêtes à sacrifier de la sécurité à court terme pour préserver leur activité. Je pense, comme beaucoup d’acteurs de la sécurité, qu’on va rattraper le retard d’ici 12 à 18 mois — c’est déjà en cours.

C’est presque un choix de conception : sur Claude Code par exemple — je suis développeur de formation, on a 60 développeurs en interne —, pour bien fonctionner, il faut lui permettre de quasiment tout faire sur la machine. Beaucoup de développeurs dans le monde l’autorisent, ce qui permet en théorie à un attaquant de tout faire via l’agent, y compris effacer l’ordinateur ou voler tous les secrets. Mais sans ce paramètre activé, on n’a pas le même gain de productivité. Le choix est vite fait, malheureusement.

Journaliste : Et le problème ne concerne pas que le code : 28 % des données proviennent d’autres outils, comme Slack par exemple. Est-ce que la sécurité se concentre encore au bon endroit ?

Eric Fourrier : Très bonne question. On voit de plus en plus de secrets fuiter sur d’autres sources de données — en partie parce qu’on en surveille de plus en plus. On a commencé par surveiller le code, puis il y a deux à trois ans on a étendu la surveillance à Slack, Jira, Confluence, les conteneurs Docker. On se lance aussi désormais dans la surveillance des postes de travail des développeurs, où l’on trouve énormément de secrets. Avec les attaques de chaîne d’approvisionnement logicielle comme Shai-Hulud, le poste de travail — et plus largement les ordinateurs portables — devient une cible très importante pour les attaquants, parce qu’il donne accès à d’autres secrets, à d’autres agents, et rapidement à tout le contexte de l’entreprise.

Sur ce point, il y a un vrai trou de sécurité dans énormément d’entreprises, qui pensent être protégées parce qu’elles ont déployé un EDR type CrowdStrike, alors que ce n’est pas du tout le cas : un EDR ne bloque pas ce type d’attaque et a du mal à la détecter en temps réel, parce qu’il peine à isoler un comportement réellement anormal. Il faut des solutions spécialisées, comme GitGuardian ou d’autres, réellement adaptées à ce type d’attaque.

Journaliste : Ça fait peur : on s’équipe d’une multitude d’outils et on n’est finalement pas protégé à 100 %.

Eric Fourrier : C’est un peu la malédiction de la cybersécurité : la défense est toujours plus difficile que l’attaque, comme dans la vraie vie — il est toujours plus facile de détruire de la valeur que d’en créer. C’est difficile, mais ce n’est pas une raison pour abandonner le combat.

Journaliste : Autre point intéressant du rapport : les environnements internes sont plus exposés que les environnements publics. Qu’est-ce que ça dit du niveau de sécurité des entreprises ?

Eric Fourrier : C’est plutôt une bonne nouvelle, en un sens. Le State of Secrets Sprawl montre qu’il y a en moyenne six fois plus de secrets dans le code interne que dans le code public, à volume de commits équivalent. Ça peut se lire dans les deux sens : d’un côté, il y a moins de secrets accessibles publiquement que dans le code interne des entreprises.

Mais il y a sept ans, quand j’ai créé GitGuardian, beaucoup de responsables sécurité ou de DevOps me disaient : « pas grave, mes dépôts sont privés, mes secrets sont dans du code privé » — ce n’était même pas vu comme un problème. Aujourd’hui, les mentalités ont évolué : la révolution DevOps des dix dernières années a fait du code une donnée distribuée — clonée sur les laptops des développeurs, packagée dans des images Docker, déplacée à divers endroits. Un secret présent dans le code doit donc être considéré comme diffusé, et compromis. Ce phénomène s’est encore accéléré ces derniers mois avec les coding agents : le code est aspiré, retraité par ces agents IA, sans qu’on sache précisément ce qu’ils en font ni où ça finit.

Notre position aujourd’hui avec nos clients, c’est qu’il faut appliquer une logique Zero Trust sur les environnements internes : partir du principe que les systèmes internes seront compromis, que les secrets seront volés, et se demander comment détecter l’attaque, en limiter l’impact, et être capable de remédier très rapidement. C’est exactement ce que notre suite de produits essaie de proposer, avec des jetons-leurres qui détectent une attaque en temps réel quand un attaquant tente de les utiliser, et l’ensemble de nos outils pour découvrir les secrets dans tous les systèmes de l’entreprise et aider nos clients à les révoquer — en les plaçant dans des coffres-forts sécurisés — et à avoir une visibilité complète sur tous leurs secrets et identités.

Identité non humaine (NHI) : le nouvel enjeu de la cybersécurité

Journaliste : Il y a une autre notion que j’ai découverte : celle de la non-human identity. De quoi s’agit-il, et pourquoi ça devient un enjeu central ?

Eric Fourrier : Très bonne question. On vient historiquement d’un monde — dont sont issus de gros acteurs de la sécurité des identités humaines comme Okta ou SailPoint — où le paradigme, ces dix ou quinze dernières années, consistait à dire : les employés, en rejoignant une entreprise, ont accès à différents systèmes — messagerie interne, base de connaissances, CRM pour les commerciaux — et on veut protéger ces accès humains, notamment lors de l’arrivée et du départ des collaborateurs. L’identité humaine par excellence, c’est mon nom d’utilisateur, mon mot de passe, l’accès à ma messagerie — le secret associé à mon email est en quelque sorte le passeport de ma boîte de réception.

La non-human identity, c’est le même concept appliqué aux machines. Aujourd’hui, on a tout un monde où des machines doivent communiquer entre elles via une clé d’API, où un agent doit communiquer avec une machine, où un humain doit communiquer avec un agent — toute une nouvelle famille d’identités et de secrets pour que machines et agents puissent se parler. Les statistiques montrent qu’il y a aujourd’hui entre 50 et 100 fois plus d’identités non humaines que d’identités humaines, ce qui rend le problème beaucoup plus complexe et différent à résoudre.

Le monde des identités humaines s’est construit autour de moments clés — l’arrivée et le départ d’un employé. Pour les machines et les agents, ces notions n’existent pas vraiment : un employé peut partir, mais l’application qu’il a créée existe-t-elle toujours ? Les secrets associés existent-ils toujours ? L’agent qu’il a créé existe-t-il toujours ? C’est un nouveau paradigme, aujourd’hui pas du tout sécurisé, et un enjeu énorme pour les cinq à dix prochaines années.

Journaliste : Un enjeu qui n’est pas près de s’arrêter.

Eric Fourrier : Et qui ne fera que grandir.

Journaliste : Au-delà de la détection, il y a aussi un enjeu de gouvernance. Qu’est-ce que ça implique pour les entreprises ?

Eric Fourrier : On dit souvent : « You cannot secure what you don’t see » — on ne peut pas sécuriser ce qu’on ne voit pas. Beaucoup d’entreprises sont aujourd’hui complètement aveugles sur ce sujet : la première étape, c’est la capacité à découvrir et comprendre combien elles ont d’agents IA, d’identités non humaines, où elles se trouvent, comment elles vivent. Cette première couche de visibilité est essentielle. Ensuite, il faut un minimum d’actions de gouvernance pour améliorer l’hygiène — par exemple réduire le nombre de secrets à longue durée de vie au profit d’identités et de secrets dynamiques, et limiter le nombre de privilèges par identité. Il y a toute une série d’actions correctives possibles pour améliorer cette hygiène et, au final, limiter les risques et éviter une brèche aux conséquences importantes pour l’entreprise.

Levée de fonds GitGuardian : le marché de la cybersécurité prend le sujet au sérieux

Journaliste : J’ai l’impression que le marché commence à prendre ça au sérieux — vous venez de lever 50 millions de dollars, félicitations. Est-ce que ça traduit une prise de conscience plus large sur ces enjeux ?

Eric Fourrier : Je pense que les entreprises réalisent le travail qu’il reste à accomplir sur la sécurisation des secrets et des identités non humaines, où la maturité est encore très faible. Sur les secrets, les gens commencent à comprendre le problème. Sur la partie non humaine, la maturité n’y est pas du tout encore.

Il y a un autre sujet très présent en ce moment, notamment aux États-Unis, et qui va arriver fortement en Europe : comment permettre aux agents IA de s’identifier auprès des systèmes de manière sécurisée, comment concevoir les protocoles d’authentification — puisqu’un agent n’est ni tout à fait une machine, ni de l’infrastructure cloud, ni un humain. Faut-il un nouveau système d’authentification, ou peut-on l’intégrer dans les cadres existants ? Ce sont des questions encore largement ouvertes, et c’est une opportunité pour nous, qui sommes experts depuis sept ans sur la sécurisation des secrets. La partie agents IA fait exploser notre problème historique, mais pose aussi de nouveaux problèmes à résoudre — c’est l’objectif de cette levée de fonds : consolider notre position de leader sur la sécurisation des secrets, et nous étendre sur la sécurisation des identités non humaines et des agents.

Journaliste : Merci Eric. Pour clôturer, projetons-nous un peu dans le futur : si on prolonge la tendance, à quoi ressemblera une cyberattaque dans quelques années ?

Eric Fourrier : Très bonne question. Il y a deux mois, on a eu le premier cas documenté d’une attaque menée de bout en bout par un agent IA, qui a réussi à compromettre des packages open source. On passe d’un monde où l’attaquant, le hacker, était — il faut le reconnaître — quelqu’un de très intelligent et doué, qui construisait des malwares complexes demandant du temps et un vrai savoir-faire, à un monde où ce sera de moins en moins un humain qui attaque, et de plus en plus un agent.

Un rapport, je crois de CrowdStrike, indique que le temps d’exploitation d’une vulnérabilité est passé de plusieurs centaines de jours il y a cinq ans à seulement quelques heures aujourd’hui. Ce qui pouvait prendre plusieurs semaines, voire plusieurs mois, prendra bientôt quelques minutes ou quelques heures — ce qui va rendre le travail de défense très différent. Ça pousse beaucoup d’éditeurs de sécurité à passer d’une approche de pure gouvernance — cartographier où sont les problèmes — à une approche de détection et de blocage en temps réel, et pousse la défense à réagir beaucoup plus vite qu’avant. C’est ce qu’on avait anticipé chez GitGuardian, et sur quoi on travaille beaucoup : être davantage sur la détection et la réponse, pour aider nos clients à réagir à une attaque en direct. Ce qu’on considérait avant comme un événement rare et décentralisé va devenir monnaie courante — toutes les entreprises vont subir des attaques en permanence, et devront investir beaucoup plus pour y faire face.

Journaliste : Merci beaucoup Eric. J’invite les auditeurs qui veulent approfondir à télécharger le rapport, disponible sur le site de GitGuardian. Merci beaucoup, à bientôt.

Eric Fourrier : Merci beaucoup.