Pendant deux décennies, la NVD (National Vulnerability Database) a constitué le fondement de facto de la gestion des vulnérabilités. Les scanners, les systèmes SIEM, les outils de correction et les cadres de conformité reposaient tous sur l'hypothèse selon laquelle, lorsqu'un CVE apparaissait dans la NVD, les analystes du NIST ajoutaient rapidement les scores de gravité, les correspondances avec les versions des produits et les métadonnées contextuelles qui rendent un identifiant CVE brut réellement utile.
Le 15 avril 2026, cette hypothèse a officiellement cessé d'être valable.
Le NIST a annoncé que le NVD adoptait désormais un modèle d'enrichissement basé sur les risques. La plupart des nouvelles CVE intégrées à la base de données ne bénéficieront plus, par défaut, d'un score CVSS attribué par le NIST, d'un mappage de produit CPE ni d'une analyse indépendante. Pour les organisations dont les processus de gestion des vulnérabilités dépendent des données enrichies par le NVD, cela crée un problème de couverture réel et croissant. Pour les développeurs et les fournisseurs de produits de sécurité qui intègrent ces données dans leurs outils, cela soulève une question encore plus cruciale : que vous indique exactement votre flux d'informations à l'heure actuelle ?
La NVD n'arrive plus à suivre le rythme des vulnérabilités signalées
Selon les propres chiffres du NIST, le nombre de signalements CVE a augmenté de 263 % entre 2020 et 2025, et au premier trimestre 2026, il était déjà supérieur de près d'un tiers à celui de la même période l'année précédente.
En 2025, le NIST a enrichi près de 42 000 CVE, soit une augmentation de 45 % par rapport à toutes les années précédentes. Cependant, cette hausse de productivité n'a pas suffi à suivre le rythme des soumissions croissantes, ce qui a conduit à la mise en place d'un système de tri formalisé.
À compter du 15 avril 2026, le NIST n'enrichira plus que les vulnérabilités figurant dans le catalogue KVE (Known Exploited Vulnerabilities) de la CISA, dans les logiciels utilisés par le gouvernement fédéral ou dans les logiciels désignés comme critiques en vertu du décret 14028. Toutes les autres vulnérabilités seront répertoriées dans le NVD, mais sans les informations d'enrichissement ajoutées par le NIST, et ne seront pas traitées immédiatement.
En conséquence, près de 300 000 CVE en attente publiées avant le 1er mars 2026 ont été regroupées en bloc dans la catégorie « Non planifiées ».
Désormais, pour les CVE ne répondant pas aux critères de priorité du NIST, les scores de gravité seront déterminés sur la base des informations fournies par l'autorité de numérotation des CVE (CNA) – souvent le fournisseur du logiciel concerné – plutôt que d'une analyse indépendante menée par le NIST. Le NIST cessera également de recalculer les scores de gravité lorsqu'une CNA en aura déjà fourni un.
Tous les principaux outils de détection des vulnérabilités, toutes les règles de corrélation SIEM, tous les scores de risque tiers et tous les cadres de conformité réglementaire, du PCI DSS au FedRAMP, s'appuient sur le pipeline d'enrichissement du NVD.
Avec cette mise à jour, ce processus s'est désormais officiellement raccourci, ce qui fait que des vulnérabilités (CVE) potentiellement dangereuses risquent de ne pas être répertoriées comme telles ou d'être découvertes trop tard.
Il existe un autre facteur d'accélération qu'il convient de prendre en compte, car la diminution de l'enrichissement des données se heurte à la prolifération rapide des outils de détection des menaces assistés par l'IA.
Les modèles d'IA avancés et les outils de codage réduisent considérablement les obstacles à l'identification des failles exploitables et des voies d'attaque complexes dans les applications, ce qui entraîne une forte augmentation du nombre de divulgations de CVE. En février 2026, le Forum of Incident Response and Security Teams (FIRST) a prévu qu'un nombre record de 50 000 CVE supplémentaires serait signalé en 2026. L'infrastructure d'enrichissement actuelle n'est pas en mesure de traiter ce volume tout en maintenant les niveaux de qualité antérieurs.
Pourquoi les produits reposant uniquement sur la technologie NVD posent problème
Un enregistrement CVE brut comprend généralement un identifiant, une description et des références. Les métadonnées qui sous-tendent la gestion automatisée des vulnérabilités provenaient traditionnellement des analystes du NVD. Ces données font référence à des scores de gravité CVSS validés de manière indépendante, à des mappages de produits CPE et à des classifications de failles CWE.
Mais c'est l'« enrichissement » qui rend un CVE exploitable. Sans lui, les flux de travail qui en dépendent se dégradent de manière prévisible.
La hiérarchisation basée sur le CVSS perd de son efficacité
Lorsqu'un scanner ou un outil de correction s'attend à recevoir une note de gravité fournie par le NVD et n'en trouve aucune, la vulnérabilité peut apparaître comme « gravité inconnue », ne pas être prise en compte dans les politiques de correction basées sur un SLA, ou voir sa priorité réduite.
La mise à jour du NIST d'avril 2026 a confirmé que :
- Les CVE qui ne répondent pas aux nouveaux critères de priorité ne feront pas automatiquement l'objet d'une évaluation indépendante
- Le NIST ne calculera plus son propre score CVSS lorsqu'un CNA en a déjà fourni un (même si ce CNA est le fournisseur du logiciel concerné)
Un mappage CPE insuffisant ou absent entraîne une détection CVE défaillante
La documentation de NVD décrit l'identification des produits comme un élément fondamental de l'enrichissement, car elle permet aux utilisateurs de vérifier par programmation si une vulnérabilité connue affecte les produits présents dans leur environnement.
Si les correspondances CPE sont absentes, incomplètes ou retardées, les outils qui s'appuient principalement sur la mise en correspondance CPE peuvent ne pas détecter la correspondance ou la détecter trop tard.
Les fournisseurs de solutions de sécurité comptent parmi les plus touchés, car leurs produits reposent souvent sur la mise en correspondance des équipements CPE et l'enrichissement des données CVE. Les outils de gestion des correctifs, de protection des terminaux, de contrôle d'accès au réseau et de gestion des actifs s'appuient sur des informations précises relatives aux vulnérabilités pour déterminer quels systèmes sont affectés, quelle est la gravité du problème et quelles mesures doivent être prises par la suite.
Pour les équipes qui développent de nouveaux produits de sécurité, se contenter de la base de données NVD revient à s'appuyer sur des fondations qui peuvent déjà présenter des lacunes importantes : une couverture limitée des vulnérabilités « zero-day », un manque d'enrichissement pour une part croissante des CVE, et des cycles de mise à jour qui risquent de ne pas suivre le rythme effréné de la détection et de l'exploitation des vulnérabilités par l'IA.
Pour les équipes qui disposent déjà de capacités de correction ou de remédiation, le risque est différent, mais tout aussi important. L'efficacité d'un moteur de remédiation dépend entièrement de la qualité des informations sur les vulnérabilités qu'il reçoit. Si ces informations sont incomplètes, obsolètes ou trop tributaires d'un enrichissement issu du NVD, les workflows en aval risquent de passer à côté de produits affectés, de ne pas accorder la priorité aux vulnérabilités dont la gravité est inconnue, ou de ne pas intervenir avant que l'exposition ne s'aggrave.
Si ces produits reprenaient les lacunes de NVD, ces lacunes pourraient se répercuter sur tous les clients en aval.
C'est précisément cette lacune que l'évaluation des vulnérabilités du cadre OESIS a été conçue pour combler : aider les équipes chargées des produits de sécurité à renforcer leurs connaissances en matière de vulnérabilités sans se contenter uniquement de l'enrichissement des données du NVD.
En quoi OPSWAT est différente
OPSWAT le module d'évaluation des vulnérabilités du cadre OESIS spécialement pour les développeurs de produits de sécurité qui ont besoin de données fiables et exploitables sur les vulnérabilités, intégrées à leurs outils.
Conçu pour combler cette lacune
Le module regroupe plusieurs sources, au lieu de s'appuyer sur une seule source.
Il s'appuie sur diverses sources commerciales et ouvertes d'informations sur les vulnérabilités afin d'assurer une couverture rapide et précise couvrant des centaines de fournisseurs et d'applications.
Le catalogue de vulnérabilités OESIS recense actuellement plus de 65 000 CVE uniques et plus de 150 000 occurrences de vulnérabilités. Il est mis à jour en continu — plusieurs fois par jour — sans attendre les cycles de traitement du NVD.
Un système de notation de gravité propriétaire qui va au-delà du CVSS et offre davantage de contexte.
Les données sur les vulnérabilités OPSWAT comprennent le « OPSWAT Score », un indice propriétaire qui va au-delà du système CVSS de base en intégrant des indicateurs supplémentaires, notamment la popularité des CVE, le risque de compromission et le cycle de vie des CVE.
Dans un contexte où une part croissante des scores CVSS pourrait provenir d'auto-évaluations des CNA, ce niveau d'analyse indépendant pourrait aider les produits de sécurité à fournir à leurs utilisateurs une indication de priorisation plus fiable.
La solution OESIS Vulnerability Intelligence prend en charge deux modes d'intégration, sans phase de mise en route complexe :
- Flux de catalogue : comparez les données de vulnérabilité OESIS à votre inventaire logiciel existant côté serveur — aucun agent de terminal n'est nécessaire. Les produits existants dotés de fonctionnalités d'inventaire logiciel peuvent utiliser les données OESIS pour détecter les vulnérabilités sur l'ensemble des ressources gérées.
- Endpoint (kitSoftware ) : Intégrez directement le framework OESIS à votre produit pour vulnerability detection en temps réel vulnerability detection directement sur l'appareil. Idéal pour les produits de sécurité fonctionnant sur les terminaux
Recherche interne sur les vulnérabilités
L'équipe interne de recherche sur les menaces OPSWAT, Unit 515, mène en permanence des recherches en sécurité offensive, des simulations d'attaques, des tests avancés et des divulgations responsables concernant les infrastructures critiques et les logiciels d'entreprise. L'équipe a identifié et signalé plus de 50 vulnérabilités de type « zero-day », y compris des découvertes critiques dans des logiciels largement déployés, tels que les plateformes ICS/OT comme les automates Delta et les plateformes natives d'IA.
En résultat, les développeurs de produits de sécurité pourraient continuer à offrir une couverture plus large des vulnérabilités, même si le champ d'action du NVD se réduit, sans que les clients aient à accepter une visibilité réduite ou à recourir à des solutions de contournement manuelles.
Détection + Remédiation : le cycle complet
La détection permet d'identifier les vulnérabilités. La correction permet de les résoudre. Ensemble, elles contribuent à réduire autant que possible les risques. OESIS Vulnerability Assessment se charge de la détection et de la hiérarchisation des priorités. OESIS Patch Management s'adresse aux équipes qui souhaitent disposer de ces deux fonctionnalités au sein d'un même cadre :
- Détection : Applications vulnérables, dont la version correspond, OPSWAT et signalées par KEV
- Hiérarchisation des priorités : OPSWAT permet d'identifier les vulnérabilités à corriger en priorité, en s'appuyant sur des signaux d'exploitation concrets
- Solution : Votre infrastructure existante peut exploiter les données de sortie d'OESIS — ou bien OESIS Patch Management appliquer les correctifs, imposer des versions ou bloquer l'accès directement
- Vérification : OESIS effectue une nouvelle analyse après la réparation afin de s'assurer que le terminal est sain avant de rétablir l'accès
Une détection sans correction n'est qu'un simple rapport. Une détection accompagnée d'une correction permet d'éliminer le risque. OESIS vise à offrir à votre produit ces deux éléments, en vous aidant à boucler plus rapidement le cycle de détection et de correction afin de mieux faire face aux menaces qui évoluent à la vitesse de l'IA.
Les vulnérabilités d'AI-Speed nécessitent une détection d'AI-Speed
Les éditeurs de solutions de sécurité ne peuvent pas se permettre de considérer les informations sur les vulnérabilités comme une dépendance en arrière-plan évoluant au ralenti. Alors que le volume des CVE augmente et que l'enrichissement des données devient moins constant, les équipes produit ont besoin d'un moyen d'aligner les processus de détection, de hiérarchisation et de correction sur les risques réels.
C'est là qu'intervient l'évaluation des vulnérabilités du framework OESIS. Elle offre aux développeurs de produits un moyen pratique de renforcer la couverture des vulnérabilités sans avoir à reconstruire de zéro leur infrastructure de gestion des terminaux ou leur pile de remédiation. Pour les équipes qui lancent un nouveau produit, elle permet d'établir plus tôt une couverture fiable. Pour celles qui améliorent un produit existant, elle offre un moyen plus simple de comparer la couverture, de valider les améliorations et de déterminer à quoi devrait ressembler une intégration plus poussée.
