Comparatif
Test d’intrusion ou bug bounty : faut-il ouvrir un programme de primes ?
En résumé
Un test d’intrusion est une mission cadrée, payée au temps passé, avec une couverture définie et un rapport complet, à partir de 1 490 €. Un bug bounty est un programme ouvert où des chercheurs sont payés seulement pour les failles qu’ils trouvent. Le premier assure un effort et un périmètre définis, le second offre une diversité d’approches dans la durée mais suppose d’avoir déjà corrigé les défauts de base et de pouvoir traiter les signalements. Ouvrir une prime avant un test d’intrusion revient souvent à payer des défauts évidents.
Sommaire : 5 sections
Ce que chaque option fait, et ce qu’elle ne fait pas
Un effort défini, un périmètre couvert, un rapport complet.
Test d’intrusion
Une mission à prix et durée connus, menée par des analystes identifiés selon une méthode, avec un rapport qui décrit aussi ce qui a été testé sans résultat. Elle répond à « ce périmètre précis a-t-il été examiné de façon systématique ? ».
- Prix
- À partir de 1 490 € pour une application web, 1 290 € pour une API. Le prix monte avec le nombre de rôles, de parcours et le niveau de preuve.
- Durée
- 2 à 15 jours selon le périmètre
Ce que cela apporte
- Effort et couverture connus d’avance, donc budget prévisible.
- Rapport documentant ce qui a été testé, y compris les zones sans constat.
- Peut avoir lieu sur un environnement de préproduction ou avec des données de test.
- Intervenants contractuellement tenus à la confidentialité et au cadrage.
Ce que cela ne fait pas
- Limité en temps : les approches non envisagées par l’analyste échappent à la mission.
- Photographie datée, à renouveler après des évolutions.
- Un seul regard (celui de l’équipe affectée) sur la période.
Des chercheurs variés, payés au résultat, dans la durée.
Programme de bug bounty
Vous publiez un périmètre et un barème de primes, des chercheurs indépendants cherchent des failles et ne sont payés que pour celles qu’ils signalent et que vous validez. Il répond à « quelqu’un trouvera-t-il quelque chose que mes tests n’ont pas vu ? ».
- Prix
- À partir des primes que vous fixez, plus la plateforme éventuelle et surtout le temps interne de tri et de correction, qu’il faut budgéter.
- Durée
- Programme continu, sans fin définie
Ce que cela apporte
- Diversité d’approches et d’outils difficile à réunir dans une mission unique.
- Couverture dans la durée, y compris après chaque déploiement.
- Coût variable : vous payez les failles trouvées.
- Utile pour une application mature, déjà éprouvée, qui évolue en continu.
Ce que cela ne fait pas
- Aucune garantie de couverture : les chercheurs choisissent ce qui les intéresse, pas ce qui compte pour vous.
- Exige du temps interne pour trier les signalements, dédoublonner, répondre et corriger vite.
- Les failles de logique métier complexes sont souvent délaissées, car longues à comprendre.
- Expose votre application de production à des tests non encadrés par un contrat de mission.
Un verdict par ligne
La colonne de droite tranche. Quand les deux options se valent, elle le dit : c’est un résultat à part entière.
| Critère | Test d’intrusion | Programme de bug bounty | Avantage |
|---|---|---|---|
| Modèle économique | Prix fixe, effort connu à l’avance. | Paiement au résultat, coût imprévisible mais proportionné aux failles. | égal |
| Garantie de couverture | Périmètre et méthode contractuels, rapport de ce qui a été testé. | Aucune : chacun teste ce qu’il choisit. | Test d’intrusion |
| Diversité des approches | Une équipe, une méthode, sur une période courte. | Nombreux chercheurs aux méthodes différentes. | Programme de bug bounty |
| Failles de logique métier et de contrôle d’accès | Traitées avec des comptes de test dédiés. | Trouvées par hasard et par les chercheurs les plus investis. | Test d’intrusion |
| Surveillance dans la durée | Ponctuelle, à renouveler. | Continue, y compris après chaque mise en production. | Programme de bug bounty |
| Charge interne | Un référent et des comptes de test. | Tri, réponse rapide aux chercheurs, correction et arbitrage des primes en continu. | Test d’intrusion |
| Maturité requise de l’application | Aucune : c’est le bon point de départ. | Élevée : sinon les primes paient des défauts évidents. | Test d’intrusion |
Lequel dans votre situation
Prenez test d’intrusion si…
- Vous n’avez jamais fait tester l’application, ou pas depuis une évolution importante.
- Vous devez prouver à un client ou un auditeur qu’un périmètre précis a été examiné.
- Vous n’avez pas d’équipe disponible pour traiter des signalements entrants sous quelques jours.
- Vous voulez un budget connu à l’avance.
Prenez programme de bug bounty si…
- Votre application a déjà fait l’objet de plusieurs tests d’intrusion et ses constats sont corrigés.
- Vous déployez fréquemment et voulez une surveillance entre deux missions.
- Vous avez une équipe capable de trier, répondre et corriger rapidement.
- Vous êtes prêt à verser des primes significatives, sans lesquelles les meilleurs chercheurs ne viendront pas.
Et si la réponse était « les deux » ?
Le test d’intrusion vient en premier, le programme de primes ensuite. La mission cadrée nettoie les défauts de base et vérifie le contrôle d’accès. Le programme de primes prend le relais pour surveiller dans la durée et profiter de regards variés sur une application déjà solide. Un test d’intrusion annuel reste utile même avec un programme ouvert, parce que lui seul assure la couverture d’un périmètre.
Ce qu’on nous demande ensuite
Un bug bounty remplace-t-il un test d’intrusion ?
Non. Un programme de primes ne donne aucune assurance de couverture ni d’exhaustivité : les chercheurs testent ce qui les attire et se détournent souvent des failles de logique métier, longues à comprendre. Un test d’intrusion fixe un périmètre et une méthode, et documente ce qui a été testé. Les deux sont complémentaires, avec le test d’intrusion en premier.
Que faut-il prévoir en interne pour un programme de primes ?
Un propriétaire du programme, une procédure de tri et de dédoublonnage, un engagement de réponse rapide aux chercheurs, un circuit de correction avec les équipes de développement, et un budget de primes crédible. Sans cela, les chercheurs partent vite et les signalements s’accumulent. Le temps interne est le poste de coût le plus souvent sous-estimé.
Un programme de primes convient-il à une PME ?
Rarement en premier choix. Une PME dispose en général de peu de temps pour traiter des signalements entrants, et son application n’a pas toujours été éprouvée. Un test d’intrusion à périmètre réduit apporte plus de valeur par euro dépensé. Un programme peut devenir pertinent plus tard, quand l’application est mature et qu’une personne peut y consacrer du temps.
Prestations concernées
- PrestationPentest webSavoir ce qu’un attaquant obtiendrait sur votre application.
- PrestationPentest APILes API portent les données et moins de garde-fous que les interfaces.
- PrestationAudit de codeRetrouver la ligne de code responsable et la raison pour laquelle elle a été écrite.
Autres arbitrages
- ComparatifInterne ou externe ?Faire tester par l’équipe qui a construit le système, ou par un tiers. Le biais de l’équipe constructrice, le coût réel d’un recrutement offensif, et les cas où une équipe interne suffit.
- ComparatifScan ou pentest : le comparatifUn scan automatisé et un test d’intrusion portent des noms proches, mais ne répondent pas à la même question et ne coûtent pas le même prix. Critères, situations et erreur d’achat la plus fréquente.
Réponse à toute demande sous 24 h ouvrées
Un périmètre à faire tester ?
Le cadrage est gratuit et sans engagement. Trente minutes suffisent à savoir si une mission est pertinente, laquelle, et ce qu’elle coûterait.
- Accord de confidentialité systématique
- Cadrage gratuit et sans engagement
- Périmètre et prix écrits avant le début