Vulnerability Disclosure: CVD, VDP, Bug Bounty und Responsible Disclosure

Jeden Tag entdecken Sicherheitsforscher, Penetrationstester und gelegentlich auch gewöhnliche Nutzer Sicherheitslücken in Produkten und Diensten anderer Unternehmen. Im Jahr 2019 meldete ein Sicherheitsforscher eine kritische Schwachstelle in einem deutschen Online-Shop - das Unternehmen erstattete Strafanzeige wegen des Hackerparagraphen. Der Forscher wurde freigesprochen, aber der Fall zeigt: Ohne klare Vulnerability-Disclosure-Policy leben Sicherheitsforscher in rechtlicher Unsicherheit, und Unternehmen verpassen wertvolle Schwachstellen-Reports.

Die drei Offenlegungsmodelle

1. Full Disclosure (Sofortige Veröffentlichung)

Der Forscher veröffentlicht alle Details der Schwachstelle sofort - inklusive Exploit-Code - ohne vorher das betroffene Unternehmen zu kontaktieren.

Argument dafür: Maximaler Druck auf Hersteller, schnelle Öffentlichkeit schützt alle. Argument dagegen: Angreifer können Exploit sofort nutzen, bevor Patches verteilt werden.

Akzeptiert für: Systeme die bereits aktiv ausgenutzt werden ("0day in the wild"), wenn Vendor seit Jahren nicht reagiert.

2. Coordinated Vulnerability Disclosure (CVD) - der Standard

ISO/IEC 29147 und ISO/IEC 30111 definieren diesen Prozess international. Der Ablauf: Forscher entdeckt Schwachstelle und kontaktiert den Vendor (CERT, security@vendor.com, HackerOne). Der Vendor bestätigt die Schwachstelle idealerweise innerhalb von 7 Tagen. Es folgt eine gemeinsame Koordination der Behebung mit einer Standard-Frist von 90 Tagen. Nach der Patch-Entwicklung und -Verteilung wird eine CVE-Nummer vergeben, und Patch und Disclosure werden koordiniert gleichzeitig veröffentlicht.

3. Non-Disclosure (Geheimhaltung)

Schwachstelle wird vertraulich an Vendor gemeldet und nach Patch ohne Veröffentlichung geschlossen. Selten genutzt, z.B. für sehr kritische Infrastruktur.

VDP vs. Bug Bounty - Unterschied und Abgrenzung

Ein Vulnerability Disclosure Programme (VDP) ist ein formalisierter Prozess zur Meldung von Schwachstellen ohne finanzielle Vergütung (nur Anerkennung, Hall-of-Fame). Es definiert klar, was getestet werden darf, und schützt Sicherheitsforscher rechtlich. Jedes Unternehmen sollte ein VDP betreiben.

Ein Bug-Bounty-Programm ist ein VDP mit zusätzlicher finanzieller Vergütung für valide Findings (typisch 100 bis 100.000+ EUR je nach Schweregrad). Es zielt darauf ab, motivierte Forscher für intensiveres Testing zu gewinnen. Voraussetzung ist ein internes Security-Team für die Triage - ohne gute Triage wird das Programm zum Chaos. Typisches Budget: 50.000-200.000 EUR/Jahr plus 1-2 Personen für das Programm-Management.

Empfehlung: Mit einem VDP starten (kostenlos, geringer Aufwand). Zum Bug-Bounty-Programm wechseln, sobald ein internes Security-Team für die Triage vorhanden ist und Budget für Auszahlungen bereitsteht.

Die 90-Tage-Frist

Google Project Zero (Googles internes Security-Research-Team) popularisierte die 90-Tage-Frist: Wenn ein Vendor nach 90 Tagen keinen Patch veröffentlicht hat, publiziert Google die Details - auch ohne Patch.

Ergebnis: Deutliche Beschleunigung der Patch-Entwicklung bei großen Anbietern. Microsoft, Apple, Adobe - alle haben ihre Prozesse optimiert, um innerhalb von 90 Tagen reagieren zu können.

Ausnahmen: Bei aktiv ausgenutzten Zero-Days: 7 Tage. Bei besonders kritischer Infrastruktur: bis zu 120 Tage.

CVE - Common Vulnerabilities and Exposures

Jede öffentlich bekannte Schwachstelle bekommt eine standardisierte CVE-Kennung im Format CVE-[Jahr]-[fortlaufende Nummer]. Bekannte Beispiele: CVE-2024-3094 (XZ Utils Backdoor), CVE-2021-44228 (Log4Shell), CVE-2017-0144 (EternalBlue/WannaCry).

CVE-Vergabe: Über CVE Numbering Authorities (CNAs) - MITRE ist die Haupt-CNA, große Vendors sind selbst CNAs (Microsoft, Apple, Red Hat).

CVSS-Score: Jede CVE bekommt einen CVSS v3/v4-Score (0-10), der Schwere, Angriffskomplexität und Auswirkung quantifiziert.

Security.txt - Kontaktinformationen für Forscher

RFC 9116 standardisiert security.txt als maschinenlesbaren Kontaktpunkt für Sicherheitsforscher. Die Datei liegt unter https://www.example.com/.well-known/security.txt oder alternativ unter https://example.com/security.txt.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Contact: mailto:security@example.com
Contact: https://example.com/security
Expires: 2027-12-31T23:59:59.000Z
Encryption: https://example.com/pgp-key.txt
Acknowledgments: https://example.com/security/hall-of-fame
Preferred-Languages: de, en
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security/disclosure-policy

-----BEGIN PGP SIGNATURE-----
[PGP-Signatur]
-----END PGP SIGNATURE-----

Eine PGP-Signatur ist empfohlen: Forscher können die Authentizität prüfen, und gefälschte security.txt-Dateien (z. B. via Redirect-Angriff) werden erkannt. Signieren mit: gpg --clearsign security.txt. Prüfen mit: curl https://www.example.com/.well-known/security.txt oder dem Tool unter securitytxt.org/checker.

Warum security.txt wichtig ist:

Forscher wissen sofort, wohin Meldungen gehen
Keine Meldungen an falsche Adressen (support@, info@)
Zeigt Sicherheitsreife und Offenheit für externe Reports
BSI und CERT-Bund nutzen security.txt für automatisiertes Monitoring

VDP-Policy Erstellung

Eine vollständige VDP-Policy enthält vier Kernelemente:

1. Scope: Was darf getestet werden? In-Scope sind typischerweise Webanwendungen unter *.company.com, mobile Apps (mit App-IDs), API-Endpunkte und öffentlich erreichbare Infrastruktur. Explizit auszuschließen (Out-of-Scope): Drittanbieter-Software, physische Sicherheit, Social Engineering gegen Mitarbeiter, Denial-of-Service-Angriffe, Tests die andere Nutzer beeinflussen, und Sub-Processor/Drittanbieter. Ein unklarer Scope führt dazu, dass Forscher mehr testen als erwartet.

2. Safe Harbor Klausel: Der Kern jeder VDP. Das Unternehmen erklärt, dass es keine Strafanzeige nach §202a StGB erstattet, keine Zivilklage gegen VDP-konforme Aktivitäten einleitet und Behörden informiert, wenn Forscher die im Rahmen des VDP handeln kontaktiert werden. Die Safe Harbor gilt nur, wenn keine Daten exfiltriert werden, keine Systeme absichtlich beschädigt werden, nur In-Scope-Systeme getestet werden und der Report zeitnah nach Entdeckung gemacht wird.

3. Timeline-Erwartungen:

Phase	Frist
Acknowledgment	Innerhalb 72 Stunden
Initial Triage	Innerhalb 7 Tagen
Remediation CVSS 9-10 (Kritisch)	7 Tage
Remediation CVSS 7-8,9 (Hoch)	30 Tage
Remediation CVSS 4-6,9 (Mittel)	90 Tage
Remediation CVSS 0-3,9 (Niedrig)	180 Tage
Koordinierte Veröffentlichung	Nach Remediation, ggf. mit Forscher

4. Report-Anforderungen: Typ der Schwachstelle, betroffene URL/Endpunkt, Impact-Beschreibung, Schritt-für-Schritt-Reproduktion (PoC), optional Empfehlung zur Behebung, Kontaktdaten für Rückfragen.

Bug-Bounty-Plattformen

HackerOne: Marktführer mit 3.000+ Unternehmen und 500.000+ Forschern. Modelle: Private und Public Programme, Triage-as-a-Service, Pentest-on-demand. Kosten: 20.000+ EUR/Jahr Plattformgebühren plus Bounties. Bekannte Programme: Twitter, Uber, GitHub, US DoD, Lufthansa.
Bugcrowd: Konkurrenz zu HackerOne mit Fokus auf Enterprise und Government. Managed-Triage-Service "Crowdcontrol". Bekannte Programme: Tesla, Mastercard, Twilio.
Intigriti (Europäisch): DSGVO-konform mit Datenspeicherung in der EU, stark im DACH-Raum. Günstiger als US-Plattformen. Bekannte Programme: europäische Banken, Siemens, BMW. Empfehlung für EU-Unternehmen.
YesWeHack (Französisch): EU-basiert, DSGVO-konform. Bekannte Programme: OVHcloud, Société Générale. Gut für kleinere europäische Unternehmen.
Eigenes Programm (ohne Plattform): Keine Plattformgebühren, vollständige Kontrolle, aber kein Triage-Support, manuelle Bearbeitung und geringere Forscher-Reichweite. Geeignet für Startups und KMU mit wenig Budget.

Scope-Definition und Bounty-Struktur

Bei der Scope-Definition ist Vorsicht bei Wildcard-Definitionen geboten (z. B. "alle Domains die example.com gehören" - Akquisitionen können ungepatchte Systeme einbringen). IP-Ranges sollten explizit angegeben werden, und "Out of Scope" muss vollständig definiert sein.

Typische Auszahlungsstruktur:

Schweregrad	CVSS Score	Bounty-Range (Beispiel)
Kritisch	9,0-10,0	5.000-25.000+ EUR
Hoch	7,0-8,9	1.000-5.000 EUR
Mittel	4,0-6,9	250-1.000 EUR
Niedrig	0,1-3,9	100-250 EUR
Informational	-	kein Bounty (optional: Swag)

Häufige Report-Kategorien nach Schweregrad: Kritisch (RCE, SQL Injection mit Datenexfiltration, Auth-Bypass für Admin), Hoch (SSRF, IDOR mit sensiblen Daten, XSS auf Admin-Panel), Mittel (CSRF, fehlendes Rate-Limiting, Information Disclosure), Niedrig (fehlende Security Header, Self-XSS, Open Redirect). Nicht bounty-fähig sind typischerweise fehlende Security Header ohne Impact-Nachweis, CSRF auf Logout oder rein theoretische Schwachstellen ohne PoC.

Triage-Prozess

Der Triage-Workflow für eingehende Reports umfasst: automatische Eingangsbestätigung innerhalb 24-72h; Erstbewertung (in Scope? Duplikat? CVSS-Erstbewertung) innerhalb 5-7 Werktagen; interne Reproduktion und Impact-Verifizierung; Status-Update an den Reporter innerhalb 10 Werktagen; Patch-Entwicklung; Auszahlung; koordinierte Public Disclosure.

Ein guter Report enthält: betroffene URL/Endpunkt, Schritt-für-Schritt-Reproduktion, Beweis (Screenshot, HTTP-Request/Response, Video), Impact-Beschreibung (was kann ein Angreifer tun?) und optional einen Lösungsvorschlag. Schlechte Reports scheitern an fehlender Reproduzierbarkeit, fehlendem PoC oder daran, dass Out-of-Scope-Findings aus Scanner-Outputs eingereicht werden.

CVSS-Bewertungsvektoren: AV (Angriffs-Vektor: N=Netzwerk, A=Adjacent, L=Lokal, P=Physisch), AC (Komplexität: L=Low, H=High), PR (benötigte Rechte: N=Keine, L=Low, H=High), UI (Nutzerinteraktion: N=Keine, R=Erforderlich), S (Scope: U=Unchanged, C=Changed), C/I/A Impact (N=None, L=Low, H=High). Beispiel IDOR mit Datenzugriff: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N → 6,5 (Medium).

Escalation: CVSS 9-10 erfordert sofortigen Notfall-Patch und CTO-Information; CVSS 7-8,9 ein High-Priority-Ticket mit 30-Tage-Fix; CVSS 4-6,9 normale Sprint-Planung; CVSS 0-3,9 Backlog.

Hall of Fame und Forscher-Kommunikation

Eine Hall of Fame (z. B. https://example.com/security/acknowledgments) ist ein starker Motivationsfaktor für Sicherheitsforscher. Einträge enthalten Name/Handle, Jahr und Art des Findings.

Zur Kommunikation: Immer höflich reagieren, auch bei Duplikaten oder Out-of-Scope-Reports. Begründungen bei Ablehnung helfen Forschern zu verstehen. Status-Updates sind wichtig - Forscher nicht im Dunkeln lassen. Bei Fix proaktiv informieren und Auszahlungs-Timeline kommunizieren. Report-Ignoring ist inakzeptabel.

Weitere Incentive-Maßnahmen: Swag (T-Shirts, Sticker), CVE-Zuweisung (oft wertvoller für Forscher als Geld), Letter of Appreciation, Early-Access zu Beta-Features für Stammforscher.

Metriken und Programm-Gesundheit

Wichtige KPIs für VDP/Bug-Bounty-Programme:

Volumen: Total Reports/Monat, Anteil valider Findings, Duplikate-Rate (über 50% Duplikate deutet auf bekannte, ungelöste Probleme hin)
Qualität: Time to Triage, Time to Resolution, Resolution Rate
Budget: Durchschnittlicher Bounty, Kosten pro Finding, ROI ("Was hätte ein professioneller Pentest für diese Findings gekostet?")
Community: Aktive Forscher (letzte 90 Tage), Researcher Retention

Programm-Reifegrade: Level 1 (VDP mit Policy und E-Mail-Eingang), Level 2 (Triage-Prozess, 72h Acknowledgment), Level 3 (Plattform, Tracking), Level 4 (Bug Bounty mit monetärer Vergütung), Level 5 (Public Programm, Hall of Fame, CVE-Zuweisung).

Rechtliche Lage in Deutschland

Das Problem: §202a StGB

§202a StGB ("Ausspähen von Daten") ist breit formuliert: "Wer unbefugt sich oder einem anderen Zugang zu Daten verschafft, die nicht für ihn bestimmt und die gegen unberechtigten Zugang besonders gesichert sind..."

Theoretisch könnte ein Sicherheitsforscher, der eine Schwachstelle in einem fremden System entdeckt - selbst ohne böse Absicht - unter §202a fallen.

Testing mit ausdrücklicher Erlaubnis (Safe Harbor) ist nicht strafbar. Eine Safe-Harbor-Klausel in der VDP-Policy schafft eine rechtliche Grundlage für Forscher, ist aber keine absolute rechtliche Garantie. Empfehlungen: Einverständniserklärung und explizite Autorisierung einholen, Rechtsanwalt für IT-Recht bei der Policy-Erstellung einbeziehen.

Vulnerability Disclosure für eigene Systeme: Empfehlungen

Für Unternehmen:

security.txt einrichten (10 Minuten Aufwand)
Security@-E-Mail-Adresse einrichten (mit PGP-Key)
Interne Prozesse definieren: Wer erhält Meldungen? Wer entscheidet über Bestätigung/Patch-Priorität? Wer kommuniziert mit dem Forscher?
Acknowledgments-Seite ("Hall of Fame") einrichten - zeigt Wertschätzung
Realistische Reaktionszeiten kommunizieren (z.B. 7 Tage Bestätigung, 90 Tage Patch)
Grundbounty für kritische Findings einplanen (auch Kleinstprogramme möglich)

Für Sicherheitsforscher:

Scope des Unternehmens prüfen (gibt es Bug-Bounty-Programm?)
Nur auf erlaubten Systemen testen
Keine Daten exfiltrieren - nur Existenz der Schwachstelle beweisen
Schriftliche Dokumentation (Screenshot, Proof-of-Concept)
Per verschlüsselter E-Mail (PGP) an security@ oder CERT-Bund melden
Angemessene Frist abwarten (mindestens 90 Tage)