Éditorial

Pourquoi les programmes gouvernementaux de recherche de vulnérabilités créent une tension entre l'immunité annoncée et le droit pénal applicable hors périmètre.

~10 min de lecture7 sections

Bug bounty gouvernemental et immunité pénale

Un programme officiel de recherche de vulnérabilités promet au chercheur une zone de sécurité juridique, mais cette zone s’arrête rarement là où le droit pénal commence. Le compromis est brutal : gagner des signalements précoces impose d’autoriser des tests réels, payer cette ouverture exige un périmètre opposable, traçable et techniquement contrôlable.

→ Lire l’explication complète de la marmotte

Immunité promise et droit pénal général

Un programme gouvernemental ne crée pas automatiquement une immunité pénale. Une charte publiée par une administration, un engagement de non-poursuite ou une clause de safe harbor, c’est-à-dire un engagement de protection du chercheur respectant les règles annoncées, fixe d’abord une position de l’organisateur. Cette position peut réduire le risque de plainte, faciliter la qualification d’une action autorisée et organiser la coopération. Elle ne neutralise pas nécessairement l’action d’une autorité judiciaire ni les infractions susceptibles d’être retenues hors périmètre.

La distinction est décisive. L’autorisation donnée par le propriétaire fonctionnel d’une application ne vaut pas toujours mandat sur l’ensemble des composants techniques : prestataire d’hébergement, opérateur de télécommunication, fournisseur d’identité, sous-traitant de paiement ou administration tierce. Un chercheur peut croire tester un portail public et atteindre une interface mutualisée, un réseau privé virtuel ou une base contenant des données d’un autre service. La permission s’évapore au franchissement de cette frontière, même si la requête initiale semblait légitime.

En droit français, l’accès ou le maintien frauduleux dans un système de traitement automatisé de données relève notamment des articles 323-1 et suivants du Code pénal. La qualification dépend des faits, de l’intention, des mesures de protection, de l’altération éventuelle et du contexte. Une page de règles ne remplace pas cette analyse. Cette fiche ne fournit pas de conseil juridique : elle décrit une architecture de réduction du risque, pas une baguette administrative capable de faire disparaître le Code pénal.

La recommandation est nette : ne jamais présenter un bug bounty gouvernemental comme une immunité générale. Le programme doit promettre une protection conditionnelle, circonscrite aux actes explicitement autorisés, et publier ce qui se produit lorsqu’un incident dépasse cette limite. Une formule marketing du type « testez sans crainte » est un aimant à ennuis avec un logo institutionnel.

Périmètre autorisé, débordement et preuves

Le périmètre doit être exprimé en actifs vérifiables : noms de domaine, plages d’adresses, applications, interfaces de programmation applicative, environnements et exclusions. Une catégorie vague comme « les services numériques de l’organisme » est inutilisable. Elle ne permet ni au chercheur de décider avant l’action, ni à l’équipe de réponse de distinguer une recherche autorisée d’une intrusion.

Chaque actif doit porter un propriétaire, un niveau de criticité et une règle de test. L’autorisation de rechercher une injection SQL (Structured Query Language) ne vaut pas autorisation d’extraire une table complète. L’autorisation d’établir qu’un contrôle d’accès échoue ne vaut pas autorisation de consulter, télécharger, modifier ou republier les données accessibles. La preuve minimale doit être définie par classe de vulnérabilité : un identifiant de ressource masqué, une capture tronquée, un hash cryptographique ou une réponse applicative non sensible suffisent souvent.

La limite la plus fragile concerne l’accès indirect. Une redirection, une résolution DNS (Domain Name System), un appel sortant ou une fédération d’identité peuvent déplacer le test vers un système non listé. Les règles doivent donc interdire explicitement l’escalade latérale, les tests sur les tiers, la collecte de secrets, l’ingénierie sociale, le déni de service et toute persistance. Sans cette liste, le périmètre ressemble à une clôture peinte sur le sol : visible, décorative, et parfaitement traversable.

La preuve d’autorisation doit être conservée avant le test : version datée des règles, identifiant du programme, actif visé, fenêtre d’essai et accusé de réception si le test sort de la routine prévue. Une copie locale seule ne suffit pas, car une page peut être modifiée après coup. Un journal horodaté, des en-têtes de requête identifiants et une conservation des réponses minimisées donnent une chronologie exploitable lors d’un désaccord.

Les sujets de gouvernance et de gestion des menaces se rejoignent ici : l’autorisation est un contrôle de sécurité, pas une prose de bas de page. Si elle n’est pas versionnée, attribuée et journalisée, elle ne permet pas d’arbitrer un incident.

Safe harbor opérationnel et responsabilité partagée

Un safe harbor exploitable doit contenir cinq éléments. D’abord, les actes permis : reconnaissance passive, authentification avec comptes de test, vérification d’accès, exploitation limitée et preuve attendue. Ensuite, les actes interdits : indisponibilité, exfiltration, chiffrement, modification, accès aux données personnelles et pivot vers un tiers. Puis, les actifs exclus, notamment les systèmes industriels, les services d’urgence, les environnements de production sensibles et les composants mutualisés.

Le quatrième élément est une voie d’escalade humaine avec délai de réponse. Un chercheur qui détecte une exposition de données n’a pas à choisir entre divulgation publique et silence parce qu’une boîte aux lettres générique dort sous trois couches de filtrage antispam. Un canal chiffré, une procédure d’urgence et un accusé de réception horodaté sont nécessaires. Les détails de chiffrement et de preuve doivent suivre les principes décrits dans la section cryptographie, pas un fichier de clés posé dans un dépôt parce que « c’est temporaire ».

Enfin, le programme doit préciser son traitement des débordements involontaires. La bonne doctrine distingue l’écart immédiatement arrêté, signalé et documenté, de l’écart poursuivi malgré les indices de sortie de périmètre. Le premier appelle une coordination et une conservation des preuves. Le second peut retirer la protection annoncée. Cette distinction protège les deux parties sans faire croire qu’un clic malheureux devient automatiquement une permission illimitée.

Le compromis central est donc le suivant : plus le périmètre est large, plus la découverte est riche, mais plus le risque d’atteindre des systèmes, des données ou des opérateurs non consentants augmente. Pour des services publics exposés, le bon choix est un périmètre initial étroit, enrichi par vagues après validation technique et juridique. Le programme « tout le patrimoine numérique » appartient aux présentations de vente, avec les licornes et les graphiques sans axe.

Exemple reproductible de vérification de périmètre

Avant toute requête de test, un manifeste signé peut publier les actifs autorisés et leurs restrictions. Il ne remplace pas l’autorisation juridique, mais réduit l’ambiguïté opérationnelle et permet de vérifier que la cible consultée correspond bien à une version publiée du périmètre.

# Télécharger le manifeste public des actifs autorisés.
curl --fail --silent --show-error \
  https://security.example.gov/bug-bounty/scope.json \
  -o scope.json

# Contrôler l'intégrité avec le hash publié sur une page indépendante.
echo "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef  scope.json" \
  | sha256sum --check

# Vérifier qu'un hôte précis est explicitement déclaré avant tout test.
jq -e '.assets[] | select(.hostname == "api.example.gov" and .status == "in-scope")' \
  scope.json

Le hash SHA-256 (Secure Hash Algorithm 256 bits) doit être publié sur un canal distinct du manifeste, sinon un compromis unique peut modifier les deux objets. Une signature numérique apporte une meilleure propriété d’origine, à condition que la clé publique soit distribuée par un canal déjà fiable et que la révocation soit gérée. Un certificat expiré n’invalide pas rétroactivement une autorisation, mais il rend la vérification future contestable si aucune archive horodatée n’existe.

Le manifeste doit aussi signaler les exclusions dynamiques : incident en cours, maintenance, transfert vers un prestataire ou risque sur la disponibilité. L’absence de réponse du manifeste n’autorise rien. Une indisponibilité est une condition d’arrêt, pas une invitation à « vérifier autrement ». Les systèmes publics ont déjà assez de surprises sans ajouter des expériences de physique appliquée sur la production.

Exploitation, supervision et reprise après incident

Le programme doit être opéré comme un service de sécurité. Cela impose un inventaire maintenu, une équipe capable de qualifier les rapports, une procédure de triage et des délais affichés. Sans capacité de réponse, la plateforme attire des signalements que personne ne peut traiter, puis transforme des vulnérabilités signalées en dette connue. Ce n’est pas de la transparence, c’est un ticketing system avec une mèche allumée.

Les identifiants de test doivent être individuels, temporaires et révocables. Ils ne doivent jamais ouvrir un accès administratif partagé, ni contourner les journaux de sécurité. La révocation d’un compte doit invalider les jetons de session associés ; désactiver seulement l’identifiant laisse des sessions actives continuer leur trajet, ce qui est une forme très calme de panne de sécurité.

Les journaux doivent conserver l’identifiant du chercheur, l’actif, l’heure, le type d’action et la décision de triage. Leur intégrité compte autant que leur présence : stockage à accès restreint, horodatage fiable, rétention définie et export exploitable en cas de contentieux. Les données personnelles collectées pendant le signalement doivent être minimisées, car un bug bounty ne transforme pas une plateforme de signalement en aspirateur à données.

La reprise doit prévoir trois cas : compromission réelle, faux positif et test autorisé ayant provoqué un effet de bord. Dans les trois cas, geler les preuves, suspendre les identifiants concernés, préserver les journaux et rétablir le service depuis des sauvegardes testées. La sauvegarde non restaurée régulièrement est une croyance métaphysique, pas une capacité de reprise.

🐝 Ce qui arrive si on s’en passe

Sans programme publié, aucun canal ne sépare le chercheur de bonne foi de l’attaquant : les requêtes ne portent ni identifiant de chercheur ni compte de test, et le journal range toute exploration dans la même catégorie d’intrusion, ce qui brouille le triage et la corrélation des alertes. La personne qui découvre un défaut n’a alors que trois issues : se taire, publier sans coordination ou céder l’information à qui la paie ; dans les trois cas, l’organisme ignore une faille déjà connue à l’extérieur. Les rares signalements arrivent anonymes, sans preuve minimale ni étapes de reproduction, donc difficiles à qualifier et à corriger. L’absence de règle de preuve laisse aussi le découvreur libre d’extraire bien plus que nécessaire pour être cru.

🦫 Explication de la marmotte 🍫

Un programme de recherche de vulnérabilités permet à des personnes extérieures de chercher des défauts dans des services publics et de les signaler. L’organisme publie d’abord une liste précise des sites et applications concernés, ainsi que les actions autorisées et interdites. Cette liste doit indiquer ce qui est exclu, par exemple les systèmes qui ne doivent jamais être ralentis ou les données qui ne doivent pas être lues.

La promesse de protection ne fonctionne que si la personne respecte ces règles. Si elle entre dans un système absent de la liste, récupère des informations, modifie un service ou continue après avoir compris qu’elle dépasse la limite, le droit pénal peut encore s’appliquer. L’organisme ne peut pas toujours empêcher une enquête judiciaire par une simple page publiée sur Internet.

Pour réduire les erreurs, les règles doivent être datées, conservées et vérifiables. Les personnes qui cherchent des défauts doivent garder une preuve de ce qu’elles avaient le droit de tester. L’organisme doit enregistrer les actions, répondre vite aux signalements et pouvoir couper un accès de test si un incident survient.

Quand un défaut est trouvé, il faut montrer juste assez pour prouver le problème, sans récupérer davantage de données ni perturber le service. Si une limite est franchie par erreur, l’action doit s’arrêter immédiatement et être signalée. Le programme protège alors une recherche encadrée, pas toutes les actions effectuées sous son nom.

Pages voisines

La citent

Bug bounty gouvernemental et immunité pénale

Elle cite

Bug bounty gouvernemental et immunité pénale

Bug bounty gouvernemental et immunité pénale

Immunité promise et droit pénal général

Périmètre autorisé, débordement et preuves

Safe harbor opérationnel et responsabilité partagée

Exemple reproductible de vérification de périmètre

Exploitation, supervision et reprise après incident

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines