Des IA trouvent maintenant des failles dans vos logiciels : ce que cela change pour votre entreprise

Votre site web, votre logiciel de facturation et votre messagerie ne sont pas écrits uniquement par vos prestataires. Ils reposent aussi sur des morceaux de code mis gratuitement à disposition par des communautés de développeurs. Le 21 octobre, une initiative américaine a rendu public le résultat d'un travail mené sur ces briques partagées : des modèles d'IA y ont cherché des défauts de sécurité, épaulés par des ingénieurs. Des centaines de problèmes ont été signalés, dont certains dans des programmes utilisés par des millions de machines. La question n'est plus de savoir si votre entreprise dépend de ce code. Elle est de savoir ce qu'elle fait du flux de correctifs qui arrive.

Ce qui s'est passé le 21 octobre

OpenAI a publié le mode de fonctionnement de « Patch the Planet », un programme mené avec Trail of Bits, société spécialisée dans la sécurité logicielle. Le principe est simple à décrire. Des ingénieurs en sécurité utilisent les modèles les plus récents d'OpenAI pour chercher des défauts dans des logiciels libres — des logiciels dont le code est public et que n'importe qui peut réutiliser. Ils vérifient ensuite chaque trouvaille avant de la transmettre aux mainteneurs, les développeurs bénévoles ou salariés qui entretiennent ces projets.

Les premiers participants comptent des projets très répandus. On y trouve cURL, qui sert à presque tous les échanges web, et Python, un langage de programmation courant. La liste inclut aussi le serveur de messagerie NATS, la bibliothèque de chiffrement de Python et Sigstore. Dix-neuf projets ont été couverts, selon OpenAI, avec « des centaines de problèmes de sécurité identifiés et des dizaines de correctifs fusionnés ». Trail of Bits, qui publie le décompte détaillé, parle de 64 propositions de correction et 51 signalements, dont 19 déjà clos par un correctif.

Le chiffre qui compte pour un dirigeant n'est pas le total. C'est le temps. Une équipe a monté un ensemble de tests automatisés couvrant des dizaines de points d'entrée en moins d'une journée. OpenAI estime que le même travail aurait pris « au moins plusieurs semaines » à la main. Trail of Bits parle de deux à trois semaines pour l'un de ses spécialistes.

Pourquoi trouver est devenu la partie facile

Une faille est un défaut du code qui permet à quelqu'un d'obtenir un comportement non prévu : lire un fichier qu'il ne devrait pas voir, prendre le contrôle d'une machine, faire tomber un service. En sécurité logicielle, le travail se découpe en deux temps. D'abord trouver. Ensuite prouver, corriger, tester, publier.

Pendant vingt ans, le premier temps a été le plus coûteux. Il fallait lire le code, comprendre l'intention de son auteur, imaginer un enchaînement. C'est un métier lent, et rare.

Les modèles actuels attaquent ce temps-là. Non pas parce qu'ils « comprennent » le code comme un ingénieur, mais parce qu'ils peuvent le lire en entier, essayer des milliers de variantes et ne jamais se fatiguer. Trois exemples publiés donnent la mesure.

Le premier : un défaut présent depuis 23 ans dans le noyau d'OpenBSD, un système réputé pour sa rigueur. Le second : 34 failles confirmées dans FreeBSD, dont sept permettent à un utilisateur ordinaire de devenir administrateur de la machine. Le troisième : une attaque par saturation nommée « HTTP/2 Bomb », qui exploite la façon dont les serveurs web compressent les informations d'identification envoyées à chaque demande — les « en-têtes ». Un seul poste relié à une connexion domestique de 100 Mbps peut rendre un serveur vulnérable inaccessible en quelques secondes. Les auteurs comptent plus de 880 000 sites web exposés au moment de leur publication. Aucune des deux techniques employées n'était nouvelle : c'est leur combinaison qui l'était.

L'analogie utile est celle du détecteur de fumée. Un détecteur bon marché dans chaque pièce ne remplace pas les pompiers. Il multiplie les alertes, y compris les fausses, et déplace l'effort vers celui qui doit vérifier et intervenir.

Le goulot d'étranglement s'est déplacé

Trail of Bits le formule sans détour : « trouver les bugs est désormais la partie facile ». Ce qui coûte, c'est la suite — confirmer qu'un signalement est réel, évaluer sa gravité, écrire un correctif que le mainteneur acceptera, le tester, organiser la publication.

Le problème est déjà mesurable. Sans consigne explicite, indique Trail of Bits, les modèles classent presque tout en « critique ». Un mainteneur qui reçoit cinquante signalements par semaine, dont trois sont réels, finit par ne plus lire. C'est le scénario classique de la fausse alerte qui tue la vraie.

La réponse observée est organisationnelle, pas technologique. Dédupliquer les signalements. Filtrer les faux positifs à l'aide d'une documentation de sécurité propre au projet. Corriger la gravité à la main. Et garder un ingénieur humain comme point de passage avant que quoi que ce soit n'atteigne le mainteneur. OpenAI insiste sur ce point : chaque trouvaille a été revue par un ingénieur avant d'être transmise.

Un exemple montre ce que donne un tel filtrage en bout de chaîne. Sur la bibliothèque aiohttp, huit correctifs ont été écrits et fusionnés par les mainteneurs en quelques heures, dont sept dans une même fenêtre de cinq heures. Le délai entre le signalement et la correction tenait en une journée. Ce n'est pas la norme : c'est ce qui devient possible quand le signal est propre.

Ce que cela change pour votre entreprise

Trois conséquences, dans l'ordre d'importance.

Le rythme des correctifs va augmenter. Si des acteurs industriels financent la recherche de failles dans les logiciels libres, la quantité d'avis de sécurité publiés augmentera. Ce n'est pas une prédiction sur une date : c'est la conséquence arithmétique d'un travail qui vient de commencer et qui s'étend, selon OpenAI, à de nouveaux projets par vagues.

Votre exposition dépend de votre délai de correction, pas de la mode. Une faille critique annoncée hier ne vous concerne que si le logiciel visé tourne chez vous et si vous ne l'avez pas mis à jour. Deux entreprises avec le même parc n'ont pas le même risque : celle qui applique sous 72 heures, et celle qui attend le prochain passage de son prestataire.

Vous ne pouvez pas auditer ce code vous-même. Personne ne lit les centaines de milliers de lignes qui font tourner un site moderne. La seule stratégie tenable est de savoir ce que vous utilisez, et de suivre les avis qui concernent ces composants.

Trois questions à poser à vos prestataires

Elles tiennent sur une page et évitent beaucoup d'illusions.

1. Qui lit les avis de sécurité, et en combien de jours un correctif critique est-il appliqué ? La réponse doit être un nom et un délai, pas « l'équipe technique ».
2. Où est la liste de vos composants, avec les versions ? Un tableur à jour vaut mieux qu'un outil sophistiqué et vide. Sans cette liste, une alerte reste une information générale.
3. Comment triez-vous les signalements automatiques ? Un prestataire qui reçoit des rapports générés par IA sans filtre humain finira par en ignorer de vrais.

Ce qu'il faut faire ce mois-ci

Cinq gestes, aucun ne demande d'acheter quoi que ce soit.

• Inventorier. Listez les logiciels qui touchent vos données clients, avec leur version. C'est le document le plus utile de votre dispositif.
• Fixer un délai. Critique : 72 heures. Important : 30 jours. Le reste : au cycle normal. Écrit, et connu de l'équipe.
• S'abonner aux avis. Les éditeurs publient des alertes ; encore faut-il qu'elles arrivent à quelqu'un.
• Tester avant de déployer. Un correctif appliqué sans vérification peut casser un service. Un environnement de test existe pour ça.
• Écrire une clause. Dans vos contrats, exigez une notification sous 72 heures en cas de faille touchant votre service.

Ce qu'il faut retenir

• L'IA a déplacé le coût de la sécurité : trouver un défaut est rapide, le corriger et le déployer reste lent.
• Une faille vieille de 23 ans a été trouvée dans un système très surveillé : l'ancienneté d'un défaut ne le rend pas inoffensif.
• Le volume de signalements va augmenter, et la majorité sera du bruit : le tri humain devient la compétence critique.
• Votre risque se mesure en jours de retard de correction, pas en nombre d'alertes reçues.
• Trois questions suffisent à évaluer un prestataire : qui surveille, en combien de jours, avec quelle liste de composants.
• Un inventaire à jour et un délai écrit font plus pour vous qu'un outil de sécurité supplémentaire.