Einen CodeAuditAgent-Bericht lesen und umsetzen

Ein Sicherheitsbericht nützt nur, wenn daraus gemergte Fixes werden. CodeAuditAgent-Berichte sind genau darauf ausgelegt: Jeder Befund ist konkret genug, um ihn schnell zu überprüfen, und bringt einen Patch mit, den Sie anpassen können. Dieser Leitfaden erklärt jeden Teil eines Berichts, wie Sie ihn ohne eigene Sicherheitsfachleute triagieren und wie Sie bestätigen, dass Ihre Korrekturen gewirkt haben.

Was auditiert wird

Ein Audit läuft entweder über ein öffentliches GitHub-Repository oder über ein Code-Snippet, das Sie einfügen. Bei Repositories liest CodeAuditAgent den Standard-Branch. Private Repositories lassen sich nicht per URL auditieren, und Kommentare in Pull Requests gibt es noch nicht; die Ergebnisse liegen im Dashboard und in den Exporten.

Wie viel von einem Repository gelesen wird, hängt von Ihrem Plan ab. Der Free-Plan umfasst 1 Repository, 3 Audits pro Monat und bis zu 20 Dateien pro Audit. Starter, für $49 pro Monat, umfasst 5 Repositories, 50 Audits und 40 Dateien pro Audit. Pro, für $199 pro Monat, umfasst unbegrenzt viele Repositories, 500 Audits und 80 Dateien pro Audit. Einzelne Dateien über 60 KB werden übersprungen. Die monatlichen Audit-Zähler werden zu Beginn jedes Kalendermonats (UTC) zurückgesetzt. Ein eingefügtes Snippet ist außerdem ein schneller Weg, eine einzelne Datei zu prüfen, die Ihnen Sorgen macht, bevor Sie das gesamte Repository auditieren.

Wenn Dateien wegen dieser Grenzen ausgelassen werden, ist der Bericht als Teilaufnahme gekennzeichnet. Nehmen Sie diese Kennzeichnung ernst. Ein sauberer Teilbericht bedeutet, dass die gelesenen Dateien sauber wirken, nicht dass das Repository es ist. Wurde ausgerechnet der Code ausgelassen, der Ihnen am wichtigsten ist, auditieren Sie ihn als eingefügtes Snippet oder in einem Plan, der mehr Dateien abdeckt.

Der Risikoscore

Am Anfang jedes Berichts steht ein Risikoscore von 0 bis 100; der Markdown-Export nennt daneben zusätzlich den Gesamtschweregrad. Höher bedeutet mehr Risiko. Er fasst die Befunde dieses Audits zusammen und ist für zwei Dinge nützlich: zu entscheiden, wie dringend Sie sich ein Repository ansehen sollten, und zu verfolgen, ob es mit der Zeit besser wird.

Lesen Sie in kleine Unterschiede zwischen nicht verwandten Repositories nicht zu viel hinein. Ein Score bezieht sich immer auf das, was auditiert wurde, und eine Teilaufnahme sieht weniger Code. Am aussagekräftigsten ist die Zahl beim Vergleich desselben Repositorys vor und nach den Korrekturen.

Schweregrad und Konfidenz

Jeder Befund hat einen Schweregrad und eine Konfidenz. Sie beantworten unterschiedliche Fragen: Der Schweregrad sagt, wie schlimm es wäre, wenn der Befund real ist, und die Konfidenz, wie sicher sich der Reviewer ist, dass er real ist.

• Critical: direkt ausnutzbar mit schwerwiegenden Folgen, etwa Injection an einem öffentlichen Endpunkt, eine Umgehung der Authentifizierung oder offengelegte Produktions-Zugangsdaten.
• High: eine echte Schwachstelle, die eine Voraussetzung benötigt oder erhebliche, aber begrenzte Auswirkungen hat.
• Medium: eine Schwäche, die erst in Kombination mit anderen Fehlern zählt oder moderate Auswirkungen hat.
• Low: Härtungsthemen und Lücken in der Verteidigung in der Tiefe.
• Info: Beobachtungen, die man kennen sollte, die für sich genommen aber keine Schwachstellen sind.

Die Konfidenz ist hoch, mittel oder niedrig. Ein Befund mit hoher Konfidenz hat einen klaren Beleg im gelesenen Code. Ein Befund mit niedriger Konfidenz hängt meist von etwas ab, das das Audit nicht sehen konnte, etwa von Middleware in einer anderen Datei, einer Datenbankrichtlinie oder einem Konfigurationswert, der beim Deployment gesetzt wird. Niedrige Konfidenz heißt nicht ignorieren; sie heißt, dass ein Mensch den fehlenden Kontext prüfen sollte, bevor korrigiert wird.

Aufbau eines Befunds

Jeder Befund folgt derselben Struktur, sodass Sie ihn in einer gleichbleibenden Reihenfolge überprüfen können.

• Titel und CWE: die Klasse der Schwäche, etwa CWE-639 für eine Umgehung der Autorisierung über einen benutzerkontrollierten Schlüssel. Die CWE sagt Ihnen, welche Art von Fix zu erwarten ist.
• Fundort: Datei und Zeile, damit Sie den Code direkt öffnen können.
• Beleg: der relevante, aus der Datei zitierte Code. Prüfen Sie, ob das Zitat zu Ihrem aktuellen Code passt; hat sich die Zeile bereits geändert, kann der Befund veraltet sein.
• Exploit-Szenario: wie ein Angreifer die Schwäche tatsächlich nutzen würde, Schritt für Schritt. Das ist der schnellste Weg, um zu beurteilen, ob sie in Ihrem Kontext real ist.
• Remediation-Patch: ein Änderungsvorschlag im Stil des umgebenden Codes.

Betrachten Sie den Patch als guten Ausgangspunkt, nicht als merge-fertigen Commit. Er entsteht aus dem Code, den das Audit gelesen hat, und kennt daher möglicherweise Ihre Hilfsfunktionen, Ihre ORM-Konventionen oder einen Aufrufer an anderer Stelle in der Codebasis nicht. Ein typischer Patch ist klein und gezielt:

--- a/app/api/invoices/[id]/route.ts
+++ b/app/api/invoices/[id]/route.ts
@@
-  const invoice = await db.invoice.findUnique({ where: { id } });
+  const invoice = await db.invoice.findFirst({
+    where: { id, userId: session.user.id },
+  });
   if (!invoice) return Response.json({ error: 'not_found' }, { status: 404 });

Positive Beobachtungen und nächste Schritte

Berichte listen auch auf, was gut gelöst ist: durchgängig parametrisierte Abfragen, Secrets aus der Umgebung, eine strikte Cookie-Konfiguration. Diese Punkte lohnt es sich zu lesen. Sie zeigen, welche Muster Sie beibehalten und in neuen Code übernehmen sollten, und sie helfen, jemand anderem den Zustand einer Codebasis zu erklären.

Der Abschnitt mit den empfohlenen nächsten Schritten macht aus den Befunden einen geordneten Plan. Er gruppiert häufig verwandte Befunde, zum Beispiel mehrere fehlende Eigentümerprüfungen, die sich besser mit einer gemeinsamen Hilfsfunktion beheben lassen als mit fünf einzelnen Patches.

Ein Triage-Workflow für kleine Teams

Ohne eigene Sicherheitsfachleute besteht das Risiko nicht darin, einen Bericht zu ignorieren; es besteht darin, einen Tag mit niedrigen Befunden zu verbringen, während ein kritischer wartet. Eine einfache Reihenfolge bewährt sich:

• Lesen Sie zuerst jeden kritischen und hohen Befund. Lesen Sie bei jedem das Exploit-Szenario und entscheiden Sie: real, nicht real oder Kontext nötig.
• Beheben Sie reale kritische Befunde noch am selben Tag. Braucht ein Fix Zeit, ergänzen Sie eine vorübergehende Entschärfung, etwa das Abschalten des Endpunkts oder eine strengere Prüfung.
• Prüfen Sie bei Befunden, die Kontext brauchen, das fehlende Teil: Gibt es Middleware, eine Richtlinie auf Zeilenebene oder eine Konfiguration, die den Fall bereits verhindert? Halten Sie die Antwort schriftlich fest.
• Planen Sie hohe Befunde in den aktuellen Sprint, mittlere ins Backlog, und bündeln Sie niedrige und Info-Punkte in einem Härtungsdurchgang.
• Wenn ein Befund nicht real ist, halten Sie fest, warum. Diese Notiz erspart der nächsten Person die erneute Untersuchung.

Weisen Sie jeden Befund einer verantwortlichen Person zu. Befunde, die dem ganzen Team gehören, gehören meist niemandem.

Der Findings-Explorer und die Exporte

Sobald Sie mehrere Audits haben, arbeitet es sich mit dem Findings-Explorer leichter als mit einzelnen Berichten. Er listet Befunde über Audits hinweg auf und filtert sie nach Schweregrad, CWE und Repository. Besonders nützlich ist das Filtern nach CWE: Taucht dieselbe Schwäche in drei Repositories auf, deutet das meist auf ein gemeinsames Muster oder eine fehlende Hilfsfunktion hin, und das Muster zu beheben ist günstiger, als jeden einzelnen Fall zu korrigieren.

Befunde lassen sich aus dem Explorer als CSV exportieren, was sich gut in einen Issue-Tracker oder eine Tabelle importieren lässt. Einzelne Berichte lassen sich als Markdown exportieren, was sich gut in einer Pull-Request-Beschreibung, einem internen Wiki oder einer Nachricht an einen Dienstleister liest, der die Korrektur umsetzt.

Zur Bestätigung erneut auditieren

Ein Fix ist erst fertig, wenn Sie ihn geprüft haben. Starten Sie nach dem Merge ein neues Audit für dasselbe Repository. Jeder Bericht lässt sich mit dem vorherigen Audit vergleichen, sodass Sie sehen, welche Befunde verschwunden sind, welche bleiben und ob etwas Neues hinzugekommen ist. Der Risikoscore sollte sinken, wenn reale Probleme behoben wurden; tut er das nicht, sehen Sie im Vergleich nach, warum.

Halten Sie den Vergleich fair. War das erste Audit eine Teilaufnahme und hat das zweite andere Dateien gelesen, spiegelt der Unterschied auch die Abdeckung wider und nicht nur die Korrekturen. Audits gehen von Ihrem monatlichen Kontingent ab, daher lohnt es sich meist, mehrere Korrekturen zu bündeln, statt nach jedem Commit erneut zu auditieren.

Was ein Bericht nicht abdeckt

Die Grenzen zu kennen hilft, die Lücken zu füllen. Audits lesen Ihren Quellcode; sie prüfen keine Abhängigkeiten auf bekannte verwundbare Versionen, lassen Sie also zusätzlich einen Dependency-Scanner laufen, etwa den Ihres Paketmanagers oder den von GitHub. Audits sehen keine Konfiguration aus dem Deployment, keine Infrastruktur außerhalb des Repositorys und keine übersprungenen Dateien. Und wie jeder Reviewer, ob Mensch oder KI, kann sich auch das Audit irren: Belege und Konfidenzstufen sind dafür da, dass Sie es schnell nachprüfen können, statt ihm blind zu vertrauen.

So genutzt, wird aus einem Bericht eine kurze, priorisierte Liste von Änderungen mit Belegen. Beheben Sie die kritischen, prüfen Sie die unsicheren, auditieren Sie erneut und beobachten Sie, wie sich der Score bewegt.