Le 12 août 2026, MyDr sp. z o.o., éditeur polonais de logiciels de dossiers médicaux électroniques, a confirmé sur [sa propre page d'incident](https://pro.mydr.pl/portal-info) avoir « été la cible d'une action criminelle externe et délibérée » touchant « une partie des données ». En parallèle, les attaquants ont affirmé au site polonais de sécurité Zaufana Trzecia Strona détenir 18 814 422 numéros PESEL uniques, l'identifiant national polonais. MyDr ne confirme ni ce chiffre ni aucun autre. Ce que cette affaire partage avec quatre autres fuites majeures sur trois continents est plus étroit, et bien plus facile à corriger, que n'importe laquelle de leurs causes profondes : le jour où quelqu'un, hors de l'entreprise, a voulu signaler quelque chose, il n'existait aucun canal prévu pour cela.

Un programme de divulgation des vulnérabilités (VDP) n'aurait empêché aucune de ces cinq fuites. Ce qui se joue ici, c'est qui l'apprend en premier, et au bout de combien de temps.

## Ce qui s'est passé chez MyDr, et les trois chiffres qui ne concordent pas

MyDr édite des logiciels de dossiers patients et de gestion de cabinet pour les cliniques polonaises ; le groupe Docplanner (ZnanyLekarz) a annoncé son rachat le 9 janvier 2023. Trois chiffres circulent aujourd'hui, et ils ne concordent pas.

- **Revendiqué par les attaquants :** 18 814 422 numéros PESEL uniques et environ 2,5 To. Zaufana Trzecia Strona indique n'avoir pu vérifier ni l'un ni l'autre.
- **Affirmé par le gouvernement :** le vice-Premier ministre Krzysztof Gawkowski a déclaré le 12 août que près de 19 millions de dossiers avaient été volés, « ce que l'entreprise elle-même confirme » ([Bankier](https://www.bankier.pl/wiadomosc/Cyberatak-na-MyDr-Gawkowski-Mozliwy-wyciek-danych-blisko-19-mln-Polakow-9181057.html), 2026).
- **Confirmé par MyDr :** rien. Sa page, mise à jour à 18 h 35 (CET) le jour même, indique que l'entreprise ne peut confirmer ni la quantité ni la nature des données divulguées, et décrit les données concernées comme « très probablement historiques, de 2024 et des années antérieures ».

Les deux sources sont primaires, publiées à quelques heures d'intervalle, et elles se contredisent sur le fait central. Aucun décompte confirmé n'existe à ce jour. Zaufana Trzecia Strona a bien vérifié une partie de l'échantillon des attaquants, dont la fiche d'un responsable politique de premier plan et trois correspondances lors d'un test sur cinq numéros PESEL. Cela corrobore le fait que les attaquants détiennent des données qui ont bien la forme de celles de MyDr. Cela ne corrobore pas les 18,8 millions.

La cause profonde est revendiquée par les attaquants et non vérifiée : une faille XXE dans le traitement des certificats menant à l'exécution de code, une clé d'API GitHub volée, puis AWS. MyDr n'a publié aucun détail technique, et l'attribution est délibérément brouillée : aucun groupe ni aucun pays ne doit donc être nommé. Les dates de détection sont inconnues, l'entreprise déclarant ne pas pouvoir les communiquer tant que l'enquête est en cours ; aucune durée de présence ne doit donc être déduite.

La chronologie, elle, est le vrai sujet. Le 5 août, les attaquants ont montré à des journalistes la capture d'écran d'un message qu'ils disaient avoir envoyé au PDG de la société propriétaire de la plateforme : un lien vers un PDF dont le mot de passe n'était autre que le numéro PESEL du PDG. Le 8 août, ils ont contacté la presse. La première déclaration de MyDr date du 10 août, le jour même où ces journalistes ont publié.

Les patients polonais ne peuvent toujours pas vérifier s'ils sont concernés. MyDr est sous-traitant au sens du RGPD : le communiqué du 12 août de l'UODO, l'autorité polonaise de protection des données, fait donc peser l'obligation d'informer les personnes sur les responsables de traitement, c'est-à-dire les milliers de cabinets qui utilisaient le logiciel. Quant au portail national de vérification des fuites, il précise que les données de MyDr n'y ont pas été chargées.

Et pour signaler une faille ? Vérification faite le 12 août 2026, `mydr.pl/.well-known/security.txt` redirige vers une page fourre-tout et `pro.mydr.pl` renvoie une 404. Le seul fichier RFC 9116 du groupe se trouve sur la marque grand public `znanylekarz.pl` : 44 octets, une ligne `Contact:`, aucun champ `Expires`, pourtant exigé par la RFC. Ce constat porte sur l'existence d'un canal, rien d'autre : il ne dit rien de la cause. Rien n'indique que qui que ce soit ait jamais tenté de signaler quoi que ce soit.

## Comment les entreprises apprennent-elles qu'elles ont été compromises ?

En 2025, **52 %** seulement des organisations ont détecté elles-mêmes l'activité malveillante en premier. **34 %** l'ont appris d'un tiers, forces de l'ordre ou CERT, et **14 %** de l'attaquant lui-même, en général dans une demande de rançon ([Mandiant M-Trends 2026](https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026/), 2026). La durée de présence médiane s'établissait à 14 jours : **9 jours** en cas de détection interne, **25 jours** lorsque c'est quelqu'un d'autre qui a découvert l'intrusion en premier, contre 11 l'année précédente.

Cet écart, c'est le prix de l'absence de canal pour être prévenu.

## Change Healthcare : 190 millions de personnes, une migration jamais terminée

Le rapport annuel 10-K 2024 d'UnitedHealth évoque « environ 190 millions » de personnes. Le chiffre plus élevé de 192,7 millions provient du portail des fuites de données de l'OCR (ministère américain de la Santé) et de la presse spécialisée, et non d'un document déposé auprès de la SEC ; le décompte transmis à l'OCR est parti d'un chiffre provisoire de 500 personnes, puis a grimpé pendant environ dix-huit mois.

La cause profonde figure dans le témoignage sous serment du PDG Andrew Witty : le 12 février 2024, des criminels ont utilisé des identifiants compromis pour atteindre un portail Citrix qui « ne disposait pas d'authentification multifacteur », se sont déplacés latéralement, puis ont exfiltré des données entre le 17 et le 20 février. Le rançongiciel s'est déclenché le 21 février, neuf jours après l'intrusion. Plusieurs médias ont incriminé CitrixBleed ; aucune source primaire ne l'étaye. Interrogé sur l'absence de MFA sur un serveur exposé sur internet, UnitedHealth a répondu au Sénat que « le serveur en cause était un ancien serveur Change Healthcare, et notre équipe travaillait à le mettre en conformité avec les exigences d'UHG ». Le rachat avait été finalisé seize mois plus tôt. Le formulaire 8-K (point 1.05) a été déposé le lendemain de la détection ; les courriers individuels aux personnes concernées n'ont commencé que fin juillet 2024, environ cinq mois après le départ des données.

Un canal existait, et il n'aurait servi à rien. La politique de signalement des vulnérabilités d'UnitedHealth, en ligne depuis 2019 au moins, n'offrait aucune prime, aucune sphère de sécurité (Safe Harbor) et aucun SLA de réponse. Elle interdisait « l'analyse ou les tests actifs de vulnérabilités », écartait « la violation des bonnes pratiques » et précisait que l'entreprise « ne divulguera, ne discutera ni ne confirmera aucun problème de sécurité ». Une passerelle exposée sur internet sans MFA, c'est précisément ce qu'un chercheur ne repère qu'avec une analyse active, et précisément ce qu'un chargé de triage peut classer sans suite comme simple manquement aux bonnes pratiques.

## Salesloft Drift : la fuite qu'un programme de divulgation n'aurait pas pu détecter

Ce cas figure ici parce qu'il joue contre la thèse défendue.

Entre mars et juin 2025, un acteur suivi sous le nom d'UNC6395 a gardé le contrôle du compte GitHub de Salesloft, puis a rebondi vers l'environnement AWS de Drift, où étaient stockés les jetons OAuth des clients, et s'est servi de ces jetons légitimes pour atteindre les instances Salesforce de ces mêmes clients. Le Google Threat Intelligence Group précise que le problème « ne provient pas d'une vulnérabilité de la plateforme Salesforce elle-même ». Salesloft n'a jamais expliqué comment le compte GitHub avait été pris.

La MFA et la surveillance des connexions ont été contournées par construction : l'application était autorisée et les jetons étaient authentiques. Ce que l'acteur cherchait, c'étaient les identifiants collés dans les tickets de support. Cloudflare a retrouvé 104 jetons d'API Cloudflare actifs dans le texte de ses propres dossiers exfiltrés et les a tous renouvelés ; l'ensemble du corpus était parti en 3 minutes et 22 secondes. Environ cinq mois se sont écoulés entre le premier accès à GitHub et la divulgation du 20 août 2025, mais deux jours seulement entre la fin de l'exfiltration observée et la révocation des jetons.

**Un VDP n'aurait rien détecté ici.** Le détournement d'un compte GitHub et un coffre à jetons centralisé au sein du parc AWS d'un éditeur ne sont pas observables de l'extérieur, et les faiblesses connexes relèvent de choix d'architecture que la plupart des périmètres de VDP excluent.

À comparer avec une faille taillée pour un VDP, dans le même écosystème, au même trimestre. Noma Security a découvert ForcedLeak (CVSS 9,4) dans Salesforce Agentforce : un domaine expiré toujours présent dans une liste d'autorisation CSP, et rachetable pour environ 5 $. Signalée le 28 juillet 2025, avec accusé de réception le 31 juillet, corrigée le 8 septembre, divulguée le 25 septembre. Trouvée de l'extérieur, signalée, corrigée, publiée.

## Free Mobile : 42 millions d'euros d'amende, et quatre millions de victimes qui avaient déjà résilié

Les délibérations de la CNIL de janvier 2026 chiffrent l'ampleur confirmée à **24 633 469 contrats** : 19 460 891 mobiles et 5 172 577 fixes, avec noms, adresses, dates de naissance et IBAN pour les clients détenant les deux services ([CNIL](https://www.cnil.fr/en/sanction-free-2026), 2026). L'attaquant a atteint l'outil de gestion des abonnés via le VPN de Free Mobile, dont la CNIL a jugé l'authentification « pas suffisamment robuste », relevant l'absence d'authentification des postes et de MFA pour les utilisateurs. Deuxième manquement retenu : l'entreprise n'avait pas déployé de moyens suffisants pour détecter les activités suspectes sur ce VPN, sur son réseau interne ou sur l'outil de gestion des abonnés. Conserver des journaux n'est pas une mesure de sécurité.

Le troisième manquement est celui que les fondateurs sous-estiment. Free Mobile a par ailleurs enfreint l'article 5-1-e en gardant plus de quinze millions de contrats résiliés au-delà de cinq ans, et trois millions au-delà de dix. Le calcul parle de lui-même : 19,46 millions de contrats mobiles exposés, pour environ 15,51 millions d'abonnés mobiles actifs au 31 décembre 2024. Les contrats touchés dépassaient donc d'environ quatre millions le nombre de clients en portefeuille. La politique de conservation était bel et bien une mesure de sécurité, et son absence a élargi le périmètre d'exposition de plusieurs millions de personnes.

L'accès a duré du 28 septembre au 22 octobre 2024, et la CNIL note que l'entreprise a été alertée le 21 octobre par un attaquant entré dans ses systèmes. Free a notifié la CNIL dans le délai de 72 heures et a tout de même été sanctionné au titre de l'article 34 : la CNIL a estimé que l'e-mail d'information ne permettait pas de rassurer les millions de personnes concernées. Amendes : 27 millions d'euros pour FREE MOBILE, 15 millions d'euros pour FREE.

`free.fr` publie aujourd'hui un `security.txt` signé PGP, vérifié le 12 août 2026 : URL canonique, deux contacts, une date `Expires`, une empreinte OpenPGP. Il n'a pas de ligne `Policy:`, donc ni périmètre ni sphère de sécurité. Une adresse de contact n'est pas un programme : l'intrus, lui, est allé sur un forum criminel plutôt que de l'utiliser.

## Tea : c'est 4chan qui a trouvé, et le correctif est venu après la publication

Tea Dating Advice a confirmé que 72 000 images avaient été consultées, dont 13 000 selfies de vérification et photos de pièces d'identité ([NBC News](https://www.nbcnews.com/tech/social-media/tea-app-hacked-13000-photos-leaked-4chan-call-action-rcna221139), 2025), le reste provenant de publications, de commentaires et de messages, les seules personnes touchées étant les utilisateurs inscrits avant février 2024 ([TechCrunch](https://techcrunch.com/2025/07/26/dating-safety-app-tea-breached-exposing-72000-user-images), 2025). Sa notification au procureur général de Californie est plus circonscrite : un accès non autorisé, aux alentours du 24 juillet 2025, à un espace de stockage contenant les pièces de vérification, avec des indices d'accès à « la plupart, voire la totalité » d'entre elles, exposant noms, dates de naissance, numéros de permis de conduire et de passeport.

La cause profonde tient dans la phrase que 404 Media a reprise du message 4chan à l'origine de l'affaire : « Aucune authentification, rien du tout. C'est un espace de stockage public. » Pas d'identifiant, pas de chaîne d'exploitation, rien qu'une URL. Puis une seconde faille : une base Firestore de messages privés, lisible par n'importe quel utilisateur authentifié de Tea. 404 Media a fait état de plus de 1,1 million de messages, vérifiés sur un échantillon ; Tea n'a jamais confirmé de chiffre, se bornant à dire que des messages avaient été consultés.

Deux failles, deux canaux, et jamais l'entreprise. La première est partie sur 4chan un jeudi soir ; l'information des consommateurs a suivi le 28 août 2025, soit 35 jours d'écart au registre californien. La seconde est passée par un journaliste : le chercheur indépendant Kasra Rahjerdi a découvert la base de messages, a choisi de ne pas la publier et l'a fait remonter via 404 Media jusqu'à Tea, parce que c'était le canal qui fonctionnait. Tea a désactivé les messages privés deux jours plus tard, après la publication. Aucune action répressive d'un régulateur n'est apparue publiquement ; rien ne permet pour autant d'en conclure qu'aucune enquête n'a été ouverte.

## Les cinq cas côte à côte

| Fuite | Ampleur confirmée | Qui les a prévenus en premier | Canal de signalement (vérifié le 12 août 2026) |
|---|---|---|---|
| **MyDr** (PL, août 2026) | Aucune ; les attaquants revendiquent 18 814 422 numéros PESEL | Les attaquants, puis des journalistes | Pas de `security.txt` ; un fichier de 44 octets non conforme sur une marque sœur |
| **Change Healthcare** (US, février 2024) | ≈ 190 millions (10-K) ; 192,7 millions sur le portail du HHS | Personne à l'extérieur ; le rançongiciel a fait office d'alarme | La politique de la maison mère interdisait l'analyse active ; le site renvoie une 404 |
| **Salesloft Drift** (SaaS, août 2025) | Non publiée | Inconnu ; aucune source publique ne nomme un premier détecteur | 404, meta-refresh, soft-404 ; aucun programme public |
| **Free / Free Mobile** (FR, octobre 2024) | 24 633 469 contrats (CNIL) | L'attaquant, au 23ᵉ jour d'une intrusion de 24 jours | `security.txt` signé PGP, sans ligne `Policy:` |
| **Tea** (US, juillet 2025) | 72 000 images, dont 13 000 pièces d'identité et selfies | 4chan, puis un journaliste | 404 sur les deux domaines |

## Ce que les cinq ont en commun

**Un seul éditeur, des milliers de périmètres d'exposition (3 cas sur 5).** MyDr est sous-traitant pour des milliers de cabinets, Change Healthcare une chambre de compensation pour une large part des remboursements de santé américains, Drift une application logée dans les environnements Salesforce de centaines d'autres entreprises. Dans les trois cas, la partie compromise n'était pas celle dont les clients ont été lésés. Un compte à rebours de 72 heures au titre de l'article 33 court désormais pour des milliers de petits cabinets polonais qui n'ont aucune visibilité technique sur ce qui s'est passé.

**Des données gardées bien après avoir cessé d'être utiles (3 cas sur 5).** Free est le cas établi par le régulateur. Tea est celui de l'écart entre la promesse et la pratique : sa politique de confidentialité affirmait que les selfies de vérification étaient supprimés immédiatement après usage, et 13 000 dormaient dans un espace de stockage public. MyDr est le cas prudemment formulé. « Très probablement historiques, de 2024 et des années antérieures » se veut rassurant ; lu comme une déclaration sur la conservation, cela signifie que des dossiers anciens restaient accessibles depuis la production.

**La victime a été prévenue, mais jamais par un découvreur (4 cas sur 5).** MyDr : les attaquants ont écrit au PDG. Free : l'intrus a mis fin à vingt-trois jours de silence. Tea : 4chan, puis un journaliste. Change Healthcare : le chiffrement lui-même. Salesloft : inconnu, et cette lacune doit rester une lacune. Les chiffres de Mandiant le confirment : on tient là la règle générale, et la malchance n'y est pour rien.

**Les identifiants qu'on ne peut pas renouveler (3 cas sur 5).** Un mot de passe, une clé d'API ou un jeton OAuth se renouvellent, et Cloudflare en a renouvelé 104 en une semaine. Un numéro PESEL, un IBAN, un numéro de passeport ou une date de naissance, non. Aujourd'hui, les recommandations officielles polonaises se résument à bloquer son numéro PESEL dans l'application mObywatel et à attendre le courrier de son cabinet médical. Chaque année de conservation supplémentaire est une année de plus pendant laquelle des identifiants impossibles à renouveler attendent dans un système que quelqu'un finira par atteindre.

**L'actif hérité (2 cas sur 5).** UnitedHealth a finalisé le rachat de Change Healthcare en octobre 2022, et la passerelle non durcie figurait encore sur la liste des migrations en février 2024. MyDr a été racheté en janvier 2023, et le seul fichier RFC 9116 du groupe se trouve sur une autre marque, avec une autre adresse de contact. L'intégration des sociétés et l'intégration des surfaces de sécurité sont deux chantiers distincts, et c'est en général le second qui passe à la trappe.

**Il n'y avait nulle part où envoyer un signalement (5 cas sur 5).** C'est le seul trait commun aux cinq, et deux d'entre eux montrent pourquoi publier une page n'est pas la ligne d'arrivée. Change Healthcare prouve qu'un canal ne suffit pas : une politique qui interdit l'analyse active et écarte les constats de simple manquement aux bonnes pratiques élimine précisément la catégorie de rapport qui comptait. Salesloft prouve qu'un canal n'est pas toujours pertinent.

Ce qu'un canal apporte réellement, Verizon le formule à propos des espaces de stockage exposés : ils « sont le plus souvent découverts par des chercheurs en sécurité, qui tentent ensuite de prévenir quelqu'un s'ils parviennent à déterminer à qui appartiennent les données. Ce que nous ignorons, c'est combien de fois d'autres personnes, moins soucieuses de l'intérêt général, sont tombées sur les mêmes données, en ont fait une copie et se sont éclipsées sans bruit » ([Verizon 2026 DBIR](https://www.verizon.com/business/resources/T1ae/reports/2026-dbir-data-breach-investigations-report.pdf), 2026). L'espace de stockage de Tea, c'est ce paragraphe incarné.

Sans canal, les options qui restent au découvreur lui font courir un vrai risque. Des étudiants et un enseignant maltais qui avaient écrit à une entreprise en octobre 2022 au sujet de vulnérabilités ont vu débarquer la police armée trois semaines plus tard, et n'ont été graciés qu'en juillet 2025. Si votre seule porte d'entrée est une boîte de support et un service juridique, vous avez bel et bien publié une politique, et c'est la mauvaise. Nous développons ce point dans [la sphère de sécurité et les menaces juridiques contre les chercheurs en sécurité](/blog/safe-harbor-legal-threats-security-researchers-vdp).

## Là où un programme de divulgation est déjà obligatoire, et là où il ne l'est pas

Soyons précis, car la plupart des articles ne le sont pas.

**Cyber Resilience Act européen (règlement 2024/2847).** L'annexe I, partie II, point 5 impose aux fabricants de produits comportant des éléments numériques de « mettre en place et faire appliquer une politique de divulgation coordonnée des vulnérabilités ». Notez le verbe : une page publiée ne suffit pas. Les délais de l'article 14 (alerte précoce sous 24 heures, notification sous 72 heures, rapport final sous 14 jours pour les vulnérabilités activement exploitées) s'appliquent à partir du 11 septembre 2026, et le règlement s'applique intégralement à partir du 11 décembre 2027. Il lie les fabricants qui mettent des produits sur le marché de l'UE : une entreprise purement SaaS reste donc généralement hors périmètre. Notre [décryptage des obligations de divulgation du CRA](/blog/eu-cyber-resilience-act-mandatory-vulnerability-disclosure) entre dans le détail.

**NIS2 (directive 2022/2555).** L'article 12 lie les États membres et l'ENISA, pas les entreprises prises individuellement. En Pologne, la révision de la loi KSC qui la transpose est entrée en vigueur le 3 avril 2026, soit environ dix-sept mois après l'échéance européenne, avec une inscription à effectuer d'ici au 3 octobre 2026. L'incident MyDr tombe dans cette fenêtre, avant que les obligations de conformité et le régime de sanctions ne deviennent contraignants.

**PSTI britannique (SI 2023/1007).** Applicable depuis le 29 avril 2024 aux produits connectables. L'annexe 1 exige un contact publié, assorti d'une indication du délai sous lequel l'auteur d'un signalement reçoit un accusé de réception et des mises à jour, le tout accessible sans démarche préalable, gratuitement et sans exiger ses données personnelles. Cette dernière clause exclut les formulaires sous condition d'accès et les pages de contact derrière une authentification.

**CISA BOD 20-01.** Obligatoire pour les agences civiles fédérales américaines depuis 2020 : une politique au chemin fixe `/vulnerability-disclosure-policy`, avec périmètre annoncé, tests autorisés et mention explicite que les signalements peuvent être anonymes. La plateforme VDP de la CISA a recensé, en cumulé jusqu'à fin 2023, plus de 12 000 signalements reçus sur 51 programmes d'agences, dont plus de 2 400 divulgations valides.

**Ce qui n'est pas obligatoire.** NIS2 n'oblige pas les entreprises à mener un VDP, et PCI DSS 4.0 non plus ; les recommandations du PCI SSC indiquent que les programmes de divulgation « peuvent aider » à satisfaire les exigences 6.3.3 et 12.10.1. Dans la commande publique fédérale américaine, aucune obligation FAR n'existe. Le véhicule législatif, H.R. 872, a été adopté par la Chambre des représentants le 3 mars 2025 et n'est toujours pas promulgué au 12 août 2026.

L'économie, elle, n'attend pas la loi. IBM chiffre le coût moyen mondial d'une fuite de données à un record de 4,99 millions de dollars en 2026, en hausse de 12 % ([IBM Cost of a Data Breach 2026](https://www.ibm.com/reports/data-breach)). HackerOne a versé 81 millions de dollars de primes sur 1 950 programmes pour l'année close au 30 juin 2025, mais les 100 premiers programmes en ont capté 51 millions : il reste environ 16 000 $ par an pour un programme ordinaire. Un programme sans prime coûte moins encore. Et presque personne ne publie de contact : une étude évaluée par les pairs, menée sur le classement Tranco, trouvait un `security.txt` sur 34,0 % des 100 premiers domaines, mais sur 1,0 % seulement du premier million lors d'un relevé de janvier 2023 (Hilbig et al., ACM DTRAP). En janvier 2025, un relevé n'en trouvait encore que sur 1,25 % du premier million, dont 44 % de fichiers conformes à la RFC (URIports, 2025).

## Ce qu'il faut publier cette semaine

Rien de tout cela n'exige un budget de primes ni un contrat de plateforme. Le minimum qui, dans les cinq cas, aurait donné au découvreur un endroit où signaler ce qu'il avait trouvé :

1. **Un `security.txt` conforme à la RFC 9116**, avec un `Contact:` qui fonctionne, une date `Expires:` et une ligne `Policy:`. `Expires` est obligatoire, et ce sont ces détails-là qui font que la plupart des fichiers publiés ne sont pas conformes.
2. **Une page de politique** énonçant le périmètre, les tests autorisés et la sphère de sécurité, en langage clair. La maison mère de Change Healthcare interdisait l'analyse active dont un découvreur aurait eu besoin ; Free a une adresse de contact et aucune politique.
3. **Un engagement d'accusé de réception.** Bonne pratique, pas obligation légale : annoncez sous quel délai vous confirmerez la réception, et tenez cet engagement.
4. **Un responsable nommé et une file.** Les rapports qui atterrissent dans une boîte partagée sont triés par la personne la moins occupée, c'est-à-dire par personne.
5. **Une chronologie exportable.** Quand un régulateur ou un journaliste demande ce que vous saviez et à quel moment, « nous avons traité l'affaire de façon responsable » ne prouve rien ; une chronologie pour chaque rapport, elle, fait foi.

La version pas à pas : [comment mettre en place un programme de divulgation des vulnérabilités](/blog/how-to-set-up-vulnerability-disclosure-program).

## Gérer la réception sans avoir à la construire

Publier un contact prend un après-midi. C'est la gestion de ce qui arrive ensuite qui déraille en silence, car une file de divulgation se comporte comme toutes les autres : elle s'engorge, le temps court, et c'est quelqu'un de l'extérieur qui s'en aperçoit le premier.

Le module CSIRT de Kit est la couche opérationnelle qui répond à cela, rien de plus. Il génère le `security.txt` et héberge un portail de signalement public qui affiche votre périmètre juste à côté du formulaire : les cibles couvertes et celles qui ne le sont pas sont énoncées plutôt que sous-entendues. Les rapports entrants sont vérifiés au regard de ce périmètre, dédoublonnés, puis placés sous un compte à rebours de SLA, avec des objectifs d'accusé de réception et de résolution par niveau de gravité, ainsi qu'un suivi des rapports à risque : un engagement en passe d'être manqué remonte avant que le chercheur n'aille en parler ailleurs. Les chercheurs disposent de profils persistants et d'un karma, si bien qu'un habitué des rapports probants ne reste pas coincé derrière le bruit. Les primes sont facultatives : la grille des primes par niveau de gravité, le vote des propositions, le grand livre et la remise du versement sont là si vous payez, en sommeil sinon. Chaque rapport porte une chronologie exportable.

Les limites comptent autant que les fonctionnalités. Kit n'aurait empêché aucune de ces cinq fuites. Ce n'est ni de l'EDR, ni de la segmentation, ni de la MFA, et il n'aurait pas révélé la prise de contrôle du compte GitHub de Salesloft. Kit ne dépose rien sur la plateforme de l'ENISA et n'effectue pas vos notifications au titre des articles 33 et 34 ; ce n'est pas non plus un conseil juridique. La promesse honnête est plus étroite : dans quatre de ces cinq cas, la première personne au courant n'était pas l'entreprise, et un canal publié change qui l'apprend en premier.

<div class="blog-inline-cta">
  <p><strong>Publiez un contact et une politique cette semaine.</strong> Le module CSIRT de Kit vous donne un portail de signalement public, un <code>security.txt</code> généré, la validation du périmètre, le suivi des SLA et une chronologie exportable pour chaque rapport.</p>
  <p><a href="/users/sign_up">Démarrez votre essai gratuit</a></p>
</div>

Cinq entreprises, trois continents, cinq causes profondes différentes. Leur seul point commun : une personne extérieure qui voulait leur dire quelque chose n'avait aucun moyen prévu de le faire. Ce n'est ni un retard de maturité ni un problème de budget. C'est une interface manquante, et c'est la moins chère de votre feuille de route.