Smart-Contract-Audits: Was sie aufdecken – und was nicht

Ein Smart-Contract-Audit wird oft wie ein Sicherheitssiegel behandelt: auditiert bedeutet sicher, nicht auditiert bedeutet riskant. Die Realität ist enger gefasst – und gerade dadurch nützlicher, wenn man sie versteht. Ein Audit ist eine strukturierte Überprüfung, die bestimmte, bekannte Fehlerkategorien aufdeckt – es ist keine Garantie, und auditierte Protokolle haben trotzdem Nutzergelder durch Exploits verloren. Dieser Beitrag beschreibt, was ein Audit tatsächlich leistet und wo seine Grenzen liegen.

Was ein Audit tatsächlich prüft

Ein Smart-Contract-Audit ist eine manuelle und automatisierte Überprüfung des Codes eines Vertrags, die in der Regel vor dem Deployment stattfindet und nach bekannten Schwachstellenmustern sucht: Reentrancy-Fehler, Integer-Overflow und -Underflow, Fehler in der Zugriffskontrolle, die es einer falschen Adresse erlauben, eine privilegierte Funktion aufzurufen, sowie Logikfehler, die vom erklärten Zweck des Vertrags abweichen. Auditoren gleichen den Vertrag zudem mit der eigenen Dokumentation des Projekts ab und suchen nach Stellen, an denen der Code etwas anderes tut, als er vorgibt.

Da Smart Contracts exakt so ausgeführt werden, wie sie geschrieben sind, und sich nach dem Deployment nur schwer ändern lassen, ist diese Fehlerkategorie ungewöhnlich folgenreich: Ein Fehler, den eine klassische Anwendung still patchen könnte, kann bei einem laufenden Vertrag mit realem Wert in dem Moment ausgenutzt werden, in dem er entdeckt wird. Das ist der Kerngrund, warum Audits als eigenständige Praxis existieren und nicht einfach Teil der gewöhnlichen Code-Review sind.

Was Audits zuverlässig aufdecken

Etablierte, gut verstandene Schwachstellenklassen sind der Bereich, in dem Audits sich ihren Ruf verdienen. Reentrancy – bei der ein bösartiger Vertrag den auditierten Vertrag erneut aufruft, bevor dessen erster Aufruf abgeschlossen ist, und so durch wiederholte Auszahlungen Gelder abzieht – ist ein Lehrbuchfall, den erfahrene Auditoren routinemäßig prüfen, gerade weil er einige der frühesten und teuersten Exploits der Branche verursacht hat. Lücken in der Zugriffskontrolle, ungeprüfte externe Aufrufe und vorhersagbare Zufallswerte fallen in dieselbe Kategorie: bekannte Fehlermodi mit bekannten Erkennungsmethoden.

Für diese Kategorien senkt ein kompetentes Audit das Risiko spürbar. Ein Vertrag, der von einer renommierten Firma geprüft wurde, scheitert nachweislich seltener an einem bekannten Angriffsmuster als einer, der das nicht wurde.

Was Audits nicht aufdecken

Bei neuartigen Exploits, komplexen Interaktionen zwischen mehreren Verträgen und ökonomischen Design-Fehlern, die nichts mit einem Programmierfehler zu tun haben, sind Audits deutlich weniger zuverlässig. Ein Vertrag kann exakt nach Spezifikation umgesetzt sein und trotzdem ausnutzbar bleiben, weil die Spezifikation selbst einen Fehler enthält – ein Orakel-Preisfeed, das manipuliert werden kann, eine Anreizstruktur, die ein von den Entwicklern nicht vorhergesehenes Verhalten belohnt, oder ein Governance-Mechanismus, den ein gut finanzierter Angreifer vorübergehend kapern kann. Nichts davon sind Fehler im klassischen Sinne, und keine noch so gründliche Code-Review deckt einen Design-Fehler auf, nach dem der Auditor nicht gezielt sucht.

Audits sind zudem eine Momentaufnahme. Ein Vertrag kann auditiert und danach ohne erneute Prüfung verändert werden, oder mit anderen Verträgen auf Weisen kombiniert werden, die das ursprüngliche Audit nie berücksichtigt hat. Das Kernmerkmal von DeFi – genehmigungsfreie Komponierbarkeit, bei der jeder Vertrag jeden anderen aufrufen kann – ist zugleich der Grund, warum das Audit eines isolierten Vertrags keine Sicherheit garantieren kann, sobald dieser mit Verträgen interagiert, die nie gemeinsam geprüft wurden.

Was das in der Praxis bedeutet

Ein Audit sollte als spürbare Risikominderung gegenüber bekannten Fehlerkategorien verstanden werden, nicht als Sicherheitsnachweis. Ein veröffentlichter Audit-Bericht lohnt die Lektüre, nicht nur das Zitieren: Man sollte prüfen, welchen Umfang er tatsächlich abgedeckt hat, ob Befunde behoben oder nur zur Kenntnis genommen wurden, und wie aktuell er im Verhältnis zum jetzigen, möglicherweise veränderten Code ist. Ein Audit senkt das Risiko; es beseitigt es nicht, und kein seriöses Projekt sollte etwas anderes suggerieren.