So bleibt Figma mit seinen Agenten Sicherheitslücken immer einen Schritt voraus

Es ist ganz einfach, Coding-Agenten auf den Code anzusetzen und sie zu beauftragen, Schwachstellen zu finden. Die für ein Unternehmen erforderliche Genauigkeit und Erkennungsrate zu erreichen, ist nach wie vor eine technische Herausforderung: Wie viele Ergebnisse sind stichhaltig, und wie viele echte Fehler erkennt das System?

In diesem Beitrag erklären wir, wie wir mit Genauigkeit, Erkennungsrate und Vertrauen umgehen, wenn es darum geht, agentische Sicherheit für die Codebasis von Figma zu gewährleisten. Wir verwenden Agenten, um Schwachstellen in drei Phasen zu verhindern, zu erkennen und zu beheben: Coden-Generierung, Pull-Anfrage-Überprüfung und Prüfung des historischen Codens.

Wir werden unsere Erkenntnisse aus all diesen Phasen teilen und dabei den Großteil unserer Zeit der PR-Prüfung widmen – dem ersten Modul, das wir entwickelt haben und das die sichere Codegenerierung und -prüfung ermöglicht hat, indem es uns dabei half, die Richtlinien zu entwickeln und automatisch zu verbessern, an die sich alle unsere Sicherheitsagenten halten.

Sichere Codeüberprüfung

Wir haben zuerst die Überprüfung implementiert, weil deren Verbesserungszyklus schneller ist als der bei der Generierung oder der Prüfung. Drei Eigenschaften machen diese Schleife effektiv:

1. Sie ist universell: Jede Pull-Anfrage durchläuft sie.
2. Sie läuft im Self-Service-Modus: Bei der Prüfung werden Anmerkungen zur PR gemacht, und der*die Autor*in reagiert direkt auf die Ergebnisse.
3. Sie ist in beide Richtungen instrumentiert: Genauigkeit und Erkennungsrate erhalten jeweils ein eigenes Signal.

Das Genauigkeitssignal ist die Bewertung des Autors / der Autorin: Bei den wenigen PRs, in denen ein Researchergebnis erwähnt wird, gibt der*die Autor*in ein „Daumen hoch“ oder „Daumen runter“ ab, meist mit einer Begründung. Um die Erkennungsrate zu messen, lassen wir den Prüfer Commits durchgehen, von denen wir bereits wissen, dass sie Fehler enthalten, und zählen, was er*sie übersieht.

Wir lassen derzeit sowohl Claude Code mit Opus 4.8 in der Einstellung „xhigh“ (extra hoch) als auch Codex mit GPT-5.6 Sol in der Einstellung „high“ laufen, da sie unterschiedliche Fehler übersehen. Wenn eines der beiden Modelle ein Ergebnis liefert, leiten wir es weiter.

Einige der Schwachstellen, die unser Prüfer entdeckt, beinhalten komplexe mehrstufige Ketten. In einem kürzlich veröffentlichten PR argumentierte er, dass ein injiziertes Sandbox-Objekt den Function-Konstruktor des Host-Realms preisgab und so einen Weg für die Codeausführung im Desktop-Client eröffnete.

Das meiste, was er findet, ist eher alltäglich, aber es lohnt sich trotzdem, es zu reparieren. Bei anderen PR vor kurzem hat der Prüfer zum Beispiel einen Endpunkt beanstandet, der eine Rechnung anhand einer vom Aufrufer angegebenen ID zurückgab, ohne zu überprüfen, ob die Rechnung zur Organisation des Aufrufers gehörte – was bedeutet, dass jeder authentifizierte Nutzer die Rechnungen einer anderen Organisation einsehen konnte, sobald er die ID kannte. Hier ist eine stark vereinfachte Version des Befunds:

Wie wir angefangen haben

Im August 2025 veröffentlichte Anthropic den Claude Code Security Reviewer. Wir haben ihn am Release-Tag ausgerollt, allerdings im Shadow-Modus, sodass die Ergebnisse an Slack und Datadog gingen und nicht in die PR-Kommentare. Es handelte sich um einen ziemlich gewöhnlichen Zwei-Schritt-Prüfer, der zunächst mögliche Schwachstellen aufspürte und anschließend die Fehlalarme unter adversarischen Gesichtspunkten herausfilterte. Wir haben festgestellt, dass das System bei der Anwendung auf echte Vorfälle mit nur minimalen Anpassungen genau die eigentliche Ursache ermittelt hat und sich gut auf alle Bereiche übertragen ließ – von der Anwendungssicherheit bis hin zu Fehlkonfigurationen in der Infrastruktur.

In der ersten Woche waren jedoch nur etwa 15 % der Funde (4 von 27) gültig. Das ist das Vertrauensproblem, das hinter OpenAIs Argument steckt, dass Genauigkeit wichtiger ist als Erkennungsrate: Entwickler*innen verlieren das Vertrauen in jedes Tool, das sie mit minderwertigen Ergebnissen überschüttet. Genauigkeit musste an erster Stelle stehen – was nicht unbedingt die Reihenfolge ist, die man vermuten würde. Man würde erwarten, dass die von uns bereits gefundenen Bugs unser größter Vorteil wären, aber als Evaluierungen wiederholt, messen sie nur den Rückruf und trugen nichts zur benötigten Genauigkeit bei.

Wir haben Kommentare zu PRs, die für Entwickler*innen gedacht sind, zurückgehalten, bis die Genauigkeit über einen zweiwöchigen Rückblick hinweg über 70 % blieb, ohne peinlich schlechte Fehlalarme. Um diese Hürde zu überwinden, haben wir die Prüfer über die vorherigen acht Wochen von PRs erneut abgespielt und als Sicherheit Team die Fehlalarme selbst manuell gekennzeichnet. Von dort aus haben wir die Richtlinie geschrieben, der der Agent folgen soll.

Nach den Best-Practices für Prompts besteht die Richtlinie aus Präzedenzfällen statt aus Regeln. Zum Beispiel schreiben wir statt „SQL-Injektionen in dbops nicht markieren“ etwas wie „dbops wird nur von hoch privilegierten Bedienern ausgeführt, die bereits direkten Datenbankzugriff haben.“

Neunundneunzig Zeilen, 2.560 Wörter und 68 Präzedenzfälle später hatte diese Arbeit einen Neben-Effekt, den wir nicht als Abo vorgesehen hatten: Wir hatten ein vollständiges Bedrohungsmodell geschrieben, ungefähr in der Form, die wir wollen, dass ein neuer Mitarbeiter am ersten Tag liest. Die Richtlinie ist das Bedrohungsmodell. Agenten benötigen Sicherheitskontext in einem expliziten, strukturierten Format und mit einer ungewöhnlich hohen Auflösung. Im ersten Jahrzehnt von Figma hat sich dieses Wissen in Dokumentationen, Vorfallanalysen und tiefem institutionellen Wissen angesammelt. Es war noch nicht auf die Ebene konsolidiert, die ein Agent benötigt. Dieses Artefakt ist der eigentliche Lohn. Sichere Codegenerierung und repository-weite Überprüfungen laufen auf dem gleichen Bedrohungsmodell, sodass wir es nie zweimal erstellen mussten.

Vom Prototyp zur Produktionsinfrastruktur

Innerhalb eines Monats nach dem Start stieg die Genauigkeit durch die Iteration der Richtlinie auf 80 % bei einem Rückblick von zwei Wochen, wodurch wir unsere 70%-Marke locker überschritten. Zu diesem Zeitpunkt haben wir entwicklerorientierte Kommentare aktiviert. Die Genauigkeitsrate verbesserte sich insgesamt weiterhin, was es uns ermöglichte, die Anforderung einzuführen, dass keine Pull-Request ohne einen abgeschlossenen Überprüfungsvorgang zusammengeführt werden darf.

Dann kam der wenig glamouröse Teil. Die Überprüfung zur Voraussetzung für ein Zusammenführen zu machen, verwandelte es von einem Nice-to-have in eine Infrastruktur, und Infrastruktur muss langweilig sein, um vertrauenswürdig zu sein. Wir haben Ausweich- und Wiederholungsrichtlinien für Anbieter hinzugefügt, damit ein Ausfall bei einem Modelldienstleister eine PR nicht ungeprüft durchrutschen lässt. Wir haben Telemetrie zu Datadog und Slack hinzugefügt, weil wir den Moment wissen mussten, in dem Genauigkeit oder Rückruf nachlässt. Wir haben auch ein Tracking der Reparaturrate hinzugefügt, weil unser ultimatives Ziel darin besteht, Schwachstellen zu beheben, nicht nur sicherzustellen, dass sie lediglich sichtbar werden.

Bis Dezember 2025 waren wir aus der GitHub-Action von Anthropic herausgewachsen und hatten sie in dreierlei Hinsicht neu aufgebaut:

• Den Prüfer in einen TypeScript-Dienst verschoben. Unser Fork der Action war für einen Prototyp in Ordnung, wurde jedoch schnell zu einem großen GitHub-Workflow, der nicht leicht zu warten war. Wir haben ihn in einen kleinen TypeScript-Dienst überführt, was es dem Prüfer erleichterte, beobachtet und iteriert zu werden. Dies ermöglicht es uns auch, Claude coden und Codex unabhängig zu betreiben und bei Fehlern erneut zu versuchen.
• Der größte Teil des Prompts wurde entfernt (auch „abliert“ genannt). Agenten und Modelle sind viel besser geworden im Kontextmanagement und der Langkontextsuche. Wir kamen zu dem Schluss, dass der Prüfer überhaupt keinen separaten adversariellen Durchgang benötigte und fügten das Filter in einem einzigen Prompt zusammen. Neuere Frontier-Modelle müssen nicht mehr lernen, wie man eine Schwachstelle findet oder an die OWASP Top 10 erinnert werden.
• Ein Schiedsrichter hinzugefügt. Der Prüfer übersah immer wieder echte Bugs, und bei der Analyse der Evaluierungsdaten stellten wir immer wieder dasselbe Muster fest: Auf der Jagd nach Genauigkeit redete sich der Agent mit „vorgegebenem Muster“, „geringem Vertrauen“ oder „Vorbereitung“ aus wahren Erkenntnissen heraus. Der erste Durchgang gibt bereits die Kandidaten aus, die er als strukturierten Output fallen ließ, daher haben wir einen zweiten Durchgang hinzugefügt, der diese grenzwertigen Abweisungen erneut untersucht. In unseren Bewertungen mit bekannten schlechten Commits erhöhte die Schiedsgerichtsbarkeit den Rückruf der Bestehensrate um relativ ~30%.

Metriken

Wir waren zuversichtlich, dass der Prüfer präzise war, und Backtesting gab einen Hinweis darauf, dass er auch eine gute Rückrufquote hatte. Der nächste Schritt war es, zu festigen, wie wir den Rückruf, die Genauigkeit und die Fixrate messen und verbessern.

Erkennungsrate mit Auswertungen messen

Wir messen die Erkennungsrate durch ein allgemeines Evaluierungs-Framework. Da dies bekannte Sicherheitslücken misst und nicht das, was noch auftaucht oder unbekannt ist, betrachten wir es als Mindestmaß, das der Agent bestehen muss, anstatt als Beweis für die Abdeckung.

Das Framework verwendet einen wachsenden Korpus von 66 Aufgaben, von denen jede eine echte Verwundbarkeit darstellt, die bei der menschlichen Überprüfung übersehen wurde und nur später durch einen Bounty, einen Vorfall oder eine Prüfung zum Vorschein kam. Sechsundvierzig der 66 Aufgaben sind aus unserem HackerOne-Bug-Bounty-Programm gekennzeichnet (24 davon von einem einzigen Spitzenforscher) und die restlichen 20 stammen aus internen Vorfällen und Audits.

Jede Aufgabe wird durch eine kleine YAML-Datei repräsentiert, die den Root-Cause-Commit, eine Beschreibung der Schwachstelle, eine Bewertung, die sie gewichtet, und einige Tags (Erkennungsquelle, Vorfallkanal oder Forscher) enthält.

# evals/pr-review/doc-export-idor.yaml
name: "doc-export-idor"
tags: ["authz", "bug-bounty"]
score: 10000

commit: "<root-cause-commit-sha>"

description: >
  A document export endpoint trusts a document id from the request and returns
  the file without checking whether the caller may access it. Any authenticated user
  can export another user's private document.

Das Framework checkt jeden Commit in ein eigenes, isoliertes Git-Arbeitsverzeichnis aus, um eine saubere Analyse durchzuführen, führt den Prüfer aus und bewertet, was es findet. Der Aufgabenbewerter ist ein einfaches LLM-als-Richter, das sich auf die Beschreibung konzentriert und überprüft, ob das Ergebnis der Prüfung dasselbe Problem erfasst (auch wenn es anders beschrieben wird).

Wir führen zwei Arten von Bewertungen durch:

• Bewertung der Erfolgsquote zeigt uns, welcher Prozentsatz der Aufgaben bestanden wurde und bietet eine Abdeckungsgrundlage über bekannte Bugs hinweg.
• Payout-gewichtete Bewertung wird normalisiert auf das, was jeder Bug in unserem Prämienprogramm ausgezahlt hat, mit einer geschätzten Auszahlung für die, die das Programm nicht erfasst hat. Dies zeigt uns, wie wir bei den Bugs abschneiden, die am meisten zählen, die dazu neigen, sich in einigen wenigen hoch bewerteten Klassen zu konzentrieren.

Beachte, dass jede Aufgabe im Korpus einen Fehler darstellt, der bei unserem bisherigen Überprüfungsprozess – bestehend aus manueller Überprüfung und statischer Analyse (SAST) – bereits übersehen wurde. Ein 75,8%iger Erfassungsgrad ist also 75,8% der Bugs, die an all unseren bestehenden Kontrollen vorbeigegangen sind. So sehen diese Metriken mit den neuesten Frontiermodellen aus:

Jede Richtlinienänderung wird von einem Sicherheit Ingenieur überprüft und erneut gegen den gesamten Korpus getestet, bevor sie veröffentlicht wird. Das fängt Regressionen bei den uns bereits bekannten Bugs ab; es sagt uns nichts über die, die wir noch nicht entdeckt haben.

Was die Richtlinie wert ist

Um zu sehen, was die Technik im Vergleich zum Rohmodell wert ist, haben wir denselben Claude coden-Reviewer ohne unsere gesamte Figma-Richtlinie getestet: nur „Schwachstellen finden“, das Modell und die Tools. Es erledigte immer noch 44,4% des Korpus bei Payout-Weight.

Während ein Frontiermodell genügend Schwachstellen ganz ohne Hilfe findet, ist unsere Richtlinie immer noch ein wesentlicher Vorteil. Mit unserer Richtlinie steigt derselbe einzelne Prüfer von 44,4 % auf 64,2 %. Genauigkeit ist die größere Lücke: Ohne Ausschlüsse kennzeichnet der leere Prompt jedes verdächtige Muster. Wir können dafür aus diesem Durchlauf keine Zahl angeben, da der Korpus nur echte Positive enthält und nur die Erkennungsrate misst, aber jeder, der ein Codierungsagent auf sein eigenes Repo losgelassen hat, hat genau das gesehen.

Messung der Genauigkeit mit menschlichem Feedback

Das Genauigkeitssignal kann nicht aus dem Auswertungskorpus stammen, da es sich um alle wahren positiven handelt; es erscheint nur bei Live-PRs. Wir haben einmal manuell markiert, um einen Ausgangspunkt zu schaffen, aber wir können das nicht ständig wiederholen. Echte Ergebnisse sind selten, daher würde eine ständige Offline-Genauigkeitszahl bedeuten, dass der Prüfer über weit mehr PRs laufen müsste, als wir manuell überprüfen könnten, nur um genügend Ergebnisse zu sammeln, um zu urteilen, und dann nach jeder Richtlinienänderung diesen Durchlauf neu zu machen, da alles, was wir tun, um die Erinnerung zu erhöhen, auch die Genauigkeit verschieben kann. Daher messen wir die Genauigkeit in der Produktion.

Der Prüfer läuft bereits bei jedem PR, und der Autor kennt seine eigene Änderung besser als ein Sicherheitstechniker, der sie zum ersten Mal sieht. Daher geht die erste Entscheidung bei jedem Fund an sie, obwohl sie nicht endgültig ist. Ein separater Agent liest regelmäßig den aktuellen Coden hinter den neuesten Funden und jeder umstrittene oder unbehandelte Fall, dessen markiertes Muster noch vorhanden ist, geht an den Sicherheits-Rufbereitschaftsdienst zur Entscheidung. Da Funde selten sind, stoßen PR-Autoren nur gelegentlich auf sie.

Mit Opus 4.7 hatten wir von Ende April bis Ende Mai 2026 eine durchgehende Phase ohne strittige Befunde. Die Genauigkeit nahm einen kleinen Rückgang, als wir zu Opus 4.8 wechselten, was wir als akzeptablen Kompromiss für die Verbesserung der Rückholquote durch das Nachverfolgen tieferer, mehrstufiger Exploit-Ketten ansehen.

Messung der Fix-Raten

Nichts davon spielt eine Rolle, wenn die Bugs nie Fixed werden, daher verfolgen wir die Fix-Raten vor dem Zusammenführen, wobei ein zweiter Agent jede Feststellung als Fixed (Fixiert), umstritten, anerkannt, nicht adressiert oder noch ausstehend kennzeichnet. Die Verbesserung dieser Kennzahl erfordert etwas soziale Beeinflussung, weil eine echte, gut geschriebene Feststellung immer noch in Konkurrenz zu allem anderen steht, was ein Entwickler benötigt. Wir haben überlegt, Zusammenführungen bei einem offenen Befund hart zu blockieren, haben uns aber letztendlich dagegen entschieden, da die folgenden geringfügigen Änderungen unsere Fehlerbehebungsrate deutlich verbessert haben, ohne dass wir dafür einen so hohen Reibungsverlust in Kauf nehmen mussten.

Zunächst haben wir die Fußzeile des Kommentars von einem unscheinbaren „Fragen?“ Frag #security. Falsch positiv? Klick auf 👎 und schließ das Fenster. Entschuldige das Informationsrauschen.“ zu einem (im wahrsten Sinne des Wortes) kräftigeren 🎯 Wir optimieren diese anhand von Evaluierungen und menschlichem Feedback, um eine hohe Signalstärke zu erreichen. Bitte geh auf diesen Fund ein. Klicke bei Fehlalarmen auf 👎, um uns dabei zu helfen, die Signalstärke hoch zu halten. Fragen? #security.“

Zweitens beschränkten wir das Ausgabeformat auf einen ein-Satz-Befund, nummerierte Exploit-Schritte, eine kurze Empfehlung und relevante coden-Links. Das beseitigt die Angewohnheit von Opus-4.5+-Modellen, in eine Textwand zu verfallen.

Wie wir den Agenten verbessern

Wir haben zwei Arten von Selbstverbesserungsschleifen für den Agenten, eine für den Abruf und eine für die Genauigkeit. Beide stärken unsere Richtlinie, damit wir in Zukunft vermeiden, die gleichen Fehler zu wiederholen.

Erkennungsrate: Blindstellen im System beheben

Nehmen wir an, einer unserer Bug-Bounty-Forscher auf HackerOne findet eine Schwachstelle in Figma und meldet sie. Hier ist der Kreislauf:

1. Ein Cloud-Agent übernimmt den Bericht und triagiert ihn.
2. Der Agent filtert die Berichte von geringer Qualität heraus (etwa 75 % der Einsendungen) und erkennt diesen als anders: eine seltene Exploit-Kette. Beachte, dass das Monorepo die Validierung für den Agenten überschaubar macht, da sich unsere gesamte Anwendungslogik dort befindet. Wir glauben, dass das Coden für die Validierung einer extern gemeldeten Schwachstelle mehr als ausreichend ist – die Erzeugung von Exploits ist nicht erforderlich.
3. Der Agent schreibt eine Korrektur und öffnet ein PR. Die Sicherheit auf Abruf überprüft den Patch und führt ihn zusammen.
4. Der Agent verfolgt die Schwachstelle bis zu dem Commit zurück, der sie eingeführt hat, und fügt diesen Commit unserem Evaluationskorpus hinzu.
5. Ein zweiter Agent läuft mit unserem bestehenden PR-Reviewer-Agent gegen diesen Root-Cause-Commit.
6. Wenn der Prüfer den Bug nicht erkennt, liest der zweite Agent die Chat-Protokolle des Prüfers, findet heraus, warum er vorbeigegangen ist (Wurde die Datei überhaupt gelesen?) Gelesen, aber nicht markiert? Markiert, aber ausgeschlossen?), aktualisiert die Richtlinie, bis der Prüfer den Bug erkennt, und eröffnet einen Pull Request mit der Änderung.
7. Aufmerksame Sicherheit prüft die Richtlinienänderung und passt sie bei Bedarf an.

Der Fix behebt diesen einen Bug. Das Aktualisieren der Richtlinie ist wichtiger, da es den Prüfer dazu bringt, jeden zukünftigen Bug dieses Typs während der PR-Prüfung zu erkennen. So verbessern wir den Rückruf automatisch.

Wir setzen an mehreren Stellen in diesem Prozess Menschen ein, weil wir immer noch menschliches Urteilsvermögen bei dem, was wir zusammenführen wollen, schätzen, insbesondere wenn ein externer Forscher den Bug gemeldet hat. Darüber hinaus kann die automatisierte Richtlinienverfeinerung immer noch überanpassen (“Goodhart”) auf den einen Bug, den sie vor sich hat, oder eine ausführliche Ergänzung produzieren, die kein Mensch lesen möchte.

Genauigkeit: Reduzierung der Häufigkeit von Fehlalarmen

Wenn ein*e PR-Autor*in einen Kommentar als Fehlmeldung ignoriert – entweder durch eine Daumen-runter-Reaktion, einen erklärenden Kommentar oder beides – führen wir eine vereinfachte Version der bisherigen Schleife durch.

1. Eine Agenten-Skill läuft und aktualisiert die Richtlinie, damit diese Klasse von Fehlalarmen nie wieder auftaucht. Sie berücksichtigt Entwicklerfeedback und durchsucht Chat-Transkriptionen, um herauszufinden, warum das Modell den Fehler gemacht hat.
2. Aufmerksame Sicherheit prüft die Richtlinienänderung und passt sie bei Bedarf an.
3. Wir führen den Prüfer gegen das Baseline-Evaluierungskorpus mit der aktualisierten Richtlinie aus.

Sicheres Code-Audit

Audits laufen mit genau der gleichen Richtlinie, die wir für die PR-Überprüfung erstellt haben. Das Bedrohungsmodell, das wir ausformulieren mussten, um die Überprüfung präzise zu machen und das durch die oben beschriebenen Feedback-Schleifen kontinuierlich verbessert wird, ist das, was Audits überhaupt erst möglich macht. Der Hauptunterschied besteht hier darin, dass wir den Agenten und die Richtlinie auf das gesamte Monorepo richten, anstatt auf einen einzelnen PR.

Das ist nicht nur für historischen coden wichtig (unser Monorepo ist älter als 10 Jahre), sondern auch im stetigen/zukünftigen Zustand. Modelle sind stochastisch und könnten nicht alles in einem einzigen Prüfungsdurchlauf zeigen. Außerdem entwickelt sich unser Bedrohungsmodell ständig weiter, und jede neue Modellgeneration kann Schwachstellen erkennen, die das vorherige nicht konnte.

Auditierung ist sowohl für Agenten als auch für Menschen eine schwierigere Aufgabe als die Überprüfung. Wenn du eine*n Entwickler*in bittest, einen Fehler in einem PR zu finden, wird er*sie das gut hinbekommen. Gib einem*einer Entwickler*in einen zehn Jahre alten Code und sag ihm*ihr, er*sie soll alle Fehler finden – er*sie wird nicht wissen, wo er*sie anfangen soll. Das gilt auch für Agenten.

Wir haben die Aufgabe durch brutales Durchprobieren des Problems mit vielen Agenten lösbar gemacht. Wir wählten ein Kostenbudget und, da wir ungefähr wussten, was ein Agent kostet, um ein Bereich zu scannen, wandelten wir es in eine Anzahl von Agenten-Splittern um und scannten dann. Wir splitten meistens nach Datei oder Anwendungsrouten. Zwei weitere Anpassungen halfen: das Ablieren von Bug-Klassen mit geringer Schwere, damit das Budget dort hingeht, wo es wichtig ist, und die Rückkehr zu einer leichten gegnerischen Überprüfung, um Bugs zu widerlegen.

Bei unserem ersten Durchlauf fanden wir mehr als hundert latente Schwachstellen, darunter zwei kritische, die von herkömmlichen SAST-Tools übersehen wurden und die wir umgehend behoben haben. Wir haben beide zu unserem Evaluierungskorpus hinzugefügt, wo sie jetzt die beiden höchstbewerteten Aufgaben sind.

In jüngerer Zeit haben wir dynamische Workflows für reaktionsweite Audits mit vielversprechenden frühen Ergebnissen ausprobiert, jedoch mit unvorhersehbarer Token-Nutzung. Wir könnten unser reaktionsweites Audit-Multi-Harness gegen dynamische, Workflow-ähnliche Systeme austauschen, wenn sie ausgereift sind. Mit diesen Systemen können wir einfach „Schwachstellen finden“ an den Bedrohungsmodell-Zeiger geben, und sie parallelisieren Scans und führen bei Bedarf feindliche und Schlichtungspässe durch.

Sicheres Coden

Um Agenten bei der Erstellung von sicherem coden zu unterstützen, verwenden wir Hooks. Wir haben festgestellt, dass sie Agenten zuverlässiger lenken als die gleiche Anleitung in AGENTS.md. Bei einigen Bugklassen wie der Log-Sicherheit (Schreiben von Daten in die falschen Logs) lag der Rückgang nach der Einführung eines Anleitungshakens bei etwa 50 %. Wir pflegen eine vendored, agentenunabhängige Version von Anthropics Sicherheitsleitfaden-Plugin. Es hat zwei Sätze von Agenten-Hooks:

• Man fügt eine sofortige Anleitung ein, sobald ein Agent etwas Riskantes berührt, wie das Hinzufügen einer Route, das Ändern einer Berechtigungsrichtlinie oder das Protokollieren von Telemetriedaten.
• Das andere Team gibt das Diff regelmäßig an einen LLM oder, bei Commit, an einen zweiten Codierungsagenten zur Überprüfung weiter. Diese basieren auf der gleichen Richtlinie wie unser Prüfer und Auditor.

Hooks haben auch eine Eigenschaft, die der PR-Überprüfung fehlt: Sie haben keine hohe Genauigkeitsanforderung, weil sie für den menschlichen Autor weitgehend unsichtbar sind. Das erlaubt es uns, sie zu nutzen, um gute Praktiken zu fördern, nicht nur, um Schwachstellen zu vermeiden. Wenn ein Agent eine neue API-Route hinzufügt, kann ein Hook es darauf lenken, den richtigen sicheren Standard-Autorisierungs-Dekorator und Tests anzuhängen, anstatt nur Autorisierungs-Bugs aufzudecken.

Was wir gelernt haben

Wir können dir nicht genau sagen, was du tun sollst: Die Einzelheiten hängen von der Größe deines Unternehmens, den Risiken, denen du ausgesetzt bist, und den Feedback-Schleifen ab, die du bereits nutzt. Aber eine Hauptlektion ist, die Genauigkeit vor dem Abruf zu verbessern. Die Reihenfolge ist kontraintuitiv, denn mit den historischen Fehlern, die du bereits hast, lässt sich nur der Recall messen; sie helfen kaum bei der Präzision, die du zuerst beheben musst.

Eine weitere wichtige Lektion ist, dass Genauigkeit und Erkennungsrate aus verschiedenen Quellen stammen, was wir selbst herausfinden mussten. Die Erkennungsrate kommt vom erneuten Testen des Prüfers gegen bereits entdeckte Bugs und dem Zählen der verpassten. Genauigkeit hat kein festes Ziel zum erneuten Testen und verändert sich mit jeder Richtlinienänderung, daher gibt es keine dauerhafte Offline-Bewertung, die durchgeführt werden kann. Genügend der seltenen Live-Funde zu bewerten würde bedeuten, größtenteils harmlose PRs in einem Umfang zu durchforsten, den kein Team bewältigen könnte. In der Produktion läuft der Prüfer ohnehin bei jedem PR, sodass der Autor, der die Änderung geschrieben hat, den ersten Anruf tätigt, mit einem weiteren Agenten, der den aktuellen coden hinter jedem Fundstück erneut liest und jeden umstrittenen oder ungelösten Fall, dessen markiertes Muster weiterhin vorhanden ist, an interne Sicherheitsexpert*innen sendet.

Ein paar weitere Dinge, die wir gelernt haben:

• Jedem eingehenden Bug-Bounty-Bericht einen Triage-Agenten mit Zugriff auf den Quellcode zuweisen. Eine neuere Art von Bug-Bounty-Researcher*innen verknüpft Schwachstellen mit geringem Schweregrad zu Exploits mit großer Auswirkung. Schnelle Triage, Vertrauen aufbauen und behandeln Sie diese Forscher als einige Ihrer wertvollsten Sicherheits-Assets. Wir können uns nicht darauf verlassen, dass der Prüfer einen neuartigen Bug außerhalb des Bedrohungsmodells entdeckt. Diese fallen weiterhin an interne Sicherheitsexperten und externe Quellen wie das Bug-Bounty-Programm. Manuelle Triage ist zu langsam, um den gesamten Feedback-Zyklus zu erhalten, während ein Agent eine schnelle Triage ermöglicht, die Vertrauen mit Forschern aufbaut, bessere Bewertungen liefert und letztlich eine bessere Rückholquote erzielt.
• Make Agenten nicht nur nach Bugs, sondern auch für gute Praktiken überprüfen. Lass die Agenten prüfen, ob der Code die richtigen „Secure-by-Default“-Frameworks nutzt und eine echte Testabdeckung aufweist. Wenn du das überspringst, driftet die Codebase in eine Richtung ab, über die weder ein Mensch noch ein Modell logisch nachdenken kann. In allen drei besprochenen Phasen lassen wir separate Agenten laufen, um gegen Anti-Muster und Qualitätsprobleme zu wachen, die weit über die Bug-Suche hinausgehen, mehr als wir hier abdecken können.

Mit den richtigen Systemen an Ort und Stelle wechselten unsere Sicherheitstechniker von der Fehlerbehebung eines einzelnen Bugs auf einmal zur Erstellung der Richtlinie, die Hunderte von Bugs erfasst und Hunderte weitere Bugs verhindert. Es ist viel wie der Job, den wir schon immer hatten, nur mit mehr Hebelwirkung.