Divulgation publique : les chercheurs qui lâchent l'éditeur

Trois zero-days Microsoft Defender lâchés dans la nature en quinze jours. Pas par un groupe APT, pas par un courtier d'exploits — par un chercheur indépendant qui a fini par claquer la porte après dix-huit mois de tentatives de communication constructive avec MSRC. Ce n'est pas un cas isolé, c'est un signal. Et il dit que le modèle de divulgation responsable, tel qu'on l'a connu pendant vingt ans, est en train de craquer sous le poids de pratiques qui ont progressivement déséquilibré un contrat moral autrefois fonctionnel. Les conséquences ne sont pas théoriques : elles se mesurent en jours d'exposition supplémentaires, en fenêtres d'exploitation non anticipées, et en SOC qui doivent défendre contre des menaces que leurs outils de patch management ne leur ont pas signalées. Voici ce qui se passe réellement, pourquoi les éditeurs en portent une responsabilité directe, et ce que les équipes défensives doivent changer maintenant.

Le contrat moral de la divulgation responsable : comment il a été cassé

Le deal historique entre chercheurs et éditeurs tenait sur trois engagements implicites, formalisés progressivement par des programmes comme Google Project Zero et les bug bounties majeurs. Premièrement, le chercheur remonte la faille de manière privée. Deuxièmement, l'éditeur la corrige dans un délai raisonnable — 90 jours est la norme établie par Project Zero depuis 2014. Troisièmement, le chercheur est crédité publiquement, ce qui lui apporte une reconnaissance professionnelle directement monnayable dans sa carrière.

Ce mécanisme a fonctionné pendant des années. Il a permis de corriger des milliers de vulnérabilités critiques avant qu'elles ne soient découvertes et exploitées par des acteurs malveillants. Google Project Zero, la plus grande success story du modèle, a documenté des centaines de cas où la divulgation coordonnée a précédé l'exploitation.

Mais depuis 2022-2023, et de manière de plus en plus visible en 2025-2026, le contrat dérive côté éditeurs. Les tickets MSRC se ferment "by design" alors que la preuve d'exploitation existe. Les bug bounties sont requalifiés à la baisse au moment du paiement — le chercheur soumet une vulnérabilité RCE pre-auth, elle est requalifiée en "information disclosure" à l'examen pour réduire la prime. Les patches sont publiés sans crédit, ou avec un crédit générique du type "external researcher" qui efface toute trace de qui a trouvé quoi.

Et les délais s'allongent. Neuf mois, douze mois, dix-huit mois entre soumission et publication du correctif ne sont plus des exceptions — ils sont devenus la norme pour une certaine catégorie de vulnérabilités que les éditeurs jugent trop complexes à corriger sans régression majeure. Pendant ce temps, le chercheur est tenu au silence par l'accord de divulgation coordonnée, pendant que des attaquants qui ont redécouvert la même faille par d'autres voies l'exploitent activement.

L'économie de la divulgation : pourquoi les chercheurs publient

Le résultat est mécanique et prévisible : un chercheur qui passe trois mois à fouiller un binaire, à développer un PoC stable et à documenter la chaîne d'exploitation n'accepte plus qu'on lui réponde "merci, c'est noté" suivi d'un silence radio de neuf mois, d'une requalification à 5 000 dollars d'une vulnérabilité qui en vaut 250 000 sur le marché, et d'un crédit "external researcher" dans les notes de bas de page du bulletin.

Il a alors plusieurs options. La première est de vendre la vulnérabilité à un courtier d'exploits. Le marché gris (et parfois noir) des zero-days est parfaitement organisé en 2026. Zerodium publie sa grille tarifaire : un zero-day RCE pre-auth sur Windows vaut jusqu'à 2 500 000 dollars. Un exploit Defender SYSTEM se monnaye sans difficulté à six chiffres. Ces prix reflètent la valeur que les acheteurs — services de renseignement, forces de l'ordre, mais aussi acteurs moins recommandables — accordent à ces vulnérabilités.

La deuxième option est la divulgation publique directe, sans coordination préalable. C'est ce qu'a fait le chercheur qui a publié les trois zero-days Defender en avril 2026. Cette option est moralement contestable — elle arme potentiellement des attaquants — mais elle est pragmatiquement compréhensible dans le contexte décrit. Et elle génère une pression publique immédiate sur l'éditeur, qui doit livrer un patch en urgence sous les projecteurs.

La troisième option — de plus en plus fréquente — est la divulgation avec délai d'avertissement raccourci. Plutôt que de respecter 90 jours, le chercheur notifie l'éditeur avec un délai de 7 à 14 jours, puis publie quel que soit l'état du patch. C'est une forme de pression organisée qui respecte formellement le principe de la notification préalable tout en supprimant la marge de manœuvre que les éditeurs utilisaient pour différer indéfiniment.

Les éditeurs qui ont créé l'incitation à publier

Microsoft, pour ne citer que lui, concentre le plus grand volume de critiques de la part de la communauté de recherche en sécurité. Le programme MSRC est devenu un guichet où la décision de payer ou non est opaque, les critères de gravité sont régulièrement revus à la baisse au moment du triage, et le délai entre soumission et accusé de réception formel s'est allongé au point de devenir une source de frustration documentée par plusieurs chercheurs de premier plan sur des conférences comme DEF CON et Black Hat.

En 2024, au moins trois chercheurs ayant soumis des vulnérabilités critiques à Microsoft ont témoigné publiquement — avec preuves à l'appui — que leurs soumissions avaient été fermées comme "not a security issue" ou "by design", avant d'être réouvertes quelques mois plus tard après exploitation in-the-wild. Ce pattern — rejeter la soumission du chercheur, attendre l'exploitation, puis corriger discrètement — est perçu par la communauté comme une forme de déni organisé qui permet à l'éditeur d'économiser sur les primes tout en évitant la publicité d'une reconnaissance publique des vulnérabilités.

Google et Apple ne sont pas exempts de critiques, mais leur gestion des bug bounties et leurs délais de réponse sont globalement considérés comme meilleurs. La différence se mesure dans les chiffres : Google a versé plus de 12 millions de dollars en primes de bug bounty en 2023. Microsoft, avec une surface logicielle bien plus large, est très en dessous proportionnellement.

Les conséquences opérationnelles pour les équipes défensives

Ce déplacement du modèle de divulgation a deux conséquences directes pour les équipes qui défendent des systèmes en production, et elles modifient substantiellement ce que signifie "avoir une bonne posture de sécurité".

Conséquence 1 : la fenêtre entre publication et exploitation de masse se rétrécit à l'état de peau de chagrin. Quand un PoC est publié directement sans coordination préalable, il n'y a pas de patch disponible. La fenêtre d'exposition commence au moment de la publication et se termine... au moment où un patch est livré, qui peut être plusieurs semaines plus tard. Pendant ce temps, votre posture défensive repose entièrement sur votre capacité de détection comportementale — pas sur l'existence d'un patch.

Conséquence 2 : les patches ne couvrent plus l'ensemble du risque connu. Quand un chercheur publie un zero-day sans correctif disponible (ce que certains appellent une "zero-day disclosure sauvage"), le Patch Tuesday habituel devient mécaniquement insuffisant. Votre workflow de patch management, conçu pour appliquer des correctifs disponibles, ne peut rien contre une vulnérabilité connue publiquement mais non corrigée. Ce cas de figure était rarissime il y a cinq ans. Il devient régulier.

La conséquence opérationnelle est claire : la posture de détection doit primer sur la posture de remédiation dans les scénarios post-divulgation sauvage. Surveiller les comportements anormaux — un MsMpEng.exe qui spawne un cmd.exe, un service qui écrit hors de son arborescence habituelle, un processus de sécurité qui établit des connexions sortantes inhabituelles — devient plus rentable que la course aux patches sur des vulnérabilités dont le correctif n'existe pas encore.

C'est un changement culturel important pour beaucoup d'équipes qui ont structuré leur SOC autour des CVE et des patches. La détection comportementale exige un investissement initial plus important — baseline, tuning, gestion des faux positifs — mais c'est la seule défense effective contre les vulnérabilités publiées sans correctif.

Ce que les RSSI doivent faire maintenant

Face à ce nouveau paradigme, voici les adaptations concrètes à engager.

Action 1 — Étendre la veille au-delà des CVE officielles. Les vulnérabilités qui font l'objet d'une divulgation sauvage ou d'une publication avec délai raccourci n'entrent pas toujours immédiatement dans les bases CVE. Il faut surveiller les comptes Twitter/X et Mastodon de chercheurs reconnus, les repositories GitHub qui publient des PoC, les forums de sécurité spécialisés. FullDisclosure et les listes de sécurité de Google Project Zero sont des sources à intégrer dans votre veille.

Action 2 — Préparer des règles de détection comportementale pour les outils de sécurité eux-mêmes. Si les zero-days récents ciblent MsMpEng.exe, il faut des règles qui détectent les comportements anormaux de ce processus spécifiquement. Le SIEM et l'EDR doivent avoir des règles qui alertent quand un processus de sécurité fait des choses qu'il ne fait normalement pas : connexions réseau sortantes, création de processus enfants, accès à des chemins inhabituels.

Action 3 — Implémenter une politique de moindre privilège sur les agents de sécurité. Un agent EDR ou antivirus qui tourne avec des privilèges SYSTEM est une cible attrayante. Certains éditeurs permettent de limiter les privilèges de leurs agents dans des environnements de production — explorez cette option pour réduire l'impact potentiel d'une compromission de l'agent lui-même.

Action 4 — Tester régulièrement la détection comportementale via des red team exercises. La question n'est plus "est-ce que notre EDR détecte les malwares connus ?" mais "est-ce que notre stack de détection identifie des comportements anormaux sur nos outils de sécurité eux-mêmes ?". Cette question nécessite des exercices spécifiques qui sont encore rares dans la plupart des organisations.

Conclusion

Les trois zero-days Defender d'avril 2026 ne sont pas un accident. Ils sont l'aboutissement logique d'une décennie de dégradation des relations chercheurs/éditeurs, accélérée par des pratiques de bug bounty de plus en plus perçues comme prédatrices par la communauté qui génère la valeur.

Les RSSI doivent intégrer cette nouvelle donne dans leur modélisation de risque : compter sur le calendrier de patch d'un éditeur ne suffit plus. Il faut compter sur sa propre capacité de détection comportementale, son hygiène d'accès, et la résilience de son architecture face à des vulnérabilités connues mais non corrigées. La fenêtre entre "vulnérabilité connue publiquement" et "patch disponible" peut désormais durer des semaines. C'est pendant cette fenêtre que l'attaquant est le plus actif. Et c'est précisément là que la détection comportementale fait la différence entre un incident détecté et un incident découvert a posteriori dans un rapport d'audit.

Le delai de divulgation : 90 jours, mythe ou norme operationnelle ?

La norme des 90 jours de divulgation coordonnee, popularisee par le Project Zero de Google en 2014, a transforme les relations entre chercheurs et editeurs mais genere aussi de nouvelles tensions. Cette convention stipule que le chercheur notifie l'editeur de la vulnerabilite decouverte et lui laisse 90 jours pour produire et deployer un correctif avant publication des details techniques. Si le delai expire sans correctif disponible, le chercheur publie les details independamment, parfois avec du code d'exploitation fonctionnel.

En theorie, ce cadre est raisonnable : il incite les editeurs a corriger rapidement et empeche les chercheurs de garder indefiniment des informations sur des vulnerabilites non corrigees qui pourraient etre decouvertes et exploitees en parallele par des acteurs malveillants. En pratique, la regle des 90 jours s'applique mal aux ecosystemes logiciels complexes ou un correctif necessite des tests de non-regression sur des centaines de versions de produits, des certifications de securite pour les secteurs regules, ou des approbations de direction pour les systemes critiques d'infrastructure. Ces contraintes operationnelles reelles ne sont pas toujours visibles des chercheurs independants qui operent sans connaitre les complexites internes de l'editeur.

Les exceptions au delai de 90 jours sont possibles mais elles doivent etre negociees explicitement et documentees pour eviter les abus. Les editeurs qui demandent systematiquement des extensions sans fournir de preuves d'avancement dans la correction perdent rapidement leur credibilite aupres de la communaute des chercheurs, qui devient alors moins incite a pratiquer la divulgation responsable. La transparence sur l'avancement de la correction — communication reguliere du chercheur sur les etapes cles atteintes, meme sans reveler les details techniques — est l'element qui permet de maintenir la confiance mutuelle au-dela des aspects purement contractuels ou proceduraux.

Vers un nouveau contrat de confiance entre chercheurs, editeurs et defenseurs

La crise actuelle de la divulgation responsable appelle a une refondation du contrat de confiance entre les trois parties prenantes principales : les chercheurs en securite qui decouvrent les vulnerabilites, les editeurs qui doivent les corriger, et les equipes de defense qui doivent proteger leurs organisations pendant la fenetre de vulnerabilite. Chacune de ces parties a des interets legitimes qui ne sont pas naturellement alignes, et le systeme actuel ne crée pas suffisamment d'incitations a leur convergence.

Les programmes de bug bounty evolues, comme ceux de Google, Microsoft ou HackerOne, representent une tentative de realignement des incitations. En remunerant les chercheurs pour leurs decouvertes et en leur offrant une reconnaissance publique via des halls of fame, ces programmes creent un canal de divulgation responsable economiquement viable pour les chercheurs independants. Les editeurs qui investissent serieusement dans leurs programmes de bug bounty obtiennent generalement de meilleurs resultats que ceux qui traitent les rapports de vulnerabilites comme une contrainte externe perturbatrice.

La coordination internationale entre les agences de cybersecurite nationales (ANSSI, BSI, CISA) sur les questions de divulgation pourrait contribuer a harmoniser les pratiques et a resoudre les situations ou des vulnerabilites critiques dans des systemes industriels ou d'infrastructure vitale necessitent des traitements particuliers qui depassent le cadre standard de 90 jours. Des mecanismes de mediation formels, impliquant les agences nationales comme tiers de confiance, permettraient de gerer les cas complexes sans recours a la pression publique que les chercheurs utilisent parfois par defaut quand les canaux normaux echouent.

Responsabilite et protection juridique des chercheurs en securite

La protection juridique des chercheurs en securite qui pratiquent la divulgation responsable reste insuffisante dans de nombreuses juridictions. En France, le cadre legal distingue le chercheur qui identifie une vulnerabilite de maniere incidente lors de ses recherches legitimes de celui qui cherche deliberement a compromettre des systemes. La loi Informatique et Libertes et le Code penal francais encadrent ces situations, mais les zones grises sont nombreuses et le risque de poursuite penale demeure pour des chercheurs de bonne foi. L'ANSSI a publie des recommandations sur la divulgation coordonnee qui offrent un cadre de reference, mais sans valeur normative contraignante pour les editeurs ou les autorites judiciaires.

La formation des equipes de developpement a la securite est un levier souvent oublie dans les discussions sur la divulgation responsable. Reduire le nombre de vulnerabilites introduites en production en premier lieu est la meilleure facon de reduire la pression sur l'ecosysteme de divulgation. Les programmes de formation secure coding, les revues de code orientees securite et les outils d'analyse statique integres dans les pipelines CI/CD contribuent a diminuer le stock de vulnerabilites qui alimentent les rapports de chercheurs en securite. Cette approche preventive est complementaire — et non substituable — aux processus de divulgation responsive qui traitent les vulnerabilites inevitables qui echappent aux mecanismes de prevention.

L'education des equipes de securite defensives sur les techniques de publication de recherche et les motivations des chercheurs en securite est tout aussi importante. Les RSSI et leurs equipes qui comprennent que les chercheurs en securite ne sont pas des adversaires mais des acteurs qui contribuent a la securite globale de l'ecosysteme developpent des reflexes de reponse plus constructifs quand ils recoivent un rapport de vulnerabilite. Cette comprehension mutuelle facilite la collaboration et reduit les tensions inutiles qui ralentissent la correction des vulnerabilites et nuisent en definitif a la securite des utilisateurs finaux des produits concernes.