samczsun: Die Sicherheit von Krypto-Protokollen hängt entscheidend von einer proaktiven erneuten Überprüfung ab.

Bug-Bounty-Programme sind passive Maßnahmen, während Sicherheitsabwehr proaktiv vorangetrieben werden muss.

Verfasst von: samczsun, Gründer von Security Alliance, ehemaliger Research Partner bei Paradigm

Inzwischen herrscht in der Branche Konsens darüber, dass der Schutz der Kryptowährungssicherheit drei entscheidende Schritte erfordert: Während der Entwicklungsphase werden Testfälle geschrieben, um grundlegende Fehler zu identifizieren; vor der Bereitstellung werden umfassende Prüfungen durch Audits und Wettbewerbe durchgeführt; und es werden Bug-Bounty-Programme eingerichtet, um Forscher, die Schwachstellen verantwortungsbewusst melden und so Angriffe verhindern, zu belohnen. Die Verbreitung dieser Best Practices hat die Anzahl der On-Chain-Schwachstellen erheblich reduziert und Angreifer dazu gezwungen, sich auf Off-Chain-Schwachstellen wie den Diebstahl privater Schlüssel oder Infrastruktureinbrüche zu konzentrieren.

Dennoch werden selbst Protokolle, die umfassend geprüft wurden und großzügige Bug-Bounties anbieten, gelegentlich Opfer von Hackerangriffen. Solche Vorfälle betreffen nicht nur das jeweilige Protokoll, sondern erschüttern auch das Vertrauensfundament des gesamten Ökosystems. Die jüngsten Angriffe auf Yearn und Balancer V2 sowie die Sicherheitsvorfälle bei Abracadabra und 1inch zu Beginn des Jahres zeigen, dass selbst bewährte Protokolle nicht absolut sicher sind. Hätte die Kryptoindustrie diese Angriffe vermeiden können? Oder ist dies nur der unvermeidliche Preis für dezentrale Finanzen?

Kritiker argumentieren oft, dass höhere Bug-Bounties diese Protokolle hätten schützen können. Doch selbst abgesehen von wirtschaftlichen Realitäten sind Bug-Bounties im Kern passive Sicherheitsmaßnahmen, die das Schicksal des Protokolls in die Hände von White-Hat-Hackern legen, während Audits proaktive Selbstschutzmaßnahmen des Protokolls sind. Die Erhöhung von Bug-Bounties kann Hackerangriffe nicht verhindern, denn das ist nichts anderes als ein doppelter Einsatz darauf, dass White-Hat-Hacker Schwachstellen schneller finden als Black-Hat-Hacker. Wenn ein Protokoll sich wirklich schützen will, muss es proaktiv Re-Audits durchführen.

Treasury-Fonds und Total Value Locked (TVL)

Manchmal erklären sich Hacker bereit, den Großteil der gestohlenen Gelder zurückzugeben und nur einen kleinen Teil (in der Regel 10%) als Belohnung zu behalten. Leider wird dieser Teil in der Branche als „White-Hat-Bounty“ bezeichnet, was die Frage aufwirft: Warum bietet das Protokoll nicht einfach im Rahmen des Bug-Bounty-Programms denselben Betrag an, um Verhandlungen zu vermeiden? Doch dieser Gedanke verwechselt die Mittel, die ein Angreifer stehlen kann, mit den Mitteln, über die das Protokoll tatsächlich verfügen kann.

Obwohl es auf den ersten Blick so aussieht, als könnte das Protokoll beide Mittel für Sicherheitsmaßnahmen verwenden, hat das Protokoll nur über die eigenen Treasury-Fonds die rechtliche Verfügungsgewalt, nicht aber über die von Nutzern eingezahlten Gelder. Nutzer werden dem Protokoll kaum im Voraus solche Rechte einräumen; nur in Krisenzeiten (wenn Einleger zwischen einem Verlust von 10% oder 100% ihrer Einlagen wählen müssen) erlauben sie dem Protokoll, Einlagen für Verhandlungen zu nutzen. Mit anderen Worten: Das Risiko wächst mit dem TVL, aber das Sicherheitsbudget kann nicht im gleichen Maße steigen.

Kapital-Effizienz

Selbst wenn ein Protokoll über ausreichende Mittel verfügt (z. B. durch einen großen Treasury, hohe Rentabilität oder bereits implementierte Sicherheitsgebühren), bleibt die Frage, wie diese Mittel sinnvoll für Sicherheitsmaßnahmen eingesetzt werden können. Im Vergleich zu Investitionen in Re-Audits ist die Erhöhung von Bug-Bounties bestenfalls äußerst ineffizient und schlimmstenfalls führt sie zu Fehlanreizen zwischen Protokoll und Forschern.

Wenn Bug-Bounties an den TVL gekoppelt sind, haben Forscher, die vermuten, dass der TVL des Protokolls steigen wird und die Wahrscheinlichkeit für wiederholte Schwachstellen gering ist, einen klaren Anreiz, kritische Schwachstellen zu verschweigen. Dies führt letztlich zu einem direkten Interessenkonflikt zwischen Forschern und Protokoll und schadet den Nutzern. Auch die bloße Erhöhung der Belohnung für kritische Schwachstellen erzielt kaum die gewünschte Wirkung: Die Gruppe der freiberuflichen Forscher ist groß, aber nur wenige investieren den Großteil ihrer Zeit in Bug-Bounties und verfügen über die nötigen Fähigkeiten, Schwachstellen in komplexen Protokollen zu finden. Diese Elite-Forscher konzentrieren sich auf die Bounty-Projekte mit der höchsten erwarteten Rendite. Bei großen, bewährten Protokollen, die ständig im Fokus von Hackern und anderen Forschern stehen, wird die Wahrscheinlichkeit, eine Schwachstelle zu finden, als äußerst gering eingeschätzt – egal wie hoch die Belohnung ist, es reicht nicht, um ihren Einsatz zu rechtfertigen.

Aus Sicht des Protokolls sind Bug-Bounties Mittel, die für die Entdeckung einer einzelnen kritischen Schwachstelle reserviert sind. Es sei denn, das Protokoll ist bereit, darauf zu wetten, dass es niemals eine kritische Schwachstelle geben wird, und seine Liquiditätssituation vor den Forschern zu verbergen, können diese Mittel nicht anderweitig verwendet werden. Anstatt passiv darauf zu warten, dass Forscher kritische Schwachstellen entdecken, sollte das Protokoll dieselben Mittel lieber über mehrere Jahre hinweg in wiederholte Re-Audits investieren. Jede Überprüfung stellt sicher, dass die Aufmerksamkeit von Top-Forschern gewonnen wird, ohne sich künstlich auf die Entdeckung einer einzigen Schwachstelle zu beschränken, und die Interessen von Forschern und Protokoll bleiben im Einklang: Wird das Protokoll ausgenutzt, leidet der Ruf beider Seiten.

Bestehende Präzedenzfälle

In der Software- und Finanzbranche sind jährliche Audits bewährte und etablierte Praxis und der beste Weg, um zu beurteilen, ob ein Unternehmen mit der sich ständig verändernden Bedrohungslandschaft Schritt halten kann. SOC 2 Type II-Berichte werden von B2B-Kunden genutzt, um zu bewerten, ob ein Anbieter angemessene Sicherheitskontrollen aufrechterhält; PCI DSS-Zertifizierungen zeigen, dass ein Unternehmen geeignete Maßnahmen zum Schutz sensibler Zahlungsinformationen ergriffen hat; die US-Regierung verlangt von Parteien, die mit Regierungsinformationen in Kontakt kommen, eine FedRAMP-Zertifizierung, um hohe Sicherheitsstandards zu gewährleisten.

Smart Contracts selbst sind zwar unveränderlich, aber ihre Ausführungsumgebung ist nicht statisch. Konfigurationen können sich im Laufe der Zeit ändern, Abhängigkeiten können aktualisiert werden, und Code-Muster, die einst als sicher galten, können sich als riskant herausstellen. Ein Audit bewertet den Sicherheitsstatus zum Zeitpunkt der Prüfung, bietet aber keine Garantie für die zukünftige Sicherheit des Protokolls. Die einzige Möglichkeit, diese Bewertung zu aktualisieren, ist ein neues Audit.

Im Jahr 2026 sollte die Kryptoindustrie jährliche Audits als vierten Schritt im Protokoll-Sicherheitsprozess etablieren. Bestehende Protokolle mit hohem TVL sollten Re-Audits für ihre Deployments durchführen; Audit-Unternehmen sollten spezialisierte Re-Audit-Dienstleistungen anbieten, die sich auf die Bewertung des gesamten Deployments konzentrieren; das gesamte Ökosystem sollte seine Wahrnehmung von Audit-Berichten ändern – sie sind nur eine Momentaufnahme der Sicherheit zu einem bestimmten Zeitpunkt und können veralten, sie sind kein dauerhafter Sicherheitsgarant.