NVD à l’ère de l’IA : pourquoi miser sur des renseignements sur les vulnérabilités issus de sources multiples

Depuis plus de vingt ans, la communauté mondiale de la sécurité s’appuie sur une hypothèse rassurante : une source publique centralisée pouvait aider à suivre, analyser et enrichir les données sur les vulnérabilités logicielles dans le monde, au rythme exigé par le secteur.

À la création de la National Vulnerability Database (NVD), le cycle de vie des vulnérabilités open source évoluait à un rythme radicalement différent. Les écosystèmes open source étaient plus restreints, les cycles de publication plus longs et le volume de vulnérabilités divulguées publiquement plus facile à gérer grâce à un enrichissement centralisé.

Mais l’écosystème logiciel actuel a officiellement dépassé ce modèle hérité. Le 15 avril 2026, le National Institute of Standards and Technology (NIST) a recalibré son approche opérationnelle et fait évoluer son mandat de longue date visant l’enrichissement universel des vulnérabilités. Face à un afflux insoutenable de soumissions, l’agence a annoncé un modèle de triage priorisé, précisant explicitement qu’avec les ressources actuelles, enrichir intégralement chaque CVE n’est plus un objectif réaliste.

Ce que cela change pour Snyk

Impact général : fonctionner de manière indépendante

Snyk ne s’appuie pas uniquement sur la NVD pour enrichir les données sur les vulnérabilités ; l’annonce du NIST ne change donc pas notre approche en matière de renseignements sur les vulnérabilités. Elle confirme plutôt l’approche que nous suivons depuis des années, comme nous l’expliquions dans « Comment les utilisateurs de Snyk évitent les retards de la NVD » : la NVD reste une source importante, mais elle ne représente qu’une partie d’un écosystème de renseignements plus vaste, qui comprend plusieurs sources de vulnérabilités, la validation par des analystes de sécurité et le contexte open source.

Cette approche aide les clients à continuer de prendre des décisions éclairées en matière de priorisation, même à mesure que les modèles publics d’enrichissement évoluent.

Au lieu de dépendre des cycles de validation du secteur public, nous enrichissons nos données au moyen de processus internes à plusieurs niveaux. Le cas échéant, nous présentons les vecteurs CVSS de la NVD à côté de nos propres évaluations CVSS afin de vous aider à comprendre comment une vulnérabilité est évaluée selon les différentes sources. Snyk Intelligence aide les clients à comprendre non seulement si une CVE existe, mais aussi ce qu’elle signifie dans le contexte des logiciels open source. La solution précise les versions de packages vulnérables, indique si un correctif est disponible, explique comment le risque est évalué selon les sources et montre exactement comment prioriser la remédiation.

En plus de recueillir des avis de sécurité provenant de diverses sources, Snyk enrichit et réévalue continuellement sa base de données de sécurité, qu’il met à jour grâce aux éléments suivants :

• Recherche en sécurité menée en interne

• Intégration des renseignements sur les menaces : divers signaux, notamment les activités d’exploitation, les mentions sur les réseaux sociaux et la publication de preuves de concept

• Contributions de la communauté : divulgations responsables de la communauté open source, notamment de chercheurs indépendants et de responsables de projets

• Collaborations universitaires et de recherche

• Priorisation axée sur les clients : aider les clients à transformer les données brutes sur les vulnérabilités en renseignements exploitables, qui facilitent la priorisation par les développeurs et les équipes AppSec

• Renseignements assistés par l’IA et validés par des experts : Face à l’augmentation du nombre de vulnérabilités, Snyk utilise des processus assistés par l’IA et l’automatisation pour recueillir, filtrer, prioriser et enrichir à grande échelle les signaux de vulnérabilité en grand volume. Mais l’automatisation ne suffit pas. Snyk maintient une approche avec intervention humaine, dans laquelle des analystes de sécurité qualifiés valident et approuvent les suggestions générées par l’IA, afin de fournir aux clients des renseignements fiables, exacts et exploitables sur les vulnérabilités.

Une nouvelle ère pour les données sur les menaces

Que change exactement cette décision ?

La NVD est passée à un modèle de triage fondé sur les risques, abandonnant l’objectif précédent d’un enrichissement universel et immédiat des vulnérabilités. Ce changement structurel pourrait créer d’importantes lacunes dans la visibilité du secteur, en particulier pour les scanners hérités qui dépendent fortement des données de la NVD pour obtenir des scores CVSS et enrichir les données sur les logiciels qui ne sont plus considérés comme prioritaires. Dans le cadre de cette nouvelle approche, la NVD donnera désormais la priorité à l’enrichissement complet des CVE qui répondent à l’un des critères suivants :

• Les CVE figurant dans le catalogue des vulnérabilités exploitées connues (KEV) de la CISA (avec pour objectif de les enrichir dans un délai d’un jour ouvrable après réception).

• Les CVE concernant des logiciels utilisés au sein du gouvernement fédéral américain.

• Les CVE concernant des logiciels critiques, selon la définition du décret présidentiel 14028.

Toute CVE qui ne relève pas de ces catégories est systématiquement classée comme « Priorité la plus basse – aucun enrichissement immédiat prévu ». Pour saisir l’ampleur de cette lacune, examinons les chiffres : alors que 48 185 CVE uniques ont été publiées en 2025 seulement, le catalogue KEV de la CISA recense environ 245 nouvelles entrées à la fin de 2025. Pour en savoir plus sur le volume de vulnérabilités en 2026 et les tendances du catalogue KEV, consultez Les vulnérabilités exploitées connues de la CISA ont bondi de 20 % en 2025.
S’en tenir strictement à ce cadre public revient à configurer les scanners des organisations pour qu’ils ciblent une liste très sélective, approuvée par le gouvernement. Elles risquent ainsi de passer à côté d’un contexte essentiel concernant le vaste univers des packages open source qui, même s’ils ne sont pas actuellement considérés comme critiques ou activement exploités, restent au fondement de la sécurité des applications modernes.

En outre, une part importante des CVE historiques publiées avant le 1er mars 2026 a été classée comme « Non planifiée », tandis que beaucoup d’autres ont reçu le statut « Modifiée après enrichissement ». Cela signifie qu’elles ne seront pas nécessairement réévaluées, contrairement à ce qui se serait produit avec l’ancien modèle. Cette situation résulte du reclassement des vulnérabilités en attente dans le cadre du modèle d’enrichissement mis à jour et illustre l’ampleur de la gestion des retards désormais intégrée à la nouvelle approche.

Point essentiel, le NIST a également apporté un changement opérationnel important à la manière dont il traite les scores et les modifications, afin de réduire les tâches en double :

• Simplification des scores de gravité : le NIST ne fournira plus systématiquement un score de gravité distinct lorsque l’autorité de numérotation CVE (CNA) qui soumet la vulnérabilité — par exemple le fournisseur du logiciel ou le responsable du package — en a déjà fourni un.

• Traitement des CVE modifiées : au lieu de réanalyser toutes les CVE modifiées, comme le prévoyait auparavant la politique, le NIST ne le fera désormais que s’il a connaissance d’une modification ayant un impact significatif sur les données d’enrichissement.

Les équipes de sécurité doivent donc mieux comprendre la source et le contexte de l’enrichissement des vulnérabilités. Lorsque le NIST ne fournit pas de score de gravité indépendant supplémentaire, les organisations peuvent devoir s’appuyer davantage sur les scores fournis par les CNA, les métadonnées des fournisseurs et d’autres sources d’enrichissement. Les données fournies par les CNA sont précieuses et proviennent souvent des responsables les plus proches du logiciel concerné, mais elles peuvent aussi présenter des différences dans les méthodes de notation, l’interprétation des risques, les incitations à la divulgation ou les contraintes opérationnelles, comme les délais de remédiation et les exigences des SLA.
La transparence des sources, la validation indépendante et les renseignements sur les vulnérabilités issus de sources multiples sont donc plus importants que jamais.

C’était inévitable

Ce changement ne s’est pas produit du jour au lendemain : il est l’aboutissement de plusieurs années de tensions sur le système de gestion des vulnérabilités de facto. Lorsque le nombre annuel de soumissions de CVE a augmenté de 263 %, passant d’environ 18 000 entrées en 2020 à plus de 48 000 en 2025, les processus de la NVD n’ont tout simplement plus pu suivre. Cette hausse s’explique par des changements structurels du système CVE, qui a adopté un modèle fédéré plutôt que centralisé pour l’attribution des CVE. Cela a supprimé un goulot d’étranglement administratif tout en permettant à un ensemble beaucoup plus vaste et diversifié d’organismes de contribuer au catalogue public des vulnérabilités. Dans le même temps, l’IA accélère le rythme de la recherche sur les vulnérabilités. Elle aide les chercheurs à avancer plus vite à chaque étape, de la découverte et de la validation à la création de preuves de concept et à la rédaction des rapports. Cela ne signifie pas que tous les rapports générés par l’IA sont de qualité, mais leur nombre et la rapidité d’apparition des signaux de vulnérabilité devraient continuer d’augmenter.

La mise à jour du NIST reflète cette réalité. Même après avoir enrichi près de 42 000 CVE en 2025 — soit 45 % de plus que toute autre année — le NIST a déclaré que les gains de productivité ne suffisaient toujours pas à suivre l’augmentation des soumissions.

Le nouveau modèle fondé sur les risques vise à aider le NIST à se concentrer sur les CVE les plus critiques, tout en stabilisant le programme et en développant les systèmes automatisés et les améliorations de processus nécessaires à sa viabilité à long terme. Ainsi, même si la responsabilité de fournir des données de qualité au processus de gestion des vulnérabilités revient davantage aux fournisseurs de logiciels et aux personnes qui signalent les vulnérabilités, il revient aux utilisateurs finaux et aux outils qu’ils utilisent de donner du sens à l’ensemble.

Pourquoi cela se produit-il maintenant ?

La principale cause de cette hausse exponentielle des CVE se résume à deux lettres : IA.
Comme nous l’expliquons dans notre analyse approfondie « La recherche sur les vulnérabilités à l’ère de l’IA », l’intelligence artificielle a complètement transformé l’économie de la recherche de bogues. Les outils de détection automatisés basés sur l’IA peuvent analyser des bases de code de manière autonome, repérer des failles et générer des milliers de rapports de vulnérabilité bruts en une fraction du temps nécessaire à un chercheur humain pour obtenir les mêmes résultats.
Cela crée une boucle de rétroaction continue : les outils de détection basés sur l’IA se multiplient et analysent exhaustivement les bases de code existantes, injectant un volume inédit de données dans l’univers des vulnérabilités.

Toutefois, cette hausse ne s’explique pas uniquement par l’IA ; elle découle aussi d’un changement opérationnel majeur dans le signalement des vulnérabilités. La croissance exponentielle a commencé plusieurs années plus tôt avec l’essor du modèle CVE fédéré. En 2018, le programme a été décentralisé grâce à une expansion rapide de son réseau d’autorités de numérotation CVE (CNA). Alors que seules quelques organisations s’occupaient auparavant de la saisie des données, plus de 500 CNA indépendantes publient désormais leurs divulgations directement et simultanément dans le catalogue mondial. Elles comprennent des éditeurs de logiciels, des responsables de packages et des fournisseurs cloud.

Chez Snyk, nous considérons que c’est l’une des raisons pour lesquelles les renseignements sur les vulnérabilités doivent évoluer. Le défi ne consiste pas simplement à recueillir davantage de données. Il s’agit de leur donner du contexte, de les valider et de les enrichir, puis de les prioriser pour que les équipes de sécurité et de développement puissent se concentrer sur les problèmes qui comptent vraiment.

Privilégier la qualité au bruit

Les équipes de sécurité et de développement ont besoin de renseignements sur les vulnérabilités auxquels elles peuvent se fier, qu’elles peuvent comprendre et auxquels elles peuvent donner suite.

Snyk mise sur une cartographie précise des vulnérabilités. Au lieu d’attribuer le risque à un projet open source dans son ensemble, Snyk Open Source identifie, dans la mesure du possible, le package concerné, la plage de versions vulnérables, le composant ou le chemin de code en cause, le correctif disponible et les éléments qui étayent l’avis. Cela réduit le bruit inutile et donne aux développeurs et aux agents de remédiation des indications plus claires sur ce qui doit réellement être corrigé.

Comme indiqué plus haut, les rapports générés par l’IA peuvent aider à repérer des pistes utiles, mais notre expérience montre qu’ils produisent aussi fréquemment des analyses incomplètes, des résultats en double et des signaux de faible qualité qui nécessitent une validation rigoureuse. Nous avons constaté à plusieurs reprises que des rapports de vulnérabilité ne reposaient pas sur des preuves suffisantes, évaluaient les répercussions de manière peu claire ou présentaient des résultats qui ne résistaient finalement pas à l’examen des responsables de projets. Par exemple, lorsqu’un responsable de projet rejette un rapport de vulnérabilité, Snyk procède à un examen supplémentaire avant de décider si, et comment, cette vulnérabilité doit figurer dans les renseignements de Snyk sur les vulnérabilités.

Cette approche délibérément axée sur les preuves, l’attribution et la validation contribue à réduire la fatigue liée aux alertes et permet aux équipes d’ingénierie et d’AppSec de se concentrer sur les vulnérabilités exactes, pertinentes et exploitables.

Et maintenant ?

La mise à jour du NVD montre clairement que la gestion des vulnérabilités entre dans une nouvelle phase. Les CVE restent des identifiants partagés essentiels, et le NVD demeure une source publique importante pour enrichir les informations sur les vulnérabilités. Mais face à l’augmentation du nombre de vulnérabilités et à l’accélération de leur découverte, de leur validation et de leur signalement par l’IA, les équipes de sécurité ne peuvent plus s’appuyer sur une seule source d’enrichissement ni sur un simple score de gravité statique.

L’avenir de la veille sur les vulnérabilités reposera sur le contexte, la priorisation et la capacité à agir. L’objectif n’est plus d’évaluer les vulnérabilités une par une, mais de fournir aux humains et aux agents d’IA une vision de la surface d’attaque constamment mise à jour, qui mette en évidence les risques les plus importants et les mesures les plus susceptibles de réduire l’exposition globale.

Pour Snyk, c’est précisément la direction que doit prendre la veille. Snyk combine l’enrichissement à partir de plusieurs sources, le contexte des écosystèmes open source, des workflows assistés par l’IA et l’expertise humaine en sécurité pour aider ses clients à passer d’un volume brut de vulnérabilités à des actions éclairées et priorisées.

À mesure que le paysage des vulnérabilités évolue, la veille doit elle aussi évoluer : aller au-delà de l’enrichissement et de l’évaluation de la gravité pour devenir le socle de décisions de sécurité plus rapides et mieux éclairées.