Il y a une semaine, la faille de sécurité « Copy Fail » a été révélée. Hyunwoo Kim s'est immédiatement rendu compte que le correctif officiel était insuffisant et a soumis son propre patch dans la journée. Dans ce processus, il a suivi les procédures standard du domaine Linux, en particulier pour l'aspect réseau : informer les ingénieurs en sécurité Linux spécifiques tout en corrigeant efficacement et discrètement la vulnérabilité sur des canaux publics. Son objectif était de ne divulguer que le patch initial afin d'imposer un « blocage » à l'annonce selon laquelle « une grave vulnérabilité existait », c'est-à-dire qu'un accord tacite entre ceux qui étaient au courant maintiendrait le silence pendant quelques jours. Cependant, quelqu'un a remarqué cette modification, en a identifié les implications sécuritaires et les a rendues publiques. Comme l'information avait déjà fuité, le protocole de blocage a été considéré comme rompu, et tous les détails de la vulnérabilité ont été publiés. Cet événement met en lumière la tension entre deux approches différentes de gestion des vulnérabilités et suscite des réflexions sur la façon dont l'accélération par IA pourrait modifier cet état de fait. D'une part, il existe une culture dite de « divulgation coordonnée ». Il s'agit probablement de la méthode la plus répandue dans le domaine de la cybersécurité : après avoir découvert une faille de sécurité, on informe discrètement les responsables de maintenance et on leur accorde une période de correction (généralement de 90 jours) visant à garantir que le correctif soit prêt avant toute publication publique de la vulnérabilité. De l'autre côté se trouve une culture dite « la vulnérabilité est une vulnérabilité », particulièrement courante dans la communauté Linux. Selon cette approche, si le noyau exécute quelque chose qu'il ne devrait pas faire, alors quelqu'un pourra toujours transformer cela en attaque ; il faut donc réparer aussi rapidement que possible sans attirer l'attention. Généralement, parmi des masses énormes de modifications de code, ces patches passent inaperçus, offrant ainsi aux machines le temps nécessaire pour appliquer les mises à jour. Cette méthode n'a jamais atteint sa perfection et, avec l'amélioration croissante des capacités de détection des failles par l'IA, elle fait face à des défis majeurs. Aujourd'hui où les corrections de sécurité sont omniprésentes, l'examen des historiques de soumission devient extrêmement attractif car le rapport signal/bruit est meilleur. Par ailleurs, l'évaluation systématique de chaque soumission grâce à l'IA devient de moins en moins coûteuse et de plus en plus efficace. Toutefois, le maintien prolongé d'un secret d'information devient également insoutenable. Autrefois, le rythme de détection était lent : si vous découvriez une faille et offriez à l'éditeur une fenêtre de divulgation de 90 jours, presque personne d'autre ne la découvrirait durant cette période. Maintenant, de nombreuses équipes assistées par l'effectuent des scans continus sur les logiciels, rendant ce scénario obsolète. Dans ce cas précis, Kuan-Ting Chen a indépendamment rapporté la même faille ESP seulement neuf heures après que Kim ait effectué son signalement. Le blocage peut paradoxalement accroître les risques : il crée une fausse impression de non-urgence et restreint le nombre de personnes impliquées dans la réparation. Bien qu'aucune conclusion définitive n'ait encore été tirée, je pense personnellement qu'un blocage temporaire semble être le compromis le plus judicieux et que, avec le temps, cette fenêtre doit être davantage réduite. Heureusement, tandis que l'IA renforce les attaquants, elle accélère également les défenseurs, rendant viables des périodes de blocage autrefois jugées trop courtes pour être efficaces.