Passer du comptage des CVE à une gestion des vulnérabilités basée sur le risque à l'ère de l'IA

L'intelligence artificielle réduit rapidement la fenêtre entre la découverte d'une vulnérabilité et son exploitation active, imposant un changement fondamental dans la manière dont les équipes d'ingénierie gèrent la dette de sécurité. À mesure que le volume de logiciels augmente et que l'automatisation des attaques s'améliore, le suivi traditionnel des Common Vulnerabilities and Exposures (CVE) via des feuilles de calcul ne fournit plus une image précise du risque organisationnel.

Ce qui s'est passé

Le modèle traditionnel de gestion des vulnérabilités est resté largement inchangé pendant des années : scanner le code, identifier les CVE, attribuer des scores de sévérité via le Common Vulnerability Scoring System (CVSS), puis transmettre la liste aux développeurs pour correction. Cette approche supposait que la sévérité technique était directement corrélée au risque commercial. Cependant, le paysage actuel révèle un écart croissant entre le nombre de vulnérabilités que les équipes de sécurité peuvent identifier et celles qu'elles peuvent réellement investiguer et corriger.

Cet écart se creuse car l'IA accélère à la fois la production logicielle et la sophistication des attaques. Bien que la densité de vulnérabilités par ligne de code puisse diminuer, le volume massif de logiciels générés augmente globalement l'exposition. Parallèlement, les attaquants utilisent l'IA pour automatiser des tâches nécessitant auparavant un effort manuel significatif, combinant les vulnérabilités de manière imprévisible pour créer de nouvelles voies d'attaque. Le résultat est que les organisations sont submergées par les données mais manquent cruellement de contexte, conduisant à ce que certains experts appellent le « théâtre des CVE », où les équipes mesurent l'activité plutôt que la réduction réelle du risque.

Le problème central est qu'une CVE indique l'existence d'une faille publiquement identifiée, mais ne précise pas si cette faille est exploitable dans un environnement spécifique. Deux organisations peuvent avoir la même CVE, mais si l'une dispose du composant vulnérable derrière plusieurs couches de sécurité sans exposition externe, tandis que l'autre l'exécute dans une application de production exposée à Internet, leurs profils de risque sont radicalement différents. Les traiter de manière égante gaspille les ressources d'ingénierie sur des éléments à faible risque tout en laissant des expositions critiques non traitées.

Comment cela fonctionne

Pour combler cet écart, les programmes de sécurité doivent passer d'un scoring de sévérité statique à une évaluation du risque contextuelle et continue. Cela commence par la réduction de l'empreinte de vulnérabilité avant le déploiement, en utilisant des images de base durcies et des bibliothèques de langage sélectionnées. Le code de première partie est sécurisé grâce aux tests de sécurité applicatifs statiques (SAST) et au scanning assisté par IA, tandis que les faiblesses de configuration sont adressées via des frameworks tels que les Security Technical Implementation Guides (STIGs). Ces checklists automatisées identifient des problèmes tels que des privilèges excessifs ou une authentification faible, qui peuvent être aussi dangereux que les vulnérabilités de code.

Crucialement, l'attention se porte sur le scan de ce qui tourne réellement en production, car les registres et les dépôts ne reflètent que le risque perçu. Les environnements de production changent constamment, nécessitant une visibilité continue. Les outils effectuent une analyse d'atteignabilité pour déterminer si un chemin de code vulnérable est réellement exécuté et si le système est accessible de l'extérieur. Ce contexte environnemental permet aux équipes de distinguer les vulnérabilités théoriques de celles qui présentent des menaces immédiates et exploitables.

Enfin, les priorités de remédiation sont définies en combinant les signaux de renseignement sur les menaces, tels que le catalogue Known Exploited Vulnerabilities (KEV) de la CISA et l'Exploit Prediction Scoring System (EPSS), avec les données d'exposition en production. Cela crée un modèle dynamique qui répond à la question de savoir quelle vulnérabilité doit être corrigée en premier, dans cet environnement spécifique, et pourquoi, plutôt que de se reposer sur une liste statique triée par score CVSS.

Détails clés

• L'IA accélère le développement d'exploits, réduisant le temps entre la divulgation de la vulnérabilité et l'attaque active.
• Les scores CVSS mesurent la sévérité technique mais ne tiennent pas compte de l'exposition environnementale ni de la probabilité d'exploitation.
• Le « théâtre des CVE » survient lorsque les équipes priorisent la fermeture d'un grand volume de découvertes sans réduire le risque consécutif.
• Le scan de production fournit la source de vérité sur ce qui est réellement déployé et exécuté.
• L'analyse d'atteignabilité détermine si les chemins de code vulnérables sont exécutés et si les systèmes sont accessibles de l'extérieur.
• Les sources de renseignement sur les menaces comme KEV et EPSS aident à estimer la probabilité d'exploitation dans un délai donné.

Pourquoi c'est important

Pour les ingénieurs logiciels et les responsables techniques, ce changement signifie s'éloigner d'une remédiation réactive basée sur le volume vers une approche plus stratégique, basée sur le risque. L'ancien modèle consistant à remettre aux développeurs une feuille de calcul contenant des milliers de CVE n'est pas durable dans un paysage de menaces piloté par l'IA. Il conduit à la fatigue d'alerte et à une allocation erronée des ressources, où les bugs critiques sont noyés sous le bruit. En se concentrant sur le contexte, les équipes peuvent réduire la charge cognitive des développeurs et s'assurer que les efforts de remédiation ciblent les failles qui comptent réellement pour l'entreprise.

De plus, cette approche aligne les objectifs de sécurité avec la réalité opérationnelle. Comprendre quelles portes sont ouvertes, lesquelles un attaquant peut atteindre, et lesquelles mènent à des actifs critiques permet une meilleure prise de décision. Cela transforme la sécurité d'un goulot d'étranglement en un processus d'amélioration continue. Comme le note Russ Andersson : « Nous devons savoir quelles portes sont ouvertes, lesquelles un attaquant peut atteindre, lesquelles mènent quelque part d'important, et lesquelles représentent le plus grand risque actuellement. »

Ce que vous pouvez faire

• Remplacez la priorisation statique basée sur le CVSS par des modèles de risque incluant les données d'exposition en production et d'atteignabilité.
• Implémentez un scan continu de production pour maintenir la visibilité sur ce qui tourne réellement dans votre environnement.
• Utilisez des images de base durcies et des bibliothèques sélectionnées pour réduire l'empreinte initiale de vulnérabilité des applications.
• Intégrez des flux de renseignement sur les menaces comme CISA KEV et EPSS pour évaluer la probabilité d'exploitation active.
• Automatisez les vérifications de configuration en utilisant les STIGs pour identifier et corriger les faiblesses de sécurité dans les paramètres et les privilèges.
• Établissez une discipline temporelle en définissant différentes fenêtres de remédiation pour les vulnérabilités en fonction de leur niveau de risque réel.