Was ein Fund in der Secret-Scanning-Übersicht tatsächlich aussagt
Secret Scanning erkennt Muster, die wie ein Secret aussehen: ein API-Key mit typischem Präfix, ein Token-Format, ein privater Schlüssel. Der Alert sagt an dieser Stelle nur eines: Ein Muster wurde gefunden. Er sagt nicht, ob das gefundene Credential überhaupt noch funktioniert. Ein Token kann längst abgelaufen, widerrufen oder durch einen anderen Prozess bereits deaktiviert worden sein, der Fund in der Historie bleibt trotzdem stehen. Wer „gefunden“ automatisch mit „aktiv ausnutzbar“ gleichsetzt, bewertet jeden Alert gleich hoch, unabhängig davon, ob dahinter noch ein funktionierendes Zugangsmittel steckt oder nur ein wirkungsloses Textmuster.
Was Validity Checks zusätzlich prüfen
Validity Checks sind ein eigenes Feature von Secret Scanning, das genau diese Lücke schließt. Nach der Aktivierung prüft GitHub periodisch, ob ein erkanntes Credential noch gültig ist, indem es das Secret an den jeweiligen Aussteller schickt und gegen dessen API testet. Aus dem reinen Musterfund wird damit eine Aussage über den tatsächlichen Zustand: aktiv, inaktiv oder Status unbekannt. Verfügbar ist die Prüfung für Secrets vieler Service-Anbieter, die Unterstützung wird über weitere GitHub-Partnerschaften laufend erweitert. Der Validierungsstatus erscheint direkt in der Alert-Ansicht, für die meisten Secrets lässt sich zusätzlich einzeln eine On-Demand-Prüfung anstoßen, statt auf den nächsten periodischen Durchlauf zu warten.
Wie die Prüfung abläuft, ohne selbst zum Risiko zu werden
Eine Validitätsprüfung bedeutet, ein echtes Credential gegen einen echten Dienst zu testen, das ist technisch kein harmloser Vorgang. GitHub begrenzt deshalb bewusst, was dabei passiert: bevorzugt werden GET-Requests, möglichst wenig eingriffsintensive Endpunkte und Endpunkte, die keine personenbezogenen Daten zurückliefern. Manche Secrets lassen sich mit dem Token allein gar nicht sinnvoll prüfen, dafür kombiniert GitHub den Token mit Zusatzkontext wie Host oder URL, um überhaupt eine aussagekräftige Antwort vom Aussteller zu bekommen. Ergänzend dazu gibt es Extended Metadata Checks, aktuell in der Public Preview: ein separates Feature, das zusätzlichen Kontext liefert, etwa wer ein Secret besitzt oder welchen Scope es hat, gedacht für Incident Response und Compliance und zur Reduktion von False Positives. Das ist ein eigenes Thema, kein Ersatz für die reine Gültigkeitsprüfung.
Was der Validierungsstatus für die Priorisierung ändert
Ohne Validierungsstatus sieht eine Fundliste nach Secret Scanning immer gleich aus: eine Reihe von Alerts, jeder mit demselben Dringlichkeitssignal. Mit Validierungsstatus zerfällt diese Liste in unterschiedliche Fälle. Ein als aktiv markiertes Secret ist ein echtes, akutes Risiko und gehört an die Spitze der Bearbeitung. Ein als inaktiv markiertes Secret ist zwar weiterhin ein Fund, aber kein akuter Handlungsdruck mehr. Status unbekannt bleibt eine offene Frage, die eine On-Demand-Prüfung wert ist. Teams, die stattdessen jeden Fund identisch behandeln und reflexhaft rotieren, binden Reaktionskapazität an Alerts, die längst wirkungslos sind, und verzögern damit die Reaktion auf die Fälle, die wirklich brennen.
Was Validity Checks nicht ersetzen
Validity Checks ordnen einen Fund ein, sie verhindern ihn nicht und sie beseitigen ihn nicht. Das Erkennen und Verhindern von Secrets, bevor sie überhaupt in die Historie kommen, ist Aufgabe von Secret Scanning und Push Protection selbst, separat beschrieben. Ob ein als aktiv erkanntes Secret überhaupt rotiert werden muss, beantwortet der Validierungsstatus mit Ja oder Nein, wie die Rotation als wiederkehrender Prozess organisiert wird, bleibt eine eigene Frage, die hier behandelt wird. Aus der Git-Historie verschwindet ein Fund durch eine Validitätsprüfung nicht, dafür braucht es die Historie-Bereinigung mit git filter-repo oder BFG. Und ob ein aktiver Fund einen internen Eskalationsprozess auslösen muss, ist eine organisatorische Entscheidung, die der Validierungsstatus nur anstößt, aber nicht selbst trifft, dazu die Meldewege für die ersten 30 Minuten. Validity Checks liefern den Input, der entscheidet, mit welcher Dringlichkeit diese vier anderen Prozesse überhaupt anlaufen.
Wo Unterstützung ansetzt
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