Defending Code Reference Harness - Anthropic Open-Source-Framework zur KI-basierten Erkennung und Behebung von Schwachstellen
(github.com/anthropics)- Defending Code Reference Harness ist eine Referenzimplementierung für die autonome Erkennung und Behebung von Schwachstellen mit Claude und basiert auf Erkenntnissen aus der Zusammenarbeit mit Sicherheitsteams mehrerer Organisationen
- Dieses Repository ist kein Produkt, sondern eine Referenzimplementierung; es wird derzeit nicht gepflegt und nimmt auch keine Beiträge an
- Anthropic bietet mit Claude Security eine verwaltete Alternative an, die Schwachstellen im Quellcode mehrerer Projekte finden und beheben sowie den Lebenszyklus von Triage, Fix-Validierung und schneller Fix-Generierung verwalten kann
- Skills für Claude Code umfassen
/quickstart,/threat-model,/vuln-scan,/triage,/patch,/customizeund unterstützen interaktive Eingrenzung des Umfangs, Scans, Triage und Patch-Arbeiten harness/ist eine autonome Referenz-Pipeline mit dem Ablauf recon → find → verify → report → patch und ist mit Docker und ASAN auf die Suche nach C/C++-Speicherschwachstellen ausgelegt- Die allgemeine Struktur der Referenz-Pipeline, die Prompts und die Sandboxing-Methoden lassen sich wiederverwenden, funktionieren aber nicht sofort in jeder Codebasis und müssen mit
/customizean Sprache, Detektoren und Schwachstellentypen angepasst werden /quickstart,/threat-model,/vuln-scan,/triagesowie/patchfür statische Ergebnisse führen nur Datei-Lese- und Schreibvorgänge aus und können in Claude Code ohne Sandbox ausgeführt werden, wenn die Nutzung der einzelnen Tools geprüft und genehmigt wurde- Die autonome Referenz-Pipeline und
/patchfür Pipeline-Ergebnisse führen den Zielcode aus und verweigern die Ausführung daher außerhalb der gVisor-Sandbox, sofern dies nicht ausdrücklich umgangen wird - Für die Pipeline-Ausführung müssen gVisor und Agent-Images mit
scripts/setup_sandbox.shvorbereitet werden; außerdem werden Docker und die UmgebungsvariablenANTHROPIC_API_KEYoderCLAUDE_CODE_OAUTH_TOKENbenötigt - Die Ausführungsschritte sind in Build, Recon, Find, Verify, Dedupe, Report und Patch unterteilt; der Find-Agent erzeugt in einem isolierten Container malformed input und sucht so lange weiter, bis das ASAN-Binary in 3 von 3 Versuchen abstürzt
- In der Verify-Phase übernimmt ein separater Grader-Agent in einem neuen Container nur das Proof of Concept, reproduziert den Absturz, und in der Dedupe-Phase wird entschieden, ob es sich um einen neuen Bug, ein besseres Beispiel für einen bestehenden Bug oder ein Duplikat handelt
- In der Report-Phase wird eine strukturierte Exploitability-Analyse mit primitive class, reachability, escalation path und severity erstellt; in der Patch-Phase wird ein Fix erzeugt und anschließend Build, Nicht-Absturz des ursprünglichen Proof of Concept, erfolgreiches Bestehen der Tests und eine erneute Suche nach Umgehungsmöglichkeiten überprüft
- Der anfängliche Nutzungsablauf sieht vor, an Tag 1 ein Threat Model sowie statischen Scan, Triage und einen Candidate Patch zu erstellen, an Tag 2 in C/C++-Bibliotheken ausführungstechnisch verifizierte Findings zu erzeugen und an den Tagen 3 bis 5
targets/<your-service>/für eigene Ziele zu erstellen - Beim Portieren auf den eigenen Stack müssen Finding-Signale, die Form des Proof of Concept sowie Build- und Ausführungsweise definiert werden; die C/C++-Referenz orientiert sich an ASAN-Crash-Signature, crashing input file und einem auf clang+ASAN basierenden Dockerfile
- Autonome Triage und Patching sind weiterhin offene Probleme; die Validierungsstrategie von
/patchhebt zwar die Messlatte, doch severity und Priorisierung sind umgebungsspezifische Entscheidungen, und ein validierter Patch ist nicht immer upstream-fähig
1 Kommentare
Hacker-News-Kommentare
Das ist eher eine Werkstattvorrichtung. Wenn man will, kann man einen Crosscut-Schlitten kaufen, aber die meisten Holzwerker bauen sich so etwas selbst
Vor zwei Jahren war die Situation anders, weil es viel gekostet hat, sich sein eigenes Harness zu bauen. Heute scheint es am besten zu sein, so etwas als Ideenquelle zu nutzen und es dann selbst an die eigene Arbeitsweise, Oberfläche, Ziele und Definition von Aufwand sowie Benachrichtigungsart anzupassen
Vor AI kostete es viel menschlichen Aufwand, Software zu bauen, die das eigene Problem löst. Deshalb machte man oft noch die zusätzliche Arbeit, sie so zu verallgemeinern, dass andere sie wiederverwenden können. Jetzt kostet das fast keine Mühe mehr, also bleibt Software unverallgemeinert
In letzter Zeit teile ich fast nichts mehr von dem, was ich baue[0], weil es anderen wahrscheinlich kaum hilft und sie sich, wenn sie etwas Ähnliches brauchen, lieber etwas bauen können, das exakt auf sie zugeschnitten ist, statt meines zu erweitern oder anzupassen. Eben wie bei einer Vorrichtung
0: https://redfloatplane.lol/blog/17-why-share/ und verwandte Beiträge
In unserem Leben gibt es viele Fälle, in denen es besser ist, zweckgebundene Werkzeuge zu bauen, und mit jedem neuen Modell wächst auch die Komplexität solcher Werkzeuge
Das hier sind wirklich persönliche Werkzeuge. Sie lösen Probleme, die auch andere haben könnten, sind aber so stark an die eigene Arbeitsweise gebunden, dass sie sich nur schwer anderen erklären oder an sie anpassen lassen. Deshalb sind es Werkstattvorrichtungen
Ich selbst habe ungefähr zehn solcher maßgeschneiderten Skripte und Programme, und dieses Gefühl hatte ich zum ersten Mal seit dem Studium nicht mehr. Damals hatte ich Zeit, meine Setups nach Belieben zu individualisieren, und heute gibt es Agenten
Ich würde sie Freunden gern zeigen, aber wenn ich im Kopf durchgehe, wie ich sie eigentlich erklären sollte, denke ich, dass sie viele der Eigenheiten nicht verstehen würden. Denn es sind meine Eigenheiten. Es sind ziemlich komplexe technische Bausteine, die meine Probleme sehr gut lösen, und diese Probleme sind persönliche Abwandlungen eines breiteren Problems. Zumindest im Moment habe ich nicht vor, dafür Support zu leisten
Dass wir in diese Richtung gehen, ist so offensichtlich, und trotzdem glauben viele noch immer, Code sei etwas für Eliten. Für Produktcode mag das stimmen, aber beim Rest wird wohl bald selbst der Computer unserer Eltern Code ausführen, den er eigens für sie geschrieben hat. Aus Sicherheitsgründen ist das beängstigend, aber als Gedanke auch faszinierend
Außerdem wurden sogar die AI-Workflows, an denen ich monatelang gefeilt hatte, durch ultracode sofort veraltet
Ich vermute, dass in vielen Organisationen immer weniger Nutzer bei den Teams landen, die solche Dinge betreuen
Die Kosten, etwas Eigenes zu bauen, sind viel zu niedrig geworden, und die Kosten, in den Grundbausteinen anderer gefangen zu sein, viel zu hoch
Gleichzeitig ist es extrem mächtig, AI-Coding an bestehende Tools anzubinden
Ich frage mich, wie teuer es ist, das auszuführen
Laut https://github.com/anthropics/defending-code-reference-harne...:
Vielleicht am Ende sogar mit einem Unterschied um eine Größenordnung
Diesem Rechner zufolge könnte ein Unternehmen mit 100 Entwicklern bei jährlichen Token-Kosten von rund 2,5 Millionen Dollar landen, was ziemlich schockierend ist
https://ai-cost-calculator.arnica.io
Über die API dürften die Kosten aber schnell hochgehen
Es ist nur eine Schätzung und kann also falsch liegen, aber auf Basis unserer Erfahrungen zeigt sie ungefähr die Größenordnung. Ich würde gern Feedback hören
Aber selbst mit höheren Zahlen könnte das immer noch nur etwa ein Zehntel dessen kosten, was ein formaler Sicherheitsauftrag zur Aufdeckung der Funde kostet, auf die solche Tools abzielen. Das sind Ergebnisse, die man nicht nur durch PR-Reviews oder
/security-reviewbekommt, sondern nur, wenn Experten die Vorarbeit mit einem Open-Source-Framework anleiten. Die Zeit und Verzögerung, die es kostet, überhaupt herauszufinden, wie man einen solchen Auftrag aufsetzt, ist dabei noch gar nicht eingerechnetDirekt gesagt: Wenn es wichtig ist, dann ist selbst ein Monatsbudget für Vibe Coding für einen einzelnen Scan im Verhältnis „Centbeträge pro Dollar“ extrem günstig
Gleichzeitig braucht es für die Ergebnisse weiterhin Experten. Ein Vorschlag kann hilfreich sein oder aktiv schaden, und viel hängt von der Qualität der Vorarbeit ab
Einem IT-Leiter würde ich raten, ein paar tausend Dollar dafür auszugeben, das laufen zu lassen, sich mit der furchteinflößenden Ergebnisseite Budget zu sichern und dann eine Beziehung zu einem Red Team aufzubauen, das Schwachstellen finden, klassifizieren und bei Bedarf auch beheben hilft und gleichzeitig das interne Team auf Security-Orientierung trainiert
„Dieses Repository wird nicht gepflegt und nimmt keine Beiträge an.“
Hm :)
https://github.com/space-bacon/SRT
Kann über Nacht alle Frontier-Modelle deutlich verbessern. Los geht’s
Unsere Erfahrung ist, dass man aus codex/claude ohne einen guten Harness nicht viel herausholen kann. Und man muss Zeit und Energie darauf verwenden herauszufinden, warum Coding-Agenten Bugs, die Menschen finden, nicht entdecken
Als Auditor sehe ich jede Woche Bugs, die unser Harness (https://zkao.io/) nicht findet, und wir müssen ziemlich interessante Techniken entwickeln, damit das Tool diese Bugs findet. Dabei geht es hier hauptsächlich um kryptografische Schwachstellen, nicht um einfache Web-App-Bugs
Deshalb scheint es plausibel, dass Unternehmen auch für Services zahlen werden, die auf Basis von Erfahrung darauf spezialisiert sind, gute Harnesses zu bauen, zusätzlich dazu, eigene Harnesses zu haben. Audit-Firmen, die viele Bugs sehen und Zeit darauf verwenden können, diese Bugs dem Harness „beizubringen“, werden darin vermutlich am besten sein
Umgekehrt braucht auch die Klassifizierung entsprechend gute Verfahren. Sonst entsteht eine Maschine, die ich Vibe-Auditing nenne, und die nur genug False Positives produziert, um Entwickler noch weiter zu ermüden, die schon von schlechten KI-Einreichungen bei Bug-Bounties und KI-Tools, die jeden PR reviewen, genervt sind
Wenn das Harness am Ende keine Bugs zurückliefert, fragt man sich dann: „Heißt das, es gibt keine Bugs?“ Letztlich landet man wieder bei einem Reputationsspiel, bei dem man das beste Tool oder das beste Team auswählt — also das Team, das weiß, was das beste Tool ist — und herausfinden muss, wer das ist
Sicherheit ist definitiv ein großartiger AI/LLM-Use-Case. Ein großer Teil der Arbeit besteht darin, bekannte Muster von Sicherheitsproblemen mit dem zu analysierenden, sehr präzisen Text in Programmiersprachen abzugleichen
Auffällig ist, dass AI-Unternehmen in den stärksten Use-Cases die Technik als Service verkaufen wollen, statt rohe Outputs zu verkaufen. Wenn der Wert des Outputs gering ist, verkaufen sie Tokens
Wenn AI-Tokens bei der Schaffung neuen Werts in der Entwicklung allgemeiner Softwareanwendungen wirklich magisch wären, würden sie diese nicht direkt verkaufen. Sie würden Tokens horten und damit SaaS-Software in allen Branchen erobern, die sie wollen
Das ist ähnlich wie bei jemandem, der am Aktienmarkt teure Kurse verkauft: Das signalisiert, dass es sich für ihn eher lohnt, die Kurse zu verkaufen, als mit seinem Wissen direkt am Aktienmarkt Geld zu verdienen
Um mit AI-Tokens Produkte zu bauen, müssten sie vollständige Produkte entwickeln und verkaufen, worin sie wenig Erfahrung haben, und zudem mit ihren eigenen Kunden konkurrieren. Für einen AI-Anbieter, der sich noch etabliert, ist das keine gute Position. Das wäre schon mit dem bestehenden Geschäft eine große Ablenkung und strategisch auch nicht besonders wertvoll
Ich habe ein ordentlich erfolgreiches SaaS betrieben und verkauft, und die ermüdenden, frustrierenden Teile sind genau die Dinge, bei denen LLMs nicht helfen können. Das Produkt zu programmieren ist weder der Engpass noch der Faktor, der den Erfolg garantiert
Selbst wenn ihre Tokens wirklich magisch wären und sie in bestehende Branchen gehen, etablierte Anbieter verdrängen und dort jährlich um 100 % wachsen könnten, wäre es immer noch besser, den Token-Verkauf zu priorisieren. Denn das ist für sich genommen bereits ein großartiges Geschäft
Diese Logik zeigt höchstens, dass es Grenzen gibt. Tokens sind nicht so mächtig, dass sie sofort in jedem Bereich der Software unbegrenzt Geld erzeugen. Das scheint zu stimmen
Am Anfang untersagten viele Unternehmen ihren Mitarbeitern aus Sicherheitsgründen, Quellcode in entfernte LLMs einzugeben. Jetzt glauben viele Unternehmen aus Sicherheitsgründen, dass ihr gesamter Quellcode von entfernten LLMs analysiert werden sollte
Wenn es normal wird, Anthropic zu vertrauen, können sie mehr Services verkaufen, die Zugriff auf Quellcode benötigen
Etwas anderes, aber es sieht so aus, als würde jemand alle guten GitHub-Links in diesem Beitrag mit dead/flag abschießen, und ich weiß nicht, warum
Ein einziges Loch zu finden ist immer leichter, als alle Löcher zu stopfen. Hacker haben dieselben Tools, also ist das ein nicht zu gewinnendes Wettrüsten
Die genannte Asymmetrie war bereits in Software vor LLMs eine vorhandene Eigenschaft
Ziemlich interessant. Ich habe eine Weile ein ähnliches Tool gebaut und benutzt:
https://github.com/bobinson/vulture
Ich habe wegen False Positives damit gekämpft und Claude + MCP wie ein Audit-Tool für Leute mit kleinem Budget verwendet. In den letzten Tagen habe ich mit von Nvidia gehosteten Modellen bessere Ergebnisse erzielt
Bevor man weiß, ob Claude mit diesem Harness Tokens effizient nutzt, ist es möglicherweise nicht so nützlich, wie es klingt
Es ist klar, dass Anthropic inzwischen Harnesses für bestimmte Use-Cases baut und als Produkte anbietet
So etwas wie Claude Design für Sicherheit
Der Harness ist anders, das Packaging ist anders, und die Zielpersona ist anders, also ist natürlich auch der Vertriebsweg anders
Interessant ist, dass man, wenn man sich Unternehmensbeiträge über Mythos ansieht, feststellt, dass alle ihr eigenes Harness bauen. Cisco hat sogar die Spezifikation eines davon veröffentlicht
Aber Anthropic ist derjenige, der herausgefunden hat, wie man das paketiert und vertreibt. Eine großartige Go-to-Market-Strategie