In meinem Public Repo waren mal Passwörter drin (in der History). Wenn die geforkt haben, sehen die das in der History. Kann ich diese Forks checken? Bekomme ich ne Benachrichtigung?
Ich hab die History auf GitHub schon bereinigt (BFG), aber die Forks speichern den alten Code. Ich hab Angst, dass das Passwort immer noch ein Risiko ist.
Wie kann ich das Risiko minimieren, dass bei neuen Public Repos Secrets rauskommen?
GitHub Secret Leak Monitoring: Forks kopieren die History des Original-Repos, nach dem BFG-Push speichern die Forks immer noch die alten Secrets. Check: 1) GitHub Insights → Network (zeigt Fork-Graph, wissen wer geforkt hat), 2) wir haben kein direktes Zugriffsrecht auf die Forks, aber wir können DMCA Notices an die Owner schicken (GitHub abuse@github.com), 3) Secret Scanning: GitHub Advanced Security (Secret Scanning aktivieren → Alerts bei Public Repos), 4) Drittanbieter-Monitoring (GitGuardian: E-Mail-Alerts wenn ein Passwort auf GitHub public auftaucht), 5) Datenbank-Passwort ändern (auch wenn die alten Secrets in den Forks sind, solange das aktuelle Passwort neu ist, gibt's kein Zugriffsproblem). Nach der Mitigation: 1) BFG History im Original-Repo bereinigen, Force Push, 2) Nachricht an Fork-Owner (geringe Chance auf Antwort), 3) GitHub Abuse melden (Forks sind oft abandoned – kein Cleanup-Support), 4) Secrets rotieren (Datenbank, API Key, Tokens). Proaktive Prävention: 1) .gitignore (Secrets ausschließen), 2) GitHub Secret Scanning + Protection Rules (Commits mit Secrets blockieren), 3) Pre-Commit Hooks (lokales Scannen), 4) Von Anfang an Private Repo, wenn public, dann frei von Secrets. Risikobewertung: Wenn die alten Secrets in den Forks nicht genutzt werden (rotiert), ist das unmittelbare Risiko gering (historischer Wert), aber die Security Posture sieht schlecht aus.
check die forks im network tab. wenn alte secrets drin sind, änder trotzdem das db passwort. du kannst ne dmca notice bei github schicken, private fork kontrolle geht nicht. also schalt secret scanning bei github an damit du alerts kriegst....
GitHub Fork Monitoring: 1) REST API (curl https://api.github.com/repos/user/repo/forks → alle Forks auflisten, created_at timestamp), 2) Network Graph (GitHub UI zeigt Fork-Timeline + Owner), 3) GitGuardian (überwacht public GitHub, E-Mail-Alert wenn Credentials auftauchen), 4) Dependency Check (OWASP: Repo nach bekannten Secrets in Dependencies scannen). Secret Scanning: GitHub Advanced Security (Enterprise/Pro) scannt automatisch, Drittanbieter TokenScan (überwacht GitHub Pushes). Benachrichtigung: DMCA Notice (GitHub schickt Takedown-Anfrage an Fork-Owner), private Nachricht (geringere Erfolgsquote). Risiko: altes Secret im Fork + Leak im Fork = Angreifer sieht Credentials, aber wenn rotiert, ist der Original-Zugriff verweigert (geringes unmittelbares Risiko).
Check die Forks im Network Tab sind die gelistet. Mach Secret Scanning bei GitHub an. naja wenn du das Passwort rotiert hast, sind die Forks egal. Schick ne DMCA Notice an GitHub, aber die Fork-Owner zu erreichen ist schwer. In Zukunft speicherst du in Public Repos einfach gar nichts Sensibles mehr Punkt...
GitHub-Sicherheits-Best-Practices: 1) Repository-Einstellungen (standardmäßig privat öffentlich nur für ausgereifte Projekte), 2) Durchsetzung der Secret-Scanning (GitHub Advanced Security: Push blockieren der Secrets enthält), 3) Branch-Schutz (Review + bestandene Checks erforderlich) 4) Audit-Logging (wer hat was gepusht), 5) CODEOWNERS (Zuweisung von Code-Reviews). Fork-Sicherheit: Ein Fork erbt die Historie des Parents + Secret Scanning (falls aktiviert) aber der Fork-Inhaber steuert die Einstellungen unabhängig. Transparenz bei der Behebung: Sicherheitswarnung posten (GitHub Security Advisory), Incident-Report veröffentlichen Root-Cause + Fixes dokumentieren.
Genau so, und das ist zudem kaum bekannt. Wenn wir ohne Messung entscheiden, landen wir immer wieder am selben Punkt.
Aus Erfahrung weiß ich das.
Hier lauert eine Falle, die ich nicht unerwähnt lassen möchte. Wenn wir ohne Messung entscheiden, landen wir immer wieder am selben Punkt.
In den ersten drei Monaten läuft alles gut, die Probleme tauchen im vierten Monat auf. Korrigiert mich, falls ich falsch liege.
Da stimme ich zu. Je schwerer es ist, eine Entscheidung rückgängig zu machen, desto langsamer solltet ihr sie treffen.
Doki · Log-Management-Einrichtung · 2024
Betrachtet man den Prozess, ändert sich das Bild. Zwei Wochen Notizen machen liefert bessere Ergebnisse als eine sechsmonatige Schätzung.
Schreibt mir, wenn ihr Fragen habt, ich antworte so gut ich kann.
Hier lauert eine Falle, die ich nicht unerwähnt lassen möchte. Beginnt mit einem kleinen Test, bindet nicht gleich alles fest.
Das war's, entschuldige, wenn ich zu lang war.
Danke fürs Schreiben, das ist genau richtig. Ein automatisierter Scan-Report ist kein Penetrationstest.
Ich werde das Gegenteil vertreten, bitte nicht böse sein. In den ersten drei Monaten läuft alles gut, die Probleme tauchen im vierten Monat auf.
Du hast recht ich bin denselben Weg gegangen. Menschen verteidigen nicht den Prozess sondern die Gewohnheit... Der Widerstand kommt daher.
Ich hätte eine Frage, möchte aber nicht vom Thema abschweifen. Maßnahmen ohne vorherige Bestandsaufnahme lassen die Türen offen, die man nicht sieht.
Wenn es jemand anders macht, würde mich das auch interessieren.
Ich stimme voll und ganz zu. Wer bei github leak hetzt, stolpert alle an derselben Stelle.
Das war's, entschuldige, wenn ich zu lang war.
Vielen Dank, ich werde es heute testen. In den ersten drei Monaten läuft alles gut, die Probleme tauchen im vierten Monat auf.
Das war's, entschuldige, wenn ich zu lang war.
Teilweise stimme ich zu, teilweise nicht. Vergessene Testumgebungen sind häufiger das Einfallstor als das Live-System.
Wenn Genehmigung und Umfang nicht schriftlich vorliegen, darf der Test nicht starten.