L'ère des correctifs passe à la vitesse machine, les cycles trimestriels sont morts

Que se passe-t-il quand trouver un bogue coûte moins cher que le corriger ? Nous venons d'en avoir une démonstration en direct, et elle n'était pas belle. Des gouvernements ont mis des sites hors ligne, et ceux qui font tourner la plomberie d'internet ont passé la semaine en mode triage.

En bref: deux failles critiques dans PHP, qui fait tourner, selon l'AFP, une large part des sites web du monde, ont été découvertes à l'aide de modèles d'IA. Comme le rapporte L'Express, des sites gouvernementaux en Europe et ailleurs ont été mis hors ligne par précaution, le temps que les exploitants appliquent les correctifs. Deux sociétés de sécurité, Calif et Wiz, disent avoir trouvé les bogues de façon indépendante, et Wiz affirme avoir utilisé des modèles d'OpenAI et de Google. Ces bogues dormaient dans le code depuis des années.

Selon nous, les failles comptent moins que ce qu'elles révèlent. La découverte va désormais à la vitesse des machines. La plupart des organisations appliquent encore leurs correctifs à la vitesse des humains.

Ce qui fait peur, ce n'est pas le bogue, c'est l'horloge

Michael Daniel, président de la Cyber Threat Alliance et ancien coordinateur de la cybersécurité à la Maison-Blanche, a donné à l'AFP le chiffre qui nous a marqués. Il fallait autrefois un mois ou deux pour qu'une preuve de concept apparaisse, puis encore un mois ou deux pour qu'elle atterrisse dans les kits d'exploitation. Aujourd'hui, dit-il, cela se compte en heures ou en jours.

Imaginez l'effet sur un cycle de correctifs trimestriel. Si le délai entre la publication d'une faille et son exploitation par les attaquants se réduit à quelques heures ou jours, un processus bâti sur des fenêtres de maintenance mensuelles revient, à notre avis, à décider de rester exposé. L'enquête de Reuters résumée par Distributique indique que, d'après les données de VulnCheck, le nombre de vulnérabilités découvertes double en un an. Voir le volume entrant doubler pendant que la fenêtre de réaction s'effondre, c'est un étau que des effectifs supplémentaires ne suffiront probablement pas à desserrer.

Il faut toutefois rester honnête sur les réserves. Michael Daniel rappelle que seules cinq à six pour cent des vulnérabilités ont historiquement été exploitées, et rien n'indique que cette proportion augmente. Sur cette faille précise, les récits divergent. Les chercheurs cités par Distributique affirmaient qu'au moment de l'enquête de Reuters, aucun exploit fonctionnel n'avait été confirmé. L'Express, de son côté, rapporte que des entreprises technologiques ont averti que certains pirates exploitaient déjà les failles. Nous ne pouvons pas trancher d'ici. Notre lecture: c'est d'abord un problème de vitesse, et affirmer qu'internet brûle déjà serait exagéré. Hausser les épaules serait pire.

« Tout tester pendant des semaines » était un luxe, pas une politique

L'idée la plus inconfortable de l'entretien avec Michael Daniel concerne la tolérance au risque. La plupart des entreprises appliquaient ce qu'il appelle une tolérance zéro à la casse, et testaient donc les correctifs de façon exhaustive. Il soutient qu'elles n'en ont plus le temps. Si un correctif a une chance sur cent de casser quelque chose, mais qu'une attaque peut coûter 50 millions de dollars, l'arbitrage change.

Nous pensons qu'il a raison, même si beaucoup de directions informatiques n'aimeront pas l'entendre. Appliquer lentement et prudemment les correctifs était rationnel quand l'exploitation était lente. Désormais, le coût de l'attente est le plus grand risque. Concrètement, cela donne trois chantiers sans éclat. D'abord, un inventaire exact de ce que vous exploitez et de ce qui est exposé sur internet. Ensuite, des chaînes de test et de déploiement automatisées capables de livrer vite un correctif. Enfin, des mesures d'atténuation provisoires quand un correctif ne peut pas partir immédiatement. C'est à peu près la liste que dresse l'article de Distributique, et rien de tout cela ne requiert d'IA. Cela demande de la discipline, ce qui est plus difficile.

Les petites organisations sont les vraies perdantes. Le conseil de Michael Daniel est sans détour: adapter l'organisation pour accepter les mises à jour des éditeurs le plus vite possible. Pour qui utilise une plateforme gérée, cela revient surtout à choisir ses fournisseurs selon leur rapidité à corriger.

La dette technique est le vrai sujet, et l'IA est le huissier

Michael Daniel parle d'une « dette technique qui arrive à échéance ». Le coût implicite du maintien de vieux logiciels n'apparaît jamais dans les comptes avant un épisode comme celui-ci. Rob Joyce, ancien directeur de la cybersécurité de la NSA, a parlé du « grand incendie de forêt purificateur des vieux logiciels ». Les deux images nous parlent.

Il existe aussi une lecture porteuse d'espoir. Michael Daniel s'attend à ce que des outils d'IA soient appliqués aux logiciels avant leur déploiement, de sorte que le code neuf parte avec moins de trous. Jason Clinton, responsable de la sécurité chez Anthropic, a écrit sur X que les choses iraient bien plus mal avant de s'améliorer et qu'il faudrait tenir environ 18 mois, d'après 01net. C'est une prévision, pas un fait, et elle vient d'une entreprise qui conçoit ces modèles. La logique reste plausible: les défenseurs finiront par disposer des mêmes outils.

Autre précaution: le bruit. Michael Daniel reconnaît franchement que beaucoup de découvertes signalées par IA sont de fausses alertes ou concernent des logiciels jamais exposés à internet. Le goulet d'étranglement semble être le tri, pas la découverte.

Notre verdict

Cessez d'y voir une affaire PHP. Considérez-la comme un test de résistance de votre chaîne de correctifs, et demandez-vous honnêtement combien de temps un correctif critique vous aurait pris cette semaine. Si la réponse est « des semaines », c'est le chantier du prochain trimestre, pas du prochain cycle de correctifs. Faites l'inventaire de ce que vous exploitez, automatisez le déploiement, acceptez un faible risque de casse et retirez les logiciels que vous maintenez en vie par simple inertie. La crue décrite par Michael Daniel viendra de toute façon. Le seul choix est de savoir si vous avez construit un déversoir.