Safe Harbor ou procès ? La clause de VDP qui vous protège

Le Safe Harbor d’un programme de divulgation des vulnérabilités, c’est un engagement écrit, formulé sans ambiguïté, par lequel votre organisation promet de ne pas engager de poursuites contre les chercheur·euses en sécurité qui signalent des vulnérabilités de bonne foi. Il transforme des attentes floues sur ce qui serait un comportement « responsable » en un véritable contrat : restez dans le périmètre, n’exfiltrez aucune donnée, ne perturbez pas le service, signalez par le canal officiel, et vous êtes autorisé·e à tester. Sans lui, des lois anti-piratage vieilles de plusieurs décennies laissent même les chercheur·euses les plus éthiques exposé·es, et celui ou celle qui a trouvé votre faille a toutes les raisons de se taire ou de la revendre.

En mai 2026, Microsoft a montré à tout le secteur ce qui se passe quand cette clause est absente ou ignorée. L’affaire est un cas d’école presque parfait : une politique ambiguë, plus une menace juridique réflexe, et la confiance des chercheur·euses s’effondre du jour au lendemain. La bonne nouvelle pour les fondateur·rices : l’échec était organisationnel, pas technique. Autrement dit, une startup peut l’éviter dès le premier jour, avec la bonne politique et le bon processus.

Ce que Microsoft vient de faire (et de défaire aussitôt)

Microsoft a menacé un chercheur en sécurité d’une enquête pénale, a essuyé plusieurs jours de tollé public de la part de la communauté infosec, puis a publiquement fait marche arrière. Le tout s’est déroulé en l’espace d’un mois environ.

Dès le début avril 2026, un chercheur pseudonyme connu sous le nom de « Nightmare-Eclipse » a publié des codes d’exploitation de type proof-of-concept pour une série de zero-days Windows, sans aucune coordination préalable avec Microsoft. Le décompte était une cible mouvante : environ six failles fin mai (avec des noms comme BlueHammer, RedSun, UnDefend et YellowKey, un contournement critique de BitLocker référencé CVE-2026-45585), puis davantage à mesure que la querelle s’éternisait en juin. Microsoft a publié un billet de blog qualifiant la divulgation non coordonnée de « jamais justifiable ». Sa Digital Crimes Unit a déclaré qu’elle « continuerait d’engager des procédures contre ces acteurs et contre ceux qui facilitent leur activité criminelle, en coordination, au besoin, avec les forces de l’ordre du monde entier ».

La communauté y a lu une menace de poursuites pénales visant un chercheur. La réaction a été immédiate et brutale. Aux alentours du 1er au 2 juin 2026, Microsoft a rétropédalé, affirmant n’avoir « aucune intention d’engager d’action contre des personnes qui mènent ou publient leurs recherches en sécurité », avec cette réserve : elle travaillerait avec les forces de l’ordre lorsqu’une personne « enfreint la loi et se livre à une activité malveillante causant un préjudice réel à nos clients ».

Un détail est plus parlant que le revirement lui-même. En pleine crise, Microsoft a discrètement remplacé l’expression « divulgation responsable » par « divulgation coordonnée des vulnérabilités » dans sa communication. Ce changement de mot, sur lequel nous reviendrons, en disait long.

Pourquoi c’est la première cause de rupture de confiance dans la divulgation

Le dommage, ici, n’a pas été causé par un exploit ingénieux. Il a été causé par l’ambiguïté. Quand une politique ne dit pas noir sur blanc que les chercheur·euses de bonne foi ne risquent rien, chaque rapport devient un pari, et c’est l’humeur de l’éditeur, un jour donné, qui décide si un inconnu serviable est un partenaire ou un accusé.

La contradiction a aggravé les choses. Kevin Beaumont, chercheur en sécurité et ancien employé de Microsoft, a qualifié l’épisode de « fiasco intégral qu’ils se sont infligé eux-mêmes », rappelant que Microsoft avait par le passé embauché SandboxEscaper, une chercheuse qui avait publié du code proof-of-concept de zero-day Windows, exactement le comportement que le billet de blog de l’entreprise présentait désormais comme criminel. Une application incohérente des règles est impossible à distinguer de l’absence totale de règles. Si les chercheur·euses ne peuvent pas prévoir votre réaction, ils et elles supposent le pire.

Katie Moussouris, qui a conçu le programme de bug bounty original de Microsoft et dirige aujourd’hui Luta Security, a mis en garde contre « un effet dissuasif, avec moins de gens qui se manifestent pour signaler des failles, ce qui nous rend tous moins en sécurité ». C’est là toute la leçon. Une menace liée à la divulgation ne punit pas qu’un seul chercheur. Elle apprend aux cent suivants à se taire.

Ce que « Safe Harbor » veut vraiment dire

Le Safe Harbor, c’est la clause qui supprime le pari. C’est une promesse écrite, publiée dans votre politique : les chercheur·euses qui agissent de bonne foi ne seront ni poursuivis ni dénoncés au parquet.

Pour bénéficier de cette protection, les chercheur·euses doivent en général remplir une courte liste de conditions :

1. Agir de bonne foi, avec l’intention d’améliorer la sécurité, pas d’extorquer ni de nuire.
2. Rester dans le périmètre défini des actifs que vous avez autorisés au test.
3. Éviter toute atteinte à la vie privée et toute exfiltration de données, en n’accédant qu’au strict minimum nécessaire pour prouver une faille.
4. Éviter toute interruption de service, sans déni de service ni test destructif.
5. Signaler par le canal officiel et laisser un délai raisonnable pour corriger avant toute divulgation publique.

Ce n’est pas une théorie juridique marginale. Le cadre safe-harbor de disclose.io, un standard open source, a été adopté en 2020 par la CISA, des fabricants de machines à voter et plusieurs États américains, et il est livré par défaut avec les programmes Bugcrowd. HackerOne maintient un « Gold Standard Safe Harbor ». Dropbox, Mozilla et les programmes de l’ère GitHub en utilisent tous des variantes. Le Safe Harbor est désormais la norme de référence — et c’est précisément pour cela que son absence est un signal d’alarme pour les personnes dont vous voulez le plus qu’elles vous fassent leurs rapports.

La loi protège-t-elle déjà les chercheur·euses ? En grande partie, non

Beaucoup de fondateur·rices supposent que, le ministère de la Justice américain (DOJ) ayant assoupli sa position sur le Computer Fraud and Abuse Act, les chercheur·euses sont désormais à l’abri et qu’une clause sur mesure est superflue. Cette hypothèse est fausse sur deux points importants.

Le 19 mai 2022, le DOJ a révisé sa politique de poursuites au titre du CFAA pour indiquer qu’il n’engagerait pas de procédure contre la recherche en sécurité menée de bonne foi. C’était un réel progrès. Mais le DOJ lui-même a été explicite : ce changement n’affecte pas la responsabilité civile et ne lie pas les lois pénales des États en matière de criminalité informatique. Comme l’a souligné le cabinet Wilson Sonsini dans son analyse, des questions et une possible responsabilité civile subsistent pour les chercheur·euses.

Traduisons cela en termes clairs. Une entreprise peut toujours poursuivre un·e chercheur·euse au civil. Un procureur d’État, agissant sous le régime d’une loi étatique sur le piratage, peut toujours engager des poursuites. Le bouclier pénal fédéral est étroit, et il ne vous appartient pas de l’élargir. Le seul instrument qui comble ces lacunes pour les personnes qui testent vos systèmes, c’est la formulation du Safe Harbor dans votre propre politique. La loi fixe un plancher ; c’est votre politique qui rend l’invitation réelle.

Divulgation « responsable » contre « coordonnée » : les mots comptent

La terminologie que vous choisissez indique si vous voyez les chercheur·euses comme des collaborateur·rices ou comme des suspects, et le secteur s’est délibérément éloigné du terme connoté.

« Divulgation responsable » est chargé de valeurs. Cela sous-entend, en filigrane, que quiconque ne suit pas le calendrier préféré de l’éditeur est irresponsable, faisant peser tout le fardeau moral sur la personne qui signale, et aucun sur l’éditeur qui a laissé traîner le correctif. Le CERT/CC et la majeure partie de la communauté de sécurité parlent désormais de divulgation coordonnée des vulnérabilités (CVD), qui décrit le processus sans jugement moralisateur. Ce terme présente la divulgation comme un problème de coordination à double sens — ce qu’elle est réellement.

Ce n’est pas un débat sémantique d’universitaires. Rappelez-vous : Microsoft elle-même est passée de « responsable » à « coordonnée » en pleine crise. Moussouris avait pointé la formulation d’origine comme « le premier faux pas ». Quand l’entreprise au cœur de la tempête change de vocabulaire sous la pression, cela vous indique quel mot écoutent les personnes qui signalent des failles. Employez « coordonnée » dans votre politique. Cela ne coûte rien et cela témoigne du respect.

Le coût de l’absence de VDP : le silence ou le marché gris

Quand les chercheur·euses ne peuvent pas signaler en toute sécurité, la vulnérabilité ne disparaît pas pour autant. Vous n’en entendez tout simplement pas parler jusqu’à ce qu’elle soit transformée en arme, parce que la personne qui l’a trouvée s’est tue ou a déniché un acheteur plus généreux.

L’ampleur de l’écart est considérable. Selon le propre décompte de HackerOne, 93 % des entreprises du Forbes Global 2000 n’ont aucun moyen publié pour qu’un·e chercheur·euse signale un problème de sécurité. C’est un constat de HackerOne, et non un recensement indépendant, mais la tendance ne prête pas à débat : la plupart des organisations n’ont pas de porte d’entrée.

Le marché alternatif obéit à une économie brutale. Les prix des exploits sur le marché gris écrasent toute prime d’éditeur. Des courtiers comme Crowdfense ont affiché jusqu’à environ 9 millions de dollars pour une chaîne d’exploitation mobile zero-click complète ; les exploits de navigateur se négocient entre 3 et 3,5 millions de dollars ; Zerodium a affiché jusqu’à 2 millions de dollars pour une chaîne d’exécution de code à distance sur Android. Vous ne rivalisez pas avec ces prix, et vous n’avez pas à le faire. Il vous suffit de rendre le signalement coordonné suffisamment sûr et sans friction pour qu’un·e chercheur·euse choisisse la voie légale. Une lettre de menace le pousse dans l’autre direction.

Les cinq ingrédients d’une politique qui protège les deux camps

Une politique de divulgation qui fonctionne est courte et concrète. Elle comporte cinq parties, et un·e chercheur·euse devrait pouvoir la lire en deux minutes et savoir exactement ce qui est permis.

Côté calendrier, alignez-vous sur des normes établies pour qu’aucun camp ne parte de zéro dans la négociation. La fenêtre de divulgation de facto standard dans le secteur tourne autour de 90 jours ; le CERT/CC retient par défaut environ 45 jours ; Google Project Zero applique un délai de 7 jours pour les failles activement exploitées. Un SLA d’accusé de réception de 24 à 48 heures est une pratique courante, et c’est le signal de confiance le moins coûteux que vous puissiez offrir. Le grief central du chercheur Nightmare-Eclipse portait sur des mauvais traitements — un compte révoqué, une prime retenue, une attribution effacée — et non sur l’absence de paiement. Réussissez les signaux de confiance, et la plupart des litiges ne démarrent jamais.

Comment en monter un dès le premier jour, sans la lourdeur de l’entreprise

Si la plupart des startups font l’impasse sur un VDP, ce n’est pas par désaccord avec ce qui précède. C’est parce que les ressources existantes sont soit un standard abstrait, soit un modèle juridique, sans aucun programme opérationnel rattaché. L’OWASP vous donne la théorie. disclose.io vous donne la clause. Ni l’un ni l’autre ne vous donne le triage, les SLA, ni un endroit où les chercheur·euses peuvent réellement déposer un rapport et en suivre l’avancement.

C’est exactement la lacune que comble le module de sécurité de Kit. Au lieu de bricoler un document de politique, un formulaire de contact et un tableur, vous configurez un seul programme qui correspond directement aux cinq ingrédients ci-dessus :

• Le Safe Harbor et le périmètre font partie de la configuration du programme : la formulation de l’autorisation et la liste des actifs dans le périmètre vivent dans la politique que lit le chercheur, et non dans la mémoire d’un·e fondateur·rice.
• Un parcours de configuration guidé mène un nouveau compte de zéro à un programme actif, pour que la question « par où commencer ? » ne devienne jamais une impasse.
• Un workflow standardisé de divulgation coordonnée gère le triage, l’évaluation de la sévérité et la détection des doublons de la même façon pour chaque personne — c’est précisément la cohérence qui a manqué à Microsoft.
• Des signaux de confiance tournés vers les chercheur·euses sont intégrés : messagerie dans le programme, statut de triage transparent, karma des chercheur·euses, et un historique de primes et un registre irréprochables, pour que personne ne se sente ignoré ni floué.
• Des SLA fermes et des échéances visibles maintiennent une réponse rapide et auditable, éliminant le schéma lent-et-silencieux qui pousse les chercheur·euses vers la divulgation publique.

Une mise en garde honnête, car l’objet même de cet article n’est pas de survendre. Kit vous fournit l’échafaudage opérationnel et le bon endroit où placer la formulation du Safe Harbor. Ce n’est pas un conseil juridique. Faites relire le texte final de votre politique par un·e juriste avant de le publier, en particulier la formulation de l’autorisation et du périmètre. Le dire à voix haute est en soi un signal de confiance, et cela rejoint la thèse : la clarté l’emporte sur l’ambiguïté à tous les coups.

Si vous voulez entrer dans les rouages, notre guide sur comment mettre en place un programme de divulgation des vulnérabilités couvre la tuyauterie de réception, et quand les chercheur·euses rendent tout public explique pourquoi c’est la lenteur de traitement, et non l’hostilité, qui produit les publications de zero-days. Si vous distribuez vers l’UE, l’échéance de divulgation du Cyber Resilience Act fait d’une politique de CVD une obligation légale, pas seulement une bonne pratique.

La checklist du jour un pour fondateur·rices

Vous n’avez pas besoin d’une équipe de sécurité pour faire cela. Il vous faut un après-midi. Voici le minimum :

1. Publiez une clause Safe Harbor indiquant que vous n’engagerez pas de poursuites contre les chercheur·euses de bonne foi qui restent dans le périmètre. Inspirez-vous de disclose.io et faites-la relire par un·e juriste.
2. Définissez votre périmètre explicitement : quels domaines et actifs sont concernés par les tests, et ce qui est interdit (pas d’exfiltration de données, pas de DoS, pas d’ingénierie sociale, pas de services tiers).
3. Ouvrez un seul canal de signalement et faites-en la publicité via un fichier security.txt à /.well-known/security.txt.
4. Engagez-vous sur un SLA de réponse : accusé de réception sous 48 heures, et un calendrier réaliste de correction et de divulgation.
5. Employez « coordonnée », pas « responsable », partout pour la divulgation, et promettez une attribution à quiconque la souhaite.

L’erreur de Microsoft a été de dégainer une menace juridique là où il aurait fallu dégainer une politique claire. Une startup a l’avantage de pouvoir construire la politique d’abord, avant le premier chercheur en colère, avant le premier rapport mal aiguillé dans support@, avant que le décompte des failles non corrigées ne se mette à grimper en public. Inscrivez dès maintenant le Safe Harbor, le périmètre, les SLA et les signaux de confiance dans votre programme de divulgation, et vous n’aurez jamais à rédiger le billet d’excuses plus tard.

Montez un VDP sûr pour les chercheur·euses cet après-midi, pas le trimestre prochain. Démarrez gratuitement avec Kit et configurez votre programme de divulgation au même endroit.