-
Continue reading →: Was in einem Incident zuerst gebraucht wird: der Unterschied zwischen Logs und Nachweisen
Wenn ein Sicherheitsvorfall aufschlägt, will jeder das Gleiche wissen: Was ist passiert, was war betroffen, und ist der Zustand wieder sauber. In den ersten Stunden greifen viele Teams reflexartig zu den Logs. Das ist richtig, reicht aber nicht. Denn Logs beantworten nur die erste Frage. Die zweite und dritte Frage…
-
Continue reading →: Vier-Augen-Prinzip in der Pipeline: wann Required Reviewers wirklich greifen
Fast jede Organisation, die etwas auf Reviews hält, aktiviert irgendwann Required Reviewers: ein Pull Request braucht mindestens eine fremde Zustimmung, bevor er in den geschützten Branch darf. Auf dem Papier ist das ein Vier-Augen-Prinzip. In der Praxis greift es oft nicht, weil rund um die Regel Umgehungspfade offen bleiben, die…
-
Continue reading →: Wie ein Software-Freigabeprozess ohne Bremswirkung aussieht
Freigabeprozesse haben in vielen Teams einen schlechten Ruf. Sie gelten als das, was zwischen fertigem Code und Produktion steht: ein Ticket, das jemand abzeichnen muss, ein Meeting, das erst am Donnerstag stattfindet, eine Person, die gerade im Urlaub ist. Die Schlussfolgerung liegt dann nahe, dass Kontrolle und Geschwindigkeit sich ausschließen.…
-
Continue reading →: Cloud-Kosten und Sicherheit: wo Sparen die Angriffsfläche vergrößert
Cloud-Rechnungen sind 2026 in vielen Teams das Dauerthema. FinOps-Runden, Rightsizing, Reserved Instances, Spot-Kapazität. Das meiste davon ist sinnvoll. Ungenutzte Ressourcen abschalten spart Geld und verkleinert nebenbei die Angriffsfläche. Aber nicht jede Sparmaßnahme ist neutral. Manche senken die Rechnung heute und erhöhen den Schaden im nächsten Vorfall. Wer nur auf die…
-
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.…
-
Abonnieren
Abonniert
Have a WordPress.com account? Log in now.
