DevSecOps: Sicherheit in Entwicklung und Betrieb integrieren

Digitale Produkte, Plattformen und Services entstehen heute in kurzen Entwicklungs- und Release-Zyklen. Geschwindigkeit entscheidet über Marktfähigkeit, Nutzerakzeptanz und Wettbewerbsposition. Gleichzeitig steigen die Anforderungen an Sicherheit, Stabilität, Nachvollziehbarkeit und regulatorische Anschlussfähigkeit.

Reibung entsteht vor allem dort, wo Entwicklung, Betrieb und IT-Sicherheit organisatorisch getrennt arbeiten. Entwicklungsteams optimieren auf Funktionalität und Geschwindigkeit. Betriebsteams verantworten Stabilität und Verfügbarkeit. Sicherheitsteams werden dagegen häufig erst spät eingebunden: kurz vor dem Release, im Rahmen nachgelagerter Prüfungen oder wenn konkrete Sicherheitsmängel bereits sichtbar geworden sind.

Genau dann wird Sicherheit zur Belastung. Nicht, weil Sicherheit überflüssig wäre. Sondern weil sie zu spät kommt.
Werden Schwachstellen erst kurz vor der Produktivsetzung erkannt, entstehen Korrekturschleifen, Verzögerungen und zusätzlicher Abstimmungsaufwand. Bei grundlegenden Architektur- oder Designfragen kann der Aufwand erheblich steigen. Dann müssen nicht nur einzelne Fehler behoben werden. Schnittstellen, Berechtigungskonzepte, Abhängigkeiten oder Betriebsprozesse müssen neu bewertet und angepasst werden.

Sicherheit wird in digitalen Projekten noch immer häufig als Kontrollpunkt behandelt. Ihr größerer Wert entsteht jedoch früher: dort, wo Architekturentscheidungen getroffen, Code geschrieben, Komponenten eingebunden und Betriebsprozesse gestaltet werden.

Abbildung 1: Nachgelagerte Berücksichtigung der Sicherheit

DevSecOps integriert Sicherheitsarbeit in die Prozesse, in denen digitale Produkte geplant, entwickelt, getestet, bereitgestellt und betrieben werden. Sicherheitsanforderungen werden früher konkretisiert, technische Prüfungen stärker automatisiert und Entscheidungen nachvollziehbarer dokumentiert.

Der Kern des Ansatzes liegt darin, Sicherheit nicht nachträglich an fertige Ergebnisse anzulegen. Sicherheitsfragen werden dort geklärt, wo Architektur, Code, Builds, Deployments und Betriebsprozesse entstehen.

Abbildung 2: Entwicklungsbegleitende Integration von Sicherheit

Tools wie Code-Scanner, Dependency-Prüfungen, Container-Scans, Infrastructure-as-Code-Prüfungen oder Secrets Detection liefern dafür wichtige Hinweise. Ihr Wert zeigt sich jedoch erst, wenn diese Hinweise bewertet, priorisiert, bearbeitet und dokumentiert werden.

DevSecOps ist deshalb kein reines Toolset und keine zusätzliche Kontrollschicht. Der Ansatz beschreibt ein Betriebsmodell, mit dem Sicherheit systematischer in digitale Wertschöpfung eingebunden werden kann.

Die Einführung von DevSecOps beginnt bei der Zusammenarbeit von Entwicklung, Betrieb, Architektur und Security. Sicherheitsarbeit braucht feste Schnittstellen zu den Teams, die Systeme entwerfen, verändern und betreiben.

In klassischen Organisationsmodellen ist IT-Sicherheit häufig als externe Prüf- oder Kontrollinstanz angelegt. Dieses Modell hat seinen Platz, stößt in agilen Entwicklungsumgebungen aber schnell an Grenzen. Wer erst am Ende prüft, kann oft nur noch beanstanden. Gestaltung ist dann nur mit hohem Aufwand möglich.

DevSecOps verschiebt diese Rolle. Sicherheitsteams werden früher in Planungs-, Architektur- und Betriebsentscheidungen eingebunden. Ihre Rolle entwickelt sich von der späten Prüfinstanz hin zum integrierten Partner innerhalb der Wertschöpfungskette.

Abbildung 3: Verzahnung von IT-Sicherheit, Entwicklung und Betrieb

Diese Verzahnung schafft ein besseres Verständnis für technische Abhängigkeiten, Sicherheitsanforderungen und operative Risiken. Sicherheitsexperten können Anforderungen konkretisieren, Architekturentscheidungen bewerten und bei der Umsetzung geeigneter Maßnahmen unterstützen.

Ein zentraler Erfolgsfaktor ist Akzeptanz. Sicherheitsmaßnahmen entfalten Wirkung, wenn sie fachlich sinnvoll und im Arbeitsfluss der Teams umsetzbar sind. Ohne Akzeptanz bleibt Sicherheit formal richtig, aber praktisch schwach.

DevSecOps setzt genau an dieser Stelle an: Sicherheit wird nicht nur geprüft, sondern anschlussfähig gemacht.

Ein zentrales Prinzip von DevSecOps ist „Shift Left“. Sicherheitsbetrachtungen, Risikoanalysen und Prüfverfahren werden möglichst früh im Entwicklungsprozess angesetzt.
Statt Sicherheitsmängel erst kurz vor dem Go-live zu identifizieren, werden Anforderungen bereits in Planung, Architektur, Coding, Build und Test berücksichtigt. Dadurch lassen sich Fehlentscheidungen früher erkennen und meist mit geringerem Aufwand korrigieren.

Abbildung 4: DevSecOps-Infinity-Loop

Im Entwicklungsanteil des DevSecOps-Zyklus sind vor allem drei Phasen relevant.

Bereits in der Planungs- und Architekturphase sollten Schutzbedarfe, Sicherheitsleitplanken und relevante Risiken betrachtet werden. Methoden wie Threat Modeling helfen, mögliche Angriffspfade, Schwachstellen und Abhängigkeiten sichtbar zu machen, bevor Architekturentscheidungen festgeschrieben sind.

Auch regulatorische und organisatorische Anforderungen sollten nicht als abstrakte Vorgabe am Ende des Projekts erscheinen. Sie müssen früh in technische und organisatorische Leitplanken übersetzt werden.

Während der Entwicklung unterstützen Peer Reviews, sichere Coding-Standards und direkte Security-Beratung dabei, Schwachstellen früh zu reduzieren. Wiederverwendbare Muster, sichere Referenzarchitekturen und klare Leitlinien helfen Teams, Sicherheitsanforderungen praktisch umzusetzen.

Der Nutzen entsteht vor allem dann, wenn Entwicklungsteams nicht nur Prüfanforderungen erhalten, sondern konkrete Unterstützung bei Architektur, Designentscheidungen und Umsetzungsfragen.

Automatisierte Sicherheitsprüfungen in CI/CD-Pipelines können das Risiko reduzieren, dass unsichere Komponenten unbemerkt integriert werden. Dazu gehören beispielsweise:

• statische Codeanalysen,
• Dependency-Scans,
• Container-Prüfungen,
• Secrets Detection,
• Infrastructure-as-Code-Prüfungen,
• Prüfungen gegen definierte Sicherheits-Baselines.

Automatisierung allein löst das Problem jedoch nicht. Prüfergebnisse müssen dort ankommen, wo sie bearbeitet werden können. Risiken müssen priorisiert, Verantwortlichkeiten zugeordnet und Korrekturen nachvollziehbar dokumentiert werden.

Ein Fail-Fast-Prinzip macht Fehler früher sichtbar, wenn Korrekturen meist noch mit geringerem Release-Risiko möglich sind.

DevSecOps endet nicht mit der Entwicklung. Auch der Betrieb muss systematisch einbezogen werden. Sichere Administrationswege, Protokollierung, Detektion, Monitoring und kontrollierte Deployments gehören zu einer sicheren Betriebsumgebung.

Im Betrieb geht es vor allem um drei Fragen.

Kontinuierliche Überwachung und Anomalieerkennung unterstützen eine schnellere Reaktion auf sicherheitsrelevante Ereignisse. SIEM-Systeme können Ereignisse bündeln und auswertbar machen. Sie ersetzen aber nicht klare Zuständigkeiten, Eskalationswege und Reaktionsprozesse.

Kontrollierte Deployment-Prozesse reduzieren das Risiko, dass ungeprüfte oder nicht freigegebene Stände in produktive Umgebungen gelangen. Dazu gehören nachvollziehbare Freigaben, definierte Rollback-Verfahren und eine klare Trennung zwischen Entwicklungs-, Test- und Produktionsumgebungen.

Wichtig ist dabei: Eine Pipeline stellt nicht automatisch regulatorische Konformität her. Sie kann aber helfen, definierte Sicherheits- und Freigabekriterien vor dem Rollout systematisch zu prüfen.

Moderne Softwareentwicklung basiert häufig auf Open-Source-Komponenten, externen Bibliotheken, Containern, Build-Artefakten und automatisierten Deployment-Prozessen. Software Supply Chain Security umfasst daher unter anderem die Prüfung externer Komponenten, den Umgang mit Schwachstellen in Abhängigkeiten, den Schutz von Secrets und die Nachvollziehbarkeit eingesetzter Artefakte.

Gerade hier zeigt sich der Wert von DevSecOps: Sicherheitsprüfungen werden nicht als Sonderprozess behandelt, sondern in bestehende Entwicklungs- und Betriebsabläufe eingebettet.

Threat Modeling macht Sicherheitsrisiken früher diskutierbar. Teams betrachten mögliche Angriffspfade, Schwachstellen, Abhängigkeiten und Schutzmaßnahmen bereits in Planung und Architektur.

Der Nutzen liegt weniger im Workshopformat selbst als in der gemeinsamen Entscheidungsvorbereitung: Welche Risiken sind relevant? Welche Maßnahmen sind angemessen? Was wird umgesetzt, akzeptiert oder eskaliert?

Gamification kann solche Analysen zugänglicher machen, wenn sie methodisch sauber eingesetzt wird. Der spielerische Anteil ist kein Selbstzweck. Er hilft, Beteiligung zu erhöhen, Perspektiven zu wechseln und Bedrohungsszenarien gemeinsam zu durchdenken.

Eine Maßnahme, die aus einer gemeinsamen Architektur- und Bedrohungsanalyse entsteht, hat eine andere Qualität als ein Finding kurz vor dem Release. Sie ist fachlich besser verankert, im Team meist akzeptierter und näher an der tatsächlichen Systemrealität.

Deshalb ist Threat Modeling kein zusätzlicher Workshop um des Workshops willen. Es ist ein Mittel, um Sicherheitsentscheidungen früher, konkreter und gemeinsamer zu treffen.

DevSecOps ist besonders relevant, wenn Unternehmen digitale Produkte, Plattformen oder IT-Services mit kurzen Release-Zyklen entwickeln und betreiben.

Typische Ausgangssituationen sind:

• Entwicklung und Betrieb arbeiten organisatorisch getrennt.
• Sicherheitsprüfungen erfolgen erst spät im Projekt.
• CI/CD-Prozesse bestehen bereits, Sicherheitsprüfungen sind aber nur teilweise integriert.
• Schwachstellen führen regelmäßig zu späten Korrekturschleifen.
• Entwicklungsteams empfinden Security-Anforderungen als zusätzliche Belastung.
• IT-Leitung oder Security-Verantwortliche benötigen mehr Transparenz über Umsetzungsstände.
• Software-Supply-Chain-Risiken werden bisher nur punktuell betrachtet.
• Operative Sicherheitskonzepte entstehen getrennt von Architektur und Entwicklung.

In solchen Situationen schafft DevSecOps einen Rahmen, um Sicherheitsanforderungen früher, konkreter und überprüfbarer in Entwicklung und Betrieb einzubinden.

Die Anzahl der eingesetzten Tools sagt dabei wenig über die Qualität des Ansatzes aus. Wichtiger sind geklärte Rollen, passende Prozesse, sinnvolle Automatisierung und eine Arbeitsweise, in der Prüfergebnisse tatsächlich bearbeitet werden.

Sicherheit entfaltet ihren größten Nutzen während der Entstehung digitaler Produkte und Services. DevSecOps schafft dafür einen organisatorischen und methodischen Rahmen.

Der Ansatz verbindet Sicherheitsanforderungen mit den Prozessen, in denen digitale Produkte geplant, entwickelt, getestet, bereitgestellt und betrieben werden. Dadurch entstehen klarere Zuständigkeiten, frühere Risikoerkennung, bessere Nachvollziehbarkeit und höhere Akzeptanz in den Teams.

Der Vorteil liegt nicht allein in weniger Findings kurz vor dem Release. Der größere Effekt entsteht, wenn Sicherheit zu einem produktiven Bestandteil digitaler Wertschöpfung wird: Risiken werden früher sichtbar, Releases planbarer und Sicherheitsentscheidungen besser begründbar.

Für Unternehmen bedeutet das weniger Reibung zwischen Sicherheit, Entwicklung und Betrieb. Sicherheitsfragen werden früher geklärt, späte Korrekturen reduziert und digitale Produkte nachvollziehbarer bereitgestellt.

Der strategische Nutzen reicht weiter: Sicherheit wird nicht mehr nachträglich angehängt, sondern in der digitalen Wertschöpfung mitproduziert. Genau darin liegt der Kern von DevSecOps.

Wie DevSecOps ISMS, Governance und Nachweisfähigkeit unterstützen kann, betrachten wir im Beitrag „DevSecOps und ISMS: Sicherheitsanforderungen operativ umsetzen“.