Linux face à l'apocalypse des vulnérabilités, l'intelligence artificielle en première ligne
Depuis des années, Linux subit des mises à jour constantes. Mais l'arrivée de outils d'intelligence artificielle capable d'analyser des quantités énormes de code change tout le rythme auquel apparaissent les bugs.
Les failles à la surface, la sécurité prend de l'ampleur
Des erreurs qui pouvaient rester cachées pendant des années maintenant émergent avec une fréquence beaucoup plus élevée, ce qui améliore la sécurité à long terme, même si cela génère une avalanche de rapports que les maintaineurs ont du mal à examiner à un rythme égal. La magnitude du problème est apparue clairement lorsque l'équipe responsable du noyau a publié 432 vulnérabilités CVE en seulement deux jours.
La majorité n'étaient pas critiques et n'avaient pas été découvertes grâce à l'IA, car Greg Kroah-Hartman a expliqué que beaucoup correspondaient à une file de travail accumulée pendant plusieurs semaines. Cependant, cet épisode a montré que le processus actuel peut être débordé lorsque des centaines d'avis arrivent presque simultanément, ce qui peut devenir un total chaos pour tous les maintaineurs du noyau Linux.
L'ia révèle des bugs anciens, mais exacerbés
Depuis longtemps, de nombreux rapports générés par des modèles décrivaient des erreurs inexistantes ou des problèmes mal interprétés, ce qui obligeait les maintaineurs à perdre des heures à vérifier les résultats qui ne contribuaient rien. Kroah-Hartman affirme que cela change car les outils actuels peuvent suivre des trajectoires d'exécution complexes, détecter des comportements suspects et indiquer des zones du noyau qui méritent une enquête réelle.
Chaque trouvaille nécessite toujours une révision humaine, mais la qualité des résultats s'est améliorée de manière évidente, et GhostLock en est un exemple clair. Cette vulnérabilité, enregistrée sous le numéro CVE-2026-43499, était présente dans Linux depuis environ 15 ans avant d'être localisée grâce à VEGA, une plateforme de Nebula Security assistée par l'IA.
Il est important de noter que le fait que 432 CVE signifie que tous les systèmes soient exposés n'est pas nécessairement le cas. Un identifiant CVE peut correspondre à une vulnérabilité grave, mais il peut également affecter uniquement un contrôleur spécifique, une fonction peu utilisée ou une configuration très particulière, de sorte que les entreprises ne doivent pas nécessairement traiter les 432 avis comme s'ils représentaient le même niveau de risque.
La difficulté réside en ceci de déterminer lesquels affectent vraiment chaque infrastructure. Pour y parvenir, les entreprises doivent comparer les correctifs aux composants qu'elles utilisent et vérifier que chaque patch ne provoque pas d'incompatibilités, ce qui peut être délicat lorsqu'il s'agit d'équipements qui doivent rester opérationnels.
Les entreprises doivent s'adapter, pas inquiéter
Jan Schaumann, responsable de la sécurité d'Akamai, considère que l'étude manuelle de centaines de modifications n'est plus une stratégie réaliste, il défend donc de mettre à jour plus fréquemment et de dépendre moins d'une sélection individuelle de patches. Le problème est que nombre d'organisations doivent préalablement tester chaque changement.
Une correction peut Closed une vulnérabilité et, en même temps, briser un contrôleur ou affecter à une outil interne qui est essentiel au fonctionnement quotidien. Kroah-Hartman pense que les entreprises doivent utiliser des versions maintenues et se fier à des distributions capables de tester les mises à jour avant de les publier. Elles peuvent également automatiser la comparaison entre les fichiers modifiés et les composants présents dans chaque système pour réduire le nombre de cas qui nécessitent une révision manuelle.
Les 18 prochains mois vont changer la façon de maintenir Linux, a affirmé Kroah-Hartman. Le problème ne réside pas uniquement dans le nombre de vulnérabilités, mais dans des processus de maintenance trop lents par rapport au nouveau rythme de découverte. Par conséquent, il recommande l'utilisation de versions supportées, l'application de mises à jour completes ainsi que la confiance en des distributions ou fournisseurs capables de les tester. Il rappelle également que les entreprises ne doivent pas traiter tous les CVE comme si ils affectaient leurs systèmes. Comparer automatiquement les fichiers modifiés aux composants installés peut réduire de manière importante le nombre de cas pertinents.
Kroah-Hartman parle de