Zum Inhalt springen
Financial Context Wiki

Funktionsweise von Krypto-Bug-Bounty-Programmen

Ein Krypto-Bug-Bounty ist ein versioniertes Melde- und Prämienverfahren, dessen Umfang, Autorisierung, Belege, Schweregrad, Behebung, Offenlegung und Zahlungsbedingungen getrennt geprüft werden müssen.

Aktualisiert

Nur zu Bildungszwecken; keine Rechts-, Steuer- oder Sicherheitsberatung. Ein veröffentlichtes Programm, eine Safe-Harbor-Erklärung, eine Schweregradeinstufung oder eine geschätzte Prämie garantiert weder Autorisierung noch Immunität, Zahlung oder Protokollsicherheit.

Direkte Antwort

Ein Krypto-Bug-Bounty ist ein versioniertes Verfahren, in dem ein Projekt zur vertraulichen Meldung bestimmter Schwachstellen einlädt und regelkonforme Berichte vergüten kann. Es ist keine Vulnerability Disclosure Policy: Diese kann einen Meldeweg und Autorisierungsbedingungen ohne Zahlungszusage bereitstellen. Keines von beiden ist Zertifikat, Versicherung, Arbeitsverhältnis oder Sicherheitsnachweis.

Maßgeblich ist ein gespeicherter Programmstand, nicht der Projektname oder die heutige Website. Festzuhalten sind URL, Revision und Zeitpunkt; genaue Chains, Verträge, Proxy-Implementierungen, Repositories, Commits und Releases; zulässige Auswirkungen; ausgeschlossene Systeme und Methoden; Prämientabelle und Obergrenze; Melde- und Offenlegungsregeln; Safe-Harbor-Text sowie Identitäts-, Sanktions-, Steuer- und Zahlungsbedingungen. Der Umfang ist die Schnittmenge aus Asset, Version, Chain, Auswirkung und erlaubter Testmethode.

Safe Harbor beschreibt, wie eine Organisation regelkonforme Forschung nach Treu und Glauben behandeln will. Er erweitert nicht den Umfang, bindet keine Dritten oder Behörden, setzt andere Rechtsordnungen nicht außer Kraft und entschuldigt weder Datenschutzverletzung, Störung, Erpressung noch unbefugte Geldbewegung. Bei Unklarheit ist vor dem Test über den offiziellen Kanal nachzufragen.

Vier Register sind getrennt zu führen: Autorisierung und Belege; technische Ausnutzbarkeit und wirtschaftliche Auswirkung; Eindämmung, Behebung und Offenlegung; Prämie, Compliance und Zahlung. Die Einstufung critical bestimmt nicht allein die Prämie, eine Prämienentscheidung ist kein Zahlungsbeleg und ein bestandener Unit-Test beweist nicht die Sicherheit des betroffenen Deployments.

Funktionsweise

Tests müssen innerhalb der gespeicherten Regeln bleiben. Ein minimaler PoC führt gewöhnlich von statischer Analyse und Unit- oder Property-Tests zu einem lokalen Fork oder ausdrücklich erlaubten Umfeld. Mainnet-, öffentliche Testnet-, DoS-, Social-Engineering-, Drittanbieter- oder personenbezogene Datentests können verboten sein. Reale Nutzerwerte dürfen nicht als Wirkungsnachweis bewegt oder behalten werden; ein gewöhnliches Bounty autorisiert keine Rettung während eines laufenden Angriffs.

Ein belastbarer Bericht fixiert Chain, Adresse, Implementierung, Commit, State-Block und Programmstand. Er nennt Voraussetzungen, genaue Reproduktion, Soll- und Istverhalten, Transaktions- oder Calldata-Folge, Artefakt-Hashes, technischen Pfad, realistische Wirkungsgrenze, Kapital und Rechte des Angreifers, Annahmen und sicheren Kontakt. Gefährliches Material und sensible Daten sind zu verschlüsseln, Erhebung und Zugriffe zu minimieren und chronologisch zu dokumentieren.

Die Triage trennt Umfang, Duplikat oder bekanntes Problem, Ausnutzbarkeit, wirtschaftliche Auswirkung, Schweregrad und Prämienfähigkeit. Eine technische Klasse bestimmt keinen ausführbaren Verlust. Kapital, Rechte, Konkurrenz, Liquidität, Oracle-Fenster, Limits, Pausen, Reorg-Risiko, Wiederholbarkeit und Nutzerinteraktion verändern das Ergebnis. Nicht zwingend die erste Nachricht ist der erste vollständige zulässige Bericht; maßgeblich sind gespeicherte Duplikatregel und Beleg der Vorkenntnis.

Eingangsbestätigung, Reproduktion, Schweregradentscheidung, Sofortmaßnahme, endgültige Behebung, Offenlegung, Prämienfreigabe und Zahlung sind verschiedene Zustände und Uhren. Ziele wie 24 hours oder 72 hours gelten nur, wenn Programm oder Incident-Plan sie definieren. Schweigen schadet operativ; ein universelles Zeitlimit folgt daraus nicht.

Eine Sofortmaßnahme kann Funktion pausieren, Limit senken, Frontend-Route entfernen oder Monitoring ändern, ist aber keine endgültige Lösung. Ein Upgrade prüft Autorisierung, Timelock oder Notfallrechte, Implementierung und Initializer, Storage-Layout, Migration und Rollback. Der PoC wird zum Regressionstest; benachbarte Pfade und Invarianten, Deployment-Zustand, Ausführungsbelege und alle betroffenen Chain-Versionen sind zu prüfen.

Offenlegung braucht privaten Kanal, Embargobeginn, Update-Rhythmus, Verlängerungs- und Notfallregeln, Namensnennung oder Anonymität sowie Aufbewahrung oder Löschung von Belegen. Die Zahlung wird separat abgestimmt: Nominalprämie, Formel oder Ermessen, Währung und Wechselkursstichtag, KYC oder Sanktionen, Steuerunterlagen oder Einbehalt, Ziel-Chain und -Adresse, Gebühren, Freigabe, Transaktionskennung und Eingang.

Vorgehen:

  1. Programmstand mit URL, Revision, Zeitpunkt, Assets, Chains, Adressen, Implementierungen, Commits, zulässigen Auswirkungen, Ausschlüssen, Prämienbedingungen, Safe Harbor und Offenlegung speichern.
  2. Schriftliche Autorisierung für Akteur, System, Umfeld, Methode, Rate, Datenverarbeitung und Drittgrenze einholen; bei Unklarheit stoppen und fragen.
  3. Kleinsten unschädlichen PoC im erlaubten Umfeld erstellen, Code und Zustand fixieren, Voraussetzungen und Auswirkung quantifizieren und bei ausreichendem Beleg stoppen.
  4. Über den sicheren autorisierten Kanal mit ID, Zeiten, verschlüsselten Artefakten, Hashes, Reproduktion, Wirkungsregister, Annahmen und Kontakthistorie melden.
  5. Umfang und Duplikat- oder Bekanntstatus bestimmen; Ausnutzbarkeit, wirtschaftliche Auswirkung, Schweregrad und Prämienfähigkeit getrennt nach gespeicherten Regeln bewerten.
  6. Eindämmung, Patch oder Migration, Upgrade- und Storage-Prüfung, Regression und Invarianten, Deployment-Belege, Monitoring und koordinierte Offenlegung getrennt verfolgen.
  7. Freigegebene Prämie, Währung und Kurs, KYC, Sanktionen, Steuern, Chain, Adresse, Gebühren und Zahlungseingang abstimmen; prüfbare Spur ohne unnötige sensible Daten bewahren.

Beispiele

  • Umfang ist enger als Namensgleichheit. Ein Stand nennt 12 assets, der Bericht 9; nur 7 stimmen mit Chain und Deployment-Version überein, ein Oracle ist Drittanbieter und ein Commit unveröffentlicht. Namensabdeckung: 9 / 12 = 75%; autorisierte Abdeckung: 7 / 12 = 58.33333333%. Der Stand, nicht die Quote, entscheidet.
  • Auswirkung, Schweregrad und mögliche Prämie sind verschieden. Reproduzierbarer Direktwert im Risiko: $8,000,000. Eine hypothetische gespeicherte Regel zahlt 10%, mindestens $50,000, höchstens $500,000. Roh: $8,000,000 * 0.10 = $800,000; nach Cap $500,000. Eine privilegierte Signer-Voraussetzung kann die Stufe ändern; die Rechnung ist weder Anspruch noch Universalformel.
  • Jede Uhr misst einen anderen Zustand. Meldung 2026-08-13 09:00; Bestätigung 11:30 nach 2.5 hours; Triage 2026-08-14 16:00 nach 31 hours; temporäres Limit 21:00 nach 36 hours; Patch 2026-08-16 21:00 nach 84 hours; Offenlegung 2026-08-23 09:00 nach 240 hours oder 10 days. Schnelle Bestätigung bedeutet keine schnelle Behebung oder Zahlung.
  • Nominalprämie und Abwicklung sind getrennt. $500,000 werden in USDC zu $1.002 per USDC gezahlt; fällig sind $500,000 / $1.002 = 499,001.996008 USDC. Zahlt das Projekt $18 Netzwerkgebühr separat, gehen 499,001.996008 USDC ein; bei Abzug beträgt der Wert $499,982. Steuer und Einbehalt bleiben eigene Posten.

Risiken

  • Die Programmseite ändert sich ohne datierten Stand.
  • Asset, Version, Chain, Adresse oder Implementierung liegen außerhalb des Umfangs.
  • Ein Proxy-Upgrade ändert den Code während Forschung oder Behebung.
  • Safe Harbor wird als universelle Immunität missverstanden.
  • Tests erfassen ausgeschlossene Anbieter, Oracles, Nutzer oder Dritte.
  • Mainnet- oder öffentliche Testnet-Aktivität verletzt Umfeldregeln.
  • Der PoC bewegt reale Mittel, stört Dienste oder greift auf Personendaten zu.
  • Automatisierung überschreitet Lastgrenzen oder wird zum DoS-Test.
  • Social Engineering, Phishing, Zwang oder Erpressung überschreiten die Erlaubnis.
  • Der PoC sammelt oder veröffentlicht unnötig gefährliche Belege.
  • Ein unsicherer Kanal leakt Geheimnisse, Nutzerdaten oder Exploit-Details.
  • Hashes, Zeiten, Codeversionen oder Chain-Zustand sind nicht reproduzierbar.
  • Duplikat, Vorkenntnis oder erster zulässiger Melder sind unbelegt.
  • Der Schwachstellenname verankert den Schweregrad ohne Erreichbarkeitsprüfung.
  • Theoretischer Risikowert wird mit Verlust oder Angreifergewinn verwechselt.
  • Floor, Cap, Ermessen, Währung oder Zulässigkeit werden falsch gelesen.
  • KYC, Sanktionen, Steuer, Rechnung oder Zahlungs-Chain blockieren Zahlung.
  • Schweigen, unklare Uhren oder frühe Offenlegung erhöhen das Exploit-Risiko.
  • Pause, Limit, Upgrade, Storage-Änderung oder Migration verursachen neuen Schaden.
  • Bounty, Audit, formaler Beweis oder Monitoring gelten fälschlich als Garantie.

Häufige Irrtümer

  • „Ein öffentliches Programm erlaubt alle verwandten Assets und Methoden.“ Autorisierung ist auf gespeicherte Assets, Versionen, Auswirkungen, Umfelder und Verhaltensregeln begrenzt.
  • „Safe Harbor garantiert Immunität in jeder Rechtsordnung.“ Er ist bedingte Policy und bindet nicht jeden Dritten oder jede Behörde.
  • „Critical oder ein Wirkungsprozentsatz legt die Auszahlung fest.“ Schweregrad, Zulässigkeit, Regeln, Caps, Ermessen und Abwicklung bleiben getrennt.
  • „Die erste Nachricht gewinnt jedes Duplikat; Geldbewegung beweist Wirkung.“ Der erste vollständige zulässige Bericht kann zählen; unbefugter Schaden kann disqualifizieren und haften lassen.
  • „Bounty und Audit beweisen nach bestandenem Patch-Test Fehlerfreiheit.“ Audits, formale Methoden, Tests, Bounties, Monitoring und Reaktion decken andere Versionen, Annahmen und Fehler ab.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...