Sicherheitsvorfallbericht: xygeni-action GitHub Action Compromise

Executive Summary

Am 3. März 2026 stellte Xygeni verdächtige Aktivitäten im Repository fest, das für die Veröffentlichung der GitHub-Aktion xygeni/xygeni-action verwendet wurde. Die Aktivitäten gingen von kompromittierten Anmeldeinformationen aus, die mit einem Maintainer-Token und einer im Repository installierten GitHub-App verknüpft waren.

Während des Vorfalls versuchte ein Angreifer, über eine Reihe von Schritten bösartigen Code in das Repository einzuschleusen. pull requestsDiese Versuche wurden durch bestehende Branch-Schutzregeln blockiert, wodurch verhindert wurde, dass der Code in den Hauptzweig des Repositorys zusammengeführt wurde.

Der Angreifer nutzte jedoch anschließend einen anderen Sicherheitsvektor aus, indem er das veränderliche v5-Tag so veränderte, dass es auf ein bösartiges Element verwies. commit erstellt während der pull request Versuche. Workflows, die auf xygeni/xygeni-action@v5 verweisen, könnten daher den kompromittierten Code abrufen, ohne dass sichtbare Änderungen an ihren Workflow-Definitionen vorgenommen werden.

Die Manipulation des Tags wurde am 9. März nach Meldungen aus der Bevölkerung festgestellt. Der manipulierte Tag wurde umgehend entfernt und die entsprechenden Maßnahmen zur Reaktion auf den Vorfall eingeleitet.

Unsere Untersuchung ergab Folgendes:

• Es wurde kein bösartiger Code in den Hauptzweig des Repositorys übernommen.
• Es gibt Es gibt keine Hinweise auf eine Kompromittierung der Xygeni SaaS-Plattform. oder Kundendaten.
• Das Belichtungsfenster war auf Workflows beschränkt, die xygeni/xygeni-action@v5 referenzierten. 3. März und 9. März 2026.
• Das kompromittierte Tag wurde dauerhaft entfernt und wird nicht wiederhergestellt.

Nach der Entdeckung der Tag-Manipulation hat Xygeni zahlreiche Sicherheitsverbesserungen in seinen Repositories und Release-Prozessen implementiert, darunter:

• Entfernung des kompromittierten Tags und Migrationshinweise zu SHA-gepinnte Referenzen.
• Vollstreckung von Unveränderlichkeit freigeben über Repositorien hinweg.
• Verschärfung der Repository-Berechtigungen und des Zugriffs für Mitwirkende.
• Verpflichtend kryptografisch signiert commits für Instandhalter.
• Beschränkung des Schreibzugriffs auf einen begrenzten Kreis von Wartungs- und Verwaltungsmitarbeitern.

Wir veröffentlichen diesen Bericht, um Transparenz hinsichtlich des Vorfalls zu schaffen, die gewonnenen Erkenntnisse weiterzugeben und die Sicherheitspraktiken im gesamten GitHub Actions-Ökosystem zu stärken.

Der Angriff nutzte zwar eine bekannte Schwachstelle in GitHub Actions im Zusammenhang mit veränderlichen Tags aus, doch der Vorfall unterstreicht auch die Bedeutung eines umfassenden Repository-Schutzes, eines strikten Zugangsdatenmanagements und einer mehrschichtigen Verteidigung. CI/CD Systemen.

Transparenz und Zusammenarbeit sind unerlässlich, um die Widerstandsfähigkeit der Software-Lieferkette zu verbessern.

Vorfallübersicht

Dieser Bericht dokumentiert die Untersuchung eines Sicherheitsvorfalls, der die Öffentlichkeit betraf. xygeni/xygeni-action GitHub Action-Repository.

Am 3. März 2026 nutzte ein Angreifer kompromittierte Zugangsdaten im Zusammenhang mit der Repository-Automatisierung, um über eine Reihe von Schritten bösartigen Code einzuschleusen. pull request Versuche. Die Nutzlast enthielt ein als Telemetrie der Scannerversion getarntes Kommando- und Kontrollimplantat.

Die Regeln zum Schutz der Repository-Zweige haben erfolgreich verhindert, dass der schädliche Code in den Hauptzweig übernommen wurde. HauptzweigDer Angreifer manipulierte jedoch später die veränderliche Datei. v5 Etikett, indem es umgeleitet wird zu einem commit die die eingefügte Nutzlast enthält. Da viele Workflows GitHub Actions mithilfe von Hauptversions-Tags referenzieren, ist dies Tag-Vergiftung erlaubte nachgelagerte Arbeitsabläufe, die darauf Bezug nehmen xygeni/xygeni-action@v5 um den kompromittierten Code abzurufen, ohne dass eine sichtbare Änderung an ihrer Workflow-Konfiguration vorgenommen wird.

Als Anbieter von software supply chain security Xygeni betreibt eine Infrastruktur, die sich direkt in die Entwicklung integriert. pipelines und CI/CD Umgebungen. Projekte in diesem Bereich sind häufige Ziele von Angriffen, die darauf abzielen, weit verbreitete Entwicklerwerkzeuge zu kompromittieren, um Zugriff auf nachgelagerte Umgebungen zu erhalten.

Geschichte

Phase 1: Der Böswillige Pull Requests (3. März, 10:22–10:50 UTC)

Am 3. März 2026 um 10:22 UTC begann ein Angreifer einen schnellen, koordinierten Angriff auf das xygeni-action-Repository. Er nutzte dafür zwei kompromittierte Identitäten: das persönliche Zugriffstoken (PAT) eines Maintainers und den privaten Schlüssel einer GitHub-App (xygeni-onboarding-app-dev). Innerhalb der nächsten 28 Minuten wurden drei Angriffe gestartet. pull requests wurden erstellt und geschlossen, wobei jeweils verschleierter Shell-Code in die action.yml-Datei eingefügt wurde.

Die Vorgehensweise des Angreifers war methodisch und anpassungsfähig:

• PR # 46 (10:22–10:29 UTC): Erstellt vom kompromittierten Maintainer PAT unter dem Branch feat/scanner-telemetryDer Angreifer versuchte, die Änderungen zusammenzuführen, wurde jedoch durch die Branch-Schutzregeln daran gehindert. Der Pull Request wurde ohne Zusammenführung geschlossen.
• Aufklärung (10:39–10:40 UTC): Der Angreifer testete den Zugriff der GitHub-App, indem er einen Branch namens „“ erstellte und ihn sofort wieder löschte. test-app-accessDies bestätigte, dass die App Schreibzugriff auf das Repository hatte.
• PR # 47 (10:41–10:44 UTC): Ein zweiter Versuch mit dem Maintainer-PAT, jetzt unter einem umbenannten Branch Verbesserung/Scanner-TelemetrieErneut durch den Branch-Schutz blockiert. Der Angreifer versuchte, die Pull Requests mithilfe der GitHub-App zu genehmigen und dabei die Zwei-Prüfer-Regel zu umgehen, indem er eine kompromittierte Identität die Arbeit der anderen genehmigen ließ. Auch dieser Versuch scheiterte.
• PR # 48 (10:45–10:49 UTC): Die Rollen wurden getauscht – die GitHub-App hat den Pull Request erstellt (Pushing). commit 4bf1d4e), und der Wartungsbeauftragte PAT reichte die Genehmigungsprüfung ein. Auch diese wurde von der Abteilung für Zweigschutz abgelehnt.

Keiner der Pull Requests erreichte den Hauptzweig. Unsere Regeln zum Schutz des Zweigs griffen: die Anforderung zweier Genehmigungen, die Regel, dass der letzte Push von einer anderen Person als dem Pusher genehmigt werden muss, und die Beschränkung, diese Einstellungen zu umgehen – all dies zusammen verhinderte jeden Merge-Versuch.

Unser Team entdeckte die ungewöhnliche Aktivität während einer routinemäßigen PR-Prüfung und leitete um 12:21 UTC – weniger als zwei Stunden nach dem ersten schädlichen PR – eine Reaktion ein. Diese umfasste die Entfernung von Workflows, die Sicherung des schädlichen Codes für forensische Analysen und die Absicherung des Repositorys.

Phase 2: Die Tag-Vergiftung

Der Branch-Schutz verhinderte zwar erfolgreich, dass der Schadcode den Hauptzweig erreichte, doch der Angreifer nutzte einen anderen Angriffsvektor. Mithilfe der kompromittierten GitHub-App-Zugangsdaten verschob er das veränderliche v5-Tag auf einen bestimmten Pfad. commit 4bf1d4e — der bösartige commit aus PR #48, der auch nach dem Löschen des PR-Branches noch im Objektspeicher des Repositorys existierte.

Entscheidend ist, dass diese Tag-Manipulation nicht unmittelbar nach den Pull Requests stattfand. Die Repository-Aktivitätsprotokolle von GitHub erfassen Tag-Force-Push-Ereignisse nicht wie Branch-Operationen, was die Rekonstruktion des genauen Zeitpunkts der Tag-Änderung erschwert. Die Manipulation des Tags wurde jedoch bestätigt, nachdem die Community am 9. März Alarm geschlagen hatte.

Das ist die entscheidende Erkenntnis: Zweigschutzregeln schützen keine Tags. commit Die Hintertür befand sich in der Git-Objektdatenbank des Repositorys, und das v5-Tag – auf das nachgelagerte Workflows verwiesen – konnte unbemerkt darauf umgeleitet werden. Jeder Workflow, der xygeni/xygeni-action@v5 verwendete, zog den kompromittierten Code, ohne dass im Hauptzweig oder in den Workflow-Dateien der konsumierenden Repositories Änderungen sichtbar waren.

Ursache

Unsere Untersuchung ergab, dass die Ursache in der Kompromittierung des privaten Schlüssels einer GitHub-App (xygeni-onboarding-app-dev) lag, die im Repository installiert worden war.

Diese GitHub-App wurde ursprünglich zum Testen des Onboarding-Prozesses auf der Xygeni-Plattform entwickelt. Sie verfügte über Schreibrechte für das Repository – Berechtigungen, die im Nachhinein betrachtet für ihren eigentlichen Zweck über das notwendige Maß hinausgingen.

Mit dem privaten Schlüssel einer GitHub-App kann ein Angreifer:

• Generieren Sie nach Belieben kurzlebige Installationstoken.
• Erstellen und genehmigen pull requests
• Push commits via Git über HTTPS
• Tags verschieben – die entscheidende Maßnahme, die diesem Vorfall so große Bedeutung verlieh

Der Angreifer nutzte sowohl das kompromittierte Maintainer-PAT als auch die Anmeldeinformationen der GitHub-App in einem koordinierten Versuch: Wenn eine Identität allein die Schutzmechanismen nicht umgehen konnte, wurden die beiden Identitäten parallel verwendet – eine zum Erstellen, die andere zum Genehmigen.

Die genauen Umstände, über die der private Schlüssel abgegriffen wurde, werden noch untersucht. Private Schlüssel von GitHub-Apps (PEM-Dateien) können durch fehlerhaft konfigurierte Arbeitsabläufe, kompromittierte Entwicklerrechner oder unsichere Speicherung geheimer Informationen in falsche Hände geraten.

Verhalten bösartiger Nutzdaten

Der eingeschleuste Code war ein kompaktes Kommando- und Kontrollimplantat. Er war so konzipiert, dass er unbemerkt neben dem legitimen Scanner lief und in drei Phasen ausgeführt wurde:

• Registrierung. Das Implantat kontaktiert einen C2-Server unter 91.214.78.178 (getarnt durch nip.io Wildcard-DNS als security-verify.91.214.78.178.nip.io) und sendet dabei den Hostnamen, den Benutzernamen und die Betriebssystemversion des Runners.
• Abfrageschleife. Für 180 Sekunden (was innerhalb typischer CI-Job-Timeouts liegt) fragt das Implantat alle 2–7 Sekunden den C2-Server nach auszuführenden Befehlen ab.
• Befehlsausführung. Alle empfangenen Befehle werden über eval ausgeführt, die Ausgabe komprimiert (zlib), base64-kodiert und zurück an den C2-Server exfiltriert.

Die Variablennamen wurden bewusst kurz gehalten und das Abfrageintervall wurde zufällig gewählt, um die Erkennung von Datenverkehrsmustern zu vermeiden.

Wenn das Implantat auf einem CI-Runner ausgeführt wurde, hätte der Angreifer Zugriff auf GITHUB_TOKEN, Repository-Geheimnisse, Quellcode und möglicherweise auch auf Signaturschlüssel für Artefakte gehabt. Das Implantat hätte die Ausführung von Befehlen auf einem CI-Runner ermöglicht, wenn es innerhalb eines Workflows ausgeführt worden wäre, der auf das kompromittierte Tag verwies.

Zu diesem Zeitpunkt haben wir Es gibt keine Hinweise darauf, dass die Nutzlast in einer CI-Umgebung eines Kunden ausgeführt wurde. oder dass Geheimnisse durch die Aktion nach außen gelangten.

C2-Infrastruktur

Der C2-Server wurde von Partner Hosting LTD (AS215826) mit Sitz in 71-75 Shelton Street, Covent Garden, London, gehostet – einer häufig genutzten Adresse für virtuelle Büros. Die Infrastruktur war erst kürzlich eingerichtet worden (das Subnetz wurde zuletzt fünf Tage vor dem Angriff geändert), und die IP-Adresse war in Bedrohungsdaten bereits mit RATs, Infostealern und Loadern verknüpft. Die Infrastruktur und die verwendeten Tools deuten auf einen fähigen Angreifer hin, der mit der Materie vertraut ist. CI/CD Umgebungen.

Expositionsbewertung

Wichtige Beobachtungen

Veränderliche Tags stellen ein bekanntes Risiko dar – aber die Trägheit ist mächtig

Das GitHub Actions-Ökosystem hat ein bekanntes Problem: veränderliche Tags. Wenn Nutzer auf action@v5 verweisen, gehen sie davon aus, dass der Tag auf sicheren Code verweist. Tags können jedoch von jedem mit Schreibzugriff manipuliert werden. Dies ist der häufigste Angriffsvektor in der Lieferkette von GitHub Actions, und wir wussten das – trotzdem verwiesen unsere Dokumentationen weiterhin auf @v5.

Astschutz ist kein Etikettenschutz

Unsere Branch-Schutzregeln funktionierten exakt wie geplant. Sie verhinderten, dass der Schadcode in den Hauptzweig übernommen wurde. Der Angreifer musste aber nicht einmal mergen – er brauchte lediglich einen commit im Repository (das jeder PR-Branch bereitstellt) und die Möglichkeit, ein Tag zu verschieben. Der Branch-Schutz vermittelte uns ein trügerisches Gefühl umfassender Sicherheit.

Neue Funktionen bieten keinen rückwirkenden Schutz.

GitHub hat eingeführt Unveränderlichkeit freigeben Im Oktober 2025 wird eine Funktion eingeführt, die verhindert, dass mit Veröffentlichungen verknüpfte Tags geändert werden. Wir hatten dies zwar im Blick, aber die Tragweite noch nicht vollständig erfasst:

• Es schützt nur Tags, die mit GitHub Releases verknüpft sind, nicht aber eigenständige Tags.
• Der Schutz gilt nicht rückwirkend – bestehende Releases, die vor der Aktivierung dieser Funktion erstellt wurden, bleiben veränderbar.
• Die Regeln zum Schutz von Tags (eine separate Funktion) müssen unabhängig konfiguriert werden.

Hätten wir die Unveränderlichkeit von Releases aktiviert und sichergestellt, dass das v5-Tag mit einem geschützten Release verknüpft ist, wäre die Tag-Vergiftung fehlgeschlagen.

Zu permissive GitHub-App-Bereiche

Die GitHub-App verfügte über Schreibrechte, die ihren betrieblichen Bedarf überstiegen. In komplexen Organisationen mit zahlreichen Apps, Bots und Integrationen kann es leicht passieren, dass sich Berechtigungen über das erforderliche Maß hinaus anhäufen. Jede zusätzliche Berechtigung stellt eine zusätzliche Angriffsfläche dar.

Berichtigungen des öffentlichen Protokolls

Der Bericht der Forscher war maßgeblich daran beteiligt, die Öffentlichkeit zu alarmieren, und wir schätzen ihre schnelle Reaktion. Unsere interne Untersuchung ergab jedoch einige Details, die von ihrer Darstellung abweichen:

• Zeitlicher Ablauf der Tag-VergiftungDer Bericht des Forschers datiert die Verschiebung des v5-Tags auf etwa 10:49 UTC am 3. März, unmittelbar nach dem Schließen der Pull Requests. Unsere Untersuchung konnte diesen Zeitpunkt nicht bestätigen – Tag-Force-Push-Ereignisse werden nicht im Aktivitätsprotokoll des GitHub-Repositorys aufgezeichnet. Wir wissen jedoch, dass der Tag zu einem späteren Zeitpunkt manipuliert wurde, nachdem die schädliche Aktion stattgefunden hatte. commit wurde erstellt, bevor die Community es am 9. März entdeckte.
• Das commit wurde nicht „mit der E-Mail-Adresse eines Wartungsmitarbeiters signiert“. Der Bericht des Forschers beschreibt den ersten bösartigen Vorfall. commit als „mit der E-Mail-Adresse eines Maintainers signiert“ bezeichnet, vermischt dies jedoch Git-Autorenmetadaten mit kryptografischer Signatur – das sind grundverschiedene Dinge. commit war nicht kryptografisch signiert. Der Angreifer hat einfach das Git-Autorenfeld auf die E-Mail-Adresse eines anderen Maintainers gesetzt – etwas, das jeder tun kann, da Git-Autorenmetadaten selbst gemeldet und nicht authentifiziert werden. commit wurde unter Verwendung des kompromittierten PAT des Maintainers durchgesetzt; der Maintainer, dessen E-Mail-Adresse verwendet wurde, wurde nicht kompromittiert und erscheint erst ab 12:21 UTC im Repository-Aktivitätsprotokoll als Teil des Incident-Response-Teams.
• Die beteiligten IdentitätenDer Forscher beschrieb die Identität des Maintainers und den GitHub-App-Bot als Beweis für „gestohlene Zugangsdaten und nicht für Insider-Aktivitäten“. Wir können bestätigen, dass der klassische PAT eines Maintainers und der private Schlüssel der GitHub-App kompromittiert wurden. Beide wurden vom selben externen Angreifer verwendet. PR #48 erscheint unter dem Phantombenutzer, da er durch die Installation der GitHub-App erstellt wurde – nicht durch ein gelöschtes Benutzerkonto.
• Die Anzahl der betroffenen RepositoriesDer Bericht des Forschers erwähnte über 137 Repositories, die @v5 verwenden. Unsere Überprüfung der GitHub-Code-Suchergebnisse konnte diese Zahl nicht bestätigen. Zum Zeitpunkt unserer letzten Analyse fanden wir keine öffentlichen Repositories, die xygeni/xygeni-action@v5 aktiv in ausführbaren Workflows einsetzen. Die identifizierten Verweise bezogen sich auf Dokumentationsbeispiele in Xygeni-Repositories, die inzwischen aktualisiert wurden. In der Praxis nutzen die meisten Kunden den CLI-basierten Scanner-Download und die Funktion „Managed Scan“ von Xygeni. Diese ruft die Aktion intern auf und verwendet eine SHA-gefixte, intern validierte Version, die nicht durch Tag-Manipulationen beeinflusst wird. Da die GitHub-Code-Suche nur öffentliche Repositories indexiert, können wir nicht mit absoluter Sicherheit feststellen, ob private Repositories den Tag möglicherweise referenziert haben. Basierend auf den verfügbaren Informationen scheint die tatsächliche Gefährdung in nachgelagerten Systemen deutlich geringer zu sein als ursprünglich berichtet.

[Wir werden diesen Abschnitt aktualisieren, sobald unsere Untersuchung abgeschlossen ist.]

Reaktionsaktionen

Sofortreaktion (3. März)

• Bösartige Pull Requests wurden markiert und blockiert (der Branch-Schutz verhinderte das Zusammenführen).
• Der Schadcode wurde extrahiert und für die forensische Analyse gesichert.
• C2-Domäne und IP-Adresse wurden als Indikatoren für eine Kompromittierung erfasst
• Die kompromittierte GitHub-App (xygeni-onboarding-app-dev) wurde aus dem Repository entfernt.
• Alle PATs der beteiligten Personen wurden rotiert.
• Die Audit-Logs des Repositorys wurden überprüft – es gab keine Hinweise auf zuvor unautorisierte Zusammenführungen.

Anleitung zur Sanierung

Sanierungsmaßnahmen (9.–10. März)

• Das kompromittierte v5-Tag wurde entfernt.
• Unveränderlichkeit freigeben wurde für das Repository aktiviert und global für alle Xygeni-eigenen Repositories durchgesetzt.
• Die Regeln zum Schutz der Zweigstellen wurden verschärft, einschließlich der obligatorischen Unterschrift. commits (Xygeni verwendet hardwaregestützte commit Unterzeichnung)
• Das v5-Tag wurde absichtlich nicht neu erstellt, um deutlich zu machen, dass es kompromittiert worden war und um die Migration zu SHA-gesicherten Referenzen zu fördern.
• Die Dokumentation wurde aktualisiert und enthält nun den vollständigen Verweis. commit SHA (13c6ed2797df7d85749864e2cbcf09c893f43b23) entsprechend v6.4.0
• GitHub Actions wurden im Repository vorsorglich vorübergehend deaktiviert.
• Die Schreibberechtigungen waren eingeschränkt – nur zwei designierte Maintainer und zwei Repository-Administratoren behalten den Schreibzugriff.

Für Benutzer von xygeni-action

Wenn Sie xygeni/xygeni-action@v5 verwendet haben, sollten Sie Folgendes tun:

• Sofort aktualisieren Ihren Workflow zum Anheften an den Safe commit SHA:

uses: xygeni/xygeni-action@13c6ed2797df7d85749864e2cbcf09c893f43b23

• Überprüfen Sie Ihre CI-Protokolle für alle ausgehenden Verbindungen zu 91.214.78.178 oder security-verify.91.214.78.178.nip.io im Zeitraum zwischen dem 3. März und dem 9. März 2026.
• Drehen Sie alle Geheimnisse die während dieses Zeitraums CI-Läufern ausgesetzt waren.
• Alternativ können Sie auch ein/eine verwenden Direkter Scanner-Download und Verifizierung

Warum wir dies am 3. März nicht öffentlich bekannt gegeben haben

Dies ist eine Frage, auf die wir eine ehrliche Antwort schulden.

Am 3. März, als unser Team auf die schädlichen Pull Requests reagierte, wurde festgestellt, dass der Angriff auf der Ebene der Pull Requests vollständig eingedämmt worden war. Die Regeln zum Schutz der Branches hatten funktioniert. Es war kein schädlicher Code in den Hauptzweig (main) übernommen worden. Kein CI-Runner hatte die Payload ausgeführt. Der kompromittierte PAT wurde rotiert, die GitHub-App entfernt und die Audit-Logs des Repositorys zeigten keine Hinweise auf zuvor unautorisierte Merges. Der Vorfall wurde als mittelschwer (P2) eingestuft – ein abgewehrter Eindringversuch.

Aufgrund dieser Einschätzung wurde eine öffentliche Bekanntgabe als nicht notwendig erachtet. Im Nachhinein betrachtet war diese Einschätzung unvollständig.

Was wir übersehen hatten, war die Tag-Vergiftung. Der v5-Tag war unbemerkt so verschoben worden, dass er auf den bösartigen Server verwies. commitDies war jedoch in den von uns überprüften Audit-Oberflächen nicht sichtbar. Die Repository-Aktivitätsprotokolle von GitHub stellen Tag-Änderungen anders dar als Branch-Operationen, wodurch die Modifikation während der ersten Untersuchung weniger erkennbar war. Unsere Reaktion auf den Vorfall konzentrierte sich auf den sichtbaren Angriffsvektor – den pull requests und die Hauptfiliale – und überprüfte nicht, ob die Etiketten manipuliert worden waren.

Im Nachhinein betrachtet ist dies eine der wichtigsten Lehren aus diesem Vorfall: Man kann nichts preisgeben, worüber man nicht Bescheid weiß. Unsere Reaktion am 3. März war schnell und effektiv gegen die erkennbare Bedrohung. Der Angreifer hatte jedoch einen zweiten, schwerer zu entdeckenden Angriffsweg, der sechs Tage lang unentdeckt blieb – bis die Community ihn aufdeckte.

Öffentliche Bekanntgabe (9. März)

Am 9. März 2026 eröffneten Mitglieder der Community das Thema. #54Sie hinterfragten den Schadcode und das kompromittierte v5-Tag. Die Forscher veröffentlichten eine detaillierte Analyse, die dazu beitrug, das Bewusstsein im gesamten Ökosystem zu schärfen.

Wir möchten die Rolle des Forschers bei der Verbreitung der Warnung und der Bereitstellung praktischer Hinweise für betroffene Nutzer würdigen. Wir möchten außerdem einige Details seines Berichts klarstellen, zu denen unsere interne Untersuchung abweichende Ergebnisse lieferte – diese Punkte werden im Abschnitt „Korrekturen“ behandelt.

Lehren für das Ökosystem

• Aktionen werden anhand der SHA-Werte, nicht anhand der Tags, fixiert.Veränderliche Tags stellen die größte Angriffsfläche im GitHub Actions-Ökosystem dar. Aktion@ in allen Produktionsabläufen.
• Die Grenzen jeder Sicherheitsfunktion verstehenBranch-Schutz schützt Branches. Tag-Schutz schützt Tags. Release-Unveränderlichkeit schützt Releases. Sie sind nicht austauschbar, und genau in den Lücken zwischen ihnen agieren Angreifer.
• GitHub-App-Berechtigungen unerbittlich prüfenJede installierte App mit Schreibzugriff stellt ein potenzielles Einfallstor für laterale Angriffe dar. Wenden Sie das Prinzip der minimalen Berechtigungen an, wechseln Sie die Zugriffsrechte regelmäßig und überprüfen Sie regelmäßig, welche Apps in kritischen Repositories installiert sind.
• Behandeln Sie CI-Runner als feindliche UmgebungenNetzwerk-Ausgangsüberwachung, kurzlebige Runner und Geheimnisisolierung sind für Repositories in der Software-Lieferkette nicht optional.
• Neue Sicherheitsfunktionen erfordern eine proaktive EinführungDie Unveränderlichkeit von GitHub-Releases war bereits Monate vor diesem Vorfall verfügbar. Nicht aktivierte Funktionen bieten keinen Schutz – Sicherheit ist keine Selbstverständlichkeit.
• Ohne Vorzeichen commits können gefälschte Identitäten haben. Git commit Autor und commitDie Felder werden selbst gemeldet – jeder kann sie auf einen beliebigen Wert setzen. Ohne kryptografische Daten commit Signieren (GPG, SSH oder S/MIME) – es gibt keine Garantie dafür, dass ein commit Die Datei wurde tatsächlich von der Person verfasst, deren Urheberschaft angegeben ist. In diesem Fall legte der Angreifer den Verfasser der ersten schädlichen Datei als Autor fest. commit an die E-Mail-Adresse eines anderen Verantwortlichen, wodurch eine falsche Zuordnung entsteht. Unterschrift erforderlich commitDurch die Anwendung von Zweigschutzregeln wird dieser Vektor eliminiert.
• Komplexität vergrößert die AngriffsflächeDas Zusammenspiel von PATs, GitHub-Apps, Branch-Schutzregeln, Tag-Semantik und der Unveränderlichkeit von Releases schuf eine Umgebung, in der Angreifer Schwachstellen fanden, die keine dieser Funktionen einzeln abdeckte. Vereinfachen Sie, wo immer möglich. Verstehen Sie das gesamte Bedrohungsmodell, auch wenn dies nicht immer möglich ist.

Kompromissindikatoren (IOCs)