Audit de la Sécurité des Smart Contracts Foundry

Que fait Audit de la Sécurité des Smart Contracts Foundry ?

Aperçu

Les smart contracts déployés sont immuables et détiennent des fonds réels, donc un bug livré sur la mainnet ne peut pas être corrigé — il ne peut qu'être exploité. La plupart des pertes catastrophiques en DeFi proviennent d'un petit ensemble de classes récurrentes : réentrance, contrôle d'accès cassé, manipulation d'oracle/prix, et arithmétique ou appels externes non vérifiés.

Cette compétence exécute un audit de défense en profondeur, pré-déploiement d'un projet Foundry, en superposant quatre techniques indépendantes qui capturent chacune ce que les autres manquent :

1. Analyse statique — slither (90+ détecteurs) et aderyn (Cyfrin, Rust) analysent l'AST/IR en quelques secondes pour détecter les anti-patrons connus.
2. Exécution symbolique — mythril (optionnel, lent) explore les chemins d'exécution et résout via SMT les bugs profonds d'arithmétique/réentrance.
3. Tests basés sur des propriétés — forge test avec fuzzing (testFuzz_*) et tests d'invariants (invariant_* + contrats handler avec variables fantômes) prouve que les propriétés au niveau du protocole tiennent sur des millions de séquences aléatoires.
4. Révision manuelle + hygiène des clés — une checklist structurée (voir references/vulnerability-checklist.md) et un audit des secrets/keystore pour qu'aucune clé privée ne vive jamais en texte clair et que le déploiement passe par un keystore chiffré cast (voir references/secure-deployment-and-keys.md).

La compétence est côté développeur et pré-déploiement — elle est exécutée par l'ingénieur qui construit le contrat, pas par un SOC après un incident. Les résultats bloquent le déploiement : tout résultat statique haut/critique, test échoué, clé divulguée, ou faible couverture = ÉCHEC.

Quand l'utiliser

• Avant de déployer tout contrat Solidity sur un testnet ou une chaîne EVM mainnet.
• Lors de l'écriture ou de la révision d'un projet Foundry (foundry.toml, src/, test/, script/).
• Lorsqu'un contrat gère de la valeur : tokens (ERC-20/721/1155), coffres, staking, AMMs, ponts, gouvernance.
• Lors de l'ajout de tests de fuzzing ou d'invariants, ou lorsque la couverture des fonctions manipulant de la valeur est inconnue.
• Lors du câblage des scripts de déploiement — pour vérifier que les clés sont dans un keystore chiffré, pas en texte clair dans .env.
• Lors de l'intégration d'un oracle de prix, d'un appel externe, delegatecall, ou d'un proxy upgradeable.
• Lors du triage d'un rapport Slither/Aderyn et du besoin de séparer les vrais bugs des faux positifs.

Prérequis

• Foundry installé (forge, cast, anvil) : curl -L https://foundry.paradigm.xyz | bash && foundryup
• Slither + solc : pip install slither-analyzer et solc-select install <ver> && solc-select use <ver>
• Aderyn (recommandé) : cargo install aderyn (ou npm i -g @cyfrin/aderyn)
• Mythril (optionnel, exécution symbolique lente) : pip install mythril
• gitleaks (scan de fuite de clés) : voir la compétence associée implementing-secret-scanning-with-gitleaks
• Un projet Foundry qui compile (forge build réussit) — les analyseurs ont besoin des artefacts de construction.
• Solidity ^0.8.x est supposé (vérifications de débordement intégrées) ; les contrats pré-0.8 nécessitent une révision supplémentaire avec SafeMath.

Installez les outils Python dans un virtualenv (recommandé sur les distributions à gestion externe). N'exécutez jamais d'analyse contre un source de contrat non fiable sur une machine avec des portefeuilles déverrouillés contenant des fonds.

Étapes

Étape 1 : Construire et vérifier la santé du projet

forge build                    # les analyseurs nécessitent des artefacts frais
forge fmt --check              # vérification du style (optionnel)
cat foundry.toml               # notez la version solc, l'optimiseur, les remappings, evm_version

Étape 2 : Analyse statique (rapide, à exécuter à chaque fois)

# Slither — projet complet (utilise foundry.toml + remappings automatiquement)
slither . --json slither-report.json

# Aderyn — analyseur Cyfrin Rust, détecteurs complémentaires
aderyn . -o aderyn-report.json

Ou exécutez l'orchestrateur groupé qui lance les deux, déduplique et bloque le résultat :

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

Étape 3 : Exécution symbolique sur les contrats critiques (optionnel, lent)

# Uniquement sur le(s) contrat(s) de plus haute valeur — Mythril est explosif en chemins
myth analyze src/Vault.sol --solc-json mythril.config.json --execution-timeout 300 -o json
# ou : python3 scripts/agent.py --project . --mythril src/Vault.sol

Étape 4 : Tests basés sur des propriétés — fuzzing + invariants

forge test -vvv                                  # tests unitaires + fuzzing
forge coverage --report summary                  # couverture du code manipulant de la valeur
forge test --match-test invariant_ -vvv          # suite d'invariants (basée sur handler)

Chaque contrat manipulant de la valeur devrait avoir des tests d'invariants avec un handler (entrées bornées, variables fantômes, targetContract(handler)) — pas seulement des tests unitaires. Voir references/api-reference.md pour le patron handler, et écrivez un test_RevertWhen_* (avec vm.expectRevert) pour chaque garde de contrôle d'accès.

Étape 5 : Révision manuelle selon la checklist

Parcourez references/vulnerability-checklist.md pour chaque contrat : réentrance (vérifications-effets-interactions / nonReentrant), contrôle d'accès, manipulation d'oracle, delegatecall/disposition de stockage proxy, valeurs de retour non vérifiées, tx.origin, aléa faible, déni de service, front-running/MEV, et pièges spécifiques aux ERC (course approve, fee-on-transfer, rebasing).

Étape 6 : Hygiène des clés et déploiement sécurisé

gitleaks detect --no-banner            # pas de clés privées / mnemonics / .env commités
git ls-files | grep -E '\.env$|keystore' && echo "ATTENTION : secrets suivis par git"

# Importez la clé de déploiement UNE FOIS dans un keystore chiffré — jamais de variable d'environnement PRIVATE_KEY en texte clair
cast wallet import deployer --interactive

# Déployez via le compte keystore (d'abord sur testnet), simulez avant --broadcast
forge script script/Deploy.s.sol --account deployer --rpc-url <testnet> --broadcast --verify

Voir references/secure-deployment-and-keys.md pour les règles complètes de durcissement (hygiène MetaMask, portefeuille matériel pour la mainnet, confiance RPC, vérification post-déploiement).

Étape 7 : Triage et rapport

Combinez les résultats de Slither + Aderyn + Mythril + tests, dédupliquez par (fichier, ligne), éliminez les faux positifs confirmés, classez par exploitabilité × impact financier, et mappez chaque résultat à son identifiant SWC. L'orchestrateur émet audit-report.json avec une porte PASS/FAIL.

Résultat attendu

Un rapport d'audit JSON listant les résultats avec identifiants SWC, sévérité, outil source, contrat/fonction/ligne affectés, et remédiation ; plus le résumé des tests/couverture et une seule porte PASS / FAIL de déploiement. ÉCHEC sur tout résultat statique haut/critique, test échoué, secret divulgué, ou couverture en dessous du seuil configuré sur le code manipulant de la valeur.