Dein Blog zum Thema digitales Business

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 DevOps ursprünglich gelöst hat

DevOps hat die Wand zwischen Entwicklung und Betrieb abgebaut. Statt Code über den Zaun zu werfen und auf das Ops-Team zu hoffen, teilen sich beide Seiten Verantwortung für Build, Deployment und Betrieb. Automatisierte Pipelines, Infrastructure as Code und schnelle Feedback-Schleifen sind das Ergebnis. Das Ziel war Geschwindigkeit bei gleichbleibender Stabilität.

Sicherheit war in diesem Modell oft ein separater Schritt am Ende. Ein Pentest vor dem Release, ein Audit einmal im Jahr, ein Security-Team, das spät dazukommt und Findings meldet, wenn der Code längst produktiv ist. Das funktioniert, solange niemand genau hinschaut. Sobald Kunden oder Prüfer Nachweise wollen, fällt auf, dass Sicherheit nicht Teil des Ablaufs war, sondern eine nachträgliche Kontrolle.

Was DevSecOps praktisch verändert

DevSecOps verschiebt Sicherheitsarbeit nach vorne und macht sie zum festen Bestandteil der Pipeline. Nicht als zusätzliches Gate, das alles blockiert, sondern als automatisierte Kontrolle, die bei jedem Commit mitläuft. Konkret heißt das:

• Secrets-Scanning bei jedem Push, damit Tokens gar nicht erst ins Repo gelangen.
• Dependency-Prüfung im Build, die verwundbare Pakete meldet, bevor sie deployt werden.
• Signierte Artefakte und ein Deployment-Trail, der zeigt, was wann von wem freigegeben wurde.
• Least-Privilege-Rechte für Pipeline-Runner statt breiter Admin-Tokens.

Der Unterschied ist nicht das Werkzeug, sondern der Zeitpunkt. In DevOps prüft man Sicherheit, wenn etwas fertig ist. In DevSecOps prüft die Pipeline kontinuierlich, und ein Fund stoppt den Build, bevor das Problem produktiv wird. Ein verwundbares Paket, das im Pull Request auffällt, kostet Minuten. Dasselbe Paket im Produktivsystem kostet einen Incident.

Wer die Verantwortung trägt

In klassischem DevOps liegt Sicherheit beim Security-Team, das getrennt vom Entwicklungsprozess arbeitet. In DevSecOps ist Sicherheit eine geteilte Verantwortung. Entwickler bekommen Feedback direkt in ihrem Workflow, das Security-Team baut Kontrollen in die Pipeline statt sie manuell auszuführen. Das Team wird vom Türsteher zum Werkzeugbauer.

Das ist der Punkt, an dem viele Umstellungen scheitern. DevSecOps als Tool-Einkauf zu verstehen reicht nicht. Wenn Findings weiterhin in einem separaten Ticketsystem landen, das niemand liest, ändert sich nichts. Die Kontrolle muss dort sichtbar sein, wo entwickelt wird, und sie muss den Build wirklich stoppen können.

Wann sich der Aufwand lohnt

Nicht jedes Team braucht sofort das volle Programm. Wer intern Software baut und keine externen Nachweispflichten hat, kann mit den Grundlagen anfangen. Sobald aber Kunden Sicherheitsfragebögen schicken, ein Audit ansteht oder der Cyber Resilience Act greift, wird der Unterschied konkret. Dann reicht es nicht zu sagen, dass man sicher entwickelt. Man muss es zeigen, mit Nachweisen aus der Pipeline, die nicht nachträglich zusammengesucht werden.

Die ehrliche Frage ist nicht, ob DevSecOps besser klingt, sondern ob die eigene Pipeline heute belegen kann, was wann freigegeben wurde und ob verwundbare Abhängigkeiten drin sind. Wenn die Antwort unklar ist, ist das der Ansatzpunkt.

GitSecOps QuickCheck: Wir prüfen deine GitHub- oder GitLab-Pipeline auf genau diese Punkte und zeigen in einem konkreten Befundbericht, wo Sicherheit heute nur behauptet und wo sie belegt ist. 1.990 Euro netto, Ergebnis in 3 Werktagen. Kontakt: mm@crank.zone.