Definition
DevOps-Praktiken zur automatisierten Integration, Test und Auslieferung von Software-Änderungen. Continuous Integration: jede Code-Änderung wird automatisch gebaut und getestet. Continuous Delivery: jeder erfolgreiche Build ist potenziell auslieferbar. Continuous Deployment: jeder erfolgreiche Build wird automatisch in Produktion gebracht. Voraussetzung für schnelle Reaktionsfähigkeit auf CRA-Schwachstellen-Meldungen.
In der Praxis
Eine Pipeline ist Qualitätsinfrastruktur, kein Entwickler-Spielzeug — das wird spätestens dann klar, wenn eine kritische Schwachstelle am Freitagabend bekannt wird und die Frage lautet: Wie schnell bekommen wir den Fix getestet und ausgerollt? Drei Fehlerbilder sehe ich regelmäßig. Erstens die Fake-CI: Der Build läuft automatisch, aber ohne Tests und ohne statische Analyse — dann integriert die Pipeline nur schneller fehlerhaften Code. Zweitens die Begriffsverwechslung: Continuous Delivery heißt auslieferbar, Continuous Deployment heißt automatisch ausgeliefert — in regulierten oder kundenkritischen Umfeldern ist Deployment ohne dokumentierte Freigabe kein Fortschritt, sondern ein Audit-Befund. Drittens fehlt der Rückweg: Kein Rollback, keine Stufen-Umgebungen, kein Monitoring nach dem Release. Der regulatorische Rahmen zieht an: Die Cyberresilienz-Verordnung verlangt wirksame Schwachstellenbehandlung während des gesamten Unterstützungszeitraums und ein gestuftes Melderegime für aktiv ausgenutzte Schwachstellen — Frühwarnung binnen 24 Stunden, Schwachstellenmeldung binnen 72 Stunden. Ohne automatisierte Pipeline ist diese Reaktionsfähigkeit kaum darstellbar.
Verwandte Begriffe
Häufige Fragen zu CI/CD
Was ist der Unterschied zwischen Continuous Integration, Delivery und Deployment?
Continuous Integration ist der erste Schritt: Jede Code-Änderung wird automatisch gebaut und gegen die automatisierten Tests geprüft — Integrationsprobleme fallen sofort auf, nicht nach Wochen. Continuous Delivery baut darauf auf: Jeder erfolgreiche Build durchläuft alle Qualitätsstufen und liegt als potenziell auslieferbares Paket bereit — die Entscheidung zur Auslieferung trifft aber ein Mensch oder ein Freigabeprozess. Continuous Deployment geht den letzten Schritt: Jeder erfolgreiche Build wird ohne manuelle Freigabe automatisch in die Produktionsumgebung gebracht. Die praktische Einordnung: CI ist Pflichtprogramm für jedes Team, Delivery der sinnvolle Standard für Unternehmenssoftware, Deployment die Königsdisziplin für beherrschte, gut überwachte Systeme. In regulierten Umfeldern — Medizintechnik, Avionik, Automotive — bleibt die dokumentierte Freigabe Pflicht; dort endet die Pipeline bewusst bei Delivery.
Welche Pflichten zur Schwachstellenbehebung stellt der Cyber Resilience Act — und was hat das mit unserer Pipeline zu tun?
Die Verordnung (EU) 2024/2847 verpflichtet Hersteller von Produkten mit digitalen Elementen, Schwachstellen während des gesamten Unterstützungszeitraums wirksam zu behandeln und Sicherheitsaktualisierungen bereitzustellen. Für aktiv ausgenutzte Schwachstellen gilt ein gestuftes Melderegime: eine Frühwarnung unverzüglich, spätestens binnen 24 Stunden ab Kenntnis, eine Schwachstellenmeldung spätestens binnen 72 Stunden und ein Abschlussbericht spätestens 14 Tage, nachdem eine Korrektur- oder Risikominderungsmaßnahme verfügbar ist. Dazu kommt die Pflicht, Schwachstellen in eingebundenen Komponenten, einschließlich Open Source, an deren Hersteller zu melden. Praktisch heißt das: Sie brauchen eine durchgängige Kette aus Schwachstellen-Monitoring, automatisiertem Test und schneller Auslieferung — genau das, was eine CI/CD-Pipeline leistet. Ohne sie werden aus 24 Stunden schnell drei Tage, und die Dokumentationspflichten der Verordnung laufen parallel weiter (Verordnung (EU) 2024/2847, Art. 13 Abs. 8 und Art. 14).
Wie bauen wir eine CI/CD-Pipeline auf, die auch einem ISMS- oder Kundenaudit standhält?
Bauen Sie stufenweise und mit Nachweislogik. Erste Stufe: automatisierter Build mit Unit-Tests und statischer Codeanalyse bei jedem Commit — das ist die Basis, ohne sie ist alles Weitere Deko. Zweite Stufe: getrennte Umgebungen für Entwicklung, Test und Produktion mit kontrollierten Übergängen; diese Trennung ist auch eine explizite Maßnahme des ISO/IEC-27001:2022-Anhangs. Dritte Stufe: Qualitäts-Gates mit definierten Kriterien — Tests bestanden, keine kritischen Findings, Freigabe dokumentiert — und ein automatisiertes Deployment-Protokoll, aus dem hervorgeht, welcher Stand wann wohin ging. Vierte Stufe: Rollback-Fähigkeit und Monitoring nach jedem Release. Fünftens die Verankerung: Die Pipeline-Regeln gehören als dokumentierte Information ins Managementsystem, inklusive Änderungssteuerung für die Pipeline selbst — sonst auditieren Sie nächstes Jahr eine Infrastruktur, die niemand mehr nachvollzieht (ISO/IEC 27001:2022, Anhang A.8.31).