Ein CI/CD-Sicherheitsvorfall ist durchgestanden, der Zugriff ist gesperrt, die Pipeline läuft wieder. Jetzt beginnt die eigentliche Arbeit: das Postmortem. Die allgemeine Postmortem-Struktur behandelt der Artikel Was ein Postmortem enthalten muss, damit es beim nächsten Mal hilft. Hier geht es um die CI/CD-spezifischen Punkte danach: wie groß der Vorfall wirklich war, ob die Secrets tatsächlich rotiert sind und warum die Beweislage oft schon weg ist, bevor jemand mit der Analyse anfängt.
Logs sichern, bevor die Analyse beginnt
CI/CD-Umgebungen löschen ihre eigene Beweisgrundlage automatisch. GitHub behält Workflow-Logs und Artefakte standardmäßig 90 Tage, danach werden sie automatisch entfernt, anpassbar zwischen 1 und 90 Tagen für öffentliche Repositories und bis zu 400 Tage für private und interne, aber nur, wenn das vorher jemand eingestellt hat (docs.github.com, „Configuring the retention period for GitHub Actions artifacts and logs“). Bei selbstgehosteten Runnern kommt eine zweite, schärfere Grenze dazu: Die Diagnose-Logs liegen lokal im _diag-Verzeichnis auf der Runner-Maschine, nicht zentral bei GitHub (docs.github.com, „Monitor and troubleshoot self-hosted runners“). Wird die Maschine nach dem Vorfall neu aufgesetzt, bevor jemand diese Logs gezogen hat, ist dieser Teil der Beweiskette weg, unabhängig davon, was die Aufbewahrungsfrist für Workflow-Logs erlaubt.
Deshalb zuerst sichern, dann analysieren: Workflow-Run-Logs und Artefakte der betroffenen Zeiträume exportieren, Runner-Diagnose-Logs von jeder beteiligten Maschine kopieren, bevor sie neu aufgesetzt oder als Autoscaling-Instanz verworfen wird, und die Pipeline-Historie (wer hat wann welchen Workflow mit welchen Inputs ausgelöst) archivieren. Erst danach beginnt die Zeitstrahl-Arbeit aus der allgemeinen Postmortem-Struktur. Die Aufbewahrungsfrist für Audit-Logs, getrennt von Workflow-Logs, behandelt Audit-Log-Aufbewahrung: wenn die Vertragsfrist länger läuft als GitHubs Standardlimit.
Blast Radius abgrenzen, wenn mehrere Pipelines betroffen waren
Sobald ein Runner-Pool, eine Secrets-Umgebung oder eine Pipeline-Vorlage von mehreren Projekten gemeinsam genutzt wird, ist „welche Systeme waren betroffen“ die falsche erste Frage. Sie beantwortet nur, wo sich der Vorfall gezeigt hat, nicht, wohin er technisch reichen konnte. Den Unterschied zwischen geteilter Angriffsfläche vorher und tatsächlichem Vorfallsradius danach behandelt Self-hosted Runner als geteilte Angriffsfläche aus der Scoping-Perspektive vor dem Vorfall; hier geht es um die Abgrenzung im Nachhinein, während des Postmortems selbst.
Dafür reicht die Symptomliste nicht aus. Der Radius ergibt sich aus drei Fragen, in dieser Reihenfolge: Welche Runner-Gruppe oder welcher Pool hat den kompromittierten Job tatsächlich ausgeführt? Welche Repositories, Environments und damit welche Secrets hatten zum Zeitpunkt des Vorfalls Zugriff auf genau diese Gruppe? Und welche anderen Jobs liefen im selben Zeitraum auf derselben Infrastruktur, sodass sie über Zustand, Cache oder Prozesse des kompromittierten Jobs potenziell mitbetroffen waren? Die dritte Frage wird am häufigsten übersprungen, weil sie keine Alarmmeldung erzeugt: Ein unauffälliger Build auf einem mitgenutzten Runner zeigt kein Symptom, war aber technisch erreichbar. Der Blast Radius ist am Ende die Menge aus diesen drei Fragen, nicht die Menge der Systeme, die eine Störung gemeldet haben.
Credential-Rotation wirklich belegen, nicht nur behaupten
„Alle betroffenen Secrets wurden rotiert“ ist im Postmortem-Entwurf schnell geschrieben und in der Praxis oft eine Behauptung ohne Beleg: ein Haken auf einer Liste, kein Nachweis. Belegbar wird die Aussage erst mit zwei Angaben pro Secret: dem Zeitpunkt, zu dem der alte Zugriff nachweislich endete, und dem Zeitpunkt, zu dem der neue begann.
Für fine-grained Personal Access Tokens liefert das GitHub-Organisations-Audit-Log genau diese zwei Ereignisse mit Zeitstempel: personal_access_token.access_revoked für den alten Token und personal_access_token.access_granted für den neuen (docs.github.com, „Audit log events for your organization“). Liegt der revoked-Zeitstempel nicht eindeutig vor Abschluss des Vorfalls, ist die Rotation nicht belegt, unabhängig davon, was die Checkliste sagt. Dazu gehört eine Ablauffrist auf dem neuen Token: GitHub empfiehlt sie ausdrücklich und kann sie organisationsweit erzwingen (docs.github.com, „Managing your personal access tokens“). Ein Token ohne Ablaufdatum ist ein Secret, das beim nächsten Vorfall erneut unbegrenzt gilt. Für andere Secret-Typen (Deploy-Keys, OAuth-App-Tokens, Cloud-Zugangsschlüssel) gilt dasselbe Prinzip, auch wenn Ereignisname und Ablaufmechanik anders aussehen: ein Erstellungs- oder Freigabe-Ereignis für das neue Secret, ein Widerrufs- oder Löschereignis für das alte, beide mit Zeitstempel im Postmortem zitiert. Die routinemäßige Rotation außerhalb eines Vorfalls behandelt Secrets-Rotation: Warum ein einmaliger Scan nicht reicht; hier geht es um den Nachweis nach einem konkreten Vorfall, nicht um die Rotationskadenz im Normalbetrieb.
Wo das im Maßnahmenkatalog landet
Alle drei Punkte gehören als eigene Zeilen in den Maßnahmenkatalog, den die allgemeine Postmortem-Struktur bereits vorsieht: mit Person, Datum und Wirkungsprobe, nicht als Fußnote im Fließtext. „Logs gesichert“ braucht als Wirkungsprobe den Pfad oder das Ablagesystem, in dem die exportierten Dateien tatsächlich liegen. „Blast Radius abgegrenzt“ braucht die Liste der geprüften Runner-Gruppen und Environments, nicht nur das Ergebnis. „Rotation verifiziert“ braucht die beiden Zeitstempel pro Secret. Ohne diese drei Nachweise bleibt das Postmortem eine Geschichte über den Vorfall, keine Grundlage, auf die sich der nächste Vorfall stützen lässt.
Das Leistungsspektrum ist gestaffelt und baut auf Delivery-Transparenz auf. Es läuft über drei Felder: Implementation (Delivery- und Nachweiskontrollen in die Pipeline einziehen), AI Governance (Nachvollziehbarkeit dort schaffen, wo KI-gestützte Schritte in Build und Deployment Freigaben und Verantwortung verwischen) und Maintenance (die Übergabefrage: wem ein System nach dem Go-Live gehört und woran man merkt, dass es niemandem gehört). Ein festes Angebot daraus entsteht erst, wenn klar ist, was du wirklich brauchst. Kontakt: mm@mhm-dl.de.
Über das Anmeldeformular für den Newsletter trägst du deine E-Mail-Adresse ein, kreuzt die Einwilligung an und bestätigst die Anmeldung danach per Mail. Mit der Anmeldung willigst du ein, dass der Newsletter unter anderem folgende Themen behandelt: Schulungen zu Docker, Kubernetes, CI/CD, Git-Workflows und DevSecOps-Werkzeugen sowie die Anforderungen aus NIS2, CRA und DORA und deren technische Umsetzung.
Kommentar verfassen