Die meisten Sicherheitsdiskussionen drehen sich um Zugriff. Wer darf was, wer kommt rein, wer wurde vergessen. Das ist die halbe Frage. Die andere Hälfte ist, was jemand über eine Organisation erfährt, ohne überhaupt Zugriff zu brauchen. Öffentliche Repos, öffentliche Profile, öffentliche Metadaten. Kein Login, kein Exploit, keine Lücke. Nur lesen.
Zwanzig Minuten reichen dafür erstaunlich weit. Nicht weil jemand etwas falsch gemacht hat, sondern weil GitHub für Zusammenarbeit gebaut ist und Sichtbarkeit dabei der Normalfall ist.
Die Mitgliederliste ist eine Organigramm-Vorlage
Wer Mitglieder in einer Organisation öffentlich sichtbar stellt, veröffentlicht damit eine Personalliste. Aus den Profilen lassen sich Rollen ableiten, aus der Aktivität die Schwerpunkte. Wer committet in die Infrastruktur-Repos, wer in die Frontend-Repos, wer hat zuletzt vor zwei Jahren etwas gemacht und ist wahrscheinlich nicht mehr da. Für Social Engineering ist das ein guter Startpunkt: Namen, Verantwortungsbereiche und ein Gefühl dafür, wer neu ist und wer nachfragen würde.
Das ist kein Argument dafür, alles zu verstecken. Open Source lebt davon. Es ist ein Argument dafür, es bewusst zu entscheiden statt als Default zu übernehmen.
Commit-Metadaten verraten mehr als der Code
Jeder Commit trägt Autor, E-Mail-Adresse und Zeitstempel. Daraus entsteht ein Muster: interne Adress-Konvention, Arbeitszeiten, Urlaubsphasen, Release-Rhythmus. Die E-Mail-Konvention allein ist wertvoll, weil sich damit Adressen für Personen erraten lassen, die nie etwas committet haben.
Zeitstempel sagen, wann niemand hinschaut. Ein Deploy am Freitag um 18 Uhr, der Montag früh geprüft wird, ist ein Zeitfenster.
Die Historie vergisst nicht, was gelöscht wurde
Das ist der Punkt, der am häufigsten unterschätzt wird. Ein Token, das in einem Commit landete und im nächsten wieder entfernt wurde, ist nicht weg. Es steht in der Historie. Wer den Verlauf klont, findet es. Ein rebase oder force-push in der eigenen Kopie hilft nur begrenzt, weil Forks und Caches den alten Stand behalten können.
Ein Secret, das einmal öffentlich war, gilt als verbrannt. Nicht als „wurde schnell gefixt“, sondern als kompromittiert. Der einzige saubere Weg ist rotieren. Warum Zugänge grundsätzlich ein Ablaufdatum brauchen, steht in Pipeline-Secrets rotieren.
Workflow-Dateien sind eine Landkarte der Infrastruktur
In .github/workflows steht, was gebaut wird, womit deployt wird und wohin. Cloud-Provider, Registry-Adressen, Umgebungs-Namen, Namen von Secrets. Die Werte sind maskiert, die Namen nicht. AWS_PROD_DEPLOY_KEY sagt ohne einen einzigen Wert, welche Plattform im Einsatz ist, dass es eine Prod-Umgebung gibt und dass ein statischer Key existiert.
Dazu kommen die verwendeten Actions samt Versionen. Wer eine Action mit bekannter Schwachstelle auf einen beweglichen Tag pinnt, macht das öffentlich sichtbar. Warum SHA statt Tag der Unterschied ist, steht in Third-Party Actions pinnen.
Issues und Pull Requests sind ein Statusbericht
Offene Issues sagen, was kaputt ist und seit wann. PR-Diskussionen zeigen, wo Unsicherheit besteht und welche Workarounds im Einsatz sind. Ein Issue mit dem Titel „Auth-Middleware greift bei Legacy-Endpunkten nicht“ ist eine Ansage, auch wenn niemand einen Exploit dazuschreibt. Geschlossene Issues bleiben lesbar.
Was das praktisch bedeutet
Nichts davon ist ein Angriff. Es ist Lesen. Deshalb greift auch keine Kontrolle, die auf Zugriff basiert. Was hilft, ist ein bewusster Blick von außen:
- Die eigene Organisation im Logout-Modus ansehen. Was ein Fremder sieht, ist selten das, was man erwartet.
- Prüfen, welche Repos wirklich öffentlich sein müssen. Öffentlich aus Versehen ist häufiger als öffentlich aus Überzeugung.
- Secret Scanning und Push Protection aktivieren, damit Tokens gar nicht erst in die Historie kommen.
- Bei jedem gefundenen Secret rotieren statt löschen.
- Secret-Namen in Workflows neutral halten. Der Name muss nichts über Provider und Umgebung verraten.
- Öffentliche Mitgliedschaft als Entscheidung behandeln, nicht als Default.
Der Aufwand dafür ist gering. Der Unterschied ist, dass man selbst weiß, was über einen im Netz steht, statt es von jemand anderem zu erfahren.
GitSecOps QuickCheck: Wir sehen uns Ihre Pipeline und Ihre öffentliche GitHub-Oberfläche an und sagen konkret, was auffällt und was zuerst zu tun ist. 1.990 Euro netto, Ergebnis in 3 Werktagen. Kontakt: mm@crank.zone
Dein Blog zum Thema digitales Business 