← Zurück zur Rangliste

Wie wir testen

Benchmarks sind nur so gut wie ihre Konfiguration. Hier erfahren Sie, wie wir messen, ob ein Modell echte Schwachstellen aufspüren kann und was das kostet.

1. 1

   Wähle echte Schwachstellen aus

   Wir beziehen bekannte CVEs aus der GitHub-Sicherheitsdatenbank, die zahlreiche Sprachen und Projekttypen abdeckt.

2. 2

   Den anfälligen Commit markieren

   Jedes Repo wird an einem Commit ausgecheckt, der unmittelbar vor der Behebung des Fehlers erfolgte.

3. 3

   Im Produktions-Harness ausführen

   Die Modelle laufen innerhalb derselben KI-Plattform, die wir mit „Code Security Audit“ und „ Aikido Attack“ ausliefern.

4. 4

   Zeige auf den anfälligen Codeausschnitt

   Da wir wissen, wo sich die einzelnen Schwachstellen befinden, konzentrieren sich die Untersuchungsagenten auf den anfälligen Code. Ein Fehlschlag spiegelt die Argumentation wider – und nicht verschwendete Mittel, die in den falschen Ecken des Repos verschwendet werden. Die Eingabeaufforderungen bleiben kurz und modellunabhängig.

5. 5

   Dreimal ausführen, dann die Ergebnisse zusammenfassen

   Die Modelle sind nicht deterministisch. Wir führen jedes Modell dreimal aus und werten eine CVE als gefunden, wenn sie bei einem der Durchläufe auftaucht. Durch die Zusammenfassung lassen sich Fehler aufspüren, die bei einem einzelnen Durchlauf übersehen würden, und dies spiegelt realistischer wider, wie diese Agenten in der Praxis eingesetzt würden.

6. 6

   Punktzahl, Abdeckung und Kosten zusammen

   Wir erfassen, wie viele CVEs jedes Modell neu entdeckt und welche Kosten dabei anfallen, da das leistungsstärkste Modell selten das preiswerteste ist. Außerdem vergleichen wir die Schlussfolgerungsebenen, sofern der Anbieter diese offenlegt.

---

Informationen zum Aufbau des Gurtzeugs

Ein „Harness“ verwandelt ein Sprachmodell in einen Prüfer. Ein universeller Programmierassistent ist für eine andere Aufgabe konzipiert, nämlich eine Aufgabe zu übernehmen und funktionierenden Code zu erzeugen. Weist man ihn auf ein Repository hin und fragt, ob es sicher ist, verhält er sich wie ein Entwickler, der nach offensichtlichen Fehlern sucht und aufhört, sobald er etwas Plausibles gefunden hat. Das Code-Sicherheitsaudit von Aikido ist anders aufgebaut. Es durchsucht die Codebasis nach möglichen Einstiegspunkten, untersucht jeden verdächtigen Ablauf eingehend und filtert die Ergebnisse so, dass wir nur echte Schwachstellen erhalten.

Da wir wussten, wo jede Schwachstelle lag, haben wir jeden Untersuchungsagenten direkt auf das anfällige Code-Snippet gerichtet. Auf diese Weise spiegelt ein Fehlschlag die Schlussfolgerung wider und nicht das Budget, das durch das Herumirren in der falschen Ecke der Codebasis verschwendet wurde. Das Modell muss immer noch den Fluss verstehen, die Ausnutzbarkeit beurteilen und korrekt berichten. Prompts wurden kurz und modellunabhängig gehalten, damit kein Anbieter durch die Formulierung bevorteilt wird.

---