Bug Bounty : le guide ultime pour un programme réussi

Vous souhaitez lancer un bug bounty, mais vous ne savez pas par où commencer ? Hackers, scope, triage… Voici notre guide étape par étape pour un programme couronné de succès.

Le bug bounty est un exercice encore jeune, si bien que certains se demandent si c’est une approche efficace du test de sécurité. La réponse est simple : oui, mais pas sans conditions.

En matière de bug bounty, deux questions séparent la réussite de l’échec :

• Pourquoi ?
• Et comment ?

Cet article ne s’attardera pas sur le pourquoi du bug bounty comme test de sécurité, ni sur ses forces et ses faiblesses. Néanmoins, précisons ici qu’il est impératif de bien comprendre l’exercice avant de se lancer, et de s’assurer que c’est bien le test le plus adapté à vos environnements et vos besoins de sécurité.

Si vous en êtes à l’étape de réflexion, nous vous conseillons ces quelques lectures préalables sur le sujet :

• Pourquoi en faire, et par où commencer ?
• Les avantages et inconvénients du bug bounty pour la cybersécurité
• Pentest vs Bug Bounty : quelle approche pour quelle situation ?

Si votre choix du bug bounty est mûrement réfléchi : félicitations, vous êtes au bon endroit ! Mais ce n’est pas tout de créer un programme de bug bounty, encore faut-il le faire dans les règles de l’art. Et vous allez voir qu’il y a du pain sur la planche !

Comment construire son programme de bug bounty ?

Ce n’est pas tout de faire du bug bounty, encore faut-il savoir comment. Comment mettre en place un programme de bug bounty couronné de succès ? Au final, ça se résume à trois choses :

1. L’attractivité du programme de bug bounty ;
2. La gestion du programme par les équipes internes ;
3. L’approche des remédiations par les équipes de développement.

Les deux premiers points déterminent la qualité de votre relation avec les hackers, et la performance du programme. Le troisième détermine la bonne réception du bug bounty en interne, et la transformation des détections en résultats actionnables. Mis bout à bout, ils conditionnent entièrement le succès ou l’échec de votre bug bounty.

Ces trois points sont tout le cœur de cet article. Accrochez-vous, on va voir tout ça en profondeur.

I. L’attractivité du programme de bug bounty

Pour être efficace, un programme de bug bounty doit être attractif. Autrement dit, il doit donner envie aux hackers éthiques de participer ; de prendre du temps pour tenter de trouver des vulnérabilités dans vos périmètres plutôt que dans ceux du voisin.

Pas de participation des hackers = pas de bugs = bug bounty inefficace. C’est aussi simple que ça. Concrètement, ça veut dire quoi ?

Un programme de bug bounty est attractif si :

1. le scope est clair et exhaustif ;
2. la communication avec les hunters est claire et rapide ;
3. le triage des rapports de vulnérabilités est rapide ;
4. les paiements sont envoyés rapidement après la validation d’un rapport ;
5. les récompenses sont compétitives ;
6. la visibilité du programme est cohérente avec la maturité des actifs.

1. Le scope

Le scope d’un bug bounty doit être clair et exhaustif. Ce sont les règles de votre programme. Elles explicitent ce que les hunters peuvent faire ou non, quelles vulnérabilités sont valides ou non – les attaques DDoS par exemple.

Le scope précise également quels sont les produits et applicatifs concernés par le bug bounty – site web, applications, etc. Il va sans dire que plus un scope est important, plus il est alléchant pour les hunters. Après tout, plus y a de mines à explorer, plus ils ont de chances de trouver le bon filon.

Le manifeste du programme doit être le plus détaillé possible, quand bien même la rédaction pourrait prendre du temps. C’est la base future de tout votre bug bounty, votre vitrine face aux hunters. Un programme mal rédigé ou incomplet peut engendrer plus de temps de gestion que ce qu’il aurait demandé à être écrit.

2. La communication avec les hunters

La communication avec les hunters doit être claire et rapide.

Une communication claire est la base d’une bonne relation entre êtres humains. Répondre aux hackers permet de les aiguiller dans leurs recherches, ce qui est autant dans votre intérêt que dans le leur. De plus, il ne faut pas oublier que les hunters viennent des quatre coins du monde. Nous n’avons pas tous le même background, nous ne parlons pas tous la même langue – même si l’anglais reste la langue de référence dans les échanges. La diversité des profils est ce qui fait la force du bug bounty. Une communication claire permet de lever certaines ambiguïtés ou incompréhensions.

Une communication rapide témoigne de votre intérêt pour le bug bounty, de votre sérieux dans l’exercice. Demander à un hacker de participer à votre programme, c’est lui demander de prendre de son temps pour trouver des vulnérabilités dans vos périmètres. C’est lui demander de relever votre défi plutôt que ceux des autres. Relèveriez-vous le défi de quelqu’un qui ne prend pas le temps de vous répondre ?

3. Le triage des rapports

La rapidité du triage des rapports est déterminante dans le succès d’un programme de bug bounty.

Imaginez qu’un hunter prenne le temps de soumettre une vulnérabilité, et qu’il n’ait aucune nouvelle de votre part pendant 2 mois, 6 mois ou plus… Il y a peu de chances qu’il soumette un deuxième rapport. Pire, d’autres chercheurs pourraient décider de ne pas participer à votre programme. Là encore, la rapidité du triage des rapports qui vous sont envoyés témoigne de votre sérieux dans l’exercice du bug bounty.

Si vous refusez un rapport, prenez le temps d’expliquer pourquoi. Sans parler d’écrire des romans, une explication sera toujours bienvenue. Souvenez-vous qu’un hunter qui vous envoie un rapport est une personne qui a pris le temps de se pencher sur vos environnements. Prenez celui de répondre. Par ailleurs, expliciter le refus d’une vulnérabilité permet souvent aux chercheurs d’aiguiller leurs futures recherches – ce qui ne peut que vous être bénéfique.

4. La rapidité des paiements

Tout travail mérite salaire, c’est aussi simple que ça. Dès lors qu’un rapport soumis par un hacker est accepté, la récompense doit lui être versée rapidement. Un bug = une prime, c’est la fondation même du bug bounty.

Parmi les meilleurs chercheurs en sécurité, certains ont fait du bug bounty leur profession, leur gagne-pain. Et comme tout le monde, ils ont leurs lots de charges à régler à la fin du mois. La rapidité des paiements est donc un argument qui peut faire toute la différence entre votre programme et celui du voisin.

5. La compétitivité des récompenses

Autrement dit, le montant des primes en contrepartie d’une vulnérabilité. Plus elles sont compétitives, plus les meilleurs éléments participeront à votre bug bounty. Le montant de la prime dépend directement de la criticité de la vulnérabilité identifiée – low, medium, high, critical. Le montant associé à chaque criticité doit être clairement affiché dans le manifeste du programme.

Mieux vaut débuter par des montants modestes, puis augmenter au fur et à mesure de la longévité du programme. Cela permet de maintenir l’intérêt des hunters pour votre programme, en plus de scaler les bounties avec la difficulté. A priori, plus un programme est ancien, plus les vulnérabilités “faciles” à trouver auront déjà été défrichées. Il est donc logique que les primes augmentent avec la difficulté.

Inutile de s’arracher les cheveux sur le montant des récompenses. A moins d’opter pour un bug bounty auto-hébergé, vous serez a priori conseillé par la plateforme de bug bounty que vous aurez choisie – Yogosha a tout hasard ! La plateforme vous conseillera une grille de récompenses en fonction de celles pratiquées par les autres programmes, du nombre de participants, de la taille de votre entreprise, de son niveau de sécurité, du secteur d’activité, etc.

Par ailleurs, ne croyez pas que le montant des primes est le critère le plus important dans l’attractivité d’un bug bounty. Trop d’organisations se découragent faute d’un budget conséquent. Mais n’est pas Google ou Facebook qui veut, et les hunters le savent très bien. De nombreux membres de la Yogosha Strike Force vous diront que la communication et la rapidité du triage sont plus importantes que la grille de récompenses.

6. La visibilité du bug bounty

La visibilité d’un bug bounty détermine combien de hackers pourront potentiellement y participer. Un programme peut être public ou privé.

• Un bug bounty public est ouvert à tout un chacun sur le web, tout le monde peut y participer.
• Un bug bounty privé n’est ouvert qu’aux hackers qui sont spécifiquement invités à y participer.

Bug bounty public et bug bounty privé

Avec un bug bounty public, le nombre de hackers participants est potentiellement illimité. Mais cela se fait au détriment de la confidentialité du programme – certaines organisations sensibles préfèrent cultiver une forme de secret, les institutions financières par exemple. De plus, un bug bounty public ne permet pas de trier les hunters en fonction de leur talent. Il y aura des hackers expérimentés, mais aussi des débutants. Pour simplifier, choisir un bug bounty public, c’est choisir la quantité à la qualité.

A l’inverse, un bug bounty privé permet aux organisations :

• de décider du nombre de hackers participants ;
• de leur niveau d’expertise ;
• de contrôler la volumétrie des rapports, et donc la charge de travail des équipes de triage. Forcément, un bug bounty public ouvert à toute la planète générera plus de rapports qu’un bug bounty privé avec 200 hackers invités. Pour autant, les rapports ne seront pas forcément de meilleure qualité – le nombre de rapports invalides, de faux positifs et de dupliqués peut être colossal avec un programme public. C’est ce qu’on appelle le SNR, pour Signal-to-Noise Ratio.

A propos du SNR des bug bounty publics : Plus le SNR est faible, plus la qualité générale des rapports envoyés est médiocre. À titre d’exemple, 95 % des vulnérabilités rapportées à Facebook et Google lors du lancement de leurs programmes publics étaient invalides. Quant au bug bounty public d’Uber, il avait un SNR de 1:6 dans ses premiers jours, avec 20% de dupliqués et seulement 161 rapports acceptés pour 2 030 reçus.

Bug bounty : plateformes publiques vs plateformes privées

La plupart des plateformes de bug bounty sont publiques. Elles offrent parfois la possibilité de conduire des programmes sur invitation, mais leur communauté de hackers est par essence publique. Autrement dit, n’importe quel hacker peut créer un compte sur ces plateformes, sans regard pour ses compétences, son expertise ou même son identité.

A l’inverse, Yogosha est une plateforme privée. Cela signifie deux choses :

• Notre communauté de hunters, la Yogosha Strike Force, est entièrement privée. Chaque membre de la YSF a prouvé sa valeur en réussissant nos tests d’entrée – qui sont pour le moins exigeants, puisque seulement 20% des participants nous rejoignent. (Cf. Comment rejoindre Yogosha ?)
• Tous les programmes de bug bounty conduits sur notre plateforme sont confidentiels. Concernant la visibilité, deux choix s’offrent à nos clients :
  1. Un programme peut être ouvert à tous les membres de la Yogosha Strike Force.
  2. Ou réservé à une frange de hunters spécifiquement sélectionnés, en fonction de leurs compétences par exemple, qui peuvent correspondre aux prérequis techniques de certains environnements. Certains chercheurs s’y connaissent en cryptos, là où d’autres penchent pour l’IoT ou le cloud.

“On a une vision de la sécurité très pragmatique, et on a retrouvé la même approche chez Yogosha. Pour les tests qu’on a eu à faire, on a été mis en relation avec des profils qui avaient les compétences nécessaires sur cette technologie pour être pertinents. ”, – Christophe Cuyala, Responsable Sécurité Opérationnelle chez Teréga

La visibilité du bug bounty pour maîtriser la compétition entre les hunters

Derrière la question de la visibilité du bug bounty s’en cache en réalité une autre : celle de la compétition entre les hunters. Autrement dit, comment multiplier les participants pour augmenter les détections, sans pour autant démotiver les hackers à participer par peur d’une compétition trop féroce ?

Avant de participer à votre bug bounty, un hacker estimera toujours ses chances de trouver une vulnérabilité dans vos périmètres. Seriez-vous plus enclin à participer au tirage d’un loto avec 100 participants, ou 10.000 participants ? C’est exactement la même chose avec le bug bounty, à l’exception que le talent est plus important que la chance.

Une compétition trop importante induit une baisse du ROI pour les hackers. Participer à un bug bounty surpeuplé, c’est augmenter la probabilité d’envoyer un rapport dupliqué – qui a déjà été soumis par un autre – et donc de ne pas toucher la récompense.

Mais alors, comment maîtriser la compétition entre les hunters ? C’est simple, on en revient à la visibilité du bug bounty. C’est elle qui va déterminer la balance entre le nombre réel de participants, et le nombre potentiel de vulnérabilités à trouver.

Aligner la visibilité du programme sur la maturité des actifs ciblés

Un bug bounty public attirera forcément plus de participants, et sera donc plus compétitif d’un bug bounty privé. Moins il y a de hackers invités à un programme > plus ils ont de chances de trouver une vulnérabilité > et plus ils seront enclins à participer.

Pour autant, inviter trop peu de participants reviendrait à diminuer la force de recherche, et donc les détections. La visibilité du bug bounty doit donc être cohérente avec la maturité des actifs visés.

En règle générale, la meilleure marche à suivre est la suivante :

• Commencer par un bug bounty privé, en invitant seulement une poignée de hunters. Ils défricheront les vulnérabilités les plus évidentes dans les périmètres jeunes, tout en laissant le temps aux équipes internes de se familiariser avec l’exercice du bug bounty.
• Inviter davantage de hunters à participer au fil du temps et des CI/CD. Amener du sang neuf, avec un regard nouveau, augmente les probabilités d’identifier des vulnérabilités critiques, complexes et chronophages à trouver. Augmenter le montant des récompenses au fil de l’eau est également une bonne chose.
• Le cas échéant, envisager un bug bounty public, souvent après plusieurs années. Le temps passé en petit comité aura permis d’identifier la plupart des vulnérabilités, et de renforcer la sécurité globale des actifs. Si les détections deviennent trop rares avec un bug bounty privé, il peut être intéressant de l’ouvrir à l’ensemble de la communauté des chercheurs pour multiplier les regards.

Compétition, coopération et chainbug

Soulignons tout de même que la compétition entre les hackers n’est pas intrinsèquement une mauvaise chose, pour peu qu’elle soit bien dosée. La compétition fait partie du jeu du bug bounty.

Une programme compétitif poussera certains hunters à collaborer, à travailler en groupe pour trouver des vulnérabilités particulièrement complexes. A l’inverse, un programme moins compétitif incitera les chercheurs à chainbug : à essayer d’enchaîner des vulnérabilités a priori légères pour créer un résultat plus critique.

• Si la compétition fait rage, les hackers auront tendance à soumettre un bug le plus rapidement possible par peur qu’un autre le fasse avant – le fameux rapport dupliqué ;
• Si la compétition est moindre, les hunters peuvent prendre le temps d’expérimenter, d’enchaîner différentes vulnérabilités pour augmenter la criticité finale, et maximiser la prime.

II. La gestion du programme par les équipes internes

Vous savez maintenant tout ce qui fait un bon bug bounty sur le papier. Mais seule une bonne gestion du programme par les équipes internes fera la différence entre la théorie et la pratique.

Prévenir les équipes internes du lancement d’un bug bounty

Il est impératif de prévenir les équipes métier du lancement d’un bug bounty. D’aucuns pourraient vouloir tester la capacité de réaction des équipes en jouant la carte de la surprise, mais ce n’est pas le rôle du bug bounty. Il existe d’autres formes de tests pour éprouver la résilience de l’entreprise – les exercices de Red Team par exemple.

Débuter un bug bounty sans alerter les équipes internes pourrait poser de mauvaises bases pour la suite.

• Les détections peuvent être importantes, et les remédiations nombreuses. Il est inutile de créer une charge de travail et un stress imprévus chez vos collaborateurs, qui pourraient être pris au dépourvu.
• L’exercice du bug bounty pourrait être mal perçu par la suite. Certains n’ont peut-être jamais entendu parler du bug bounty. Introduire vos équipes à la chose avec une déferlante de hackers sortis de nulle part n’est peut-être pas le plus judicieux.
• Le rôle premier du bug bounty est la détection des vulnérabilités préjudiciables, pas la mise à l’épreuve de la capacité de réaction des équipes. Mélanger les exercices et les objectifs envoie un mauvais signal.

Evangéliser les autres corps de métier

Ce n’est pas tout de prévenir les équipes métier, comme les développeurs ou l’équipe de sécurité. Pour que le bug bounty soit un succès au sein de l’entreprise, il est important de prévenir tous les corps de métier qui pourraient être concernés – de près comme de loin.

• Le service juridique aura sûrement quelques questions vis-à-vis du hacking éthique. Prenez le temps de leur apporter des réponses, d’aborder les sujets sensibles ;
• L’équipe marketing souhaitera peut-être communiquer sur le lancement du bug bounty. Il faudra donc un peu de temps pour préparer les éléments de communication ;
• Le service des ressources humaines s’appuiera peut-être sur le bug bounty pour renforcer la marque employeur auprès des profils tech.

N’oubliez pas que toutes ces personnes n’ont, en général, pas un profil tech. Un développeur comprendra sûrement très vite de quoi il en retourne avec le bug bounty, mais il faudra peut-être un peu plus de temps aux juristes de l’entreprise. Il vous appartient de prendre le temps du dialogue, d’expliquer ce qu’est le bug bounty et pourquoi vous y avez recours. Sans quoi, l’exercice pourrait être au mieux incompris, et au pire mal reçu.

Lorsque vous communiquez avec des équipes qui n’ont pas un bagage technique, n’hésitez pas à utiliser le terme de “chercheur en sécurité” plutôt que “hacker” ou “hacker éthique”. Les mentalités évoluent, mais le terme de “hacker” est encore connoté négativement dans l’inconscient collectif. Certaines personnes pourraient prendre peur ou accueillir le bug bounty avec réticence, là où “chercheur en sécurité” peut rassurer et apporter une certaine crédibilité aux yeux d’un public néophyte.

Former les équipes métier au bug bounty

Cela peut sembler évident, mais mieux vaut prévenir que guérir. Ce n’est pas tout de prévenir les équipes techniques du lancement d’un bug bounty, encore faut-il expliquer ce que c’est. Tout le monde n’est pas forcément familier avec le sujet.

Prenez le temps d’expliquer l’intérêt du bug bounty, le rôle des hunters dans la détection continue des vulnérabilités. Il est essentiel que les équipes comprennent les concepts du bug bounty, ainsi que son lexique. Triage, rapports de vulnérabilités, bounties… Autant de termes qu’il peut être utile d’expliquer avant que tout le monde se jette dans le bain de la “prime aux bogues”, en bon français.

Pour former les équipes au bug bounty :

• partagez des ressources que vous avez trouvées utiles – cet article par exemple ?
• organisez un workshop sur le sujet – avant et après le lancement du bug bounty ;
• une fois les premières semaines passées, n’hésitez pas à partager quelques chiffres en interne, pour témoigner des résultats du programme ;
• si vous voyez les choses en grand, pourquoi ne pas organiser un Live Hacking Event ? Une compétition de bug bounty en direct, pendant laquelle vos équipes et les hackers peuvent se rencontrer le temps de quelques jours.

Désigner un ou plusieurs Program Owners

Pour que votre bug bounty soit un succès, il est essentiel de désigner un ou plusieurs responsables chargés du projet et de la communication avec les hackers éthiques.

Vous pouvez désigner un responsable permanent, ou instaurer des roulements au sein de l’équipe. Cela permet :

• de partager la charge de travail supplémentaire liée au bug bounty – la communication et le triage ;
• d’initier tout le monde à l’exercice ;
• d’embarquer tout le monde dans l’aventure, afin que les succès comme les échecs soient ceux d’une équipe et pas d’une seule personne ;
• une formation passive de chaque individu, qui peut monter en compétences au contact des hackers.

A ce sujet, précisons que le Vulnerability Operations Center (VOC) Yogosha permet de contingenter les accès et les rôles, au sein des équipes mais aussi des différentes entités qui peuvent composer une même organisation. Cette organisation en silos permet de régler minutieusement l’implication de chacun, et la visibilité sur la sécurité des actifs de l’entreprise.

Lire aussi : C’est quoi, un Vulnerability Operations Center (VOC) ?

Triage : géré en interne ou confié à une plateforme de bug bounty ?

Trier les rapports de vulnérabilités envoyés par les hunters est la tâche la plus chronophage d’un bug bounty. Il existe deux approches du triage.

1. Internaliser le triage

Certaines organisations décident de confier le triage à leurs équipes internes. Le plus souvent un membre de l’équipe sécu, ou un développeur avec un penchant pour la cybersécurité. Internaliser le triage présente de nombreux avantages :

• Vous gardez le contrôle sur votre bug bounty ;
• vous assurez la confidentialité des rapports de vulnérabilités ;
• vous avez une vision complète sur les remontées, positives comme négatives ;
• vous vous assurez de la pertinence du triage. Après tout, vos équipes connaissent mieux vos produits que n’importe quel externe, et sont donc les mieux placées pour juger de l’impact business réel d’une vulnérabilité.

C’est ce dont témoigne Antonin Garcia, le RSSI de Veepee, qui a confié le triage à l’équipe OffSec (Offensive Security) : “Puisqu’ils font du pentest, ils ont la finesse nécessaire pour jauger les vulnérabilités. Ils savent qualifier la criticité, et être dans le débat s’il y a désaccord avec un hunter. “

Si vous confiez le triage à vos équipes internes, insistez sur l’importance de la communication avec les hunters. Il est absolument crucial de maintenir un échange sain et transparent avec les hunters, que les rapports soient acceptés ou refusés. Cette communication claire est le terreau de toute votre relation avec la communauté.

2. Confier le triage à une plateforme de bug bounty

La deuxième solution est de confier le triage des rapports à la plateforme que vous aurez choisie pour héberger votre bug bounty. Cette solution présente le double avantage :

• de délester les équipes internes de cette charge de travail, qui peut s’avérer plus ou moins fastidieuse en fonction du flux des rapports ;
• de permettre à toutes les organisations de faire du bug bounty, y compris à celles qui n’ont pas le savoir-faire ou les ressources nécessaires en interne pour trier les rapports de vulnérabilités.

Si vous confiez le triage des rapports à une plateforme, renseignez-vous sur les équipes de triage. La plupart des plateformes de bug bounty ont des équipes de triage en interne. Elles sont donc juge et partie en cas de désaccord ou de conflit avec un hacker.

Chez Yogosha, nous garantissons notre impartialité en matière de triage en travaillant avec les cabinets de conseil les prestigieux. Nos Services Managés s’étendent bien au-delà du triage, avec des solutions complètes et modulables pour les grands comptes. Nous concevons ainsi des stratégies de sécurité de bout en bout, de la phase de construction à la phase de remédiation.

Mettre à jour le programme régulièrement

Il est important d’actualiser régulièrement le manifeste de votre bug bounty – notamment le scope – et cela pour deux raisons :

1. Faire plusieurs mises à jour par an plutôt qu’une seule – ou pire, au lancement puis plus jamais ! – témoigne de l’activité de votre programme. Les hunters seront d’autant plus enclins à participer à votre bug bounty s’ils voient que vous prenez les choses au sérieux, que votre programme vit et évolue.
2. Updater votre bug bounty au fil des nouvelles releases permet d’aiguiller la recherche des hunters, de concentrer leurs efforts sur ce que vous souhaitez tester. Une nouvelle feature est passée en prod ? Mettez votre scope à jour, et dites-le aux chercheurs !

III. L’approche des remédiations par les équipes de développement

C’est la fin du tunnel, le dernier sprint. Les étapes précédentes conditionnent la performance de votre programme ; mais c’est ici qu’il faut transformer les détections en résultats actionnables. Le rôle du bug bounty est simple : identifier les vulnérabilités – et notamment les plus critiques. Mais à quoi bon détecter si rien n’est corrigé ?

Les remédiations apportées par les développeurs sont cruciales, puisque ce sont elles qui vont in fine renforcer la sécurité globale des actifs. Il faut donc s’assurer que ces équipes envisagent les remontées du bug bounty de la meilleure façon possible.

Prioriser les remédiations, établir des process

Il est impératif d’établir des processus clairs et précis, en cybersécurité peut-être encore plus qu’ailleurs. Ce sont eux qui permettront à vos équipes d’envisager au mieux les remédiations, sans avoir à prendre des décisions dans l’urgence.

Les processus de remédiation doivent être rédigés et communiqués aux équipes en amont du bug bounty. Ils doivent leur permettre de répondre au minimum aux questions suivantes dès lors qu’une vulnérabilité est acceptée :

• Qui ? Quelles sont les ressources humaines à mobiliser ? Les équipes et collaborateurs chargés de la remédiation sont-ils différents selon les produits, les environnements, les technologies ?
• Quand ? Quel est le temps nécessaire à la correction ? Il est impératif de fixer des délais de remédiation selon la criticité des vulnérabilités. Une vulnérabilité critique doit être adressée au plus vite, là où une low peut probablement attendre.
• Comment ? Comment corriger la vulnérabilité ? Quelles sont les besoins techniques et les compétences nécessaires ?

Ces points sont le strict nécessaire à mettre en place. Plus vos processus seront détaillés, mieux ce sera. Il peut être utile de s’aligner avec le plan de réponse aux incidents de l’entreprise, de définir des astreintes en cas de détection d’une vulnérabilité critique, ou encore de s’accorder sur les feedbacks à faire après la remédiation.

Dégager du temps aux équipes pour la remédiation

Cela peut sembler évident, mais il est important de dégager du temps aux équipes de développement pour qu’elles puissent apporter des correctifs. C’est une tâche à part entière, pas quelque chose qui s’ajoute à la charge de travail habituelle ou à faire “quand on a un peu de temps”.

Attention au rush du lancement. Les détections sont souvent nombreuses pendant les premières semaines d’un bug bounty, et les premières heures peuvent être particulièrement intenses. Il est important que les équipes soient préparées à y répondre, ne serait-ce que mentalement. Ne lancez pas un bug bounty en pensant qu’il ne génèrera aucun retour.

Par ailleurs, la cadence de détection du bug bounty doit être cohérente avec la capacité de remédiation des équipes de l’organisation. Si les vulnérabilités high et critiques sont identifiées plus vite que l’équipe ne peut les corriger, c’est le stress assuré – et le burn-out si la situation perdure.

On en revient à l’importance des processus pour prioriser les actions de remédiation. Par ailleurs, avec Yogosha, il est possible de mettre les programmes en pause pour réguler le flux des rapports. Veillez tout de même à prévenir les hunters participants, et à ne pas mettre le bug bounty en pause en toute opacité. Certains chercheurs étaient peut-être sur le point d’envoyer un rapport, et pourraient ne pas comprendre pourquoi le programme est gelé. Là encore, la communication avec les hunters est essentielle.

Le bug bounty est un contrôle continu, pas une punition

Le bug bounty est un contrôle continu des actifs numériques de l’organisation, pas une punition pour ses équipes de développement. Les vulnérabilités détectées par le bug bounty ne doivent pas être considérées comme un aveu d’échec, ou présentées comme la preuve d’un travail mal fait. Cela ne ferait que braquer vos équipes internes vis-à-vis du bug bounty et des hunters.

Il y aura toujours des vulnérabilités dans les environnements numériques, quels qu’ils soient. Parfois par design, parfois non. Demander à un développeur de ne jamais créer de failles, c’est demander à un être humain de ne jamais faire d’erreurs. C’est tout bonnement irréalisable. En revanche, il est possible de prôner l’amélioration.

Le bug bounty pour détecter les faiblesses d’une équipe

Le bug bounty est un excellent outil pour comprendre les forces et les faiblesses d’une équipe de développement. Une formation peut s’avérer bénéfique si vous constatez qu’une même typologie de vulnérabilités est régulièrement exploitée par les hunters, ou qu’un pattern particulier se dessine. De même, la résilience notable d’un produit à une classe de vulnérabilités courante peut témoigner du savoir-faire d’une équipe, qui pourrait partager ses connaissances aux autres collaborateurs.

Le bug bounty pour sensibiliser les développeurs à la cybersécurité

Grâce au contact régulier avec les hackers éthiques, le bug bounty est une excellente formation de terrain à la cybersécurité pour vos équipes de développement. Le bug bounty offre un regard neuf sur leur travail, pas avec l’œil d’un développeur mais avec celui d’un attaquant. Les développeurs seront plus à même d’intégrer une bonne sécurité par design en apprenant du bug bounty, en découvrant les réels vecteurs d’attaques utilisés par les hunters.

Le bug bounty est une approche ludique et concrète pour intéresser les dévs à la sécurité numérique. C’est ce qu’explique Julien Reitzel, le Lead Sécurité Offensive chez Veepee :

“Je ne m’y attendais pas forcément, mais on a remarqué que les vulnérabilités remontées par le programme de bug bounty suscitent beaucoup plus l’intérêt des équipes. […] Quand on dit qu’une vulnérabilité vient du bug bounty, ils se disent : “ah, mais ça veut dire que n’importe qui sur Internet peut faire ça sur mon application ! Et en plus, on a dû payer quelqu’un pour avoir trouvé cette vuln en particulier. “

En adoptant ces quelques conseils, vous devriez être fin prêts à attaquer la chasse aux bugs de la meilleure manière possible. Si vous décidez de continuer l’aventure du bug bounty, n’hésitez pas à nous contacter !