-
Continue reading →: Berechtigungs-Reviews in GitHub-Organisationen: wer darf eigentlich noch was
In den meisten GitHub-Organisationen kennt niemand mehr die vollständige Antwort auf eine einfache Frage: Wer hat gerade Zugriff worauf, und warum. Rechte werden vergeben, wenn jemand sie braucht. Zurückgenommen werden sie fast nie. Das Ergebnis ist ein stiller Rechte-Berg, der mit jedem Onboarding, jedem Projekt und jedem externen Dienstleister weiter…
-
Continue reading →: Third-Party Actions pinnen: warum SHA statt Tag und was eine Allowlist bringt
Fast jeder GitHub-Actions-Workflow zieht fremden Code. actions/checkout@v4, docker/build-push-action@v6, dazu ein Dutzend kleinerer Helfer aus dem Marketplace. Bequem, aber jede dieser Zeilen ist eine Vertrauensentscheidung. Wer @v4 schreibt, sagt damit: ich fuehre aus, was hinter diesem Tag heute steht, und auch das, was morgen dahinter steht. Genau das ist das Problem.…
-
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 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…
-
Abonnieren
Abonniert
Hast du ein WordPress.com-Konto? Melde dich jetzt an.
