Grenzen des GitHub-Audit-Logs: Aufbewahrung, Lücken, Pläne

Kurz gesagt. Das Audit-Log ist der beste Beweis, den Sie auf GitHub-Seite haben, und es hat harte Grenzen. Aufbewahrung: 180 Tage für Audit-Ereignisse, 7 Tage für Git-Events. Plan: API, Git-Events und Streaming setzen Enterprise Cloud voraus. IP-Adressen: verborgen, solange kein Owner die Anzeige aktiviert. Inhalte: keine Dateiinhalte, keine Diffs, kein Eintrag, wenn ein Workflow ein Secret liest, keine Lesezugriffe einzelner Benutzer auf Code in der Weboberfläche. Umfang: Die Sicherheitsprotokolle persönlicher Konten sind separat. Bevor Sie „keine Hinweise auf eine Kompromittierung“ schreiben, gleichen Sie jeden dieser Punkte mit dem Export ab, den Sie tatsächlich analysiert haben.

Jeder Untersuchungsbericht sollte sagen, was die Beweise zeigen konnten und was nicht. Für GitHub ist diese Liste kurz, aber wichtig, und mehrere Punkte hängen von Ihrem Plan und Ihren Einstellungen ab, nicht vom Angreifer.

Aufbewahrung

Daten	Aufbewahrung	Quelle
Audit-Ereignisse der Organisation / des Enterprise	180 Tage	About the audit log for your enterprise
Git-Events (`git.clone`, `git.fetch`, `git.push`)	7 Tage	dieselbe Seite sowie die Seite zum Audit-Log der Organisation
Standardzeitraum der API	die letzten 3 Monate, sofern `created` nicht angegeben ist	REST-Referenz
GraphQL-Audit-Log	90 bis 120 Tage an Daten	Reviewing the audit log (Enterprise Cloud)
Actions-Protokolle und -Artefakte	standardmäßig 90 Tage (konfigurierbar)	Aufbewahrungseinstellungen
Gestreamtes Audit-Log	so lange, wie Ihr Speicher es aufbewahrt	Ihr Bucket / SIEM

Was das in der Praxis bedeutet: Bei einem Einbruch, der drei Wochen zu spät entdeckt wird, gibt es überhaupt keine Klon-Einträge, sofern Sie nicht streamen. Bei einem Einbruch, der sieben Monate zu spät entdeckt wird, gibt es auf GitHub-Seite kaum noch Beweise. Audit-Log-Streaming ist der einzige Weg, beide Grenzen zu überwinden.

Voraussetzungen je nach Plan

Funktion	Free / Team	Enterprise Cloud
Audit-Log der Organisation ansehen und exportieren (UI, JSON / CSV)	ja	ja
REST- und GraphQL-API des Audit-Logs	nein	ja
Git-Events	nein	ja (API, Export, Streaming)
Audit-Log-Streaming	nein	ja (Enterprise)
IP-Zulassungsliste, SAML-SSO	nein	ja

GitHub gibt an, dass die Audit-Log-API Enterprise Cloud voraussetzt, und dasselbe gilt für IP-Zulassungslisten. In den Plänen Free und Team ist der Export aus der UI Ihre wichtigste Quelle, und Massen-Klonen lässt sich nur indirekt erschließen (siehe Exfiltration von Repositories).

Einstellungen, die bestimmen, was Sie bekommen

IP-Adressen. GitHub zeigt Quell-IP-Adressen standardmäßig nicht an. Wenn ein Owner die Anzeige aktiviert, gilt das für neue und bestehende Ereignisse. Selbst dann werden IP-Adressen nur unter bestimmten Bedingungen angezeigt: bei Mitgliedern der Organisation, die auf private oder interne Ressourcen der Organisation zugreifen, und bei API-Anfragen mit Repository-Kontext. Rechnen Sie mit Lücken.
Token-Metadaten. hashed_token, programmatic_access_type und token_scopes werden für Ereignisse aufgezeichnet, die mit einem Token authentifiziert wurden. Die Daten für Git-Events sowie für SSH- und Deploy-Keys sind in GitHubs Dokumentation als Public Preview gekennzeichnet, und Suchen nach hashed_token in UI und API schließen Git-Events aus.

Was nicht aufgezeichnet wird

Dateiinhalte und Diffs. Das Audit-Log sagt Ihnen, dass ein Push stattgefunden hat und ein Workflow gelaufen ist. Es sagt Ihnen nicht, was in der Workflow-Datei stand. Ein veränderter Workflow muss aus seinen Läufen erschlossen werden (neuer Branch, ausgegebene Secrets) und in der Historie des Repositories bestätigt werden.
Lesezugriffe auf Secrets. Das Anlegen, Ändern und Löschen von Actions-Secrets sind Ereignisse. Dass ein Workflow während eines Laufs ein Secret verwendet, ist keines. Das Protokollarchiv des Laufs ist der einzige Nachweis dafür, was ein Schritt damit gemacht hat (siehe Actions-Secrets geleakt).
Git-Operationen über Weboberfläche oder API. Git-Events schließen sie aus. Ein im Browser gemergter Pull Request pusht auf den Basis-Branch, ohne dass ein git.push-Ereignis entsteht.
Code-Ansicht in der Weboberfläche. Das Betrachten von Dateien im Browser erzeugt keine Audit-Ereignisse pro Datei. Archiv-Downloads (repo.download_zip) dagegen schon.
Was auf Runnern passiert. Das Audit-Log sieht die Registrierung und den Status von Runnern, nicht die Befehle, die ein Job auf einem Self-hosted Host ausgeführt hat. Diese stehen in den _diag-Logs des Runners (siehe Self-hosted Runner Sicherheit).
Aktivität persönlicher Konten. Das eigene Sicherheitsprotokoll eines Benutzers (Anmeldungen, 2FA-Änderungen, seine SSH-Keys und Tokens) ist vom Audit-Log der Organisation getrennt und nicht Teil ihres Exports. Der Benutzer prüft es selbst, und der Analyzer liest es nicht.
Alles, nachdem der Angreifer GitHub verlassen hat. In AWS, Google Cloud oder Azure verwendete Cloud-Keys tauchen in deren Logs auf (siehe Geleakte Cloud-Keys in GitHub Actions).

Grenzen des Analyzers selbst

Das Werkzeug erbt jede der oben genannten Lücken und bringt eigene mit:

Heuristiken und Schwellenwerte. Massen-Klonen schlägt ab 10 verschiedenen Repositories pro Akteur und IP-Adresse innerhalb von etwa einer Stunde an. Neue IP-Adresse und neues Land brauchen 24 Stunden Historie pro Token oder Akteur. Ein langsamer Angreifer oder ein Export, der am Tag des Einbruchs beginnt, kann darunter bleiben.
Laute Regeln mit niedrigem Schweregrad. workflow-new-branch, token-new-ip und actions-secret-created schlagen bewusst auch bei normaler Arbeit an. Lesen Sie sie im Kontext.
Keine Anreicherung. Kein Abgleich von ASN oder Hosting-Anbieter, keine Threat Intelligence. So bleibt alles offline, aber die IP-Adressen müssen Sie selbst bewerten.
Begrenzte Tabelle. Die Ereignistabelle listet die ersten 100.000 Ereignisse. Analysiert werden alle Ereignisse, und die Hinweise zur Abdeckung sagen Ihnen, wann die Tabelle gekürzt ist.
Das Urteil „Keine Anzeichen einer Kompromittierung“ bedeutet „keine Regel hat bei diesen Logs angeschlagen“, nicht „keine Kompromittierung“. Die Hinweise zur Abdeckung sagen Ihnen, welche Regeln blind waren.

Die nächste Untersuchung erleichtern

Streamen Sie das Audit-Log in einen Speicher, den Sie kontrollieren, mit einer Aufbewahrung von mehr als 180 Tagen.
Aktivieren Sie die Anzeige von IP-Adressen.
Legen Sie die Aufbewahrung der Actions-Protokolle so fest, dass sie Ihre Erkennungsverzögerung abdeckt, und leiten Sie die Logs Ihrer Self-hosted Runner weiter.
Exportieren und archivieren Sie die Git-Events bei jedem Verdacht. Sieben Tage sind schnell vorbei.
Bewahren Sie monatlich einen Export als Vergleichsbasis auf, damit die Erkennung „neues Land“ eine Historie zum Vergleich hat.

FAQ

Wie lange bewahrt GitHub das Audit-Log auf?

Audit-Ereignisse der Organisation und des Enterprise werden für die letzten 180 Tage aufgeführt. Git-Events werden sieben Tage aufbewahrt. Die API liefert standardmäßig die letzten drei Monate, sofern Sie keinen created-Qualifier angeben. Wer mehr aufbewahren will, muss in den eigenen Speicher streamen.

Ist das GitHub-Audit-Log in den Plänen Free und Team verfügbar?

Owner einer Organisation können in jedem Plan das Audit-Log der Organisation in der Weboberfläche ansehen und exportieren. Die REST- und GraphQL-API des Audit-Logs, Git-Events, Audit-Log-Streaming, IP-Zulassungslisten und SAML-SSO setzen GitHub Enterprise Cloud voraus.