Cybersécurité il y a 3 hAjouter aux favoris
L'équipe de sécurité du noyau Linux publie 432 CVE en 48 heures. Chiffre brut spectaculaire, mais il faut le remettre à sa place : c'est la conséquence directe de la politique CNA adoptée en 2024.
L'équipe de sécurité du noyau Linux publie 432 CVE en deux jours - un pic qui alimente titres alarmants et discussions sur les listes de diffusion. Le chiffre lui-même est incontestable, mais son interprétation demande du contexte.
Depuis février 2024, le projet Linux est devenu CNA (CVE Numbering Authority) auprès de MITRE. Cela signifie que l'équipe kernel peut, elle-même, attribuer des identifiants CVE à ses correctifs de sécurité, sans passer par une entité tierce. Résultat direct : la cadence de publication de CVE a explosé, non pas parce que le noyau est soudainement moins sûr, mais parce que chaque correctif qui pourrait avoir une incidence sécurité reçoit désormais un CVE, par défaut.
Il faut distinguer trois catégories dans cette masse de CVE :
La politique CNA du kernel, défendue par Greg Kroah-Hartman, est explicite : tout correctif qui touche à la sécurité est un CVE, et il revient aux utilisateurs (distributions, entreprises) de trier ce qui les concerne. C'est un renversement de responsabilité par rapport à l'ère « on appelle CVE ce qui est déjà exploité » - plus honnête intellectuellement, mais qui produit ces pics de chiffres.
Le sous-titre de la couverture The Register de l'affaire est explicite : le pic « alimente les spéculations sur des rapports de bugs assistés par IA ». L'idée circule sur les listes kernel depuis plusieurs mois : la démocratisation d'outils qui font tourner du fuzzing intelligent et de l'analyse statique augmentée par LLM produit des rapports de bug en flux tendu, et une partie de ces rapports (les vrais positifs) finit en correctifs qui, sous la politique CNA, deviennent des CVE.
À ce stade, rien n'est confirmé officiellement côté équipe kernel. Le passage à la CNA large suffit largement à expliquer le chiffre brut, sans avoir besoin d'invoquer un facteur IA. Mais la question mérite d'être posée : si demain une part significative des CVE est produite par des outils IA, l'écosystème doit-il traiter ces rapports différemment (canal dédié, revue humaine obligatoire avant CVE, marquage explicite dans les descriptions) ? Le débat n'est pas résolu.
1. Ne paniquez pas devant le chiffre brut : 432 CVE ≠ 432 machines à ré-installer. 2. Suivez les advisories de VOTRE distribution (Debian DSA, Ubuntu USN, Red Hat RHSA) - elles filtrent déjà pour vous. 3. Sur un poste desktop grand public : les mises à jour automatiques hebdomadaires suffisent. 4. Sur une flotte critique : évaluez CVE par CVE via l'outillage habituel (OpenSCAP, kernel-live-patching) au lieu de vouloir tout corriger d'un coup.
Le fond du sujet est un vieux débat de la sécurité open source : quel niveau de granularité pour la divulgation de vulnérabilité ?
L'ancien modèle (« on ne parle que des vraies vulnérabilités exploitées ») avait pour avantage la lisibilité, et pour défaut de créer un CVE noise floor artificiellement bas - les entreprises croyaient leur kernel « propre » alors que des dizaines de bugs sécurité passaient sous le radar chaque mois.
Le nouveau modèle (CNA large) rend la réalité visible, mais inutilisable brut pour la plupart des équipes. La médiation devient le travail des distributions et des outils de patch management, pas celui de l'utilisateur final.
Un chiffre honnête pour se repérer : le noyau Linux corrige environ 1 800 à 2 500 bugs par mois dans les branches stables. La fraction qui touche la sécurité est structurellement significative - le kernel est un monstre de 30+ millions de lignes de C, une bonne partie en code pilote peu audité. Que la publication CVE reflète cette réalité est sain ; que ça donne l'impression d'un incendie ne l'est pas.
À retenir
Article produit par intelligence artificielle, relu sous contrôle éditorial humain.