Ein Secret taucht in einem Commit auf, in einem CI-Log oder in einer Fehlermeldung, die jemand in einen öffentlichen Issue-Tracker kopiert hat. In diesem Moment beginnt eine Uhr zu laufen, die mit der eigentlichen technischen Bereinigung noch gar nichts zu tun hat. Was in den ersten 30 Minuten nach der Entdeckung passiert, entscheidet häufiger über den Schaden als die Frage, wie sauber die Git-Historie am Ende aussieht. Dieser Text beschreibt genau diese 30 Minuten: wer informiert wen, in welcher Reihenfolge, und welche Entscheidungen fallen müssen, bevor überhaupt ein technischer Schritt beginnt.
Was dieser Artikel bewusst ausklammert
Drei Fragen rund um einen Secret-Leak sind an anderer Stelle bereits ausführlich beantwortet, und sie werden hier nicht wiederholt. Wie du verhinderst, dass ein Secret überhaupt in die Git-Historie gelangt, steht in „Secret Scanning und Push Protection: Tokens stoppen, bevor sie in die Historie kommen“ (18.07.2026). Wie du eine Historie technisch bereinigst, in der ein Secret bereits liegt, steht in „Git-Historie nach einem Secret-Leak bereinigen: Was git filter-repo und BFG wirklich leisten“ (11.10.2026). Dieser Schritt beginnt nach allem, was hier beschrieben wird, nicht davor oder parallel dazu. Und wie und warum du ein kompromittiertes Secret rotierst, steht in „Secrets-Rotation: Warum ein einmaliger Scan nicht reicht“ (10.09.2026). Hier geht es nur darum, wer die Rotation auslöst und wann, nicht darum, wie sie technisch abläuft.
Die erste Entscheidung ist keine technische
Wer ein Secret entdeckt, steht sofort vor einem Impuls: selbst beheben, bevor jemand anders es merkt. Genau dieser Impuls ist das erste Problem. Eine Einzelperson kennt in diesem Moment weder den vollständigen Geltungsbereich des Secrets noch, ob bereits jemand unbefugt darauf zugegriffen hat. Die erste notwendige Handlung ist deshalb keine technische Reparatur, sondern eine Meldung an eine vorher festgelegte Stelle. Ohne diese Festlegung entscheidet im Ernstfall meist die Person, die zufällig am Bildschirm sitzt, und das ist keine verlässliche Eskalationskette.
Wer die Meldung zuerst bekommt
Die Meldung muss an genau eine vorab benannte Rolle gehen, nicht an einen Gruppenchat, in dem sich mehrere Personen für zuständig oder eben nicht zuständig halten können. Üblich und sinnvoll ist eine feste Incident-Owner-Rolle, die bei einem Secret-Leak immer zuerst informiert wird, unabhängig davon, wer die Entdeckung gemacht hat: ein Entwickler, ein automatisierter Secret-Scanner oder eine externe Meldung über ein Responsible-Disclosure-Postfach. Diese Rolle muss zum Zeitpunkt der Meldung tatsächlich erreichbar sein, mit einem benannten Vertreter für den Fall, dass sie es nicht ist. Wird diese Festlegung erst während des laufenden Vorfalls getroffen, kostet allein die Klärung „wer ist zuständig“ Minuten, die später fehlen.
Rotation sofort oder erst Scope klären: wer das entscheidet
Die zweite Entscheidung in dieser halben Stunde ist, ob das betroffene Secret sofort rotiert wird oder ob zuerst geklärt wird, wofür es überhaupt Zugriff gewährt. Beide Reihenfolgen haben Nachteile: Sofortige Rotation ohne Scope-Kenntnis kann produktive Systeme stören, die von diesem Secret abhängen, oder Spuren verwischen, die für die spätere Einordnung des Vorfalls relevant gewesen wären. Scope-Klärung vor Rotation lässt ein kompromittiertes Secret länger aktiv, in der Zeit, in der ein Angreifer es bereits nutzen könnte. Welche Reihenfolge im Einzelfall richtig ist, hängt vom Risiko ab, nicht von Gewohnheit, und genau deshalb braucht es eine benannte Person, die diese Abwägung trifft, nicht ein informelles „wir machen das schon“. Dieser Artikel beschreibt bewusst nur, dass diese Entscheidung fällt und wer sie trifft, nicht wie die Rotation selbst technisch ausgeführt wird.
Wann ein Incident-Ticket eröffnet wird
Ein Incident-Ticket entsteht in dem Moment, in dem der Leak bestätigt ist, nicht erst nachdem die Rotation abgeschlossen oder die Historie bereinigt wurde. Der Grund ist Nachvollziehbarkeit: Ohne einen Zeitstempel ab der Entdeckung lässt sich später nicht rekonstruieren, wie viel Zeit zwischen Fund und erster Reaktion lag, und diese Zeitspanne ist für eine spätere Bewertung des Vorfalls relevant, auch rechtlich. Enthält das betroffene System personenbezogene Daten, beginnt mit Kenntnis des Vorfalls die in Art. 33 DSGVO vorgesehene 72-Stunden-Frist zur Meldung an die Aufsichtsbehörde zu laufen. Ob dieser Fall vorliegt, muss früh geprüft werden, nicht erst, wenn die Frist bereits läuft.
Wer externe Kommunikation freigibt, und wer sie nicht freigeben darf
Wer gerade technisch an einem Vorfall arbeitet, soll in diesem Moment keine Aussage gegenüber Kunden, Aufsichtsbehörden oder der Öffentlichkeit formulieren oder freigeben müssen. Diese beiden Rollen gehören getrennt, mit einer eigenen, vorab benannten Freigabeinstanz für externe Kommunikation. Diese Trennung verhindert zwei typische Fehler: voreilige Entwarnung, bevor der Scope überhaupt geklärt ist, und eine technische Person, die neben der eigentlichen Arbeit auch noch Kommunikationsdruck abfedern muss. Die Freigabeinstanz entscheidet, ob und wann überhaupt kommuniziert wird, die technische Seite liefert ihr dafür den aktuellen Kenntnisstand, nicht die fertige Formulierung.
Was diese 30 Minuten dokumentieren müssen
Unabhängig vom weiteren Verlauf hält die erste halbe Stunde mindestens vier Angaben fest: den Zeitpunkt der Entdeckung, wer wann informiert wurde, welche Entscheidung zu Rotation oder Scope-Klärung getroffen wurde und von wem, sowie den zu diesem Zeitpunkt angenommenen Geltungsbereich des Secrets. Diese vier Punkte sind der Unterschied zwischen einem Vorfall, der sich später auswerten lässt, und einem, bei dem sich niemand mehr an die Reihenfolge erinnert. Erst auf dieser Grundlage beginnt die technische Arbeit, die in den oben verlinkten Artikeln beschrieben ist.
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