Dans un billet de blog daté du 10 décembre 2025, Simcha Kosman décrit une méthode qui combine analyse statique CodeQL et raisonnement LLM afin de réduire drastiquement les faux positifs et de concentrer les équipes sur des failles réellement exploitables.

L’auteur introduit l’outil Vulnhalla, conçu pour laisser passer uniquement les « vrais » problèmes. En moins de 48 h et pour moins de 80 $, l’approche a permis d’identifier des vulnérabilités publiées sous les identifiants CVE-2025-38676 (Linux Kernel), CVE-2025-0518 (FFmpeg), CVE-2025-27151 (Redis), CVE-2025-8854 (Bullet3), CVE-2025-9136 (RetroArch), CVE-2025-9809 (Libretro) et CVE-2025-9810 (Linenoise), avec divulgation responsable préalable aux éditeurs.

Le texte expose deux difficultés majeures des LLM appliqués à la chasse aux vulnérabilités: le problème du WHERE (où regarder dans d’immenses bases de code) et du WHAT (quel type de bug chercher). Il compare cette approche aux travaux de Google DeepMind (NapTime/Deep Sleep), qui s’appuient sur l’analyse de correctifs liés à des CVE, et à OpenAI (Aardvark), focalisé sur les commits introduisant des failles potentielles. Chaque stratégie traite partiellement le « où » et/ou le « quoi », mais présente des limites d’évolutivité ou de couverture.

Côté analyse statique, CodeQL génère un volume massif d’alertes, dont une forte proportion de faux positifs, rendant l’inspection manuelle impraticable à grande échelle. L’article illustre un cas de faux positif autour de memcpy et montre qu’un LLM, privé de contexte suffisant, ne peut pas trancher. La solution proposée: fournir au LLM les résultats CodeQL puis laisser le modèle demander le contexte nécessaire à la demande (fonction complète, appels adjacents, etc.). L’auteur détaille les difficultés techniques pour extraire correctement le contexte en C (impossibilité d’utiliser des regex, complexités liées aux macros, commentaires, pointeurs de fonction) et explique pourquoi des indexeurs de code comme Elixir se sont révélés peu pratiques (indexation très longue, dépendances via submodules non gérées), avant d’orienter l’utilisation de CodeQL comme navigateur de code.

Vulnhalla se présente ainsi comme un workflow outillé pour trier intelligemment les résultats de CodeQL via un LLM, réduisant le bruit et accélérant la découverte de failles. L’article est une publication technique visant à démontrer la viabilité de l’approche et à partager la méthodologie, tout en signalant des résultats concrets (CVE) et des pistes en cours.

Vulnérabilités identifiées (exemples) :

  • CVE-2025-38676 — Linux Kernel
  • CVE-2025-0518 — FFmpeg
  • CVE-2025-27151 — Redis
  • CVE-2025-8854 — Bullet3
  • CVE-2025-9136 — RetroArch
  • CVE-2025-9809 — Libretro
  • CVE-2025-9810 — Linenoise

TTPs (techniques/outils/processus) :

  • 🧰 Analyse statique via CodeQL et requêtes ciblées
  • 🧠 Triage LLM des alertes, avec contexte à la demande
  • 🔎 Utilisation de CodeQL comme navigateur de code pour extraire le contexte pertinent
  • 🔄 Référence aux approches patch/commit-centric (Deep Sleep, Aardvark) pour cadrer le « WHERE/WHAT »

Conclusion: un article de publication de recherche présentant une méthodologie et un outil nouveaux pour optimiser la chasse aux vulnérabilités en combinant LLM et analyse statique.

🔗 Source originale : https://www.cyberark.com/resources/threat-research-blog/vulnhalla-picking-the-true-vulnerabilities-from-the-codeql-haystack