04 — Audit de code (Trail of Bits)

Outils d'audit de code Trail of Bits (Semgrep, differential review, sharp edges, etc.).

📋 Index — 04 — Audit de code (Trail of Bits)

04 — Audit de code (Trail of Bits)

Index des skills regroupés dans ce livre. Clique sur un skill pour ouvrir sa fiche.

12 skills documentés.

Skill En une phrase
ask-questions-if-underspecified Force Claude à te poser des questions de clarification avant de se lancer dans le code, quand ta demande peut être interprétée de…
audit-context-building Avant de chercher des bugs, force Claude à lire le code ligne par ligne et à construire une compréhension profonde et structurée…
burpsuite-project-parser Permet de fouiller en ligne de commande dans les fichiers de projet de Burp Suite (un outil de test d'intrusion web très répandu…
constant-time-analysis Détecte les bouts de code cryptographique qui mettent un peu plus (ou un peu moins) de temps à s'exécuter selon la valeur d'un…
differential-review Compare deux versions d'un code (avant/après une modification) pour repérer ce qui a changé et identifier les risques de bugs ou…
dwarf-expert Apporte une expertise pointue sur DWARF — un format technique caché dans les programmes compilés qui permet aux outils de debug…
entry-point-analyzer Cartographie toutes les « portes d'entrée » d'un smart contract — c'est-à-dire les fonctions que n'importe qui peut appeler…
interpreting-culture-index Interprète les résultats du test Culture Index — un sondage RH qui mesure des traits comportementaux (autonomie, sociabilité,…
semgrep-rule-creator Aide à écrire des règles personnalisées pour Semgrep — un outil qui scanne le code à la recherche de motifs vulnérables — afin de…
sharp-edges Repère les API ou les configurations qui ressemblent à des « pièges à doigts » : techniquement utilisables, mais conçues d'une…
spec-to-code-compliance Compare un document de spécification (le « cahier des charges » d'un projet, type whitepaper) au code réellement écrit, pour…
variant-analysis Quand on a trouvé un bug à un endroit, ce skill cherche systématiquement le même type de bug ailleurs dans le code — parce qu'une…

entry-point-analyzer

entry-point-analyzer

Catalogue généré le 2026-05-11

En une phrase

Cartographie toutes les « portes d'entrée » d'un smart contract — c'est-à-dire les fonctions que n'importe qui peut appeler depuis l'extérieur pour modifier l'état du contrat — afin de savoir où concentrer un audit de sécurité.

Quand l'utiliser

Comment l'invoquer

Description détaillée

Un smart contract, c'est un programme qui vit sur la blockchain. Il expose des fonctions, comme des boutons qu'on peut presser depuis l'extérieur. Certains boutons sont réservés à l'admin (par exemple : retirer de l'argent du contrat), d'autres sont accessibles à tout le monde (par exemple : transférer ses propres tokens). Le skill entry-point-analyzer dresse la liste exhaustive de ces boutons et indique qui a le droit de les actionner.

Il ne s'intéresse qu'aux fonctions qui changent l'état du contrat (celles qui peuvent déplacer de l'argent, modifier des balances, changer des permissions). Les fonctions purement « lecture seule » (view, pure) sont exclues parce qu'elles ne peuvent pas, à elles seules, faire perdre des fonds. Pour les contrats en Solidity, le skill peut s'appuyer sur Slither, un outil d'analyse statique très utilisé, qui produit automatiquement le tableau des entry points.

En sortie, tu obtiens un rapport Markdown structuré : la liste des fonctions exposées, leur niveau d'accès (public, admin, restreint à un rôle, accessible seulement par un autre contrat), et les « modifiers » de sécurité appliqués (les garde-fous comme onlyOwner). C'est la base de travail à partir de laquelle tout audit sérieux démarre.

Pour aller plus loin

Pour les détails techniques, exemples et patterns spécifiques, voir le SKILL.md original.

Source

variant-analysis

variant-analysis

Catalogue généré le 2026-05-11

En une phrase

Quand on a trouvé un bug à un endroit, ce skill cherche systématiquement le même type de bug ailleurs dans le code — parce qu'une erreur faite une fois est souvent reproduite plusieurs fois.

Quand l'utiliser

Comment l'invoquer

Description détaillée

Le principe de base de ce skill, c'est qu'un bug est rarement seul. Quand un développeur fait une erreur dans une partie du code (par exemple : oublier de vérifier qu'une valeur n'est pas négative), il a probablement fait la même erreur à plusieurs autres endroits, par copier-coller ou simplement par habitude. Plutôt que d'attendre que ces bugs frères soient découverts un par un, on les chasse tous d'un coup.

Le skill fonctionne en cinq étapes : 1) bien comprendre la cause racine du bug initial (pas juste son symptôme), 2) écrire un motif de recherche qui retrouve exactement le bug d'origine, 3) repérer les éléments qu'on peut généraliser (le nom de la variable n'a pas d'importance, mais la structure de l'appel oui), 4) élargir le motif petit à petit en vérifiant qu'on ne génère pas trop de faux positifs (alertes injustifiées), 5) trier les résultats par exploitabilité.

En entrée, on lui donne un bug connu. En sortie, on obtient une liste de candidats potentiels dans tout le projet, classés par niveau de confiance (élevé / moyen / faible), avec leur fichier et leur ligne. Il choisit son outil selon le besoin : ripgrep pour une recherche textuelle rapide, Semgrep pour des motifs syntaxiques, ou CodeQL pour suivre des flux de données complexes à travers le code.

Pour aller plus loin

Pour les détails techniques, exemples et patterns spécifiques, voir le SKILL.md original.

Source

ask-questions-if-underspecified

ask-questions-if-underspecified

Catalogue généré le 2026-05-11

En une phrase

Force Claude à te poser des questions de clarification avant de se lancer dans le code, quand ta demande peut être interprétée de plusieurs façons — pour éviter de coder pendant deux heures dans la mauvaise direction.

Quand l'utiliser

Comment l'invoquer

Description détaillée

C'est un skill méta : il ne fait pas de code, il discipline la manière dont Claude réagit à une demande. L'idée part d'un constat simple : quand un dev (humain ou IA) se lance sans avoir compris le besoin, il finit souvent par livrer quelque chose qui ne correspond pas, qu'il faut tout refaire. Plutôt que de deviner, autant prendre cinq minutes pour s'aligner.

Concrètement, dès que Claude reçoit une demande, il vérifie six choses : l'objectif (qu'est-ce qui doit changer ?), la définition de « terminé » (à quoi je reconnais que c'est fait ?), le périmètre (quels fichiers, quels composants ?), les contraintes (perf, style, dépendances), l'environnement (quelle version, quel OS ?), et la sécurité (faut-il une procédure de rollback ?). Si une de ces dimensions est floue, il s'arrête et te pose 1 à 5 questions courtes, sous forme numérotée avec des options à choisir.

Mieux : il propose toujours une option par défaut (marquée « recommandée ») et accepte une réponse compacte type defaults ou 1a 2b 3a. Tu n'as donc pas besoin de rédiger un cahier des charges, juste de cocher des cases. Une fois les réponses obtenues, Claude reformule ta demande en deux phrases pour confirmer, puis commence. Ça évite la moitié des « ah non, ce n'était pas ce que je voulais ».

Pour aller plus loin

Pour les détails techniques, exemples et patterns spécifiques, voir le SKILL.md original.

Source

spec-to-code-compliance

spec-to-code-compliance

Catalogue généré le 2026-05-11

En une phrase

Compare un document de spécification (le « cahier des charges » d'un projet, type whitepaper) au code réellement écrit, pour vérifier que le code fait exactement ce que la doc promet — ni plus, ni moins.

Quand l'utiliser

Comment l'invoquer

Description détaillée

Dans le monde de la blockchain et des protocoles décentralisés, un projet commence presque toujours par un « whitepaper » : un document qui explique en détail ce que le système est censé faire (les règles, les calculs, les garanties de sécurité, les invariants à respecter). Puis des développeurs traduisent ce document en code. Le problème, c'est que la traduction n'est jamais parfaite : il y a des oublis, des interprétations, des raccourcis. Ce skill traque ces écarts.

Il fonctionne en plusieurs phases. D'abord, il identifie tous les documents qui font office de spécification (whitepaper PDF, Markdown, notes de design). Ensuite, il extrait de manière exhaustive chaque exigence ou affirmation de la doc. Puis il cherche dans le code la portion qui implémente cette exigence. Pour chaque correspondance, il attribue un type (match complet, match partiel, divergence, exigence non implémentée) et un niveau de confiance entre 0 et 1. Il signale aussi le sens inverse : du code qui existe mais qui ne correspond à aucune ligne de la spec — c'est souvent là que se cachent les vulnérabilités les plus retorses.

La règle d'or du skill : ne jamais inventer. Chaque conclusion doit citer une preuve précise (section du document, numéro de ligne du code). Pas de supposition, pas de « probablement ». Quand quelque chose est ambigu, c'est classé comme tel plutôt que tranché à la légère.

Pour aller plus loin

Pour les détails techniques, exemples et patterns spécifiques, voir le SKILL.md original.

Source

semgrep-rule-creator

semgrep-rule-creator

Catalogue généré le 2026-05-11

En une phrase

Aide à écrire des règles personnalisées pour Semgrep — un outil qui scanne le code à la recherche de motifs vulnérables — afin de détecter automatiquement un type de bug spécifique à ton projet.

Quand l'utiliser

Comment l'invoquer

Description détaillée

Semgrep est un outil qui parcourt ton code et signale tous les endroits où un certain motif apparaît. Par exemple, on peut lui demander de signaler tous les appels à eval() (une fonction réputée dangereuse) ou toutes les requêtes SQL construites par concaténation. Le skill semgrep-rule-creator t'aide à écrire ces règles correctement, parce qu'une règle mal écrite produit soit trop d'alertes inutiles (faux positifs qui érodent la confiance), soit pas assez (faux négatifs qui laissent passer des vrais bugs).

Le skill insiste sur la méthode : commencer par un motif large pour bien capturer le bug initial, puis l'affiner jusqu'à ce qu'il ne déclenche que sur le vrai cas dangereux. Il rappelle aussi qu'une règle non testée ne sert à rien : il faut toujours fournir des exemples de code vulnérable (qui doivent déclencher l'alerte) et des exemples sûrs (qui ne doivent pas la déclencher). Il décourage les patterns trop larges (qui matchent tout et n'importe quoi) et trop spécifiques (qui ratent les variantes).

Pour les cas où on veut suivre la propagation d'une donnée — par exemple, une entrée utilisateur qui finit dans une commande système — il guide vers le mode « taint » de Semgrep, qui modélise les sources (où entre la donnée) et les sinks (où elle ne devrait jamais arriver sans nettoyage). En sortie : une règle YAML prête à intégrer dans ton pipeline d'intégration continue (CI).

Pour aller plus loin

Pour les détails techniques, exemples et patterns spécifiques, voir le SKILL.md original.

Source

burpsuite-project-parser

burpsuite-project-parser

Catalogue généré le 2026-05-11

En une phrase

Permet de fouiller en ligne de commande dans les fichiers de projet de Burp Suite (un outil de test d'intrusion web très répandu chez les pentesters), pour retrouver des requêtes HTTP, des en-têtes ou des réponses suspectes.

Quand l'utiliser

Comment l'invoquer

Description détaillée

Burp Suite est l'outil de référence pour auditer la sécurité des applications web : il se positionne comme un proxy entre ton navigateur et le serveur, et capture toutes les requêtes et réponses qui passent. À la fin d'une session, tu te retrouves avec un fichier .burp qui peut peser plusieurs giga-octets et contenir des dizaines de milliers d'échanges. Impossible à explorer à la main.

Ce skill ne lit pas le fichier directement (le format est propriétaire), mais s'appuie sur Burp Suite Professional et une extension officielle appelée burpsuite-project-file-parser. Une fois cette extension installée, le skill fournit un script wrapper qui te permet de lancer des recherches ciblées depuis le terminal — par exemple : « donne-moi toutes les réponses dont le code de statut est 500 », ou « trouve-moi toutes les requêtes qui contiennent le mot password dans leur corps ».

Le skill insiste fortement sur les filtres : récupérer l'historique complet d'un projet Burp peut renvoyer plusieurs giga-octets de texte qui saturent la console. Il préconise donc de toujours commencer par les en-têtes (petits, rapides à scanner) et de ne charger les corps de réponses qu'après avoir identifié les URLs intéressantes. Idéal pour extraire automatiquement des éléments de preuve à coller dans un rapport d'audit.

Pour aller plus loin

Pour les détails techniques, exemples et patterns spécifiques, voir le SKILL.md original.

Source

differential-review

differential-review

Catalogue généré le 2026-05-11

En une phrase

Compare deux versions d'un code (avant/après une modification) pour repérer ce qui a changé et identifier les risques de bugs ou de failles introduits par la modif.

Quand l'utiliser

Comment l'invoquer

Description détaillée

Ce skill intervient au moment où une modification de code est sur le point d'être intégrée (un merge, un déploiement, une release). Il prend en entrée un « diff » — c'est-à-dire la liste des lignes ajoutées, supprimées ou modifiées — et le compare au reste du projet pour comprendre l'impact réel du changement.

Il ne se contente pas de lire les nouvelles lignes : il regarde aussi l'historique Git (qui a touché à ces fichiers avant, quand, pourquoi), calcule le « blast radius » (autrement dit : combien d'autres parties du code dépendent de ce que tu changes), vérifie si des tests automatiques couvrent les nouvelles lignes, et adapte sa profondeur d'analyse à la taille du projet (petit / moyen / gros).

En sortie, tu obtiens un rapport en Markdown qui liste les problèmes de sécurité potentiels, classés par niveau de risque (élevé / moyen / faible), avec pour chacun une preuve concrète (numéro de ligne, scénario d'attaque imaginé) et un niveau de confiance. Il sait notamment repérer les régressions de sécurité — par exemple, une vérification d'identité qu'on aurait silencieusement retirée en refactorisant.

Pour aller plus loin

Pour les détails techniques, exemples et patterns spécifiques, voir le SKILL.md original.

Source

audit-context-building

audit-context-building

Catalogue généré le 2026-05-11

En une phrase

Avant de chercher des bugs, force Claude à lire le code ligne par ligne et à construire une compréhension profonde et structurée du projet — parce qu'on ne trouve pas de failles dans un code qu'on n'a pas vraiment compris.

Quand l'utiliser

Comment l'invoquer

Description détaillée

C'est un skill de discipline mentale, pas un outil. Il configure la manière dont Claude « pense » pendant la phase préparatoire d'un audit. Plutôt que de survoler le code à la recherche de patterns suspects (ce qui est tentant mais qui produit des hallucinations et des faux positifs), Claude bascule en mode « ultra-granulaire » : il lit fonction par fonction, bloc par bloc, parfois ligne par ligne.

Pour chaque morceau de code, il applique trois techniques. Le « First Principles » consiste à se demander ce que le code fait vraiment, sans accepter les apparences. Les « 5 Pourquoi » consistent à creuser une décision de design jusqu'à toucher la raison profonde. Les « 5 Comment » servent à explorer toutes les manières dont une logique peut être déclenchée ou contournée. À chaque étape, Claude note explicitement ses hypothèses, les invariants qu'il croit identifier, les acteurs en jeu (utilisateurs, admin, oracles), et il met à jour son modèle mental dès qu'une nouvelle preuve contredit ce qu'il pensait.

L'objectif n'est pas de trouver des bugs (ça vient après), mais de construire une carte mentale stable et explicite du système. Une fois cette carte établie, les autres skills d'audit (chasse aux vulnérabilités, analyse de variantes, contrôle de conformité à la spec) peuvent travailler sur des bases solides plutôt que sur des suppositions. Lent en apparence, mais beaucoup plus efficace au final.

Pour aller plus loin

Pour les détails techniques, exemples et patterns spécifiques, voir le SKILL.md original.

Source

dwarf-expert

dwarf-expert

Catalogue généré le 2026-05-11

En une phrase

Apporte une expertise pointue sur DWARF — un format technique caché dans les programmes compilés qui permet aux outils de debug (comme gdb) de savoir à quelle ligne de code source correspond chaque instruction machine.

Quand l'utiliser

Comment l'invoquer

Description détaillée

Quand on compile un programme (en C, C++, Rust…), le code source lisible est transformé en code machine illisible. Mais pour pouvoir déboguer ce programme plus tard, le compilateur joint un dictionnaire à part qui dit : « cette suite d'instructions machine correspond à la ligne 42 du fichier main.c, la variable x est stockée dans le registre EAX à ce moment-là, etc. ». Ce dictionnaire suit un standard appelé DWARF (versions 3, 4 et 5). C'est lui qui permet à gdb ou à un profileur de te montrer du code source plutôt que de l'assembleur.

Ce skill apporte la connaissance technique pour manipuler ces données : comment elles sont structurées, comment les extraire avec les outils standards (dwarfdump, readelf, llvm-dwarfdump), comment les générer correctement, et comment écrire du code qui les analyse à l'aide de bibliothèques comme libdwarf, pyelftools ou gimli (côté Rust).

Il est utile dans plusieurs scénarios concrets : développer un outil de couverture de code, analyser un binaire suspect dans un contexte de reverse engineering, vérifier qu'un binaire de production est correctement compilé avec ses infos de debug, ou comparer la qualité du debug entre deux versions d'un compilateur. C'est un skill très spécialisé, qui ne sert que si tu touches à des binaires compilés natifs (pas du JavaScript, pas du Python).

Pour aller plus loin

Pour les détails techniques, exemples et patterns spécifiques, voir le SKILL.md original.

Source

constant-time-analysis

constant-time-analysis

Catalogue généré le 2026-05-11

En une phrase

Détecte les bouts de code cryptographique qui mettent un peu plus (ou un peu moins) de temps à s'exécuter selon la valeur d'un secret — ce qui peut permettre à un attaquant de deviner ce secret juste en mesurant les temps de réponse.

Quand l'utiliser

Comment l'invoquer

Description détaillée

Imagine un cadenas digital qui dit « bipe court » quand le premier chiffre est faux et « bipe long » quand il est juste. Tu n'as plus qu'à essayer de 0 à 9 sur le premier chiffre, retenir lequel a fait le bip long, puis passer au deuxième. En quelques secondes, tu ouvres un cadenas censé être inviolable. C'est exactement le principe des « attaques par canal auxiliaire par mesure de temps » (timing side-channel) : un attaquant ne voit pas le secret, mais il voit combien de temps le programme met à répondre, et ça lui suffit parfois à le déduire.

Pour qu'un code cryptographique soit sûr, il doit prendre exactement le même temps quel que soit le secret manipulé — on dit qu'il est « à temps constant ». Concrètement, ça veut dire éviter les branchements if (secret == x) qui prennent un chemin différent selon la valeur, et éviter certaines opérations comme la division qui peuvent être plus rapides sur certains nombres que sur d'autres. Le skill analyse le code (en C, C++, Go, Rust, Java, Python, JavaScript et plein d'autres langages) et signale tous les endroits qui ne respectent pas cette contrainte.

Il fournit un script ct_analyzer qui produit un rapport détaillé : chaque opération suspecte, sa ligne dans le code, et pourquoi elle est risquée. Il peut sortir en JSON pour intégration dans un pipeline CI. Particulièrement utile sur les opérations sensibles modernes (signatures Ed25519, encapsulation post-quantique type Kyber, etc.). À noter : ce skill n'est pas pertinent pour du code « métier » classique — il vise uniquement le code qui manipule des secrets cryptographiques.

Pour aller plus loin

Pour les détails techniques, exemples et patterns spécifiques, voir le SKILL.md original.

Source

interpreting-culture-index

interpreting-culture-index

Catalogue généré le 2026-05-11

En une phrase

Interprète les résultats du test Culture Index — un sondage RH qui mesure des traits comportementaux (autonomie, sociabilité, patience…) — pour aider à recruter, manager, prévenir l'épuisement professionnel ou composer des équipes équilibrées.

Quand l'utiliser

Comment l'invoquer

Description détaillée

Culture Index (CI) est un sondage comportemental utilisé par beaucoup d'entreprises pour mieux comprendre comment leurs employés fonctionnent au quotidien. Il mesure six dimensions (autonomie, sociabilité, patience, conformité, logique, ingéniosité) et produit deux graphes : un graphe « Survey » qui décrit la personnalité naturelle de la personne (câblée à l'adolescence, ne change quasiment plus) et un graphe « Job » qui décrit la manière dont elle se comporte au travail (modifiable, mais demande de l'énergie).

Ce skill est l'expert qui sait lire ces graphes correctement, sans tomber dans les pièges classiques. Premier piège évité : ne jamais comparer des valeurs brutes entre deux personnes (« Dan a 8 en autonomie, Jim a 5, donc Dan est plus autonome »). Ce qui compte, c'est la distance entre le point du trait et la flèche rouge qui marque la moyenne. Deuxième piège évité : interpréter un écart entre Survey et Job comme une bonne ou une mauvaise chose. Un écart durable (3-6 mois) est un signal de burnout potentiel, parce que la personne dépense de l'énergie à faire semblant d'être quelqu'un qu'elle n'est pas.

En entrée, le skill accepte soit un JSON déjà extrait d'un rapport CI, soit un PDF brut qu'il peut analyser via un script OpenCV pour reconnaître les graphes. Il sait faire de l'interprétation individuelle, de la prédiction de traits à partir d'un transcript d'entretien, de l'analyse d'équipe, du coaching de manager, et même de la médiation de conflit en se basant sur les profils respectifs.

Pour aller plus loin

Pour les détails techniques, exemples et patterns spécifiques, voir le SKILL.md original.

Source

sharp-edges

sharp-edges

Catalogue généré le 2026-05-11

En une phrase

Repère les API ou les configurations qui ressemblent à des « pièges à doigts » : techniquement utilisables, mais conçues d'une manière où l'usage normal mène facilement à une faille de sécurité.

Quand l'utiliser

Comment l'invoquer

Description détaillée

Il existe deux philosophies pour concevoir une API. La première : « on offre toute la flexibilité, c'est au développeur de bien l'utiliser ». La deuxième : « on rend le chemin sécurisé tellement évident qu'on ne peut pas vraiment se tromper » — c'est le « pit of success ». Ce skill vérifie si une API tombe dans la première catégorie (auquel cas elle produira des bugs en masse) ou dans la deuxième.

Concrètement, il chasse plusieurs types de « pièges ». Les pièges de choix d'algorithme : laisser le développeur choisir entre RSA, HMAC, ou pire none (le célèbre piège JWT où un attaquant peut désactiver la vérification de signature). Les valeurs par défaut dangereuses : un timeout par défaut de 0 qui signifie « accepte tout », un mode debug activé par défaut. Les paramètres ambigus : lifetime=0 veut-il dire « immédiat » ou « infini » ? Personne ne sait. Les API qui demandent au développeur de se rappeler de règles spéciales (« n'oublie pas d'appeler verify() après decode() ») au lieu de les imposer automatiquement.

Le skill rejette aussi les excuses classiques : « c'est documenté » (les devs ne lisent pas la doc sous pression), « les utilisateurs avancés ont besoin de flexibilité » (90 % des usages « avancés » sont du copier-coller), « c'est la responsabilité du dev » (non, c'est le designer qui a mis le piège). Il propose à la place des principes : choix sécurisé par défaut, primitives dangereuses cachées derrière une couche haut niveau, configurations dangereuses rejetées à la validation.

Pour aller plus loin

Pour les détails techniques, exemples et patterns spécifiques, voir le SKILL.md original.

Source