-
Continue reading →: Software Composition Analysis: Abhängigkeiten kennen, bevor es der Angreifer tut
Der Code, den Ihr Team selbst schreibt, ist in den meisten Projekten die Minderheit. 70 bis 90 Prozent einer typischen Anwendung bestehen aus Open-Source-Abhängigkeiten. Wer diese Abhängigkeiten nicht kennt, kennt seine Angriffsfläche nicht. Genau hier setzt Software Composition Analysis an, kurz SCA. Was SCA konkret macht SCA-Werkzeuge inventarisieren alle Bibliotheken…
-
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…
-
Abonnieren
Abonniert
Hast du ein WordPress.com-Konto? Melde dich jetzt an.
