-
Continue reading →: Arbeitszeugnisse rechtssicher gestalten: Ein Leitfaden für ArbeitgeberDas Arbeitszeugnis ist nicht nur ein formeller Abschluss eines Arbeitsverhältnisses, sondern ein entscheidendes Dokument, das das berufliche Weiterkommen eines Mitarbeiters maßgeblich beeinflussen kann. In diesem Ratgeber erhalten Arbeitgeber wertvolle Einblicke, wie sie rechtssichere und aussagekräftige Arbeitszeugnisse erstellen können.
-
Continue reading →: Build-Caches als Angriffsfläche: warum ein vergifteter Cache alle Builds betrifft
Build-Caches sind ein Standardwerkzeug, um Pipelines schneller zu machen. Statt Abhängigkeiten, kompilierte Zwischenstände oder Docker-Layer bei jedem Lauf neu zu erzeugen, werden sie gespeichert und wiederverwendet. Das spart Minuten pro Build und bei vielen Läufen am Tag summiert sich das. Der Preis dafür wird selten benannt: Ein Cache ist geteilter,…
-
Continue reading →: Secret Scanning und Push Protection: Tokens stoppen, bevor sie in die Historie kommen
Ein Token, das einmal committet wurde, ist nicht weg, wenn du es im nächsten Commit löschst. Es steht in der Historie, und die kann jeder auslesen, der Zugriff auf das Repo hat oder bekommt. Wie schnell ein Angreifer genau das findet, haben wir aus der Außensicht beschrieben. Dieser Beitrag dreht…
-
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.…