Le fait, d'abord, parce qu'il est brutal. Un chercheur en sécurité, Ammar Askar, a découvert une vulnérabilité sérieuse dans Visual Studio Code — l'éditeur de code le plus utilisé au monde. Il en a informé un contact chez GitHub. Puis, environ une heure plus tard, il a publié un exploit fonctionnel. La faille, d'après ce qui en est rapporté par SecurityAffairs, permettrait une exécution de code « juste en cliquant sur un lien ». Sa justification : un historique de différends avec Microsoft sur la manière dont l'éditeur traite les signalements de bugs.
Une heure entre le signalement privé et la publication de l'arme. Pour quiconque connaît les usages du secteur, c'est un geste rare et lourd de sens. Et avant de le condamner ou de l'applaudir, il faut comprendre le mécanisme qu'il met en lumière — parce que ce mécanisme nous concerne tous, bien au-delà de VS Code.
Les faits, et ce qu'on ne sait pas
Soyons précis sur la frontière entre ce qui est établi et ce qui ne l'est pas. Ce qui est rapporté : la découverte d'une faille sérieuse dans VS Code, un signalement à un contact chez GitHub, la publication d'un exploit fonctionnel environ une heure après, et une motivation explicite tenant à des litiges passés avec Microsoft sur le traitement des vulnérabilités.
Ce que je ne sais pas, et que je ne vais donc pas inventer : le détail technique exact de la faille, l'état d'un correctif au moment où vous lisez ces lignes, ni la version complète de Microsoft sur l'historique invoqué. Cet article n'est pas une analyse de la vulnérabilité ligne par ligne. C'est une réflexion sur la mécanique de divulgation que l'affaire rend visible — et sur ce qu'elle devrait changer dans votre manière de voir les outils que vous utilisez tous les jours.
Ce qu'est censée être la divulgation responsable
Pour mesurer l'écart, il faut rappeler la norme. La « divulgation coordonnée » est le contrat tacite qui régit la sécurité depuis des années. Il tient en quelques étapes simples.
Un chercheur trouve une faille. Il la signale en privé à l'éditeur, généralement par un canal dédié. L'éditeur accuse réception, évalue, développe un correctif. Pendant ce temps — souvent quatre-vingt-dix jours, par convention — le chercheur garde le silence. À la sortie du correctif, ou à l'expiration du délai, les détails sont publiés, et le chercheur reçoit le crédit de sa découverte.
Ce contrat n'est pas une politesse. C'est un équilibre entre trois intérêts qui tirent dans des directions opposées. Les utilisateurs, qui ont besoin d'un correctif avant que la faille ne soit connue des attaquants. L'éditeur, qui a besoin de temps pour corriger proprement. Et le chercheur, qui a besoin de reconnaissance et d'une garantie qu'on ne va pas enterrer son travail ni le poursuivre en justice. Quand le contrat fonctionne, tout le monde y gagne : la faille est corrigée discrètement, et le monde l'apprend une fois la porte déjà refermée.
Pourquoi un chercheur compétent brûle ce contrat
Reste la vraie question : qu'est-ce qui pousse quelqu'un d'assez bon pour trouver une faille critique dans VS Code à publier un exploit une heure après l'avoir signalée ? La réponse honnête, c'est presque toujours l'usure. La divulgation responsable repose sur une réciprocité. Le chercheur offre du temps et du silence ; en échange, il attend une prise au sérieux, une communication, un crédit. Quand ce retour n'arrive pas — réponses automatiques, mois de silence, faille minimisée puis corrigée en douce sans un mot de remerciement, voire menaces juridiques — le contrat se vide de sens du point de vue du chercheur.
Au bout de plusieurs expériences de ce genre, certains concluent que le canal privé ne sert qu'à enterrer leur travail. Alors ils changent d'arme. La publication immédiate devient un levier : c'est le seul moyen qu'il leur reste de forcer une réaction, d'obtenir une reconnaissance publique, ou simplement d'exprimer une colère accumulée. Le geste d'Askar, dans la manière dont il est rapporté, s'inscrit exactement dans cette logique : une décision motivée non par la faille du jour, mais par l'historique de la relation.
Comprendre cette mécanique n'est pas l'excuser. C'est refuser l'explication paresseuse du « chercheur irresponsable ». Un système où des gens compétents finissent par juger que faire exploser une faille au grand jour est plus efficace que de la signaler proprement, c'est un système qui a un problème structurel — pas seulement un problème d'individus.
Il faut ajouter un facteur que peu de gens mesurent : l'asymétrie de pouvoir. D'un côté, une multinationale avec une armée de juristes et un service de communication. De l'autre, un individu, souvent bénévole, qui a investi des dizaines d'heures à trouver et documenter une faille. Quand le rapport de force est aussi déséquilibré, le seul contre-pouvoir réel dont dispose le chercheur, c'est la publication. Il le sait, et l'éditeur le sait aussi. C'est précisément pour neutraliser ce levier — pour éviter qu'on en arrive là — qu'un bon programme de divulgation existe. Le supprimer ou le négliger ne fait pas disparaître le levier ; ça pousse seulement à l'utiliser.
L'autre côté : pourquoi le geste reste dangereux
Et pourtant. Comprendre la frustration ne doit pas faire oublier qui paie l'addition, et ce n'est ni le chercheur ni l'éditeur. Ce sont les utilisateurs.
Quand un exploit fonctionnel est publié une heure après le signalement, aucun correctif n'existe. Les millions d'utilisateurs de VS Code se retrouvent exposés à une faille « cliquez sur un lien » dont le mode d'emploi est désormais public, sans aucun moyen de se protéger autrement qu'en cessant d'utiliser l'outil. Le bras de fer entre un chercheur et une multinationale est mené avec, comme otages, des gens qui n'ont aucune part au conflit.
C'est la limite morale de la divulgation immédiate. Elle peut se défendre comme acte de dernier recours face à un éditeur de mauvaise foi — l'histoire de la sécurité compte de vrais cas où seule la publication a forcé un correctif après des mois d'inertie. Mais elle convertit un désaccord en risque collectif. Et la frontière entre « j'ai épuisé tous les recours » et « j'ai perdu patience après une heure » est exactement celle qui sépare un acte défendable d'un acte qui ne l'est pas. Une heure, ce n'est pas un recours épuisé. C'est un délai qui ne laisse à personne la moindre chance de réagir.
Ce que l'affaire dit vraiment, et qui nous concerne tous
Le débat « chercheur vs éditeur » est un piège : il fait croire que l'affaire se joue entre deux parties lointaines. Or elle dit trois choses qui touchent directement quiconque écrit ou exploite du logiciel.
D'abord, vos outils de développement sont une surface d'attaque. On blinde les serveurs de production, et on installe sans réfléchir des extensions et des éditeurs qui ont accès à tout notre code, à nos clés, à notre environnement. Une faille « clic sur un lien » dans l'éditeur où vous passez vos journées, c'est potentiellement une porte vers tout ce que vous touchez. La leçon rejoint celle de toute cette semaine : le danger n'est pas que dans ce que vous produisez, il est aussi dans ce que vous utilisez sans le surveiller. C'est précisément la posture qu'on installe dans le Bootcamp DevSecOps — traiter la chaîne de développement comme une partie du périmètre à sécuriser, pas comme un environnement de confiance par défaut.
Ensuite, la fenêtre entre divulgation et correctif est un moment de danger maximal, et il ne dépend pas de vous. Quand un exploit sort sans correctif, votre seule défense est la réactivité : savoir vite que l'outil est concerné, et appliquer la mesure d'atténuation — désactiver une fonction, éviter un type de lien, attendre le patch. Cela suppose une veille. Pas une veille d'expert : juste l'habitude de savoir ce qui tourne chez vous et de suivre les annonces qui le concernent.
Enfin, la santé de l'écosystème de divulgation est un sujet de sécurité, pas un drame de personnes. Si les chercheurs cessent de faire confiance aux canaux privés, tout le monde perd : on bascule vers un monde où les failles sortent sans préavis. La qualité d'un programme de divulgation — délais de réponse tenus, crédit donné, communication honnête, protection juridique des chercheurs de bonne foi — n'est pas de la communication. C'est un dispositif de sécurité qui protège les utilisateurs finaux, en gardant les chercheurs dans le cadre coopératif.
Ce qu'il faut retenir
Cette affaire n'a pas de héros propre. Un chercheur visiblement à bout, un éditeur dont les pratiques de divulgation sont mises en cause, et au milieu, des utilisateurs exposés sans l'avoir demandé. La vraie leçon n'est pas de désigner un coupable, mais de voir le système : la divulgation responsable est un équilibre fragile, et chaque relation chercheur-éditeur qui se dégrade rapproche un peu plus le moment où les failles sortiront brutes, sans correctif, dans la nature.
Pour vous, concrètement, trois réflexes. Considérez vos outils de développement comme une partie de votre surface d'attaque, au même titre que vos serveurs. Mettez en place le minimum de veille qui vous permet d'apprendre vite qu'un outil que vous utilisez est concerné. Et si vous êtes du côté de ceux qui reçoivent des signalements de failles, rappelez-vous que la manière dont vous traitez un chercheur aujourd'hui détermine s'il vous laissera quatre-vingt-dix jours la prochaine fois — ou une heure.
La sécurité n'est pas qu'une affaire de code. C'est aussi une affaire de confiance entre les gens qui le cassent pour le réparer et ceux qui le maintiennent. Quand cette confiance se brise, c'est l'utilisateur, toujours, qui se retrouve dans la ligne de tir.