Entwickle einen Claude Code Security Scanner Agent für OWASP

Entwickle einen Claude Code Security Scanner Agent für OWASP

Der Scan endete um 23:47 Uhr an einem Donnerstag, und ich saß da und starrte auf das Terminal, als hätte es gerade meine gesamte Codebasis beleidigt. Siebenunddreißig Schwachstellen. Neun kritisch. Ein Risikowert von 245, der ganz oben im Bericht in genau dem Rot blinkte, das bedeutet: "Dieses Produkt darf auf keinen Fall ausgeliefert werden." Und das Beste daran? Es war nicht einmal der Code eines Kunden. Es war eine absichtlich verwundbare Notiz-Anwendung, die ich als Testziel für den Claude Code Security Scanner Agent gebaut hatte, den ich am Nachmittag zusammengebaut hatte.

Und der Agent hat alles gefunden. MD5-Passwort-Hashing. Ungefilterte SQL-String-Konkatenation. Einen fehlerhaften Zugriffspfad, bei dem jeder authentifizierte Nutzer die Notizen jedes anderen Nutzers löschen konnte, wenn er eine ID erriet. Eine beliebige Codeausführung, die ich drei Dateien tief versteckt hatte, weil ich wirklich wissen wollte, ob der Agent das findet. Hat er. Dreißig Sekunden.

An diesem Punkt habe ich aufgehört, das Ganze als Wochenendexperiment zu sehen, und begonnen, darüber nachzudenken, dass ich das eigentlich schon vor sechs Monaten hätte bauen sollen.

Ich betreibe eine Cybersecurity-Marke — xCyberSecurity — und ein großer Teil dieser Arbeit besteht darin, OWASP-Audits für Webanwendungen durchzuführen. Das Audit selbst ist teure menschliche Arbeitszeit: Code lesen, Datenflüsse nachvollziehen, Abhängigkeitsversionen prüfen, CVEs abgleichen, die Ergebnisse mit Schweregrad und Handlungsempfehlungen dokumentieren. Das macht ein erfahrener Engineer. Sorgfältig. Langsam. Auf Stundenbasis abrechenbar.

Ein Claude-Code-Agent kann diesen Engineer nicht ersetzen. Aber er kann die Erstprüfung übernehmen. Er findet die offensichtlichen Probleme, noch bevor ein Mensch überhaupt die Datei öffnet. Und weil Claude Code jetzt das Skill- plus Subagent-Pattern unterstützt, ist das System modular – ein wiederverwendbares Modul, das ich projektübergreifend teilen, mit anderen Agents verketten und an einem Dienstagnachmittag einfach in einen Pre-Commit-Hook einbauen kann.

So habe ich es gebaut. Und noch wichtiger: Warum die Architektur entscheidend ist.

Warum ein einziger großer Agent hier nicht funktioniert

Mein erster Instinkt – und wahrscheinlich auch deiner – war es, einfach einen großen System-Prompt zu schreiben. „Du bist ein Security-Auditor. Prüfe auf SQL-Injection, fehlerhafte Zugriffskontrolle, schwache Verschlüsselung, die komplette OWASP Top 10, schreibe einen Bericht.“ Losschicken. Weitergehen.

Ich habe diese Version zuerst ausprobiert. Sie hat funktioniert. Irgendwie. Die Berichte waren inkonsistent. Manche Scans haben jeden md5()-Aufruf als kritisch gemeldet; andere haben ihn übersehen. Die Bewertung der „Schwere“ schwankte zwischen den Durchläufen – bei einem Scan war ein hardcodierter API-Schlüssel „hoch“, beim nächsten „kritisch“. Schlimmer noch: Der Agent hatte kein Gefühl dafür, wie gute Ergebnisse aussehen sollten. Jeder Aufruf war eine neue Improvisation.

Das eigentliche Problem lag in der Struktur. Ich habe versucht, vier verschiedene Dinge gleichzeitig in ein Kontextfenster zu packen: die OWASP-Top-10-Referenz, die Scan-Methodik, das Berichtsformat und den zu prüfenden Code selbst. Das ist jede Menge kognitive Last für einen einzelnen Prompt, und Claude – selbst Opus 4.7 – reagiert auf diese Überladung genauso wie ein menschlicher Auditor nach dem achten Energydrink. Es wird schlampig.

Dafür gibt es Skills. Und Sub-Agenten. Nutzt man beides zusammen, fügt sich alles sauber zusammen.

Falls du mehr Hintergrund dazu willst, wie Skills in Claude Code passen, habe ich das in meinem Claude-Code-Agenten-Skills-Guide ausführlich erklärt – es lohnt sich, den parallel zu diesem Beitrag zu lesen, denn der Scanner hier ist eine ganz praktische Anwendung dieser Muster.

Die Architektur: Skill + Sub-Agent

So funktioniert die Aufteilung.

Das Skill bildet die Wissensschicht. Es enthält das Referenzmaterial zu den OWASP Top 10, die Scan-Methodologie und das genaue Berichtsformat. Es handelt sich um einen Ordner mit einer SKILL.md-Datei und mehreren weiteren Markdown-Dateien – jeweils eine pro OWASP-Kategorie –, die bei Bedarf geladen werden. Das Skill selbst scannt nichts. Es ist eine Sammlung von Anleitungen, die zur Ausführung bereitsteht.

Der Sub-Agent ist die Ausführungsschicht. Dabei handelt es sich um einen spezialisierten Claude Code Sub-Agent mit eigenem Systemprompt, eigenen Tools (Read, Glob, Grep, Bash für gh-Klonvorgänge, Write für Berichte) sowie expliziten Anweisungen, beim Start das Security-Skill zu laden. Den Sub-Agent ruft man tatsächlich auf. Das Skill wird dabei als Nachschlagewerk genutzt.

Diese Aufteilung ist aus drei Gründen entscheidend:

Erstens, Trennung der Verantwortlichkeiten. Das Wissen wird unabhängig von der Ausführungslogik versioniert. Als OWASP die Top 10 im Jahr 2025 aktualisiert hat – SSRF wurde in Broken Access Control integriert, Software Supply Chain Failures als neue Hauptkategorie hinzugefügt und Mishandling of Exceptional Conditions ergänzt –, habe ich lediglich zwei Markdown-Dateien im Skill angepasst. Der Sub-Agent blieb unverändert. In der alten Welt des „One-Big-Prompt“ hätte ich den gesamten Systemprompt neu schreiben müssen.

Zweitens, Teilbarkeit. Das Skill ist ein Ordner. Ich kann ihn zippen, an eine Kollegin senden, ins gemeinsame Repository committen oder im Team-Skills-Register ablegen. Der Sub-Agent ist eine einzelne Markdown-Datei mit Frontmatter. Dasselbe Prinzip. Jemand aus meinem Team kann beides klonen, in fünf Minuten verbinden und erhält identische Scan-Ergebnisse wie ich.

Drittens, Komponierbarkeit. Der Scanner-Sub-Agent kann direkt aufgerufen werden – @security-scanner audit this repo – oder von einem übergeordneten Koordinator-Agenten eingekettet werden. Mein Hauptagent übernimmt das Code-Review; sobald er ein security: im Commit-Text erkennt, delegiert er an den Scanner. Dieses Muster wäre unmöglich, wenn die Security-Prüfung im Prompt des Review-Agents stecken würde. Mehr zu solchen Übergaben habe ich in meinem Agent Swarm Architecture Beitrag geschrieben; der Scanner ist dafür ein anschauliches Beispiel.

Im weiteren Verlauf des Beitrags folgt nun der eigentliche Build.

Die SKILL.md, die Sie kopieren können

Die Skill-Datei befindet sich unter .claude/skills/security-vulnerability/. Hier ist die Datei SKILL.md – das ist das Gerüst, das ich tatsächlich verwende, nur leicht bereinigt:

---
name: security-vulnerability
description: Scannt einen Codebestand oder ein GitHub-Repository nach OWASP Top 10 2025 Schwachstellen. Verwenden Sie dies, wenn der Nutzer nach einem Security Audit, Vulnerability Scan, OWASP Review oder einem Security-Check vor der Bereitstellung in einem lokalen Verzeichnis oder über eine GitHub-URL fragt.
---

Sie führen ein Security Audit anhand der OWASP Top 10 2025 Kategorien durch. Befolgen Sie den untenstehenden Ausführungsablauf exakt. Überspringen Sie keine Schritte. Erfinden Sie keine Schweregrade.

## Eingabeverarbeitung

Akzeptiere eine der beiden folgenden Eingaben:
- Einen lokalen Verzeichnispfad (z. B. `/Users/me/projects/app`)
- Eine GitHub-URL (z. B. `https://github.com/org/repo`)

Handelt es sich bei der Eingabe um eine GitHub-URL, klone das Repository mit:
  gh repo clone <org/repo> /tmp/scan-<timestamp>
Setze anschließend den Arbeitsverzeichnis-Pfad auf das geklonte Verzeichnis.

## Ausführungsablauf

1. **Inventarisierung des Codebestands.** Ermitteln Sie verwendete Programmiersprachen, Frameworks und Paketmanifeste (package.json, composer.json, requirements.txt, go.mod, Gemfile, pom.xml).
2. **Kategorien-Referenzen laden.** Für jede OWASP Top 10 2025 Kategorie wird die passende Referenzdatei aus folgendem Verzeichnis dieser Skill-Ordner eingelesen:
   - references/A01-broken-access-control.md
   - references/A02-security-misconfiguration.md
   - references/A03-supply-chain-failures.md
   - references/A04-injection.md
   - references/A05-cryptographic-failures.md
   - references/A06-insecure-design.md
   - references/A07-auth-failures.md
   - references/A08-data-integrity-failures.md
   - references/A09-logging-alerting-failures.md
   - references/A10-exceptional-conditions.md
3. **Kategorieweise Scannen.** Für jede Kategorie wird mittels Grep und Lese-Operationen im Codebestand nach den in der jeweiligen Referenzdatei dokumentierten Mustern gesucht. Jeder Fund wird mit Dateipfad, Zeilennummer, Ausschnitt und Kategorie dokumentiert.
4. **Abhängigkeiten prüfen.** Für jedes Paketmanifest werden die deklarierten Versionen extrahiert. Pakete mit bekannten CVEs werden anhand von OSV.dev oder der GitHub Advisory Database gekennzeichnet. CVE-IDs dürfen nicht erfunden werden. Ist ein Abgleich in der aktuellen Umgebung nicht möglich, wird das Paket samt Version unter „unverifizierte Abhängigkeiten“ aufgeführt, anstatt eine Bewertung zu erfinden.
5. **Bewerten und klassifizieren.** Jeder Fund erhält eine Schweregradbewertung: kritisch, hoch, mittel oder gering. Die Bewertung erfolgt nach Kriterien aus references/severity-rubric.md. Die Gesamtrisiko-Bewertung wird nach folgender Formel berechnet: (kritisch × 10) + (hoch × 5) + (mittel × 2) + (gering × 1).
6. **Bericht verfassen.** Speichern Sie den Bericht unter `audit/YYYY-MM-DD/report.md` relativ zum Scan-Ziel. Verwenden Sie das untenstehende Berichtsformat.

## Berichtsformat

Der Bericht muss in folgender Reihenfolge enthalten:

1. **Zusammenfassung** — Ziel, Scan-Datum, Gesamtanzahl der Funde nach Schweregrad, Gesamtrisikoscore, Bestehen-/Nichtbestehen-Urteil.
2. **Funde nach Kategorie** — jeweils ein Abschnitt pro OWASP-Kategorie mit Funden. Jeder Fund listet auf: Schweregrad, Datei:Zeile, Codeausschnitt, Relevanz, empfohlene Behebung.
3. **Abhängigkeitsrisiken** — bekannte, verwundbare Pakete mit CVE-Verweisen und möglichen Upgrade-Pfaden.
4. **Unbestätigte Abhängigkeiten** — Pakete, die als verdächtig markiert, aber nicht verifiziert wurden.
5. **Behebungspriorität** — eine nach Schweregrad und Aufwand geordnete Liste der zehn wichtigsten Maßnahmen.

## Harte Regeln

- Erfinde niemals CVE-IDs, Schweregrade oder Fixes, bei denen du dir nicht sicher bist. Markiere Unsicherheiten explizit.
- Niemals automatische Fixes anwenden. Der Sub-Agent kann Patches in einer separaten Datei vorschlagen, aber das Modifizieren des Quellcodes erfordert explizite menschliche Zustimmung.
- Wenn eine Datei mehr als 2000 Zeilen umfasst, lese sie in Abschnitten. Überspringe sie nicht.
- Jeder Fund muss eine spezifische Datei und einen Zeilenbereich zitieren.

Das ist alles. Das gesamte Skill-Brain. Jede Referenzdatei unter references/ ist ein fokussiertes 200–400 Zeilen umfassendes Dokument: Definition, typische Muster für Grep-Suchen, sprachspezifische Beispiele und die Bewertungsskala der Schweregrade für diese Kategorie. Solche Referenzdateien kannst du an einem Nachmittag verfassen, sofern du jemals mit Security-Themen gearbeitet hast.

Der Sub-Agent, der ihn nutzt

Der Sub-Agent befindet sich unter .claude/agents/security-scanner.md. Hier sind das Frontmatter und der System-Prompt — erneut die tatsächliche Version, die ich verwende:

---
name: security-scanner
description: Überprüft ein lokales Verzeichnis oder ein GitHub-Repository anhand der OWASP Top 10 2025. Proaktiv einsetzen, wenn der Nutzer eine Sicherheitsüberprüfung, einen Schwachstellenscan, Penetrationstest, Pre-Deployment-Check oder eine OWASP-Prüfung erwähnt.
model: opus
tools: Read, Glob, Grep, Bash, Write
---

Du bist Senior Application Security Engineer. Deine Aufgabe ist es, ein Ziel-Codebase sorgfältig nach den OWASP Top 10 2025 zu prüfen und einen Bericht zu erstellen, anhand dessen ein menschlicher Prüfer Maßnahmen ableiten kann.

Beim Ausführen:

1. Bestätige das Scan-Ziel mit dem Nutzer, falls es unklar ist (lokaler Pfad vs. GitHub-URL).
2. Lade die `security-vulnerability`-Skill. Folge deren Ablauf exakt.
3. Führe den Scan durch. Sei systematisch, nicht clever. Abdeckung ist wichtiger als Geschwindigkeit.
4. Schreibe den Bericht nach `audit/YYYY-MM-DD/report.md` und gib die Zusammenfassung im Chat aus.
5. Wenn der Bericht gespeichert wurde, biete — aber führe nicht automatisch durch — Korrekturen für mechanisch sichere Findings an (z. B. Ersetzen von `md5()` durch `password_hash()`, Parametrisierung einer SQL-Abfrage). Warte auf explizite Zustimmung, bevor du Quelldateien änderst.

Betriebsregeln:

- Du führst keine Penetrationstests an Live-Systemen durch. Nur statische Analyse.
- Du rätst nicht. Falls ein Befund unsicher ist, kennzeichne ihn im Bericht als unsicher.
- Du löschst oder verschiebst keine Dateien.
- Du protokollierst jeden Tool-Aufruf. Halte das Audit-Trail in `audit/YYYY-MM-DD/trail.log` fest.

Zwei Dateien. Das ist der gesamte Scanner.

Was passierte, als ich es ausführte

Ich habe als Testziel eine absichtlich verwundbare Notiz-App gebaut. Laravel-ähnlicher Stack, SQLite, ein paar Routen, Benutzer-Authentifizierung, CRUD für Notizen. Ich habe absichtlich sechs verschiedene Verwundbarkeitsklassen eingebaut und ein paar hinzugefügt, an die ich mich später nicht mehr erinnert hatte.

Der Scan dauerte von Anfang bis Ende etwa 90 Sekunden auf einer Codebasis mit 4.000 Zeilen. Hier die Zusammenfassung:

• Gesamtanzahl der Funde: 37
• Kritisch: 9
• Hoch: 15
• Mittel: 12
• Niedrig: 1
• Risiko-Score: 245 (kritisch)

Die kritischen Funde umfassten A01 Broken Access Control (zwei Routen ohne Besitzprüfungen — jeder authentifizierte Nutzer konnte jede beliebige Notiz bearbeiten oder löschen, sofern er die ID erriet), A04 Injection (drei Fälle von ungesicherter String-Konkatenation in SQL-Queries), A05 Cryptographic Failures (MD5-Passwort-Hashing plus ein hartkodierter APP_KEY in einer committeten .env.example) und A06 Insecure Design (ein Admin-Endpunkt, der einen cmd-Parameter akzeptierte, welcher direkt in einen Shell-Exec-Call übergeben wurde).

Der Report listete all dies mit Dateipfaden, Zeilennummern, genauen Codeausschnitten und einem Verbesserungsvorschlag pro Fund auf. Für die SQL-Injection-Fälle schlug er direkt eine Umstellung auf parametrisierte Queries vor. Für das MD5-Hashing verwies er auf Laravels Hash::make() und beschrieb eine Migrationsstrategie für bestehende Passworthashes.

War das perfekt? Nein. Es wurde ein Logging-Statement beanstandet, das eine Nutzer-E-Mail als A09-Issue ausgab — das ist vertretbar, wirkte aber überzogen; in vielen Rechtsräumen ist so etwas kein echter Befund. Außerdem übersah der Scan eine subtile Race-Condition im Notizfreigabe-Endpunkt, die einem menschlichen Reviewer in etwa dreißig Sekunden aufgefallen wäre. Statisches Pattern-Matching kann keine Nebenläufigkeit erfassen — und kein noch so ausgefeilter Prompt wird das ändern.

Aber was der Scanner gefunden hat, war sauber erkannt. Und ich hatte am Ende einen datierten Report unter audit/2026-04-18/, den ich direkt an einen Kunden schicken könnte.

Integration in einen Pre-Commit- oder CI-Workflow

Der Sub-Agent ist als eigenständiges Tool nützlich. Noch nützlicher wird er, wenn er automatisch ausgeführt wird.

Für Pre-Commit verwende ich ein Git-Hook, das den Claude-Code im Headless-Modus ausschließlich auf den gestagten Dateien ausführt. Es lädt den Scanner-Sub-Agent, beschränkt den Scan auf die geänderten Pfade und schlägt den Commit fehl, falls neue kritische oder hohe Findings auftauchen, die im letzten Scan noch nicht vorhanden waren. Das entscheidende Stichwort ist hier „neu“ – bei jedem Commit einen vollständigen OWASP-Scan durchzuführen, wäre absurd. Ein Delta-Scan im Vergleich zum letzten bestandenen Baseline-Resultat ist der richtige Ansatz.

Für CI gilt das gleiche Muster, jedoch mit einer anderen Hülle. Eine GitHub Action läuft auf Pull-Requests, klont den PR-Branch in ein temporäres Verzeichnis, ruft den Scanner auf und postet die Zusammenfassung als PR-Kommentar, wobei der vollständige Bericht als Build-Artefakt hinterlegt wird. Steigt der Risikoscore gegenüber dem Basis-Branch über einen definierten Schwellenwert, schlägt der Check fehl. Der Team-Owner kann das Ergebnis mit einem genehmigten Label überschreiben. Das hat bereits zweimal verhindert, dass durch transitive Abhängigkeiten verwundbare Pakete in main gelangt sind.

Beides gehört nicht zum eigentlichen Aufgabenbereich des Scanners – das ist reine Orchestrierung um den Scanner herum. Aber sobald Skill und Sub-Agent existieren, ist die Anbindung trivial, denn der Scanner liest einen Pfad ein und schreibt einen Report. Alles andere ist nur Klebstoff.

Wo das ehrlich gesagt an seine Grenzen stößt

Ich werde nicht so tun, als könnte das einen menschlichen Pentester ersetzen, also lassen Sie uns die Grenzen klar benennen.

False Positives. Der Scanner meldet viele Muster übervorsichtig. Jeder Aufruf von md5() wird geflaggt, selbst wenn er lediglich für Fingerprinting-Zwecke und nicht aus Sicherheitsgründen eingesetzt wird. Jeder kritisch anmutende Funktionsaufruf in einer Testdatei wird ebenfalls gemeldet. Mit der Zeit lernt man, wie man damit umgeht und priorisiert. Doch wenn Sie den Bericht an einen nicht-technischen Kunden weitergeben, müssen Sie diese Triage selbst durchführen.

Keine Laufzeitanalyse. Statische Analyse sieht nur, was im Code steht, nicht, was zur Laufzeit passiert. Race Conditions, Timing-Angriffe, Geschäftslogik-Fehler, die erst durch eine bestimmte Abfolge von API-Aufrufen sichtbar werden — all das entgeht dem Scanner. Ein Pentester erkennt solche Probleme. Diese Lücke lässt sich nicht automatisieren.

Abhängigkeits-Intelligenz nur so gut wie der Feed. Der Scanner gleicht Bibliotheken gegen OSV.dev und GitHub Advisories ab. Verfügt ein Paket über eine veröffentlichte CVE, ist das ideal. Wurde eine Schwachstelle aber erst vor drei Tagen gemeldet und ist noch nicht öffentlich erfasst, übersieht der Scanner sie. Zero-Day-Schwachstellen bleiben immer ein Problem für Menschen.

Autofix ist eine Falle. Dieser Punkt ist mir besonders wichtig. Der Sub-Agent kann Fixes vorschlagen. Er sollte sie aber niemals ungeprüft anwenden. Ich weiß das aus Erfahrung — die erste Version des Agents hat Änderungen automatisch übernommen und dabei einen md5()-Aufruf in einer alten Passwort-Überprüfung durch etwas anderes ersetzt, ohne eine Passwortmigration anzustoßen. Das Ergebnis: Für alle bestehenden Nutzer war der Login in der Staging-Umgebung blockiert. Statische Fixes ohne Migrationsbewusstsein verwandeln ein „mittel“-kritisches Finding schnell in einen Produktionsausfall. Menschliche Kontrolle ist unerlässlich. Immer.

Skill Security selbst. Abschließend — und das hat mich nach aktueller Forschung von Repello zum Thema Skill Security wirklich zum Nachdenken gebracht —: Skills sind ausführbarer Kontext. Jede installierte Skill kann auf das Dateisystem zugreifen und Shell-Kommandos ausführen. Eine bösartige Skill, die sich als Security Scanner tarnt, ist ein echtes Risiko. Ich schreibe meine Skills selbst, prüfe jede importierte Skill sorgfältig und halte die Vertrauensgrenze bewusst eng. Das sollten Sie auch tun.

Der Teil, den die meisten übersehen

Was ich immer wieder erkläre, wenn andere Entwickler mich nach diesem Ansatz fragen, ist: Der Scanner ist nicht der wertvolle Teil. Den Scanner baut man in einer Woche. Jeder kompetente Engineer mit Claude Code und einem Nachmittag kann einen erstellen.

Der wirklich wertvolle Teil ist die Disziplin, die durch die Trennung in Skill und Sub-Agent erzwungen wird. Wenn du das Skill schreibst, hältst du fest, wie ein guter Security Audit tatsächlich aussieht — die Kategorien, die Muster, das Bewertungsraster für Schweregrade, das Format des Reports. Dieses Dokument, das unter .claude/skills/security-vulnerability/ liegt, ist institutionelles Wissen, das es zuvor nicht gab. Es ist wertvoller als der Agent selbst. Denn im nächsten Jahr, wenn OWASP die Top 10 für 2028 veröffentlicht und die Hälfte der Kategorien sich wieder verschiebt, aktualisiert man die Referenzdateien. Der Agent läuft weiter. Das Wissen ist versioniert, teilbar und steckt nicht im Kopf einzelner Personen.

Das ist die eigentliche Erkenntnis aus diesem Projekt. Nicht „Ich habe OWASP automatisiert.“ Die Lektion ist: Modulare Agents zwingen dich dazu, dein Wissen explizit zu machen, und explizites Wissen wächst exponentiell.

Suche dir heute Abend ein Repository aus. Nicht das vom Kunden. Eines von deinen eigenen. Führe einen Scan durch. Schau dir die Ergebnisse an. Du wirst in neunzig Sekunden mehr über deinen eigenen Code lernen als in den letzten sechs Monaten Entwicklung.

Häufig gestellte Fragen

Kann Claude Code ein privates GitHub-Repository scannen?

Ja, solange das gh CLI auf der Maschine, auf der Claude Code läuft, mit Zugriff auf das betreffende Repository authentifiziert ist. Der Scanner verwendet intern gh repo clone und übernimmt daher die Berechtigungen, die Sie über gh auth login erteilt haben. Bei Organisations-Repositories stellen Sie sicher, dass Ihr Token den Scope repo besitzt.

Ersetzt der Scanner Tools wie Snyk oder Semgrep?

Nein. Er ergänzt sie. Snyk und Semgrep nutzen kuratierte Regelsätze und Schwachstellendatenbanken, die autoritativer sind als jeder einzelne LLM-Prompt. Der Claude Code Scanner fügt zusätzliche Argumentationsfähigkeit hinzu – er kann Datenflüsse nachverfolgen und kontextspezifische Probleme erkennen, die statische Regeln übersehen. Benutzen Sie beide. Der Scanner erkennt Design-Schwächen, Snyk spürt bekannte CVEs schneller auf.

Wie viel kostet ein OWASP-Scan auf diese Weise?

Mit Opus 4.7 kostet ein vollständiger Scan einer Codebasis mit 4.000 Zeilen und dem Skill + Subagent-Setup wenige Dollar an API-Gebühren pro Durchlauf. Delta-Scans für gestagte Dateien im Pre-Commit-Hook sind deutlich günstiger. Wenn Sie ein Claude Code-Abonnement mit Inklusiv-Nutzung haben, decken die meisten Alltags-Scans dieses Budget ab.

Kann ich das Skill mit meinem Team teilen, ohne meinen Claude-Account weiterzugeben?

Ja. Das Skill ist einfach ein Ordner mit Markdown-Dateien. Checken Sie .claude/skills/security-vulnerability/ in Ihr Projekt-Repository oder ein gemeinsames Skills-Repository ein. Jeder Teamkollege, der Claude Code nutzt, lädt es automatisch von seinem eigenen Account. Gleiches gilt für die Subagent-Datei unter .claude/agents/.

Sollte der Scanner Fixes automatisch anwenden?

Nein, und ich würde sogar sagen: Niemals. Schlagen Sie Fixes vor, schreiben Sie sie in eine separate Patch-Datei und verlangen Sie eine menschliche Prüfung, bevor eine Quelldatei verändert wird. Ich persönlich habe einmal eine Staging-Umgebung zerschossen, weil ich dem Agenten vertraute, einen „sicheren“ Krypto-Tausch automatisch auszuführen. Für sich genommen sicher, im Zusammenspiel mit dem restlichen Authentifizierungs-Flow katastrophal. Halten Sie den Menschen in der Entscheidungs­schleife.

Lassen Sie uns zusammenarbeiten

Möchten Sie KI-Systeme entwickeln, Workflows automatisieren oder Ihre technische Infrastruktur skalieren? Ich unterstütze Sie gerne.

• Fiverr (individuelle Lösungen & Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Enterprise-Lösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Sicherheitsdienste): xcybersecurity.io