議論： Geheimnisse ausserhalb des Repositorys verwalten

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-17

翻訳がないため、原文を表示しています。 原文

Schritt 2 stellt das Entfernen aus der Repository-Geschichte vor die Rotation, und diese Reihenfolge ist falsch herum – der Artikel sagt es im Nebensatz selbst, zieht aber nicht die Folgerung. Ein Umschreiben der Geschichte ändert nichts am Sicherheitsstand: Jeder Klon, jeder Fork, jeder CI-Cache und jedes Spiegel-Repository hat die alten Commits; auf GitHub bleiben umgeschriebene Commits über ihre SHA erreichbar, bis der Support die Referenzen entfernt, und die Dokumentation von GitHub verlangt deshalb ausdrücklich, dass alle Mitwirkenden danach neu aufsetzen. Gleichzeitig ist die Umschreibung selbst ein Eingriff mit Kosten: Alle offenen Branches und Pull Requests müssen rebased werden, Signaturen und Verweise auf Commit-Hashes in Tickets und Release-Notes brechen, und ein Team, das das in der Hektik eines Vorfalls tut, produziert Folgefehler. Das Geheimnis ist ab dem Moment des Pushs als kompromittiert zu behandeln, also ist die einzige Sofortmassnahme die Rotation und die Prüfung der Nutzung. Die Umschreibung ist danach eine Frage der Hygiene – damit Scanner nicht bei jedem Lauf anschlagen und damit ein neues Teammitglied den Wert nicht in `git log -p` findet – und lohnt sich bei privaten Repositories mit kleinem Kreis eher als bei öffentlichen, wo der Wert längst geerntet ist. Der Schritt sollte «rotieren, dann entscheiden, ob umschreiben» heissen.

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-17

翻訳がないため、原文を表示しています。 原文

Ergänzungen zu Schritt 3 und zum Abschnitt «Grenzen». Für Geheimnisse, die nur beim Bauen gebraucht werden (privates Paketregister, Git-Zugang), hat BuildKit `RUN --mount=type=secret,id=npmrc` zusammen mit `docker build --secret id=npmrc,src=.npmrc`: Die Datei ist während des einen `RUN`-Schritts eingehängt und landet in keiner Image-Schicht, anders als `ARG`, dessen Wert in der Build-Historie steht. Zur Sichtbarkeit von Umgebungsvariablen: `/proc/<pid>/environ` ist für denselben Benutzer und für root lesbar, und Kindprozesse erben die gesamte Umgebung. systemd bietet mit `LoadCredential=`, `LoadCredentialEncrypted=` und `SetCredentialEncrypted=` (verschlüsselt mit `systemd-creds encrypt`, Schlüssel im TPM oder unter `/var/lib/systemd/credential.secret`) einen Weg, Geheimnisse einem Dienst als Dateien unter `$CREDENTIALS_DIRECTORY` zu geben, ohne sie in die Umgebung zu legen. Werkzeuge für Schritt 6: gitleaks und trufflehog durchsuchen Arbeitskopie und Geschichte; für das Entfernen aus der Geschichte empfiehlt die Manpage von `git filter-branch` selbst das Werkzeug `git filter-repo`; GitHub bietet mit Push Protection eine Sperre vor dem Push.