Quand les chercheurs rendent tout public : le prix d'une divulgation ratée

Si un chercheur en sécurité choisit la divulgation complète plutôt que la divulgation responsable, c’est qu’il a perdu confiance dans le processus de l’éditeur, pas parce qu’il cherche à nuire. Le déclencheur est presque toujours opérationnel : un rapport resté sans accusé de réception pendant des semaines, un correctif déployé en douce sans la moindre mention, ou une gravité discrètement rétrogradée en « aucun impact ». Le jour où un chercheur conclut que se coordonner avec vous lui fait perdre son temps, il publie. La faille n’a jamais été le problème. C’est votre processus de divulgation qui l’était.

C’est le problème du « jour 2 » que la plupart des équipes ignorent. Mettre en place un programme de divulgation des vulnérabilités est la partie facile : un fichier security.txt, un périmètre, une boîte de réception. Le gérer pour que de vrais chercheurs vous signalent les failles à vous, au lieu de parler de vous à d’autres, voilà la partie difficile. Et en 2026, le prix d’un programme bâclé s’est étalé au grand jour.

La divulgation de github.dev qui a complètement court-circuité Microsoft

Le 2 juin 2026, le chercheur en sécurité Ammar Askar a publié une preuve de concept complète permettant de voler un jeton OAuth GitHub en un clic dans github.dev, l’éditeur VS Code accessible depuis le navigateur. L’exploit enchaînait la propagation des événements keydown dans la webview de VS Code pour installer silencieusement une extension locale et exfiltrer le jeton de l’utilisateur. Le jeton volé n’était pas limité à un seul dépôt : il donnait accès à tous les dépôts auxquels la victime pouvait accéder, y compris les dépôts privés (sources : BleepingComputer, CSO Online).

La gravité technique était élevée. Mais ce que tout responsable de programme devrait étudier, c’est la divulgation elle-même.

Askar n’a laissé à GitHub qu’une heure de préavis avant de tout publier, et il a explicitement contourné le Microsoft Security Response Center (MSRC). Sa raison affichée : un précédent bug VS Code qu’il avait signalé avait été corrigé en douce, sans aucune mention, et classé comme « sans impact sécurité ». Il en a conclu que le processus ne traiterait pas son travail équitablement, alors il a cessé d’y participer. Un chercheur coopératif s’est mué en lanceur de zero-day à cause de la façon dont un rapport précédent avait été géré.

Toute la leçon tient en une phrase. L’échec de la divulgation a transformé un allié en adversaire, et aucune excellence technique du côté de Microsoft ne pouvait réparer les dégâts une fois le mal fait. Microsoft a déployé un correctif d’urgence (une fenêtre de confirmation pour les notebooks web et un blocage du contournement de la confiance accordée aux éditeurs), mais la confiance était déjà perdue, et l’exploit non corrigé était déjà public.

Divulgation responsable contre divulgation complète, et pourquoi la frontière bouge

La divulgation responsable (aussi appelée divulgation coordonnée des vulnérabilités) consiste pour un chercheur à signaler une faille en privé et à laisser à l’éditeur le temps de la corriger avant qu’aucun détail ne soit rendu public. La divulgation complète, c’est quand le chercheur publie la vulnérabilité, souvent avec un exploit fonctionnel, avant l’existence d’un correctif. La frontière entre les deux n’est pas une question de tempérament. Elle dépend de la conviction du chercheur que l’éditeur tiendra ses engagements.

Le secteur dispose de repères temporels bien connus pour définir ce qu’est un « délai raisonnable pour corriger » :

• Google Project Zero applique un délai de divulgation de 90 jours, ramené à 7 jours pour les failles activement exploitées.
• CERT/CC divulgue 45 jours après le signalement initial, qu’un correctif existe ou non.

(Sources : CERT/CC Guide to Coordinated Vulnerability Disclosure, Wikipedia : Coordinated vulnerability disclosure.)

Ces délais existent parce que les chercheurs avaient besoin d’une norme neutre à invoquer quand un éditeur traînait indéfiniment. C’est l’étalon à l’aune duquel un chercheur exaspéré vous jugera.

Ce que la divulgation responsable exige vraiment d’un éditeur

La divulgation responsable est un accord à double sens. Le chercheur accepte d’attendre et de garder le silence. En échange, l’éditeur s’engage à accuser réception rapidement, à communiquer honnêtement sur la gravité et le calendrier, à corriger la faille et à créditer le chercheur. La plupart des politiques de divulgation publiées le formulent exactement ainsi : de la coopération en échange d’un traitement de bonne foi. Quand un camp tient sa promesse et que l’autre la trahit, l’accord s’effondre.

Quand les chercheurs estiment que le jeu n’en vaut plus la chandelle

Les chercheurs ne sont pas payés pour attendre. Beaucoup font ce travail sur leur temps libre, et leur réputation repose sur la reconnaissance publique. Quand un éditeur traite un rapport comme une corvée, l’ignore, ou efface le crédit qui justifie cet effort bénévole, le réflexe rationnel est d’arrêter de se coordonner. Rendre la faille publique restaure la seule chose que le processus défaillant leur a retirée : la preuve visible de leur travail.

Pourquoi les chercheurs publient : les cinq tueurs de confiance

À travers l’affaire github.dev et l’ensemble des travaux sur les programmes de divulgation, ce sont toujours les mêmes cinq échecs opérationnels qui reviennent. Aucun n’est technique. Chacun est une décision de processus que vous maîtrisez.

1. Accusé de réception lent ou inexistant. Un rapport laissé sans réponse signale au chercheur que son temps ne compte pas.
2. Rétrogradation injustifiée de la gravité. Classer un vrai bug en « aucun impact » ou « faible gravité » passe pour de la mauvaise foi, surtout quand le chercheur ne voit pas le raisonnement.
3. Correctifs silencieux sans mention. Déployer le correctif tout en effaçant le nom du chercheur lui retire toute incitation à signaler en privé.
4. Paiement tardif ou absent. Quand une prime est promise, les retards et les litiges rongent la confiance aussi vite qu’une rétrogradation.
5. Silence radio. Disparaître pendant la période de correction laisse le chercheur deviner si quoi que ce soit avance.

(Sources : OWASP Vulnerability Disclosure Cheat Sheet, entretien HelpNetSecurity avec Roy Davis, Zoom.)

Accusé de réception lent ou inexistant

L’accusé de réception est le signal de confiance le moins coûteux dont vous disposez, et le plus facile à manquer. Un chercheur qui écrit à votre boîte de réception et n’entend plus rien pendant deux semaines n’a aucun moyen de savoir si vous travaillez sur le problème ou si vous l’ignorez. La démarche honnête, c’est une confirmation rapide qu’un humain a bien reçu le rapport et le prend en charge. Les programmes gouvernementaux en font un minimum vital : le Département du Commerce américain et le Département de l’Intérieur s’engagent tous deux à accuser réception sous 3 jours ouvrés, et Silicon Labs prend le même engagement. Si des agences fédérales tiennent la barre des 3 jours, une startup le peut aussi.

Rétrogradation injustifiée de la gravité

Les désaccords sur la gravité sont le deuxième point de friction le plus courant, et ils sont évitables. Le problème n’est pas la note elle-même ; c’est qu’elle tombe comme un verdict opaque que le chercheur ne peut ni examiner ni contester. Une rétrogradation qui ressemble à une manœuvre pour esquiver une prime ou minimiser l’embarras passe pour de la mauvaise foi, même quand elle n’en est pas. La solution : asseoir la gravité sur un référentiel standard et transparent (CVSS) et montrer votre démarche, afin que le chercheur voie les mêmes éléments que vous.

Correctifs silencieux sans mention

C’est l’échec qui a déclenché la divulgation de github.dev. Le chercheur a signalé un bug, l’éditeur l’a corrigé en douce, et le nom du chercheur n’apparaissait nulle part. Pour quelqu’un qui bâtit sa carrière sur la reconnaissance publique, un correctif silencieux est pire qu’un rejet. Il prend le travail et la reconnaissance. Le crédit, qu’il s’agisse d’une mention dans un CVE ou d’une entrée au tableau d’honneur, ne vous coûte rien et reste le moyen le plus fiable de faire en sorte qu’un chercheur vous signale encore la prochaine fois.

Paiement tardif ou absent

Si vous gérez un programme rémunéré, la prime est une promesse. Les chercheurs citent régulièrement les paiements irréguliers ou tardifs comme la raison pour laquelle ils abandonnent un programme. Un processus de versement prévisible et auditable compte plus qu’une grosse récompense annoncée. Le flou sur le quand et le si du paiement fait plus de dégâts qu’une prime modeste mais fiable.

Silence radio

Même quand vous faites le travail, le silence passe pour de la négligence. Les recommandations de l’OWASP sont explicites : envoyez des points d’étape réguliers même quand il n’y a aucun progrès à signaler, parce que le point d’étape lui-même est le signal que le rapport n’a pas été oublié. Un « on y travaille toujours, voilà où on en est » d’une ligne toutes les deux semaines fait souvent la différence entre un chercheur qui patiente et un chercheur qui publie.

Ce n’est pas un cas isolé : la vague de zero-days publics de 2026

L’affaire github.dev n’était pas une exception. La même fenêtre d’avril à juin 2026 a vu un chercheur connu sous le nom de « Chaotic Eclipse » lâcher publiquement six zero-days Windows non corrigés, dont trois déjà activement exploités. Les raisons invoquées composaient une liste familière : rapports ignorés, compte de signalement supprimé, zéro rémunération, et le sentiment d’avoir été diffamé par la manière dont un avis de sécurité CVE décrivait son travail (sources : SecurityAffairs, The Hacker News).

Microsoft a publiquement condamné ces divulgations « non coordonnées » comme exposant ses clients à un risque inutile, avant de tendre un rameau d’olivier face au tollé. L’enchaînement est instructif : accabler le chercheur n’a pas réparé le processus, et n’a pas empêché la divulgation suivante. Quand un même schéma de défaillance produit plusieurs publications en un seul trimestre, et ce contre l’une des organisations de sécurité les mieux dotées de la planète, ce n’est plus un problème de chercheurs : c’est un problème de conception de programme.

Ce qu’un VDP digne de confiance fait différemment

Un programme digne de confiance transforme chacun des cinq tueurs de confiance en un engagement sur lequel le chercheur peut compter. Les mécanismes n’ont rien d’ésotérique ; c’est de la discipline opérationnelle appliquée avec constance.

Le fil rouge de tout cela, c’est le respect du temps et du travail du chercheur. Faites-le bien et le compte à rebours de la divulgation reste privé. Faites-le mal et le chercheur sortira les 90 jours de Project Zero ou les 45 jours du CERT/CC comme la norme que vous n’avez pas su tenir.

Comment Kit opérationnalise la confiance des chercheurs

Le module de sécurité de Kit (Csirt) a été conçu précisément autour de ces modes de défaillance. Vous former au modèle de fonctionnement compte plus que n’importe quel outil, mais l’intérêt d’un outil, c’est qu’il fait du bon comportement le réglage par défaut, plutôt qu’une chose dont il faut se souvenir sous pression. Voici comment chaque tueur de confiance se traduit en un réglage concret.

Pour être clair sur ce que Kit peut et ne peut pas prétendre : Kit n’a rien à voir avec le bug de github.dev, et aucun outil ne l’aurait « empêché ». C’était le produit de Microsoft. Ce que Kit corrige, c’est l’échec du processus de divulgation qui a poussé le chercheur vers la divulgation complète. Si votre entreprise recevait un rapport comme celui-là, le SLA d’accusé de réception de Kit, sa gravité CVSS transparente, son crédit par défaut et ses versements prévisibles sont ce qui maintient le chercheur en coordination avec vous, plutôt que de le voir publier un exploit non corrigé.

Votre processus de divulgation, c’est votre posture de sécurité

La leçon des publications de zero-days de 2026 est inconfortable, mais simple : les chercheurs ne rendent pas les choses publiques par hostilité. Ils le font parce que le processus a manqué de respect à leur temps et à leur travail. Accusé de réception lent, rétrogradations opaques de gravité, correctifs silencieux, paiement tardif et silence radio ne sont pas de petits ratés administratifs. Ce sont la cause directe d’exploits non corrigés qui atterrissent sur Hacker News avec votre nom accolé.

Chacun de ces échecs est une décision que vous maîtrisez, et chacun se traduit par un réglage que vous pouvez corriger dès aujourd’hui. Si vous avez déjà un VDP, l’étape suivante n’est pas davantage de politique ; ce sont les opérations du « jour 2 » qui gardent les chercheurs de votre côté. Commencez par le guide de mise en place si vous n’y êtes pas encore, puis transformez votre réception en un flux adossé à un SLA, crédité et rémunéré. Quand vous serez prêt à le gérer correctement, vous pouvez démarrer un essai gratuit et avoir l’ensemble opérationnel en une après-midi.