DevSecOps in der Industrie: IEC 62443
Security-First für industrielle Umgebungen: Wie Sie IEC 62443 in Ihre CI/CD-Pipelines integrieren und DevSecOps-Praktiken auf OT-Systeme übertragen — ohne die Produktion auszubremsen.
Andreas Schönfeld
Geschäftsführer & DevOps-Berater, Comquent GmbH
18+ Jahre Erfahrung in DevOps, CI/CD und Industrial Automation
Auf einen Blick
DevSecOps in der Industrie bedeutet, Cybersicherheit (industrielle Cybersicherheit, auch: OT Cybersecurity) nach der Norm IEC 62443 direkt in CI/CD-Pipelines zu automatisieren. Die IEC 62443 — die internationale Normenreihe für Cybersecurity in Industrial Automation and Control Systems (IACS) — definiert 4 Security Levels (SL 1–4) und 7 Foundational Requirements, die sich auf 7 Pipeline-Stages abbilden lassen. Die größten Unterschiede zu IT-DevSecOps: OT-Systeme haben Lebenszyklen von 15–30 Jahren, Verfügbarkeitsanforderungen von 99,999 % und die Gefahr von Personenschäden. Die EU-Regulierung (NIS2-Richtlinie, EU Cyber Resilience Act) macht Security-by-Design für Industrieunternehmen zunehmend verpflichtend.
Warum Security in der OT anders ist
In der IT-Welt ist DevSecOps mittlerweile etabliert: Security-Checks laufen automatisiert in der Pipeline, Schwachstellen werden in Stunden gepatcht, Container werden bei jedem Build gescannt. Shift Left — Security von Anfang an. Auch in der OT müssen wir diesen Shift-Left-Ansatz für Security umsetzen.
In der OT-Welt sieht die Realität anders aus. Hier laufen SPS-Steuerungen, die seit 15 Jahren unverändert im Einsatz sind. Hier gibt es Protokolle ohne Verschlüsselung, Systeme ohne Patch-Möglichkeit und Netzwerke, die nie für Konnektivität designed wurden — und jetzt plötzlich mit der Cloud verbunden sind. OT Vulnerability Management erfordert daher grundlegend andere Strategien als in der IT.
IEC 62443 ist die internationale Normenreihe (industrielle Cybersicherheit Norm), die genau dieses Problem adressiert: Cybersecurity für Industrial Automation and Control Systems (IACS). Und DevSecOps ist der Ansatz, diese Anforderungen in automatisierte, reproduzierbare Prozesse zu überführen — statt sie manuell in Excel-Tabellen zu verwalten.
Dazu kommt der regulatorische Druck: Die NIS2-Richtlinie und der EU Cyber Resilience Act machen Security-by-Design für Industrieunternehmen ab 2026/2027 verpflichtend. Wer jetzt DevSecOps in seine Delivery-Pipeline integriert, schafft die Grundlage für NIS2-Konformität und die SBOM-Pflicht.
Die Bedrohungslage ist real
Industrielle Systeme sind zunehmend Ziel von Cyberangriffen. Ransomware-Angriffe auf Produktionsanlagen, Manipulation von Steuerungssystemen und Datendiebstahl sind keine Theorie mehr — sie passieren regelmäßig.
- Colonial Pipeline (2021): Ransomware legt größte US-Kraftstoff-Pipeline lahm
- Norsk Hydro (2019): LockerGoga-Ransomware — 71 Mio. USD Schaden
- TRITON/TRISIS (2017): Angriff auf Safety-Instrumented Systems in Petrochemie
IEC 62443: Was Sie wissen müssen
Die IEC 62443 ist keine einzelne Norm, sondern eine Normenreihe mit vier Teilen, die den gesamten Security-Lifecycle abdecken — vom Betreiber über den Integrator bis zum Komponentenhersteller.
Die 4 Teile der IEC 62443
Für DevSecOps ist besonders IEC 62443-4-1 relevant: „Product Security Development Life-Cycle Requirements". Diese Norm definiert, wie sichere Software für industrielle Systeme entwickelt werden muss — und lässt sich direkt auf CI/CD-Pipelines abbilden (IEC 62443-4-1 CI/CD). Als ergänzende Referenz lohnt der Blick auf das NIST Cybersecurity Framework und das MITRE ATT&CK for ICS-Bedrohungsframework für OT-spezifische Angriffsszenarien.
Die 4 Security Levels (SL 1–4)
IEC 62443 definiert vier Security Levels, die den Schutzgrad gegen unterschiedliche Bedrohungen beschreiben. Nicht jedes System braucht SL 4 — der richtige Level hängt von der Risikoanalyse ab.
Zufällige Verletzung
Schutz gegen unbeabsichtigte oder zufällige Verletzungen der Sicherheit. Basis-Hygiene: Passwortschutz, Netzwerksegmentierung.
Gezielte Angriffe (geringe Ressourcen)
Schutz gegen gezielte Angriffe mit begrenzten Ressourcen, allgemeinen Fähigkeiten und geringer Motivation.
Gezielte Angriffe (moderate Ressourcen)
Schutz gegen gezielte Angriffe mit spezifischen IACS-Kenntnissen, moderaten Ressourcen und mittlerer Motivation.
Gezielte Angriffe (hohe Ressourcen)
Schutz gegen staatliche Akteure mit umfangreichen Ressourcen, tiefem IACS-Wissen und hoher Motivation.
Comquent-Mapping: IEC 62443 Anforderungen auf CI/CD-Pipelines
Die IEC 62443 definiert 7 grundlegende Sicherheitsanforderungen (Foundational Requirements). Unser Comquent-Mapping zeigt, wie sich jede dieser IEC 62443 Anforderungen konkret auf CI/CD-Pipeline-Aktionen abbilden lässt — ein Ansatz, den wir in über 18 Jahren Industrial-DevOps-Praxis entwickelt haben.
Identification & Authentication Control
Identifikation und Authentifizierung aller Benutzer, Geräte und Software-Prozesse.
Use Control
Autorisierung und Zugriffskontrolle nach dem Least-Privilege-Prinzip.
System Integrity
Sicherstellung der Integrität von IACS-Komponenten und Software.
Data Confidentiality
Vertraulichkeit von Informationen in Kommunikationskanälen und Datenspeichern.
Restricted Data Flow
Segmentierung von Netzwerken und Kontrolle des Datenflusses.
Timely Response to Events
Zeitnahe Reaktion auf Sicherheitsvorfälle durch Monitoring und Alerting.
Resource Availability
Sicherstellung der Verfügbarkeit des IACS trotz Denial-of-Service-Angriffen.
Die DevSecOps-Pipeline für IEC 62443
7 Stages, die Security von Anfang an integrieren — mit konkreten Tools und IEC-62443-Bezug.
Secure Commit
Pre-Commit-Hooks prüfen auf Secrets, Credentials und sensible Daten im Code. Keine API-Keys, keine Passwörter im Repository.
FR 1 (Identification & Authentication) — Credentials dürfen nicht im Quellcode liegen.
Static Analysis (SAST)
Statische Code-Analyse identifiziert Schwachstellen, unsichere Funktionsaufrufe und Compliance-Verstöße — bevor der Code kompiliert wird.
FR 3 (System Integrity) — Software-Integrität sicherstellen, bekannte Schwachstellenmuster erkennen.
Dependency Scanning
Automatische Prüfung aller Abhängigkeiten auf bekannte Schwachstellen (CVEs). Software Bill of Materials (SBOM) generieren.
FR 3 (System Integrity) — Supply-Chain-Security, keine bekannten Vulnerabilities in Abhängigkeiten.
Build & Sign
Artefakte werden in einer kontrollierten Umgebung gebaut und kryptographisch signiert. Jedes Artefakt ist nachvollziehbar.
FR 3 (System Integrity) — Nachweisbare Integrität und Authentizität von Software-Artefakten.
Dynamic Testing (DAST)
Laufende Systeme werden auf Schwachstellen getestet: offene Ports, unsichere Konfigurationen, Authentifizierungs-Bypasses.
FR 5 (Restricted Data Flow) — Unerlaubte Datenflüsse und offene Angriffsvektoren identifizieren.
Compliance Gate
Automatisierte Prüfung gegen IEC 62443 Anforderungen. Policy-as-Code definiert, welche Security-Level erfüllt sein müssen.
Alle FRs — Automatisierte Validierung der Zielvorgaben vor dem Release.
Deploy & Monitor
Kontrolliertes Deployment mit Security-Monitoring. Anomalie-Erkennung, Log-Analyse und Incident-Response-Prozesse.
FR 6 (Timely Response) — Sicherheitsvorfälle erkennen, protokollieren und zeitnah reagieren.
Pipeline-Stages im Überblick
| Stage | Tools | IEC-62443-Bezug |
|---|---|---|
| Secure Commit | git-secrets, detect-secrets, pre-commit hooks | FR 1 (Identification & Authentication) — Credentials dürfen nicht im Quellcode liegen. |
| Static Analysis (SAST) | SonarQube, Semgrep, Fortify, Custom IEC-Regeln | FR 3 (System Integrity) — Software-Integrität sicherstellen, bekannte Schwachstellenmuster erkennen. |
| Dependency Scanning | OWASP Dependency-Check, Trivy, Grype, Syft (SBOM) | FR 3 (System Integrity) — Supply-Chain-Security, keine bekannten Vulnerabilities in Abhängigkeiten. |
| Build & Sign | Jenkins / GitLab CI, cosign, Sigstore, Notary | FR 3 (System Integrity) — Nachweisbare Integrität und Authentizität von Software-Artefakten. |
| Dynamic Testing (DAST) | OWASP ZAP, Nessus, OpenVAS, Custom OT-Scanner | FR 5 (Restricted Data Flow) — Unerlaubte Datenflüsse und offene Angriffsvektoren identifizieren. |
| Compliance Gate | Open Policy Agent (OPA), Custom Compliance Scripts, Audit-Reports | Alle FRs — Automatisierte Validierung der Zielvorgaben vor dem Release. |
| Deploy & Monitor | SIEM, Wazuh, Grafana + Prometheus, OT-spezifische IDS | FR 6 (Timely Response) — Sicherheitsvorfälle erkennen, protokollieren und zeitnah reagieren. |
IT-Security vs. OT-Security: Die Unterschiede
DevSecOps-Praktiken aus der IT lassen sich nicht 1:1 auf die OT übertragen. Diese Unterschiede müssen bei der Pipeline-Gestaltung berücksichtigt werden.
Patch-Zyklen
Wöchentlich bis monatlich
Jährlich oder seltener — Patch erfordert Anlagenstillstand
Lebenszyklus
3–5 Jahre
15–30 Jahre — Legacy-Systeme ohne Security-Support
Verfügbarkeit
99,9 % (8,7 h Downtime/Jahr)
99,999 % (5,3 min Downtime/Jahr)
Fehlerfolgen
Datenverlust, Reputationsschaden
Personenschäden, Umweltschäden, Produktionsausfall
Protokolle
HTTP, TLS, SSH — standardisiert und verschlüsselbar
Modbus, OPC UA, PROFINET — oft unverschlüsselt
5 Quick Wins: Morgen starten
Sie müssen nicht gleich die komplette IEC 62443 umsetzen. Beginnen Sie mit diesen fünf Maßnahmen — sie liefern sofortigen Sicherheitsgewinn bei überschaubarem Aufwand.
Secrets aus dem Repository entfernen
NiedrigInstallieren Sie git-secrets oder detect-secrets als Pre-Commit-Hook. Kosten: 30 Minuten. Wirkung: sofort. Kein Credential landet mehr im Repository.
Dependency Scanning aktivieren
NiedrigTrivy oder OWASP Dependency-Check in die bestehende Pipeline einbauen. Ein zusätzlicher Stage, der alle Abhängigkeiten gegen CVE-Datenbanken prüft.
SBOM generieren
NiedrigMit Syft oder CycloneDX bei jedem Build eine Software Bill of Materials erzeugen. Regulatorisch zunehmend gefordert (EU Cyber Resilience Act).
Netzwerk-Segmentierung der Build-Umgebung
MittelJenkins-/GitLab-Server in ein eigenes VLAN. OT-Netzwerk nur über definierte Schnittstellen erreichbar. Kein direkter Zugriff aus dem Build-Netz auf Produktionsanlagen.
Security-Retrospektive einführen
NiedrigEinmal pro Quartal: Was waren unsere Security-Incidents? Welche Schwachstellen wurden gefunden? Was können wir verbessern? Gemeinsam mit IT und OT.
Fazit: Security ist kein Feature — es ist eine Grundlage
Die Zeiten, in denen OT-Systeme durch physische Isolation geschützt waren, sind vorbei. Industrielle Systeme sind vernetzt, angreifbar und zunehmend im Visier von Cyberkriminellen. IEC 62443 liefert den Rahmen, DevSecOps liefert die Methodik — und CI/CD-Pipelines liefern die Automatisierung.
Der Schlüssel ist Shift Left Security: Security nicht am Ende prüfen, sondern von der ersten Zeile Code an einbauen. Automatisiert, reproduzierbar und nachvollziehbar. Nicht als Bremse, sondern als Qualitätsmerkmal. Mit der NIS2-Richtlinie und dem EU Cyber Resilience Act wird dieser Ansatz ab 2026/2027 für viele Industrieunternehmen regulatorisch verpflichtend.
Starten Sie mit den Quick Wins, bauen Sie schrittweise ein systematisches OT Vulnerability Management auf und machen Sie Security zu einem natürlichen Teil Ihrer Delivery-Pipeline. Generieren Sie eine SBOM bei jedem Build — damit schaffen Sie die Grundlage für die kommende SBOM-Pflicht. Ihre Produktion — und Ihre Kunden — werden es Ihnen danken.
Security-Assessment für Ihre OT-Umgebung
Wo stehen Sie in Bezug auf IEC 62443? Unser kostenloser Quick-Scan identifiziert in 90 Minuten die drei größten Sicherheitslücken und die wirksamsten Sofortmaßnahmen.
Quellen & weiterführende Informationen
- IEC 62443 — Industrial communication networks – Network and system securityInternational Electrotechnical Commission (IEC)
- Colonial Pipeline Cyberattack (2021) — CISA AdvisoryCybersecurity and Infrastructure Security Agency
- Norsk Hydro LockerGoga Incident Report (2019)Norsk Hydro ASA
- TRITON/TRISIS Malware Analysis — Targeting Safety Instrumented SystemsMandiant / FireEye
- NIST Cybersecurity FrameworkNational Institute of Standards and Technology
- MITRE ATT&CK for Industrial Control Systems (ICS)MITRE Corporation
- NIS2-Richtlinie (EU) 2022/2555Europäisches Parlament und Rat
- EU Cyber Resilience Act — Regulation (EU) 2024/2847Europäische Kommission
Häufig gestellte Fragen zu DevSecOps und IEC 62443
Was ist DevSecOps in der Industrie?
DevSecOps in der Industrie ist die automatisierte Integration von Cybersicherheitsprüfungen nach IEC 62443 in CI/CD-Pipelines — von der ersten Zeile Code bis zum Deployment auf der Produktionsanlage. Statt Security manuell am Ende zu prüfen (Shift Right), werden Schwachstellen automatisch in jeder Pipeline-Stage erkannt und behoben (Shift Left Security).
Was ist die IEC 62443 und für wen gilt sie?
Die IEC 62443 ist die internationale Normenreihe für Cybersecurity in Industrial Automation and Control Systems (IACS). Sie richtet sich an drei Zielgruppen: Betreiber (Asset Owner), Systemintegratoren und Komponentenhersteller — und definiert für jede Rolle spezifische Sicherheitsanforderungen.
Was sind die Security Levels (SL 1–4) der IEC 62443?
Die vier Security Levels beschreiben den Schutzgrad gegen unterschiedliche Bedrohungsszenarien — von zufälligen Verletzungen (SL 1) bis zu staatlich gesteuerten Angriffen (SL 4). Der erforderliche Level wird durch eine Risikoanalyse bestimmt und beeinflusst die Schutzmaßnahmen und den Aufwand.
Wie integriert man IEC 62443 in eine CI/CD-Pipeline?
Jede Pipeline-Stage wird um Security-Checks erweitert: Pre-Commit-Hooks für Secrets-Scanning, SAST und Dependency Scanning beim Build, DAST beim Testing und automatisierte Compliance-Gates vor dem Release. Die IEC-62443-Anforderungen werden als Policy-as-Code definiert und automatisch geprüft.
Was ist eine SBOM und warum ist sie für OT-Security wichtig?
Eine Software Bill of Materials (SBOM) ist eine vollständige Liste aller Software-Komponenten in einem Produkt — inklusive Open-Source-Bibliotheken und deren Versionen. Sie ist die Grundlage für Vulnerability Management und wird durch den EU Cyber Resilience Act zur Pflicht für Hersteller.
Warum kann man IT-Security-Maßnahmen nicht 1:1 auf OT übertragen?
OT-Systeme haben fundamental andere Rahmenbedingungen: Lebenszyklen von 15–30 Jahren, Verfügbarkeitsanforderungen von 99,999 %, unverschlüsselte Protokolle und die Gefahr von Personenschäden bei Fehlfunktionen. Security-Maßnahmen dürfen die Anlagenverfügbarkeit und Safety niemals beeinträchtigen.
Was ist der Unterschied zwischen Safety und Security in der OT?
Safety schützt Menschen und Umwelt vor Gefahren durch die Maschine (funktionale Sicherheit), während Security die Maschine vor absichtlichen Angriffen und Manipulation schützt (Cybersicherheit). Beide Disziplinen müssen gemeinsam betrachtet werden, da ein Cyberangriff die funktionale Sicherheit kompromittieren kann.
Welche Quick Wins gibt es für OT-Security?
Sofort umsetzbare Maßnahmen sind: Secrets-Scanning als Pre-Commit-Hook (30 Minuten Aufwand), Dependency Scanning gegen CVE-Datenbanken in der bestehenden Pipeline und die Generierung einer SBOM bei jedem Build. Diese drei Maßnahmen liefern sofortigen Sicherheitsgewinn bei minimalem Aufwand.
Verwandte Artikel
EU Cyber Resilience Act im Maschinenbau
SBOM-Pflicht, Security by Design und CE-Fristen bis 2027.
CI/CD für SPS: TIA-Portal mit Jenkins
SPS-Programmierung automatisieren mit Jenkins, Git-Versionierung und PLCSim-Tests.
Industrial DevOps: Der komplette Leitfaden
Was ist Industrial DevOps? CI/CD für cyber-physische Systeme und Industrie 4.0.
Bereit für den nächsten Schritt?
Vereinbaren Sie ein kostenloses Erstgespräch — wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Erstgespräch buchenVon Comquent-Experten beraten — seit 2006 | 47+ erfolgreiche Projekte | Industrie, Automotive, Finance