Je bent aan het rondklikken op een bekende Nederlandse webshop en je ziet iets dat niet klopt. Een URL-parameter die je kunt aanpassen, een formulier dat meer invoer accepteert dan het zou mogen. Het eerste instinct van veel mensen is: venster sluiten en doorgaan met je dag. Maar er is een andere optie: het melden via een bug bounty programma en er mogelijk honderden tot duizenden euro’s voor ontvangen. Hoe zo’n programma precies werkt, wat je realistisch kunt verdienen en wanneer je juist níet wordt uitbetaald, leggen we hieronder stap voor stap uit.
Van lek naar uitbetaling: een concreet voorbeeld
Neem een veelvoorkomend scenario: een beveiligingsonderzoeker ontdekt een cross-site scripting (XSS)-kwetsbaarheid op de inlogpagina van een Nederlandse bank. Via een slim samengestelde URL kan een aanvaller kwaadaardige code uitvoeren in de browser van een nietsvermoedende bezoeker. De onderzoeker meldt dit netjes via het officiële programma van de bank, inclusief een reproductiestap en een proof-of-concept.
Wat er daarna gebeurt: het securityteam van de bank bevestigt het lek, beoordeelt de ernst (in dit geval ‘hoog’) en kent een beloning toe van bijvoorbeeld 750 euro. Betaling volgt binnen dertig dagen. Simpel? In theorie wel. In de praktijk zijn er best wat hobbels te nemen.
Hoe een bug bounty programma is opgebouwd
Elk programma heeft een eigen structuur, maar de basisonderdelen zijn vrijwel overal hetzelfde. Ten eerste is er de scope: welke systemen, domeinen of apps mag je testen? Dit is cruciaal. Buiten scope testen kan je melding ongeldig maken, en in het ergste geval juridische consequenties hebben.
Daarnaast zijn er de regels: geen DDoS-aanvallen, geen social engineering van medewerkers, geen data van echte gebruikers inzien. Vervolgens is er de beloningsstructuurvaak gekoppeld aan de ernst van een kwetsbaarheid, oplopend van P4 (laag) tot P1 (kritiek). En dan het onderscheid tussen publieke en private programma’s. Publieke programma’s zijn voor iedereen toegankelijk. Private programma’s zijn op uitnodiging en bevatten vaak interessantere doelwitten met hogere uitbetalingen.
De grote platforms vergeleken
Er zijn drie platforms die er echt toe doen voor Nederlandse onderzoekers.
- HackerOne is het grootste platform ter wereld. Veel grote techbedrijven en overheidsorganisaties werken hier mee. Aanmelden is gratis; je reputatie bouw je op via meldingen.
- Bugcrowd is het Amerikaanse alternatief, sterk in financiële sector en zakelijke software. Iets minder groot, maar met een actieve community.
- Intigriti is de Europese speler, opgericht in België en sterk gericht op de Europese markt. Wij van Techguide.nl zien dit platform steeds vaker opduiken bij Nederlandse bedrijven en overheidsinstanties. Als je hier wilt beginnen met Europese programma’s, is Intigriti een logische eerste keuze.
Verschillende Nederlandse organisaties, waaronder overheidsdiensten via de Responsible Disclosure richtlijnen van het NCSC, zijn te vinden op Intigriti of hebben eigen programma’s.
Wat bedrijven werkelijk uitkeren
Eerlijk is eerlijk: de bedragen variëren enorm. Hieronder een indicatief overzicht van typische beloningsranges per ernstniveau.
| Ernstniveau | Omschrijving | Google (bij benadering) | Gemiddeld NL-bedrijf |
|---|---|---|---|
| P1 (Kritiek) | Remote code execution, volledige accountovername | €15.000 tot €150.000+ | €1.000 tot €5.000 |
| P2 (Hoog) | Ernstige datalekken, auth-bypass | €5.000 tot €15.000 | €500 tot €1.500 |
| P3 (Middel) | XSS, CSRF zonder directe impact | €500 tot €5.000 | €100 tot €500 |
| P4 (Laag) | Informatielekken, verouderde headers | €100 tot €500 | €0 tot €100 (of alleen een bedankje) |
Microsoft en Meta zitten qua uitbetalingen ergens tussen Google en een gemiddeld Nederlands bedrijf in. Sommige Nederlandse organisaties betalen geen geld maar bieden swag of publieke erkenning. Goed om te weten voordat je uren investeert.
Wat telt als geldig lek, en wat niet
Dit is waar veel beginners de mist in gaan. Veelgemaakte fouten zijn onder andere het melden van een kwetsbaarheid die buiten de scope valt, een lek dat al eerder door iemand anders is gemeld (duplicate), of een rapport zonder duidelijke reproductiestappen. Ook ’theoretische’ kwetsbaarheden zonder bewijs van impact worden regelmatig afgewezen.
Niet geldig zijn ook: het melden van verouderde softwareversies zonder aangetoonde exploitbaarheid, of het rapporteren van ontbrekende best-practice-headers die geen directe veiligheidsgevolgen hebben. Lees altijd eerst de programmaregels, dan de scope, en dan pas ga je testen.
Hoe een goed rapport eruitziet
Een sterke melding bevat een duidelijke titel die het probleem direct beschrijft, een stapsgewijze beschrijving van hoe het lek te reproduceren is, een proof-of-concept (screenshot, video of code), en een uitleg van de impact: wat kan een aanvaller hiermee doen?
Een zwak rapport zegt iets als: ‘Ik heb een XSS gevonden op jullie site, zie bijlage.’ Geen stappen, geen context, geen impact. Zo’n rapport belandt vrijwel zeker in de prullenbak, ongeacht hoe serieus het lek is. Een goed rapport schrijven kost tijd, maar het is het verschil tussen uitbetaling en afwijzing.
Realistisch beeld voor beginners
Laten we eerlijk zijn: de eerste maanden zijn frustrerend. Je zoekt, vindt weinig, en wat je vindt blijkt al gemeld. Hobbyisten die er tien uur per week in stoppen, verdienen gemiddeld een paar honderd euro per maand, als ze geluk hebben. Velen verdienen de eerste tijd helemaal niets.
Het wordt interessanter zodra je een specialisme opbouwt. Denk aan een focus op API-kwetsbaarheden, of expertise in een specifiek framework. Mensen die er structureel geld mee verdienen, doen dit voltijds of bijna voltijds, en hebben vaak honderden uren achter de rug. Een realistische verwachting voor een beginner: na zes maanden consistent oefenen je eerste echte uitbetaling ontvangen. Niet eerder verwachten, niet opgeven na drie maanden.
Juridische en ethische grenzen
Een bug bounty programma biedt bescherming, maar die bescherming is niet onbeperkt. Zolang je binnen de scope blijft, je geen data downloadt die je niet nodig hebt, en je een melding doet via de officiële kanalen, sta je juridisch sterk. Ga je buiten scope, dan kun je ondanks goede bedoelingen toch in de problemen komen. In Nederland valt dit onder de Wet Computercriminaliteit, en ‘ik wilde het alleen maar melden’ is geen waterdicht verweer als je systemen hebt benaderd die buiten het programma vallen.
Werk je met een bedrijf dat geen formeel programma heeft, dan is responsible disclosure de route: melden, een redelijke termijn geven om te fixen, en daarna eventueel publiceren. Het NCSC heeft hiervoor een leidraad gepubliceerd die je als houvast kunt gebruiken.
Bug bounty programma’s zijn geen snelle bijverdienste, maar voor wie technische kennis heeft en bereid is de regels serieus te nemen, is het een concrete manier om die kennis te laten renderen. Wij van Techguide.nl raden aan om klein te beginnen: kies één platform, lees de scope-documenten zorgvuldig en schrijf je eerste rapport zo gedetailleerd mogelijk. Een kleine uitbetaling bij je eerste succesvolle melding is een reëler doel dan meteen een kritieke kwetsbaarheid proberen te vinden. De meeste ervaren bug bounty hunters bouwden hun reputatie op door jarenlang consistent te rapporteren, niet door geluk.
