Sicherheitsaudits: was ein Auditbericht wirklich aussagt

·5 Min. Lesezeit·Von SSP Editorial Team
SSP Academy-Titelbild: Sicherheitsauditberichte lesen

Sicherheitsaudits: was ein Auditbericht wirklich aussagt

„Auditiert von“ ist eines der häufigsten Abzeichen in der Kryptowelt. Es taucht auf Websites, in Pitch-Decks und bei Token-Launches auf, oft so, als wäre damit die Frage geklärt, ob etwas sicher ist. Das ist es nicht – aber ein echter Auditbericht verrät, richtig gelesen, eine ganze Menge. Der Trick besteht darin, zu wissen, worauf man achten muss.

Was ein Audit ist

Ein Sicherheitsaudit ist eine zeitlich begrenzte Prüfung von bestimmtem Code durch eine externe Firma. Die Auditoren lesen den Code, testen ihn, versuchen ihn zu knacken und dokumentieren, was sie finden. Bei Smart Contracts bedeutet das meist manuelle Prüfung plus automatisierte Werkzeuge; bei Wallets kann es die Apps, die Kryptografie, die Server, mit denen sie kommunizieren, und das Zusammenspiel all dessen umfassen.

Das Ergebnis ist ein Bericht: was geprüft wurde, wann, was gefunden wurde, wie schwerwiegend jeder Befund war und ob das Team ihn behoben hat.

Drei Formulierungen in dieser Beschreibung sind wichtiger als der Rest: bestimmter Code, zeitlich begrenzt und was gefunden wurde.

Zuerst den Umfang lesen

Der Umfang (Scope) legt genau fest, was sich die Auditoren angesehen haben – meist benannte Repositories, Verträge oder Komponenten, oft an einen bestimmten Commit gebunden.

Genau hier fallen die meisten irreführenden „auditiert“-Behauptungen in sich zusammen. Ein Projekt hat vielleicht einen einzigen kleinen Vertrag prüfen lassen und bewirbt das ganze Protokoll als auditiert. Eine Wallet hat vielleicht ihre Smart Contracts prüfen lassen, während die App, die deine Transaktionen tatsächlich erstellt und signiert, nie angesehen wurde. Wenn das, worauf du vertraust, nicht im Umfang liegt, sagt das Audit nichts darüber aus.

Frag dich: Deckt der Umfang die Teile ab, die mit meinen Geldern in Berührung kommen?

Datum und Version prüfen

Ein Audit beschreibt den Code so, wie er am Tag der Prüfung war. Alles, was danach ausgeliefert wurde – neue Funktionen, neue Chains, Refactorings –, liegt außerhalb davon, sofern es nicht erneut geprüft wurde.

Das ist normal; Software verändert sich ständig. Es bedeutet aber, dass ein zwei Jahre altes Audit eines sich schnell entwickelnden Projekts ein historisches Dokument ist. Die nützlichen Fragen lauten: Wann fand es statt, welche Version deckte es ab, und wurden größere Änderungen seitdem eigens geprüft?

Bei Smart Contracts kommt eine zusätzliche Besonderheit hinzu: Ist ein Vertrag upgradefähig, ist der heute laufende Code möglicherweise nicht der Code, der auditiert wurde. Wer Upgrades kontrolliert, ist ebenso wichtig wie das Audit selbst.

Die Befunde lesen, nicht nur die Zusammenfassung

Berichte stufen Befunde nach Schweregrad ein – typischerweise Kritisch, Hoch, Mittel, Niedrig und Informativ – und halten fest, ob jeder behoben, zur Kenntnis genommen oder unverändert gelassen wurde.

  • Kritische und hohe Befunde sind diejenigen, die zum Verlust von Geldern führen könnten. Gab es welche, und wurden sie behoben und erneut geprüft?
  • „Zur Kenntnis genommen“ ist nicht „behoben“. Es bedeutet, dass das Team das Risiko akzeptiert hat. Manchmal ist das vernünftig; lies die Begründung.
  • Null Befunde sind nicht automatisch eine gute Nachricht. Das kann exzellenten Code bedeuten – oder einen engen Umfang und einen kurzen Auftrag.
  • Nachtests sind wichtig. Ein guter Bericht besagt, dass die Auditoren die Korrekturen überprüft haben, nicht nur, dass das Team behauptet hat, sie umgesetzt zu haben.

Was ein Audit dir nicht sagen kann

Selbst ein gründliches Audit hat Grenzen, die man klar benennen sollte:

  • Es ist eine Stichprobe an Aufmerksamkeit, kein Beweis. Auditoren finden viele Fehler, aber nicht alle. Auditierte Protokolle wurden schon ausgenutzt.
  • Es deckt Code ab, nicht den Betrieb. Wie Schlüssel aufbewahrt werden, wer deployen darf, wie das Team mit einem Vorfall umgeht – das liegt meist außerhalb des Umfangs.
  • Es deckt das ökonomische Design nicht ab, sofern das nicht ausdrücklich zum Umfang gehörte. Ein Vertrag kann genau so funktionieren, wie er geschrieben ist, und trotzdem über Preise, Anreize oder andere Protokolle ausnutzbar sein.
  • Es deckt nicht ab, was du installierst. Ein Audit des Quellcodes sagt nichts über eine gefälschte App mit demselben Namen aus. Reproduzierbare Builds sind das, was veröffentlichten Code mit der Software verbindet, die du tatsächlich ausführst.

Warnsignale bei „auditiert“-Behauptungen

  • Kein Link zum eigentlichen Bericht, oder ein Bericht, der nur vom Projekt selbst gehostet wird.
  • Ein Auditor, den du nicht finden kannst, oder dessen Website den Auftrag nicht aufführt.
  • Ein Umfang, der nicht zu dem passt, was beworben wird.
  • Nicht behobene Befunde mit hohem Schweregrad, die als „adressiert“ beschrieben werden.
  • Ein einziges Audit vor Jahren, für ein Produkt, das sich seitdem komplett verändert hat.

Wie SSP damit umgeht

Der Code von SSP ist Open Source, sodass ihn jeder lesen kann – aber offener Code und auditierter Code sind nicht dasselbe, und wir behandeln beides getrennt.

Halborn, ein unabhängiges Sicherheitsunternehmen, hat die ERC-4337-Smart-Contracts von SSP sowie die SSP Wallet-Erweiterung, die SSP Key-App und SSP Relay im Zusammenspiel auditiert. Beide Berichte sind öffentlich auf der Website von Halborn einsehbar, ohne kritische oder hohe Befunde, und die niedrigen und informativen Befunde wurden adressiert. Unser Audit-Rückblick 2025 führt Umfang und Daten jedes Auftrags auf.

Für uns gelten dieselben Vorbehalte wie für alle anderen. Diese Audits decken den Code so ab, wie er zum Zeitpunkt der Prüfung war; seitdem hinzugekommene Funktionen und Chains sind davon nicht abgedeckt. Deshalb sagen wir, welche Art von Prüfung neuerer Code erhalten hat, statt ein altes Abzeichen darüber zu dehnen.

Das ehrliche Fazit

Ein Audit ist ein Beleg, keine Garantie. Es sagt dir, dass bestimmter Code zu einem bestimmten Zeitpunkt von einer bestimmten Firma geprüft wurde – und was diese gefunden hat.

Lies den Umfang, prüfe Datum und Version, sieh dir die Schweregrade an und wie sie gelöst wurden, und suche den Bericht auf der eigenen Website des Auditors. Tu das, und „auditiert“ ist kein Abzeichen mehr, sondern eine Information.

Diesen Artikel teilen

Verwandte Artikel