Governance mit dem Tempo von KI: Wie DevGovOps die DORA-Compliance-Lücke schließt

Was ist DevGovOps?

DevGovOps ist ein Ansatz im Software-Lieferketten-Engineering, der kontinuierliche Governance und Compliance in den DevOps-Lebenszyklus der Softwarebereitstellung integriert. Anstatt Compliance als nachgelagerte, manuelle Hürde zu behandeln, stellt DevGovOps sicher, dass die Durchsetzung von Richtlinien, kontinuierliche Auditierbarkeit und kryptografische Rückverfolgbarkeit bei jedem Release automatisch gewährleistet werden. Durch den Übergang von punktuellen Prüfungen zu kontinuierlichen Nachweisen können Unternehmen mit DevGovOps eine überprüfbare Kontrollkette für ihre Software aufrechterhalten. So können Teams Governance mit der Geschwindigkeit KI-gestützter Entwicklung umsetzen und gleichzeitig strenge regulatorische Auflagen wie den Cyber Resilience Act (CRA) und das SSDF (Secure Software Development Framework) des NIST erfüllen.

 

Während autonome KI-Coding-Agenten zunehmend nicht mehr nur Autocomplete-Vorschläge liefern, sondern ganze Software-Pipelines schreiben, kompilieren, testen und bereitstellen, entsteht eine wachsende Kluft zwischen menschlicher Absicht und den in der Produktion eingesetzten Binärdateien. Dadurch entsteht ein erhebliches strukturelles Defizit: Unsere Software-Pipelines laufen mit Maschinengeschwindigkeit, während unsere GRC(Governance, Risk & Compliance)-Frameworks immer noch auf manuelle Prozesse angewiesen sind.

Das Schließen dieser Lücke erfordert mehr als nur das Nachrüsten veralteter Sicherheitstools. Es braucht eine ausgewiesene, unabhängige technische und operative Disziplin: Development Governance Operations (DevGovOps).

Jede Epoche der Softwarebereitstellung hat eine neue Disziplin erfordert, um den neuen Herausforderungen gerecht zu werden.

 

Disziplin	Vereinigt	Der Auslöser	Das Ergebnis
DevOps	Dev + Ops	Isolierte Handoffs verlangsamten das Tempo	CI/CD, automatisiertes Testen, schnelle Bereitstellung
DevSecOps	Dev + Security + Ops	Lücken und träge Prozesse bremsten die Geschwindigkeit	Sicherheitsscans in der CI/CD-Pipeline
DevGovOps	Dev + Governance + Ops	Governance kann nicht erst im Nachhinein erfolgen	Governance als fester Bestandteil der Pipeline

 

Ähnlich wie DevOps Entwicklung und Softwarebetrieb (Operations) zusammenbrachte und DevSecOps dann Security in die Pipeline einbettete, schließt DevGovOps die Lücke zwischen Engineering, Sicherheit und Governance. Es handelt sich um einen kollaborativen Ansatz: AppSec definiert die Sicherheits- und Governance-Richtlinien, während Engineering diese Richtlinien direkt in die eigenen Pipelines integriert. Dadurch wird sichergestellt, dass Software nicht nur sicher ist und die Leistungskriterien erfüllt, sondern auch kontinuierlich compliant bleibt.

Ein relevantes Einsatzszenario für DevGovOps ist die kontinuierliche Einhaltung des neuen europäischen Digital Operational Resilience Act (DORA), von dem Finanzinstitute und ihre Softwareanbieter in der Europäischen Union betroffen sind.

DORA-Compliance basiert auf der Annahme, dass jede Änderung stets auf einen Menschen zurückzuführen ist, der benannt, befragt und zur Rechenschaft gezogen werden kann. KI-Coding-Agenten stellen diese Annahme jedoch grundlegend infrage. Die meisten Finanzinstitute haben noch nicht nachgezogen.

In einem kürzlich veranstalteten JFrog-Webinar haben wir erläutert, warum diese Lücke besteht, was sie kostet und wie sie geschlossen werden kann. Während das Webinar den Fokus auf unmittelbare, praktische Schritte zur Bewältigung von Governance-Herausforderungen mit der JFrog-Plattform legte, verdeutlichen diese Hürden zugleich den wachsenden Trend: DevGovOps etabliert sich zunehmend als unverzichtbarer Bestandteil moderner Software-Development-Operations.

Warum die Durchsetzungsphase von DORA alles verändert

Regulierungsbehörden fragen nicht mehr danach, ob ein entsprechendes Framework vorhanden ist. Sie verlangen dokumentierte Nachweise über einen Zeitraum von sechs Monaten.

Früher fragten Regulierungsbehörden, ob ein entsprechendes Framework vorhanden ist. Heute verlangen sie dokumentierte Nachweise über einen Zeitraum von sechs Monaten.

Als DORA (EU-Verordnung 2022/2554) im Januar 2025 in Kraft trat, akzeptierten die Aufsichtsbehörden zunächst regelmäßige Bestätigungen und punktuelle Richtlinienüberprüfungen als Nachweis dafür, dass Kontrollen umgesetzt wurden. Diese Phase ist vorbei. Die zuständigen nationalen Behörden (National Competent Authorities = NCAs) in der EU verlangen inzwischen Nachweise darüber, dass die Kontrollen in den letzten sechs Monaten kontinuierlich angewendet wurden.

KI-Coding-Agenten committen, erstellen und promoten Artefakte 10- bis 50-mal schneller als bei einer traditionellen sprintbasierten Entwicklung. Bei diesem Volumen und Tempo häufen sich nicht dokumentierte Entscheidungen schneller an, als sie durch eine nachträgliche Prüfung oder vierteljährliche Bewertungen bewältigt werden können.

Diese Evidenzlücke lässt sich messen. Laut dem JFrog-Bericht zur Sicherheit der Software-Lieferkette: Zum Stand der Dinge 2026:

• 35 % des neuen Enterprise-Codes wird bereits von KI generiert oder mithilfe von KI erstellt.
• Unternehmen verwalten pro Jahr 47 % mehr KI-Pakete als noch vor zwölf Monaten.
• 59 % der Unternehmen geben an, vollständige Visibility über die Provenance in der Produktion zu haben.
• Dennoch benötigen 48 % nach wie vor eine Woche oder länger, um bei Bedarf Nachweise für ein Compliance-Audit bereitzustellen.
• Nur 6 % schaffen das innerhalb eines Tages.

Genau an dieser Lücke zwischen dem Anspruch, Compliance zu erfüllen, und dem tatsächlichen Nachweis dafür setzt DevGovOps an: mit kontinuierlichen Nachweisen für jedes Artefakt und jeden Prozess in der Lieferkette.

Wie schließt DevGovOps die KI-Compliance-Lücke in DORA?

Fünf Compliance-Lücken treten bei Finanzinstituten, die agentenbasierte Pipelines nutzen, immer wieder auf. Jede davon lässt sich direkt einer DORA-Anforderung zuordnen und durch ein effektives DevGovOps-Programm schließen.

 

DORA-Säule	Die Lücke durch agentische Entwicklung	Der DevGovOps-Ansatz
ICT-Risikomanagement (Art. 8)	KI-Agenten beziehen undokumentierte Libraries von npm, PyPI oder Maven ohne vorherige Richtlinienprüfungen und schaffen dadurch nicht überwachte IKT-Assets.	Automatisierte Ingestion-Kontrolle: Die Pipeline fängt nicht regelkonforme Artefakte automatisch am Gateway ab und blockiert sie, wobei die Richtlinienbewertung in Ihrem zentralen System of Record dokumentiert wird.
Änderungsmanagement (Art. 9)	Commits werden von automatisierten Systemen ohne menschliche Entscheidungsträger eingespielt, wodurch die Verantwortlichkeitskette unterbrochen wird.	Kryptografische Attestierungen: Jede Release-Freigabe wird mit manipulationssicheren Metadaten signiert, aus denen hervorgeht, welches Policy-as-Code-Gate die Freigabe autorisiert hat.
Schwachstellen- Management	Herkömmliche Scanner übersehen LLM-spezifische Schwachstellen, API-Logikfehler und das Einschleusen schädlicher Pakete.	Kontextbezogenes Policy-Gating: Blockierte Artefakte werden anhand von CVE-Schweregrad, Lizenzrisiko und kontextbezogenes Scoring geprüft. So lassen sich Lücken erkennen, die Scanner nach der Bereitstellung zu spät finden.
Drittanbieter-Risiko (Art. 28–44)	Auf externe KI-Modelle, SaaS-Endpunkte und Paket-Registries wird dynamisch zugegriffen, ohne einen formellen Onboarding-Prozess für Anbieter.	Einheitliches System of Record: Jede Abhängigkeit, einschließlich KI-Modell-Komponenten und MCP-Registry-Komponenten, wird in einer laufend generierten SBOM erfasst, sodass Sie ein live einsehbares, überprüfbares Inventar aller IKT-Komponenten von Drittanbietern erhalten.
Incident Reporting	Wenn ein Vorfall auftritt, kann das Sicherheitsteam nicht schnell nachverfolgen, welcher KI-Agent, Prompt oder welches Modell den anfälligen Code generiert hat.	Anwendungskontext und Provenance: Jedes Release ist mit seiner Entstehungshistorie und seinem Anwendungskontext verknüpft, sodass Security-Teams innerhalb weniger Minuten die möglichen Auswirkungen eines Incidents und die verantwortlichen Personen bestimmen können.

 

Keine dieser Lücken schließt sich von selbst. Um sie zu schließen, muss Governance direkt in die Pipeline integriert werden, anstatt sie erst nachträglich zu berücksichtigen. Das bedeutet DevGovOps in der Praxis.

Wie sieht ein echtes Governance-Versagen aus?

Eine skandinavisches Investmentunternehmen setzte einen KI-Coding-Agenten ein, um die Bereitstellung zu beschleunigen. Innerhalb von 90 Tagen fügte der Agent der Codebasis in der Produktionsumgebung 67 neue Open-Source-Abhängigkeiten hinzu. Keine einzige davon wurde anhand der DORA-Richtlinie des Unternehmens bewertet oder mit dem Drittanbieter-Risikoregister abgeglichen. Als eine aufsichtsrechtliche Prüfung anstand, gab es keinerlei Aufzeichnungen darüber, wie über diese Abhängigkeiten entschieden worden war. Die Behebung dauerte vier Wochen und verzögerte eine Produkteinführung.

Die Verantwortung für diese 67 Pakete lag nach wie vor genau dort, wo sie schon immer lag: bei den Entwicklungs-, Security- und Compliance-Teams. Der Agent erzeugt das Risiko. Die Menschen mussten dafür geradestehen.

Drei DevGovOps-Prinzipien für DORA-Governance in agentischem Tempo

Die Zeit der aufsichtsrechtlichen Kulanz ist vorbei. Im Folgenden sind die Grundprinzipien von DevGovOps aufgeführt, bei denen Governance direkt in den Entwicklungslebenszyklus integriert ist, statt erst im Nachhinein umgesetzt zu werden.

Im Kontext der DORA-Vorgaben sind diese Prinzipien nicht mehr optional, sondern unerlässlich:

1. Richtlinien sind Code, keine Dokumente – Governance-Regeln müssen versioniert und überprüft werden und von der Pipeline selbst maschinell durchsetzbar sein. Eine Richtlinie, die nur in einem Word-Dokument hinterlegt ist, lässt sich nicht einem bestimmten Artefakt zuordnen und kann im Falle einer Anfrage einer Aufsichtsbehörde nicht unmittelbar abgerufen werden.
2. Governance im Tempo der Pipeline – Checks mit Blockierfunktion müssen bei jedem Commit synchron und ohne manuelle Verzögerung ausgeführt werden. Manuelle Reviews und vierteljährliche Assessments können mit dem Tempo agentenbasierter Entwicklung nicht mithalten. Wenn Ihre Kontrollen nicht mit dem Tempo Ihrer Pipeline Schritt halten können, verlieren sie ihre Wirkung.
3. Nachweise werden automatisch erstellt, nicht erst nachträglich zusammengestellt – Bei jedem Durchlauf müssen unveränderliche, mit Zeitstempeln versehene Datensätze als Teil des Bereitstellungsprozesses generiert werden. Nachträglich zusammengestellte Nachweise sind nicht dasselbe wie Nachweise, die zum Zeitpunkt der jeweiligen Entscheidung vorlagen.

Die Lücke besteht. Die Frage ist, wann Sie sie schließen.

Während die oben genannten Prinzipien einen theoretischen Rahmen für DevGovOps bieten, erfordert ihre Umsetzung die richtigen Tools. In unserem kürzlich verantsalteten Webinar DORA im Zeitalter von KI haben wir gezeigt, wie die JFrog Plattform als "Single System of Record" fungiert, um diese Prinzipien in die Praxis umzusetzen. Mithilfe von JFrog Curation und JFrog AppTrust haben wir demonstriert, wie Sie bösartige Pakete bereits beim Import automatisch blockieren, Policy-as-Code-Gates durchsetzen und die kryptografischen Nachweise erfassen, die erforderlich sind, um jederzeit auditfähig zu sein.

Wenn Sie KI-Agenten in Ihrer Pipeline einsetzen und Ihre Governance damit nicht Schritt hält, wird die nächste Aufsichtsprüfung diese Lücke aufdecken. Unternehmen, die diese Lücke jetzt schließen, indem sie Governance direkt in die Pipeline integrieren, anstatt sie erst im Rahmen nachträglicher Audits zu berücksichtigen, werden bei der nächsten Prüfung deutlich besser aufgestellt sein.

 

---

Häufig gestellte Fragen

Was ist DORA und für wen gilt die Verordnung?

DORA (EU-Verordnung 2022/2554) ist ein verbindliches EU-Gesetz, das im Januar 2025 in Kraft getreten ist. Die Verordnung gilt für Finanzinstitute, die in der Europäischen Union tätig sind oder den EU-Markt bedienen – darunter Banken, Versicherungen, Investmentgesellschaften und Zahlungsdienstleister  – sowie für die IKT-Drittanbieter, die diese Unternehmen versorgen. Ihre fünf Säulen umfassen IKT-Risikomanagement, Incident Reporting, Resilienztests, Drittanbieterrisiken und Informationsaustausch.

Gilt DORA für Softwareanbieter außerhalb der EU?

Ja. Wenn Ihre Software oder Services von EU-regulierten Finanzinstituten genutzt werden, fallen Sie gemäß Artikeln 28–44 in den Anwendungsbereich von DORA für IKT-Drittanbieter – unabhängig davon, wo Ihr Unternehmen seinen Hauptsitz hat. Jeder Zulieferer in der Software-Lieferkette eines EU-Finanzinstituts sollte seine DORA-Verpflichtungen überprüfen, insbesondere in Bezug auf vertragliche Anforderungen, Prüfungsrechte und die Transparenz der Lieferkette.

Welche Strafen drohen bei Verstößen gegen DORA?

Finanzinstituten, die als nicht regelkonform eingestuft werden, drohen Geldstrafen von bis zu 2 % des gesamten weltweiten Jahresumsatzes. Als kritisch eingestufte IKT-Drittanbietern drohen Strafen von bis zu 5 Mio. €. Neben Geldstrafen können Regulierungsbehörden Unternehmen dazu verpflichten, Verträge mit nicht regelkonformen IKT-Anbietern auszusetzen oder zu kündigen. Verstöße gegen DORA bergen damit nicht nur ein Compliance-, sondern auch ein erhebliches geschäftliches Risiko. (Hinweis: Die genauen Strafen können je nach Durchsetzung durch die Mitgliedstaaten variieren; ziehen Sie stets einen Rechtsbeistand zu Rate.)

Warum sind KI-Coding-Agenten eine besondere Herausforderung für DORA-Compliance?

DORA wurde für Entwicklungsprozesse konzipiert, die von Menschen kontrolliert werden und bei denen sich jede Änderung auf eine konkrete verantwortliche Person zurückführen lässt. KI-Coding-Agenten unterbrechen diese Verantwortlichkeitskette, indem sie eigenständig Artefakte committen, bauen und freigeben. Sie beziehen Abhängigkeiten ohne Richtlinienprüfung, generieren Code mit Schwachstellenklassen, die herkömmliche Scanner übersehen, und erstellen standardmäßig keinen Audit-Trail. Dadurch können Unternehmen Schwierigkeiten haben, die von DORA geforderten Nachweise bei Bedarf vorzulegen.

Was ist DevGovOps und welche Rolle spielt es bei DORA?

DevGovOps ist ein Ansatz im Software-Lieferketten-Engineering, der kontinuierliche Governance und Compliance direkt in den Softwarebereitstellungsprozess integriert. DevGovOps generiert automatisch kryptografische Attestierungen, setzt Policy-as-Code-Gates durch und betreibt ein einheitliches System of Record ain jeder Phase der Pipeline, anstatt Compliance-Nachweise erst im Nachhinein zusammenzustellen. Speziell für DORA stellt dies sicher, dass die von Regulierungsbehörden geforderten Nachweise in dem Moment vorliegen, in dem jede Entscheidung getroffen wird, und nicht erst Wochen später.

Wie lange dauert es, mit und ohne DevGovOps einen DORA-Audit-Nachweis zu erbringen?

Laut dem JFrog-Bericht zur Sicherheit der Software-Lieferkette: Zum Stand der Dinge 2026 benötigen 48 % der Unternehmen eine Woche oder länger, um auf Anfrage den Nachweis für ein Compliance-Audit bereitzustellen. Nur 6 % schaffen das innerhalb eines Tages. Mit einem DevGovOps-Ansatz werden Nachweise bei jedem Pipeline-Durchlauf automatisch generiert und können bei Bedarf unmittelbar abgerufen werden. Dadurch entfällt die mehrwöchige manuelle Zusammenstellung, weil die erforderlichen Nachweise bereits vorliegen.

---

Um tiefer ins Thema DevGovOps einzutauchen und zu erfahren, wie kontinuierliche Governance in der Praxis aussieht, besuchen Sie jfrog.com/de/learn/grc/devgovops.