Dein Blog zum Thema digitales Business

Die häufigste Schwachstelle, die wir in echten Pipelines finden, ist keine exotische Zero-Day-Lücke. Es ist ein API-Token, ein Datenbankpasswort oder ein Cloud-Zugangsschlüssel, der im Klartext in einem Git-Repository liegt. Meist nicht einmal versteckt, sondern in einer Konfigurationsdatei, einem Test-Skript oder einer alten Commit-Nachricht. Wer Software baut, hat diese Lücke mit hoher Wahrscheinlichkeit irgendwo offen.

Wie Secrets überhaupt ins Repo geraten

Selten aus Nachlässigkeit, fast immer aus Bequemlichkeit. Ein Entwickler will lokal schnell etwas testen und schreibt den Schlüssel direkt in den Code, statt ihn als Umgebungsvariable zu laden. Das Skript wandert in einen Commit, der Commit in einen Branch, der Branch ins zentrale Repository. Ab da ist der Schlüssel für jeden sichtbar, der Lesezugriff hat. Bei öffentlichen Repositories bedeutet das: für die gesamte Welt, inklusive automatisierter Scanner, die GitHub rund um die Uhr nach genau solchen Mustern absuchen.

Typische Fundorte sind .env-Dateien, die versehentlich nicht in der .gitignore stehen, hartkodierte Verbindungsstrings in CI-Konfigurationen und Zugangsdaten in Klartext in Dockerfiles oder Deployment-Skripten.

Warum Löschen das Problem nicht löst

Der häufigste Reflex ist falsch: Den Schlüssel aus der Datei entfernen, neuen Commit machen, fertig. Git vergisst nichts. Jeder Commit bleibt in der Historie, und ein gelöschter Schlüssel lässt sich mit einem einzigen Befehl aus jedem früheren Stand wiederherstellen. Solange das Token gültig ist, ist es kompromittiert, sobald es ein einziges Mal im Repository stand.

Die einzig sichere Reaktion auf ein geleaktes Secret ist, es zu widerrufen und neu auszustellen. Erst danach geht es darum, die Historie zu bereinigen, damit der alte Wert nicht weiter herumliegt.

Was ein einzelnes Token anrichten kann

Die Tragweite hängt davon ab, was der Schlüssel öffnet. Ein Read-only-Token für eine Test-API ist ärgerlich. Ein Cloud-Zugangsschlüssel mit Schreibrechten kann eine ganze Infrastruktur kosten: fremde Server, die auf Ihre Rechnung Kryptowährung schürfen, gelöschte Datenbanken, abgeflossene Kundendaten. Die Angreifer brauchen dafür keine raffinierte Methode. Sie scannen, finden, nutzen. Zwischen dem Push und dem ersten Missbrauch liegen in dokumentierten Fällen nur Minuten.

Drei Maßnahmen, die heute Wirkung haben

• Secret-Scanning aktivieren. GitHub, GitLab und vergleichbare Plattformen bieten eingebaute Scanner, die bekannte Token-Muster erkennen. Einschalten kostet wenige Minuten und fängt die offensichtlichen Fälle ab, bevor sie produktiv werden.
• Secrets aus dem Code in einen Tresor verlagern. Zugangsdaten gehören nicht ins Repository, sondern in ein Secrets-Management-System oder zumindest in Umgebungsvariablen, die zur Laufzeit geladen werden. Der Code referenziert nur noch den Namen, nie den Wert.
• Pre-Commit-Hooks einsetzen. Ein lokaler Hook prüft jeden Commit, bevor er entsteht, und blockiert ihn, wenn ein verdächtiges Muster auftaucht. So entsteht die Lücke gar nicht erst.

Wissen Sie, was in Ihrer Historie liegt?

Die meisten Teams können diese Frage nicht beantworten. Nicht weil sie schludrig arbeiten, sondern weil niemand systematisch nachgesehen hat. Genau das prüfen wir.

Der GitSecOps QuickCheck durchleuchtet Ihre Repositories und Pipelines auf geleakte Secrets, ungesicherte Zugänge und typische Schwachstellen. Sie bekommen in drei Werktagen einen konkreten Befundbericht, keine Folien. Festpreis 1.990 Euro netto. Kontakt: mm@crank.zone.