-
Continue reading →: Dependabot vs. Renovate: welches Update-Tool wofür (Stand 2026)
Veraltete Abhängigkeiten sind der häufigste Weg, über den Schwachstellen in Software gelangen. Nicht der eigene Code, sondern die 300 Pakete darunter. Automatische Update-Tools wie Dependabot und Renovate lösen genau dieses Problem. Trotzdem scheitert die Einführung in vielen Teams. Nicht am Tool, sondern an der fehlenden Strategie dahinter. Stand dieses Vergleichs:…
-
Continue reading →: Monorepo vs Polyrepo aus Sicherheitssicht
Die Frage Monorepo oder Polyrepo wird meist als Organisations- und Tooling-Frage diskutiert. Aus Sicherheitssicht ist sie mindestens genauso relevant. Wer alle Projekte in einem Repository hält, trifft andere Risikoentscheidungen als jemand, der hundert kleine Repositories betreibt. Beide Modelle haben blinde Flecken, und die meisten Teams kennen ihre eigenen nicht. Zugriffsrechte:…
-
Continue reading →: Was ein Audit-fähiger Freigabeprozess in der Pipeline braucht
Jede Softwareorganisation hat einen Freigabeprozess. Irgendjemand entscheidet, dass ein Stand in Produktion geht. Die Frage im Audit lautet aber nicht, ob es diesen Prozess gibt. Sie lautet: Kannst du für ein beliebiges Release vom letzten Jahr zeigen, wer freigegeben hat, auf welcher Grundlage und ob die Regel technisch erzwungen war?…
-
Continue reading →: Provenance und Attestation: woher ein Artefakt wirklich stammt
Ein fertiges Build-Artefakt sieht immer gleich aus: eine Datei, ein Container-Image, ein Paket. Was man ihm nicht ansieht, ist die Frage, die im Ernstfall zählt. Aus welchem Commit ist es entstanden, welche Pipeline hat es gebaut, mit welchen Abhängigkeiten. Provenance und Attestation beantworten genau das. Sie machen die Herkunft eines…
-
Continue reading →: DevSecOps vs DevOps: was der Unterschied praktisch bedeutet
DevOps und DevSecOps klingen nach einer Marketing-Umbenennung, sind aber zwei verschiedene Betriebsmodelle. Der Unterschied zeigt sich nicht in der Definition, sondern darin, an welcher Stelle in der Pipeline Sicherheit passiert und wer sie verantwortet. Wer beide Begriffe synonym nutzt, verschiebt Sicherheitsarbeit meist ans Ende, wo sie am teuersten ist. Was…
-
Continue reading →: Infrastructure as Code absichern: die häufigsten Terraform-Fehlkonfigurationen
Infrastructure as Code hat einen einfachen Vorteil: Server, Netzwerke und Datenbanken entstehen nicht mehr per Klick in einer Weboberfläche, sondern aus versioniertem Code. Wer Terraform einsetzt, bekommt reproduzierbare Umgebungen und einen nachvollziehbaren Verlauf. Der gleiche Mechanismus verteilt aber auch Fehler zuverlässig. Eine falsch gesetzte Zeile landet nicht auf einem Server,…
-
Continue reading →: Vulnerability Management: vom CVE-Report zur Priorisierung
Ein Schwachstellen-Scanner findet hunderte CVEs in einer durchschnittlichen Codebasis. Die meisten Teams kippen diese Liste in ein Ticket-System und arbeiten sie von oben nach unten ab. Das ist der falsche Weg. Vulnerability Management beginnt nicht mit dem Scan, sondern mit der Frage, welche der gefundenen Schwachstellen in eurem konkreten System…
-
Continue reading →: Least Privilege in der Pipeline: Rechte, die niemand braucht
Die meisten CI/CD-Pipelines laufen mit weit mehr Rechten, als sie für ihre Arbeit brauchen. Ein Job, der nur Tests ausführt, hat plötzlich Schreibzugriff auf das Repository, kann Releases anlegen und liest jedes Secret im Projekt. Niemand hat das so geplant. Es ist über die Zeit gewachsen, weil ein breiter Token…
-
Continue reading →: Code Review als Sicherheitskontrolle, nicht als Formalakt
In vielen Teams ist das Code Review zur Pflichtübung geworden. Jemand klickt auf Approve, der Pull Request geht durch, niemand hat wirklich hingeschaut. Das Häkchen ist gesetzt, der Prozess sieht sauber aus, und genau hier entsteht das Risiko. Ein Review, das nur eine Freigabe abnickt, fängt keine Schwachstelle ab. Es…
-
Continue reading →: Reproducible Builds: Warum derselbe Code zweimal dasselbe Artefakt ergeben sollte
Sie bauen heute aus einem bestimmten Commit ein Artefakt. Nächste Woche bauen Sie aus demselben Commit erneut. Kommt exakt dieselbe Datei heraus, Byte für Byte? Bei den meisten Pipelines lautet die ehrliche Antwort: niemand weiß es. Genau das ist das Problem, das Reproducible Builds lösen. Was ein reproduzierbarer Build bedeutet…
-
Abonnieren
Abonniert
Have a WordPress.com account? Log in now.
