2 436 failles, un seul déclarant : repensez la réception de votre VDP

Une campagne de divulgation de vulnérabilités en masse, c’est un déclarant unique qui adresse de nombreuses découvertes à de nombreuses parties sans lien entre elles, selon un calendrier qu’il fixe seul. Le registre public de divulgation de sécurité de Z.ai recense 2 436 découvertes réparties sur 269 projets open source, dont 107 critiques et 990 élevées, avec un écart moyen de 26,6 ans entre l’écriture d’un défaut et sa mise au jour. Un audit indépendant du champ de statut de ce registre a relevé 2 239 découvertes encore marquées discovered et exactement une marquée sent to maintainer. La réception rapport par rapport — un accusé de réception, un compteur SLA, une décision de gravité — ne résiste pas au contact de cette forme-là.

C’est le troisième article d’une série, et la distinction est capitale. L’article sur le contenu IA bâclé traitait des rapports invalides arrivant en volume. L’article sur l’économie du triage traitait de l’effondrement du coût de découverte d’une vraie faille, tombé au prix d’un déjeuner. Celui-ci ne parle ni de l’un ni de l’autre : ces découvertes sont pour l’essentiel valides, et personne ne les a demandées. L’article sur la divulgation multipartite suivait une faille unique qui frappait cinq éditeurs. Ici, c’est un déclarant unique qui frappe 269 projets : le même problème de gouvernance retourné comme un gant, avec l’échéance tenue par la partie qui a un lancement de produit à assurer.

2 436 découvertes, 269 projets, un seul déclarant

Le 14 août 2026, Z.ai a lancé GLM-5.3 et publié le même jour un registre de divulgation de sécurité à l’adresse cvd.z.ai. C’est le registre, et non le score aux tests de référence, qui mérite d’être lu.

Parmi les découvertes divulguées et nommées figurent la pile 6lowpan du noyau Linux, WebKit, le ptrace de FreeBSD, GStreamer et Suricata. Z.ai annonce pour GLM-5.3 un score de 84,5 % sur CyberGym, contre 77,2 % pour GLM-5.2. Le fil Hacker News a atteint 1 170 points et 584 commentaires, la critique la plus vive ne visant pas le modèle mais le fait de passer l’open source au crible à grande échelle sans la moindre politique d’embargo.

Deux réserves avant de bâtir quoi que ce soit sur ces chiffres.

La campagne n’est pas l’œuvre d’un seul modèle. Z.ai indique qu’elle a débuté à l’époque de GLM-5.2, au sein de plusieurs équipes de sécurité et avec plusieurs chaînes d’automatisation, et les avis publiés par les projets amont attribuent les découvertes à différentes versions de GLM. Écrivez « la campagne de Z.ai », jamais « GLM-5.3 a trouvé 2 436 failles ».

Tous les agrégats repris ici reposent sur la seule publication de Z.ai. Personne, hors de l’entreprise, ne peut auditer les 2 383 entrées non divulguées. Rien là-dedans ne vise Z.ai en particulier : vous serez exactement dans la même position le jour où un lot de quarante tombera dans votre boîte de réception. Impossible de vérifier les affirmations d’un déclarant en masse au moment où elles arrivent, et je ne peux pas davantage vérifier celles-ci.

Ni l’histoire du contenu IA bâclé, ni celle de la découverte à bas coût

Le problème du contenu bâclé portait sur le rapport signal/bruit. Le problème économique portait sur le coût unitaire. Celui-ci porte sur la forme, et c’est la forme qui casse l’outillage.

Un programme de divulgation des vulnérabilités (VDP) ordinaire suppose une relation de plusieurs vers un : de nombreux chercheurs indépendants, chacun envoyant un rapport, chacun adhérant à votre politique par le seul fait de le soumettre sous son régime. Une campagne en masse inverse ce schéma. Un déclarant unique s’adresse à 269 destinataires en même temps, selon un calendrier qu’il maîtrise seul, et publie un registre public avant même que la plupart d’entre eux aient été contactés.

La partie réceptrice n’a rien accepté, n’a consenti à aucun calendrier et, dans la plupart des cas, n’a même pas été prévenue. On ne parle plus d’une soumission à un programme de primes, mais d’une campagne de notification de vulnérabilités en masse — un objet que la recherche en sécurité étudie depuis dix ans et dont elle connaît le taux de réponse déplorable.

Le goulot d’étranglement, c’est la notification, pas le correctif

Le fait le plus utile du registre, ce n’est pas le chiffre de 2 436. C’est l’endroit où ces découvertes stagnent.

Un audit du champ de statut du registre lui-même, réalisé le 14 août, a relevé : 2 239 discovered, 84 reported, 53 revealed, 29 acknowledged, 30 patched et 1 sent to maintainer. Soit près de 92 % des découvertes toujours immobilisées du côté du déclarant.

Anthropic avait joué le même coup deux mois plus tôt, et s’est fait auditer pour cela. L’analyse du registre Mythos d’Anthropic publiée par VulnCheck le 9 juin 2026 recensait 23 019 vulnérabilités potentielles, dont 467 validées puis transmises et 1 129 transmises sans validation. Soit 1 596 découvertes, 6,9 %, parvenues aux mainteneurs en 60 jours — un rythme que VulnCheck chiffrait à environ 2,4 ans pour résorber l’arriéré. La même analyse relevait dix découvertes déjà hors du délai de 90 jours fixé par Anthropic elle-même, toujours non publiées, et 168 autres arrivant à échéance sous 30 jours.

Deux éditeurs, deux registres, un même résultat structurel : la découverte passe à l’échelle, la notification non. Un modèle trouve un débordement de tas dans une base de code de 1994 en quelques minutes. Retrouver le mainteneur, rédiger un rapport exploitable par un humain et l’accompagner jusqu’au correctif reste un travail humain inchangé.

Pour celui qui reçoit, c’est une bonne nouvelle avec une date de péremption. La vague ne vous a pas encore atteint, et quand elle le fera, elle arrivera sous forme de lot : le déclarant vide une file d’attente, il n’ouvre pas un ticket.

Ce qui casse quand quarante rapports arrivent du même expéditeur

Trois défaillances mécaniques, dont aucune ne relève du jugement. Dans les trois cas, votre automatisation actuelle fonctionne exactement comme prévu.

Démultiplication des accusés de réception. Une réponse automatique par rapport est correcte pour un rapport et abusive pour quarante. L’expéditeur reçoit quarante e-mails dont personne ne voulait, votre domaine envoie quarante messages quasi identiques à une seule adresse, et au bout du compte l’expéditeur ignore toujours qui prend le lot en charge et quand un humain s’y penchera.

Agrégation des SLA. Quarante compteurs d’accusé de réception démarrent d’un coup, chacun tenable en 72 heures pris isolément, tous ensemble une charge de triage pour laquelle personne n’a dimensionné la rotation. Votre file est au vert rapport par rapport, et intenable dans l’ensemble. C’est le mode de défaillance documenté dans l’article sur la divulgation multipartite, à l’envers : là-bas, un même dossier portait plusieurs compteurs ; ici, de nombreux dossiers partagent un même plafond de capacité.

La gravité avant la cause racine. Le triage rapport par rapport demande d’abord « celui-ci, quelle est sa gravité ? ». Pour une campagne, c’est la deuxième question. La première : « la méthode de ce déclarant tient-elle debout, et ces découvertes partagent-elles une cause racine ? » Quarante découvertes issues d’une même chaîne lancée contre un même analyseur, c’est souvent une seule classe de vulnérabilité répartie sur quarante sites d’appel. Les trier séparément coûte quarante fois plus cher et donne une moins bonne réponse, parce que le motif n’apparaît qu’à l’échelle du lot.

Les trois défaillances découlent d’un unique choix de modélisation : le rapport est l’unité de travail. Pour une campagne, il ne l’est pas.

Une campagne n’est pas un rapport : ce que votre réception doit modéliser

Le remède tient dans un objet « lot » placé au-dessus du rapport. Cinq champs en portent l’essentiel de la valeur.

1. Un lot, un accusé de réception. Une seule réponse, qui nomme le lot, indique combien de découvertes sont arrivées et s’engage sur une date de première réponse substantielle. Supprimez l’envoi par rapport dès qu’un identifiant de lot est présent.
2. Un responsable unique. Un humain nommément désigné, comptable du lot, et non quarante affectations distribuées à tour de rôle.
3. Un compteur partagé pour le lot, avec des compteurs par découverte en dessous. L’accusé de réception est une obligation qui porte sur le lot ; la remédiation se joue découverte par découverte.
4. Une évaluation de la méthode consignée une seule fois. La chaîne d’automatisation est-elle fiable ? Les preuves de concept sont-elles exécutables ? Répondez pour le lot, laissez chaque découverte hériter de la réponse, ne la révisez que là où une découverte la contredit.
5. Regroupement par cause racine avant la gravité. Regroupez d’abord, puis notez les regroupements plutôt que les lignes.

Kit ne propose pas encore cela. Son domaine Csirt:: traite Csirt::Report comme l’objet de plus haut niveau : ni notion de campagne, ni lot de soumission. Quarante rapports, ce sont quarante lignes, quarante e-mails d’accusé de réception, quarante compteurs SLA, quarante notifications d’astreinte. C’est l’argument central de cet article, et il pointe un manque dans notre propre produit plutôt qu’une de ses fonctionnalités. Les cinq champs ci-dessus décrivent la forme que cela devrait prendre, selon nous.

Qui tient le compteur de divulgation quand le déclarant est un éditeur de modèles ?

Personne, sauf si vous l’écrivez noir sur blanc.

Aucune loi ne fixe la divulgation coordonnée à 90 jours. Il y a des conventions — le 90+30 de Project Zero, le 90+14 de la ZDI pour les éditeurs coopératifs — et il y a celui qui publie le premier. Quand le déclarant est un éditeur de modèles, l’échéance se mêle au marketing de lancement, parce que le registre est autant une démonstration de capacité qu’un artefact de divulgation.

Z.ai n’a publié aucune politique d’embargo sur ce registre : pas de page de politique, pas d’échéance par découverte, pas de compte à rebours. Seulement des statuts, des niveaux de gravité et des identifiants. C’est plus transparent qu’une analyse menée en silence, et cela vous laisse tout de même sans date annoncée.

Anthropic, de son côté, avait bien publié un délai de 90 jours, et VulnCheck a trouvé dix découvertes qui l’avaient dépassé et n’avaient toujours pas été publiées. Le choix ne se joue donc pas entre un éditeur doté d’une politique et un éditeur sans : il se joue entre une date inscrite dans votre dossier et une date logée dans le calendrier de publication de quelqu’un d’autre.

Trois champs comblent ce vide : requested_embargo_at (ce que le déclarant a demandé), agreed_embargo_at (ce que vous avez négocié) et published_at (ce qui s’est produit). Kit ne les a pas, et le dit sur sa propre page de comparaison : « Kit ne modélise aucun compteur de divulgation ni aucune date d’embargo. Un champ de date d’embargo est une demande légitime ; aujourd’hui, Kit suit l’accusé de réception, pas la divulgation. » La seule constante de 90 jours de la base de code est une expiration de jeton de réception, pas un compteur de divulgation.

Limiter le débit est la mauvaise défense : ce que le plafond d’Apple a réellement rapporté

Le premier réflexe, à la lecture de tout ceci, est de brider l’expéditeur. Apple a mené cette expérience en public, et le résultat est plus intéressant que les gros titres.

En juin 2026, Apple a ajouté un plafond de soumissions assorti d’un délai de carence de 30 jours sur son portail de recherche en sécurité, toute soumission supplémentaire exigeant une demande spéciale. Le chiffre du plafond n’est pas publié. Bynario, qui avait déposé 13 rapports sur toute l’année 2025 et le début de 2026, a monté une chaîne d’automatisation pilotée par IA et déposé plus de 50 rapports macOS en trois semaines. Il a franchi le plafond et s’est vu couper l’accès au portail au moment précis où il tenait une découverte critique.

Vient ensuite la partie qu’on omet d’ordinaire : le bridage n’a pas empêché la découverte de sortir. Apple a reçu les détails par un autre canal et a corrigé CVE-2026-43760 le 27 juillet — une faille de délégation abusive (confused deputy) dans l’ancien chemin VNC, qui permettait à un client VNC authentifié de lire et de créer des fichiers en tant que root. Bynario a publié son analyse deux jours plus tard, une fois le correctif diffusé : de la publication de recherche après correctif tout ce qu’il y a de plus ordinaire, et non une faille zero-day lâchée par dépit.

Puis est venue la partie sur laquelle le plafond n’avait aucune prise. Le compte rendu de Bynario a attiré l’attention des chercheurs sur un ancien chemin de code du Partage d’écran. En moins de 48 heures, une faille distincte dans le même démon, exploitable avant authentification, était divulguée, preuve de concept à l’appui. Quatre jours plus tard, un code d’exploitation opérationnel circulait, puis la faille était activement exploitée pour du minage de cryptomonnaie contre le port 5900 exposé sur Internet. Apple a publié un correctif d’urgence le 6 août. La CISA a réévalué la faille de 7,1 à 9,8 le 14 août et l’a inscrite au catalogue des vulnérabilités activement exploitées (KEV) le 18 août, avec une date de correction obligatoire pour les agences fédérales au 21 août 2026.

Dix jours pour passer d’une élévation de privilèges après authentification à une exécution de code à distance avant authentification inscrite au KEV, dans le même composant.

La leçon n’est pas que le bridage engendre des zero-days ; ce serait surinterpréter les faits. Elle est plus étroite et plus utile : un plafond de soumissions régit la vitesse à laquelle les rapports entrent dans votre file, et n’a aucune prise sur la vitesse à laquelle le monde en prend connaissance. Sur ce calendrier-là, la capacité de réception est la seule variable que vous maîtrisez, et le plafond n’y a pas ajouté un gramme.

GitHub a mieux répondu : quatre soumissions et une porte de sortie

GitHub s’est heurté au même mur et a choisi les paliers plutôt que le bridage. Pour les rapports déposés à partir du 27 juillet 2026, la plateforme applique un palier public à montants fixes — 250 $ / 2 000 $ / 5 000 $ / 10 000 $ de faible à critique — et un palier VIP sur invitation à 1 000 $ / 7 500 $ / 20 000 $ / 30 000 $ et plus.

Le mécanisme intéressant, c’est l’entrée. Les chercheurs situés sous le seuil de signal de la plateforme disposent de quatre premières soumissions au maximum pour faire leurs preuves, et la porte VIP s’ouvre dès une seule faille critique valide, ou deux élevées, ou quatre moyennes, ou sept faibles.

C’est une limitation de débit avec une sortie. La chaîne de Bynario aurait consommé quatre soumissions puis, sur n’importe laquelle des failles critiques signalées ensuite, décroché la voie rapide. Le plafond d’Apple, lui, n’a pas de porte : il compte les soumissions, cesse de compter, et la seule façon d’avancer est un calendrier.

La distinction de conception mérite d’être énoncée sans détour : un plafond de débit ne se défend que si son franchissement dépend de la justesse des rapports, et non d’une attente de 30 jours. Le résumé que GitHub fait de sa refonte est la formule à reprendre : « vous ne gagnez pas plus en soumettant plus. Vous gagnez plus en soumettant mieux. »

Kit applique déjà la moitié « confiance » de cette idée et doit corriger la moitié « bridage ». Csirt::Researcher#karma_tier classe les chercheurs par karma accumulé et atteint trusted à 200 points, alimenté par des valeurs Csirt::KarmaEvent signées : report_validated +5, bounty_awarded +10, contre spam_dismissed -10, ai_slop_confirmed -15, policy_violation -25. Le karma est propre à chaque compte, par choix de conception : le jugement d’un programme ne suit pas un chercheur à travers tout Internet.

Les réglages par défaut de Kit auraient eux aussi bloqué un Bynario. SpamConfig bloque au-delà de 5 rapports en 300 secondes, et le limiteur de débit plafonne les soumissions CSIRT à 10 par heure et par IP. Un déclarant porteur de quarante découvertes vérifiées franchit les deux seuils. Le mode de défaillance d’Apple se retrouve donc dans nos propres réglages par défaut, et le remède n’est pas un chiffre plus élevé : il consiste à compter le lot plutôt que la requête, et à laisser karma_tier relever le plafond pour un déclarant qui l’a mérité.

Triage centré sur la reproduction : cinq champs que votre politique doit exiger

Ross McKerchar, RSSI de Sophos, et Ryan Westman posent la règle sans ambages : les programmes ont besoin de « PoC clairs, de journaux, de traces, de versions affectées et d’étapes reproductibles. Si une affirmation ne peut pas être reproduite, elle n’a pas sa place dans le circuit de traitement. »

Transformez cela en champs de formulaire obligatoires, pas en paragraphes de votre politique. Exigez :

1. Une preuve de concept fonctionnelle. Un script, une requête ou une trace. Un texte qui décrit une exploitation n’est pas un code d’exploitation.
2. Les versions affectées, exactement. Un SHA de commit ou une étiquette de version. Jamais « la dernière ».
3. Des étapes de reproduction qu’un inconnu peut suivre, de l’état vierge jusqu’à l’impact observé.
4. Une partie de cette découverte a-t-elle été produite par un modèle ? Oui ou non, et lequel. Non pas pour pénaliser, mais pour orienter.
5. Un humain a-t-il vérifié cette découverte de bout en bout ? Oui ou non, et qui.

Le champ 5 fait le vrai travail. C’est lui qui sépare le cas Bynario, où une sortie d’IA vérifiée par un humain a produit une faille critique, du contenu bâclé. Presque personne ne le demande aujourd’hui, et il coûte deux booléens et un champ de texte.

Dès l’instant où vous acceptez les campagnes, ajoutez-en deux autres : l’identifiant de lot ou le nom de la campagne, et la date de divulgation demandée, pour que le déclarant inscrive son compteur dans votre dossier plutôt que sur son blog.

Le compteur du régulateur démarre le 11 septembre 2026

Si vous vendez des produits connectés dans l’Union européenne, un seul rapport entrant peut déclencher un délai légal qui n’a rien à voir avec votre file. À partir du 11 septembre 2026, le règlement sur la cyberrésilience impose une alerte précoce sous 24 heures, une notification complète sous 72 heures et un rapport de vulnérabilité final dans les 14 jours suivant une mesure corrective, déposés auprès de votre CSIRT national via la plateforme de notification unique prévue par le CRA et partagés simultanément avec l’ENISA.

Ce compteur se déclenche dès que vous avez connaissance d’une exploitation active. Peu lui importe que le rapport soit arrivé en 23ᵉ position sur 40, qu’aucun humain ne l’ait lu ou qu’un modèle l’ait rédigé. Un lot qui dort quatre jours sans être ouvert constitue un risque de non-conformité, et pas seulement un arriéré. Notre guide du règlement européen sur la cyberrésilience détaille l’obligation dans son intégralité.

Sans circuit de réception, le registre devient votre canal de divulgation

Si un déclarant ne trouve aucun moyen de vous joindre, il n’arrête pas pour autant de signaler. Il publie.

security.txt est le remède le moins cher de la sécurité, et le moins adopté. Une étude de 2025 portant sur le million de domaines les plus fréquentés en a trouvé 1,25 % (12 510 sites) qui en publient un, contre 0,7 % en avril 2024, et seulement 44 % d’entre eux conformes à la RFC 9116. Environ 99 % du web n’a aucun contact de sécurité lisible par une machine, et plus de la moitié des exceptions en ont un mal formé.

Kit génère un fichier conforme à partir de Csirt::SecurityTxtConfig, avec Contact, Policy, Acknowledgments, Encryption et un Expires glissant à 365 jours. Si vous n’avez encore aucun programme, commencez par notre guide de mise en place d’un programme de divulgation des vulnérabilités avant de vous soucier des lots.

Ce que le CSIRT de Kit gère face à une campagne, et ce qu’il ne gère pas encore

Une partie de ce que ce moment exige existe déjà dans Kit. Une autre non, et cette répartition est plus instructive qu’une liste de fonctionnalités.

Ce qui tient la route aujourd’hui :

• Une réception structurée, pas un champ de texte libre. Csirt::Report exige title, description, un vulnerability_type pris dans une liste fixe et affected_endpoint, plus une colonne dédiée reproduction_steps. Cette colonne accepte la valeur nulle, ce que la liste de contrôle ci-dessus juge erroné. La rendre obligatoire est le changement de configuration que ce moment appelle.
• Le dépistage de l’origine IA comme objet de premier rang. Csirt::AiScreening note chaque rapport entrant et renvoie un ai_confidence_score accompagné de signaux issus d’un ensemble fermé (hallucinated_functions, fabricated_cves, no_specific_poc, vague_reproduction_steps, et d’autres), avec une recommandation pass / review / flag. C’est le test de reproductibilité de Sophos mis en œuvre sous forme de colonne plutôt que de paragraphe.
• Le regroupement par cause racine existe déjà comme primitive. Les rapports portent un plongement vectoriel à 3 072 dimensions, et la détection des doublons s’appuie sur le plus proche voisin par similarité cosinus au sein d’un même programme. Là où quarante découvertes ne forment qu’une seule classe de vulnérabilité, c’est le mécanisme qui ramène quarante tickets à un seul.
• La réputation plutôt que le bridage, via karma_tier.
• Un SLA scindé entre accusé de réception et résolution. Csirt::SlaConfig retient par défaut une fenêtre d’accusé de réception de 72 heures, avec des objectifs de résolution par niveau de gravité allant de 24 heures en « super critique » (super_critical) à 720 heures en faible, plus des alertes de dépassement répétées et une escalade vers l’astreinte pour les failles critiques.

Ce qui manque, présenté comme feuille de route et non comme fonctionnalités :

1. Aucune notion de campagne. Quarante rapports restent quarante lignes avec quarante compteurs.
2. Aucun champ de calendrier de divulgation. Le cycle de vie va de submitted à resolved puis paid, sans le moindre vocabulaire pour le compteur du déclarant.
3. Aucun indicateur déclaré « généré par un modèle » ou « vérifié par un humain ». Le dépistage déduit l’origine IA après coup ; rien n’est demandé au déclarant.
4. Des réglages de bridage par défaut qui bloqueraient un déclarant en masse de bonne foi, exactement comme le plafond d’Apple.

Tous les autres articles consacrés à ce registre en font une histoire de modèle. C’est d’abord une histoire de boîte de réception. Les découvertes sont majoritairement réelles, majoritairement non transmises, et elles arrivent. Le changement qui vous y prépare est modeste : faites de la campagne, et non du rapport, l’objet dont votre programme accuse réception, qu’il prend en charge et qu’il chronomètre. Puis inscrivez la date du déclarant dans votre dossier avant qu’il ne l’inscrive sur son blog.