openclaw-secret-scanning-maintainer

OpenClaw Secret Scanning Maintainer

Nur für Betreuer. Diese Fähigkeit erfordert Admin-/Betreuerberechtigungen für das Repository, um Kommentare anderer Benutzer zu bearbeiten oder zu löschen und Secret Scanning-Warnungen aufzulösen.

Verwenden Sie diese Fähigkeit bei der Verarbeitung von Warnungen von https://github.com/openclaw/openclaw/security/secret-scanning.

Sprachregelung: Alle Benachrichtigungskommentare und Ersatzkommentare MÜSSEN auf Englisch verfasst sein.

Skript

Alle mechanischen Vorgänge (API-Aufrufe, temporäre Dateiverwaltung, Sicherheitsdurchsetzungen) werden von folgendem Skript ausgeführt:

$REPO_ROOT/.agents/skills/openclaw-secret-scanning-maintainer/scripts/secret-scanning.mjs

Das Skript erzwingt:

• hide_secret=true bei allen Alarmabrufen (keine Klartext-Geheimnisse in stdout)
• mktemp mit zufälligen UUIDs für alle temporären Dateien
• -F body=@file für alle Body-Uploads (keine Inline-Shell-Zitierung)
• Benachrichtigungsvorlagen, die nach Standorttyp verzweigt werden
• Gibt niemals .secret oder .body an stdout aus

Gesamtablauf

Unterstützt einzelne oder mehrere Alarme. Bei mehreren Alarmen in aufsteigender Reihenfolge verarbeiten.

Für jeden Alarm:

1. Identifizieren – fetch-alert + fetch-content, um Metadaten und Inhalt abzurufen
2. Entscheiden – Der Agent liest die Body-Datei, identifiziert, ob Klartext-Geheimnisse verbleiben, und erstellt nur bei Bedarf eine redigierte Version
3. Redigieren – redact-body-if-needed für Issue-/PR-Body; bei Kommentaren überspringen (direkt löschen)
4. Bereinigen – delete-comment + recreate-comment für Kommentare; Body-Verlauf kann nicht bereinigt werden
5. Benachrichtigen – notify postet die richtige Vorlage pro Standorttyp, es sei denn, der aktuelle Issue-/PR-Body ist bereits redigiert
6. Auflösen – resolve schließt den Alarm
7. Zusammenfassung – summary gibt formatierte Ergebnisse aus

Schritt 1: Identifizieren

# Alle offenen Alarme auflisten
node secret-scanning.mjs list-open

# Bestimmte Alarm-Metadaten + Standorte abrufen
node secret-scanning.mjs fetch-alert <NUMMER>

# Inhalt für jeden Standort abrufen (speichert Body in temporärer Datei)
node secret-scanning.mjs fetch-content '<standort-json>'

Die Ausgabe von fetch-content enthält:

• body_file: Pfad zur temporären Datei mit dem vollständigen Inhalt
• author: Wer den Inhalt erstellt hat
• issue_number / pr_number: Wo er sich befindet
• edit_history_count: Anzahl vorhandener Bearbeitungen
• type: Standorttyp für das Routing
• Bei discussion_comment zusätzlich comment_node_id, discussion_node_id und reply_to_node_id, wenn der ursprüngliche Kommentar eine Antwort war.

Standorttyp-Routing

Typ	Ablauf
issue_comment	Kommentar: löschen+neu erstellen
pull_request_comment	Kommentar: löschen+neu erstellen
pull_request_review_comment	Kommentar: löschen+neu erstellen
discussion_comment	Diskussionskommentar: löschen+neu erstellen (GraphQL)
issue_body	Body: direkt redigieren
pull_request_body	Body: direkt redigieren
commit	Nur benachrichtigen
andere	Überspringen und melden

Schritt 2: Entscheiden (Agent)

Der Agent liest die Body-Datei aus der fetch-content-Ausgabe und:

1. Identifiziert ALLE Geheimnisse im Inhalt (es können mehr sein als der Alarm markiert hat)
2. Bestimmt, ob ein Klartext-Geheimnis im aktuellen Body verbleibt
3. Ersetzt jedes verbleibende Geheimnis durch [REDACTED <geheimnis_typ>] – keine Teilwerte, kein Präfix/Suffix
4. Speichert den redigierten Inhalt in einer neuen temporären Datei

Dies ist der einzige Schritt, der semantisches Verständnis erfordert. Alles andere ist mechanisch.

Bei issue_body und pull_request_body: Wenn der aktuelle Body bereits vom Autor redigiert wurde und kein Klartext-Geheimnis mehr vorhanden ist, posten Sie keinen öffentlichen Benachrichtigungskommentar. Dies vermeidet einen neuen öffentlichen Hinweis auf historische sensible Inhalte. Dokumentieren Sie die Redaktion separat und verwenden Sie Schritt 6, um zu entscheiden, ob die Beweise eine Auflösung des Alarms unterstützen.

Schritt 3: Redigieren

Für Kommentare (issue_comment / PR-Kommentare)

Nicht redigieren. Direkt zu Schritt 4 springen (löschen + neu erstellen). Ein PATCH vor einem DELETE erzeugt eine unnötige Bearbeitungsverlaufsrevision.

Für issue_body / pull_request_body

node secret-scanning.mjs redact-body-if-needed <issue|pr> <NUMMER> <aktuelle-body-datei> <redigierte-body-datei> <ergebnis-datei>

Verwenden Sie die body_file von fetch-content als <aktuelle-body-datei>. Der Befehl schreibt notify_required in die <ergebnis-datei> und führt nur dann einen PATCH des Body durch, wenn sich die redigierte Datei vom aktuellen Body unterscheidet.

Schritt 4: Bearbeitungsverlauf bereinigen

Kommentare – Löschen und neu erstellen

Für Issue-/PR-Kommentare:

# Original löschen (gesamter Bearbeitungsverlauf weg)
node secret-scanning.mjs delete-comment <KOMMENTAR_ID>

# Mit redigiertem Inhalt neu erstellen
node secret-scanning.mjs recreate-comment <ISSUE_NUMMER> <body-datei>

Für Diskussionskommentare (verwendet GraphQL):

# Original löschen
node secret-scanning.mjs delete-discussion-comment <KOMMENTAR_NODE_ID>

# Mit redigiertem Inhalt neu erstellen
node secret-scanning.mjs recreate-discussion-comment <DISKUSSION_NODE_ID> <body-datei> [ANTWORT_AUF_NODE_ID]

Die Ausgabe von fetch-content für discussion_comment enthält comment_node_id und discussion_node_id für diese Befehle. Wenn der ursprüngliche Diskussionskommentar eine Antwort war, enthält sie auch reply_to_node_id; übergeben Sie dieses optionale dritte Argument, damit der redigierte Ersatz im ursprünglichen Thread bleibt.

Der neu erstellte Kommentar sollte folgendem Format folgen:

> **Hinweis:** Der ursprüngliche Kommentar von @<AUTOR> wurde aufgrund von Geheimnislecks entfernt. Unten ist die redigierte Version des ursprünglichen Inhalts.

---

<redigierter Originalinhalt>

issue_body / pull_request_body – Bearbeitungsverlauf kann nicht bereinigt werden

Durch Bearbeiten entsteht eine Bearbeitungsverlaufsrevision mit dem Klartext vor der Bearbeitung. Diese kann nicht über die API gelöscht werden.

Weisen Sie Autoren nicht öffentlich an, Issues zu löschen/neu zu erstellen oder PRs zu schließen/erneut zu öffnen. Dies könnte Aufmerksamkeit auf historische Inhalte lenken. Halten Sie die Bereinigungsanleitung nur für Betreuer.

Ausgabe nur für das Betreuer-Terminal (niemals in öffentlichen Kommentaren):

⚠️ Der Bearbeitungsverlauf von Issue/PR-Body enthält noch Klartext-Geheimnisse.
Kontaktieren Sie den GitHub-Support zur Bereinigung: https://support.github.com/contact
Fordern Sie die Bereinigung der userContentEdits von Issue/PR #{NUMMER} an.

KRITISCH: Erwähnen Sie den Bearbeitungsverlauf oder die Schaltfläche „Bearbeitet“ in keinem öffentlichen Kommentar oder Auflösungs-Kommentar.

Commits

Können nicht bereinigt werden. Benachrichtigen Sie den Autor, den Branch zu löschen oder einen Force-Push durchzuführen (bei nicht gemergten PRs).

Schritt 5: Benachrichtigen

node secret-scanning.mjs notify <ZIEL> <AUTOR> <STANDORT_TYP> <GEHEIMNIS_TYPEN> [ANTWORT_AUF_NODE_ID|BODY_REDACTIONS_ERGEBNIS_DATEI]

• Bei Nicht-Diskussionstypen ist <ZIEL> die Issue-/PR-Nummer.
• Bei discussion_comment ist <ZIEL> die discussion_node_id, die von fetch-content zurückgegeben wird.
• Bei discussion_comment-Standorten vom Typ Antwort übergeben Sie die optionale reply_to_node_id von fetch-content, damit die Benachrichtigung im selben Thread bleibt.
• Bei issue_body und pull_request_body übergeben Sie die <ergebnis-datei> von redact-body-if-needed. Das Skript überspringt die Benachrichtigung, wenn notify_required false ist, und lehnt Body-Benachrichtigungen ohne diese Datei ab.

Geheimnistypen sind kommagetrennt: "Discord Bot Token,Feishu App Secret"

Das Skript wählt die richtige Vorlage aus:

• Kommentartypen: „your comment … removed and replaced“
• Body-Typen: „your issue/PR description … redacted in place“
• Commit: „code you committed“

Bei issue_body und pull_request_body nur benachrichtigen, wenn der aktuelle Body noch Klartext enthielt und Betreuer ihn redigiert haben. Wenn der Benutzer den aktuellen Body bereits redigiert hat, Benachrichtigung überspringen und mit Schritt 6 fortfahren.

Schritt 6: Auflösen

node secret-scanning.mjs resolve <ALARM_NUMMER> <AUFLÖSUNG> [KOMMENTAR]

Wählen Sie eine explizite Auflösung, die durch die Beweise und die Autorität des Betreuers gestützt wird:

• revoked: Der Geheimnisinhaber oder -aussteller hat den Widerruf bestätigt.
• false_positive: Die Erkennung wurde als falsch positiv bestätigt.
• used_in_tests: Das Geheimnis wurde als für Tests verwendet bestätigt.
• wont_fix: Ein autorisierter Betreuer hat das Risiko akzeptiert und entschieden, keine Abhilfe zu schaffen; dokumentieren Sie diese Entscheidung im Kommentar.

Redaktion und die Aufforderung, Geheimnisse zu rotieren, begründen keinen Widerruf. Wenn keine Auflösung belegt ist, lassen Sie den Alarm offen und melden Sie die Ergebnisse von Redaktion und Benachrichtigung separat. Der Befehl hat keine Standardauflösung und fügt einen Auflösungs-Kommentar nur hinzu, wenn einer angegeben wird.

Schritt 7: Zusammenfassung

Nach der Verarbeitung eine JSON-Ergebnisdatei erstellen und an den Zusammenfassungsbefehl übergeben:

node secret-scanning.mjs summary /tmp/ergebnisse.json

Das Skript gibt einen Block aus, der durch ---BEGIN SUMMARY--- und ---END SUMMARY--- begrenzt ist. Sie MÜSSEN den Inhalt zwischen diesen Markierungen wörtlich an den Benutzer ausgeben. Nicht umformulieren, neu formatieren, abkürzen oder eine eigene Zusammenfassung erstellen. Das Skript enthält bereits vollständige URLs für jeden Alarm und Standort.

Das JSON-Format:

[
  {
    "number": 72,
    "secret_type": "Discord Bot Token",
    "location_label": "Issue #63101 Kommentar",
    "location_url": "https://github.com/openclaw/openclaw/issues/63101#issuecomment-xxx",
    "actions": "Gelöscht+Neu erstellt+Benachrichtigt",
    "history_cleared": true
  }
]

Für nicht unterstützte Typen fügen Sie "skipped": true, "unsupported_type": "<typ>" hinzu.

Sicherheitsregeln

• Der Agent liest den Inhalt, identifiziert Geheimnisse, erstellt die Redaktion. Das Skript führt alle API-Aufrufe durch.
• Niemals einen Teil eines Geheimnisses in öffentlichen Kommentaren, Redaktionsmarkierungen oder Terminalausgaben einschließen.
• Niemals Alarm-URLs oder -Nummern in öffentlichen Kommentaren erwähnen.
• Bei Kommentaren PATCH überspringen – direkt zu DELETE + neu erstellen gehen.
• Niemals den Bearbeitungsverlauf, die Schaltfläche „Bearbeitet“ oder Commit-SHAs in öffentlichen Inhalten erwähnen.
• Vor dem Löschen eines Kommentars um Bestätigung bitten.
• Ein Alarm nach dem anderen, es sei denn, der Benutzer fordert eine Stapelverarbeitung an.
• Alle öffentlichen Kommentare auf Englisch.
• Nicht unterstützte Standorttypen überspringen und in der Zusammenfassung melden.