-
Continue reading →: Was ein Angreifer in 20 Minuten aus einer offenen GitHub-Organisation liest
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.…
-
Continue reading →: Deploy-Umgebungen trennen: warum Staging und Prod nicht dieselben Credentials teilen dürfen
In vielen Pipelines gibt es genau einen Satz Zugangsdaten. Ein Deploy-Key, ein Cloud-Account, ein Datenbank-Passwort. Damit läuft der Build nach Staging, und damit läuft er nach Produktion. Das ist bequem, spart Einrichtung und funktioniert jahrelang problemlos. Bis zu dem Tag, an dem jemand Zugriff auf Staging bekommt und feststellt, dass…
-
Continue reading →: Effektive vs. nominale Rechte in GitHub: warum Team-Vererbung überrascht
In der GitHub-Oberfläche steht neben jedem Team eine Rolle: Read, Write, Admin. Das ist die nominale Zuweisung, also das, was jemand laut Konfiguration bekommen soll. Was eine einzelne Person am Ende tatsächlich darf, steht dort nicht. Effektive Rechte entstehen aus mehreren Quellen gleichzeitig, und bei Konflikten gewinnt immer die höchste.…
-
Continue reading →: Pipeline-Secrets rotieren: warum statische Deploy-Keys ein Ablaufdatum brauchen
In den meisten Pipelines liegt irgendwo ein Deploy-Key oder ein Access-Token, das seit Jahren unverändert ist. Es funktioniert, also fasst es niemand an. Genau das ist das Problem. Ein statisches Secret, das nie rotiert wird, sammelt über die Zeit stillschweigend Risiko an, ohne dass jemand es merkt. Dieser Beitrag zeigt,…
-
Continue reading →: Lockfiles richtig nutzen: Reproduzierbarkeit gegen Sicherheit
Ein Lockfile ist die stille Instanz in fast jedem Projekt. Es entscheidet, welche Version jeder Abhängigkeit wirklich installiert wird, und trotzdem schaut kaum jemand hinein. Dabei liegt genau hier der Punkt, an dem Reproduzierbarkeit und Sicherheit sich treffen und manchmal gegeneinander ziehen. Wer den Umgang mit package-lock.json, yarn.lock, poetry.lock oder…
-
Continue reading →: Artifact Registries absichern: von Docker Hub bis internem Nexus
Jede Pipeline endet an derselben Stelle: einem Artefakt, das irgendwo abgelegt wird. Container-Images, npm-Pakete, JAR-Dateien, Helm-Charts. Der Ort, an dem sie liegen, heißt Artifact Registry. In vielen Teams ist genau dieser Ort der am schlechtesten kontrollierte Teil der gesamten Lieferkette. Wer in die Registry schreiben kann, entscheidet, was in Produktion…
-
Continue reading →: Berechtigungs-Reviews in GitHub-Organisationen: wer darf eigentlich noch was
In den meisten GitHub-Organisationen kennt niemand mehr die vollständige Antwort auf eine einfache Frage: Wer hat gerade Zugriff worauf, und warum. Rechte werden vergeben, wenn jemand sie braucht. Zurückgenommen werden sie fast nie. Das Ergebnis ist ein stiller Rechte-Berg, der mit jedem Onboarding, jedem Projekt und jedem externen Dienstleister weiter…
-
Continue reading →: Third-Party Actions pinnen: warum SHA statt Tag und was eine Allowlist bringt
Fast jeder GitHub-Actions-Workflow zieht fremden Code. actions/checkout@v4, docker/build-push-action@v6, dazu ein Dutzend kleinerer Helfer aus dem Marketplace. Bequem, aber jede dieser Zeilen ist eine Vertrauensentscheidung. Wer @v4 schreibt, sagt damit: ich fuehre aus, was hinter diesem Tag heute steht, und auch das, was morgen dahinter steht. Genau das ist das Problem.…
-
Continue reading →: Runner-Sicherheit: Warum Self-hosted Runner ein eigenes Risiko sind
Wer GitHub Actions oder GitLab CI intensiv nutzt, stößt irgendwann auf die Grenze der gehosteten Runner: zu langsam, zu teuer bei hohem Volumen, kein Zugriff auf interne Systeme. Die Antwort heißt dann Self-hosted Runner. Was viele Teams dabei übersehen: Ein selbst betriebener Runner ist kein Werkzeug wie jedes andere. Er…
-
Continue reading →: Merkle-Trees und Transparenz-Logs: Wie Sigstore Vertrauen ohne zentrale Instanz schafft
Signaturen sollen beweisen, dass ein Artefakt von einer bestimmten Stelle stammt und seitdem nicht verändert wurde. In der Praxis scheitert das selten an der Kryptografie und fast immer am Drumherum: Schlüssel liegen jahrelang auf Build-Servern, niemand weiß, wer wann was signiert hat, und ein geleakter Key fällt erst auf, wenn…
-
Abonnieren
Abonniert
Hast du ein WordPress.com-Konto? Melde dich jetzt an.
