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.

CVD-Ablauf:

Forscher entdeckt Schwachstelle
        ↓
Forscher kontaktiert Vendor (CERT, security@vendor.com, HackerOne)
        ↓
Vendor bestätigt Schwachstelle (idealerweise < 7 Tage)
        ↓
Gemeinsame Koordination der Behebung
        ↓
Patch wird entwickelt und verteilt (90 Tage Standard-Frist)
        ↓
CVE-Nummer wird vergeben
        ↓
Koordinierte Veröffentlichung: Patch + Disclosure gleichzeitig

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

Vulnerability Disclosure Programme (VDP):
  Definition: Formalisierter Prozess für Meldung von Schwachstellen
  Vergütung: KEINE (nur Anerkennung, Hall-of-Fame)
  Ziel: Sicherheitsforscher schützen + Schwachstellen erhalten
  Scope: klar definiert was getestet werden darf
  Richtig für: alle Unternehmen ab sofort!

Bug-Bounty-Programm:
  Definition: VDP + finanzielle Vergütung für valide Findings
  Vergütung: 100 - 100.000+ EUR je nach Severity
  Ziel: Motivierte Forscher für intensiveres Testing gewinnen
  Richtig für: Wenn internes Security-Team vorhanden (Triage-Ressourcen!)
  Vorsicht: Ohne gute Triage → Programm wird zum Chaos

Wann welches:
  Start: VDP (kostenlos, geringer Aufwand)
  Wachstum: VDP → Bug Bounty wenn:
  □ Internes Security-Team für Triage vorhanden
  □ Budget für Auszahlungen (50.000-200.000 EUR/Jahr typisch)
  □ Programm-Management-Ressourcen (1-2 Personen)

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:

CVE-2024-3094  → XZ Utils Backdoor (2024)
CVE-2021-44228 → Log4Shell (2021)
CVE-2017-0144  → EternalBlue (WannaCry, 2017)

Format: CVE-[Jahr]-[fortlaufende Nummer]

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 - security.txt:

Speicherort (laut RFC):
  https://www.example.com/.well-known/security.txt
  https://example.com/security.txt  (alternativ)

Vollständige security.txt mit PGP-Signatur:
  -----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-----

Wichtig: PGP-Signatur empfohlen!
  → Forscher kann Authentizität prüfen
  → Verhindert gefälschte security.txt (Redirect-Angriff)
  → gpg --clearsign security.txt

Security.txt prüfen:
  curl https://www.example.com/.well-known/security.txt
  # Tool: 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

Elemente einer vollständigen VDP-Policy:

1. Scope (Was darf getestet werden?):

   IN SCOPE:
   → Webanwendungen unter *.company.com
   → Mobile Apps (iOS App Store / Google Play Store - App IDs angeben!)
   → API-Endpunkte: api.company.com
   → Öffentlich erreichbare Infrastruktur

   OUT OF SCOPE (explizit ausschließen!):
   → Drittanbieter-Software (WordPress-Core, etc.)
   → Physische Sicherheit
   → Social Engineering gegen Mitarbeiter
   → Denial-of-Service-Angriffe
   → Tests die andere Nutzer beeinflussen!
   → Sub-Processor/Drittanbieter: EXPLIZIT ausschließen!

   Wichtig: Unklar formulierter Scope = Forscher testet mehr als erwartet!

2. Safe Harbor Klausel (Kern des VDP):

   Mustertext:
   "COMPANY erkennt an dass Sicherheitsforschung wichtig ist.
   Wenn Sie unsere Richtlinie in gutem Glauben befolgen, wird COMPANY:

   - Keine Strafanzeige wegen §202a StGB oder ähnlicher Gesetze erstatten
   - Keine Zivilklage wegen VDP-konformer Aktivitäten einleiten
   - Behörden informieren wenn wir nach VDP handelnde Forscher kontaktiert werden
   - Sicherstellen dass unsere zuständigen Parteien wissen dass Sie im Rahmen VDP handeln

   Diese Safe Harbor gilt NUR wenn:
   → Keine Daten exfiltriert werden (nur Nachweis der Schwachstelle)
   → Keine Systeme absichtlich beschädigt werden
   → Nur in-scope Systeme getestet werden
   → Report so schnell wie möglich gemacht wird nach Entdeckung"

3. Timeline-Erwartungen:

   Acknowledgment:    Innerhalb 72 Stunden
   Initial Triage:    Innerhalb 7 Tagen
   Remediation:       CVSS 9-10 (Kritisch): 7 Tage
                      CVSS 7-8.9 (Hoch): 30 Tage
                      CVSS 4-6.9 (Mittel): 90 Tage
                      CVSS 0-3.9 (Niedrig): 180 Tage
   Koordinierte Veröffentlichung: nach Remediation, ggf. mit Forscher

4. Report-Anforderungen:
   □ Typ der Schwachstelle (z.B. SQL Injection, SSRF)
   □ Betroffene URL / Endpunkt
   □ Impact-Beschreibung
   □ Schritt-für-Schritt-Reproduktion (Step-by-step, PoC)
   □ Optional: Empfehlung zur Behebung
   □ Eigene Kontaktdaten (für Rückfragen)

Bug-Bounty-Plattformen

HackerOne:
  Marktführer: 3.000+ Unternehmen, 500.000+ Forscher
  Modelle: Private Programm + Public Programm
  Features: Triage-as-a-Service, Pentest-on-demand
  Kosten: 20.000+ EUR/Jahr Plattformgebühren + Bounties
  Bekannte Programme: Twitter, Uber, GitHub, DOD (US Government), Lufthansa

Bugcrowd:
  Konkurrenz zu HackerOne, Fokus: Enterprise + Government
  Crowdcontrol: Managed-Triage-Service
  Bekannte Programme: Tesla, Mastercard, Twilio

Intigriti (Europäisch):
  DSGVO-konform: Daten in EU gespeichert
  Stark im DACH-Raum und UK
  Kosten: günstiger als US-Plattformen
  Bekannte Programme: Europäische Banken, Siemens, BMW
  Empfehlung für EU-Unternehmen!

YesWeHack (Französisch):
  EU-basiert, DSGVO
  Bekannte Programme: OVHcloud, Société Générale
  Gut für kleinere europäische Unternehmen

Eigenes Programm (ohne Plattform):
  Vorteile: keine Plattformgebühren, vollständige Kontrolle
  Nachteile: kein Triage-Support, manuelle Bearbeitung, weniger Forscher-Reichweite
  Geeignet für: Startups, KMU mit wenig Budget

Scope-Definition und Bounty-Struktur

Scope richtig definieren:

Asset-Typen:
  Wildcard: *.example.com (alle Subdomains, inklusive!)
  Spezifisch: api.example.com (nur dieser Subdomain)
  Mobile: iOS App "com.example.app"
  Binaries: API-Client, Desktop-Anwendung

Scope-Tipps:
  → Vorsicht mit "alle Domains die example.com gehören"!
    → Akquisitionen können ungepatchte Systeme einbringen
  → IP-Ranges explizit angeben wenn getestet werden darf
  → "Out of Scope" explizit und vollständig definieren

Auszahlungsstruktur (Bounty Table):

  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:
  → Kritisch: RCE, SQL Injection mit Daten-Exfiltration, Auth-Bypass für Admin
  → Hoch: SSRF, IDOR mit sensiblen Daten, XSS auf Admin-Panel
  → Mittel: CSRF, Rate-Limiting fehlt, Information Disclosure
  → Niedrig: Missing Security Headers, Self-XSS, Open Redirect
  → OOS: CVSS-basierte Bugs ohne Impact-Beweis, SPF-Konfiguration allein

Nicht-bounty-fähige Reports (häufig):
  → "Security Header fehlt" ohne Impact-Nachweis
  → "SSL 3.0 verfügbar" (wenn kein echter Angriff demonstriert)
  → CSRF auf Logout
  → "Passwort kann 6 Zeichen kurz sein" (Low, nicht Hoch)

Triage-Prozess

Eingehende Reports bearbeiten:

Triage-Workflow:
  1. Eingangsbestätigung (automatisch, innerhalb 24-72h)
  2. Erstbewertung (5-7 Werktage):
     → Ist der Report verständlich? (Reproduzierbar?)
     → In Scope?
     → Dupliziert? (schon bekannt?)
     → Erstbewertung CVSS
  3. Reproduktion (intern):
     → Sicherheitsthema in Testumgebung nachstellen
     → Impact verifizieren
  4. Status-Update an Reporter (10 Werktage)
  5. Patch-Entwicklung (intern)
  6. Auszahlung (nach Patch oder direkt)
  7. Public Disclosure (koordiniert)

Report-Qualitätskriterien:
  Guter Report enthält:
  □ Betroffene URL/Endpunkt
  □ Schritt-für-Schritt-Reproduktion
  □ Beweis (Screenshot, HTTP-Request/Response, Video)
  □ Impact-Beschreibung (was kann Angreifer tun?)
  □ Suggested Fix (nicht Pflicht, aber wertvoll)

  Woran schlechte Reports scheitern:
  → "Ihre Website ist unsicher" (kein konkreter Fund)
  → Missing Steps to Reproduce
  → Theoretische Schwachstelle ohne PoC
  → Out-of-Scope (Scanner-Output eingereicht)

CVSS-Bewertung:
  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-Matrix:
  CVSS 9-10: SOFORT! Notfall-Patch, CTO informieren
  CVSS 7-8.9: High-Priority-Ticket, 30-Tage-Fix
  CVSS 4-6.9: Normal-Ticket, Sprint-Planung
  CVSS 0-3.9: Backlog, nächster Maintenance-Zyklus

Schwierige Report-Typen:
  "Informational" (eigentlich kein Bug):
  → SPF-Record nicht vorhanden → kein direkter Exploit → Informational
  → HTTP-Header-Empfehlung → Informational
  → Aktion: schließen mit Erklärung, kein Bounty

  Out-of-Scope:
  → Drittanbieter-Software, physisch, DoS
  → Aktion: schließen + erklären warum out-of-scope

Hall of Fame und Forscher-Kommunikation

Forscher-Beziehungen pflegen:

Hall of Fame:
  → Sicherheitsforscher sind stolz auf ihre Findings
  → Hall of Fame = starker Motivationsfaktor
  → Eigene Seite: https://example.com/security/acknowledgments
  → Eintrag: Name/Handle + Jahr + Art des Findings

Kommunikation:
  → Immer höflich, auch bei Duplikaten oder OOS-Reports
  → Begründung bei Ablehnung (Forscher wollen verstehen!)
  → Status-Updates: Forscher nicht im Dunkeln lassen
  → Bei Fix: proaktiv informieren + Auszahlung-Timeline
  □ Niemals: Report ignorieren, keine Antwort geben!

Incentive-Programme:
  → Swag (T-Shirts, Sticker): günstig, Forscher freuen sich
  → CVE-Zuweisung: wertvoller für Forscher als Geld!
  → Letter of Appreciation (für Forscher ohne Bounty-Anspruch)
  → Early-Access zu Beta-Features: besonders für Stammforscher

Metriken und Programm-Gesundheit

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

Volumen-Metriken:
  Total Reports: Eingehende Reports/Monat
  Valid Findings: % der Reports die echt + in-scope sind
  Duplicates: % doppelte Reports (>50% Duplikate → bekanntes Problem!)

Qualitäts-Metriken:
  Time to Triage: Stunden von Report bis Triage-Entscheidung
  Time to Resolution: Tage von Bestätigung bis Fix
  Resolution Rate: % der Findings die behoben wurden

Budget-Metriken:
  Average Bounty: Ø Auszahlung pro Finding
  Cost per Finding: Gesamtkosten / Anzahl valider Findings
  ROI: "Was hätte ein professioneller Pentest für diese Findings gekostet?"

Community-Metriken:
  Active Researchers: Forscher die zuletzt 90 Tage aktiv waren
  Researcher Retention: Kommen Top-Forscher zurück?

Programm-Reifegrade:
  Level 1 (VDP): Policy vorhanden, E-Mail-Eingang
  Level 2: Triage-Prozess, 72h Acknowledgment
  Level 3: Plattform (HackerOne/Intigriti), Tracking
  Level 4: Bug Bounty, monetäre Vergütung
  Level 5: Private → Public Programm, Hall of Fame, CVEs

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.

Rechtslage Deutschland zusammengefasst:
  Hackerparagraph §202a StGB: "Ausspähen von Daten"
  → Strafbar: Umgehen von Zugangssicherung ohne Berechtigung
  → NICHT strafbar: Testing mit ausdrücklicher Erlaubnis (Safe Harbor)
  → Safe-Harbor-Klausel in VDP-Policy = rechtliche Grundlage für Forscher!

  Wichtig:
  → Safe Harbor in Policy ist KEINE rechtliche Garantie!
  → Empfehlung: Einverständniserklärung + explizite Autorisierung
  → Rechtsanwalt für IT-Recht bei Policy-Erstellung einbeziehen!
  → BugBounty DE: Zusammenschluss deutscher Unternehmen für klare Rahmenbedingungen

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? (Sicherheitsverantwortlicher)
- Wer entscheidet über Bestätigung/Patch-Priorität?
- Wer kommuniziert mit dem Forscher?
Acknowledgments-Seite (“Hall of Fame”) - 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)