GitHub-Audit-Log exportieren: UI, API und Streaming

Kurz gesagt. Für vollständige Beweise brauchen Sie mehrere Quellen, nicht nur eine. Sichern Sie den UI-Export (JSON, alle Pläne), die REST-API mit include=all (Enterprise Cloud und der einzige Weg zu Git-Events pro Organisation), die Streaming-Dateien, falls vorhanden, den Git-Events-Export (Enterprise, 7 Tage Aufbewahrung) und die Actions-Protokollarchive verdächtiger Läufe. Holen Sie die Git-Events zuerst. Jedes der unten beschriebenen Formate können Sie unverändert in den Analyzer im Browser ziehen.

Dieser Leitfaden behandelt die praktische Seite jeder Quelle: wo Sie klicken, wie die Datei aussieht, welchen Plan Sie brauchen und was sie nicht enthält. Was Sie anschließend mit den Dateien tun, beschreibt die GitHub-Audit-Log-Analyse Schritt für Schritt.

Welche Quelle für welche Frage

Quelle	Plan	Inhalt	Aufbewahrung	Format
Audit-Log der Organisation, Export aus der Weboberfläche	Alle Organisationen	Einstellungen, Mitglieder, Repositories, Workflows, Metadaten zu Secrets	180 Tage	JSON-Array oder CSV
REST `GET /orgs/{org}/audit-log`	Enterprise Cloud	Dasselbe, plus Git-Events mit `include=all`	180 Tage (Git-Events: 7)	JSON-Seiten
Audit-Log-Export des Enterprise	Enterprise Cloud	Alle Organisationen des Enterprise	180 Tage	JSON oder CSV
Enterprise-Menü „Export Git Events“	Enterprise Cloud	`git.clone` / `git.fetch` / `git.push`	7 Tage	JSON Lines, gzip-komprimiert
Audit-Log-Streaming	Enterprise Cloud	Audit- und Git-Events, fortlaufend	Aufbewahrung Ihres Buckets	Dateien `.json.log.gz`
Actions „Download log archive“	Alle	Ausgabe jedes Schritts eines Laufs	standardmäßig 90 Tage	ZIP mit Textdateien
API für Secret-Scanning-Warnungen	Wo Secret Scanning aktiviert ist	Im Code gefundene geleakte Secrets	Bis zum Schließen	JSON

Die Planvoraussetzungen stammen aus der GitHub-Dokumentation: Laut der Seite für Organisationen setzt die Audit-Log-API GitHub Enterprise Cloud voraus. Unter GitHub Free oder Team ist der UI-Export Ihre Hauptquelle.

1. Audit-Log der Organisation aus der Weboberfläche

Öffnen Sie in der Organisation Settings → Archive → Logs → Audit log. Nur Owner haben Zugriff.
Filtern Sie zuerst. Das Suchfeld akzeptiert created:>=2026-09-01, actor:, action:, repo: und country:.
Klicken Sie auf Export und wählen Sie JSON. CSV funktioniert ebenfalls, aber JSON erhält verschachtelte Felder wie actor_location.country_code.

GitHub begrenzt jeden Export auf 100 MB komprimiert oder 10 Minuten Verarbeitungszeit. Einen langen Zeitraum exportieren Sie deshalb Woche für Woche. Duplikate aus überlappenden Abschnitten sind für den Analyzer kein Problem, er dedupliziert anhand von _document_id.

Aktivieren Sie zuerst die IP-Adressen. GitHub zeigt Quell-IP-Adressen standardmäßig nicht an. Ein Owner kann die Anzeige der IP-Adressen einschalten. Die Einstellung gilt für neue und bestehende Ereignisse, das Aktivieren lohnt sich also auch noch während eines Vorfalls. Ohne sie fehlt actor_ip, und die Erkennungen für neue IP-Adressen und neue Länder können nicht anschlagen. IP-Adressen gelten in vielen Rechtsordnungen als personenbezogene Daten: Prüfen Sie Ihre Pflichten, bevor Sie sie speichern.

2. REST-API (Enterprise Cloud)

Der Endpunkt für Organisationen ist in der REST-Referenz dokumentiert. Sie müssen Owner sein, und ein klassisches Token braucht den Scope read:audit_log.

curl -sSL -H "Authorization: Bearer $TOKEN" \
  -H "Accept: application/vnd.github+json" \
  "https://api.github.com/orgs/ORG/audit-log?include=all&per_page=100&phrase=created:%3E%3D2026-08-01" \
  -o page-001.json

Drei Details sorgen regelmäßig für Überraschungen:

include ist standardmäßig web. Mit include=all erhalten Sie zusätzlich die Git-Events, mit include=git nur diese.
Ohne phrase mit einem created-Qualifier liefert die API nur die letzten drei Monate.
Folgen Sie dem Header Link: rel="next", bis er verschwindet. Der Endpunkt erlaubt 1.750 Abfragen pro Stunde je Benutzer und IP-Adresse.

Speichern Sie jede Seite als eigene Datei oder hängen Sie sie aneinander. Der Analyzer akzeptiert Arrays, aneinandergehängte Arrays und JSON Lines.

3. Git-Events-Export (Enterprise)

Enterprise-Owner finden im Audit-Log des Enterprise ein eigenes Menü Export Git Events. Wählen Sie den Zeitraum und laden Sie das Ergebnis herunter. GitHub beschreibt das auf der Seite zum Enterprise-Export. Die Datei enthält komprimierte JSON Lines mit einem Namen wie export-<enterprise>-<timestamp>.json.gz; entpacken müssen Sie sie nicht.

Zwei Grenzen sind für eine Untersuchung wichtig:

Die Aufbewahrung beträgt sieben Tage. Exportieren Sie noch am Tag, an dem Sie den Vorfall eröffnen.
Operationen über Web und API fehlen. Ein im Browser gemergter Pull Request pusht auf den Basis-Branch, doch dieser Push erscheint nicht als Git-Event. Das Fehlen von git.push bedeutet also nicht, dass es keine Änderungen gab.

Da das Audit-Log Token-Daten für Git-Events enthalten kann, können git.clone-Zeilen einen hashed_token tragen. Wenn Sie nach diesem Feld gruppieren, können Sie den Entwickler von jemandem unterscheiden, der sein Token wiederverwendet.

4. Audit-Log-Streaming

Wenn Ihr Enterprise sein Audit-Log streamt, besitzen Sie bereits die vollständigste Quelle. Sie enthält Audit- und Git-Events aller Organisationen, und Ihr Speicher bewahrt sie so lange auf, wie Sie es festlegen. Unterstützte Ziele sind Amazon S3, Azure Blob Storage, Azure Event Hubs, Datadog, Google Cloud Storage und Splunk. Im Objektspeicher gilt die Struktur YYYY/MM/DD/HH/MM/<uuid>.json.log.gz.

Laden Sie die Ordner herunter, die den Zeitraum abdecken, und ziehen Sie den gesamten Verzeichnisbaum oder ein ZIP davon in das Werkzeug. Jede .json.log.gz-Datei wird on the fly entpackt. Prüfen Sie außerdem, ob jemand den Stream verändert hat. audit_log_streaming.destroy oder .update während des Vorfalls ist für sich schon ein Befund (siehe Übernahme der Organisation). Der Glossareintrag zum Streaming erklärt, wie GitHub Ereignisse zwischenspeichert, während ein Stream pausiert ist.

5. Protokollarchive von Actions-Läufen

Für jeden verdächtigen Lauf: Repository → Actions → der Lauf → ⋯ → Download log archive. Sie erhalten ein ZIP mit dem zusammengefassten Protokoll jedes Jobs und einem Ordner mit je einer Datei pro Schritt. Jeder mit Lesezugriff kann es herunterladen.

Tun Sie das frühzeitig. Die Protokolle unterliegen der Aufbewahrungsrichtlinie (standardmäßig 90 Tage), und jeder mit Schreibzugriff kann sie löschen. Wurde ein Lauf teilweise erneut ausgeführt, enthält das Archiv nur die erneut ausgeführten Jobs – laden Sie deshalb auch die früheren Versuche herunter.

6. Secret-Scanning-Warnungen

GET /orgs/{org}/secret-scanning/alerts liefert die Warnungen als JSON (siehe REST-Referenz). Legen Sie diese Datei neben das Audit-Log. Betrifft eine Warnung Zugangsdaten für AWS, Google Cloud oder Azure, zeigt das Werkzeug den nächsten Schritt in der Cloud an. Warum das wichtig ist, erklärt der Artikel zum Weg in die Cloud.

Beweiskette in Kürze

Dokumentieren Sie, wer was wann mit welchem Filter exportiert hat. Berechnen Sie für jede Datei einen SHA-256-Hash und bewahren Sie die Originale schreibgeschützt auf. Arbeiten Sie nur mit Kopien. Nichts davon ist GitHub-spezifisch, doch wegen der kurzen Aufbewahrung der Git-Events bekommen Sie für denselben Export keine zweite Chance.

FAQ

Warum fehlt git.clone in meinem Audit-Log-Export?

Der Export aus der Weboberfläche enthält keine Git-Events. Sie erhalten sie über die REST-API mit include=git oder include=all, über das Enterprise-Menü Export Git Events oder über Audit-Log-Streaming – alles setzt GitHub Enterprise Cloud voraus. Git-Events werden sieben Tage aufbewahrt.

Gibt es eine Größenbeschränkung für Audit-Log-Exporte?

Ja. GitHub bricht einen Export bei 100 MB komprimiert oder nach 10 Minuten Verarbeitungszeit ab. Filtern Sie mit dem Qualifier created nach Datum und exportieren Sie in mehreren Abschnitten, oder nutzen Sie für große Datenmengen die API oder Streaming.