Defending Code Reference Harness - framework open source d’Anthropic pour la découverte et la correction de vulnérabilités par IA
(github.com/anthropics)- Defending Code Reference Harness est une implémentation de référence conçue pour permettre à Claude d’effectuer de façon autonome la découverte et la correction de vulnérabilités, à partir d’enseignements tirés d’une collaboration avec les équipes sécurité de plusieurs organisations
- Ce dépôt n’est pas un produit mais une implémentation de référence ; il n’est actuellement plus maintenu et n’accepte pas de contributions
- Anthropic propose comme alternative managée Claude Security, qui permet de trouver et corriger des vulnérabilités dans le code source de plusieurs projets tout en gérant le cycle de vie de triage, de validation des correctifs et de génération rapide de correctifs
- Les skills pour Claude Code incluent
/quickstart,/threat-model,/vuln-scan,/triage,/patch,/customizeet prennent en charge le cadrage interactif du périmètre, le scan, le triage et l’application de patchs harness/est un pipeline autonome de référence suivant le flux recon → find → verify → report → patch, optimisé pour la recherche de vulnérabilités mémoire en C/C++ à l’aide de Docker et d’ASAN- La structure générale du pipeline de référence, les prompts et la méthode de sandboxing peuvent être réutilisés, mais ils ne fonctionnent pas immédiatement sur toutes les bases de code et doivent être portés via
/customizeselon le langage, les détecteurs et le type de vulnérabilité /quickstart,/threat-model,/vuln-scan,/triageet/patchsur des résultats statiques n’effectuent que des lectures et écritures de fichiers ; après examen et approbation de l’utilisation de chaque outil dans Claude Code, ils peuvent être exécutés sans sandbox- Le pipeline autonome de référence et
/patchappliqué aux résultats du pipeline exécutent le code cible ; sauf contournement explicite, ils refusent donc de s’exécuter en dehors de la sandbox gVisor - Pour exécuter le pipeline, il faut préparer gVisor et les images d’agent avec
scripts/setup_sandbox.sh, et disposer de Docker ainsi que des variables d’environnementANTHROPIC_API_KEYouCLAUDE_CODE_OAUTH_TOKEN - L’exécution se découpe en étapes build, recon, find, verify, dedupe, report et patch ; l’agent find génère des entrées malformées dans un conteneur isolé et poursuit l’exploration jusqu’à ce que le binaire ASAN plante 3 fois sur 3
- À l’étape verify, un agent grader distinct ne reçoit que la proof of concept et reproduit le crash dans un nouveau conteneur ; l’étape dedupe détermine s’il s’agit d’un nouveau bug, d’un meilleur exemple d’un bug existant ou d’un doublon
- L’étape report produit une analyse structurée de l’exploitabilité incluant la classe de primitive, l’accessibilité, le chemin d’escalade et la sévérité ; l’étape patch génère ensuite une correction puis vérifie la compilation, l’absence de crash avec la proof of concept d’origine, le passage des tests et la recherche de possibilités de contournement
- Le flux d’utilisation initial consiste à produire le Day 1 un threat model, un scan statique, un triage et un patch candidat ; le Day 2, à générer des findings validés à l’exécution sur une bibliothèque C/C++ ; puis, aux Days 3-5, à créer
targets/<your-service>/pour sa propre cible - Pour le porter à sa propre stack, il faut définir le signalement des findings, le format de la proof of concept ainsi que les méthodes de build et d’exécution ; la référence C/C++ s’appuie sur une signature de crash ASAN, un fichier d’entrée provoquant le crash et un Dockerfile basé sur clang+ASAN
- Le triage autonome et l’application automatique de patchs restent des problèmes ouverts ; la stratégie de validation de
/patchélève le niveau d’exigence, mais la sévérité et la priorité dépendent du contexte, et même un patch validé n’est pas toujours acceptable upstream
1 commentaires
Avis sur Hacker News
C’est plus proche d’un gabarit d’atelier. On peut acheter un traîneau de coupe transversale si on veut, mais la plupart des menuisiers fabriquent le leur
Il y a 2 ans, le coût de créer son propre harness était élevé, donc la situation était différente, mais aujourd’hui il vaut mieux voir ce genre de chose comme une source d’idées et le construire soi-même en l’adaptant à sa façon de travailler, à son interface, à sa définition des cibles et de l’effort, et à son mode de notification
Avant l’IA, créer un logiciel pour résoudre son propre problème demandait beaucoup d’effort humain, donc on faisait souvent l’effort supplémentaire de le généraliser pour qu’il puisse aussi être réutilisé par d’autres. Maintenant, cela ne demande presque plus d’effort, donc les logiciels restent non généralisés
Ces derniers temps, je ne partage presque rien de ce que je fais[0], parce qu’il y a peu de chances que cela aide quelqu’un d’autre, et que si quelqu’un a besoin de quelque chose de similaire, il peut créer quelque chose qui lui correspond exactement au lieu d’étendre ou modifier le mien. Comme un gabarit
0: https://redfloatplane.lol/blog/17-why-share/ et les billets associés
Dans nos vies, il est souvent préférable de créer des outils dédiés à un usage précis, et à chaque nouveau modèle, la complexité de ces outils augmente aussi
Ce sont vraiment des outils personnels. Ils résolvent des problèmes que d’autres peuvent aussi avoir, mais ils sont tellement liés à une manière de travailler propre à chacun qu’ils sont difficiles à expliquer ou à adapter pour quelqu’un d’autre. Donc oui, ce sont des gabarits d’atelier
J’ai moi aussi une dizaine de scripts et programmes personnalisés comme ça, et je n’avais pas ressenti ça depuis l’université. À l’époque, j’avais le temps de tout personnaliser dans les réglages ; aujourd’hui, il y a les agents
J’aimerais les montrer à mes amis, mais quand j’essaie mentalement d’expliquer leur fonctionnement, je me dis qu’ils ne comprendraient pas toutes les bizarreries. Parce que ce sont mes propres bizarreries. Ce sont des morceaux de technique assez complexes qui résolvent très bien mes problèmes, et ces problèmes sont des variantes personnelles de problèmes plus larges, sans que j’aie l’intention de les maintenir pour d’autres, du moins pour l’instant
Il est tellement évident que nous allons dans cette direction, et pourtant beaucoup continuent de penser que le code est réservé à une élite. Le code produit le sera peut-être encore, mais pour tout le reste, on dirait bien que même l’ordinateur de nos parents exécutera bientôt du code écrit spécialement pour eux. C’est effrayant du point de vue de la sécurité, mais fascinant quand on y pense
Et même quand on le fait soi-même, les workflows IA que j’avais peaufinés pendant des mois sont devenus obsolètes du jour au lendemain à cause d’ultracode
J’imagine que, dans beaucoup d’organisations, de moins en moins d’utilisateurs se tournent vers les équipes qui s’occupent de ce type de travail
Le coût de fabriquer le sien est devenu trop faible, et le coût de rester enfermé dans les briques de base de quelqu’un d’autre est devenu trop élevé
Mais ancrer le codage par IA dans des outils existants reste incroyablement puissant
Je me demande combien coûte l’exécution de tout ça
D’après https://github.com/anthropics/defending-code-reference-harne... :
L’écart pourrait peut-être même être d’un ordre de grandeur à un chiffre
Ce calculateur est assez frappant : pour une entreprise de 100 développeurs, le coût annuel en tokens peut monter jusqu’à 2,5 millions de dollars
https://ai-cost-calculator.arnica.io
En revanche, en passant par l’API, j’imagine que les coûts grimperaient très vite
Ce n’est qu’une estimation, donc ça peut être faux, mais cela donne un ordre de grandeur basé sur notre expérience. Je serais curieux d’avoir des retours
Mais même en prenant des chiffres plus élevés, cela peut rester autour d’un dixième du coût d’une mission de sécurité formelle visant le type de découvertes que ce genre d’outil recherche. Ce ne sont pas des résultats qu’on obtient juste avec une review de PR ou un
/security-review, mais plutôt le genre de résultats qui demandent qu’un expert pilote le travail préparatoire d’un framework open source. Et je ne compte même pas le temps et les délais nécessaires pour comprendre comment monter ce type de missionPour le dire franchement, si c’est important, même si un scan unique coûte l’équivalent d’un budget mensuel de vibe coding, cela reste extraordinairement peu cher, de l’ordre de « quelques centimes par dollar »
En même temps, il faut toujours un expert derrière les résultats. Les suggestions peuvent être utiles comme elles peuvent être activement nuisibles, et tout dépend de la qualité du travail préparatoire
À un DSI, je conseillerais de dépenser quelques milliers de dollars pour faire tourner ça, d’utiliser la page de résultats inquiétants pour débloquer du budget, puis de nouer une relation avec une red team capable de trouver et classer les vulnérabilités, voire d’aider à les corriger si nécessaire, tout en formant l’équipe interne à une approche orientée sécurité
« Ce dépôt n'est pas maintenu et n'accepte pas de contributions. »
Hmm :)
https://github.com/space-bacon/SRT
On peut améliorer fortement tous les modèles figés du jour au lendemain. Allons-y
D'après notre expérience, sans bon harness, on n'obtient pas grand-chose de codex/claude. Et il faut dépenser du temps et de l'énergie à comprendre pourquoi les agents de code ne trouvent pas les bugs que des humains trouvent
En tant qu'auditeur, je vois chaque semaine des bugs que notre harness (https://zkao.io/) ne trouve pas, et il faut découvrir des techniques assez intéressantes pour amener l'outil à les détecter. On parle ici surtout de vulnérabilités cryptographiques, pas de simples bugs de webapp
Du coup, il semble raisonnable que les entreprises aient leur propre harness et paient aussi pour des services qui se concentrent, grâce à l'expérience, sur la création de bons harness. Les cabinets d'audit qui voient beaucoup de bugs et peuvent passer du temps à « enseigner » ces bugs à leur harness sont probablement les mieux placés pour ce travail
À l'inverse, le triage a besoin de techniques tout aussi solides. Sinon, on obtient ce que j'appelle de l'audit vibe, une machine qui ne produit que suffisamment de faux positifs pour épuiser encore davantage des développeurs déjà fatigués par les soumissions IA médiocres des bug bounties et par les outils d'IA qui relisent toutes les PR
Au final, si le harness ne retourne aucun bug, on se retrouve à se demander : « Est-ce que ça veut dire qu'il n'y a pas de bug ? » En fin de compte, on revient à un jeu de réputation où il faut choisir le meilleur outil ou la meilleure équipe, c'est-à-dire l'équipe qui sait quels sont les meilleurs outils, puis déterminer qui c'est
La sécurité est clairement un excellent cas d'usage de l'IA/LLM. Une grande partie du travail consiste à faire correspondre des motifs connus de problèmes de sécurité avec le texte d'un langage de programmation analysé avec une très grande précision
Ce qui frappe, c'est que, dans les cas d'usage les plus puissants, les entreprises d'IA semblent vouloir vendre la technique comme un service plutôt que vendre des sorties brutes. Quand la valeur de la sortie est faible, elles vendent des tokens
Si les tokens d'IA étaient réellement magiques pour créer de la nouvelle valeur dans le développement d'applications logicielles classique, elles ne les vendraient pas directement. Elles les thésauriseraient et s'en serviraient pour dominer les logiciels SaaS de tous les secteurs qu'elles veulent
C'est un peu comme quelqu'un qui vend une formation chère sur la bourse : cela signale qu'il a plus à gagner en vendant la formation qu'en gagnant directement de l'argent sur le marché avec son savoir
Construire un produit avec des tokens d'IA implique de créer et vendre un produit complet, domaine où elles ont moins d'expérience, et de se mettre en concurrence avec leurs propres clients. Ce n'est pas une bonne position pour un fournisseur d'IA encore en phase d'installation. C'est une grosse distraction alors qu'elles ont déjà beaucoup à gérer avec leur activité actuelle, et stratégiquement ce n'est pas si précieux
J'ai exploité puis vendu un SaaS raisonnablement réussi, et les aspects épuisants et frustrants sont précisément ceux sur lesquels les LLM ne peuvent pas aider. Le fait de coder le produit n'est ni le goulot d'étranglement ni la garantie du succès
Même si leurs tokens étaient vraiment magiques, et qu'ils pouvaient entrer dans des secteurs existants, évincer les acteurs en place et y croître de 100 % par an, il serait encore préférable de privilégier la vente de tokens. C'est déjà une excellente activité en soi
Tout ce que cette logique montre, c'est qu'il y a une limite. Les tokens ne sont pas assez puissants pour générer immédiatement de l'argent infini dans tous les domaines du logiciel. Cela semble vrai
Au début, beaucoup d'entreprises interdisaient à leurs employés de saisir du code source dans des LLM distants pour des raisons de sécurité. Maintenant, beaucoup commencent à croire qu'il faut analyser tout leur code source avec des LLM distants, toujours pour des raisons de sécurité
Si le fait de faire confiance à Anthropic devient normalisé, ils pourront vendre davantage de services nécessitant l'accès au code source
Un peu hors sujet, mais on dirait que quelqu'un est en train de tuer tous les bons liens GitHub de ce post avec des dead/flag, et je ne vois pas pourquoi
Trouver une faille est toujours plus facile que toutes les colmater. Les hackers ont les mêmes outils, donc c'est une course aux armements impossible à gagner
L'asymétrie mentionnée était déjà une propriété du logiciel avant les LLM
Assez intéressant. Je construis et j'utilise depuis quelque temps un outil similaire :
https://github.com/bobinson/vulture
J'ai souffert des faux positifs, et j'utilisais Claude + MCP comme un outil d'audit du pauvre. Ces derniers jours, j'ai obtenu de meilleurs résultats avec des modèles hébergés par Nvidia
Tant qu'on ne sait pas si Claude utilise efficacement les tokens avec ce harness, ce n'est peut-être pas aussi utile que ça en a l'air
Il est clair qu'Anthropic construit et industrialise désormais des harness pour des cas d'usage spécifiques
C'est en quelque sorte l'équivalent de Claude Design pour la sécurité
Le harness est différent, le packaging est différent, et la persona visée est différente, donc le mode de distribution l'est naturellement aussi
Ce qui est intéressant, c'est que si l'on regarde les billets d'entreprise parlant de Mythos, tout le monde construit son propre harness. Cisco a même publié la spécification de l'un d'eux
Mais celui qui a trouvé comment empaqueter et distribuer cela, c'est Anthropic. Excellente stratégie de go-to-market