-
Continue reading →: Runner-Sicherheit: Warum Self-hosted Runner ein eigenes Risiko sind
Wer GitHub Actions oder GitLab CI intensiv nutzt, stößt irgendwann auf die Grenze der gehosteten Runner: zu langsam, zu teuer bei hohem Volumen, kein Zugriff auf interne Systeme. Die Antwort heißt dann Self-hosted Runner. Was viele Teams dabei übersehen: Ein selbst betriebener Runner ist kein Werkzeug wie jedes andere. Er…
-
Continue reading →: Merkle-Trees und Transparenz-Logs: Wie Sigstore Vertrauen ohne zentrale Instanz schafft
Signaturen sollen beweisen, dass ein Artefakt von einer bestimmten Stelle stammt und seitdem nicht verändert wurde. In der Praxis scheitert das selten an der Kryptografie und fast immer am Drumherum: Schlüssel liegen jahrelang auf Build-Servern, niemand weiß, wer wann was signiert hat, und ein geleakter Key fällt erst auf, wenn…
-
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 und Renovate: automatische Updates richtig einsetzen
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. Was beide Tools…
-
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…
-
Abonnieren
Abonniert
Du hast bereits ein WordPress.com-Konto? Melde dich jetzt an.
Dein Blog zum Thema digitales Business 