Claude Code Security Skills: 34 defensive Playbooks aus realer Studio-Praxis

Der Anlass: ein Anruf, den wir nicht erwartet haben

Es war ein Mittwoch Ende April. Ein Bestandskunde meldet sich, kurz, knapp, leicht panisch: seine WordPress-Site verhalte sich seltsam, seit ein paar Stunden. Wir greifen zu, ziehen den ersten Faden, und nach drei Stunden wissen wir: nicht eine Site, sondern 30 von 37 WordPress-Installationen auf demselben Hosting-Account sind kompromittiert. Eine Webshell-Familie, die seit Jahren unter dem Namen "Sid Gifari" zirkuliert, hat sich quer durch den Account propagiert.

Die Signatur war eindeutig und peinlich vorhersehbar. Drei Lücken, immer dieselben: ein ungepatchtes Theme von einem Marketplace, das vor 14 Monaten ein bekanntes RCE-Issue hatte. Kein Login-Lockout, also Brute-Force über XML-RPC. Keine File-Integrity-Überwachung, also lag die Webshell als wp-cache.php getarnt im Plugin-Root und niemand hat sie wochenlang gesehen.

Was uns die nächste Woche beschäftigt hat, war nicht die Cleanup-Arbeit selbst. Die ist Routine: Webshells lokalisieren, hashen, Original-Dateien aus den WP-Core-Source-Trees restaurieren, Datenbank-Inhalt forensisch prüfen, Passwörter rotieren, Defense-Pack auf alle 37 Subs ausrollen, Cron für Wordfence und File-Integrity einrichten, Backups validieren.

Was uns wirklich beschäftigt hat: wir hatten die Schritte für genau dieses Szenario schon dreimal aufgeschrieben. Einmal nach einem vergleichbaren Vorfall vor zwei Jahren, einmal als interne Best-Practice-Doku, einmal als Leitfaden für einen Junior-Kollegen. Jedes Mal hatten wir das Wissen. Aber es lag auf drei verschiedenen Notion-Pages, einem alten Confluence-Wiki und einer Markdown-Datei in einem internen Repo.

In der Woche danach kam die Erkenntnis: wir haben das Wissen, wir haben es nur nie konsumierbar gemacht. Weder für unser eigenes Team unter Zeitdruck, noch für die Coding-Agents, mit denen wir und unsere Kunden mittlerweile täglich arbeiten.

Heute veröffentlichen wir die Library, die daraus entstanden ist.

Was die Library ist

claude-security-skills ist eine Open-Source-Sammlung von 34 defensiven Security-Playbooks für LLM-basierte Coding-Agents. Funktioniert mit Claude Code, Cursor, GitHub Copilot, Codex CLI, Cline, Gemini CLI. Überall dort, wo der Agent strukturierte Prompts aus dem Workspace lesen kann.

Jeder Skill ist eine Markdown-Datei mit einer YAML-Frontmatter (name, description). Der Coding-Agent matched die Beschreibung semantisch gegen das, worüber gerade gesprochen wird, und zieht sich den passenden Playbook automatisch in den Kontext. Sie tippen keinen Befehl. Der Agent erkennt selbstständig "ah, hier geht's um WordPress-Härtung" und befolgt die entsprechenden Schritte.

13 Domänen, 34 Skills, MIT-Lizenz, v1.0.0 ist heute draußen.

Die Mandate hinter der Library

Wir wollten keine theoretische Library bauen. Jeder Skill, der im Repo liegt, kommt aus einem konkreten Mandat aus den letzten zwölf Monaten. Hier die vier Engagements, die das Rückgrat der Library bilden.

Mandat 1: Hosting-Account-Konsolidierung nach Webshell-Vorfall

Der eingangs beschriebene Vorfall. Was die Cleanup-Arbeit zur Library gemacht hat, war die Erkenntnis, dass WordPress-Sicherheit auf Shared Hosting nicht auf Site-Ebene gelöst wird, sondern auf Account-Ebene. Eine einzelne kompromittierte Sub-Domain reicht aus, um über Cross-Account-File-Permissions oder gemeinsame Datenbank-User Lateral Movement durchzuführen.

Aus diesem Mandat sind drei Skills entstanden: wordpress-hardening (Site-Level), shared-hosting-isolation (Account-Level Defense-Pack mit File-Integrity-Cron, mu-Plugin-Audit-Backdoor und automatisiertem Plugin-Patch-Status-Report), und incident-response-wordpress (Forensik-Reihenfolge, was an Logs gesichert wird, wann der Hoster informiert werden muss).

Ein Coding-Agent, der diese drei Skills im Kontext hat, kann eine WordPress-Site nicht "nur einbauen". Er prüft erst, in welchem Hosting-Setup er ist, schaut nach den File-Permissions auf Account-Ebene, schlägt das Defense-Pack vor und implementiert es.

Mandat 2: Greenfield-VPS-Hardening für SaaS-Backend

Ein Kunde hat einen neuen Hetzner-Cloud-VPS aufgesetzt, Debian 12, plant einen NestJS-Backend-Service mit Postgres als Production. Klassisches Greenfield, kein Legacy. Wir wurden gefragt, das Setup einmal komplett mit defensiven Standards zu fahren, bevor irgendwelche Apps drauflanden.

Was wir am Ende ausgeliefert haben, waren acht aufeinander aufbauende Konfigurations-Schritte: UFW-Regelwerk, SSH-Key-Only mit fail2ban, automatische Security-Updates ohne automatisches Reboot, Postgres mit Listen-Address auf localhost und Connection-Pool-Limits, Backup-Strategie mit Off-Site-Encryption über restic auf B2, Cloudflare-Origin-IP-Schutz mit Authenticated Origin Pulls (damit kein Direct-IP-Bypass möglich ist), Secrets-Management über systemd-Environment-Files mit 600-Permissions und Vault-Read-Only-User für die App, plus monitoring mit fail2ban-Webhooks in einen privaten Slack-Channel.

Genau diese acht Schritte hatten wir bei drei vorherigen VPS-Hardenings in derselben Reihenfolge schon implementiert. Aus diesem Mandat sind die Skills vps-hardening-debian, cloudflare-origin-protection, postgres-listen-hardening, secrets-management-systemd, backup-strategy-restic und fail2ban-monitoring entstanden, sechs Skills aus einem Mandat.

Mandat 3: Security-Audit einer verteilten Agent-Plattform

Ein Klient betreibt eine eigene LLM-Agent-Plattform: ein Server-Cluster, das Tasks orchestriert, plus Worker-Clients, die in isolierten Containern laufen, plus ein NATS-Message-Bus dazwischen. Wir wurden geholt, einen Security-Audit zu fahren, bevor sie auf eine breitere Beta gehen.

Die Findings, die uns am meisten überrascht haben:

• NATS lief ohne ACLs. Jeder Worker konnte auf alle Subjects subscriben, auch auf die, die für andere Worker bestimmt waren. Ein kompromittierter Worker hätte die komplette Task-Queue mitlesen können.
• Tool-Calls vom Agent zum Server hatten keine Re-Validation der Auth. Der Agent hat ein JWT bei der Initial-Connection bekommen und es danach für jeden Tool-Call wiederverwendet, ohne Refresh, ohne Scope-Verengung pro Call.
• MCP-Server vertrauten dem Agent vollständig. Die MCP-Tools haben angenommen, dass der Agent verantwortungsvoll Inputs validiert. Was der Agent natürlich nicht tut, wenn die Inputs aus Prompt-Injection-fähigen Quellen kommen.

Aus diesem Audit sind die Skills nats-acl-patterns, mcp-server-hardening, prompt-injection-defense und agent-jwt-rotation entstanden. Plus ein längerer Skill distributed-agent-architecture-review, der die Audit-Methodik dokumentiert.

Mandat 4: Inheritance-Audit eines 12 Monate alten NestJS-Codebases

Ein Klient hatte einen Backend-Service vom vorigen Dienstleister übernommen: 12 Monate Code, rund 40.000 Zeilen, keine Doku, ehemaliger Lead nicht mehr ansprechbar. Auftrag: "macht uns einen Brief, was hier drin ist und wo es brennt."

Wir haben einen reproduzierbaren Audit-Prozess durchgezogen, in dieser Reihenfolge: gitleaks zuerst (drei Sekunden, fängt vergessene API-Keys in der Git-History; wir haben sieben gefunden, zwei davon noch aktiv). Dann semgrep mit dem auto-Ruleset (zwei Minuten, fängt 80 Prozent der OWASP-Top-10-Patterns; 23 Findings, davon vier kritisch). Dann CodeQL für Datenfluss-Analysen (eine halbe Stunde, fängt die Dinge, die semgrep nicht findet; drei zusätzliche Findings, alle drei tatsächlich exploitable). Dann ein manueller Architekturreview entlang der Auth- und Datenfluss-Pfade.

Total: drei Stunden Wall-Time, 18 actionable Findings, ein 14-Seiten-Brief mit Severity, Reproduzierbarkeit und Fix-Vorschlag pro Finding.

Aus diesem Mandat ist der Skill codebase-audit entstanden: die Reihenfolge, die Tool-Auswahl, was in welchen Output-Brief gehört, wann manuelle Review-Schritte unausweichlich sind.

Wie es technisch funktioniert

Jeder Skill ist eine Markdown-Datei mit zwei Pflichtfeldern in der Frontmatter:

---
name: wordpress-hardening
description: Use this skill when working on WordPress sites,
  addressing security vulnerabilities, hardening shared hosting
  environments, or responding to webshell incidents.
---

Der Body enthält den Playbook in Prosa: Diagnose-Schritte, konkrete Befehle, typische Fehler, Verifikations-Checkliste. Klare Sprache, keine Querverweis-Tabellen pro Zeile. Der Agent versteht den semantischen Kontext besser, wenn er normale Anleitung liest, statt eine Mapping-Matrix zu parsen.

Der Coding-Agent lädt die Skills beim Start aus dem .claude/skills/-Verzeichnis (oder dem äquivalenten Pfad seiner Plattform) und matched die description semantisch gegen das, worüber im Gespräch geredet wird. Wenn Sie sagen "Ich migriere gerade einen Express-Server nach Cloudflare Workers", zieht er sich automatisch die relevanten Skills (Origin-Hardening, Secrets-Management, Worker-spezifische Caveats) in den Kontext. Sie tippen keinen Befehl ab.

Für programmatische Verwendung gibt es einen index.json. Wer eigene Tooling drumherum baut, etwa einen MCP-Server, der die Skills als Resources serviert, oder ein CI-System, das den Agent vor jedem PR mit dem passenden Subset bootet, kann darüber den vollen Katalog lesen.

Installation ist git clone ins Projekt-Root oder in ~/.claude/skills/ für globale Verwendung. Keine npm-Dependencies, keine Build-Steps, keine Runtime. Nur Markdown-Dateien.

Fünf Skills, die wir hervorheben

Aus 34 hier die fünf, die wir am häufigsten reaktiv gebraucht hätten und die jetzt proaktiv im Werkzeugkasten Ihres Agents leben.

wordpress-hardening

Anker dieser ganzen Library. Drei-Schichten-Ansatz: Account-Level (alle Subs auf einem Hosting-Account isolieren, Defense-Pack-Cron einrichten), Site-Level (Wordfence plus 2FA plus Login-Lockout plus File-Integrity-Monitor), Forensik (mu-Plugin als Read-Only-Audit-Backdoor, das Hashes von wp-config.php, .htaccess und allen Plugin-Roots stündlich loggt). Wenn der Agent auf einer WordPress-Codebase arbeitet und Datei-Mutationen vorschlägt, prüft er erst, ob die Site noch in einem cleanen Zustand ist.

ai-agent-guardrails

Antwort auf die Frage "Was passiert, wenn der Agent eine Bulk-Operation auslöst, die er nicht zurücknehmen kann?". Pattern: dry-run-first, plus Confirm-Threshold (--apply ab dem N-ten Schreibvorgang, default N=1 bei zerstörerischen Operationen). Plus Logging aller Mutationen in eine Append-Only-Datei, gegen die der Agent vor jedem --apply prüft, ob er nicht denselben Vorgang bereits ausgeführt hat. Verhindert die Klasse "Agent löscht versehentlich 10.000 Datenbankzeilen, weil er die Idempotenz-Garantie missverstanden hat".

codebase-audit

Methodik fürs Erben unbekannter Codebases (siehe Mandat 4 oben). Reihenfolge, Tool-Auswahl, Output-Format. Ein Coding-Agent, der diesen Skill lädt, baut bei jedem neuen Projekt zuerst eine AUDIT-FINDINGS.md im Repo-Root auf, gegen die er ab dann arbeitet, statt jede Session bei Null anzufangen.

prompt-injection-defense

Pattern, das wir "untrusted-since-confirm" nennen. Wenn der Agent fremden Input verarbeitet (Markdown aus einer User-Submission, Inhalt einer E-Mail, Output eines Tools, das selbst LLM-generiert ist), wird dieser Input ab dem Empfangs-Punkt als untrusted markiert und bleibt das, bis ein menschlicher Confirm passiert. Konkret: keine Tool-Calls, keine Sub-Agent-Spawns, keine API-Writes basierend auf untrusted Content ohne explizite Approval. Verhindert die Klasse "PDF mit versteckten Instructions wird vom Agent ausgeführt".

dach-compliance

Anker für unseren lokalen Markt. Impressum, Datenschutzerklärung, AGB nach AT/DE/CH-Recht; Cookie-Consent nach TTDSG/DSG; Auftragsverarbeitungsverträge bei US-Subprocessors. Wenn der Agent eine neue Page für einen DACH-Kunden baut, prüft er, ob die drei Pflicht-Pages existieren und korrekt verlinkt sind, bevor er Production-Ready signalisiert.

Plus 29 weitere: Postgres-Hardening, Backend-Architecture-Patterns, E-Mail-Security mit DMARC/DKIM/SPF, Mobile-App-Security, Secrets-Management, Session-Auth-Patterns, Origin-IP-Protection, etcetera. Vollständige Liste im Repo.

Bewusste Design-Entscheidungen

Drei Entscheidungen, die wir explizit getroffen haben, weil sie nicht selbstverständlich sind:

Defensive only. Kein Red-Team-Material, keine Exploit-PoCs, keine Skills, die Agents beibringen, wie man durch eine WAF bricht. Wir richten uns an Teams, die Production-Code shippen, nicht an Pen-Tester. Diese Entscheidung schließt eine ganze Klasse möglicher Skills aus, was die Library kleiner macht. Das ist Absicht.

Erfahrung vor Vollständigkeit. Jeder Skill in der Library kommt aus einem konkreten Mandat, an dem wir gearbeitet haben. Kein theoretisches Material, keine Skills für Themen, mit denen wir keine eigene Praxis haben. Wir würden lieber 34 Skills in voller Tiefe veröffentlichen als 200 in halber.

Multi-Plattform-Format. Skills sind reines Markdown mit YAML-Frontmatter, kein Tool-spezifischer Code. Wir testen primär gegen Claude Code, aber Cursor, Copilot, Codex CLI und Gemini CLI laden sie genauso. Pull Requests für Plattform-Spezifika sind willkommen. Compliance-Mapping (OWASP, PCI-DSS, ISO 27001) ist bewusst nicht Teil der Library: das ist die Aufgabe des Auditors, nicht des Coding-Agents. Was der Agent braucht, ist klare Anleitung in lesbarer Sprache.

Was als Nächstes kommt

Der nächste Schwung Skills ist in Arbeit, alle aus laufenden oder kürzlich abgeschlossenen Mandaten:

• postgres-hardening (RLS-Patterns, Connection-Pool-Limits, pgaudit-Setup), kommt aus einem Multi-Tenant-SaaS-Mandat
• terraform-iac-security (Provider-Auth, State-File-Encryption, Drift-Detection), kommt aus einer Cloud-Migration für einen Klienten in Q1
• threat-modeling-with-agent (STRIDE-basiert, geführt durch den Agent), kommt aus zwei Architekturreviews, in denen wir den Agent als strukturierten Interview-Partner für Threat-Modeling eingesetzt haben
• kubernetes-cluster-hardening (PodSecurityStandards, NetworkPolicies, PSA-Migration), kommt aus einem Cluster-Audit, der gerade läuft

Dazu prüfen wir gerade einen MCP-Server-Wrapper, der die Skills als zentrale Resource serviert, sodass Sie nicht in jedem Projekt klonen müssen, sondern Ihr Agent sich live aus dem Index zieht.

Weitere Posts in dieser Serie folgen. Der heutige Companion-Artikel auf dev.to behandelt zehn Antipatterns, die wir bei AI-generated Code in Produktion immer wieder sehen, eine gute Einstiegslektüre, bevor Sie die Library installieren.

Mitmachen oder mit uns arbeiten

Repo: github.com/GoldenWing-360/claude-security-skills, MIT-Lizenz, Pull Requests willkommen. Eine kuratierte Prompt-Library im Wiki zeigt, wie Sie die Skills in einer Live-Session aktivieren.

Companion-Artikel auf dev.to: 10 Security Mistakes Claude Code and Copilot Make in Production.

Wenn Sie diese Patterns auf Ihren Stack angewendet haben wollen, sei es ein WordPress-Konglomerat nach einem Vorfall, ein Greenfield-VPS-Setup mit Cloudflare-Origin-Schutz, ein Audit Ihrer LLM-integrierten Backend-Services oder eine Übernahme eines unbekannten Codebases, sprechen Sie uns an. Wir machen das hauptberuflich.