Cybersécurité : les humains hors-jeu ?
Une faille de sécurité très médiatisée a mis à l’arrêt des milliers de plateformes Web : en cause, les procédures de mise à jour trop lentes, face à l’accélération de l’IA.
Terrain
Lundi, on évoquait avec un client l'accélération à venir des failles de sécurité découvertes « grâce à l'IA ». Deux jours plus tard, on y est.
PHP2Shell, une faille dans le cœur de PHP, le langage de WordPress, de Drupal, et d'une quantité de sites qu'on ne compte plus. Rendue publique le 21 octobre. Des centaines de sites ont été mis à l'arrêt, le temps que le correctif soit appliqué. Même les médias traditionnels en parlent, la BBC, le Guardian. C'est dire si c'est important.
Ça va vite. Beaucoup plus vite qu'avant.
Le mois est devenu l'heure
Le rythme classique (faille découverte, analyse humaine, installation d'un correctif, tests en tous sens) pouvait prendre 7 à 30 jours. Désormais, la faille doit être traitée dans les minutes ou les heures qui suivent sa sortie.
Pire. Des tentatives d'exploitation ont commencé avant la levée de l'embargo. Plusieurs heures avant. Amazon a vu des preuves de concept dès 4 heures du matin, heure de Paris, pour une publication prévue à 16 heures. Une tentative date même du 17 octobre. On ne sait pas encore qui a eu l'information en premier.
Ce qu'on sait, c'est comment la faille a été trouvée. Elle dormait dans le code depuis plus de dix ans. Ce sont des chercheurs, outillés par des modèles d'IA, qui l'ont rendue praticable. Et ce qu'on sait aussi, c'est la suite : une fois le correctif public, ces mêmes outils raccourcissent le trajet jusqu'à l'attaque. Quelques heures. Parfois quelques minutes.
L'intervention humaine, dans ce jeu du chat et de la souris, commence à devenir un goulet d'étranglement. Toutes les équipes vont devoir industrialiser les processus de mise à jour, de déploiement, de test. Seule l'IA possède la vélocité et la capacité de traitement suffisantes pour le faire.
La réécriture n'est plus le chantier qu'on reporte
Et que dire des plateformes développées il y a plusieurs années, sur des technologies obsolètes ? Les réécrire, chose qui paraissait impensable il y a quelques mois encore (parce que ça coûtait trop cher), est devenu une formalité. Il y a un coût, en tokens (ce que facturent les modèles), mais il est sans commune mesure avec le coût d'un développeur qui aurait fait le même travail : on parle de quelques centaines d'euros, face à un chantier de 20 000 euros sur des plateformes conséquentes.
Ce qui change, en revanche, c'est le rythme imposé. Là où la mise à jour était un chantier de plusieurs semaines, qu'on attaquait lors d'une refonte tous les 3 ans, elle devient une routine hebdomadaire, voire quotidienne.
À surveiller néanmoins : l'humain reste garant de l'architecture, et doit s'assurer que l'IA ne bricole pas des rustines intenables.
Ne pas utiliser l'IA pour contrer l'IA devient une posture intenable.
Bref, tout va très vite, les métiers changent, mais l'IA n'a pas encore supprimé tout le travail. Elle crée de nouveaux besoins, qui demandent aux techniciens beaucoup d'adaptation.
Une chose est sûre : qu'on soit pour ou contre l'IA, ça n'empêchera pas les transformations qu'elle fait subir au monde de l'informatique, l'accélération des risques de cybersécurité, et la pression permanente pour tenir à jour les écosystèmes logiciels.
Si votre application a quelques années, et que la mise à jour de sécurité est encore le chantier qu'on ouvre à la refonte d'après, le calendrier ne vous appartient plus. Sécuriser l'existant, industrialiser les déploiements et les tests, réécrire quand les rustines ne tiennent plus : c'est le travail. On l'a déjà mené sans couper le service, jusqu'à refermer une trentaine de failles majeures sur une API de 320 000 lignes. Si le vôtre ressemble à ça, on peut regarder une refonte d'application obsolète, ou en parler directement.