Reverse engineering pour la recherche de vulnérabilités : ce qui est légal et ce qui ne l'est pas
C'est l'une des zones grises les plus lourdes de conséquences dans ce domaine, et la traiter à la légère est un risque réel, pas juste une technicité.
Ce qui est généralement clairement acceptable
Tester votre propre logiciel, ou un logiciel pour lequel vous avez une autorisation écrite explicite de tester, est le choix par défaut sûr. Tout devient significativement plus risqué en dehors de cette frontière.
- Votre propre code ou systèmes — aucun droit d'autrui n'est impliqué.
- Un test de pénétration ou une évaluation de sécurité autorisés avec un accord de périmètre signé.
- Un programme bug bounty, strictement dans son périmètre défini — la plupart des grands programmes (via des plateformes comme HackerOne ou Bugcrowd) publient des règles exactes sur ce qui est dans et hors périmètre, et suivre ces règles est ce qui fournit le havre légal.
Ce qui est généralement clairement inacceptable
- Faire du reverse engineering sur un logiciel commercial spécifiquement pour contourner des licences, du DRM, ou des paywalls.
- Tester des systèmes de production ou des logiciels que vous ne possédez pas et pour lesquels vous n'avez aucune autorisation de test, même « juste pour voir ».
- Continuer à sonder un système après avoir trouvé une vulnérabilité, au-delà de ce qui est nécessaire pour la démontrer et la signaler (cela peut passer de la recherche à l'accès non autorisé).
- Divulguer publiquement une vulnérabilité avant de laisser au fournisseur un délai raisonnable pour la corriger, lorsque cela viole les conditions de divulgation du programme applicable.
Les zones grises qui font trébucher les gens
- Les accords de licence qui interdisent entièrement le reverse engineering — certaines juridictions et contextes permettent le reverse engineering pour l'interopérabilité ou la recherche de sécurité malgré de telles clauses (cela varie significativement selon le pays et le contexte) ; d'autres non. Cela dépend véritablement de la juridiction et vaut la peine d'être vérifié plutôt que supposé dans un sens ou l'autre.
- Trouver une vulnérabilité en dehors du périmètre déclaré d'un programme en testant à l'intérieur — signalez-la de manière responsable, mais comprenez que vous pourriez ne pas avoir la même protection légale que le test dans le périmètre fournissait.
- Tester un système auquel vous étiez autrefois autorisé à accéder mais ne l'êtes plus (les systèmes d'un ancien employeur, par exemple) — une autorisation expirée ne se reporte pas.
Une checklist pratique avant de commencer toute recherche de vulnérabilité
- Avez-vous une autorisation explicite et actuelle pour cette cible spécifique ?
- S'il s'agit d'un programme bug bounty, ce que vous êtes sur le point de faire est-il dans son périmètre publié ?
- Avez-vous un plan de divulgation responsable si vous trouvez quelque chose ?
- Êtes-vous prêt à vous arrêter à « trouvé et démontré » plutôt que de continuer à explorer un accès supplémentaire ?
Rien de tout cela n'est un conseil juridique pour votre situation spécifique — les lois varient considérablement selon la juridiction et les détails comptent. Quand vous n'êtes vraiment pas sûr qu'une cible ou une activité soit autorisée, le choix par défaut plus sûr est de ne pas procéder tant que vous ne l'avez pas clarifié.
Questions fréquentes
Est-il légal de faire du reverse engineering sur un logiciel pour trouver des bugs de sécurité ?
Cela dépend fortement de la juridiction, des termes de licence du logiciel, et si vous avez une autorisation explicite (comme le périmètre défini d'un programme bug bounty). Il n'y a pas de réponse globale unique — vérifiez les termes spécifiques et la loi applicables à votre situation avant de commencer.
Un programme bug bounty rend-il automatiquement le reverse engineering légal ?
Il autorise l'activité dans le périmètre spécifiquement défini de ce programme — tester en dehors du périmètre déclaré, ou contre des systèmes/versions non couverts, n'est pas automatiquement protégé simplement parce que l'entreprise gère un programme bug bounty en général.
Qu'est-ce que la « divulgation responsable » et pourquoi compte-t-elle légalement et éthiquement ?
C'est la pratique de signaler en privé une vulnérabilité trouvée au fournisseur concerné et de lui laisser un délai raisonnable pour la corriger avant toute divulgation publique — c'est à la fois la norme éthique en recherche de sécurité et, dans beaucoup de conditions bug bounty, une condition du havre légal offert.