Wie verhindert man, dass Secrets über die CI/CD-Pipeline durchsickern?
Kurzantwort
Setzen Sie auf Defense in Depth: Pre-Commit-Hooks (z. B. gitleaks) fangen Secrets ab, bevor sie landen, serverseitiges CI-Scanning fängt, was durchrutscht, und regelmäßige Scans des gesamten Verlaufs finden alte Lecks. Entscheidend: Ein Secret, das ein Remote-Repository erreicht hat, muss als kompromittiert behandelt und rotiert werden — den Commit zu löschen hilft nicht, da es im Verlauf, in Forks und Logs lebt. Kombinieren Sie das mit einem echten Secrets-Manager, damit Secrets gar nicht erst im Code stehen.
Fest codierte Zugangsdaten gehören zu den häufigsten und schädlichsten Fehlern in Software, und die Pipeline ist der Ort, an dem man sie abfängt. Eine gute Antwort ist mehrschichtig.
Fangen Sie es ab, bevor es landet: Pre-Commit
Ein Pre-Commit-Hook (mit einem Scanner wie gitleaks oder detect-secrets) läuft auf dem Rechner des Entwicklers und blockiert den Commit, wenn er einen API-Schlüssel, einen privaten Schlüssel oder ein Token entdeckt. Das ist der günstigste Ort, um ein Leck zu stoppen — das Secret erreicht den Server nicht einmal. Die Schwäche: Hooks sind lokal und können umgangen oder übersprungen werden, daher können sie nicht Ihre einzige Linie sein.
Fangen Sie ab, was durchrutscht: serverseitige CI
Da Hooks nicht erzwingbar sind, führen Sie das gleiche Scanning serverseitig in der CI bei jedem Push und Pull Request aus, idealerweise als plattformweiten Scan (natives Secret-Scanning von GitHub/GitLab), den der Entwickler nicht deaktivieren kann. Das ist das erzwingbare Gate.
Finden Sie alte Lecks: Verlaufsscanning
Vor Monaten committete Secrets liegen weiterhin im Git-Verlauf. Scannen Sie regelmäßig den gesamten Verlauf und nutzen Sie Push-Schutz, damit von der Plattform erkannte Secrets bereits beim Push blockiert werden.
Das Unverhandelbare: rotieren
Hier ist der Teil, den Junioren übersehen. Sobald ein Secret ein Remote-Repository erreicht hat, ist es kompromittiert — Punkt. Es bleibt im Verlauf, in Klonen, in Forks und in CI-Logs bestehen. Den Commit zu löschen oder den Verlauf umzuschreiben macht es nicht sicher. Die einzig richtige Reaktion ist, die Zugangsdaten sofort zu rotieren.
Besser: keine Secrets im Code
Die grundlegende Lösung ist ein Secrets-Manager (Vault, Cloud-KMS/Secret-Stores), damit Anwendungen Secrets zur Laufzeit abrufen und die CI sie als maskierte Variablen injiziert — es gibt nichts zu lecken.
Worauf Interviewer achten
Sie wollen das mehrschichtige Modell, das Beharren auf Rotation statt Löschung und die Erkenntnis, dass Secrets-Manager das Problem an der Quelle beseitigen.
Wahrscheinliche Anschlussfragen
- Warum reicht das Löschen des betreffenden Commits nicht aus?
- Wo sollten Secrets tatsächlich liegen statt im Code?
- Warum Scanning sowohl pre-commit als auch serverseitig ausführen statt nur eines?