Ein neues Architektur- und Betriebsmodell für durchgängige Cyberresilienz

Illustration Absmeier foto ki designer

DevSecResOps © verbindet sichere Softwarebereitstellung, laufende Überwachung und vertrauenswürdige Wiederherstellung zu einem gemeinsamen Betriebsmodell.

DevSecOps beschleunigt die sichere Bereitstellung digitaler Produkte. Resilience Operations, kurz ResOps, sorgt dafür, dass geschäftskritische Dienste auch unter Störung kontrolliert weiterlaufen oder rasch wiederhergestellt werden. DevSecResOps © führt beide Disziplinen zu einem gemeinsamen Architekturprinzip zusammen: Sicherheit, Betriebsfähigkeit und Wiederherstellbarkeit werden von Beginn an entworfen, automatisiert geprüft und im laufenden Betrieb kontinuierlich verbessert.

Management Summary

DevSecResOps erweitert das Zielbild: Nicht nur sicher ausliefern, sondern Angriffe, Ausfälle und Fehlkonfigurationen beherrschen und nachweisbar wiederherstellen.
Resilienz wird zur Architektureigenschaft: Wiederanlaufziele, Abhängigkeiten, saubere Wiederherstellungspunkte und alternative Betriebswege fließen in Entwurf und Backlog ein.
Eine gemeinsame Kontrollkette verbindet Build und Run: Code, Artefakte, Konfigurationen, Telemetrie, Backups und Recovery-Pläne werden versioniert, geprüft und korreliert.
Automatisierung braucht sichere Leitplanken: Pipelines prüfen nicht nur Schwachstellen, sondern auch Wiederherstellbarkeit, Datenintegrität und die Wirksamkeit von Notfallverfahren.
Erfolg misst sich am Geschäftsdienst: Entscheidend sind unter anderem Wiederherstellungszeit, tolerierbarer Datenverlust, Änderungsrisiko und die Dauer bis zu einer belastbaren Lageeinschätzung.

Vom Shift Left zum durchgängigen Resilienzzyklus

Für den täglichen Betrieb gilt ein risikobasierter Mindestumfang. Nicht jede Kontrolle wird bei jeder Änderung vollständig ausgeführt. Kritische Dienste benötigen automatisierte Basisprüfungen in der Pipeline, aktuelle Betriebs- und Recovery-Anweisungen sowie regelmäßig geplante Restore- und Störungstests. Aufwendige Clean-Room-Wiederherstellungen, Angriffssimulationen und vollständige End-to-End-Übungen werden nach Kritikalität, Änderungsrisiko und regulatorischen Anforderungen terminiert. Ausnahmen erhalten einen Eigentümer, eine Begründung und ein Ablaufdatum.

DevSecOps hat die Sicherheitsarbeit näher an Architektur, Entwicklung und Auslieferung gerückt. Bedrohungsmodellierung, automatisierte Tests, Richtlinien als Code und abgesicherte Lieferketten sollen verhindern, dass Risiken erst kurz vor dem Go-live sichtbar werden. Das Prinzip ist unverzichtbar, beantwortet aber nur einen Teil der betrieblichen Realität. Auch gut entwickelte Systeme können durch unbekannte Schwachstellen, kompromittierte Identitäten, fehlerhafte Änderungen, Ausfälle von Abhängigkeiten oder gezielte Datenmanipulation beeinträchtigt werden.

ResOps setzt an diesem Punkt an. Die Disziplin verbindet Security, IT-Betrieb, Plattformteams, Daten- und Backup-Verantwortliche sowie Fachbereiche in abgestimmten Abläufen. Im Mittelpunkt stehen belastbare Daten, die Eindämmung von Vorfällen, kontinuierlich validierte Recovery-Verfahren und ein Wiederanlauf entlang geschäftlicher Prioritäten. DevSecResOps verknüpft diese Perspektive mit DevSecOps und schließt damit die Lücke zwischen sicherer Veränderung und sicherer Wiederherstellung.

Was DevSecResOps bedeutet

DevSecResOps ist ein Architektur- und Betriebsprinzip für digitale Dienste. Es ergänzt bestehende DevSecOps-, Security-, Betriebs- und Wiederherstellungsprozesse, indem vier Fähigkeiten gemeinsam geplant werden: Veränderungen reproduzierbar bereitstellen, Risiken früh erkennen, Störungen begrenzen und den vertrauenswürdigen Betrieb kontrolliert wiederherstellen. Jede Änderung soll deshalb risikoadäquat nicht nur auf Funktion und Sicherheit, sondern auch auf Beobachtbarkeit, Reversibilität und Wiederanlauffähigkeit geprüft werden.

Gegenüber klassischem DevSecOps erweitert sich der betrachtete Verantwortungsbereich über die erfolgreiche Bereitstellung hinaus bis zur nachweisbaren Funktionsfähigkeit des Dienstes unter realistischen Störungen. Gegenüber traditionellem Notfallmanagement beginnt die Resilienzarbeit früher: nicht erst mit Runbooks und Wiederanlaufplänen, sondern bereits bei Anforderungen, Datenmodellen, Schnittstellen und Deployment-Strategien. Die organisatorische Verantwortung bleibt dabei auf Produkt-, Plattform-, Security-, Betriebs- und Fachverantwortliche verteilt.

Sieben Architekturprinzipien

Geschäftsdienste statt Einzelsysteme betrachten. Schutzbedarf, Abhängigkeiten und Wiederanlaufreihenfolge werden aus Sicht eines End-to-End-Dienstes modelliert.
Secure, observable and recoverable by design. Sicherheitskontrollen, Telemetrie, Isolation, Datenwiederherstellung und alternative Betriebswege gehören in die Architekturentscheidung.
Unveränderlichkeit und Nachweisbarkeit. Artefakte, Konfigurationen, Protokolle und geschützte Wiederherstellungspunkte müssen manipulationsgeschützt und revisionsfähig sein.
Explizite Degradationsmodi. Dienste definieren, welche Kernfunktionen bei Teilstörungen verfügbar bleiben, welche Schnittstellen abgeschaltet und welche Daten nur lesend bereitgestellt werden.
Automatisierung mit kontrollierter Rückfallebene. Systeme dürfen automatisiert reagieren, benötigen aber nachvollziehbare Freigaben, Abbruchkriterien und manuelle Notverfahren.
Zero Trust auch für Recovery. Wiederherstellungsumgebungen dürfen kompromittierten Identitäten, Images oder Konfigurationen nicht ungeprüft vertrauen.
Kontinuierliche Validierung. Architekturannahmen werden durch Restore-Tests, Game Days, Chaos-Experimente und Angriffssimulationen regelmäßig überprüft.

Die Referenzarchitektur: vier eng gekoppelte Ebenen

1. Produkt- und Anwendungsebene

Auf dieser Ebene werden Missbrauchsszenarien, Datenklassifikation, Fehlergrenzen und Wiederanlaufziele als Anforderungen formuliert. Anwendungen verwenden definierte Identitäts- und Geheimnisdienste, liefern strukturierte Telemetrie und unterstützen sichere Rücksetz- oder Roll-forward-Verfahren. Kritische Transaktionen benötigen Idempotenz, konsistente Wiederholbarkeit und überprüfbare Kompensationsmechanismen.

2. Plattform- und Lieferkettenebene

Die Plattform stellt gehärtete Laufzeitumgebungen, standardisierte Deployments, signierte Artefakte, Richtlinien als Code und isolierte Sicherungsräume bereit. Build-Provenienz, Komponentenverzeichnisse und freigegebene Basiskonfigurationen schaffen Transparenz. Progressive Auslieferung, Feature Flags und automatisierte Rollbacks begrenzen den Radius fehlerhafter Änderungen.

3. Daten- und Recovery-Ebene

Backups allein reichen nicht. DevSecResOps fordert klassifizierte Datenbestände, unveränderbare Sicherungskopien, getrennte Vertrauensdomänen, regelmäßige Integritätsprüfungen und wiederholbare Wiederherstellung. Ein Clean Room ermöglicht die Analyse und den Neuaufbau kritischer Systeme, ohne kompromittierte Komponenten ungeprüft zu übernehmen.

4. Steuerungs- und Beobachtungsebene

Richtlinien definieren, wann ein Deployment gestoppt, ein Dienst isoliert, ein Wiederherstellungspunkt verworfen oder ein Krisenstab aktiviert wird. Automatische Maßnahmen werden auf reversible, vorab getestete Reaktionen mit belastbaren Signalen begrenzt. Maßnahmen mit hoher Geschäftswirkung erfordern eine benannte Entscheidungsrolle, dokumentierte Abbruchkriterien und einen manuellen Rückfallweg.

Der DevSecResOps-Lebenszyklus

Planen: Produktverantwortliche, Architektur, Security und Betrieb definieren gemeinsam Schutzbedarf, tolerierbare Ausfallzeiten, tolerierbaren Datenverlust, Degradationsmodi und regulatorische Nachweise. Diese Vorgaben werden als überprüfbare Akzeptanzkriterien in Epics und Stories übersetzt.

Entwickeln und bauen: Quellcode, Infrastrukturdefinitionen, Identitätsrichtlinien und Recovery-Automationen werden versioniert. Prüfungen umfassen Code- und Komponentenanalyse, Geheimniserkennung, Signaturkontrollen, Konfigurationsregeln sowie Tests auf Wiederholbarkeit und sichere Fehlerbehandlung.

Testen und bereitstellen: Neben Funktions- und Sicherheitstests werden Fehlerbilder, Datenkorruption, Ausfall von Abhängigkeiten und der Wiederaufbau aus geschützten Kopien geprüft. Deployments erfolgen schrittweise; beobachtete Risiken können die Auslieferung automatisch stoppen oder eine Rückkehr zur letzten vertrauenswürdigen Version auslösen.

Betreiben, reagieren und lernen: Laufzeitüberwachung erkennt Abweichungen und bewertet deren Dienstwirkung. Im Vorfall arbeiten Entwicklung, Plattform, Security Operations und Recovery-Verantwortliche in einem gemeinsamen Takt. Erkenntnisse fließen anschließend als neue Kontrollen, Architekturentscheidungen und Tests zurück in den Backlog.

Von der CI/CD-Pipeline zur Resilience Pipeline

Kontrollpunkt	Prüffrage	Beispiel für Evidenz
Design	Sind Bedrohungen, Abhängigkeiten und Wiederanlaufziele dokumentiert?	Architekturentscheidung, Datenfluss, Dienstlandkarte
Build	Ist das Artefakt vertrauenswürdig und reproduzierbar?	Signatur, Provenienz, Komponentenverzeichnis
Pre-Release	Funktioniert der Dienst bei Teilstörungen und lässt er sich sauber zurücksetzen?	Fehlertest, Rollback-Protokoll, Restore-Nachweis
Deployment	Kann eine riskante Änderung früh begrenzt werden?	Canary-Metriken, Freigaberegeln, Abbruchkriterien
Run	Werden Angriffe, Fehlzustände und Datenabweichungen rechtzeitig erkannt?	Telemetrieabdeckung, Alarmqualität, Dienststatus
Recovery	Ist der gewählte Wiederherstellungspunkt nach den verfügbaren Integritätsprüfungen, Erkennungsregeln und Untersuchungsbefunden hinreichend vertrauenswürdig, und ist das verbleibende Risiko dokumentiert?	Integritätsprüfung, Malware-Analyse, Clean-Room-Freigabe

Operating Model: gemeinsame Verantwortung ohne Zuständigkeitslücken

DevSecResOps verlangt keine Auflösung bestehender Teams, wohl aber eine gemeinsame Ergebnisverantwortung mit eindeutigen Entscheidungsrechten. Produktteams verantworten die Resilienzeigenschaften ihres Dienstes. Plattformteams liefern sichere Standardpfade und Wiederherstellungsbausteine. Security definiert risikobasierte Leitplanken und unterstützt die Untersuchung. Eine klar benannte Recovery-Funktion koordiniert Datenintegrität, Wiederanlauf und Validierung. Fachbereiche priorisieren kritische Geschäftsprozesse, genehmigen zulässige Degradationen und erteilen die Geschäftsfreigabe für den Wiederanlauf.

Praktisch eignet sich ein föderiertes Modell: Ein kleines Enablement-Team pflegt Referenzarchitektur, Kontrollkatalog, Metriken und wiederverwendbare Übungsszenarien. Domänenteams setzen diese Vorgaben risikoadäquat um. Ein Resilience Review prüft kritische Dienste und wesentliche Ausnahmen in einem zur Kritikalität passenden Rhythmus; operative Detailfragen verbleiben in den bestehenden Produkt- und Betriebsprozessen. Im Vorfall gilt ein vorher festgelegtes Entscheidungsmodell für Isolation, Wiederherstellung und Geschäftsfreigabe.

Die wichtigsten Artefakte

Service Resilience Profile: Kritikalität, Eigentümer, Abhängigkeiten, Schutzbedarf, Wiederanlaufziele und zulässige Degradationen.
Resilience Backlog: priorisierte Maßnahmen aus Bedrohungsmodellen, Vorfällen, Restore-Tests und Architekturabweichungen.
Golden Recovery Path: getesteter Standardablauf für Isolation, Identitätsneustart, Datenprüfung, Wiederaufbau und Geschäftsfreigabe.
Evidence Store: manipulationsgeschützte Sammlung von Entscheidungen, Prüfergebnissen, Artefaktprovenienz und Recovery-Nachweisen.
Dependency Graph: aktuelle Darstellung technischer und geschäftlicher Abhängigkeiten einschließlich externer Dienste.
Resilience Scorecard: wenige, gemeinsam interpretierte Kennzahlen für Leitung, Produktteams und Betrieb.

Kennzahlen, die Verhalten steuern

Ein DevSecResOps-Kennzahlensystem darf weder die Zahl gefundener Schwachstellen noch eine isolierte Verfügbarkeitsquote zum Hauptziel machen. Sinnvoll ist ein ausgewogener Satz aus Veränderungs-, Sicherheits- und Wiederherstellungsmetriken: Anteil kritischer Dienste mit validiertem Recovery-Pfad, Zeit bis zur belastbaren Lageeinschätzung, Zeit bis zur Eindämmung, tatsächliche Wiederherstellungszeit, erreichter Datenstand, Erfolgsquote von Restore-Tests, Anteil signierter Artefakte, Richtlinienausnahmen, Abdeckungsgrad der Telemetrie und Änderungsfehlerquote.

Wichtig ist die gemeinsame Interpretation. Eine kurze Wiederherstellungszeit ist nur dann wertvoll, wenn der wiederhergestellte Zustand integer ist. Eine hohe Deployment-Frequenz ist nur dann ein Fortschritt, wenn Änderungen kontrolliert begrenzt und zurückgenommen werden können. Kennzahlen sollten deshalb Trends und Abweichungen sichtbar machen, nicht Teams gegeneinander ausspielen.

Fallbeispiel: kompromittierte Softwarekomponente

Ein Unternehmen entdeckt, dass eine häufig genutzte Bibliothek in mehreren Diensten kompromittiert ist. Ein reines DevSecOps-Verfahren würde betroffene Builds identifizieren, die Komponente aktualisieren und neue Versionen bereitstellen. DevSecResOps erweitert die Reaktion: Die Dienstlandkarte zeigt sofort betroffene Geschäftsprozesse und Abhängigkeiten. Telemetrie und geschützte Protokolle helfen, tatsächliche Ausnutzung zu bewerten. Progressive Deployments begrenzen die Änderung, während kritische Dienste geplant in einen Degradationsmodus wechseln.

Falls eine Kompromittierung bestätigt wird, erfolgt der Wiederaufbau für die betroffenen kritischen Komponenten in einer getrennten Vertrauensdomäne aus signierten Artefakten und geprüften Daten. Identitäten und Geheimnisse werden risikobasiert erneuert, bevor der Dienst wieder freigegeben wird. Externe Abhängigkeiten, Datenabgleiche und die Reihenfolge des Wiederanlaufs werden ausdrücklich in die Freigabeentscheidung einbezogen. Anschließend entstehen aus dem Vorfall neue Pipeline-Regeln, Erkennungsmuster und Übungen. So wird aus Incident Response ein geschlossener Verbesserungszyklus.

Einführung in vier Etappen

Transparenz schaffen: Kritische Dienste auswählen, Eigentümer und Abhängigkeiten erfassen, bestehende Security-, Delivery- und Recovery-Kontrollen zusammenführen.
Pilotieren: Für ein relevantes Produkt ein Service Resilience Profile, einen Golden Recovery Path und gemeinsame Kennzahlen entwickeln. Ein realistisches Ausfallszenario testen.
Standardisieren: Erfolgreiche Muster als Plattformdienste, Pipeline-Vorlagen und Richtlinien als Code bereitstellen. Evidenzen automatisiert sammeln.
Skalieren und üben: Weitere Dienste risikobasiert anbinden, Lieferanten einbeziehen, regelmäßige Game Days durchführen und Ausnahmen aktiv zurückbauen.

Typische Fehlansätze

Nur Werkzeuge integrieren: Eine gemeinsame Oberfläche ersetzt weder klare Entscheidungen noch getestete Abläufe.
Recovery an ein Backup-Team delegieren: Wiederanlauf ist eine Eigenschaft des Geschäftsdienstes und benötigt Anwendungskontext.
Alles gleich behandeln: Kontrolltiefe und Testfrequenz müssen sich an Kritikalität und Angriffsexposition orientieren.
Automatisierung ungeprüft vertrauen: Fehlerhafte Automationen können Störungen beschleunigen; deshalb sind Tests, Freigaben und Abbruchwege nötig.
Nur Happy Paths testen: Übungen müssen fehlende Identitäten, manipulierte Daten, nicht verfügbare Abhängigkeiten und Zeitdruck einschließen.

Wirtschaftlichkeit: Resilienz als Produktivitätsfaktor

DevSecResOps verursacht anfangs Aufwand für Architekturarbeit, Plattformfunktionen, Datenpflege und Übungen. Der Nutzen kann auch im Regelbetrieb entstehen, wenn standardisierte Wiederherstellung, bessere Diensttransparenz, frühere Fehlererkennung und sichere Deployment-Muster Betriebsunterbrechungen und Abstimmungsaufwand tatsächlich reduzieren. Investitionen sollten deshalb vor und nach der Einführung anhand von Ausfallkosten, Wiederherstellungszeiten, manueller Kontrollarbeit und Änderungsfehlern bewertet werden.

Fazit: Sicherheit endet nicht mit dem Deployment

DevSecResOps verbindet sichere Entwicklung mit belastbarem Betrieb zu einem durchgängigen System. Das Architekturprinzip zwingt Organisationen, Sicherheit, Beobachtbarkeit, Eindämmung und Wiederherstellung gemeinsam zu entwerfen. Dadurch entsteht kein absolut störungsfreier Betrieb. Es entsteht jedoch die Fähigkeit, unter Unsicherheit schneller zu erkennen, gezielter zu entscheiden und vertrauenswürdig wiederherzustellen. Für digitale Unternehmen ist genau diese Fähigkeit ein entscheidendes Qualitätsmerkmal ihrer Produkte und Plattformen.

Albert Absmeier & KI

Management-Checkliste

Sind die wichtigsten Geschäftsdienste mit Eigentümern und Abhängigkeiten erfasst?

Sind Sicherheits- und Wiederanlaufziele Teil von Architektur und Produkt-Backlog?

Gibt es für kritische Dienste einen getesteten, vertrauenswürdigen Recovery-Pfad?

Kann die Organisation im Vorfall schnell zwischen Isolation, Degradation und Wiederherstellung entscheiden?

Liefern Pipelines und Betriebsplattformen belastbare Evidenzen statt manueller Nachweissammlungen?

Werden technische Tests regelmäßig mit geschäftlichen Szenarien verbunden?

FAQ: Die 10 wichtigsten Fragen zu DevSecResOps

1. Was ist DevSecResOps?

DevSecResOps ist ein Architektur- und Betriebsprinzip, das sichere Softwareentwicklung, stabilen Betrieb und belastbare Wiederherstellung zusammenführt. Ziel ist es, digitale Dienste nicht nur schnell und sicher bereitzustellen, sondern sie bei Angriffen, Fehlern oder Ausfällen kontrolliert weiterzubetreiben und vertrauenswürdig wiederherzustellen.

2. Worin unterscheidet sich DevSecResOps von DevSecOps?

DevSecOps verankert Sicherheit in Entwicklung und Auslieferung. DevSecResOps erweitert diese Verantwortung bis in den laufenden Betrieb und die Wiederherstellung. Eine Änderung gilt damit erst dann als beherrscht, wenn sie beobachtbar, begrenzbar, reversibel und im Störungsfall wiederanlauffähig ist.

3. Welche Rolle spielt ResOps?

ResOps koordiniert die betriebliche Widerstandsfähigkeit. Dazu gehören Datenintegrität, Eindämmung, Wiederanlauf, die Validierung von Backups sowie die Abstimmung zwischen Security, IT-Betrieb, Plattformteams und Fachbereichen. ResOps macht Recovery zu einem regelmäßig geprüften Prozess statt zu einer Annahme.

4. Braucht DevSecResOps ein eigenes Team?

Nicht zwingend. Entscheidend ist eine gemeinsame Ergebnisverantwortung über bestehende Teams hinweg. Ein kleines Enablement-Team kann Referenzarchitekturen, Kontrollkataloge, Messgrößen und Übungsszenarien pflegen, während Produkt- und Domänenteams die Vorgaben risikogerecht umsetzen.

5. Welche Systeme sollten Unternehmen zuerst einbeziehen?

Der Einstieg sollte bei wenigen geschäftskritischen End-to-End-Diensten erfolgen. Geeignet sind Dienste mit hohem Ausfallrisiko, sensiblen Daten, vielen Abhängigkeiten oder strengen regulatorischen Anforderungen. Ein klar abgegrenzter Pilot liefert schneller belastbare Erkenntnisse als ein unternehmensweiter Werkzeug-Rollout.

6. Was ist ein Golden Recovery Path?

Der Golden Recovery Path ist ein dokumentierter und getesteter Standardweg für die Wiederherstellung. Er beschreibt unter anderem Isolation, Prüfung des Wiederherstellungspunkts, Erneuerung von Identitäten und Geheimnissen, Wiederaufbau, technische Validierung und fachliche Freigabe.

7. Wie verändert DevSecResOps die CI/CD-Pipeline?

Die Pipeline prüft zusätzlich zur Funktion und Sicherheit auch Wiederherstellbarkeit, Datenintegrität und kontrollierte Fehlerbehandlung. Signierte Artefakte, Provenienz, Richtlinien als Code, Restore-Tests, progressive Deployments und definierte Abbruchkriterien werden Teil einer umfassenderen Resilience Pipeline.

8. Welche Kennzahlen sind besonders relevant?

Wichtige Größen sind die tatsächliche Wiederherstellungszeit, der erreichte Datenstand, die Zeit bis zur belastbaren Lageeinschätzung, die Erfolgsquote von Restore-Tests, die Änderungsfehlerquote und der Anteil kritischer Dienste mit validiertem Recovery-Pfad. Einzelwerte sollten immer gemeinsam und im Geschäftskontext interpretiert werden.

9. Wie lässt sich die Wiederherstellung zuverlässig testen?

Geeignet sind regelmäßige Restore-Tests, Game Days, Chaos-Experimente und Angriffssimulationen. Die Tests sollten nicht nur den technischen Start eines Systems prüfen, sondern Identitäten, Abhängigkeiten, Datenintegrität, Degradationsmodi und die fachliche Nutzbarkeit des wiederhergestellten Dienstes einbeziehen.

10. Was sind die größten Hürden bei der Einführung?

Typische Hürden sind getrennte Zuständigkeiten, unvollständige Dienst- und Abhängigkeitsdaten, ungeprüftes Vertrauen in Automatisierung und Recovery sowie eine zu starke Konzentration auf Werkzeuge. Erfolgreiche Programme beginnen mit klaren Geschäftszielen, einem realistischen Piloten und gemeinsam verantworteten Nachweisen.

Text, Management Summary, FAQ und Bild wurden mit Hilfe von KI erstellt

© DevSecResOps Albert Absmeier

Resilience Pipeline mit regulatorischen Kontrollpunkten

Phase	Kernaktivitäten	Evidenzpunkte	Regulatorische Kontrollpunkte
Design	Architektur, Threat Modeling, Risikoanalyse	Security Architecture, Resilience Requirements	NIS2 Art. 21 – Risikomanagement &  Governance CRA Annex I – Secure Design  Principles
Build	Entwicklung, Code‑Review, SBOM‑Erstellung	Secure Code Reviews, Static/Dynamic Scans, SBOM Verification	CRA Art. 10 – Software Bill of Materials DORA Art. 9 – ICT Risk Management
Pre‑Release	Test, Simulation, Recovery‑Drills	Penetration Testing, Chaos Simulations, Recovery Drills	NIS2 Art. 23 – Incident Reporting  Readiness DORA Art. 11 – Testing of  ICT Systems
Deployment	Infrastruktur, Policies, Telemetrie	Immutable Infrastructure, Zero Trust Policies, Telemetry Activation	NIS2 Art. 21(2) – Technische und  organisatorische Maßnahmen DORA Art. 12 – ICT Security Controls
Run	Betrieb, Monitoring, Incident Response	Anomaly Detection, Incident Correlation, Degradation Modes	NIS2 Art. 23 – Meldung von  Zwischenfällen DORA Art. 17 – Operational  Resilience Testing
Recovery	Wiederherstellung, Nachweisführung	Backup Integrity Checks, Clean Room Verification, Recovery Exercises	NIS2 Art. 21(3) – Wiederherstellungsfähigkeit DORA Art. 11(3) – Business  Continuity Plans

720 Artikel zu »DevSecOps«

IT-Security | News | Produktmeldung

DevSecOps: Neue Orchestrierungsfunktionen schließen die Lücke zwischen Entwicklung und Bereitstellung

28. Mai 2026

Die Kombination aus plattformnahem Geheimnis-Management, vollständigen Merge-Request-Workflows, Transparenz über wiederverwendete Komponenten, lokal ausführbaren KI-Modellen und SBOM-basiertem Dependency-Scanning adressiert zentrale Schwachstellen in modernen DevSecOps-Prozessen. Sie ermöglicht Teams, Automatisierung, Sicherheit und Governance in einem einheitlichen Umfeld zu bündeln, wodurch die Lücke zwischen Code-Entwicklung und zuverlässiger Bereitstellung geschlossen wird. Eine aktuelle Plattformversion (siehe Meldung am Ende des…