Contexte et évolution des rapports de vulnérabilité

Le projet GNOME, développé majoritairement en C, C++ et Vala, a longtemps souffert de défauts de sécurité liés à la nature non sécurisée de ces langages. Les présentations de l’auteur en 2024 et 2025 décrivaient une incapacité humaine à garantir la qualité du code. En 2026, l’émergence d’outils d’analyse basés sur des modèles de langage a modifié ce constat, les mainteneurs affirmant que l’IA est désormais indispensable pour identifier les failles avant les attaquants.

Apport de l’IA dans la détection

Les modèles d’IA sont capables de parcourir le code source, d’identifier des patterns de débordement de tampon ou d’utilisation après libération, puis de générer un rapport de vulnérabilité. Selon l’auteur, la plupart des rapports produits en 2026 sont « assez bons », même si certains contiennent des traces de pile factices ou des exagérations de gravité. Cette variabilité impose une relecture humaine, mais le volume de rapports dépasse largement la capacité des bénévoles GNOME.

Analyse des données de CVE 2021‑2026

Year   GNOME CVEs   Excl. GIMP,Gegl,libxml2,libxslt
2021   21           14
2022   14           6
2023   13           4
2024   37           28
2025   97           49
2026*  141          74
2026*  Normalized   188          99

Le tableau montre une progression annuelle du nombre de CVE publiés par GNOME, passant de 21 en 2021 à 141 en 2026 (au 30 septembre). Même en excluant les projets tiers, les CVE restent en hausse (de 14 à 74). L’auteur explique que cette augmentation reflète l’efficacité accrue des scans IA, qui détectent des vulnérabilités auparavant invisibles. La normalisation (multiplication par 4/3) indique une tentative de comparer les années avec des pratiques de reporting différentes.

Enjeux pour les mainteneurs

Les rapports IA sont souvent très détaillés, ce qui alourdit la charge de validation. Rewriter les rapports pour éliminer le contenu généré ne scale pas : le temps nécessaire pour examiner 100 rapports dépasse les ressources disponibles. Certains projets ont tenté d’interdire les contributions IA, mais l’auteur argue que cela équivaut à refuser la plupart des rapports de vulnérabilité, rendant le projet moins attractif pour les contributeurs externes. La recommandation est de réviser les politiques internes afin de permettre les rapports IA tout en renforçant les processus de revue, par exemple en automatisant la détection de faux positifs ou de traces factices.