KI-Sicherheitsanalyse-security-audit-skill
Einleitung
Große Sprachmodelle können Code lesen, Zusammenhänge über viele Dateien hinweg verfolgen und Werkzeuge bedienen. Damit liegt es nahe, sie für die Suche nach Sicherheitslücken einzusetzen. Offen ist, wie belastbar ihre Ergebnisse sind, denn ein falscher Befund ist in der Sicherheitsanalyse teuer.
Der Bericht folgt den vier Fragen:
- Welche Werkzeuge sind verfügbar und geeignet?
- Wie funktioniert eine KI-Agent-basierte Sicherheitsanalyse?
- Können die gefundenen Schwachstellen verstanden und verifiziert werden?
- Wo liegen Stärken, Schwächen und Kosten?
Werkzeugfamilien
- Klassische statische Analyse (SAST) wie Semgrep oder CodeQL ist schnell und reproduzierbar, findet aber vor allem Muster, die vorher als Regel formuliert wurden.
- KI-Ageten wie Claude Code lesen und durchsuchen Code selbstständig. Sie erkennen auch Logikfehler über Dateigrenzen hinweg, arbeiten aber nicht deterministisch.
Ein Skill ist ein Ordner mit Anweisungen, den ein KI-Agent bei Bedarf lädt und der festlegt, wie der Agent eine Aufgabe erledigt.
Der Cloudflare security-audit skill
Steckbrief
| Merkmal | Beschreibung |
|---|---|
| Herkunft | Cloudflare, großer Anbieter für den Schutz von Websites, auf GitHub unter MIT-Lizenz veröffentlicht |
| Bedeutung | Laut Blogartikel „Build your own vulnerability harness“ Ausgangspunkt für Cloudflares interne Schwachstellensuche, später ausgebaut zu einer Pipeline über mehr als 128 Repositories |
| Form | kein Scanner und kein Programm, sondern ein Ordner skills/security-audit/ mit rund 5.300 Zeilen Anweisungen und zwei Prüfskripten
|
| Modi | Anleitungsmodus (Standard): beantwortet Sicherheitsfragen ohne Berichtsdateien. Vollständiger Audit-Modus: Dieser wird nur auf ausdrückliche Anfrage („Security Audit“, „Pen-Test“, „Full Security Review“) durchgeführt und durchläuft alle sechs Phasen. Im Projekt wird nur dieser Modus verwendet. |
Bestandteile
Der Skill ist kein Scanner und kein Programm. Er ist ein Ordner skills/security-audit/ mit rund 5.300 Zeilen Anweisungen und zwei Prüfskripten:
| Datei | Aufgabe |
|---|---|
SKILL.md |
Einstieg: Betriebsarten, Sicherheitsregeln, Profile, Budget, Schweregradskala, verbotene Fehler |
RECONNAISSANCE.md |
Phase 1: Aufklärung des Projekts und Aufbau des Coverage Ledgers |
HUNTING.md, ATTACK-CLASSES.md |
Phase 2: Aufbau der Suchaufträge und Angriffsklassen (Injection, Zugriffskontrolle, Dateien, Kryptografie, Geschäftslogik …) |
| 10 Begleitdateien | Spezialwissen, nur bei Bedarf geladen: Web und Authentifizierung, Client-Seite, KI/LLM, Lieferkette, Cloud, Protokolle, Ressourcenerschöpfung, Datenisolation, Desktop/Mobil, Speichersicherheit |
VALIDATION-AND-REPORTING.md |
Phasen 3 bis 6: Validierung, Ausgabe, zweite Verifikation, Bericht |
report-schema.json |
festes JSON-Schema für jedes Ergebnis |
validate-findings.cjs, validate-coverage-ledger.cjs |
Node.js-Skripte, die die Ausgabe mit festen Regeln prüfen |
Warum die Prüfskripte wichtig sind: Ein Sprachmodell kann eine JSON-Datei schreiben, die richtig aussieht, aber unvollständig oder widersprüchlich ist. Die Skripte arbeiten ohne KI und lehnen etwa fehlende Felder, ungültige Pfade oder einen Schweregrad für einen unbestätigten Fund ab.
Vier Rollen
Der Skill macht aus einem Agenten ein kleines Prüfteam mit vier Rollen:
| Rolle | Name im Skill | Aufgabe |
|---|---|---|
| Koordinator | Parent | die Hauptsitzung in Claude Code; verteilt die Arbeit und schreibt als Einziger die gemeinsamen Dateien |
| Sucher | Hunter | Subagenten, die in einem zugewiesenen Codebereich und für eine Angriffsklasse nach Fehlern suchen |
| Prüfer | Verifier | neue Subagenten, die die Suche nicht kennen und jeden Fund zu widerlegen versuchen |
| Kritiker | Critic | Subagenten, die nach Codebereichen suchen, die niemand geprüft hat |
Prinzip: Wer findet, bewertet nicht. Ein Agent, der seinen eigenen Fund bewertet, neigt zur Selbstbestätigung; die Trennung entspricht dem Vier-Augen-Prinzip im Code-Review. Jeder Subagent arbeitet in agents/<agent-id>/scratch/ und liefert strukturiertes JSON an den Koordinator.
Sechs Phasen
| Phase | Was passiert | Ergebnis |
|---|---|---|
| 1 Aufklärung reconnaissance |
Der Koordinator startet vier Agenten gleichzeitig, die nur lesen:
|
architecture.md, coverage-ledger.json
|
| 2 Suche hunting |
Hunter erhalten Prüfeinheiten samt Angriffsklassen-Anweisungen im Wortlaut und verfolgen eine Eingabe bis zur kritischen Stelle (sink, z. B. Datenbankabfrage). Ein Kritiker sucht danach Lücken; diese werden neue Einheiten, falls das Budget eine weitere Welle erlaubt. | Kandidaten als JSON |
| 3 Validierung validation |
Kern des Skills: Ein neuer Prüfer liest jede zitierte Zeile erneut, sucht übersehene Schutzmechanismen und versucht zu widerlegen. | eines von drei Urteilen |
| 4 Strukturierte Ausgabe | Urteile werden geschrieben, Prüfskripte kontrollieren das Format. | findings.json
|
| 5 Zweite Verifikation | Weitere neue Agenten prüfen die Aussagen erneut; wesentliche Änderungen prüft ein zusätzlicher Agent. | bestätigte Datensätze |
| 6 Bericht | Bericht nur aus geprüften Datensätzen; er darf kein Urteil ändern. | REPORT.md, FINDINGS-DETAIL.md, NEEDS-VALIDATION.md
|
Endbedingung: Ein Lauf endet nie mitten in einer Phase. Entweder sind alle Berichtsdateien geschrieben und beide Skripte bestanden, oder der Lauf wird mit Grund als „incomplete“ markiert.
Urteile und Schweregrad
| Urteil | Bedeutung | Schweregrad? |
|---|---|---|
confirmed |
vollständige Codespur vom Eingabepunkt zur kritischen Stelle und lokal beobachtetes Ergebnis | ja |
needs_validation |
codebasierter Verdacht, dem genau ein Fakt fehlt, mit Prüfplan | nein |
rejected |
von einem Prüfer widerlegt | nein |
Einträge mit needs_validation heißen hier Verdachtsfälle (leads). Für „confirmed“ muss der Code ausgeführt werden; fehlerhaft aussehender Code genügt nicht.
| Schweregrad (nur bestätigte Funde) | Beispiel |
|---|---|
| critical | nicht angemeldeter Angreifer führt Code aus, erhält vollen Datenbankzugriff oder übernimmt beliebige Konten |
| high | Sicherheitskontrolle vollständig umgangen, z. B. Anmeldung umgangen, fremde Daten gelesen |
| medium | echte Grenzverletzung mit begrenzter Wirkung oder seltenen Voraussetzungen |
| low | Preisgabe nicht geheimer interner Informationen |
| informational | bestätigt, aber minimale Wirkung |
Coverage Ledger
Das Coverage Ledger zerlegt das Projekt in Prüfeinheiten. Jede Einheit ist eine Kombination aus vier Teilen: Eingabepunkt × Vertrauensgrenze × Teilsystem × Angriffsklasse, und einen Status
| Status | Bedeutung |
|---|---|
planned |
geplant, noch nicht begonnen |
in_progress |
ein Hunter arbeitet daran |
covered |
geprüft, kein Fund |
candidate |
enthält einen validierten Verdachtsfall |
blocked |
geprüft, enthält aber nur ungeprüfte Hinweise |
deferred |
zurückgestellt, meist wegen des Budgets |
out_of_scope, not_applicable |
außerhalb des Umfangs bzw. nicht zutreffend |
Die meisten Werkzeuge sagen, was sie gefunden haben, aber nicht, was sie nicht geprüft haben. Das Ledger macht Lücken in der Abdeckung sichtbar. Niemand kann „alles geprüft“ behaupten, solange Einheiten zurückgestellt sind.
Fingerabdruck
Jede Grundursache erhält eine feste Kennung, den Fingerabdruck (fingerprint), z. B. juice-shop/routes/login/raw-sql-string-interpolation. Er enthält keine Zeilennummer und bleibt daher auch bei kleinen Codeänderungen gleich. Damit lassen sich Läufe vergleichen.
Profile und Budget
| Profil | Bedeutung |
|---|---|
quick |
eine Suchwelle, ein abschließender Kritiker, ein Prüfer pro Kandidat. Für einen ersten Überblick. |
standard |
Suchwellen, bis die Kritiker keine Lücken mehr finden oder das Budget aufgebraucht ist, zwei Kritiker, zwei getrennte Prüfer pro Fall |
deep |
für große, kritische Projekte: feinere Einheiten, zusätzliche unabhängige Prüfung |
Das Budget ist die Höchstzahl der Agentenaufrufe über alle Phasen. Vor der Suche reserviert der Skill Aufrufe für Kritiker und Prüfer, damit die Hunter nicht das ganze Budget verbrauchen und am Ende niemand mehr prüfen kann.
Mehrere Läufe bauen aufeinander auf
Kennt ein zweiter Lauf den Ort des ersten, liest er dessen Ledger und Ergebnisse. Er konzentriert sich dann auf zurückgestellte Einheiten und ungeprüfte Hinweise und prüft alte Ergebnisse erneut. Laut Cloudflare findet ein einzelner Lauf etwa die Hälfte dessen, was wiederholte Läufe zusammen finden.
Sicherheitsregel: ohne Sandbox keine Ausführung
Zielcode darf nur in einer vom Betriebssystem erzwungenen Sandbox laufen: kein externes Netzwerk, leere Umgebung ohne Variablen und Passwörter, Zielcode nur lesbar, Schreiben nur im eigenen Arbeitsordner, harte Grenzen für CPU, Speicher, Prozesse und Laufzeit. Fehlt eine Eigenschaft, führt der Skill nichts aus, vermerkt einen Blocker und belässt den Fund bei needs_validation. Zudem verboten: Anfragen an produktive Systeme, Installation von Abhängigkeiten, echte Zugangsdaten, Änderungen am Zielcode (Korrekturen werden nur beschrieben).
Das Zielprojekt: OWASP Juice Shop
| Merkmal | Beschreibung |
|---|---|
| Was | fiktiver Saft-Webshop, absichtlich voller Lücken, für Sicherheitstrainings |
| Technik | Server: TypeScript, Node.js, Express, SQLite (Sequelize), MarsDB (In-Memory) Oberfläche: Angular · Anmeldung: JWT |
| Warum dieses Projekt | Lösungsschlüssel data/static/challenges.yml mit 116 Challenges liefert eine Referenz (ground truth), um Treffer und Lücken des Werkzeugs zu messen. Juice Shop ist nicht klein, dieser Vorteil überwiegt aber.
|
| safetyMode | schaltet ca. 19 gefährliche Challenges (Codeausführung, Dateizugriff) ab, sobald die App in Docker oder auf Heroku läuft; entscheidend für Fall Nr. 13 |
| Version | 20.2.0, Commit 5658473c vom 10.08.2026: „Add missing guard around lfrChallenge for safe mode“, sollte also den sicheren Modus verbessern
|
| Warum fester Stand | Sonst wäre unklar, ob ein Unterschied zwischen Läufen an der KI oder am Code liegt. |
Versuchsdurchführung
Versuchsdesign und Ablauf
| Merkmal | Lauf 1 | Lauf 2 |
|---|---|---|
| Profil | quick | standard |
| Budget | 25 Aufrufe | 60 Aufrufe |
| Vorwissen | keins | Lauf 1 (nur lesend) |
| Ausführung von Zielcode | nein | nein |
| Commit | 5658473c | 5658473c |
| Kandidaten je Hunter | 2 | 1 |
| Dauer | 26 Minuten | 3 h 13 Minuten (davon 1 h 37 min Wartezeit) |
| Aufrufe nach Rolle | ||
| Aufklärung | 4 | 4 |
| Hunter | 6 | 9 |
| Kritiker | 1 | 2 |
| Prüfer Phase 3 | 12 | 21 |
| Prüfer Phase 5 / erneute Prüfung | 1 | 21 |
| Summe erfolgreich | 24 von 25 | 57 von 60 |
| Fehlstarts durch Ratenlimit (nicht gezählt) | – | 20 |
Aufträge
Lauf 1:
Run a full security audit of this codebase using the security-audit skill. Profile: quick. Budget: 25 agent invocations. Source-only: do not execute target code; record anything that needs execution as needs_validation. Output to ~/ITS/audits/juice-shop/run-1
Lauf 2:
/security-audit Full audit of ~/ITS/targets/juice-shop. Profile: standard. Budget: 60 agent invocations. Source-only: do not execute target code; record anything needing execution as needs_validation. Prior run: ~/ITS/audits/juice-shop/run-1 (coverage-ledger.json, findings.json); do not modify run-1. Output: ~/ITS/audits/juice-shop/run-2
Beide Aufträge enthalten die ausdrückliche Bitte um ein vollständiges Audit (damit der Audit-Modus greift), Profil, Budget, die Regel „nur Quellcode“ und den Ausgabeort. In Lauf 2 musste der Ort von Lauf 1 angegeben werden, da der Skill frühere Läufe nur in seinem Standardordner ~/security-audit-skill/ selbst findet.
Ereignisse
Überblick
| Kennzahl | Lauf 1 | Lauf 2 |
|---|---|---|
Geprüfte Verdachtsfälle (needs_validation) |
12 | 21 (12 übernommen, 9 neu) |
| Bestätigt / verworfen | 0 / 0 | 0 / 0 |
| Ungeprüfte Hinweise | 23 | 33 |
| Prüfeinheiten im Ledger | 22 | 53 |
| davon covered / candidate / blocked / deferred | 0 / 11 / 1 / 10 | 4 / 21 / 20 / 8 |
| Prüfskripte (selbst nachgeprüft) | bestanden | bestanden |
Eigene Kontrolle der Prüfskripte
Die Skripte wurden von Hand erneut ausgeführt, statt der Aussage des Agenten zu vertrauen (hier Lauf 1; Lauf 2 ebenfalls bestanden):
node .claude/skills/security-audit/validate-findings.cjs audits/juice-shop/run-1/findings.json PASS: 12 findings valid node .claude/skills/security-audit/validate-coverage-ledger.cjs audits/juice-shop/run-1/coverage-ledger.json PASS: 22 coverage units valid
Ergebnisse
Überblick
| Kennzahl | Lauf 1 | Lauf 2 |
|---|---|---|
| Validierte Verdachtsfälle | 12 | 21 (12 übernommen, 9 neu) |
| Bestätigt / verworfen | 0 / 0 | 0 / 0 |
| Ungeprüfte Hinweise | 23 | 33 |
| Prüfeinheiten im Ledger | 22 | 53 |
| Prüfskripte (selbst nachgeprüft) | bestanden | bestanden |
Lauf 2 brachte vor allem mehr Breite, aber keinen zusätzlichen Beweis. Die Ergebnisse sind stabil: Alle 12 Fälle aus Lauf 1 kamen mit demselben Urteil zurück. Von den 9 neuen Fällen waren 5 in Lauf 1 schon als ungeprüfte Hinweise notiert, 4 sind neue Ursachen.
Die 21 Verdachtsfälle
„Katalog“ zeigt, ob der Fall einer beabsichtigten Juice-Shop-Challenge entspricht. „Eigene Prüfung“ ist das Ergebnis meiner Quellcodeprüfung. Angriffsdaten werden bewusst nicht genannt.
| Nr. | Verdachtsfall | Katalog | Eigene Prüfung |
|---|---|---|---|
| 1 | JWT-Signierschlüssel fest im Code und öffentlich abrufbar | ja | gestützt |
| 2 | JWT-Algorithmus nicht festgelegt | ja | gestützt |
| 3 | YAML-Upload erlaubt Codeausführung | nein | gestützt |
| 4 | Zip-Slip beim Datei-Upload | ja | gestützt |
| 5 | Benutzername wird per eval ausgewertet (Template-Injection) | ja | Codezeile stimmt |
| 6 | SQL-Injection in Login und Produktsuche | ja | nicht geprüft |
| 7 | Methodensperren über PATCH umgehbar | nein | widerlegt |
| 8 | Öffentlicher Endpunkt liefert Passwort-Hashes der Fotowand | nein | Code stimmt |
| 9 | Öffentliche Zugriffsprotokolle enthalten Passwörter | teilweise | gestützt |
| 10 | SSRF über Profilbild-URL | ja | Codezeile stimmt |
| 11 | SSRF über Chatbot-Nachrichten | nein | nicht geprüft |
| 12 | JavaScript-Injection über MarsDB-$where |
ja | nicht geprüft |
| 13 | Unvollständiger Sicherheitsschalter im neuesten Commit | nein | gestützt |
| 14 | Sitzungen laufen nie ab und werden nie widerrufen | nein | Code stimmt |
| 15 | Adressen ohne Eigentümerprüfung änderbar | nein | Route stimmt |
| 16 | Bewertungen massenhaft änderbar (NoSQL) | ja | nicht geprüft |
| 17 | Datenexport schreibt fremde Texte als HTML | nein | Codezeile stimmt |
| 18 | DOM-XSS über Suchparameter | ja | Codezeile stimmt |
| 19 | Unbehandelter Fehler kann den Server beenden | nein | plausibel |
| 20 | Pfadtraversal mit Backslash (nur Windows) | nein | Codezeile stimmt |
| 21 | Chatbot-Verläufe bleiben nach Abmeldung erhalten | nein | Code stimmt |
Vergleich mit dem Lösungsschlüssel
- Nach Lauf 1: ca. 29 von 116 Challenges gemeldet (ca. 25 %)
- Nach beiden Läufen: ca. 37 von 116 Challenges gemeldet (ca. 32 %)
Warum der Anteil niedrig ist: Viele Challenges sind durch Lesen von Code grundsätzlich nicht auffindbar. Bezogen auf die im Code auffindbaren Challenges wäre der Anteil höher.
Bemerkenswert: Beide Läufe zusammen fanden 12 Verdachtsfälle außerhalb des Katalogs (oder nur teilweise darin). Einer davon (Nr. 7) erwies sich später als falsch.
Verifikation der Ergebnisse
Dieser Teil beantwortet die vierte Seminarfrage. Unterschieden werden drei Ebenen:
| Ebene | Prüfung | Stand | Ergebnis |
|---|---|---|---|
| 1. Format | Entsprechen die Dateien Schema und Regeln? | durchgeführt | beide Skripte bestanden, in beiden Läufen; sagt nichts über die Echtheit einer Lücke |
| 2. Quellcode | Existieren die zitierten Stellen und tun sie, was behauptet wird? | durchgeführt, nur lesend | 320 von 320 Referenzen korrekt; 5 offene Fragen geklärt, 1 Fall widerlegt |
| 3. Laufzeit | Funktioniert der Angriff auf einer laufenden Kopie? | nicht durchgeführt | erfordert eine isolierte Umgebung |
Beispiel: Ein Verdachtsfall ist kein Befund (Nr. 7)
| Schritt | Inhalt |
|---|---|
| Behauptung | Ein Hunter in Lauf 2: Benutzerdatensätze seien gegen PUT und DELETE geschützt, vielleicht nicht gegen PATCH. Akzeptiere finale-rest PATCH, könne jeder Besucher Passwort oder Rolle beliebiger Benutzer ändern. |
| Prüfer | Zwei unabhängige Prüfer markierten den Fall korrekt als needs_validation und benannten die offene Frage („Registriert die Bibliothek eine PATCH-Route?“), konnten sie aber ohne Bibliothekscode nicht beantworten.
|
| Tatsache | finale-rest 1.2.2 registriert Aktualisierungen standardmäßig nur für put, außer updateMethod ist gesetzt – Juice Shop setzt es nicht. Eine PATCH-Route existiert nicht.
|
Das Werkzeug war ehrlich und benannte seine Wissenslücke, trotzdem war der Fall falsch. Genauigkeit muss gemessen, nicht angenommen werden. In 33 Prüfurteilen (12 + 21) wurde kein Kandidat verworfen, obwohl mindestens einer falsch war: Ohne Informationen neigen die Prüfer zur Nachsicht.
Warum keine Laufzeitprüfung?
- Juice Shop ist absichtlich gefährlich und sollte nicht auf einem privaten Rechner laufen.
- macOS bietet die geforderte Sandbox nicht; der Skill selbst verweigert die Ausführung.
- Ziel des Seminars ist die Bewertung des Ansatzes, nicht die Behebung der Lücken.
NEEDS-VALIDATION.md enthält für jeden Fall einen fertigen Prüfplan, meist auf Basis der Projekttests, die Grundlage für einen späteren Lauf mit Ausführung.
Antwort auf die vierte Seminarfrage
- Verstehen: ja. Jeder Fall nennt Angreifer, Eingabe, fehlende Kontrolle, Codespur, fehlende Information und Prüfplan.
- Am Quellcode verifizieren: weitgehend. Alle Referenzen stimmen; der Bibliothekscode klärte fünf Fragen und widerlegte einen Fall.
- Zur Laufzeit verifizieren: noch nicht.
Stärken, Schwächen und Kosten
| Stärken | Schwächen |
|---|---|
| Genau: keine von 320 Code-Referenzen erfunden | Keine Bestätigung ohne Sandbox: auf einem Mac bleibt jedes Ergebnis ein Verdacht |
| Ehrlich: kein Schweregrad ohne Beweis; „keine bestätigten Funde“ heißt ausdrücklich nicht „sicher“ | Fehlender Bibliothekscode: in Minuten klärbare Fragen blieben offen |
| Stabil: alle Ergebnisse aus Lauf 1 kehrten in Lauf 2 wieder | Nachsichtige Prüfer: 0 von 33 Urteilen verworfen, trotzdem war einer falsch |
| Über das Lehrbuch hinaus: 12 Fälle außerhalb des Katalogs, darunter eine Regression im neuesten Commit | Budget bestimmt das Ergebnis: 23 bzw. 33 Ursachen blieben ungeprüft – abhängig von der Budgetplanung, nicht vom Code |
| Gegenseitige Prüfung wirkt: ein Prüfer korrigierte einen Hunter (Windows-Pfadtraversierung) | Hoher Ressourcenbedarf: 20 parallele Agenten übersteigen das Pro-Limit |
| Sichtbare Lücken: das Ledger zeigt, was nicht geprüft wurde | Nicht deterministisch: ein Lauf ist eine Stichprobe, keine Messung |
| Sicheres Scheitern: bei Ratenlimit und Berechtigungsproblem hielt das Werkzeug an und fragte nach |
Kosten
| Posten | Lauf 1 | Lauf 2 |
|---|---|---|
| Dauer | 26 Minuten | 3 Stunden 13 Minuten |
| Agentenaufrufe | 24 | 57, dazu 20 Fehlstarts |
| Geschätzte Kosten | nicht gemessen | 51,65 USD |
| Kosten je neuem Verdachtsfall | – | ca. 5,70 USD |
Fazit und nächste Schritte
Der Cloudflare security-audit skill ist heute ein genauer und ehrlicher „Generator von Verdachtsfällen“, aber noch keine „Urteilsmaschine“. Er findet echte, nachvollziehbare Probleme, auch außerhalb jedes Katalogs, und sagt offen, was er nicht beweisen kann. Aus einem Verdachtsfall wird erst durch Ausführung in einer isolierten Umgebung oder durch einen prüfenden Menschen ein Befund – genau dort liegen die größten Kosten.
| Seminarfrage | Antwort |
|---|---|
| Wie funktioniert es? | Ein Koordinator zerlegt das Projekt in Einheiten, Hunter suchen parallel, unabhängige Prüfer versuchen zu widerlegen, feste Skripte prüfen die Ausgabe. |
| Welche Werkzeuge sind geeignet? | Der Skill eignet sich gut für belastbare Verdachtsfälle. Ein Vergleich mit klassischer statischer Analyse steht noch aus. |
| Stärken, Schwächen, Kosten? | genau, ehrlich, stabil; aber ohne Sandbox keine Bestätigung, budgetabhängig, ca. 52 USD geschätzt für Lauf 2 |
| Verstehen und verifizieren? | Verstehen ja; am Quellcode weitgehend; zur Laufzeit noch nicht |
Nächste Schritte (jede Option verändert genau eine Größe):
- Ausführung in einer isolierten Linux-VM: Der Skill kann Verdachtsfälle dort bestätigen oder verwerfen. Erst damit lässt sich die Genauigkeit messen.
- Ein zweites, kleines reales Projekt: zeigt, ob sich die Ergebnisse von einer Trainingsanwendung auf echten Code übertragen lassen; entspricht am ehesten der Vorgabe „eher kleine Projekte“.
Quellen
- Cloudflare: security-audit-skill. github.com/cloudflare/security-audit-skill
- Cloudflare Blog: Build your own vulnerability harness. blog.cloudflare.com
- OWASP Juice Shop, Commit 5658473c, inkl.
challenges.yml. github.com/juice-shop/juice-shop