VINCE-NT remplace VINCE : ce que change la bascule

Le 17 septembre 2026, l’agence américaine CISA (1) a mis en service VINCE-NT, la nouvelle plateforme de son programme de divulgation coordonnée de vulnérabilités, ou CVD (2). La date est donnée par la foire aux questions publiée avec la plateforme, qui précise que la plateforme précédente, VINCE, a tenu ce rôle de 2020 au 17 septembre 2026. VINCE était financée par la CISA mais hébergée par le CERT Coordination Center, ou CERT/CC (3), du Software Engineering Institute, ou SEI (4), de l’université Carnegie Mellon. VINCE-NT est financée, hébergée et administrée par la CISA seule, à l’adresse vulnerabilities.cisa.gov.

La bascule s’accompagne d’une refonte de la page du programme, publiée sous une nouvelle adresse, et de l’ouverture d’un dépôt public cisagov/VINCE-NT qui porte la documentation utilisateur, les conditions d’utilisation et le suivi des anomalies. Cette documentation est vivante : ses pages ont été modifiées les 14 et 17 septembre 2026, et les premiers tickets ouverts par les utilisateurs portent sur la gestion des comptes.

La page refondue ajoute par ailleurs une section qui sépare la divulgation coordonnée de la politique de signalement de vulnérabilités, ou VDP (5), deux dispositifs régulièrement confondus. Deux autres publications de l’agence complètent le contexte : la directive opérationnelle contraignante, ou BOD (6), 26-04 du 10 juin 2026, qui remplace et abroge les directives 19-02 et 22-01, et la CISA Vulnerability Review du 26 août 2026, qui porte sur les exercices budgétaires fédéraux américains 2024 et 2025, lesquels courent du 1er octobre au 30 septembre.

La création de compte passe désormais par le portail d’enregistrement de la CISA, adossé à Okta. Deux parcours existent : le parcours en libre-service, ouvert à tous, qui exige la vérification d’une adresse de courriel, un mot de passe et au moins une méthode d’authentification multifacteur, ou MFA (7), au choix parmi une application d’authentification, l’application Okta ou une clé de sécurité ; et le parcours par carte à puce PIV ou CAC, réservé aux agents et partenaires du gouvernement américain. La documentation précise que les champs de nom ne sont pas tenus d’être des noms réels. Les sessions sont courtes, un ticket ouvert par l’équipe évoque vingt minutes et la désactivation des comptes restés inactifs.

Le sort des dossiers en cours est traité dans la foire aux questions : les cas actifs sont transférés dans les semaines qui suivent la mise en service, chaque coordinateur annonçant la date de transfert dans le dossier concerné ; les données historiques restent consultables dans VINCE pour une durée non précisée. La transition ne concerne, selon l’agence, que les personnes qui utilisaient déjà la plateforme : équipe CVD, chercheurs, fournisseurs.

Un vocabulaire et des formats différents

Le changement n’est pas seulement technique. La documentation acte un glissement de vocabulaire et un rapprochement avec les formats de publication automatisables.

La différence de fond annoncée porte sur le statut de vulnérabilité : VINCE-NT gère une information de statut plus formelle que le champ d’information fournisseur des notes de vulnérabilité du CERT/CC, et cette information est alignée sur le format CSAF et sur le format de fiche CVE. Autrement dit, la sortie du processus devient exploitable par une machine plutôt que par un lecteur humain seul. Pour une équipe qui consomme des avis, c’est le changement le plus structurant de la bascule.

Les conditions d’utilisation, datées du 16 septembre 2026 et publiées en même temps dans le wiki du dépôt et sous forme de fichier, sont la pièce la plus instructive de l’ensemble. Elles formalisent ce qui relevait auparavant de l’usage.

Le régime de marquage

La coordination s’opère selon le protocole TLP (10). L’information d’origine déposée par un déclarant est marquée TLP:AMBER. Tout le reste de ce qui circule dans la plateforme, messages et documents partagés par les autres parties, est marqué TLP:AMBER+STRICT. Ce que la CISA publie est en général marqué TLP:CLEAR, les éléments non repris dans l’avis public conservant leur marquage d’origine. La règle qui en découle est explicite : ne rien publier de ce qui provient de la plateforme, captures d’écran et messages compris, sauf ce que l’on a soi-même déposé. Le non-respect des embargos et des dates de publication peut restreindre la participation aux dossiers suivants ou entraîner la fermeture du compte.

Les délais

• Cinq jours ouvrés : le délai attendu pour accuser réception des questions de la CISA, déclarants comme fournisseurs.
• Quarante-cinq jours : le délai au terme duquel la CISA se réserve le droit de publier, à compter de la première tentative de contact du fournisseur, que le correctif existe ou non, si celui-ci ne répond pas ou refuse de fixer un calendrier raisonnable.
• Sans délai annoncé : la fermeture d’un dossier sans résolution si le déclarant cesse de répondre aux demandes de l’agence.

Le cadre juridique

Trois clauses méritent d’être lues par une équipe européenne. La première rattache les informations transmises par une entité non fédérale, lorsqu’elles relèvent de la définition d’indicateur de menace ou de mesure défensive, aux dispositions de la loi américaine de 2015 sur le partage d’informations de cybersécurité ; le texte demande d’ailleurs de ne pas y joindre de données personnelles sans lien direct avec la menace. La deuxième indique que les demandes formulées au titre du Freedom of Information Act, ou FOIA (11), font l’objet d’un examen fédéral. La troisième écarte les signalements externes du processus d’arbitrage entre divulgation et rétention, ou VEP (12) : la CISA en est membre, mais les soumissions des déclarants externes sont traitées comme de l’information issue de la recherche, destinée à être divulguée rapidement, et ne sont pas soumises à cet arbitrage.

Deux autres clauses sont sans équivalent dans la plateforme précédente. La CISA examine la situation des déclarants, des fournisseurs et des autres participants au regard des listes de contrôle américaines, dont la liste consolidée de criblage et les listes tenues par l’office de contrôle des avoirs étrangers, ou OFAC (13), avant d’engager la coordination ; un coordinateur décide alors de la suite à donner. Et les régulateurs peuvent être associés à un dossier lorsque le produit ou l’entité relève de leur compétence, la CISA prévenant les parties au préalable et sollicitant l’accord du fournisseur. Le texte ajoute une précision utile : déposer un signalement dans la plateforme ne suffit pas, en soi, à satisfaire une obligation légale ou réglementaire de déclaration.

La section ajoutée à la page du programme traite une confusion courante, y compris en France, où les deux dispositifs sont souvent désignés par le même mot. La foire aux questions de la plateforme va plus loin en nommant le dispositif concurrent : le service de politique de signalement de la CISA est une plateforme distincte, destinée aux agences civiles fédérales américaines pour recevoir, trier et router les signalements portant sur leurs propres systèmes exposés.

La distinction n’est pas qu’un point de vocabulaire. Une organisation qui publie une politique de signalement ouvre un canal autorisé vers ses propres actifs exposés et s’engage sur ce qu’un déclarant peut attendre. Une organisation qui pratique la divulgation coordonnée gère la vie d’une faille produit jusqu’à sa publication, avec attribution d’un identifiant et rédaction d’un avis. Les deux peuvent coexister dans la même entité, mais elles ne mobilisent ni les mêmes équipes ni les mêmes engagements.

Le dépôt ne suppose pas de compte. La documentation est explicite sur ce point, que la page du programme ne mentionne pas : n’importe qui peut déposer un signalement sans être authentifié, en passant par le formulaire de la plateforme. La contrepartie est également écrite : l’agence analysera et coordonnera éventuellement le signalement, mais pourra ne pas être en mesure de communiquer avec son auteur. Pour un déclarant identifié, l’identité et les informations fournies sont partagées avec les fournisseurs et, le cas échéant, avec d’autres parties au dossier.

Le signalement déposé crée un dossier provisoire à l’état en attente, visible dans l’espace du déclarant. Un coordinateur le marque actif, et le dossier devient un cas suivi, avec échanges, dépôt de pièces jointes et discussion entre les parties. L’équipe de divulgation coordonnée effectue un premier triage, qui vérifie notamment si la faille est déjà connue du fournisseur ou déjà publique, et si un identifiant lui a déjà été attribué.

Trois orientations ressortent de ce triage. Le cas est pris en charge. Il est réorienté, mention que la page définit comme un signalement valide mais mieux traité par une autre organisation ou par le fournisseur, le déclarant étant alors dirigé vers le bon canal. Ou il ne relève pas du programme. Si la faille paraît entrer dans les règles du programme d’identification, la CISA détermine si un identifiant doit être attribué et quelle autorité de numérotation, ou CNA (14), en a la charge. La CISA étant elle-même une CNA, elle peut rédiger la fiche lorsque c’est pertinent.

Deux détails complètent le tableau pour qui outille sa veille. Chaque utilisateur peut générer une clé d’interface de programmation depuis son profil, ce qui ouvre la voie à un suivi automatisé de ses propres dossiers. Et les vulnérabilités de la plateforme elle-même se signalent soit dans la plateforme, soit par un avis privé sur le dépôt public, soit par courriel à l’équipe.

La directive 26-04 s’applique aux agences civiles fédérales américaines et à elles seules. Elle mérite pourtant d’être lue ailleurs, parce qu’elle abandonne un modèle que beaucoup d’organisations utilisent encore : un délai unique par niveau de gravité. À la place, quatre variables binaires déterminent l’urgence.

La combinaison des quatre réponses donne seize cas, répartis sur quatre délais : trois jours calendaires, quatorze jours, soixante jours, ou traitement à la prochaine montée de version du système. Les combinaisons les plus défavorables, actif exposé, vulnérabilité au catalogue KEV, exploitation automatisable et contrôle total, imposent en plus un triage forensique destiné à établir si la compromission a déjà eu lieu. Deux règles de repli complètent le dispositif : une exposition inconnue est traitée comme une exposition publique, et une donnée d’enrichissement manquante ramène le délai à soixante jours.

L’effet de volume est le point qui intéresse une équipe de gestion des vulnérabilités. Selon une analyse initiale de la CISA conduite dans une grande agence civile et rapportée par un éditeur du secteur, 1 % des occurrences de vulnérabilités relevaient du délai de trois jours, et plus de 60 % pouvaient attendre la prochaine montée de version. Le modèle vise donc à réduire la file d’attente, pas à l’allonger.

La revue se présente comme une ligne de base établie avant que la découverte de vulnérabilités assistée par intelligence artificielle ne se généralise. Elle porte sur les causes racines plutôt que sur les failles prises une par une, et sur l’écart entre les vulnérabilités publiées et celles réellement exploitées.

Les faiblesses qui reviennent

• En 2024, les dix faiblesses les plus fréquentes au sens de la nomenclature CWE (16) représentent 5,9 % de l’ensemble des CVE publiées, dont deux faiblesses d’injection.
• Les faiblesses d’injection, toutes catégories confondues, pèsent 10,1 % des CVE en 2024 et 9,2 % en 2025.
• Le cross-site scripting, ou XSS (17), domine à nouveau le classement en 2025, ce que la revue rattache à la persistance d’une validation d’entrée insuffisante.
• Les faiblesses de memory safety et de validation d’entrée pèsent 19,7 % des entrées du catalogue KEV en 2024 et 16,7 % en 2025, une part sans commune mesure avec leur poids dans l’ensemble des CVE.

L’enseignement tient dans ce dernier écart. Les injections dominent en volume de publication mais aboutissent rarement dans un environnement mature. La memory safety et la validation d’entrée dominent, elles, la liste de ce qui est effectivement exploité. Une priorisation construite sur le volume de CVE par catégorie ne mène donc pas au même plan de charge qu’une priorisation construite sur le catalogue KEV.

L’exposition et l’exécution

• 520 CVE ont été désignées pour action auprès d’entités d’infrastructure critique sur les deux exercices.
• 26 % des entités d’infrastructure critique balayées exposaient des services réseau vulnérables, dont environ 18 % un serveur FTP.
• La CVE-2025-33073, faille du protocole SMB, a été ajoutée au catalogue KEV en octobre 2025 ; la CVE-2026-24061, qui donne un accès root non authentifié via Telnet, l’a été en janvier 2026.
• La correction des vulnérabilités du catalogue KEV s’accélère et le nombre d’entités laissant une exposition au-delà de trente jours baisse, mais la majorité des organisations reste en dehors des délais recommandés.

La revue insiste enfin sur la qualité des fiches elles-mêmes : champs CVSS (18) manquants, absence de rattachement à une CWE, descriptions incomplètes. Ces manques ralentissent le triage et cassent les chaînes d’automatisation, y compris celles qui alimentent la décision de priorisation décrite plus haut. Pour sa propre priorisation, la CISA renvoie à l’arbre de décision SSVC (19), construit sur cinq facteurs : statut d’exploitation, impact technique, automatisation, prévalence dans la mission et impact sur le public.

Ce souci d’automatisation relie les deux sujets de cet article. Une capacité logicielle décrite par la CISA le 14 août 2026, développée avec le département du Trésor, vise à ingérer, valider et dédoublonner à grande échelle des signalements produits par intelligence artificielle, en amont de la coordination. Le document précise qu’elle complète la plateforme de coordination sans s’y substituer. Passer à des statuts alignés sur les formats CSAF et CVE prend son sens dans cette perspective de volume.

Aucun de ces textes n’est opposable à une organisation française. Quatre conséquences pratiques existent malgré tout.

La première concerne le signalement anonyme. Il reste possible, la documentation le dit, mais il se paie : sans compte, l’agence peut ne pas être en mesure de recontacter l’auteur, donc de poser les questions nécessaires à l’attribution d’un identifiant. Avec un compte, l’identité est partagée avec les fournisseurs du dossier. Le choix entre les deux n’est plus un détail de formulaire, c’est un arbitrage entre anonymat et suivi du cas.

La deuxième concerne le régime de marquage. Un chercheur ou une équipe qui participe à un dossier accepte que ses dépôts soient marqués TLP:AMBER, que tout le reste soit marqué TLP:AMBER+STRICT et que rien de ce qui provient de la plateforme ne soit republié, captures d’écran comprises. Pour une équipe habituée à alimenter son propre blog ou ses propres bulletins à partir de ses travaux, c’est une contrainte à intégrer avant d’ouvrir un dossier, pas après.

La troisième concerne le cadre juridique. Les signalements étrangers passent par une plateforme gouvernementale américaine, avec examen des demandes au titre du Freedom of Information Act, rattachement des indicateurs transmis au régime américain de partage d’informations de cybersécurité, criblage des participants au regard des listes de sanctions, et association possible des régulateurs compétents. La clause la plus utile à retenir est celle qui rappelle que déposer un signalement chez la CISA ne satisfait aucune obligation réglementaire européenne.

La quatrième concerne la priorisation. Le modèle à quatre variables est transposable sans rien devoir aux États-Unis, et il a un mérite que n’ont pas les grilles fondées sur le score CVSS : trois des quatre réponses sont fournies par une source extérieure, ce qui réduit le travail de qualification à une seule question, celle de l’exposition réelle de l’actif. C’est aussi la question à laquelle la plupart des organisations répondent mal, faute d’inventaire à jour.

L’essentiel de cet article repose sur la documentation primaire publiée par la CISA avec la plateforme, lue intégralement. Les chiffres de la revue des vulnérabilités font exception et sont à confirmer sur le fichier d’origine.

Pour qui signale des failles

• Vérifier l’adresse de dépôt avant de créer un compte : les deux pages du programme ne pointent pas vers la même plateforme, et seule vulnerabilities.cisa.gov est la nouvelle.
• Décider en amont entre dépôt anonyme et dossier suivi : sans compte, l’agence peut ne pas pouvoir recontacter l’auteur, ce qui pèse sur l’attribution d’un identifiant.
• Prévoir la disponibilité : cinq jours ouvrés pour répondre aux questions, faute de quoi le dossier peut être fermé sans résolution.
• Lire la clause de republication avant de prévoir une publication de son côté : rien de ce qui vient de la plateforme ne se republie, sauf ce que l’on y a soi-même déposé.
• Privilégier la CNA du fournisseur concerné quand elle existe : la coordination par une agence est faite pour les cas multi-acteurs ou pour les fournisseurs non réactifs.

Pour qui reçoit des signalements sur ses produits

• Créer le groupe fournisseur et identifier les personnes habilitées avant d’être partie à un dossier, plutôt que dans l’urgence d’un premier cas.
• Retenir le repère des quarante-cinq jours : au-delà, et en l’absence de coordination active, la CISA se réserve la publication de l’avis et de la fiche, correctif disponible ou non.
• Préparer la production d’un statut de vulnérabilité au format CSAF, la plateforme s’alignant sur ce format et sur celui des fiches.

Pour qui gère des vulnérabilités

• Reprendre les quatre variables de la directive et les câbler sur ses propres données : exposition depuis l’inventaire, statut du catalogue, automatisation et impact technique depuis l’enrichissement public.
• Traiter l’exposition inconnue comme une exposition publique, règle de repli qui vaut aussi hors périmètre fédéral.
• Rattacher au délai le plus court une recherche de compromission, et non seulement une correction.
• Ne pas construire son plan de charge sur la répartition des CVE par catégorie de faiblesse, l’écart avec le catalogue KEV étant considérable sur les familles réellement exploitées.

Pour qui rédige une politique

Écrire noir sur blanc lequel des deux dispositifs est mis en place. Une politique de signalement décrit un périmètre d’actifs, un canal de réception et ce que le déclarant peut attendre. Un programme de divulgation coordonnée engage en plus sur le triage, l’attribution d’un identifiant et la publication d’un avis, ce qui suppose un mandat, une CNA de rattachement et une capacité de rédaction. Promettre le second en n’ayant que le premier est la façon la plus rapide de perdre la confiance des chercheurs.

1. CISA (1) : Cybersecurity and Infrastructure Security Agency, agence américaine de cybersécurité et de sécurité des infrastructures, rattachée au département de la Sécurité intérieure.
2. CVD (2) : Coordinated Vulnerability Disclosure, divulgation coordonnée de vulnérabilités entre un déclarant, un fournisseur et un éventuel coordinateur.
3. CERT/CC (3) : CERT Coordination Center, centre de coordination créé en 1988, premier du genre.
4. SEI (4) : Software Engineering Institute, institut de l’université Carnegie Mellon qui héberge le CERT/CC.
5. VDP (5) : Vulnerability Disclosure Policy, politique par laquelle une organisation autorise et organise le signalement de failles sur ses propres actifs exposés.
6. BOD (6) : Binding Operational Directive, directive opérationnelle contraignante pour les agences civiles fédérales américaines.
7. MFA (7) : Multi-Factor Authentication, authentification exigeant plusieurs facteurs distincts.
8. CSAF (8) : Common Security Advisory Framework, format normalisé et lisible par machine pour la publication d’avis de sécurité.
9. CVE (9) : Common Vulnerabilities and Exposures, système d’identification publique des vulnérabilités.
10. TLP (10) : Traffic Light Protocol, protocole de marquage qui définit les conditions de rediffusion d’une information. Le niveau AMBER+STRICT en restreint la diffusion à la seule organisation destinataire.
11. FOIA (11) : Freedom of Information Act, loi américaine d’accès aux documents administratifs.
12. VEP (12) : Vulnerabilities Equities Process, processus américain d’arbitrage entre divulgation et rétention d’une vulnérabilité par l’État.
13. OFAC (13) : Office of Foreign Assets Control, office du Trésor américain chargé des sanctions économiques et financières.
14. CNA (14) : CVE Numbering Authority, entité habilitée à attribuer des identifiants CVE et à publier les fiches correspondantes.
15. KEV (15) : Known Exploited Vulnerabilities, catalogue des vulnérabilités dont l’exploitation est avérée, tenu par la CISA.
16. CWE (16) : Common Weakness Enumeration, nomenclature des types de faiblesses logicielles à l’origine des vulnérabilités.
17. XSS (17) : Cross-Site Scripting, injection de code exécuté dans le navigateur d’un utilisateur.
18. CVSS (18) : Common Vulnerability Scoring System, système de notation de la gravité technique d’une vulnérabilité.
19. SSVC (19) : Stakeholder-Specific Vulnerability Categorization, arbre de décision de priorisation tenant compte du contexte de chaque partie prenante.

1. CISA, The Coordinated Vulnerability Disclosure (CVD) Program, page refondue du programme, consultée le 18 septembre 2026. cisa.gov
2. CISA, Coordinated Vulnerability Disclosure Program, page précédente décrivant VINCE hébergée par le SEI. cisa.gov
3. CISA, dépôt public cisagov/VINCE-NT, documentation et suivi d’anomalies. github.com
4. CISA, VINCE-NT Frequently Asked Questions, page modifiée le 17 septembre 2026. github.com
5. CISA, VINCE-NT Terms and Conditions, version du 16 septembre 2026. github.com
6. CISA, VINCE-NT All Users, création et gestion de compte. github.com
7. CISA, VINCE-NT Reporters, dépôt et suivi d’un signalement. github.com
8. CISA, plateforme VINCE-NT. vulnerabilities.cisa.gov
9. CISA, Vulnerability Disclosure Policy (VDP) Platform, service aux agences fédérales. cisa.gov
10. CISA, CVE Program Vision, document de vision référencé par la foire aux questions, septembre 2025. cisa.gov
11. CISA, CISA Vulnerability Review, page de la ressource, publiée le 26 août 2026. cisa.gov
12. CISA, CISA Vulnerability Review Fiscal Years 2024 and 2025, fichier PDF de 3,43 mégaoctets. cisa.gov
13. CISA, BOD 26-04: Prioritizing Security Updates Based on Risk, 10 juin 2026. cisa.gov
14. CISA, BOD 26-04: Implementation Guidance, guide de mise en oeuvre et triage forensique. cisa.gov
15. CISA, communiqué de publication de la directive 26-04. cisa.gov
16. CISA et département du Trésor, Gold Eagle: The AI Cybersecurity Clearinghouse, document TLP:CLEAR du 14 août 2026. cisa.gov
17. Industrial Cyber, synthèse de la revue des vulnérabilités, 27 août 2026. industrialcyber.co
18. Software Engineering Institute, annonce de la mise en service de VINCE, juin 2020. sei.cmu.edu