auditing-foundry-smart-contract-security

Auditing Foundry Smart Contract Security

Übersicht

Bereitgestellte Smart Contracts sind unveränderlich und verwalten echte Gelder, daher kann ein auf Mainnet ausgelieferter Bug nicht mehr gefixt werden – er kann nur ausgenutzt werden. Die meisten katastrophalen DeFi-Verluste stammen aus einer kleinen Gruppe wiederkehrender Fehlerklassen: Wiedereintritt, defekte Zugriffskontrolle, Oracle-/Preismanipulation sowie ungeprüfte Arithmetik oder externe Aufrufe.

Diese Fähigkeit führt eine verteidigungsbasierte Sicherheitsüberprüfung vor dem Deployment eines Foundry-Projekts durch, die vier unabhängige Techniken schichtet, von denen jede die Fehler erkennt, die die anderen übersehen:

1. Statische Analyse – slither (90+ Detektoren) und aderyn (Cyfrin, Rust) scannen den AST/IR in Sekunden nach bekannten Anti-Patterns.
2. Symbolische Ausführung – mythril (optional, langsam) durchläuft Ausführungspfade und löst per SMT tiefe Arithmetik-/Wiedereintrittsfehler.
3. Eigenschaftsbasierte Tests – forge test mit Fuzzing (testFuzz_*) und Invariantentests (invariant_* + Handler-Contracts mit Ghost-Variablen) beweist, dass Protokolleigenschaften über Millionen zufälliger Sequenzen hinweg gelten.
4. Manuelle Überprüfung + Schlüsselhygiene – eine strukturierte Checkliste (siehe references/vulnerability-checklist.md) und ein Secrets/Keystore-Audit, damit kein privater Schlüssel je im Klartext liegt und die Bereitstellung über einen verschlüsselten cast-Keystore erfolgt (siehe references/secure-deployment-and-keys.md).

Die Fähigkeit ist entwicklerseitig und vor dem Deployment – sie wird vom Entwickler ausgeführt, der den Contract erstellt, nicht von einem SOC nach einem Vorfall. Erkenntnisse sperren den Deploy: Jeder hohe/kritische statische Fehler, fehlgeschlagener Test, durchgesickerter Schlüssel oder niedrige Abdeckung = FAIL.

Wann zu verwenden

• Vor dem Deployment eines Solidity-Contracts in ein Testnetz oder Mainnet-EVM-Netzwerk.
• Beim Schreiben oder Überprüfen eines Foundry-Projekts (foundry.toml, src/, test/, script/).
• Wenn ein Contract Werte verwaltet: Token (ERC-20/721/1155), Vaults, Staking, AMMs, Bridges, Governance.
• Beim Hinzufügen von Fuzz- oder Invariantentests oder wenn die Abdeckung von werttransferierenden Funktionen unbekannt ist.
• Beim Verkabeln von Deployment-Skripten – um zu verifizieren, dass Schlüssel in einem verschlüsselten Keystore liegen, nicht als .env-Klartext.
• Bei der Integration eines Preis-Oracles, externen Aufrufs, delegatecall oder upgradeable Proxys.
• Beim Triagieren eines Slither/Aderyn-Berichts und der Notwendigkeit, echte Bugs von False Positives zu trennen.

Voraussetzungen

• Foundry installiert (forge, cast, anvil): curl -L https://foundry.paradigm.xyz | bash && foundryup
• Slither + solc: pip install slither-analyzer und solc-select install <ver> && solc-select use <ver>
• Aderyn (empfohlen): cargo install aderyn (oder npm i -g @cyfrin/aderyn)
• Mythril (optional, langsame symbolische Ausführung): pip install mythril
• gitleaks (Schlüssel-Leak-Scan): siehe die begleitende Fähigkeit implementing-secret-scanning-with-gitleaks
• Ein Foundry-Projekt, das kompiliert (forge build erfolgreich) – Analysewerkzeuge benötigen Build-Artefakte.
• Es wird Solidity ^0.8.x angenommen (eingebaute Overflow-Prüfungen); Contracts vor 0.8 benötigen eine zusätzliche SafeMath-Überprüfung.

Installieren Sie die Python-Werkzeuge in einer virtualenv (empfohlen auf extern verwalteten Distributionen). Führen Sie niemals eine Analyse gegen unvertrauten Contract-Quellcode auf einem Rechner mit entsperrten, finanzierten Wallets durch.

Schritte

Schritt 1: Projekt bauen und auf Korrektheit prüfen

forge build                    # Analysewerkzeuge benötigen frische Artefakte
forge fmt --check              # Style-Check (optional)
cat foundry.toml               # solc-Version, Optimizer, Remappings, evm_version notieren

Schritt 2: Statische Analyse (schnell, jedes Mal ausführen)

# Slither — komplettes Projekt (nutzt automatisch foundry.toml + remappings)
slither . --json slither-report.json

# Aderyn — Cyfrin Rust-Analyzer, komplementäre Detektoren
aderyn . -o aderyn-report.json

Oder den gebündelten Orchestrator ausführen, der beide ausführt, dedupliziert und das Ergebnis filtert:

python3 scripts/agent.py --project . --output audit-report.json

Schritt 3: Symbolische Ausführung auf kritischen Contracts (optional, langsam)

# Nur auf dem/den höchstwertigen Contract(s) — Mythril ist pfadexplosiv
myth analyze src/Vault.sol --solc-json mythril.config.json --execution-timeout 300 -o json
# oder: python3 scripts/agent.py --project . --mythril src/Vault.sol

Schritt 4: Eigenschaftsbasierte Tests — Fuzz + Invarianten

forge test -vvv                                  # Unit + Fuzz-Tests
forge coverage --report summary                  # Abdeckung von werttransferierendem Code
forge test --match-test invariant_ -vvv          # Invarianten-Suite (handlerbasiert)

Jeder werttransferierende Contract sollte Invariantentests mit einem Handler haben (begrenzte Eingaben, Ghost-Variablen, targetContract(handler)) – nicht nur Unit-Tests. Siehe references/api-reference.md für das Handler-Muster und schreiben Sie einen test_RevertWhen_* (mit vm.expectRevert) für jede Zugriffskontrollsicherung.

Schritt 5: Manuelle Überprüfung anhand der Checkliste

Durchlaufen Sie references/vulnerability-checklist.md für jeden Contract: Wiedereintritt (Checks-Effects-Interactions / nonReentrant), Zugriffskontrolle, Oracle-Manipulation, delegatecall/Proxy Storage Layout, ungeprüfte Rückgabewerte, tx.origin, schwache Zufallszahlen, DoS, Front-Running/MEV und ERC-spezifische Fallstricke (Approve-Race, Fee-on-Transfer, Rebasing).

Schritt 6: Schlüsselhygiene & sicheres Deployment

gitleaks detect --no-banner            # keine privaten Schlüssel / Mnemonics / .env committen
git ls-files | grep -E '\.env$|keystore' && echo "WARN: secrets tracked by git"

# Den Bereitstellungsschlüssel EINMAL in einen verschlüsselten Keystore importieren — niemals eine Klartext-Umgebungsvariable PRIVATE_KEY
cast wallet import deployer --interactive

# Deployment über das Keystore-Konto (zuerst Testnetz), vor --broadcast simulieren
forge script script/Deploy.s.sol --account deployer --rpc-url <testnet> --broadcast --verify

Siehe references/secure-deployment-and-keys.md für die vollständigen Härtungsregeln (MetaMask-Hygiene, Hardware-Wallet für Mainnet, RPC-Vertrauen, Post-Deploy-Verifikation).

Schritt 7: Triagieren und Bericht

Kombinieren Sie Slither- + Aderyn- + Mythril- + Testergebnisse, deduplizieren Sie nach (Datei, Zeile), entfernen Sie bestätigte False Positives, ordnen Sie nach Ausnutzbarkeit × finanzieller Auswirkung und ordnen Sie jeden Befund seiner SWC-ID zu. Der Orchestrator gibt audit-report.json mit einem PASS/FAIL-Gate aus.

Erwartete Ausgabe

Ein JSON-Auditbericht mit SWC-Identifikatoren, Schweregrad, Werkzeugquelle, betroffenem Contract/Funktion/Zeile und Abhilfe; sowie die Test-/Abdeckungszusammenfassung und ein einzelnes PASS / FAIL-Deployment-Gate. FAIL bei jedem hohen/kritischen statischen Fehler, fehlgeschlagenem Test, durchgesickertem Geheimnis oder Abdeckung unter dem konfigurierten Schwellenwert für werttransferierenden Code.