GhostAction: Ein gelöschter Schlüssel bleibt ein Risiko

Die Datei ist sauber. Was sagt der Aussteller des Schlüssels?

Sie haben das Secret gelöscht. Haben Sie auch den Zugang widerrufen? GhostAction macht diese Frage dringlich: Ein kompromittiertes Maintainer-Konto kann einen Workflow einbringen, der alte Commits ebenso durchsucht wie aktuelle Dateien. Ein sauberes Arbeitsverzeichnis zeigt nicht, ob der gefundene Schlüssel noch funktioniert. Darüber entscheidet der Dienst, der ihn ausgestellt hat.

Die Kampagne vom Oktober 2026 ist der Ausgangspunkt. Das nützliche Ergebnis ist ein Verfahren, um den Vorfall mit Belegen abzuschließen. Ich trenne drei Fragen: Wo liegen noch Secrets, akzeptiert der Aussteller sie weiterhin, und kann der Angreifer einen weiteren Workflow einschleusen? Diese Analyse beruht auf öffentlichen Untersuchungen und GitHub-Dokumentation; der Kampagnen-Payload wurde hier nicht ausgeführt. [1][2]

Der Git-Verlauf wird zur Eingabe des kompromittierten Runners

StepSecurity beschreibt eine schädliche security-audit.yml, die direkt unter einer kompromittierten Maintainer-Identität eingecheckt wurde. Der Checkout fordert die vollständige Historie an; anschließend untersucht das Skript Patches mit git log -p --all. Es versucht außerdem, Werte konfigurierter Actions-Secrets abzugreifen, indem es zuvor in Workflows gefundene Namen einsetzt. Die Namen bestimmen die Abfrage; die Werte sind das Ziel. [1]

Betrachten Sie den beispielhaften Verlauf unten. Commit B entfernt das Token aus der aktuellen Datei, während Commit A es weiterhin enthält. Eine Suche über die Historie kann den alten Text deshalb wiederfinden. Die Sammlung bleibt durch abgerufene Referenzen, Suchmuster und Ausgabelimits des Payloads begrenzt. Aus dieser Fähigkeit folgt nicht, dass jedes historische Secret erfolgreich entwendet wurde.

Illustrative repository history; no real credential

A: config.env contains API_TOKEN=DEMO_NOT_A_REAL_TOKEN
B: config.env no longer contains API_TOKEN

Current file: absent
Earlier commit: present
Issuer status: a separate question

Kann sich ein wiedergefundenes Secret noch authentifizieren?

Auffindbarkeit und Gültigkeit sind voneinander unabhängig. Ein altes Token kann nach seinem Widerruf sichtbar bleiben, ohne weiterhin Zugang zu gewähren. Es kann auch aus Ihrem Repository verschwinden und aus einer fremden Kopie heraus noch funktionieren. GitHub empfiehlt, offengelegte Zugangsdaten zuerst zu widerrufen oder zu rotieren. Das Umschreiben der Historie behandelt verbleibende Kopien und erfordert Abstimmung für Klone, Forks und Referenzen. [2]

Diese Trennung verändert meinen Blick auf Bereinigungsstatistiken. Die Zahl der Repositories mit altem Secret-Text misst öffentliche Rückstände, nicht die Zahl weiterhin akzeptierter Schlüssel. Auch der Abnahmetest ändert sich: Eine CI-Variable zu ersetzen genügt erst, wenn die vorherigen Zugangsdaten beim Aussteller deaktiviert sind. Dokumentieren Sie das getrennt vom erfolgreichen Build mit dem Ersatz.

                              Old credential accepted?
                              Yes                 No
Secret text recoverable       Access remains       Residual disclosure
Secret text no longer found   Access may remain    Both checks needed

A repository scan cannot answer the issuer-status column.

Welche Kontrolle stoppt tatsächlich den nächsten Workflow?

Review-Anforderungen helfen dort, wo sie durchgesetzt werden. GitHubs Freigabe für Workflows aus öffentlichen Forks gilt für diesen Beitragsweg. Sie ist keine allgemeine Freigabeschranke für direkte Pushes eines Maintainers. StepSecurity berichtet über eine Freigabeschranke, die bestimmte beobachtete Läufe stoppte. Daraus folgt jedoch nicht, dass die Fork-Einstellung jedes Repository gegen diese Kampagne schützt. [1][3]

Verlangen Sie für geschützte Branches Pull Requests und das passende Code-Owner-Review. Prüfen Sie anschließend, wer die Regel umgehen darf. Ein CODEOWNERS-Eintrag für .github/workflows/ definiert Zuständigkeit; die Branch-Regel macht das Review verpflichtend. Schützen Sie auch CODEOWNERS selbst und untersuchen Sie weitere Branches, deren Push-Workflows Secrets erhalten. Allein main zu schützen beschreibt nicht jeden ausführbaren Workflow-Pfad. [4][5]

Ein lesendes Repository-Token schließt Secret-Diebstahl nicht aus

Die Rechte von GITHUB_TOKEN zu reduzieren ist sinnvoll. Dadurch wird aber kein Cloud-Schlüssel widerrufen, der dem Job separat übergeben wird. Der beobachtete Workflow konnte mit Leserechten auf Repository-Inhalte arbeiten und gleichzeitig andere Zugangsdaten sammeln. Eine Rechteprüfung muss deshalb das eingebaute Token und jedes zusätzliche Secret erfassen, das während der Ausführung verfügbar ist. [1]

Meine Prüfung verfolgt eine konkrete Kette: Wer ändert den Workflow, welches Ereignis startet ihn, welche Identität und Secrets erhält der Job, und welche Ziele kann er kontaktieren? Bei einem Veröffentlichungsjob lautet die Frage, ob ein Workflow-Autor ihn in einen Leser von Zugangsdaten verwandeln kann. Schreibrechte im Repository zu begrenzen beantwortet nur einen Teil davon. Das ist eine Architekturfrage, keine Behauptung, jeder Runner habe sämtliche Secrets offengelegt.

Begrenzen Sie den Zugang vor der Bereinigung der Historie

Sichern Sie Workflow-Revision, Laufkennungen und relevante Audit-Daten, bevor die Bereinigung den Kontext entfernt. Stoppen Sie den schädlichen Ausführungspfad und widerrufen Sie die kompromittierten Maintainer-Zugangsdaten. Erfassen Sie danach aktuelle Job-Secrets und historische Schlüssel im betroffenen Umfang, ordnen Sie Verantwortliche zu und belegen Sie den Widerruf beim Aussteller. Ein unbekannter Gültigkeitsstatus bleibt offen; er rechtfertigt keine Entwarnung. [1][2]

Ein Ersatzschlüssel muss über einen vertrauenswürdigen Ausführungspfad verteilt werden. Andernfalls liest derselbe kompromittierte Workflow ihn beim nächsten Lauf aus. Die historische Bereinigung benötigt eigene Abstimmung und kann Kopien beim Angreifer nicht zurückholen. Konnten Schlüssel Sitzungen oder weitere Zugangsdaten erzeugen, prüfen Sie auch diese Zugänge. Das Deaktivieren des ursprünglichen Secrets beweist nicht, dass kein eigenständiger Zugang angelegt wurde.

Verlangen Sie einen Abschlussnachweis statt eines sauberen Screenshots

Ein Abschlussnachweis muss einem anderen Entwickler erlauben, erledigte Arbeit von Annahmen zu unterscheiden. Erfassen Sie für alle offengelegten Zugangsdaten die nicht geheime Kennung, Verantwortliche, Aussteller, Expositionszeitraum, Widerrufsnachweis und Status des Ersatzes. Dokumentieren Sie die Eindämmung der einschleusenden Identität und die Einschränkung des Workflow-Pfads. Das folgende Blatt ist ein vorgeschlagenes Prüfartefakt, kein Protokoll dieses Vorfalls.

Für Auftraggeber wird die Frage damit konkret: Kann Ihr Team zeigen, dass zuvor offengelegter Zugang nicht mehr akzeptiert wird und der Ersatz nicht über denselben Weg abfließen kann? Diese Belege würde ich bei einer Remediation-Verifikation verlangen. Sie unterscheiden das Schließen eines Tickets vom Schließen des Zugangs, den das Ticket beseitigen sollte.

Credential ID / owner / issuer: ____________________
Exposure scope and evidence: _______________________
Old credential disabled at issuer: _________________
Replacement deployed through trusted workflow: _____
Compromised maintainer access contained: ____________
Other credentials or sessions investigated: _________
Remaining copies / uncertainty / responsible owner: _