Security Audit Skill Schritt-für-Schritt-Anleitung: Claude Code zum KI-Sicherheitsauditor machen – vom Code-Scan bis zum vollständigen Schwachstellenbericht in der Praxis

Eine Security Audit Skill kann Claude Code als schrittweise arbeitenden KI-Sicherheitsauditor anleiten: Verwenden Sie sie für einen klar begrenzten, autorisierten Code-Audit, aber behandeln Sie ihre Ergebnisse weder als Sicherheitszertifikat noch als bestätigte Schwachstellen, bevor sie geprüft wurden. Das Verfahren ist besonders geeignet, wenn wiederkehrende Prüfschritte standardisiert und Befunde nachvollziehbar dokumentiert werden sollen; die Qualität hängt weiterhin von Umfang, Kontext, verfügbaren Werkzeugen und menschlicher Kontrolle ab.

Dieser Leitfaden richtet sich an Entwickler, die Claude Code bereits einsetzen und Codeprüfungen vereinheitlichen möchten.
Er hilft Sicherheitsteams, aus Hinweisen überprüfbare Schwachstellenberichte zu erstellen.
Technische Verantwortliche erhalten einen Ablauf, mit dem sich Nutzen und Grenzen eines KI-Agenten kontrolliert bewerten lassen.

Erst die Rollen trennen: Skill, Scanner und Fachprüfung

Eine Skill ist eine wiederverwendbare Anleitung für Claude Code. Sie beschreibt, welches Repository und welche Risiken geprüft werden sollen, in welcher Reihenfolge die Analyse abläuft und welche Belege ein Bericht enthalten muss. Sie ist aber kein zusätzlicher Scanner und keine Garantie, dass der Agent jeden relevanten Fehler findet.

Die Rollen lassen sich so auseinanderhalten:

Bestandteil	Aufgabe im Audit	Was das Ergebnis nicht beweist
Security Audit Skill	Legt Umfang, Ablauf, Beleganforderungen und Berichtsformat fest	Dass die Anweisungen immer vollständig befolgt oder alle Risiken gefunden werden
Claude Code	Untersucht bereitgestellten Code und Kontext, kann Funde erläutern und Ergebnisse strukturieren	Dass eine plausible Erklärung durch Laufzeitverhalten oder einen reproduzierbaren Test bestätigt ist
Konfigurierte Scan-Werkzeuge	Liefern zusätzliche, regel- oder analysebasierte Hinweise	Dass ihre Abdeckung alle Programmiersprachen, Konfigurationen und Fehlerklassen umfasst
Menschliche Prüfung	Kontrolliert Codepfad, Datenfluss, Auswirkungen, Fehlalarme und Priorität	Dass ein nicht geprüfter Rest des Systems automatisch sicher ist

Claude Code kann mit Anweisungen wiederholbare Arbeitsschritte ausführen, aber die konkrete Werkzeugnutzung hängt von der lokalen Konfiguration und den erteilten Berechtigungen ab. Prüfen Sie die offizielle Beschreibung von Skills und ihrer Konfiguration, bevor Sie Dateien oder Aufrufweisen übernehmen. Die verfügbaren Berechtigungen und Freigaben sind gesondert zu betrachten; eine Skill sollte nicht als stillschweigende Erlaubnis für beliebige Shell-Befehle oder Änderungen am Repository verstanden werden. Maßgeblich sind die Dokumentation zu Berechtigungen und die Sicherheitshinweise für Claude Code.

Der Nutzen liegt daher nicht darin, die Sicherheitsverantwortung an einen Agenten abzugeben. Er liegt darin, wiederkehrende Prüfschritte und Dokumentationsanforderungen zu vereinheitlichen und nachvollziehbare Hinweise für die menschliche Entscheidung zu erzeugen.

Den Audit-Umfang festlegen, bevor der Code geprüft wird

Ein zu weiter Auftrag wie „Prüfe die Anwendung auf alle Sicherheitsprobleme“ lässt zu viel offen: Welche Verzeichnisse gehören zum Projekt? Sind Abhängigkeiten eingeschlossen? Welche Daten gelten als sensibel? Soll der Agent nur lesen oder auch Tests ausführen? Fehlen diese Antworten, kann eine Analyse harmlose Testdateien übergewichten, zentrale Module übersehen oder einen Verdacht als fertigen Befund formulieren.

Legen Sie deshalb vor dem Start fest:

• Autorisierung: Das Repository muss dem Team gehören oder ausdrücklich zur Prüfung freigegeben sein. Bei einem fremden oder gemeinsam genutzten Repository muss geklärt sein, welche Dateien und Aktionen erlaubt sind.
• Gegenstand: Nennen Sie Pfade und Komponenten, zum Beispiel src/auth/ und src/api/, und schließen Sie generierte Dateien oder Drittanbieter-Code bei Bedarf ausdrücklich aus.
• Technischer Kontext: Beschreiben Sie Programmiersprachen, Frameworks, Vertrauensgrenzen, Authentifizierungswege und den Umgang mit sensiblen Daten. Verweisen Sie auf relevante Architektur- oder Datenflussdokumentation.
• Risikofokus: Wählen Sie konkrete Prüffelder, etwa Zugriffskontrollen, Eingabevalidierung, Geheimnisse im Quelltext oder unsichere Datenbankabfragen. Die OWASP-Liste der zehn wichtigsten Webanwendungsrisiken aus dem Jahr 2021 ist eine Orientierung für Webanwendungen, aber keine vollständige Prüfliste für jedes System.
• Erlaubte Aktionen: Geben Sie an, ob die Skill nur lesend prüfen, vorhandene Tests ausführen oder konfigurierte Scanner starten darf. Änderungen, Installation neuer Werkzeuge und externe Zugriffe sollten nicht stillschweigend vorausgesetzt werden.
• Ausgabe: Legen Sie fest, welche Belege ein Fund benötigt und wie Unsicherheiten, mögliche Fehlalarme und nicht geprüfte Bereiche ausgewiesen werden.

Ein präziser Auftrag könnte lauten: „Prüfe ausschließlich das autorisierte Repository beispielprojekt, insbesondere src/auth/ und src/api/. Untersuche Zugriffsprüfungen und den Datenfluss von externen Eingaben zu Datenbankabfragen. Lies Konfiguration und Tests; starte nur die im Projekt bereits vorhandenen, freigegebenen Prüfwerkzeuge. Ändere keine Dateien. Kennzeichne unbestätigte Hinweise ausdrücklich.“

So eine Abgrenzung begrenzt nicht nur den Arbeitsumfang. Sie macht später auch sichtbar, ob ein Ergebnis außerhalb des genehmigten Prüfbereichs liegt. Für die Verwaltung von Projekt- und Benutzerberechtigungen sollten Sie die Dokumentation zu Einstellungen und Berechtigungsregeln mit der tatsächlich verwendeten Konfiguration abgleichen.

Die Skill-Datei so schreiben, dass jeder Fund prüfbar bleibt

Wie lässt sich die Security Audit Skill so konfigurieren, dass Claude Code Sicherheitsprobleme im Code untersucht? Beschreiben Sie einen reproduzierbaren Ablauf statt einer pauschalen Aufforderung, nach Schwachstellen zu suchen. Die offizielle Dokumentation führt Skills als Verzeichnisse mit einer SKILL.md-Datei und beschreibt die dazugehörigen Aufruf- und Konfigurationsregeln. Prüfen Sie diese Vorgaben vor der Einrichtung anhand der aktuellen Skill-Dokumentation, anstatt aus einem Beispiel ungeprüft auf spätere Versionen zu schließen.

Ein mögliches, bewusst knappes Grundgerüst für ein autorisiertes Projekt sieht so aus:

.claude/
└── skills/
    └── security-audit/
        └── SKILL.md

Der Inhalt kann zum Beispiel diese Struktur verwenden:

---
name: security-audit
description: Prüft autorisierten Anwendungscode auf klar benannte Sicherheitsrisiken und erstellt belegte, überprüfbare Befunde.
---

# Auftrag
Prüfe ausschließlich die im Benutzerauftrag genannten Projektpfade.
Nimm keine Änderungen am Repository vor.

# Ablauf
1. Lies die Projektübersicht und die relevanten Architekturhinweise.
2. Bestimme die Vertrauensgrenzen und verfolge relevante Datenflüsse.
3. Prüfe die angegebenen Risikofelder im Quellcode und in passenden Tests.
4. Verwende nur bereits konfigurierte und ausdrücklich freigegebene Prüfwerkzeuge.
5. Vergleiche jeden Hinweis mit konkreten Codepositionen und Werkzeugausgaben.
6. Ordne jedes Ergebnis als bestätigt, offen oder nicht zutreffend ein.
7. Erstelle einen Bericht mit Belegen, Auswirkungen und Verifikationsstatus.

# Belegregeln
Nenne für jeden Hinweis Datei, Funktion oder präzise Codeposition sowie den
relevanten Codeausschnitt oder die nachvollziehbare Beweiskette.
Trenne beobachtetes Verhalten von Annahmen.
Erfinde keine Ausgaben, Testergebnisse oder Laufzeitbedingungen.

# Grenzen
Greife nicht auf externe Systeme zu, beschaffe keine zusätzlichen Geheimnisse
und führe keine Änderungen, Installationen oder destruktiven Befehle aus.
Wenn Kontext oder Berechtigung fehlt, halte an und frage nach.

Die Beispielstruktur soll zeigen, welche Informationen erforderlich sind; sie behauptet nicht, dass jede Konfiguration für jedes Projekt genügt. Der Name muss zur vorgesehenen Skill passen, und Aufruf sowie Verfügbarkeit sind in der realen Umgebung zu prüfen. Wenn Claude Code eine Aktion vorschlägt, die Berechtigungen erfordert, entscheidet die konfigurierte Freigabe darüber, ob sie ausgeführt werden darf. Die Skill selbst sollte solche Freigaben nicht als bereits erteilt darstellen.

Ein Scannergebnis ist ein Hinweis, kein Beweis. Wird etwa eine Datenbankabfrage markiert, muss die Prüfung klären, ob nicht vertrauenswürdige Eingaben den betreffenden Parameter tatsächlich erreichen und ob eine Schutzmaßnahme den Pfad wirksam unterbricht.

Den Scan mit einem kontrollierten Ablauf ausführen

Wie kann Claude Code mithilfe der Security Audit Skill aus einem Code-Scan einen Schwachstellenbericht erstellen? Führen Sie die Prüfung in einem autorisierten Beispiel-Repository aus und halten Sie jeden Übergang vom Auftrag zum Befund fest. Ein sicherer Ablauf umfasst diese Schritte:

1. Repository und Zustand prüfen. Bestätigen Sie, dass der Arbeitsstand zum freigegebenen Projekt gehört und keine unbeabsichtigten Änderungen vorliegen. Beginnen Sie nicht mit einem Repository, dessen Autorisierung unklar ist.
2. Auftrag und Ausschlüsse übergeben. Nennen Sie betroffene Pfade, Risikofelder, erlaubte Werkzeuge und die erwartete Ausgabe. Markieren Sie Tests, generierte Dateien oder externe Abhängigkeiten, die nicht Teil des Audits sind.
3. Projektkontext sammeln lassen. Claude Code soll zunächst Architekturhinweise, relevante Einstiegspunkte und vorhandene Tests lesen. Fehlt ein entscheidender Datenfluss, sollte die Skill eine Rückfrage oder eine offene Einschränkung verlangen, statt den Kontext zu erfinden.
4. Codepfade untersuchen. Verfolgen Sie bei einem Eingabevalidierungsproblem zum Beispiel den Weg von der Eingabe über Aufrufstellen bis zu einer sicherheitsrelevanten Operation. Ein isolierter verdächtiger Ausdruck reicht noch nicht für eine Aussage über die Ausnutzbarkeit.
5. Vorhandene Werkzeuge gezielt ausführen. Ein Scanner kann Hinweise zu bekannten Mustern oder Regeln liefern. Starten Sie nur Werkzeuge, die im Projekt bereits eingerichtet und für diese Prüfung freigegeben sind. Dokumentieren Sie Werkzeugname, relevante Ausgabe und geprüfte Pfade; behaupten Sie keine Abdeckung, die das Werkzeug nicht belegt.
6. Jeden Fund verifizieren. Vergleichen Sie Dateiposition und Kontext mit dem tatsächlichen Codepfad. Prüfen Sie, ob Tests oder Schutzmaßnahmen die Annahme widerlegen, und halten Sie unbeantwortete Fragen offen.
7. Bericht erstellen und nachprüfen. Übernehmen Sie nur Belege, die sich im Repository oder in nachvollziehbaren Werkzeugausgaben wiederfinden. Prüfen Sie anschließend den Bericht gegen den Code, bevor er als Grundlage für Änderungen oder Freigabe dient.

Eine sinnvolle Orientierung für die Risikofelder bieten die Kategorien der OWASP-Übersicht zu Webanwendungsrisiken. Verwenden Sie diese Kategorien nicht als Behauptung, dass eine Prüfung alle dort aufgeführten Bereiche abdeckt. Bei der Benennung eines technischen Fehlers kann außerdem die Erklärung zu Schwächen und Schwachstellen helfen: Eine beobachtete Code-Schwäche und eine bestätigte, ausnutzbare Schwachstelle sind nicht automatisch dasselbe.

Wie werden Scan-Funde von Claude Code überprüft und eingestuft? Verlangen Sie eine nachvollziehbare Beweiskette: Wo beginnt der Datenfluss, welche Funktion verarbeitet ihn, welche Schutzmechanismen greifen, und welche konkrete Auswirkung ist unter den gegebenen Bedingungen plausibel? Stimmen Sie eine Klassifizierung auf die vorhandenen Belege ab. Wenn eine Eingabe zwar ungeprüft erscheint, aber der relevante Pfad nicht bis zur Operation verfolgt werden kann, gehört der Fund zunächst in „offen“ statt in „bestätigt“.

Aus einem Hinweis einen belastbaren Schwachstellenbericht machen

Ein Scanprotokoll ist noch kein verständlicher Bericht. Für eine Prüfung durch Entwickler oder Sicherheitspersonal braucht jeder Eintrag mindestens einen Typ oder eine vorsichtige Kategorie, den betroffenen Bereich, konkrete Belege, eine begründete Auswirkung, einen Reparaturvorschlag und einen sichtbaren Prüfstatus. Trennen Sie dabei technische Beobachtung und Risikobewertung: „Die Eingabe erreicht diese Funktion“ ist eine andere Aussage als „Ein Angreifer kann damit Daten auslesen“.

Ein illustrative, nicht auf einem realen Audit beruhende Umwandlung könnte so aussehen:

Ungeprüfter Scan-Hinweis: „Möglicherweise unsichere Datenbankabfrage in src/api/search.“

Überprüfbarer Berichtseintrag: „Status: offen. In src/api/search wird ein Suchparameter an die Abfrage übergeben. Der gezeigte Codeausschnitt belegt noch nicht, ob die Datenbankbibliothek den Wert als Parameter bindet oder ob er in den Abfragetext eingesetzt wird. Vor einer Einstufung sind die konkrete Aufrufstelle und die verwendete Abfragemethode zu prüfen. Falls der Wert direkt in den Abfragetext gelangt, sollte die Abfrage auf gebundene Parameter umgestellt und mit einem projektspezifischen Test geprüft werden.“

Der zweite Eintrag vermeidet eine unbelegte Behauptung und nennt die nächste Verifikationshandlung. Sobald Code und Test die Annahme bestätigen oder widerlegen, wird der Status aktualisiert. Eine Zuordnung zu einer CWE-Kategorie ist nützlich, wenn sie durch den konkreten Fehler gestützt ist; eine Klassifikation ersetzt jedoch nicht die Erklärung des Datenflusses und der Auswirkungen.

Was gehört in den Bericht, damit die Fundprüfung nachvollziehbar bleibt?

• Kennung und Status: Verwenden Sie eine projektinterne Kennung und die eindeutige Bezeichnung „bestätigt“, „offen“ oder „nicht zutreffend“.
• Betroffene Stelle: Nennen Sie Pfad, Funktion und eine stabile Codeposition; prüfen Sie, ob sie im aktuellen Arbeitsstand noch existiert.
• Belege: Zitieren Sie den relevanten Code oder die konkrete Werkzeugausgabe und erläutern Sie, was der Beleg zeigt und was nicht.
• Auswirkung: Beschreiben Sie eine mögliche Folge nur dann als bestätigt, wenn die Beweiskette sie trägt. Kennzeichnen Sie Annahmen ausdrücklich.
• Reparatur und Verifikation: Formulieren Sie eine auf den Code bezogene Empfehlung und nennen Sie, welcher Test oder welche erneute Prüfung den Fix bestätigen soll.
• Abdeckung und Grenzen: Halten Sie fest, welche Pfade oder Werkzeuge nicht geprüft wurden und warum.

Für den Prozessrahmen kann das NIST Secure Software Development Framework herangezogen werden. Es ordnet sichere Softwareentwicklung in vier Praxisgruppen ein: organisatorische Vorbereitung, Schutz der Software, sichere Herstellung und Reaktion auf Schwachstellen. Diese Gruppen sind ein Rahmen für Entwicklungsprozesse, kein Beleg dafür, dass eine einzelne KI-Prüfung regelkonform oder vollständig ist.

Prüfliste für Grenzen, Datenschutz und Nachkontrolle

Welche Teile eines Audits mit Claude Code müssen Menschen besonders sorgfältig prüfen? Entscheidend sind die Autorisierung, der Umgang mit sensiblen Informationen, die tatsächliche Reichweite eines Codepfads, die Bedeutung eines Fundes und die Wirksamkeit der Reparatur. Ein gut formulierter Bericht ersetzt keine dieser Prüfungen.

• [ ] Repository, Branch und Prüfpfade sind ausdrücklich freigegeben.
• [ ] Ausgeschlossene Bereiche und erlaubte Aktionen sind im Auftrag festgehalten.
• [ ] Es werden keine Zugangsdaten, personenbezogenen Daten oder vertraulichen Produktionsdaten unnötig in Prompts oder Berichte übernommen.
• [ ] Jeder als bestätigt markierte Fund lässt sich an Code und Beweiskette nachvollziehen.
• [ ] Scanner-Ausgaben sind als Werkzeughinweise dokumentiert, nicht als vollständige Sicherheitsbewertung.
• [ ] Mögliche Fehlalarme und fehlender Kontext sind sichtbar als offene Punkte markiert.
• [ ] Reparaturempfehlungen passen zur Architektur und ändern nicht unbemerkt den freigegebenen Umfang.
• [ ] Nach einer Korrektur wurde der betroffene Codepfad erneut geprüft und der Status im Bericht aktualisiert.
• [ ] Nicht geprüfte Komponenten und bekannte Werkzeuggrenzen sind im Abschluss dokumentiert.

Die Sicherheitshinweise für Claude Code sollten Sie vor dem Einsatz mit den Anforderungen Ihres Teams an Zugriffsschutz und Datenschutz abgleichen. Bei vertraulichem Quellcode ist insbesondere zu klären, welche Informationen in Eingaben, Protokollen und Berichten landen und wer darauf zugreifen kann. Für Organisationen, die personenbezogene Daten verarbeiten, müssen zusätzlich die internen Datenschutzvorgaben und die geltenden DSGVO-Prozesse berücksichtigt werden; eine Skill-Konfiguration allein schafft keine rechtliche Freigabe.

Eine weitergehende Prüfung durch Sicherheitspersonal ist erforderlich, wenn ein Fund Authentifizierung, Berechtigungsgrenzen, vertrauliche Daten oder sicherheitskritische Abläufe betrifft; wenn der Datenfluss mit den verfügbaren Informationen nicht abschließend belegt werden kann; oder wenn Werkzeuge und Tests zu widersprüchlichen Ergebnissen kommen. Dasselbe gilt, wenn eine Änderung Auswirkungen auf mehrere Dienste hat oder eine Korrektur Produktionsverhalten verändern könnte. In solchen Fällen sollte der Bericht die offene Frage präzise benennen, statt aus Unsicherheit eine definitive Einstufung zu machen.

Für einen reproduzierbaren Lauf die passende Umgebung wählen

Für einen einzelnen, überschaubaren Audit kann eine vorhandene lokale Entwicklungsumgebung ausreichen. Sie bietet direkten Zugriff auf das Repository, setzt aber voraus, dass Berechtigungen, Abhängigkeiten und Werkzeuge dort korrekt eingerichtet sind. Bei wiederkehrenden Läufen können ein dauerhaft verfügbarer Remote-Arbeitsplatz und eine kontrollierte Tool-Konfiguration die Ausführung besser planbar machen. Das verbessert nicht automatisch die Erkennungsqualität: Umfang, Skill-Anweisungen, Scannerabdeckung und menschliche Verifikation bleiben ausschlaggebend.

Eine allgemeine Remote-Umgebung ist nicht in jedem Fall die beste Wahl. Wenn ein Team bestimmte physische Schnittstellen benötigt, Daten nicht außerhalb eines lokalen Systems verarbeiten darf oder dauerhaft hohe Last auf einer bereits vorhandenen Maschine ausführt, kann eine lokale oder intern betriebene Umgebung besser passen. Bei macOS-spezifischen Build- und Testanforderungen kann dagegen ein Mac als Arbeitsumgebung sinnvoll sein. Prüfen Sie vorab, ob Betriebssystem, Zugriffsschutz, Datenverarbeitung und verfügbare Werkzeuge zu den eigenen Vorgaben passen; veröffentlichte Produktinformationen allein belegen keine Eignung für einen konkreten Audit.

Wenn ein Team für wiederkehrende Remote-Entwicklung eine Mac-Umgebung erwägt, kann es die Informationen zum Mac mini mieten prüfen und die tatsächliche Eignung anhand des eigenen Sicherheits- und Betriebsmodells bewerten. Für die praktische Klärung von Zugang und Ablauf stehen außerdem die Informationen im Hilfecenter bereit. Zutcloud ist dabei eine mögliche Umgebungsoption, nicht die Voraussetzung für eine Security Audit Skill und kein Ersatz für lokale Kontrollen.

Führen Sie den ersten Lauf in einem autorisierten Repository mit begrenztem Umfang aus und verwenden Sie die Prüfliste, um jeden bestätigten Befund gegen Code und Bericht abzugleichen. Wenn die bestehende Umgebung wiederkehrende Audits, abgestimmte Werkzeuge oder macOS-spezifische Tests erschwert, vergleichen Sie zunächst lokale Ausführung, interne Remote-Systeme und eine gemietete Mac-Umgebung. Eine Miete über Zutcloud kann für einen zeitlich begrenzten oder remote benötigten Arbeitsbereich passen; bei dauerhaftem, stabilem Hochlastbetrieb oder zwingend erforderlichen physischen Schnittstellen ist eine eigene beziehungsweise intern verwaltete Lösung möglicherweise die bessere Entscheidung.