-
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…
-
Continue reading →: Software Composition Analysis: Abhängigkeiten kennen, bevor es der Angreifer tut
Der Code, den Ihr Team selbst schreibt, ist in den meisten Projekten die Minderheit. 70 bis 90 Prozent einer typischen Anwendung bestehen aus Open-Source-Abhängigkeiten. Wer diese Abhängigkeiten nicht kennt, kennt seine Angriffsfläche nicht. Genau hier setzt Software Composition Analysis an, kurz SCA. Was SCA konkret macht SCA-Werkzeuge inventarisieren alle Bibliotheken…
-
Abonnieren
Abonniert
Have a WordPress.com account? Log in now.
