-
Continue reading →: Technische Schulden in der Pipeline: wie man sie sichtbar macht
Technische Schulden kennt jedes Team aus dem Anwendungscode. In Build, Test und Deployment entstehen sie genauso. Nur fallen sie dort seltener auf, weil niemand auf die Pipeline schaut, solange sie grün ist. Das Problem zeigt sich erst, wenn ein Build bricht, ein Deployment hängt oder ein Prüfer nach Nachweisen fragt.…
-
Continue reading →: Warum Sicherheitswerkzeuge scheitern, wenn niemand für die Befunde zuständig ist
Ein neuer Scanner ist schnell eingeführt. Ein Klick in der Pipeline, ein Report erscheint, und plötzlich stehen dreihundert Befunde auf einer Liste. Das fühlt sich nach Fortschritt an. Sechs Wochen später ist die Liste auf achthundert gewachsen, niemand hat sie gelesen, und die Sicherheit ist keinen Schritt besser. Das Werkzeug…
-
Continue reading →: Was hinter „Stand der Technik“ im Kundenvertrag steckt
Immer mehr Softwareverträge enthalten eine Klausel, die verlangt, dass der Anbieter seine Systeme nach dem „Stand der Technik“ absichert. Der Satz klingt harmlos und wird oft überlesen. Er verschiebt aber die Beweislast: Wer unterschreibt, verpflichtet sich zu einem Sicherheitsniveau, das nicht der Vertrag definiert, sondern die Fachwelt. Und der bewegt…
-
Continue reading →: Von der Excel-Liste zum SBOM: der pragmatische Einstieg für kleine Teams
Fast jedes kleine Softwareteam hat eine Liste seiner Abhängigkeiten. Sie steht in einer Excel-Tabelle, in einer README oder im Kopf des Entwicklers, der am längsten dabei ist. Diese Liste ist der Anfang einer Software-Stückliste. Der Schritt zum echten SBOM ist kleiner, als die Abkürzung vermuten lässt. Er lohnt sich, sobald…
-
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…