„Auditiert“ ist das am stärksten überinterpretierte Wort dieser Branche. Es wird als binäre Eigenschaft eines Projekts behandelt, obwohl es tatsächlich eine Aussage über eine bestimmte Menge von Dateien zu einem bestimmten Zeitpunkt ist, getroffen von einer bestimmten Prüfgesellschaft, unter einem Prüfumfang, den beide Seiten vorab vereinbart haben.
Den Bericht statt des Badges zu lesen, dauert rund zehn Minuten und verändert, was Sie wissen.
Beginnen Sie beim Prüfumfang, nicht bei den Feststellungen
Jeder glaubwürdige Bericht hat einen Abschnitt zum Prüfumfang, meist innerhalb der ersten beiden Seiten. Er nennt das Repository, den geprüften Commit-Hash und die Liste der Contract-Dateien im Prüfumfang. Das ist der mit Abstand nützlichste Teil des Dokuments.
Der Commit-Hash ist wichtig, weil er die Prüfung präzise datiert. Jeder Code, der nach diesem Commit geschrieben wurde — einschließlich der Behebung der im Bericht selbst genannten Feststellungen —, war nicht Teil des Untersuchten. Ein Projekt, das im März auditiert und im Juni neue Funktionen ausgeliefert hat, betreibt auditierten und nicht auditierten Code gemeinsam, und nur der Bericht sagt Ihnen, was wovon ist.
Lesen Sie, was ausgeschlossen wurde
Abschnitte zum Prüfumfang sagen auch, was nicht geprüft wurde, und diese Liste ist oft interessanter als die Feststellungen. Übliche Ausschlüsse: das Front-End, Deployment-Skripte, Off-Chain-Infrastruktur, die Oracle-Konfiguration, die Verwaltung von Admin-Schlüsseln und jeder Contract Dritter, von dem das System abhängt.
Diese Ausschlüsse decken sich fast genau damit, wie Systeme tatsächlich scheitern. Eine Front-End-Kompromittierung geschieht in einer Schicht, die Contract-Audits überhaupt nicht abdecken, und die Kontrolle über Admin-Schlüssel — wer upgraden oder pausieren kann — liegt häufig außerhalb des Prüfumfangs, obwohl sie darüber entscheidet, ob Mittel entnommen werden können.
Feststellungen: Schweregrad und was danach geschah
Feststellungen werden üblicherweise von kritisch bis informativ eingestuft. Zwei Fragen zählen mehr als die Anzahl:
- Wurde jede Feststellung behoben, zur Kenntnis genommen oder bestritten? Berichte halten die Reaktion des Projekts normalerweise fest. „Zur Kenntnis genommen“ bedeutet, dass das Projekt sie gelesen und sich entschieden hat, nichts zu ändern — was vernünftig sein kann, aber es ist eine Entscheidung, keine Behebung.
- Wurde die Behebung erneut geprüft? Eine Behebung, die nach der Prüfung geschrieben und nie erneut untersucht wurde, ist neuer, nicht auditierter Code im empfindlichsten Teil des Systems.
Was ein Audit strukturell nicht erfassen kann
Prüfer bewerten Code gegen die Absicht. Wo die Absicht selbst fehlerhaft ist, kann der Code korrekt sein und das System dennoch Geld verlieren — das ist ein Fehler in der Geschäftslogik, und es ist die Klasse, die eine Prüfung am ehesten übersteht, weil Zeile für Zeile nichts falsch aussieht. Der Euler-Finance-Donation-Angriff ist ein Datensatz dieser Form.
Audits setzen zudem voraus, dass der Compiler das erzeugt, was der Quelltext sagt. Wo diese Annahme scheitert — eine Toolchain-Kompromittierung — weichen geprüfter Quelltext und ausgerollter Bytecode voneinander ab, wie bei den Curve-Finance-Vyper-Reentrancy-Datensätzen.
Eine kurze Checkliste
- Gibt es überhaupt einen Bericht, vollständig veröffentlicht — keine Zusammenfassung und kein Logo?
- Welcher Commit wurde geprüft, und stimmt der ausgerollte Code damit überein?
- Was lag ausdrücklich außerhalb des Prüfumfangs?
- Wurden kritische und hohe Feststellungen behoben, und wurden die Behebungen erneut geprüft?
- Gibt es außerdem ein Bug-Bounty-Programm, das Code in seiner Veränderung abdeckt statt nur eine Momentaufnahme?
Keine Beratung. Conisec berichtet ausschließlich zu Informationszwecken. Nichts in diesem Artikel ist eine Finanz-, Rechts-, Steuer- oder Sicherheitsberatung. Prüfen Sie die oben verlinkten Primärquellen, bevor Sie auf dieser Grundlage handeln.
