Jusqu'où vérifier les chercheurs en bug bounty ?

La vérification des chercheurs en bug bounty est un curseur, pas un interrupteur. Vous ajustez ce que vous vérifiez sur un chercheur à la sensibilité de ce qu’il peut atteindre, selon quatre niveaux : accueil sur simple inscription (n’importe qui peut signaler, aucune identité requise), paiements après vérification d’identité (signalement sous pseudonyme, mais contrôles d’identité, fiscaux et de sanctions avant tout mouvement d’argent), accès privé conditionné par la confiance (invitations gagnées à la réputation et vérification d’identité obligatoire) et contrôle d’antécédents ou contractualisation (enquête sur les antécédents judiciaires et testeurs nommés et contractualisés pour vos actifs les plus stratégiques). L’erreur des fondateurs, c’est d’accepter le réglage par défaut d’une place de marché au lieu de choisir le cran que leur modèle de menace exige réellement.

Vous êtes sur le point d’inviter des inconnus à sonder votre production. La question qui sous-tend tout programme de divulgation des vulnérabilités (VDP) est simple et dérangeante : qui, exactement, suis-je en train de laisser entrer, et que dois-je savoir de lui d’abord ? Voici la réponse, niveau par niveau.

Ce que « vérifier un chercheur » veut vraiment dire

La vérification n’est pas une seule chose. Ce sont trois contrôles distincts et cumulables que les fondateurs confondent en permanence, et que les grandes plateformes activent chacun de façon indépendante.

• Vérification d’identité (IDV / KYC). Confirmer qu’un être humain réel et vérifiable auprès des autorités se cache derrière le pseudonyme, généralement une pièce d’identité avec photo et un selfie de détection du vivant.
• KYC de paiement et fiscal. Le formulaire fiscal, le moyen de paiement et le contrôle des sanctions que vous devez légalement effectuer avant de pouvoir envoyer de l’argent à quelqu’un.
• Contrôle des antécédents judiciaires. Une enquête formelle sur le casier, généralement avec un historique remontant sur plusieurs années.

La plupart des programmes publics n’utilisent que le contrôle du milieu. Vous pouvez laisser quelqu’un signaler une faille sous pseudonyme, puis exiger les documents d’identité et fiscaux uniquement lorsqu’un paiement est dû. Cette séparation — la participation d’un côté, l’argent de l’autre — est la charnière sur laquelle repose tout le modèle de confiance. Dès lors qu’on voit la vérification comme trois curseurs plutôt qu’un seul interrupteur, la répartition par niveaux découle naturellement.

Jusqu’où HackerOne et Bugcrowd vérifient-ils réellement ?

Les places de marché grand public vérifient délibérément peu par défaut, parce que tout leur argumentaire repose sur l’échelle. La communauté enregistrée de HackerOne dépasse largement le million de comptes, en grande partie sous pseudonyme, et l’argument économique du bug bounty ouvert, c’est le grand nombre d’yeux à faible friction.

Sur HackerOne, les chercheurs peuvent participer sous pseudonyme. Une identité légale n’est exigée que pour être payé : la vérification d’identité passe par Veriff, reste valable 12 mois et ne devient accessible qu’après qu’un chercheur a soumis au moins un rapport valide. Pour recevoir effectivement une récompense, un chercheur a aussi besoin d’un formulaire fiscal approuvé et d’un moyen de paiement. Les contrôles d’antécédents judiciaires sont optionnels et ne conditionnent que le niveau renforcé HackerOne Clear, réalisé par Checkr avec un historique de 7 ans, renouvelé tous les deux ans et réservé aux chercheurs qui franchissent des seuils de conduite et de réputation (dont 15 000 $ de primes cumulées). Une vingtaine de pays interdisent purement et simplement ce contrôle.

Bugcrowd a serré la vis d’un cran. La plateforme exige désormais une vérification d’identité — un selfie en direct et une pièce d’identité officielle — avant qu’un chercheur puisse soumettre à un programme Managed Bug Bounty, public ou privé. Les contrôles d’antécédents, en revanche, restent une option sur invitation réservée à un petit groupe de chercheurs de haute confiance. Les deux places de marché ne sont donc pas identiques : HackerOne privilégie le pseudonyme avec un KYC déclenché au paiement, tandis que Bugcrowd conditionne la participation elle-même à la vérification d’identité.

Toutes deux superposent ensuite un parcours de confiance. Les chercheurs de Bugcrowd débloquent les engagements publics, puis privés, puis restreints à mesure que leur réputation grandit. HackerOne construit la même idée à travers son programme Pentester, où les testeurs doivent être vérifiés Clear, justifier de plus de 3 ans d’expérience et de certifications de premier plan, passer un contrôle d’antécédents judiciaires et effectuer une période probatoire sur leurs trois premiers pentests. Même les plateformes « légères » construisent une échelle vers les missions à haute assurance.

L’extrémité lourde : la red team fermée et contractualisée de Synack

Synack se situe au pôle opposé et vérifie lourdement, en amont, avant que quiconque ne touche à un client. Elle exploite sa propre Synack Red Team (SRT) de plus de 1 500 chercheurs, et chaque membre franchit un processus de vérification en cinq étapes conçu pour évaluer à la fois la compétence et la fiabilité. Historiquement, moins de 10 % des candidats sont acceptés, et l’intégration s’étalerait, dit-on, sur plusieurs mois.

La différence déterminante n’est pas le taux d’acceptation. C’est que les membres de la SRT sont des profils sous contrat, pas des pseudonymes au hasard. Les membres américains sont rémunérés comme prestataires indépendants 1099 (les membres hors États-Unis via un formulaire W-8BEN), et gagnent leur revenu sur les missions, les soumissions valides, la vérification des correctifs et le mentorat. Synack surveille en continu le comportement en ligne de ses membres et les exclut lorsque cela se justifie. C’est cette foule fermée et vérifiée qu’achètent les administrations publiques et les entreprises fortement réglementées, et elle coûte cher précisément parce qu’une vérification aussi stricte réduit l’entonnoir à peau de chagrin.

Ce compromis est tout l’enjeu. Une vérification lourde est un impôt sur le vivier, la rapidité et le budget. Sur-vérifier un site vitrine public est un aussi mauvais réglage que sous-vérifier le cœur d’un système de paiement. C’est pourquoi la réponse n’est jamais « vérifiez au maximum », mais « vérifiez à la mesure du périmètre ».

L’échelle de vérification à quatre niveaux, et comment choisir le vôtre

Jusqu’où faut-il vérifier les chercheurs en bug bounty ? Ajustez la rigueur de la vérification à la sensibilité de ce qui est dans le périmètre, selon quatre niveaux : (1) accueil sur simple inscription, où n’importe qui peut signaler et aucune identité n’est requise, pour les actifs publics et peu sensibles ; (2) paiements après vérification d’identité, où le signalement est sous pseudonyme mais où le KYC d’identité, fiscal et de sanctions est exigé avant tout paiement — le réglage grand public par défaut ; (3) accès privé conditionné par la confiance, où la réputation vaut une invitation et où la vérification d’identité est obligatoire ; et (4) contrôle d’antécédents ou contractualisation, avec enquête judiciaire et testeurs nommés et contractualisés pour un périmètre stratégique, réglementé ou classifié.

Voici cette échelle sous forme de tableau de décision opérationnel.

Lisez le tableau par surface d’exposition, non par prestige. Posez une seule question par actif : si un acteur malveillant opérait à l’intérieur de ce périmètre, quelle serait la pire journée crédible ? Un rapporteur sous pseudonyme qui fouine dans votre site de documentation public est un problème de niveau 0. Un inconnu disposant d’un chemin vers le cœur de votre système de paiement en production, non — et aucune prime ne vaut de faire l’impasse sur l’identité à cet endroit.

Deux remarques pratiques. D’abord, la plupart des jeunes pousses font tourner plus d’un niveau à la fois : un vaste programme public de niveau 1 pour le périmètre externe, et une invitation de niveau 2 ou 3 pour tout ce qui approche les données sensibles. Ensuite, les niveaux sont une progression, pas une condamnation à perpétuité. Un chercheur qui signale bien au niveau 1 est exactement celui que vous faites monter dans votre vivier privé de niveau 2. La réputation, c’est la façon dont des inconnus de bonne foi gagnent leur place vers la confiance.

Ce que la vérification a à voir avec la légalité : la leçon Sullivan

C’est là que les fondateurs passent à côté de l’essentiel. La vérification n’est pas seulement un contrôle de sécurité ; c’est ce qui vous permet de prouver, après coup, qu’un acteur donné opérait à l’intérieur d’un périmètre autorisé. Et en 2026, cette preuve a un vrai poids juridique.

Dans l’affaire United States v. Sullivan, la Cour d’appel du neuvième circuit (arrêt rendu le 13 mars 2025) a confirmé la condamnation de l’ancien directeur de la sécurité d’Uber et a jugé que, sous le Computer Fraud and Abuse Act (CFAA), le caractère « non autorisé » de l’accès s’apprécie au moment de l’accès. Des documents produits après coup — dans cette affaire, un accord de confidentialité déguisé en bug bounty — ne peuvent pas blanchir rétroactivement un accès qui n’était pas autorisé au moment des faits. Les faits sous-jacents sont à eux seuls un avertissement : une violation en 2016 a exposé les données de 57 millions d’utilisateurs et 600 000 numéros de permis de conduire, avec un paiement de 100 000 $ acheminé via le programme de bug bounty, et Sullivan a finalement été condamné pour entrave et non-dénonciation d’un crime.

La leçon pour un responsable de programme est précise. L’autorisation doit être établie en amont, par écrit, et rattachée à une partie connue. Une vérification légère ne crée pas à elle seule une responsabilité au titre du CFAA, mais elle rend plus difficile de démontrer par la suite qu’un acteur précis se trouvait dans un périmètre autorisé et de bonne foi. Le libellé de sphère de sécurité (Safe Harbor) et le fait de savoir qui est votre chercheur sont les deux moitiés d’une même réponse à la question « cet accès était-il légitime ? ». C’est pourquoi votre document de périmètre, les conditions de sphère de sécurité et le niveau de vérification forment une seule décision, pas trois. (Pour le volet rédactionnel, voyez notre guide sur la sphère de sécurité et les menaces juridiques contre les chercheurs en sécurité, et l’analyse plus large de l’obligation de divulgation du Cyber Resilience Act européen si vous vendez en Europe.)

Rien de tout ceci ne constitue un avis juridique. Kit vous donne l’endroit où inscrire le libellé d’autorisation et de périmètre ; faites relire le texte final de votre politique par un conseil.

Vérifier un chercheur, c’est vérifier un prestataire sous un autre nom

Le modèle mental le plus limpide qu’un fondateur possède déjà, c’est celui du prestataire. Un chercheur externe disposant d’un chemin vers un accès en production est l’équivalent, côté sécurité, d’un prestataire que vous laissez entrer dans vos systèmes. Et vous graduez presque certainement déjà votre niveau d’exigence selon la sensibilité du rôle : un designer qui touche à un fichier Figma passe un contrôle plus léger qu’un ingénieur détenant des identifiants de production.

Appliquez la même logique graduée. Identité, réputation ou références, et contrôle d’antécédents ajustés à ce que la personne peut atteindre : cela se transpose presque à l’identique de votre politique de recrutement vers les niveaux de vérification des chercheurs. Traiter « qui peut toucher à la production » comme une décision de politique délibérée, plutôt que comme un détail secondaire, c’est toute la discipline. C’est aussi pourquoi la fraude à l’identité dans la chaîne d’approvisionnement en talents — comme la vague de fraude à l’embauche de faux informaticiens nord-coréens — relève de la même conversation : un faux prestataire et un « chercheur » sous pseudonyme visé par des sanctions sont un même échec de KYC portant des casquettes différentes.

Là où les programmes crypto rendent le levier de l’argent évident

Les programmes Web3 font ressortir le curseur du KYC de paiement de la manière la plus nette, parce que les paiements sont assez élevés pour que la question de l’argent domine tout. Immunefi n’exige pas de KYC par défaut ; chaque projet fixe sa propre politique. Lorsque le KYC est requis, il est collecté via Onfido seulement une fois qu’un rapport de faille est confirmé valide, juste avant un paiement qui peut atteindre six ou sept chiffres.

C’est tout le principe en une phrase : le KYC verrouille l’argent, pas la participation. Vous pouvez garder l’accueil grand ouvert et refuser malgré tout de faire bouger le moindre dollar tant que vous ne savez pas exactement qui le reçoit et que vous êtes légalement autorisé à le payer. Séparer « peut signaler » de « peut être payé », voilà le schéma de conception, que vos primes soient de 500 $ ou de 5 millions de dollars.

Mettre en place votre niveau sans la lourdeur d’une entreprise

Chaque acteur en place a intérêt à vous pousser vers son cran. Les places de marché vendent du léger-et-à-grande-échelle ; Synack vend du lourd-et-fermé. Personne de neutre ne publie un cadre piloté par le périmètre — « de combien de vérification votre programme a-t-il réellement besoin » — pour vous remettre ensuite l’outillage permettant de faire tourner le niveau que vous avez choisi. C’est dans cet interstice que se place le module CSIRT de Kit.

Kit est une infrastructure auto-hébergée, pas une foule gérée pour vous. Il ne fournit pas de chercheurs vérifiés comme le fait Synack. Ce qu’il vous donne, ce sont les contrôles pour faire tourner n’importe quel niveau et encoder vous-même les décisions de confiance :

• Configurez le programme avec le périmètre et la sphère de sécurité en amont, pour que la « bonne foi » soit définie avant l’accès — la leçon Sullivan rendue opérationnelle. La validation du périmètre maintient les rapports à l’intérieur de la limite que vous avez publiée.
• Séparez « peut signaler » de « peut être payé ». Les profils de chercheur et un flux de versement inscrit au grand livre vous permettent de garder l’accueil ouvert (niveau 0/1) tout en verrouillant l’argent derrière l’identité et l’approbation.
• Faites tourner un parcours de confiance qui se mérite. Le karma des chercheurs et les signaux de réputation vous permettent de faire monter les bons rapporteurs de niveau 1 dans un périmètre privé et restreint de niveau 2.
• Restreignez un groupe à plus haute assurance. Des contrôles d’accès au niveau du programme dirigent le périmètre sensible et stratégique vers un groupe privé et vérifié (niveau 3).
• Triez de façon cohérente, quel que soit l’auteur du signalement. Une évaluation standardisée, des suggestions de sévérité et des contrôles de doublons font qu’un pseudonyme et un prestataire nommé reçoivent le même traitement rigoureux.

Parce que Kit possède aussi un module de recrutement, il est particulièrement bien placé pour traiter la vérification des chercheurs comme le pendant « hacker externe » de votre politique de contrôle d’antécédents des prestataires : une seule discipline d’identité pour tous ceux qui peuvent toucher à vos systèmes.

La checklist de vérification du premier jour, pour un fondateur

Copiez-la, adaptez-la à votre périmètre, et vous tenez une position de départ défendable.

1. Inventoriez le périmètre par surface d’exposition. Listez chaque actif de votre programme et notez la pire journée crédible si un acteur malveillant opérait à l’intérieur. Cette note, c’est votre niveau.
2. Réglez le périmètre externe par défaut sur le niveau 1. Les actifs publics et non stratégiques donnent droit au signalement sous pseudonyme, avec KYC d’identité, fiscal et de sanctions avant tout paiement.
3. Isolez vos actifs stratégiques au niveau 2 ou 3. Tout ce qui approche les paiements, les données personnelles, les données de santé ou les clés d’infrastructure va vers un vivier sur invitation, à identité vérifiée ou à antécédents contrôlés.
4. Écrivez l’autorisation en amont. Publiez le libellé de périmètre et de sphère de sécurité avant d’inviter qui que ce soit, et rattachez l’autorisation à une partie connue. Faites-le relire par un conseil.
5. Verrouillez l’argent, pas l’accueil. N’envoyez jamais de paiement tant que l’identité, le formulaire fiscal et le contrôle des sanctions ne sont pas validés. Consignez chaque approbation, réduction et refus dans un grand livre.
6. Construisez un chemin de promotion. Laissez les bons rapporteurs de niveau 1 gagner leur place dans votre vivier privé à la réputation, pour que votre groupe de confiance grandisse à partir de comportements avérés.

La vérification est un curseur. Réglez-le à la sensibilité de ce qui est dans le périmètre, encodez l’identité et l’autorisation assez étroitement pour survivre à une question du type « cet accès était-il légitime ? », et vous obtenez les rapporteurs de bonne foi sans l’exposition juridique. Choisissez votre cran, publiez vos conditions, et faites tourner le programme qui applique les deux. Pour les mécanismes de mise en place, commencez par comment mettre en place un programme de divulgation des vulnérabilités et notre point de vue sur les niveaux de récompense en bug bounty et la confiance envers les chercheurs.