Post by Michél Keilhauer
Heute Morgen habe ich das erste Mal (bewusst) von GitGuardian gehört.
Grund dafür war eine Spammail mit dem Betreff “[mrtoadie/lab] Kubernetes JSON Web Token exposed on GitHub“.
Mein erster Impuls: Spam, Fake, Phishing – ignorieren. Also weiter gemacht, aber mein Unterbewusstsein hat mir immer wieder den einen Satz untergejubelt: “Hinterfrage alles, ALLES!“
Dass ich nicht sofort reagiert habe, lag wohl an der Uhrzeit und dem fehlenden ersten Kaffee. 🫖
Also zurück zur Mail und recherchiert, und die Behauptung der Mail überprüft.
Und siehe da: Ich hatte tatsächlich gestern Abend eine .env-Datei mit einem Kubernetes-Token in mein Repo gepusht.
Glücklicherweise ist mein Homelab nicht von außen erreichbar und nachts grundsätzlich ausgeschaltet. Keine Gefahr, aber ich habe etwas gelernt.
Also, vielen Dank an GitGuardian für genau das, was sie tun:
“GitGuardian ist ein Sicherheitsunternehmen mit Fokus auf Secret Detection – also das Aufspüren versehentlich committeter Zugangsdaten in Git-Repositories.”
Es gibt für genau derartige Zwecke reichlich SW die man in pre-commit-hooks stecken kann (und sollte) a la trufflehog, gitleaks etc.
Und natürlich für PRs (wobei da dann je nach Ort der Schaden schon gegeben ist) und das klassische GitHub Token/Secret Scanning.
Ich hatte es vor längerer Zeit mal getestet. Soweit ich mich erinnern kann, konnte man es nicht komplett offline nutzen. Es war immer nen GitGuardian Account nötig und das Repo wurde in die GitGuardian Cloud gecloned.
Mein Ansatz ist offline First, damit die Tools auch in Repos und Pipelines genutzt werden können, in denen es um privaten oder sensiblen Code geht.
Die dann entsprechend auch nicht unnötig frei zugängig sein sollte. Es gab da in letzter Zeit ein paar Vorfälle.
Da wäre mal seitens der großen Drittverwender aus der ÖD-Ecke die regelmäßige Finanzierung von Audits angesagt. Alleine schon aus Eigeninteresse…
Keine Sorge. Läuft auf meinem Cluster der grundsätzlich nicht von außen erreichbar ist.