Veröffentlichen Sie nicht Ihr aktives Arbeitsverzeichnis. Kopieren Sie den Code in ein neues Repository mit frischer Historie, scannen Sie ihn auf Secrets, personenbezogene Daten und Kundennamen, bis der Scan leer bleibt, pushen Sie ihn privat, prüfen Sie einen frischen Clone und machen Sie ihn erst dann öffentlich. Behandeln Sie alles, was jemals in der Historie stand, als bereits veröffentlicht.
Im Oktober 2026 habe ich etwa zehn meiner eigenen Tools veröffentlicht: Helfer für Sicherheitsaudits, einen Fragebogen-Assistenten, Netzwerk- und Migrations-Tooling sowie eine lokale Diktier-App. Alle begannen in einem privaten Arbeitsverzeichnis, in dem Kundenprojekte, Test-Credentials und mein eigenes Netzwerk vorkamen. Hier ist der Prozess, den ich genutzt habe, und was er noch nicht abdeckte.
Warum man das Repository nicht einfach auf öffentlich stellt
Weil Git sich alles merkt. Ein Token, den Sie vor drei Jahren committet und im nächsten Commit gelöscht haben, bleibt in der Historie. Das gilt auch für Kundennamen in alten Test-Fixtures, interne Hostnamen in Konfigurationsbeispielen und die persönliche E-Mail-Adresse im Autorenfeld jedes Commits.
Man kann die Historie umschreiben; GitHub dokumentiert dies. Bei einer Handvoll Tools war es jedoch sauberer, neu zu beginnen: ein frisches Repository pro Tool, nur der aktuelle Code, ein einziger initialer Commit. So gibt es keinen alten Branch, den man vergisst, und keinen veralteten Tag.
Die Checkliste
- Frisches Repository, frische Historie. Kopieren Sie nur den aktuellen Stand des Codes. Kein
git clone, keine Historie. - Commit über die Noreply-Adresse. GitHub stellt jedem Account eine private Commit-Adresse bereit. Für Accounts, die nach dem 18. Juli 2017 erstellt wurden, lautet das Format
ID+USERNAME@users.noreply.github.com, laut GitHub's email reference. Wenn die E-Mail-Privatsphäre aktiviert ist, "the commit author email address cannot be changed and will be a no-reply by default" (die E-Mail-Adresse des Commit-Autoren kann nicht geändert werden und ist standardmäßig eine No-Reply-Adresse) (setting your commit email). - Secret-Scanner ausführen. Ich habe Gitleaks genutzt, "a tool for detecting secrets like passwords, API keys, and tokens in git repos, files" (ein Tool zum Erkennen von Secrets wie Passwörtern, API-Keys und Token in Git-Repos und Dateien). Wichtig: Die README besagt nun, dass das Projekt funktional vollständig ist und zukünftige Releases nur Sicherheitspatches enthalten.
- Eigene Musterliste anwenden. Kundennamen und Arbeitgeber, persönliche Identifikatoren (Namen, Adressen, Telefonnummern, E-Mails), interne Hostnamen, private IP-Bereiche und Autoren-E-Mails in jeder Historie, die Sie beibehalten haben.
- Binärdateien und Dumps entfernen. Datenbank-Exporte, Modell-Dateien, Packet-Captures, Screenshots mit sichtbaren Details im Hintergrund.
- Zuerst privat pushen. Klonen Sie dieses private Repository dann in einen neuen Ordner und prüfen Sie den Clone, nicht Ihre Arbeitskopie. Der Clone ist exakt das, was die Welt sehen wird.
- Korrigieren, erneut scannen, wiederholen, bis sowohl der Secret-Scanner als auch Ihre eigenen Muster keine Treffer mehr liefern.
- Öffentlich machen und sauber halten. Aktivieren Sie Dependabot-Warnungen und mergen Sie die Sicherheits-Updates. Ein öffentliches Repository, das verrottet, ist eine eigene Art von Leak.
GitHub hilft zudem beim Pushen. Push protection ist "designed to prevent hardcoded credentials, such as secrets or tokens, from ever being pushed to your repository" (darauf ausgelegt, zu verhindern, dass hartkodierte Credentials wie Secrets oder Token in Ihr Repository gepusht werden). Auf Benutzerebene ist dies "is enabled by default" (standardmäßig aktiviert) und "stops you from pushing secrets to public repositories on GitHub" (verhindert das Pushen von Secrets in öffentliche Repositories auf GitHub). Auf Repository-Ebene ist es standardmäßig deaktiviert. Nutzen Sie dies als zweites Netz, nicht als primären Scan.
Was Scanner übersehen
Secret-Scanner suchen nach Dingen, die wie Credentials aussehen. Sie markieren keinen Kundennamen in einem Kommentar, keine E-Mail eines Kollegen in einer Test-Fixture oder den Hostnamen einer Firewall in einer Beispiel-Konfiguration. Das sind technisch gesehen keine Secrets. Es sind jedoch Informationen, die Sie nicht veröffentlichen wollten. Deshalb gibt es Schritt 4, und deshalb muss es Ihre eigene Liste sein: Niemand sonst kennt Ihre Kunden.
Test-Fixtures sind die andere Falle. Einige meiner Testdaten sehen absichtlich wie ein Token aus. Anstatt den Scanner auszuschalten, habe ich diese Funde in eine .gitleaksignore-Datei eingetragen, welche spezifische Funde per Fingerprint ignoriert. Alles andere wird weiterhin erfasst. Dasselbe gilt für jede Kontrolle: Sicherheitskontrollen, die das Audit bestehen und nichts bewirken (Kontrollen, die lautlos versagen) sind schlimmer als solche, die zu viele Meldungen produzieren.
Wenn trotzdem etwas durchrutscht
Das ist mir einmal passiert. Nach der Veröffentlichung tauchte ein privater Netzwerkbereich in einem Konfigurationsbeispiel auf. Es war kein Credential, aber es gab mehr über mein Setup preis, als ich teilen wollte.
GitHubs Anleitung zum removing sensitive data ist klar in der Reihenfolge. Wenn die Daten ein Secret sind, ist der erste Schritt "revoke and/or rotate that secret" (das Secret zu widerrufen und/oder zu rotieren). Das Umschreiben der Historie folgt danach, mit git-filter-repo und der Option --sensitive-data-removal. Die Anleitung sagt selbst, dass ein Rewrite "may not be warranted" sein kann (also nicht in jedem Fall nötig ist). Bei einem Credential macht die Rotation es nutzlos; der Rewrite räumt nur auf. Bei meinem Netzwerkbereich gab es nichts zu rotieren, also schrieb ich die Historie um.
Die zweite Lektion war weniger technischer Natur. Ein paar Wochen später habe ich drei Repositories wieder gelöscht. Es war nichts durchgeleakt, sie passten einfach nicht zu meinem Namen. Mein Test ist jetzt simpel: Würde ich dieses Repository in einem Vorstellungsgespräch ohne Zögern erklären? Wenn nicht, bleibt es privat.
Wo meine Tools gelandet sind
Die Tools, die den Prozess bestanden haben, finden Sie auf github.com/falshaw. Dieselbe Checkliste funktioniert für jeden, der echte Arbeit zeigen will, ohne das Netzwerk eines Kunden mitzuliefern. Sie passt zu dem Ansatz, Maschinen-Identitäten und Token als primäre Risiken zu betrachten, wie in KI-Agenten sind die Service-Accounts, die denken gelernt haben und Zugangsdaten sind tot. Es lebe die kontinuierliche Verifizierung..
Verwandte Notizen: