CI/CD-Pipeline-Sicherheitsgovernance für Audits 2026

Es ist 08:17 Uhr an einem Montagmorgen, als der CISO eines wachsenden Fintechs die Nachricht erhält, die jede Sicherheitsleitung fürchtet:

„Der Produktions-Build sieht sauber aus, aber der Artefakt-Hash passt nicht zum Quellcode-Commit.“

Binnen Minuten bestätigt das Engineering-Team, dass das Release die Unit-Tests bestanden hat, das Deployment-Ticket vorliegt und der kundenbezogene Service stabil läuft. Die Pipeline erzählt jedoch eine andere Geschichte. Ein selbst gehosteter CI-Runner wurde projektübergreifend wiederverwendet. Temporäre Cloud-Zugangsdaten blieben länger aktiv als vorgesehen. Die Artefakt-Registry zeigt ein signiertes Container-Image, doch der Signaturschlüssel war von demselben Runner aus zugänglich, der nicht vertrauenswürdige Build-Skripte ausgeführt hat.

Der Release-Manager kann nachweisen, dass etwas bereitgestellt wurde. Was die Organisation zumindest nicht schnell genug nachweisen kann, ist, was gebaut wurde, wer es genehmigt hat, ob die Build-Umgebung unverändert und vertrauenswürdig war und ob die Nachweise einem Audit oder einer Vorfalluntersuchung standhalten würden.

Das ist nicht mehr nur ein DevOps-Problem.

Im Jahr 2026 liegt CI/CD-Pipeline-Sicherheitsgovernance an der Schnittstelle von Sicherheit der Software-Lieferkette, operativer Resilienz, Datenschutz-Rechenschaftspflicht, Produktsicherheit und Cyberrisikoaufsicht auf Ebene des Leitungsorgans. NIS2 verpflichtet Leitungsorgane, Risikomanagementmaßnahmen zur Cybersicherheit zu genehmigen und zu überwachen. DORA verlangt von Finanzunternehmen die Steuerung von IKT-Risiken, Vorfällen, Tests und Abhängigkeiten von Drittparteien. GDPR verpflichtet Verantwortliche und Auftragsverarbeiter, angemessene Sicherheit und Rechenschaftspflicht für personenbezogene Daten nachzuweisen. Der Cyber Resilience Act erhöht die Markterwartungen an sichere Produkte mit digitalen Elementen, sichere Aktualisierungen und den Umgang mit Schwachstellen. ISO/IEC 27001:2022 verlangt ein ISMS, das Risikobehandlung in kontrollierte und nachweisbare Abläufe überführt.

Die Pipeline ist zum Prüfpfad für modernes Softwarevertrauen geworden.

Die neue Compliance-Frage: Können Sie nachweisen, was in Produktion gelangt ist?

Über Jahre konzentrierten sich DevSecOps-Programme darauf, Scanner in Pipelines einzubauen. Statische Analyse, Abhängigkeitsprüfungen, Secret Scanning, Container-Scanning und Infrastructure-as-Code-Validierung wurden üblich. Diese Kontrollen bleiben relevant, beantworten aber nicht die Governance-Frage, die Auditoren, Aufsichtsbehörden, Kunden und Leitungsorgane heute stellen:

Kann die Organisation nachweisen, dass jedes Produktions-Deployment aus genehmigtem Quellcode stammt, in einer kontrollierten Umgebung gebaut wurde, ein überprüfbares Artefakt erzeugt hat, die erforderlichen Sicherheits-Gates durchlaufen hat, genehmigte Zugangsdaten verwendet hat, dem Änderungsmanagement folgte und Nachweise erzeugt hat, die gesichert werden können?

Angreifer wissen, dass Build-Systeme, Paketabhängigkeiten, Entwickler-Token, CI-Runner, Release-Automatisierung, Artefakt-Registries und Cloud-Deployment-Rollen hochwertige Ziele sind. Eine kompromittierte Pipeline kann klassische Abwehrmaßnahmen umgehen, weil sie vertrauenswürdige Automatisierung nutzt, um Schadcode in vertrauenswürdige Umgebungen zu bringen.

Ein ausgereiftes Governance-Modell für CI/CD-Pipeline-Sicherheit benötigt daher sechs Nachweissäulen.

Hier unterscheidet sich der Ansatz von Clarysec von reiner Checklisten-Compliance. Wir behandeln die CI/CD-Plattform als gesteuerten Geschäftsprozess, nicht nur als technisches Werkzeug. Dieser Prozess muss in den ISMS-Geltungsbereich aufgenommen, risikobewertet, kontrolliert, überwacht, auditiert und verbessert werden.

CI/CD in das ISO/IEC 27001:2022-ISMS aufnehmen

ISO/IEC 27001:2022 beginnt mit Kontext, interessierten Parteien und Geltungsbereich. Die Klauseln 4.1 bis 4.4 verlangen, dass Organisationen interne und externe Themen verstehen, Anforderungen interessierter Parteien bestimmen, gesetzliche, regulatorische und vertragliche Anforderungen identifizieren und den ISMS-Geltungsbereich unter Berücksichtigung von Abhängigkeiten zu anderen Organisationen festlegen.

Für einen SaaS-Anbieter, ein Fintech, einen Managed Service Provider, einen Softwareanbieter oder ein cloud-natives Unternehmen liegt CI/CD nahezu immer innerhalb dieses Geltungsbereichs, weil es Leistungserbringung, Kundendaten, Produktionsinfrastruktur und vertragliche Zusagen unmittelbar beeinflusst.

Die Klauseln 5.1 bis 5.3 machen die Leitung für das ISMS verantwortlich. Das ist relevant, weil moderne Release-Automatisierung zwischen Engineering, Sicherheit, Cloud-Betrieb, Beschaffung, Compliance und Produktmanagement liegt. Wenn keine Führungskraft die Risikobereitschaft für automatisierte Produktions-Deployments verantwortet, entstehen typischerweise fragmentierte Werkzeuge und inkonsistente Nachweise.

Die Klauseln 6.1.1 bis 6.1.3 bilden das Planungsfundament. Die Organisation muss Risiken für Vertraulichkeit, Integrität und Verfügbarkeit beurteilen, Risikoverantwortliche identifizieren, Risiken gegen Kriterien bewerten, Maßnahmen auswählen, ausgewählte Kontrollen mit Anhang A abgleichen, eine Anwendbarkeitserklärung erstellen und die Genehmigung des Risikobehandlungsplans sowie des Restrisikos einholen.

Eine CI/CD-Risikobeurteilung sollte nicht nur „Risiko der Software-Lieferkette“ nennen. Sie sollte realistische Szenarien benennen:

• Ein bösartiges Build-Skript exfiltriert Signaturschlüssel von einem gemeinsam genutzten Runner.
• Ein Entwickler umgeht den Branch-Schutz und stellt ungeprüften Code bereit.
• Eine kompromittierte Drittanbieter-Action verändert während des Builds ein Artefakt.
• Zugangsdaten für Staging gewähren Produktionszugriff.
• Ein Deployment erfolgt ohne verknüpften Änderungsantrag.
• Pipeline-Protokolle, die für die Rekonstruktion eines Vorfalls benötigt werden, werden nach sieben Tagen überschrieben.
• Ein Dependency-Poisoning-Vorfall erreicht die Vorproduktion oder Produktion.

Klausel 8.1 verlangt anschließend die geplante und kontrollierte Durchführung von ISMS-Prozessen, dokumentierte Nachweise, die Steuerung geplanter Änderungen, die Überprüfung unbeabsichtigter Änderungen sowie die Steuerung extern bereitgestellter Prozesse, Produkte oder Dienstleistungen, die für das ISMS relevant sind. Wenn die Pipeline die Produktion verändert, muss sie Nachweise für kontrollierten Betrieb erzeugen.

Das Clarysec-Kontrollmodell für sichere Softwarebereitstellung

Clarysec verbindet Richtlinien, Kontrollen und Auditnachweise. Die Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint ordnet sicheren DevOps-Betrieb und sichere Entwicklung der Risikomanagementphase, Schritt 14, zu. Darin wird festgelegt, dass Organisationen CI/CD-Werkzeuge absichern, sicherstellen müssen, dass nur autorisiertes Personal Deployments auslösen kann, MFA für den Pipeline-Zugriff verwenden, die Integrität von Build-Artefakten schützen sowie CI/CD-Aktionen protokollieren und überwachen.

„DevOps-Pipeline-Kontrollen: CI/CD-Werkzeuge müssen abgesichert werden – nur autorisiertes Personal darf Deployments auslösen; MFA für den Pipeline-Zugriff verwenden; Integrität von Build-Artefakten schützen. CI/CD-Aktionen protokollieren und überwachen.“

Diese Leitlinie wird umsetzbar, wenn sie in Richtlinienklauseln und Nachweisanforderungen übersetzt wird.

Die P24 – Richtlinie für sichere Softwareentwicklung Richtlinie für sichere Softwareentwicklung legt fest:

„Build-Artefakte müssen signiert und auf Quellcode-Commits zurückführbar sein.“

Dies ist eine der stärksten Kontrollen in einem CI/CD-Governance-Programm. Sie gibt dem Engineering vor, dass ein Produktionsartefakt eine überprüfbare Herkunftskette bis zur Versionsverwaltung tragen muss. Sie zeigt Auditoren zugleich, was zu prüfen ist: ein Produktionsrelease auswählen, die Artefaktsignatur untersuchen, die Commit-Referenz validieren, die Pull-Request-Genehmigung überprüfen und den Pipeline-Build-Datensatz bestätigen.

Dieselbe Richtlinie legt fest:

„Alle Entwicklungstätigkeiten müssen über genehmigte Versionskontrollsysteme mit durchgesetzten Zugriffskontrollen, Prüfpfaden und Schutzmechanismen für Branches nachverfolgt werden.“

Damit wird Governance nach vorgelagert verlagert. Wenn Quellcode-Repositories nicht geschützt sind, ist der Build-Herkunftsnachweis schwach. Wenn Schutzmechanismen für Branches umgangen werden können, baut die Pipeline möglicherweise zuverlässig nicht genehmigten Code. Wenn Prüfpfade deaktiviert sind, hängt die Rekonstruktion von Vorfällen von Erinnerung und Screenshots statt von belastbaren Nachweisen ab.

Für kleinere Organisationen enthält die Richtlinie für sichere Softwareentwicklung für KMU Richtlinie für sichere Softwareentwicklung für KMU eine pragmatische Mindestanforderung:

„Nachverfolgung von Codeversion, Deployment-Datum und Genehmigendem“

Dieses einfache Deployment-Register ist ein belastbarer Ausgangspunkt. Viele KMU benötigen am ersten Tag keine schwergewichtige Release-Governance, müssen aber wissen, welche Version wann produktiv gesetzt wurde und wer sie genehmigt hat.

Die KMU-Richtlinie legt außerdem fest:

„Der Zugriff auf Werkzeuge oder Systeme für Produktions-Deployments muss kontrolliert, protokolliert und regelmäßig durch die Geschäftsführung oder den IT-Dienstleister überprüft werden.“

Das ist der Governance-Schritt, den viele kleinere Teams übersehen. Eine CI/CD-Plattform mit Produktions-Cloud-Zugangsdaten ist ein privilegierter Produktionszugriffspfad.

Drei Kontrollbereiche aus ISO/IEC 27002:2022 hinter sicherer CI/CD

Die Zenith Controls: The Cross-Compliance Guide Zenith Controls ist Clarysecs bereichsübergreifender Kompass zur Abbildung offizieller Standards und Rahmenwerke auf praktische Kontrollbeziehungen. Für CI/CD-Pipeline-Sicherheitsgovernance sind drei Kontrollbereiche aus ISO/IEC 27002:2022 zentral.

Zenith Controls beschreibt 5.21 als präventive Kontrolle zur Unterstützung von Vertraulichkeit, Integrität und Verfügbarkeit, wobei Sicherheit in Lieferantenbeziehungen eine zentrale operative Fähigkeit ist. Das passt zu CI/CD, weil moderne Pipelines von externen Diensten abhängen: Plattformen zur Versionsverwaltung, gehostete Runner, Container-Registries, Open-Source-Paket-Repositories, Drittanbieter-GitHub-Actions, Scan-Werkzeuge, Cloud-Deployment-APIs und externe Entwickler.

In der Zuordnung zu 5.21 verknüpft Zenith Controls die Sicherheit der IKT-Lieferkette mit 5.19 Informationssicherheit in Lieferantenbeziehungen, 5.20 Behandlung von Informationssicherheit in Lieferantenvereinbarungen, 8.27 Sichere Systemarchitektur und Engineering-Grundsätze, 8.28 Sichere Programmierung, 8.29 Sicherheitstests in Entwicklung und Abnahme, 5.15 Zugriffskontrolle, 5.28 Beweissicherung, 8.25 Sicherer Entwicklungslebenszyklus und 8.30 Ausgelagerte Entwicklung.

Für 8.25 identifiziert Zenith Controls den sicheren Entwicklungslebenszyklus als präventive Kontrolle zum Schutz von Vertraulichkeit, Integrität und Verfügbarkeit. Sie verbindet Sicherheitsanforderungen, Architektur, Programmierung, Tests, ausgelagerte Entwicklung und 8.31 Trennung von Entwicklungs-, Test- und Produktionsumgebungen.

Für 8.32 beschreibt Zenith Controls das Änderungsmanagement als Brücke zwischen Entwicklung und Betrieb. Es steht in Beziehung zu 8.9 Konfigurationsmanagement, 8.8 Management technischer Schwachstellen, sicherem Entwicklungslebenszyklus und Incident Response. Deshalb darf Deployment-Automatisierung nicht außerhalb der Änderungsgovernance stehen. Sie ist der Mechanismus, über den Produktionsänderungen erfolgen.

Build-Herkunftsnachweis: die Release-Geschichte, der Auditoren folgen können

Build-Herkunftsnachweis ist die Fähigkeit, mit Nachweisen zu beantworten, woher ein Softwareartefakt stammt und wie es erzeugt wurde. Ein belastbarer Herkunftsdatensatz erzählt die Geschichte eines Releases:

1. Welches Quellcode-Repository und welcher Commit verwendet wurden.
2. Welcher Branch oder Tag den Build ausgelöst hat.
3. Welcher Pull Request, welcher Prüfer und welche Genehmigung verknüpft waren.
4. Welche Pipeline-Definition ausgeführt wurde.
5. Welcher Runner den Job ausgeführt hat.
6. Welche Abhängigkeiten und Basis-Images verwendet wurden.
7. Welche Tests und Sicherheits-Gates ausgeführt wurden.
8. Welches Artefakt erzeugt wurde.
9. Welche Signatur oder welcher Hash erzeugt wurde.
10. Welches Deployment das Artefakt verwendet hat.

Die P05 – Änderungsmanagement-Richtlinie Änderungsmanagement-Richtlinie stellt die Governance-Verknüpfung her. Sie legt fest:

„Werkzeuggestützte Änderungen müssen weiterhin dieser Richtlinie entsprechen und auf eine zugehörige Änderungsantragskennung zurückführbar sein.“

Damit wird das verbreitete Argument adressiert, automatisierte Deployments bräuchten keine Änderungstickets. Automatisierung hebt Änderungsgovernance nicht auf. Sie verändert, wie Nachweise erzeugt werden.

Dieselbe Richtlinie legt fest:

„Alle Änderungsanträge, Überprüfungen, Genehmigungen und unterstützenden Nachweise müssen im zentralen Änderungsmanagementsystem aufgezeichnet werden.“

In der Praxis sollte das Änderungsmanagementsystem der Index sein, nicht die Ablage für alles. Das Ticket sollte auf Quellcode-Repository, Build-Lauf, Artefaktsignatur, Deployment-Protokoll und Rollback-Plan verweisen. Detaillierte Nachweise können in Engineering-Werkzeugen verbleiben, sofern Aufbewahrung, Zugriffskontrolle und Exportierbarkeit definiert sind.

Runner-Härtung: die übersehene Produktionskontrolle

CI/CD-Runner werden häufig als Wegwerfinfrastruktur behandelt, sind aber Ausführungsumgebungen mit hohem Risiko. Ein Runner kann Zugriff auf Quellcode, Geheimnisse, Build-Caches, Paket-Repositories, Signaturschlüssel, Artefakt-Registries und Cloud-Deployment-Rollen haben. Ist er persistent, gemeinsam genutzt, überprivilegiert oder unzureichend überwacht, wird er zu einem privilegierten Pivot-Punkt.

Die sichere Governance-Position ist einfach: Runner, die Produktionscode bauen oder bereitstellen, müssen wie Produktionsinfrastruktur gehärtet werden.

Die Testdaten- und Testumgebungsrichtlinie Testdaten- und Testumgebungsrichtlinie legt fest:

„Die Integration mit CI/CD-Pipelines muss die Trennung von Umgebungen und Authentifizierungsdaten durchsetzen.“

Ein Runner, der mit demselben Zugangsdatenmodell in Staging und Produktion deployen kann, verletzt die Trennung von Umgebungen dem Sinn nach, selbst wenn die Infrastruktur logisch getrennt ist. Clarysec empfiehlt typischerweise getrennte Deployment-Identitäten je Umgebung, separate Genehmigungs-Gates für Produktion und explizite Kontrollen, die verhindern, dass Jobs aus niedrigeren Umgebungen auf Produktionsgeheimnisse zugreifen.

Die Zenith Blueprint, Phase „Controls in Action“, Schritt 21, bekräftigt dies durch die Trennung von Entwicklungs-, Test- und Produktionsumgebungen:

„Wenn CI/CD verwendet wird, bestätigen Sie, dass die Deployment-Promotion zwischen Umgebungen kontrolliert ist und eine Überprüfung oder Genehmigung erfordert. Dokumentieren Sie dies in Ihrem Verfahren zum Umgebungsmanagement und sichern Sie es mit Screenshots oder Konsolenexporten ab.“

Für ein reales Audit bedeutet das, dass der Auditor nicht nur ein Diagramm sehen sollte. Er sollte Konsolenexporte sehen, die umgebungsspezifische Zugangsdaten, geschützte Deployment-Umgebungen, Genehmigungs-Gates und Protokolle zeigen, die belegen, dass die Promotion kontrolliert wurde.

Deployment-Nachweise: das Compliance-Artefakt, das offen zutage liegt

Die ausgereiftesten DevSecOps-Teams behandeln Nachweissammlung nicht als vierteljährliche Aufräumaktion. Sie gestalten Pipelines so, dass Nachweise automatisch erzeugt werden.

Die Richtlinie zur Protokollierung und Überwachung für KMU Richtlinie zur Protokollierung und Überwachung für KMU nennt als relevante Protokollereignisse:

„Systemprotokolle: Konfigurationsänderungen, administrative Aktionen, Softwareinstallationen, Patch-Aktivitäten“

CI/CD-Systeme erzeugen alle vier Kategorien. Änderungen der Pipeline-Konfiguration beeinflussen, wie Software gebaut wird. Administrative Aktionen ändern, wer genehmigen oder deployen kann. Softwareinstallationen erfolgen in Build-Images und Deployment-Zielen. Patch-Aktivitäten können durch automatisierte Release-Prozesse laufen. Diese Ereignisse sollten risikobasiert protokolliert, aufbewahrt und überprüft werden.

Für Untersuchungsbereitschaft legt die P31S – Richtlinie zur Beweissicherung und Forensik für KMU Richtlinie zur Beweissicherung und Forensik für KMU fest:

„Screenshots, exportierte Protokolle und Dateihashes müssen zusammen mit der Datei zur Übertragungskette gespeichert werden.“

Dies ist besonders wichtig nach einer vermuteten Pipeline-Kompromittierung. Screenshots allein sind schwache Nachweise. Protokolle ohne Hashes können angefochten werden. Eine Datei zur Übertragungskette ohne Quellreferenzen ist unvollständig.

Ein belastbarer Produktions-Deployment-Datensatz sollte Folgendes enthalten.

Dieses Paket verwandelt CI/CD von einer Reihe technischer Schritte in eine Geschichte von Governance, Kontrolle und gebotener Sorgfalt.

Zuordnung von CI/CD-Governance zu NIS2, DORA, GDPR und CRA

NIS2 gilt für viele wesentliche und wichtige Einrichtungen, einschließlich digitaler Infrastruktur, IKT-Service-Management und digitaler Anbieterorganisationen, sofern die Kriterien erfüllt sind. Article 20 ist besonders relevant, weil er Cybersicherheitspflichten auf Managementebene begründet. Leitungsorgane müssen Risikomanagementmaßnahmen zur Cybersicherheit genehmigen, deren Umsetzung überwachen und Schulungen erhalten.

Article 21 stellt die Risikomanagement-Basislinie bereit. Er verlangt angemessene und verhältnismäßige technische, operative und organisatorische Maßnahmen für Risikoanalyse, Richtlinien, Vorfallsbehandlung, Aufrechterhaltung des Geschäftsbetriebs, Sicherheit der Lieferkette, sichere Beschaffung, Entwicklung und Wartung, Umgang mit Schwachstellen, Wirksamkeitsbewertung, Cyberhygiene, Kryptografie, HR-Sicherheit, Zugriffskontrolle, Asset-Management und MFA, soweit angemessen.

Article 23 ergänzt eine gestufte Meldung erheblicher Vorfälle, einschließlich Frühwarnung innerhalb von 24 Stunden nach Kenntniserlangung, Vorfallmeldung innerhalb von 72 Stunden und Abschlussbericht spätestens einen Monat nach der Vorfallmeldung. Wenn eine CI/CD-Kompromittierung schwere Betriebsstörungen, finanzielle Verluste oder erhebliche Schäden für andere verursachen könnte, muss der Prozess zur Vorfallklassifizierung vor dem Vorfall bereitstehen.

Für Finanzunternehmen gilt DORA seit dem 17. Januar 2025 und umfasst IKT-Risikomanagement, Vorfallmeldung, Resilienztests, Informationsaustausch, Management von IKT-Drittparteienrisiken und vertragliche Anforderungen. Article 5 verlangt ein internes Governance- und Kontrollrahmenwerk für IKT-Risiken mit Verantwortung des Leitungsorgans. Article 6 verlangt ein dokumentiertes Rahmenwerk für das Management von IKT-Risiken, das in das allgemeine Risikomanagement integriert ist.

Articles 8 bis 14 lassen sich direkt auf CI/CD-Pipeline-Governance abbilden. Finanzunternehmen müssen IKT-gestützte Geschäftsfunktionen, Assets, Abhängigkeiten, Bedrohungen und Schwachstellen identifizieren und klassifizieren. Sie müssen IKT-Systeme durch Richtlinien, Zugriffskontrollen, starke Authentifizierung, Schutz kryptografischer Schlüssel, kontrolliertes IKT-Änderungsmanagement, Patching und Segmentierung schützen. Sie müssen Anomalien erkennen, reagieren, wiederherstellen und aus Vorfällen lernen.

Articles 28 bis 30 sind ebenso wichtig, weil CI/CD-Plattformen, Anbieter von Versionsverwaltung, Artefakt-Registries, Cloud-Build-Systeme und externe Entwickler Abhängigkeiten von IKT-Drittparteien sein können. DORA erwartet gebotene Sorgfalt, vertragliche Schutzmaßnahmen, Bewertung von Konzentrationsrisiken, Audit- und Inspektionsrechte, Beendigungsauslöser, Exit-Strategien und Service-Level-Klauseln.

GDPR ergänzt die Rechenschaftsperspektive. Article 5 verlangt, dass personenbezogene Daten rechtmäßig, fair, transparent, für festgelegte Zwecke, minimiert, richtig, nur so lange wie erforderlich aufbewahrt und gegen unbefugte oder unrechtmäßige Verarbeitung sowie unbeabsichtigten Verlust, Zerstörung oder Beschädigung geschützt verarbeitet werden. Article 5(2) verpflichtet den Verantwortlichen, die Einhaltung nachzuweisen.

CI/CD-Pipelines sind für GDPR relevant, weil Entwickler Produktionsdaten in Testumgebungen verwenden können, Pipeline-Protokolle personenbezogene Daten oder Token offenlegen können, Releases die Verarbeitungslogik ändern können und kompromittierte Artefakte Datenschutzverletzungen verursachen können. Wenn Softwareänderungen Datenschutzkontrollen beeinflussen, sollte der Änderungsdatensatz die datenschutzbezogene Auswirkung erfassen. Wenn ein Pipeline-Vorfall unbefugten Zugriff auf personenbezogene Daten verursacht, muss die Bewertung der Datenschutzverletzung mit der Vorfallsbehandlung verknüpft sein.

CRA-Erwartungen ergänzen Produktsicherheit und Nachweise für sichere Aktualisierungen. Für Hersteller und Softwareanbieter, die Produkte mit digitalen Elementen auf dem EU-Markt bereitstellen, erwarten Kunden zunehmend Produktsicherheitsakten, Nachweise zum Umgang mit Schwachstellen, Kontrollen für sichere Aktualisierungen und Release-Integrität. CI/CD-Governance liefert einen großen Teil dieser Nachweise über Quellcode-Rückverfolgbarkeit, signierte Artefakte, Ergebnisse von Schwachstellenscans, Release Notes, Sicherheitskorrekturen und Aufzeichnungen zur Verteilung von Aktualisierungen.

NIST CSF 2.0 und COBIT 2019: die Auditperspektive jenseits von ISO

NIST CSF 2.0 stellt eine Integrationsschicht für Cybersicherheitsgovernance bereit. Core, Organizational Profiles und Tiers helfen Organisationen, den aktuellen und angestrebten Sicherheitszustand zu verstehen, Maßnahmen entlang gesetzlicher und regulatorischer Anforderungen zu priorisieren und Cyberrisiken zu kommunizieren.

Für CI/CD erstellt Clarysec häufig ein Software Delivery Pipeline Profile. Das Current Profile erfasst, wie Versionsverwaltung, Runner, Artefaktsignierung und Deployment-Genehmigungen heute funktionieren. Das Target Profile definiert den erforderlichen Zustand für regulierte Betriebsabläufe. Der Lückenplan wird zur Umsetzungsroadmap.

Die NIST-GOVERN-Funktion ist besonders relevant. GV.OC-03 verlangt, dass gesetzliche, regulatorische und vertragliche Cybersicherheitsanforderungen verstanden und gesteuert werden. GV.RM deckt Risikobereitschaft und standardisierte Risikopriorisierung ab. GV.RR weist Führungsverantwortung, Rollen und Ressourcen zu. GV.PO verlangt, dass Richtlinien für das Cybersicherheitsrisikomanagement festgelegt, durchgesetzt, überprüft und aktualisiert werden. GV.OV umfasst Aufsicht und Leistungsbewertung.

Ein COBIT 2019- oder ISACA-orientierter Auditor betrachtet häufig weniger die kryptografischen Details der Artefaktsignierung, sondern stärker das Governance-Design. Er wird fragen, ob Verantwortlichkeiten definiert sind, ob Change Enablement kontrolliert ist, ob Drittparteienservices risikogesteuert werden, ob Überwachung Sicherheit vermittelt, ob Ausnahmen genehmigt werden und ob die Leitung aussagekräftige Berichte erhält.

Häufige CI/CD-Auditfeststellungen und Kennzahlen für das Leitungsorgan

Die meisten CI/CD-Auditfeststellungen sind vorhersehbar. Die erste ist unverknüpfte Nachweisführung. Das Team hat Git-Protokolle, Pipeline-Protokolle und Deployment-Protokolle, aber keinen einzelnen Änderungsdatensatz, der sie verbindet. Die zweite ist überprivilegierte Automatisierung, bei der ein Job Produktionsgeheimnisse lesen, Artefakte pushen, Deployments genehmigen und Pipeline-Definitionen ändern kann. Die dritte sind persistente gemeinsam genutzte Runner, die Kontaminationsrisiken zwischen Projekten schaffen und die forensische Eingrenzung nach einer Kompromittierung erschweren.

Weitere häufige Mängel sind unsignierte oder überschriebene Artefakte, informelle Scan-Übersteuerungen, fehlende Lieferantentransparenz und Datenschutzabfluss in Protokollen. Eine gute Pipeline erlaubt Ausnahmen, verlangt aber Genehmigung, Ablaufdatum, Risikoverantwortung und Überprüfung.

Sicherheitsverantwortliche sollten dem Leitungsorgan nicht nur Scanner-Zählwerte berichten. Stattdessen sollten sie Kennzahlen zum Release-Vertrauen berichten:

• Anteil der Produktions-Deployments, die mit genehmigten Änderungsaufzeichnungen verknüpft sind.
• Anteil der Produktionsartefakte, die signiert und auf Quellcode-Commits zurückführbar sind.
• Anzahl der Deployments mit Ausnahmen oder Notfallgenehmigungen.
• Anteil privilegierter CI/CD-Benutzer mit MFA und aktueller Berechtigungsüberprüfung.
• Anzahl aktiver langlebiger Deployment-Zugangsdaten.
• Anteil kritischer Services, die gehärtete oder ephemere Runner verwenden.
• Durchschnittliche Zeit bis zum Widerruf oder zur Rotation von Pipeline-Geheimnissen nach einem Vorfall.
• Anzahl kritischer Lieferantenabhängigkeiten, die die Softwarebereitstellung unterstützen.
• Vollständigkeitsquote der Nachweise für Releases in Audit-Stichproben.

Diese Kennzahlen unterstützen Führung, Planung und operative Steuerung nach ISO/IEC 27001:2022. Sie unterstützen außerdem die Aufsichtspflichten des Managements nach NIS2 Article 20 und die Governance-Erwartungen aus DORA.

Machen Sie Ihre Pipeline auditierbar, bevor der Vorfall eintritt

CI/CD-Pipeline-Sicherheitsgovernance im Jahr 2026 bedeutet nicht, Engineering auszubremsen. Es geht darum, Softwarebereitstellung vertrauenswürdig, resilient und nachweisbar zu machen. Die besten Programme nutzen Automatisierung, um Nachweise zu beschleunigen, nicht um Governance zu umgehen.

Eine praxisnahe Clarysec-Umsetzung beginnt mit drei Maßnahmen.

1. Nutzen Sie Zenith Blueprint Zenith Blueprint, um sicheren DevOps-Betrieb, Quellcodezugriff, Trennung von Umgebungen und Änderungsmanagement in Ihre ISO/IEC 27001:2022-Umsetzungsroadmap aufzunehmen.
2. Nutzen Sie Zenith Controls Zenith Controls, um CI/CD-Risiken über sicheren Entwicklungslebenszyklus, IKT-Lieferkette, Zugriffskontrolle, Änderungsmanagement, Beweissicherung, NIS2, DORA, GDPR, NIST CSF 2.0 und COBIT 2019-Auditperspektiven hinweg abzubilden.
3. Setzen Sie Clarysec-Richtlinienvorlagen ein, einschließlich Richtlinie für sichere Softwareentwicklung, Änderungsmanagement-Richtlinie, Testdaten- und Testumgebungsrichtlinie, Richtlinie für sichere Softwareentwicklung für KMU, Richtlinie zur Protokollierung und Überwachung für KMU und Richtlinie zur Beweissicherung und Forensik für KMU, um festzulegen, wer Releases genehmigt, wie Artefakte rückverfolgt werden, wie Runner kontrolliert werden und welche Nachweise aufzubewahren sind.

Wenn Ihre nächste Audit-Stichprobe mit „Zeigen Sie uns den Produktions-Release-Pfad“ beginnt, sollte Ihr Team in Minuten antworten können, nicht erst nach Wochen. Das ist der Unterschied zwischen DevOps-Automatisierung und gesteuerter Softwarebereitstellung.

Laden Sie das Clarysec-Richtlinienpaket herunter, prüfen Sie Ihre CI/CD-Pipeline anhand von Zenith Blueprint und Zenith Controls, oder buchen Sie ein Clarysec-Assessment, um Ihre Pipeline von einer Quelle der Audit-Sorge zu einem Eckpfeiler digitaler Resilienz zu machen.