-
Continue reading →: Forks und private Repos: warum eine Kopie Rechte mitnimmt, die niemand geplant hat
Ein Fork wirkt harmlos. Jemand kopiert ein Repository, um in Ruhe etwas auszuprobieren, ohne den Hauptzweig zu stören. In der Praxis entsteht damit oft eine zweite Kopie des Codes, die niemand mehr im Blick hat und die Zugriffe mitbringt, die im Original längst geregelt waren. Wer Rechte in GitHub sauber…
-
Continue reading →: Warum „wir sind zu klein für Angriffe“ bei Lieferketten nicht mehr stimmt
Der Satz fällt in fast jedem Erstgespräch: „Uns greift doch keiner an, wir sind viel zu klein.“ Das war nie ganz richtig, und bei Software-Lieferketten stimmt es heute gar nicht mehr. Wer Code baut und ausliefert, ist Teil einer Kette. Und Angreifer suchen nicht mehr das größte Ziel, sondern das…
-
Continue reading →: Offboarding in GitHub: die Checkliste für den sauberen Zugangsentzug
Jemand verlässt das Team. Der Laptop wird eingezogen, das Postfach deaktiviert, der Chat-Zugang gesperrt. Und der GitHub-Zugang? Der bleibt in vielen Firmen noch Wochen bestehen, weil niemand genau weiß, woran er überall hängt. Genau in dieser Lücke entsteht das Risiko. Ein ehemaliger Entwickler mit weiter gültigem Token liest still den…
-
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…
-
Abonnieren
Abonniert
Du hast bereits ein WordPress.com-Konto? Melde dich jetzt an.
Dein Blog zum Thema digitales Business 