Plus tôt en octobre 2026, des ingénieurs d’Amazon Web Services (AWS) ont présenté à Prague un processus de tri des CVE du noyau Linux maintenu pour l’infrastructure EC2. Un script filtre d’abord les vulnérabilités applicables à l’image du noyau; une IA classe celles qui restent, puis des ingénieurs examinent ses résultats. Ce noyau est distinct d’Amazon Linux et de ceux que les clients exécutent dans leurs machines virtuelles.
Comment AWS filtre les CVE avant la revue
Une CVE est un identifiant public associé à une vulnérabilité. Le premier filtre d’AWS compare les versions concernées et les fichiers cités dans chaque fiche CVE avec la version du noyau et les fichiers intégrés à l’image EC2. Cette étape repose sur un script, pas sur l’IA.
AWS indique que ce filtre écarte environ 70 % des CVE dans son environnement. La proportion dépend fortement de la configuration et de l’environnement concernés. Les ingénieurs transmettent ensuite à l’agent le code du noyau personnalisé, sa configuration, un modèle de menace et une grille de gravité. L’agent traite chaque CVE restante en un passage et produit un tableau indiquant notamment le sous-système, le type de vulnérabilité et le vecteur d’attaque.
L’IA classe, les ingénieurs gardent la main
AWS a rapporté un temps de traitement d’environ 3,4 secondes par CVE pour l’agent, contre plusieurs minutes pour le triage humain. Ce chiffre concerne la classification, pas l’examen du résultat, la correction, les tests ou le déploiement. Deux ingénieurs examinent généralement le tableau, et cette revue humaine reste l’étape la plus lente du processus.
Justinien Bouron a avancé, à titre informel, que 5 à 10 % des décisions de l’agent posaient problème. Cette estimation ne constitue pas un taux d’erreur mesuré selon une méthode formelle.
Le triage sert ensuite à choisir une réponse adaptée au cas. AWS cite quatre options : ne rien faire si la CVE ne concerne pas l’environnement, attendre le prochain correctif LTS si son impact le permet, intégrer une correction ciblée par cherry-pick lorsqu’une intervention plus rapide est nécessaire, ou recourir à une solution de contournement quand une mise à jour du noyau est impossible. LTS désigne une branche Linux bénéficiant d’une prise en charge à long terme.
Une mise à niveau mobilise aussi l’espace utilisateur
Pour le passage de Linux 5.10 à 6.12, AWS a réparti les problèmes suivis entre quatre catégories. Ces parts concernent les problèmes rencontrés pendant la mise à niveau, pas des CVE ni du temps de correction.
| Catégorie de problème suivi | Part des problèmes suivis |
| Espace noyau | 45 % |
| Espace utilisateur | 43 % |
| Configuration du noyau | 7 % |
| Micrologiciel ou matériel | 5 % |
AWS a également indiqué que 15 % des corrections apportées dans l’espace noyau avaient été intégrées au noyau amont. Les problèmes relevés illustrent l’étendue des vérifications nécessaires : une modification du stockage des zones de mémoire virtuelle a ralenti mmap() et munmap(), tandis qu’un changement de l’ordonnanceur a modifié le comportement temporel de fork(). Une hausse de la taille maximale par défaut des requêtes du sous-système de blocs a, elle, provoqué des délais d’attente d’E/S du micrologiciel, traités par un réglage sysctl.
AWS a rapporté des durées de mise à niveau de 24 mois pour le passage de 4.19 à 5.10, de 12 mois pour celui de 5.10 à 6.12 et de 6 mois pour celui de 6.12 à 6.18. La présentation attribue cette réduction à de meilleurs outils, à une couverture de tests plus large et à l’expérience de l’équipe, plutôt qu’au seul écart d’âge entre les branches LTS.
Les chiffres des branches LTS ne mesurent pas l’exposition d’EC2
La photographie AWS du 16 septembre 2026 recense les CVE non corrigées par branche Linux. Ces totaux décrivent les branches, pas le nombre de vulnérabilités qui touchent le noyau déployé par AWS sur EC2. Les branches 4.19 et 5.4, signalées en fin de vie, comptaient respectivement 3 725 et 3 481 CVE non corrigées.
| Branche LTS Linux | CVE non corrigées au 16 septembre 2026 | Médiane entre l’intégration du correctif dans mainline et sa publication en LTS (jours) |
| 5.10 | 1 709 | 31,8 |
| 5.15 | 1 567 | 31,5 |
| 6.1 | 1 062 | 28,8 |
| 6.6 | 762 | 23,1 |
| 6.12 | 483 | 19,0 |
| 6.18 | 229 | 18,1 |
La médiane mesure ici le délai entre l’intégration d’un correctif dans la branche principale du noyau et sa publication dans une branche LTS. Ce n’est pas le temps nécessaire à AWS pour déployer une mise à jour.
Au 27 octobre 2026, AWS n’avait pas publié les outils décrits. Dylan Johnson indiquait que l’équipe souhaitait étudier la possibilité de partager le filtre.
