Zwei Engines, ein Audit

Lassen Sie zwei erfahrene Reviewer denselben Pull Request lesen, und Sie bekommen zwei verschiedene Listen. Der eine bemerkt, dass die Kennung in der URL nie gegen die Session geprüft wird; der andere sieht, dass die Retry-Schleife bei jedem Fehlschlag eine Datenbankverbindung offen lässt. Keiner liegt falsch, keiner ist vollständig. Sprachmodelle verhalten sich aus demselben Grund genauso: Was ein Reviewer bemerkt, hängt davon ab, was er zuvor gesehen hat.

Übereinstimmung ist ein Signal

Ein einzelnes Modell nennt Ihnen seine Konfidenz. Dieser Wert ist etwas wert, aber er ist selbst berichtet: Das Modell benotet die eigene Hausaufgabe. Wenn zwei Modelle aus verschiedenen Laboren, mit verschiedenen Daten und verschiedenen Schwächen unabhängig voneinander dieselbe Schwachstelle in derselben Datei finden, ist diese Übereinstimmung ein Beleg von außerhalb des Modells. Näher kommt ein automatisiertes Review einer zweiten Meinung nicht.

Die Umkehrung zählt genauso. Ein Befund, den nur eine Engine meldet, ist nicht automatisch falsch, und ihn zu verwerfen hieße, genau die Bugs wegzuwerfen, die ein einzelner Reviewer gut findet. Er gehört gemeldet und zugeordnet, damit Sie selbst abwägen können.

Wo eine Engine schweigt

In der Praxis weichen die beiden Engines dort am stärksten voneinander ab, wo Denken statt Mustererkennung nötig ist:

• Logikfehler: ein doppelt angewandter Rabatt, ein Zustandsautomat, der nach einer Rückerstattung noch eine akzeptiert, eine Besitzprüfung am falschen Objekt.
• Framework-spezifische Autorisierung: Middleware, die eine Routengruppe schützt, aber nicht den daneben eingehängten API-Handler.
• Ressourcen- und Speicherlecks: Listener, Timer und Verbindungen, die pro Request geöffnet und nur auf dem Happy Path freigegeben werden.
• Prompt Injection, versteckt in Kommentaren oder Testdaten, die sich wie harmloser Text liest, wenn man nicht danach sucht.

Wie aus zwei Berichten einer wird

Beim Zusammenführen zahlt sich die zweite Engine entweder aus, oder sie verdoppelt Ihr Rauschen. Die Regeln, auf die wir uns festgelegt haben:

• Befunde werden über das abgeglichen, was einen Bug ausmacht, nicht über die Formulierung: seine CWE-Klasse und die Datei, in der er steckt.
• Eine Übereinstimmung wird einmal gemeldet, mit der strengeren der beiden Schweregrade, denn die sichere Lesart ist die, nach der man handelt.
• Behalten wird die Fassung, mit der ein Entwickler arbeiten kann: der längere Nachweis, der konkrete Patch, die geordneten Schritte.
• Ein bestätigter Befund wird auf hohe Konfidenz gesetzt und mit beiden Engines gekennzeichnet.
• Ein Befund, den nur eine Engine gesehen hat, bleibt erhalten, markiert mit der Engine, die ihn gefunden hat.

Beide Engines lesen dieselbe Quelle gleichzeitig, das Audit dauert also nicht doppelt so lange; es kostet doppelt so viel im Betrieb, und deshalb gehört es zum Pro-Tarif. Ist die zweite Engine nicht verfügbar oder liefert sie Unbrauchbares, wird das Audit mit der ersten abgeschlossen, statt zu scheitern.

Nichts davon macht einen Bericht wahr. Zwei Engines können sich einig sein und beide falsch liegen; der zitierte Nachweis unter jedem Befund steht genau dafür da, dass Sie prüfen statt vertrauen. Was die Bestätigung bringt, ist eine Reihenfolge: Wenn hundert Befunde eintreffen und Sie einen Nachmittag haben, fangen Sie mit denen an, die zwei unabhängige Reviewer beide gesehen haben.