DevSecOps für die Industrie: Security in jeder Stufe

DevSecOps ist die Erweiterung von DevOps um Security als festen Bestandteil jeder Pipeline-Stufe, von Commit über Build und Test bis Deployment und Betrieb. Statt eines Penetrationstests kurz vor dem Release laufen SAST, Dependency-Scans, Container-Scans und SBOM-Erzeugung automatisiert bei jedem Build; Compliance-Regeln stehen als Policy-as-Code im Repository. Für Industrieunternehmen ist das der praktikable Weg, NIS2, IEC 62443 und Cyber Resilience Act nachweisbar zu erfüllen, ohne dass jedes Release auf ein Security-Gate wartet.

Compliance in automatisierten Pipelines bleibt erhalten, wenn die Regeln selbst in der Pipeline stehen: Policy-as-Code-Gates prüfen jedes Deployment gegen die Vorgaben, jeder Build erzeugt eine SBOM, Artefakte sind signiert, und der Audit-Trail kommt aus dem Versionskontrollsystem, das Commit, Review und Freigabe ohnehin protokolliert. Ändert sich eine Anforderung, ändert sich eine Regel im Repository, mit Review und Historie wie jede andere Codeänderung. Für die NIS2-Umsetzung heißt das, die Maßnahmen nach § 30 BSIG (Schwachstellenmanagement, Sicherheit der Lieferkette, Nachweise) laufen als Build-Schritte mit, statt dass jemand sie vor dem Audit aus Tickets rekonstruiert.

Beides, nacheinander: SAST im Build, DAST in Staging. SAST (Static Application Security Testing) analysiert den Quellcode, ohne ihn auszuführen, und gehört direkt hinter den Commit, weil ein Fund dort am günstigsten zu beheben ist. DAST (Dynamic Application Security Testing) testet die laufende Anwendung von außen und braucht deshalb eine Staging-Umgebung nach dem Deployment. Dazwischen liegt SCA (Software Composition Analysis), der Dependency-Scan gegen bekannte Schwachstellen in Bibliotheken. Wer nur eines davon fährt, sieht entweder die eigenen Fehler oder die der Konfiguration, aber nie beides.

IEC 62443-4-1 beschreibt einen sicheren Entwicklungsprozess für Automatisierungskomponenten: Anforderungen an Threat Modeling, Secure Coding, Schwachstellen-Tests, Update-Management und Dokumentation. DevSecOps ist die Art, diese Anforderungen technisch umzusetzen: Die Pipeline führt die geforderten Prüfungen bei jedem Build aus und legt die Nachweise automatisch ab. Für die Zertifizierung zählt dann nicht mehr die Erinnerung des Teams, sondern der Pipeline-Report, inklusive Security Level (SL 1–4), gegen das die Komponente getestet wurde.

Als wichtige oder besonders wichtige Einrichtung nach § 28 BSIG müssen Sie sich beim BSI registrieren, Risikomanagementmaßnahmen nach § 30 BSIG umsetzen und erhebliche Sicherheitsvorfälle melden, die Erstmeldung binnen 24 Stunden. Das Gesetz gilt seit dem 06.12.2025 ohne Übergangsfrist, die Registrierungsfrist lief am 06.03.2026 ab, und bis zum 30.09.2026 hatten sich 20.141 Einrichtungen registriert. Die Geschäftsleitung muss die Maßnahmen umsetzen, überwachen und sich schulen lassen; verletzt sie diese Pflichten, haftet sie der eigenen Einrichtung nach Gesellschaftsrecht (§ 38 BSIG). Bußgelder reichen bis 10 Mio. € für besonders wichtige und bis 7 Mio. € für wichtige Einrichtungen (§ 65 BSIG).

Der CRA verpflichtet Hersteller digitaler Produkte zu Security-by-Design über den gesamten Lebenszyklus. Der Stufenplan: ab 11.06.2026 können Konformitätsbewertungsstellen notifiziert werden, ab 11.09.2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle binnen 24 Stunden als Frühwarnung an das zuständige CSIRT und die ENISA melden, ab 11.12.2027 ist der CRA vollständig anwendbar und ohne Cyber-Compliance keine CE-Kennzeichnung mehr zulässig. Pflichten sind unter anderem SBOM, Schwachstellenmanagement und Security-Updates über den Supportzeitraum, in der Regel mindestens fünf Jahre.

Eine SBOM ist eine maschinenlesbare Liste aller Softwarekomponenten, Abhängigkeiten und Lizenzen eines Produkts. Der EU Cyber Resilience Act macht sie spätestens mit der Vollanwendung am 11.12.2027 zur Pflicht, die Meldepflicht greift bereits seit dem 11.09.2026. Automatisierte SBOM-Generierung (CycloneDX, SPDX) in der Pipeline hält die Liste bei jedem Build aktuell.

Shift-Left Security verlegt Sicherheitsprüfungen so früh wie möglich in den Entwicklungsprozess, idealerweise an den Commit. SAST, Dependency-Scans und Container-Scans laufen dann automatisch bei jedem Build. Schwachstellen fallen auf, solange sie günstig zu beheben sind und der Entwickler den Code noch im Kopf hat.

Security by Design heißt, Sicherheit wird von Anfang an in Architektur und Entwicklung eingeplant; Security by Default heißt, das Produkt wird mit sicherer Grundkonfiguration ausgeliefert, etwa ohne Standardpasswörter und mit abgeschalteten unnötigen Diensten. Der Cyber Resilience Act verlangt beides: Anhang I fordert Produkte, die nach ihrem Risiko sicher konzipiert sind und mit einer sicheren Standardkonfiguration auf den Markt kommen. In der Pipeline lässt sich Security by Default prüfen, zum Beispiel mit einer Regel, die Images mit Standard-Zugangsdaten oder offenen Debug-Ports nicht freigibt.

Policy-as-Code schreibt Compliance-Anforderungen als maschinenlesbare Regeln ins Repository, und die Pipeline prüft sie bei jedem Deployment automatisch. Werkzeuge wie Open Policy Agent (OPA) oder HashiCorp Sentinel machen die Regeln versionierbar und testbar. Eine Änderung an einer Vorgabe läuft dann durch dasselbe Review wie jede Codeänderung.

Seit dem 02.08.2025 gelten die Pflichten der KI-Verordnung für General-Purpose-AI-Anbieter (Transparenz, Copyright-Policy, technische Dokumentation), und die Governance-Strukturen (AI Office, nationale Behörden) sind operativ. Für die Pipeline zählen die Hochrisiko-Pflichten, deren Stichtage der Digital Omnibus (Verordnung (EU) 2026/1744) verschoben hat. KI-Systeme nach Anhang III, etwa als Sicherheitskomponente kritischer Infrastruktur, müssen ab dem 02.12.2027 dokumentiert, getestet und überwachbar sein, KI mit Sicherheitsfunktion in Maschinen ab dem 02.08.2028. CI/CD-Pipelines werden damit zur Compliance-Infrastruktur: Modell-Versionierung, Trainings-Daten-Lineage, Audit-Trail, Bias-Tests, Human-Oversight-Hooks und Cybersecurity-Checks gehören in die Pipeline. Wir helfen, das pragmatisch in bestehende Jenkins-, GitLab- und Azure-DevOps-Setups zu integrieren.