Smart-Contract-Pre-Audit-Checkliste: 30 Fragen

Wavect stellt diese Liste nicht als unabhängiges Audit dar. Sie dient als Pre-Audit-Hardening-Review für EVM-Contracts. Eine Checkliste kann fehlende Evidenz und häufige Risiken aufdecken, aber nicht beweisen, dass ein Contract sicher, wirtschaftlich tragfähig, korrekt integriert oder auf jeder Chain und in jedem Deployment sicher ist.

Begrenze den Review auf exakte Quellen, Compiler, Einstellungen, Abhängigkeiten, erzeugten Bytecode, Proxy-Muster, Chain, Adressen, Rollen, Assets, Integrationen, Deployment-Skripte und Betriebsprozesse. Nutze aktuelle Solidity-Dokumentation, bekannte Compilerfehler, ein Threat Model und einen breiteren Verifikationsstandard. Hilfreiche Grundlagen sind die offiziellen Solidity-Sicherheitshinweise, die Liste bekannter Fehler, der OWASP Smart Contract Security Verification Standard und die aktuelle EEA-Liste der EthTrust Security Levels.

Wie sollte die Checkliste genutzt werden?

Beantworte jede Frage mit Code-Referenz, Test, Tool-Ergebnis, Deployment-Artefakt, Betriebskontrolle oder expliziter Risikoakzeptanz. Bestanden bedeutet, dass die vereinbarte Evidenz die abgegrenzte Anforderung stützt, nicht dass die gesamte Kategorie sicher ist. Ein wesentlicher Fehler muss behoben, aus dem Scope entfernt oder von einem befugten Owner mit Folgen, kompensierenden Kontrollen und Follow-up akzeptiert werden.

Statische Analyse, Fuzzing, Invarianten, formale Methoden, Fork-Tests und manueller Review finden unterschiedliche Fehlerklassen. Keine feste Seed-Zahl oder Null-Warnungen-Regel passt zu jeder Codebasis. Definiere relevante Eigenschaften und Abdeckung, triagiere False Positives, bewahre Tool-Versionen und Konfigurationen auf und erkläre verbleibende Unsicherheit.

Kategorie 1: Spezifikation und Toolchain (Fragen 1 bis 5)

1. Ist das beabsichtigte Verhalten spezifiziert? Erfasse Assets, Akteure, Rechte, Vertrauensannahmen, Zustandsübergänge, Invarianten, Fehlerarten und verbotene Ergebnisse.
2. Ist der Build reproduzierbar? Pinne veröffentlichten Compiler, EVM-Ziel, Optimizer- und IR-Einstellungen, Abhängigkeiten, Generatoren und Befehle; vergleiche deployten Bytecode und Metadaten.
3. Wurden Compiler-Risiken geprüft? Vergleiche die gewählte Version mit der aktuellen maschinenlesbaren Fehlerliste und Upgrade-Empfehlungen.
4. Sind automatisierte Findings bearbeitet? Führe geeignete Compiler-Checks, Linter und Analyzer aus, triagiere jedes wesentliche Ergebnis und dokumentiere begründete Unterdrückungen.
5. Zielen Tests auf Eigenschaften? Kombiniere Beispiele, Grenzen, Negativfälle, Fuzzing, Invarianten, Integration sowie differenzielle oder formale Prüfungen, wo der Nutzen den Aufwand rechtfertigt.

Kategorie 2: Berechtigungen und Lebenszyklus (Fragen 6 bis 10)

6. Ist jede privilegierte Aktion erfasst? Dokumentiere, wer pausieren, upgraden, minten, burnen, beschlagnahmen, konfigurieren, auszahlen, retten oder Abhängigkeiten ändern kann.
7. Passt die Kontrolle zum Risiko? Bewerte Key Custody, Quorum, Signer-Unabhängigkeit, Timelocks, Notfallbefugnis, Liveness, Recovery und Betriebsaufwand, statt einen Kontotyp pauschal zu verbieten.
8. Sind Vergabe, Übertragung, Widerruf und Verzicht sicher? Teste beabsichtigte und versehentliche Übergänge, ausstehende Zustände, verlorene Signer und den letzten Admin-Pfad.
9. Sind Initialisierung und Deployment geschützt? Verhindere unbefugte Initialisierung, Front-running, falsche Parameter und Adressen sowie ungeprüfte Implementation- oder Proxy-Zustände.
10. Sind Notfallkontrollen begrenzt? Definiere Auslöser, Befugnis, Wirkung, Kommunikation, Evidenz, Unpause oder Recovery und den Ausfall der Kontrolle selbst.

Kategorie 3: Assets, Arithmetik und Ökonomie (Fragen 11 bis 15)

11. Sind numerische Bereiche explizit? Prüfe Einheiten, Präzision, Rundungsrichtung, Grenzen, Casts, Vorzeichen und begründete unchecked-Blöcke.
12. Sind Token-Annahmen verifiziert? Behandle Dezimalstellen, Rückgabewerte, Callbacks, Transfergebühren, Rebasing, Pausen, Blocklisten und nicht standardisiertes Verhalten integrationsspezifisch.
13. Werden Werterhaltungs-Eigenschaften getestet? Definiere, wie Einzahlungen, Auszahlungen, Gebühren, Rewards, Schulden, Collateral und Restbeträge über alle Übergänge abgeglichen werden.
14. Sind Oracle- und Marktannahmen begrenzt? Teste Aktualität, Manipulationskosten, Dezimalumrechnung, Sequencer- oder Marktausfall, Fallback und Liquidation.
15. Wurde gegnerisches Wirtschaftsverhalten modelliert? Untersuche Reihenfolge, MEV, Flash-Liquidität, Griefing, Governance Capture, Anreizschleifen und profitable Zustände, die reine Codeprüfungen verpassen.

Kategorie 4: Externe Aufrufe und Komponierbarkeit (Fragen 16 bis 20)

16. Kann eine externe Interaktion wiedereintreten? Analysiere dieselbe Funktion, funktions- und contractübergreifende, Read-only-, Hook-, Token- und Callback-Pfade, statt mechanisch auf einen Guard zu vertrauen.
17. Sind Effects und Rollback korrekt? Nutze Checks-Effects-Interactions oder ein begründetes Design und teste Teilfehler sowie verschachtelte Calls.
18. Werden Rückgabedaten nach der tatsächlichen Schnittstelle interpretiert? Behandle Erfolg, Revert, leere oder fehlerhafte Daten und nicht standardisierte Tokens nach dem erforderlichen Vertrag, nicht nach einer universellen Längenregel.
19. Kann eine Abhängigkeit Fortschritt blockieren? Teste nicht verfügbare, revertende, gasintensive, bösartige, pausierte oder aktualisierte externe Contracts und definiere Isolation oder Recovery.
20. Sind Approvals und Signaturen sicher? Prüfe Allowance-Races, Nonce- und Replay-Domänen, Fristen, Chain- und Contract-Bindung, Signaturmalleabilität und Smart-Account-Validierung.

"Eine Pre-Audit-Checkliste ist nützlich, wenn jede Antwort auf Evidenz und Restrisiko verweist. Eine Reihe grüner Kästchen ist kein Sicherheitsbeweis."

Kategorie 5: Upgrades und Storage (Fragen 21 bis 25)

21. Ist das Upgrade-Modell explizit? Erfasse Proxy-Typ, Implementation Discovery, Upgrade-Befugnis, Verzögerung, Rollback-Annahmen, Initialisierung und Kompatibilitätsgrenze.
22. Ist Storage-Kompatibilität validiert? Vergleiche Layouts mit Tools, die Muster, Vererbung, Packing und Namespaced Storage verstehen. Unterstelle nicht, dass eine feste Gap-Größe überall passt.
23. Sind Implementation-Contracts geschützt? Sperre bei passenden Proxy-Mustern ihre Initialisierung und validiere Parent Initializers und Reinitializers. Folge bei diesem Stack der aktuellen OpenZeppelin-Upgrade-Anleitung.
24. Ist die Autorisierung mustergerecht? Teste, wer ein Upgrade auswählen und ausführen kann, über welchen Proxy- oder Governance-Pfad, einschließlich Stornierung und kompromittierter Befugnis.
25. Wurde die echte Migration geprobt? Befülle repräsentativen State, upgrade über den Produktionspfad, prüfe Invarianten und Integrationen, teste Fehler und Recovery und bewahre Artefakte auf.

Kategorie 6: Verfügbarkeit, Deployment und Betrieb (Fragen 26 bis 30)

26. Kann nutzergesteuertes Wachstum Ausführungsgrenzen überschreiten? Begrenze oder paginiere Schleifen und Batches und teste realistische Worst Cases gegen aktuelle Regeln der Ziel-Chain.
27. Können Gas oder Reverts DoS verursachen? Analysiere Push-Zahlungen, Callbacks, externe Calls, Refunds, Batch-Atomizität und Griefing ohne willkürlichen Block-Gas-Prozentsatz.
28. Ist das Deployment deterministisch und verifiziert? Prüfe Parameter, Salts, Libraries, Owner, Rollen, Implementations, Source Verification, Chain IDs, Funding und Übergabe.
29. Sind Monitoring und Reaktion bereit? Definiere Events, Invarianten- oder Balance-Monitore, Alerts, Owner, Key-Kompromittierungsreaktion, Pause-Kriterien, Kommunikation und Beweissicherung.
30. Sind Launch- und Exit-Risiken kontrolliert? Setze Wert- und Ratenlimits, stufenweisen Rollout, Abhängigkeits- und Chain-Notfallpläne, Nutzer-Recovery, Upgrade- oder Immutability-Folgen und Stilllegung.

Warum unfertigen Code nicht direkt zum Auditor schicken?

Unabhängige Review-Zeit ist meist wertvoller, wenn Anforderungen, Build-Artefakte, Tests, bekannte Tool-Findings, Berechtigungen und Deployment-Pläne konsistent sind. Das rechtfertigt keine universellen Tagessätze, zugesagte Finding-Reduktion oder garantiert billigeren oder schnelleren Launch. Scope, Komplexität, Team, Retests, Berichtspolitik und Termin variieren.

Frage Reviewer, was eingefroren sein muss, welche Artefakte sie brauchen, wie Änderungen und Retests laufen, welche Chains und Integrationen abgedeckt sind und wie Findings klassifiziert werden. Vergleiche schriftlich denselben Scope. Der externe Reviewer muss Annahmen frei infrage stellen können.

Wer verantwortet den Sign-off?

Weise jeder Frage einen verantwortlichen technischen Owner und jedem akzeptierten wesentlichen Risiko einen befugten Business- oder Governance-Owner zu. Übergib Commit- und Bytecode-Referenzen, Test- und Tool-Evidenz, Deployment-Konfiguration, offene Annahmen und Change Log. Der unabhängige Reviewer entscheidet, wie viel er darauf stützt.

Code- und Betriebsänderungen nach dem Review können Evidenz entwerten. Definiere, welche Änderungen eine neue Analyse oder ein Re-Audit verlangen, und knüpfe das Deployment an das aktuell genehmigte Artefakt statt an eine veraltete Checkliste.