Bug Bounty oder Penetrationstest: Was brauchen Sie zuerst?

Sie haben in diesem Jahr Budget für genau eine ernsthafte offensive Sicherheitsmaßnahme, und zwei laute Lager erklären Ihnen, was Sie kaufen sollen. Das eine hält den Penetrationstest für die professionelle Grundausstattung. Das andere erklärt Bug-Bounty-Programme zum Standard moderner Unternehmen. Beide haben in Teilen recht, beide liegen für viele Teams falsch, und die Reihenfolge wiegt schwerer als die Wahl selbst.

Zwei Modelle, mechanisch grundverschieden

Ziehen Sie das Marketing ab, und es bleiben zwei völlig unterschiedliche Maschinen übrig. Wer sie verwechselt, zahlt am Ende Bounty-Triage-Kosten für Befunde, die ein Junior-Pentester am ersten Tag gefunden hätte.

Was ein Penetrationstest tatsächlich ist

Ein Pentest ist ein klar abgegrenztes, zeitlich begrenztes Projekt. Ein kleines Team (oft ein oder zwei Tester) greift ein definiertes Ziel in einem definierten Zeitfenster an, typischerweise ein bis drei Wochen, entlang einer Methodik wie PTES oder dem OWASP Web Security Testing Guide. Sie erhalten:

• Einen definierten Scope: konkrete Hosts, Anwendungen, APIs, IP-Bereiche, gelegentlich einen Cloud-Account oder ein internes Netzsegment.
• Methodische Abdeckung: Recon, Mapping, Tests von Authentifizierung und Session-Handling, Autorisierungsprüfungen für jede Rolle, Injection-Klassen, Missbrauch der Geschäftslogik, danach Exploitation und Post-Exploitation innerhalb vereinbarter Rules of Engagement.
• Einen Bericht mit Reproduktionsschritten, Schweregraden (üblicherweise CVSS plus kontextuelle Einordnung) und konkreten Empfehlungen zur Behebung.
• Ein Retest-Fenster, in dem die Korrekturen verifiziert werden.

Die entscheidende Eigenschaft: Die Abdeckung ist systematisch. Ein kompetenter Tester geht die gesamte Angriffsfläche im Scope durch, auch die unspektakulären Ecken, für die niemand auf eigene Rechnung jagen würde. Er testet jede Rolle gegen jeden Endpunkt auf fehlerhafte Autorisierung, jene Fehlerklasse, die wir in unserem Leitfaden zur API-Sicherheit im Detail behandeln, weil die Methodik es vorschreibt, nicht weil es sich finanziell lohnt.

Was ein Bug-Bounty-Programm tatsächlich ist

Ein Bounty ist ein stehendes Angebot: ein veröffentlichter Scope, eine Prämientabelle und Regeln, gehostet auf einer Plattform wie HackerOne, Bugcrowd oder Intigriti oder in Eigenregie betrieben. Hunderte oder Tausende unabhängige Researcher können sich Ihre Assets ansehen, wann immer sie wollen. Sie zahlen pro akzeptierter, eindeutiger Schwachstelle im Scope.

Die entscheidende Eigenschaft: Die Abdeckung ist ökonomisch, nicht systematisch. Researcher gehen dorthin, wo Geld und Trefferwahrscheinlichkeit locken. Beliebte Ziele werden auf wenigen hochdotierten Klassen regelrecht abgegrast (Account-Takeover-Ketten, SSRF auf Cloud-Metadaten, IDORs auf sensible Objekte), während ganze Subsysteme monatelang unberührt bleiben, weil sie nach wenig Ausbeute aussehen. Niemand schuldet Ihnen Abdeckung. Niemand unterschreibt ein Leistungsverzeichnis.

Was jedes Modell wirklich gut kann

Pentests gewinnen, wenn Sie Folgendes brauchen

• Nachweise und Prüfsicherheit. Auditoren, Enterprise-Kunden und Rahmenwerke wie ISO 27001, TISAX oder SOC 2 verlangen den Bericht einer benannten Firma mit nachvollziehbarer Methodik. Auch Art. 32 DSGVO fordert ein Verfahren zur regelmäßigen Überprüfung der Wirksamkeit Ihrer technischen Maßnahmen, und ein Bounty-Programm beantwortet keinen Due-Diligence-Fragebogen. Wenn Compliance der Treiber ist, beginnen Sie mit dem, was SOC 2 konkret verlangt.
• Abdeckung der unglamourösen Fläche. Interne Netze, Fat Clients, das Admin-Panel hinter dem VPN, fehlkonfiguriertes Active Directory. Researcher kommen dort nicht hin und würden sich den Aufwand meist auch nicht machen.
• Tiefe in der Geschäftslogik. Ein Tester, der drei Tage Ihren Rechnungsprozess studiert, findet den Erstattungsfehler mit negativer Stückzahl. Ein Researcher im Vorbeigehen in aller Regel nicht.
• Eine kalkulierbare Rechnung. Festpreis, feste Termine, definiertes Ergebnis. In der Beschaffung im DACH-Raum ist das oft die einzige Form, die durch den Einkauf und die Budgetplanung kommt.

Bounty-Programme gewinnen, wenn Sie Folgendes brauchen

• Kontinuierlichen Druck. Sie deployen täglich. Ein Pentest ist eine Momentaufnahme, Ihre Angriffsfläche ist ein Film. Mit einem Bounty steht potenziell jedes Deployment unter Beobachtung.
• Technische Vielfalt. Tausend Researcher bringen tausend Toolchains mit, kuriose Gerätefarmen, obskure Browser-Eigenheiten und neuartige Exploit-Ketten, die kein einzelner Dienstleister vorhält.
• Ein realistisches Signal zur Außenhaut. Bounty-Befunde zeigen, was ein opportunistischer Angreifer tatsächlich sieht, denn Researcher verhalten sich exakt so, nur ohne Straftat.
• Grenzkosten, die an echte Bugs gekoppelt sind. Keine validen Befunde, kaum Ausgaben jenseits der Plattformgebühren und Ihrer eigenen Triage-Zeit.

Wo jedes Modell scheitert

Das ist der Teil, den Anbieter gern überspringen.

Pentest-Fehlermodi

• Der Checklisten-Tester. Manche Anbieter lassen automatisierte Scanner laufen, formatieren die Ausgabe um und berechnen Beratungstagessätze. Verlangen Sie Beispielberichte, Namen und Zertifizierungen der Tester (OSCP, OSWE oder eine Historie aus CVEs und veröffentlichter Forschung) sowie eine ehrliche Angabe, wie viel Zeit manuell und wie viel Tooling ist.
• Verfall der Momentaufnahme. Der Bericht gilt exakt für den getesteten Commit. Zwei Sprints später beschreibt die Hälfte davon eine andere Anwendung.
• Scope-Theater. Nur die Marketing-Website zu testen, während die eigentliche Produkt-API außerhalb des Scopes liegt, produziert einen sauberen Bericht und null Sicherheit.
• Abbruch durch das Zeitfenster. Schwierige Bugs brauchen länger als das Projekt dauert. Ein Zweiwochenfenster kann genau dann enden, wenn die interessante Angriffskette kurz vor dem Durchbruch stand.

Bounty-Fehlermodi

• Kollaps des Signal-Rausch-Verhältnisses. Ein unvorbereitetes Programm wird begraben: Duplikate, Out-of-Scope-Meldungen, Scanner-Spam und Bettelprämien ("Ihr SPF-Record fehlt, zahlen Sie"). Nach unserer Erfahrung unterschätzen Teams die Triage-Last um ein Vielfaches.
• Bezahlen für bekannte Schulden. Wer ein Bounty auf eine ungetestete Anwendung startet, zahlt Marktpreise, Meldung für Meldung, für Bugs, die ein einziger Pentest zum Festpreis gesammelt aufgelistet hätte.
• Researcher-Vertrauen ist fragil. Langsame Antworten, heruntergestufte Schweregrade und unbezahlte Duplikate landen als Screenshot in der Community. Ein Programm mit schlechtem Ruf bekommt schwache Researcher und schlechtere Befunde.
• Rechtsrisiko bei schlampigen Regeln. Ohne klaren Safe Harbor und sauberen Scope laden Sie Tests ein, die Sie nie autorisiert haben, auf Systemen, die Sie nie exponieren wollten. Im DACH-Raum kommt hinzu: §202a ff. StGB in Deutschland und die Pendants in Österreich und der Schweiz stellen unbefugte Zugriffe unter Strafe, und sobald Researcher weltweit Produktivsysteme mit personenbezogenen Daten anfassen, sind DSGVO, Auftragsverarbeitung und der Hosting-Standort der Bounty-Plattform keine Fußnoten mehr.

Die Reifegradfrage, die niemand stellt

Die eigentliche Entscheidungsvariable ist nicht das Budget. Sie lautet: Kann Ihre Organisation einen Strom ungeprüfter externer Meldungen verarbeiten?

Ein Bounty-Programm ist ein Posteingang, der zu unvorhersehbaren Zeiten feuert, mit Behauptungen wechselnder Qualität, manche davon kritisch, und er schließt nie. Für den Betrieb brauchen Sie mindestens:

• Einen benannten Triage-Verantwortlichen mit Engineering-Kontext, keinen reinen Ticket-Verteiler.
• Eine vorab vereinbarte Schweregrad-Rubrik, damit Prämiendiskussionen nicht bei jeder Meldung zur Grundsatzdebatte werden.
• Ein Behebungs-SLA pro Schweregrad, denn eine bezahlte, aber nicht behobene kritische Schwachstelle ist der schlechteste aller Zustände.
• Einen Meldekanal, der wirklich funktioniert, beginnend mit einer security.txt:

# https://yourdomain.com/.well-known/security.txt
Contact: mailto:security@yourdomain.com
Policy: https://yourdomain.com/security/policy
Preferred-Languages: en, fr
Expires: 2027-06-01T00:00:00.000Z

Wenn beim Lesen dieser Liste jemand in Ihrem Team zusammengezuckt ist, sind Sie für ein öffentliches Bounty nicht bereit. Das ist normal. Die meisten Unternehmen sind es nicht, und die Lösung heißt Reihenfolge, nicht Verzicht.

Kostenmechanik, ehrlich gerechnet

Die Zahlen variieren stark nach Region, Scope und Anbieter. Lesen Sie das Folgende also als typische Größenordnungen, nicht als Angebot:

• Ein solider Pentest einer Webanwendung liegt üblicherweise als Festpreis im vier- bis fünfstelligen Eurobereich für ein bis drei Wochen Aufwand. Die Kosten skalieren mit der Komplexität des Scopes, nicht mit der Zahl der Befunde.
• Ein Bounty-Programm kostet Plattformgebühren plus Prämien. Einzelne Auszahlungen reichen üblicherweise von niedrigen dreistelligen Beträgen für valide Low-Severity-Befunde bis zu fünfstelligen Summen für kritische Schwachstellen bei reifen Programmen. Der versteckte Posten ist Engineering-Zeit: Triage, Reproduktion, Duplikatsdiskussionen und Fixes innerhalb des SLA.

Entscheidend ist die Fehlerrechnung. Wer ein Bounty auf ungehärtete Software startet, verwandelt einen fixen, gedeckelten Pentest-Preis in einen ungedeckelten Strom von Einzelprämien plus Reputationsrisiko. Wer bei einem schnell auslieferenden Produkt nur jährliche Pentests fährt, verwandelt kontinuierliche Exposition in ein einziges Foto pro Jahr. Die Schwäche des einen Modells ist die Stärke des anderen, und genau darum geht es.

Das Entscheidungsraster

Arbeiten Sie die Liste der Reihe nach ab und stoppen Sie bei der ersten zutreffenden Antwort.

1. Noch nie professionell offensiv getestet worden? Pentest zuerst. Ohne Ausnahme. Zahlen Sie nicht den Einzelpreis pro Bug für Befunde, die systematische Abdeckung im Paket liefert. Beginnen Sie mit wie ein echter Pentest von Anfang bis Ende abläuft.
2. Compliance- oder Kundenanforderung in den nächsten zwei Quartalen, etwa ISO 27001, TISAX, NIS2 oder ein Auditor mit Fragebogen? Pentest zuerst. Er ist das Artefakt, das der Prozess verlangt.
3. Kritische Angriffsfläche aus dem Internet nicht erreichbar? Pentest (intern oder als Assumed-Breach-Variante). Bounties sehen sie schlicht nicht.
4. Jährliche Pentests kommen weitgehend sauber zurück, Sie releasen wöchentlich, aber es gibt kein kontinuierliches Testen? Starten Sie jetzt ein Vulnerability Disclosure Program (VDP), danach ein bezahltes privates Bounty.
5. VDP läuft rund, Triage im Griff, kritische Befunde werden innerhalb des SLA behoben? Steigen Sie auf ein privates Bounty mit 20 bis 50 eingeladenen Researchern um.
6. Privates Bounty seit zwei oder mehr Quartalen stabil, Duplikatquote sinkt, Prämien kalkulierbar? Denken Sie über den Schritt in die Öffentlichkeit nach.
7. Bereits öffentlich? Behalten Sie trotzdem jährliche Pentests oder Tests pro Major-Release bei, gezielt auf das, was Bounties strukturell übersehen: neue Features vor dem Launch, interne Systeme, Cloud-Konfiguration und logiklastige Abläufe.

Den ersten Pentest richtig aufsetzen

Ein Pentest ist nur so gut wie sein Scoping. Bestehen Sie auf Folgendem:

• Scope auf die Kronjuwelen, nicht auf die Broschüre. Produktanwendung, APIs, Auth-Flows und der Cloud-Account kommen vor der Marketing-Website.
• Zugangsdaten für jede Rolle. Rein unauthentifiziertes Testen übersieht genau die Autorisierungsfehler, die reale Vorfälle dominieren. Stellen Sie Testkonten pro Berechtigungsstufe bereit.
• Grey-Box statt Black-Box beim ersten Engagement. Architekturdokumentation und notfalls Quellcode vervielfachen, was ein zeitlich begrenzter Tester erreicht. Sie kaufen Befunde, kein Realismus-Rollenspiel.
• Einen Retest im Vertrag. Ein Bericht ohne verifizierte Fixes ist ein Haftungsdokument.
• Befunde in Ihre Pipeline statt auf den PDF-Friedhof. Jeder Befund wird ein Ticket, und wiederkehrende Fehlerklassen werden automatisierte Checks in der CI, exakt der Kreislauf, den wir in Aufbau einer DevSecOps-Pipeline beschreiben.

Das erste Bounty richtig aufsetzen

Starten Sie privat, starten Sie eng, und schreiben Sie den Scope wie eine Firewall-Regel: explizit erlauben, standardmäßig verbieten. Prüfen Sie bei der Plattformwahl außerdem nüchtern, wo Meldungen und Daten gehostet werden und ob ein Auftragsverarbeitungsvertrag nach Art. 28 DSGVO vorliegt; für viele Unternehmen im DACH-Raum ist das ein Argument für einen europäischen Anbieter.

## In scope
- app.example.com (production web app)
- api.example.com/v2/* (public API)

## Out of scope
- *.staging.example.com
- Denial of service, rate limit reports
- Findings requiring physical access or social engineering
- Third-party services (report to the vendor)

## Rewards (guideline)
- Critical: $3,000 to $8,000
- High: $1,000 to $3,000
- Medium: $250 to $1,000
- Low: $0 to $250, at our discretion

Und dann halten Sie die operative Linie:

• Bestätigen Sie Meldungen schnell, idealerweise innerhalb von zwei Werktagen. Researcher verzeihen langsame Auszahlungen eher als Schweigen.
• Zahlen Sie bei Triage, nicht erst nach dem Fix. Einen Researcher auf Ihr Sprint-Planning warten zu lassen, ist die klassische Todesursache von Programmen.
• Veröffentlichen Sie eine Safe-Harbor-Erklärung, die gutgläubige Forschung ausdrücklich autorisiert. Mit Blick auf das deutsche Computerstrafrecht ist das keine Formalie, sondern die Voraussetzung dafür, dass seriöse Researcher überhaupt teilnehmen.
• Messen Sie Duplikatquote und Time-to-Triage als vollwertige Kennzahlen. Steigende Duplikate bedeuten: Ihre Fixes landen nicht oder Ihr Scope ist veraltet.

Die eigentliche Antwort: erst die Reihenfolge, dann beides

Auf die Frage, was zuerst kommt, gibt es für fast alle eine klare Antwort: Pentest zuerst, Bounty später, langfristig beides. Der Pentest räumt die angesammelten Sicherheitsschulden zum Festpreis ab und liefert das Artefakt, nach dem Ihre Kunden und Auditoren fragen. Das VDP und danach das Bounty halten den Druck auf alles, was Sie ausliefern, nachdem die Tester abgereist sind. Reife Sicherheitsprogramme behandeln den jährlichen Pentest als Tiefe und das Bounty als Breite und leiten beides in dieselbe Remediation-Pipeline, damit aus Befunden Regressionstests werden statt wiederkehrender Rechnungen.

Die Reihenfolge zu überspringen ist der teure Weg. Bounty-First-Teams bezahlen ihren Backlog öffentlich, Bug für Bug. Pentest-Only-Teams rahmen ein sauberes Foto, während der Film weiterläuft.

Wie Innovation T Sie unterstützt

Innovation T betreibt offensive Sicherheit so, wie dieser Artikel sie beschreibt: sauber gescopte Grey-Box-Penetrationstests mit Zugangsdaten für jede Rolle und vertraglich zugesichertem Retest, danach der Aufbau von VDP und privatem Bounty, sobald Ihre Triage-Prozesse tragen. Wir bauen auch den Remediation-Kreislauf und verdrahten Befunde mit der CI, damit behobene Fehlerklassen behoben bleiben. Einen Überblick geben unsere Security- und Engineering-Leistungen.

Wenn Sie auf eine Compliance-Deadline starren, auf einen Kundenfragebogen oder auf ein Produkt, das noch nie professionell angegriffen wurde: Sprechen Sie mit uns. Wir sagen Ihnen ehrlich, welches Engagement Sie zuerst brauchen und welches warten kann.