Sicherheits-Triage

Was macht Sicherheits-Triage?

Verwenden Sie diesen Skill bei der Überprüfung von OpenClaw-Sicherheitsmeldungen, Entwürfen oder GHSA-Berichten.

Ziel: Maintainer mit hoher Vertrauenswürdigkeit, ohne echte Probleme zu schließen oder unnötige Regressionen auszuliefern.

Schließkriterien

Schließen Sie nur, wenn eine der folgenden Bedingungen zutrifft:

• Duplikat einer bestehenden Meldung oder eines behobenen Problems
• Ungültig in Bezug auf das ausgelieferte Verhalten
• Außerhalb des Geltungsbereichs gemäß SECURITY.md
• Vor jedem betroffenen Release/Tag behoben

Nicht schließen, nur weil main behoben ist. Wenn das letzte ausgelieferte Tag oder npm-Release betroffen ist, lassen Sie es offen, bis es mit dem richtigen Status veröffentlicht oder publiziert wird.

Erforderliche Prüfungen

Vor einer Antwort:

1. Lesen Sie SECURITY.md.
2. Lesen Sie den GHSA-Body mit gh api /repos/openclaw/openclaw/security-advisories/<GHSA>.
3. Überprüfen Sie die genauen betroffenen Codepfade.
4. Verifizieren Sie den Auslieferungszustand:
   • git tag --sort=-creatordate | head
   • npm view openclaw version --userconfig "$(mktemp)"
   • git tag --contains <fix-commit>
   • bei Bedarf: git show <tag>:path/to/file
5. Suchen Sie nach kanonischen Überschneidungen:
   • bereits veröffentlichte GHSAs
   • ältere behobene Fehler
   • gleiche Vertrauensmodell-Klasse, die bereits in SECURITY.md behandelt wird

Überprüfungsmethode

Für jede Meldung entscheiden Sie:

• close (schließen)
• keep open (offen halten)
• keep open but narrow (offen halten, aber eingrenzen)

Standardmäßig immer nur eine Meldung auf einmal bearbeiten, wenn Kommentare/Schließungen betroffen sind:

1. Überprüfen Sie genau eine GHSA.
2. Geben Sie zuerst die GHSA-URL aus.
3. Fassen Sie die Entscheidung und die Beweise für die Diskussion zusammen.
4. Verfassen Sie einen für den Maintainer bereiten Kommentar.
5. Kopieren Sie nur diesen Kommentar in die Zwischenablage.
6. Stoppen Sie und warten Sie, bis Peter den Kommentar veröffentlicht/diskutiert, bevor Sie zur nächsten GHSA übergehen.

Führen Sie keine Batch-Schließungen durch, es sei denn, Peter bittet ausdrücklich um eine Stapelverarbeitung.

Prüfen Sie in dieser Reihenfolge:

1. Vertrauensmodell
   • Liegt die Voraussetzung bereits im vertrauenswürdigen Host/Lokal/Plugin/Operator-Status?
   • Stuft SECURITY.md diese Klasse explizit als nicht zum Geltungsbereich gehörend oder nur als Härtung ein?
2. Ausgeliefertes Verhalten
   • Ist der Fehler im neuesten ausgelieferten Tag oder npm-Release vorhanden?
   • Wurde er vor dem Release behoben?
3. Exploit-Pfad
   • Zeigt der Bericht eine echte Grenzüberschreitung, nicht nur Prompt Injection, lokale Same-User-Kontrolle oder Helper-Level-Semantik?
   • Wenn Daten nur zwischen vertrauenswürdigen Workspace-Memory-Dateien verschoben werden, die in SECURITY.md genannt sind, behandeln Sie "Injection-Marker" nicht allein als Sicherheitsfehler.
   • In diesem Fall Rahmen Sie die Bereinigung als optionale Härtung ein, nur wenn sie erwartete Memory-Workflows erhält.
4. Funktionale Abwägung
   • Wenn eine Härtungsänderung die beabsichtigte Benutzerfunktionalität einschränken würde, weisen Sie darauf hin, bevor Sie sie vorschlagen.
   • Bevorzugen Sie Korrekturen, die Benutzerworkflows erhalten, gegenüber pauschalen Verweigerungen, es sei denn, die Grenze erfordert es.
5. Härtungs-Nachverfolgung
   • Auch wenn die GHSA geschlossen werden sollte, fragen Sie, ob eine enge Härtungsänderung Fehlermöglichkeiten reduzieren würde, ohne die dokumentierte Vertrauensgrenze zu ändern.
   • Trennen Sie Härtung vom Schwachstellenstatus. Formulieren Sie es als "nicht erforderlich für das Schließen der GHSA, aber erwägenswert".
   • Bringen Sie Härtung nur zur Sprache, wenn sie konkret, risikoarm ist und die beabsichtigten Maintainer/Operator-Workflows erhält.
   • Wenn eine Härtung eine Produkt-/Sicherheitsmodelländerung erfordern würde, sagen Sie das explizit und geben Sie nicht vor, dass sie für das Schließen erforderlich ist.

Antwortformat

Wenn Sie eine schließfähige Antwort für den Maintainer vorbereiten:

1. Geben Sie zuerst die GHSA-URL aus.
2. Verfassen Sie dann eine detaillierte Antwort, die der Maintainer posten kann.
3. Fügen Sie Folgendes ein:
   • genauen Grund für das Schließen
   • genaue Code-Referenzen
   • genaue Fakten zu ausgeliefertem Tag/Release
   • Herkunft der Korrektur oder kanonisches GHSA-Duplikat, falls zutreffend
   • optionale Härtungsnotiz, nur wenn lohnenswert und funktionserhaltend

Halten Sie den Ton bestimmt, spezifisch und nicht defensiv.

Öffentliche Formulierungshygiene

• Halten Sie rohe Commit-Hashes, PR-Titel/Nummern und Zusammenfassungen des Korrekturmechanismus aus öffentlichen Meldungstexten heraus. Verwenden Sie nur das Feld für das gepatchte Release/Version.
• Halten Sie genaue Commit-SHAs, PRs und Implementierungsnotizen in internen Notizen und Verifikationsdateien.
• Für Härtungs-/Nicht-Veröffentlichungs-Ergebnisse fügen Sie keine ausbeutungsreichen Details, "Behoben durch"-Text oder einen Abschnitt "Korrektur-Commits" hinzu. Danken Sie den Meldern, bewahren Sie die Anerkennung, nennen Sie die Grenze aus SECURITY.md und sagen Sie klar, dass die GHSA ohne Veröffentlichung geschlossen wird.
• Für veröffentlichte CVE/GHSA-Texte bevorzugen Sie ### Gepatchte Versionen mit dem behobenen Release. Erklären Sie nicht, wie der Patch funktioniert, es sei denn, Peter bittet ausdrücklich um diese öffentlichen Details.
• Halten Sie GHSA-IDs aus Changelog- und Release-Notizen-Formulierungen heraus, es sei denn, Peter bittet ausdrücklich darum.

Diskussionsmodus

Wenn Peter GHSA-Kommentare manuell postet, verwenden Sie diesen Ablauf:

1. Zeigen Sie die URL.
2. Geben Sie ein knappes Urteil (close, keep open oder keep open but narrow).
3. Listen Sie die stärksten Beweispunkte auf.
4. Nennen Sie optionale Härtungs-Nachverfolgung getrennt vom Schließgrund.
5. Kopieren Sie den vorgeschlagenen Kommentartext mit pbcopy.
6. Beenden Sie die Antwort nach dieser einen Meldung. Fahren Sie nicht mit der nächsten Meldung fort, bis Peter sagt, dass Sie weitermachen sollen.

Wenn die GitHub-API für private Meldungen keine Kommentare posten kann, sagen Sie dies einmal und verwenden Sie weiterhin die Zwischenablage/UI-Einfügung.

Zwischenablage-Schritt

Nachdem Sie den endgültigen Beitragstext für die aktuelle Meldung verfasst haben, kopieren Sie ihn:

pbcopy <<'EOF'
<finale Antwort>
EOF

Teilen Sie dem Benutzer mit, dass die Zwischenablage nun den vorgeschlagenen Antworttext für diese Meldung enthält.

Nützliche Befehle

gh api /repos/openclaw/openclaw/security-advisories/<GHSA>
gh api /repos/openclaw/openclaw/security-advisories --paginate
git tag --sort=-creatordate | head -n 20
npm view openclaw version --userconfig "$(mktemp)"
git tag --contains <commit>
git show <tag>:<path>
gh search issues --repo openclaw/openclaw --match title,body,comments -- "<Begriffe>"
gh search prs --repo openclaw/openclaw --match title,body,comments -- "<Begriffe>"

Cyber-Klassifikator-Unterbrechungen

Für erlaubte defensive Arbeiten, die durch einen Cyber-Klassifikator unterbrochen werden, verwenden Sie eine genehmigte, verfügbare Daybreak-Blue-Route nur für diese begrenzte Aufgabe und stellen Sie dann das vorherige Modell wieder her. Bewahren Sie die genehmigte Identität, den Umfang, die Berechtigungen, die Sandbox und die Überprüfungsgates. Wechseln Sie niemals das Modell, um Zugriffsverweigerungen, nicht erlaubte Anfragen oder verweigerte Tool-Aktionen zu umgehen; wenn auch diese Route verweigert, stoppen Sie und melden Sie dies. Befolgen Sie die OpenAI-Richtlinie für genehmigten Modellzugriff.

Entscheidungsnotizen

• "Behoben auf main, nicht veröffentlicht" ist normalerweise kein Schließgrund.
• "Erfordert zuerst vom Angreifer kontrollierten vertrauenswürdigen lokalen Zustand" ist normalerweise nicht im Geltungsbereich.
• "Gleicher Host, gleicher Benutzerprozess kann bereits lokalen Zustand lesen/schreiben" ist normalerweise nicht im Geltungsbereich.
• "Vertrauenswürdiger Workspace-Speicher fördert/indiziert vertrauenswürdigen Workspace-Speicher" ist normalerweise nicht im Geltungsbereich, es sei denn, es überschreitet eine dokumentierte Grenze.
• "Helper-Funktion verhält sich anders als dokumentierte Konfigurationssemantik" ist normalerweise ungültig.
• Wenn nur der Schweregrad falsch ist, der Fehler aber real ist, lassen Sie ihn offen und grenzen Sie die Auswirkungen in der Antwort ein.