Reaktion auf Vorfälle

# 1. Erkennung und Triage

Wir überwachen Sicherheitssignale aus:

• GitHub Security Advisories (GHSA) und privaten Schwachstellenmeldungen.
• Öffentlichen GitHub-Issues/-Diskussionen, wenn Meldungen nicht vertraulich sind.
• Automatisierten Signalen (zum Beispiel Dependabot, CodeQL, npm-Advisories und Secret Scanning).

Erste Triage:

1. Betroffene Komponente, Version und Auswirkungen auf Vertrauensgrenzen bestätigen.
2. Anhand des Geltungsbereichs und der Ausschlussregeln im SECURITY.md des Repositorys als Sicherheitsproblem oder als Härtung/keine Maßnahme klassifizieren.
3. Ein Incident Owner reagiert entsprechend.

# 2. Bewertung

Schweregrad-Leitfaden:

• Critical: Kompromittierung von Paket/Release/Repository, aktive Ausnutzung oder nicht authentifizierte Umgehung einer Vertrauensgrenze mit weitreichender Kontrolle oder Datenoffenlegung.
• High: Verifizierte Umgehung einer Vertrauensgrenze mit begrenzten Vorbedingungen (zum Beispiel authentifizierte, aber nicht autorisierte Aktion mit hoher Auswirkung) oder Offenlegung sensibler Zugangsdaten im Besitz von OpenClaw.
• Medium: Erhebliche Sicherheitsschwäche mit praktischer Auswirkung, aber eingeschränkter Ausnutzbarkeit oder wesentlichen Voraussetzungen.
• Low: Defense-in-depth-Befunde, eng begrenzter Denial-of-Service oder Härtungs-/Paritätslücken ohne nachgewiesene Umgehung einer Vertrauensgrenze.

# 3. Reaktion

1. Eingang gegenüber der meldenden Person bestätigen (privat, wenn vertraulich).
2. Auf unterstützten Releases und dem neuesten main reproduzieren, dann einen Patch mit Regressionsabdeckung implementieren und validieren.
3. Für kritische/hohe Incidents gepatchte Releases so schnell wie praktisch möglich vorbereiten.
4. Für mittlere/niedrige Incidents im normalen Release-Ablauf patchen und Hinweise zur Risikominderung dokumentieren.

# 4. Kommunikation

Wir kommunizieren über:

• GitHub Security Advisories im betroffenen Repository.
• Release Notes/Changelog-Einträge für behobene Versionen.
• Direkte Nachverfolgung mit der meldenden Person zu Status und Lösung.

Offenlegungsrichtlinie:

• Kritische/hohe Incidents sollten koordiniert offengelegt werden, mit CVE-Vergabe, wenn angemessen.
• Härtungsbefunde mit geringem Risiko können je nach Auswirkung und Benutzerexposition ohne CVE in Release Notes oder Advisories dokumentiert werden.

# 5. Wiederherstellung und Nachverfolgung

Nach Auslieferung des Fixes:

1. Behebungen in CI und Release-Artefakten verifizieren.
2. Eine kurze Nachbesprechung des Incidents durchführen (Zeitachse, Ursache, Erkennungslücke, Präventionsplan).
3. Folgeaufgaben für Härtung/Tests/Dokumentation hinzufügen und bis zum Abschluss nachverfolgen.