Wie Claude Desktop und Claude Code CLI Security-Standards über Dutzende Repositories hinweg konsistent durchsetzen
SerieSupply Chain Security
Teil 4 von 8
Nach den ersten drei Teilen dieser Serie – Bedrohungen erkennen, Lösungen implementieren, Karrieren aufbauen – stellt sich eine praktische Frage: Wie verwaltet man Security-Konfigurationen über Dutzende von Repositories hinweg konsistent?
Die Antwort liegt nicht in komplexen CI/CD-Pipelines oder teuren Enterprise-Tools. Sie liegt in der Art, wie wir mit KI-Assistenten arbeiten.
Das Problem: Fragmentierte Security-Konfigurationen
Ein typisches Entwicklungsteam arbeitet heute mit:
- 15-30 aktiven Repositories
- 5-10 verschiedenen Dependency-Management-Tools
- 3-5 unterschiedlichen CI/CD-Systemen
- Unzähligen Ad-hoc-Security-Checks
Jedes Repository hat seine eigenen Pre-Commit-Hooks, seine eigenen Renovate-Konfigurationen, seine eigenen GitHub Actions. Wenn eine neue Schwachstelle bekannt wird – wie die GitHub Actions Injection CVE-2025-30066 aus Teil 1 – müssen diese Konfigurationen in jedem einzelnen Repository aktualisiert werden.
Claude Projects: Zentrale Security-Richtlinien
Claude Projects von Anthropic bieten eine interessante Lösung für dieses Problem. Ein Claude Project kombiniert drei Komponenten:
1. Custom Instructions Zentrale Anweisungen, die für jede Konversation im Project gelten.
2. Knowledge Base (200K-Token-Kontextfenster, bei Paid Plans automatisch via RAG auf das bis zu 10-fache erweiterbar) Referenzmaterial, das Claude automatisch nutzen kann. Einzelne Dateien bis 30 MB in gängigen Formaten (PDF, DOCX, CSV, TXT, HTML).
3. Model Context Protocol (MCP) Server Verbindungen zu externen Tools und Datenquellen.
Der entscheidende Vorteil: Ein Project definiert die Security-Richtlinien einmal. Jedes Repository, das innerhalb dieses Projects geöffnet wird, folgt automatisch denselben Standards.
Custom Instructions: Die zentrale Security-Policy
Die Custom Instructions eines Projects funktionieren wie eine universelle Sicherheitscheckliste. Ein Beispiel für ein DevSecOps-Project:
# Security Review Standards
## Dependency Management
Bei jeder Code-Review prüfe:
- Sind neue Dependencies in package.json/requirements.txt mit pinned versions?
- Existiert eine Abhängigkeit von Packages mit unter 1.000 Downloads/Woche?
- Sind alle Dependencies mit npm audit / pip-audit / cargo audit geprüft?
## GitHub Actions Security
Für jeden Workflow in .github/workflows/:
- Verwendet pull_request_target? → Flag als kritisch
- Nutzt actions/checkout ohne explicit ref? → Flag als Risiko
- Werden Secrets in Umgebungsvariablen exponiert?
## API-Security
Bei REST/GraphQL-Endpoints prüfe:
- Rate-Limiting implementiert?
- Input-Validierung mit Schema (Zod, Pydantic, etc.)?
- Authentication/Authorization korrekt implementiert?
## Reporting
Fasse Findings in drei Kategorien:
- **Kritisch**: Muss vor Merge behoben werden
- **Wichtig**: Sollte in diesem Sprint behoben werden
- **Nice-to-have**: Kann später optimiert werdenDiese Instructions gelten für jedes Repository, das im Project geöffnet wird – ob Frontend, Backend, Infrastructure-as-Code oder Dokumentation.
Knowledge Base: Organisatorische Security-Policies
Die Knowledge Base enthält die spezifischen Richtlinien der Organisation:
Dokument 1: Approved Dependencies
Eine Liste freigegebener Packages mit zugelassenen Versionen:
# approved-dependencies.yaml
javascript:
axios: "^1.6.0" # Approved: 2024-11-15
lodash: "BLOCKED" # Reason: Tree-shaking issues
python:
requests: "^2.31.0" # Approved: 2024-10-01
pyyaml: "^6.0.1" # Requires: safe_load onlyDokument 2: CI/CD Templates
Vorgefertigte, sichere Workflow-Definitionen:
# secure-node-ci.yml
name: Secure Node.js CI
on:
pull_request: # NICHT pull_request_target
branches: [main]
jobs:
security-check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
ref: ${{ github.event.pull_request.head.sha }} # Explicit ref
- name: Dependency Audit
run: npm audit --audit-level=moderate
- name: SAST Scan
uses: github/codeql-action/analyze@v3Dokument 3: Incident Response Playbook
Was tun, wenn eine Schwachstelle bekannt wird:
# Incident Response: Compromised Dependency
1. **Sofort** (unter 1 Stunde):
- Dependency aus allen package.json/requirements.txt entfernen
- PR erstellen mit Fix
- Slack #security-incidents benachrichtigen
2. **Innerhalb 4 Stunden**:
- Überprüfen: Wurde die kompromittierte Version deployed?
- Logs prüfen: Verdächtige Aktivität?
- Falls deployed: Rollback initiieren
3. **Innerhalb 24 Stunden**:
- Post-Mortem erstellen
- CI/CD anpassen: Wie wurde die Dependency überhaupt merged?Claude liest diese Dokumente automatisch und berücksichtigt sie bei Code-Reviews.
MCP-Server: Externe Tool-Integration
Model Context Protocol (MCP) ist der interessanteste Teil. MCP verbindet Claude Desktop mit externen Systemen – von Datenbanken über Git bis zu custom Security-Tools.
Beispiel 1: GitHub MCP-Server
Der GitHub MCP-Server ermöglicht Claude direkten Zugriff auf Repository-Metadaten:
// claude_desktop_config.json
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxx"
}
}
}
}Damit kann Claude:
- Alle Repositories einer Organisation auflisten
- Issues und Pull Requests durchsuchen
- Branch-Protection-Rules prüfen
- Dependabot-Alerts aggregieren
Use Case: “Liste alle Repositories mit aktivem pull_request_target in Workflows”
Claude greift via MCP auf GitHub zu, parsed alle .github/workflows/*.yml Dateien und erstellt einen Report – über Hunderte von Repositories hinweg.
Beispiel 2: Custom Security-Tool MCP-Server
Ein selbst entwickelter MCP-Server kann interne Security-Tools anbinden:
// mcp-server-security-dashboard.ts
import { Server } from '@modelcontextprotocol/sdk/server/index.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
const server = new Server({
name: 'security-dashboard',
version: '1.0.0',
}, {
capabilities: {
tools: {},
},
});
// Tool: Aktuelle CVEs für dependencies abrufen
server.setRequestHandler('tools/call', async (request) => {
if (request.params.name === 'get_cve_status') {
const { package_name, version } = request.params.arguments;
// Abfrage gegen interne Vulnerability-DB
const cves = await vulnerabilityDB.query({
package: package_name,
version: version,
});
return {
content: [{
type: 'text',
text: JSON.stringify(cves, null, 2),
}],
};
}
});
const transport = new StdioServerTransport();
await server.connect(transport);Konfiguration in claude_desktop_config.json:
{
"mcpServers": {
"security-dashboard": {
"command": "node",
"args": ["/path/to/mcp-server-security-dashboard.js"],
"env": {
"VULN_DB_API_KEY": "xxx"
}
}
}
}Use Case: Während einer Code-Review ruft Claude automatisch CVE-Daten für jede neue Dependency ab – ohne dass der Entwickler manuell nachschlagen muss.
Beispiel 3: PostgreSQL für Audit-Logs
Der offizielle PostgreSQL MCP-Server verbindet Claude mit einer Audit-Log-Datenbank:
{
"mcpServers": {
"postgres-audit": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-postgres"],
"env": {
"POSTGRES_CONNECTION_STRING": "your-connection-string-here"
}
}
}
}Use Case: “Zeige mir alle Deployments der letzten 7 Tage, bei denen Dependencies mit bekannten CVEs deployed wurden”
Claude durchsucht die Audit-Log-Datenbank und korreliert Deployment-Events mit CVE-Daten.
Der Workflow in der Praxis
Ein Entwickler öffnet ein Repository in Claude Desktop. Das zugeordnete DevSecOps-Project wird automatisch geladen:
1. Code-Review anfordern
Entwickler: “Review diese Pull Request: #142”
2. Claude liest die Changes
Via GitHub MCP-Server holt Claude den Diff von PR #142.
3. Custom Instructions greifen
Claude prüft automatisch:
- Neue Dependencies? → Check gegen
approved-dependencies.yaml - GitHub Actions geändert? → Prüfung gegen
secure-node-ci.ymlTemplate - API-Endpoints hinzugefügt? → Rate-Limiting vorhanden?
4. Externe Tools werden konsultiert
Via Security-Dashboard MCP-Server:
- CVE-Status für neue Dependencies
- SAST-Scan-Ergebnisse aus interner Tool-Chain
5. Strukturierter Report
Claude liefert:
## Security Review: PR #142
### Kritisch
- `axios@1.5.0` hat bekannte CVE-2024-xxxxx
→ Upgrade auf `axios@1.6.2` erforderlich
### Wichtig
- Neuer Endpoint `/api/users` ohne Rate-Limiting
→ Implementierung gemäß Standard erforderlich
### Nice-to-have
- Error-Messages exponieren Stack-Traces
→ Sollte in Production deaktiviert werdenDer entscheidende Punkt: Diese Review folgt exakt denselben Standards wie in allen anderen Repositories der Organisation – weil die Custom Instructions und Knowledge Base zentral definiert sind.
Wo werden die Konfigurationen gespeichert?
Ein wichtiger Punkt für Unternehmen: Claude Projects sind cloudbasiert, während MCP-Server lokal laufen.
Cloud: Custom Instructions & Knowledge Base
Claude Projects werden bei Anthropic gespeichert:
- Custom Instructions
- Knowledge Base (200K-Token-Kontextfenster, bei Paid Plans via RAG auf bis zu 10x erweiterbar)
- Synchronisiert zwischen Claude Web-App und Claude Desktop
- Zugänglich über alle Geräte mit demselben Account
Das bedeutet: Deine Security-Policies, Approved-Dependencies-Listen und CI/CD-Templates liegen in der Anthropic-Cloud. Vorteil: Team-Mitglieder können dieselben Projects nutzen (nach manueller Einrichtung). Nachteil: Sensible interne Richtlinien werden extern gespeichert.
Lokal: MCP-Server
MCP-Server laufen ausschließlich auf deinem Rechner:
// ~/Library/Application Support/Claude/claude_desktop_config.json (macOS)
// %APPDATA%/Claude/claude_desktop_config.json (Windows)
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxx"
}
}
}
}Diese Konfiguration wird nicht synchronisiert. Jedes Team-Mitglied muss MCP-Server selbst einrichten. Credentials (GitHub-Token, DB-Passwörter) bleiben lokal.
Hybride Realität
In der Praxis kombiniert man beides:
- Cloud (Projects): Generelle Security-Standards, die nicht sensitiv sind
- Lokal (MCP): Zugriff auf interne Systeme (GitHub Enterprise, interne DBs)
Die Grenzen: Was Claude Projects nicht lösen
Es gibt klare Limitierungen:
Keine API für Projects
Claude Projects sind ausschließlich über Claude Desktop und die Web-App zugänglich. Es gibt keine API, um Projects programmatisch zu erstellen oder Custom Instructions via CI/CD zu aktualisieren.
Getrennte Welten: Claude Desktop vs. Claude Code CLI Claude Projects und Claude Code (CLI) sind konzeptionell unterschiedliche Systeme. Claude Code nutzt stattdessen:
- CLAUDE.md: Project-spezifische Instructions im Repository-Root
- .claude/commands/: Custom Slash-Commands pro Repository oder global in
~/.claude/commands/ - .claude/settings.json: Repository-spezifische Konfiguration
Der Vorteil von CLAUDE.md: Die Datei liegt im Repository und wird über Git synchronisiert. Jedes Team-Mitglied mit Claude Code bekommt automatisch dieselben Standards – ohne manuelles Project-Setup.
Keine Enforcement
Claude kann Probleme finden, aber nicht verhindern, dass Code gemerged wird. Dafür sind weiterhin Branch-Protection-Rules und Status-Checks in GitHub notwendig.
Team-Synchronisation
Jedes Team-Mitglied muss das Project manuell einrichten. Es gibt keine zentrale Project-Verwaltung für Organisationen (wie bei GitHub Copilot mit org-weiten Policies).
MCP-Server-Entwicklung
Custom MCP-Server erfordern Entwicklungsaufwand. Die Einstiegshürde ist höher als bei einfachen CLI-Tools.
Claude Projects vs. GitHub Copilot
Der Vergleich mit GitHub Copilot ist naheliegend:
| Feature | Claude Projects | GitHub Copilot |
|---|---|---|
| Custom Instructions | Zentral pro Project | Pro-File .github/copilot-instructions.md |
| Knowledge Base | Dokumente als Referenz (200K Tokens + RAG) | Indexiert gesamtes Repository |
| Tool-Integration | MCP-Server (offener Standard) | MCP-Server (GitHub MCP-Server, MCP Registry) |
| Team-Workflows | CLAUDE.md im Repository | GitHub-native, org-weit, Copilot CLI (GA seit Feb 2026) |
Wo Claude stärker ist: Zentrale Custom Instructions über alle Repositories hinweg, starke Performance bei komplexen Code-Reviews mit großem Kontext, flexible Knowledge Base mit RAG-Erweiterung.
Wo GitHub Copilot stärker ist: Native GitHub-Integration (PRs, Issues, Actions), automatische Indexierung aller Repositories einer Organisation, zentrale Policy-Verwaltung für Admins, eigene MCP Registry für einfache Server-Verwaltung, Copilot CLI als Terminal-nativer Agent.
Wichtig: Beide Systeme unterstützen inzwischen MCP als offenen Standard. Der Unterschied liegt weniger in der Tool-Integration und mehr im Ökosystem: Claude Projects bieten projektübergreifende Custom Instructions; GitHub Copilot ist tiefer in das GitHub-Ökosystem eingebettet.
Claude Code Security: Dedizierte Sicherheitsanalyse
Seit Februar 2026 bietet Anthropic mit Claude Code Security ein eigenständiges Produkt, das den im vorherigen Abschnitt beschriebenen manuellen Ansatz in eine integrierte Lösung überführt. Statt Security-Reviews über Custom Instructions und MCP-Server selbst zu orchestrieren, übernimmt Claude Code Security die Codebase-Analyse direkt.
Das System geht über klassische statische Analyse hinaus: Es nutzt KI-gestütztes Reasoning, um Datenflüsse nachzuverfolgen und subtile Schwachstellen zu identifizieren, die regelbasierte Scanner übersehen. Ein mehrstufiger Verifikationsprozess filtert False Positives, bevor Ergebnisse in einem Dashboard erscheinen. Für jedes Finding liefert das Tool Severity-Ratings, Confidence-Scores und konkrete Patch-Vorschläge – die ausdrücklich menschliche Freigabe erfordern.
Dieser Human-in-the-Loop-Ansatz deckt sich mit der These aus Teil 3 dieser Serie: Automatisierung findet Probleme, Menschen lösen sie. Claude Code Security automatisiert die Erkennung, aber die Entscheidung über Patches bleibt beim Entwicklungsteam.
Verfügbarkeit: Derzeit als Research Preview für Enterprise- und Team-Kunden. Open-Source-Maintainer erhalten beschleunigten Zugang. Claude Code selbst läuft in isolierten virtuellen Maschinen mit Netzwerkkontrollen – ein Sandboxing-Konzept, das Anthropic im Januar 2026 als Open Source veröffentlicht hat.
Einordnung: Für Teams, die den manuellen Ansatz mit Claude Projects und MCP-Servern bereits nutzen, ist Claude Code Security eine Ergänzung – nicht ein Ersatz. Die selbst konfigurierten Workflows (Custom Instructions, Knowledge Base, organisationsspezifische MCP-Server) bleiben für individuelle Policies relevant. Claude Code Security deckt die breite, automatisierte Schwachstellensuche ab, während die Project-basierte Konfiguration die organisationsspezifischen Standards durchsetzt.
Kosten und ROI
Setup-Kosten:
- Claude-Subscription pro Entwickler (aktuelle Preise auf anthropic.com)
- Entwicklung eines Custom MCP-Servers: 2 bis 5 Entwicklertage
- Knowledge Base pflegen: 2 bis 4 Stunden pro Monat
Einsparungen:
Ein Team mit 10 Entwicklern und 25 Repositories: Manuelle Security-Reviews kosten bei 50 PRs pro Woche rund 25 Stunden – eine halbe Minute Lesen, Prüfen, Einordnen pro PR. Mit Claude-gestützter Erstprüfung reduziert sich der manuelle Aufwand auf etwa 4 Stunden pro Woche. Die verbleibende Zeit fließt in die Bewertung der gefilterten Findings.
Wichtiger als die reine Zeitersparung ist die Konsistenz. Jede Review folgt denselben Standards, unabhängig davon, welcher Entwickler sie durchführt oder wie müde dieser am Freitagabend ist.
Der praktische Einstieg
Je nachdem, ob du Claude Desktop (GUI) oder Claude Code (CLI) nutzt, ist der Setup unterschiedlich:
Option 1: Claude Desktop mit Projects
Schritt 1: Project erstellen
In Claude Desktop oder Web-App: Neues Project anlegen, z.B. “DevSecOps Reviews”
Schritt 2: Custom Instructions definieren
Starte mit den 5 häufigsten Security-Problemen in deiner Organisation:
# Security Review Basics
1. Prüfe jede neue Dependency gegen npm audit / pip-audit
2. Suche nach hardcoded Secrets (API-Keys, Passwords)
3. Validiere Input an API-Boundaries (Zod, Joi, Pydantic)
4. Prüfe GitHub Actions auf pull_request_target
5. Suche nach SQL-Injection-Risiken (Raw Queries)Schritt 3: Knowledge Base füllen
approved-dependencies.yaml: Whitelist freigegebener Packagessecure-ci-template.yml: Standard GitHub Actions Workflowcommon-vulnerabilities.md: Top-10-Schwachstellen in eurer Tech-Stack
Schritt 4: GitHub MCP-Server einrichten
# GitHub Personal Access Token erstellen (Scopes: repo, read:org)
# claude_desktop_config.json
cat > ~/Library/Application\ Support/Claude/claude_desktop_config.json <<EOF
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxxxxxxxxxxx"
}
}
}
}
EOFSchritt 5: Testing
Öffne ein Test-Repository in Claude Desktop (im Project!) und frage:
“Prüfe die letzte Pull Request auf Security-Probleme gemäß unserer Standards.”
Claude sollte jetzt Custom Instructions anwenden, Knowledge Base konsultieren und via MCP die PR abrufen.
Option 2: Claude Code CLI (Terminal, VS Code, Zed)
Claude Code nutzt CLAUDE.md-Dateien statt Projects – mit dem Vorteil, dass die Standards direkt im Repository versioniert werden:
Schritt 1: Globale Security-Standards
Erstelle ~/.claude/commands/security-review.md:
---
title: Security Review
description: Prüfe Code-Changes auf Security-Probleme
---
# Security Review Standards
Prüfe die aktuellen Changes auf:
1. **Dependencies**: npm audit / pip-audit ausführen
2. **Secrets**: Hardcoded API-Keys, Passwords suchen
3. **Input-Validierung**: Zod/Joi/Pydantic an Boundaries
4. **GitHub Actions**: pull_request_target vermeiden
5. **SQL-Injection**: Raw Queries identifizieren
Erstelle einen Report mit:
- Kritisch (muss vor Merge behoben werden)
- Wichtig (sollte in diesem Sprint behoben werden)
- Nice-to-have (kann später optimiert werden)Schritt 2: Repository-spezifische Policies
In jedem Repository erstelle CLAUDE.md:
# DevSecOps Standards für [Projekt-Name]
## Approved Dependencies
Nur diese Packages sind freigegeben:
- axios: ^1.6.0
- zod: ^3.22.0
- (siehe vollständige Liste in docs/approved-deps.yaml)
## CI/CD Security
GitHub Actions müssen:
- `pull_request` nutzen (NICHT `pull_request_target`)
- Explicit ref in `actions/checkout@v4`
- Secrets nur in Environment-Variablen mit `${{ secrets.* }}`
## API Security Checklist
- [ ] Rate-Limiting implementiert (express-rate-limit)
- [ ] Input-Validierung mit Zod
- [ ] Authentication über JWT (keine Sessions)
- [ ] CORS richtig konfiguriertSchritt 3: Workflow in Zed/VS Code
# Repository öffnen
cd my-project
# Claude Code starten
claude
# Security-Review ausführen
/security-review
# Oder direkter Prompt
"Prüfe die letzten Git-Changes auf Security-Probleme gemäß CLAUDE.md"Claude Code liest automatisch die CLAUDE.md und wendet die Standards an.
Schritt 4: Sync zwischen Teams
Da CLAUDE.md im Repository liegt, wird es via Git synchronisiert:
git add CLAUDE.md
git commit -m "Add DevSecOps standards for Claude Code"
git pushJedes Team-Mitglied mit Claude Code bekommt automatisch dieselben Standards.
Die Gretchenfrage: Automatisierung vs. Mensch
Wir sind wieder bei der zentralen These aus Teil 3:
Automatisierung findet Probleme. Menschen lösen Probleme.
Claude Projects ändern nichts an dieser Gleichung. Sie verschieben nur, wo die Automatisierung stattfindet:
Ohne Claude Projects:
- Entwickler schreibt Code
- CI/CD führt SAST-Scans aus
- Entwickler reviewed 47 Findings
- Entwickler entscheidet: Was ist kritisch?
Mit Claude Projects:
- Entwickler schreibt Code
- Claude führt Erstprüfung durch (Custom Instructions + MCP)
- Entwickler reviewed 8 gefilterte Findings
- Entwickler entscheidet: Was ist kritisch?
Die Entscheidung bleibt beim Menschen. Aber die Vorabfilterung erfolgt mit konsistenten, zentral definierten Standards.
MCP als offener Standard
Model Context Protocol ist seit November 2024 öffentlich und hat sich zum De-facto-Standard für Tool-Integrationen in KI-Assistenten entwickelt. Über 10.000 aktive MCP-Server decken inzwischen Plattformen von GitHub über AWS bis Kubernetes ab, bei 97 Millionen monatlichen SDK-Downloads. Die Unterstützung ist breit: Claude, ChatGPT, Cursor, Gemini, Microsoft Copilot und VS Code haben MCP-Support integriert.
Für Security-Teams bedeutet das: Einmal entwickelte MCP-Server für interne Vulnerability-Datenbanken oder Audit-Logs funktionieren in verschiedenen Entwicklungsumgebungen – unabhängig davon, welchen Editor das Team bevorzugt.
Konsistenz schlägt Perfektion
Supply Chain Security ist kein einmaliges Projekt. Es ist ein kontinuierlicher Prozess über Dutzende von Repositories, Tools und Teams hinweg.
Claude Projects bieten einen pragmatischen Ansatz: Zentrale Custom Instructions definieren die Standards. Knowledge Base enthält die organisatorischen Policies. MCP-Server verbinden externe Tools.
Die Grenzen sind klar: Keine API, keine Enforcement, manuelles Team-Setup. Aber für Teams, die bereits Claude nutzen, ist der Zusatzaufwand minimal – und die Konsistenz-Gewinne erheblich.
Letztlich geht es nicht darum, ob man Claude oder Copilot nutzt. Es geht darum, ob Security-Standards konsistent über alle Projekte hinweg durchgesetzt werden.
Und dafür braucht es nicht nur Tools. Es braucht Entwickler, die diese Tools konfigurieren, pflegen und kontinuierlich verbessern.
Die Karrierepfade aus Teil 3 sind nicht nur theoretisch. Sie sind notwendig – weil jemand diese zentralen Configurations verwalten muss.
Weiterführende Ressourcen: