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
Security.
Nicht am Ende.
In jeder Stufe.
DevSecOps in der Industrie bedeutet, Cybersicherheit nach der Norm IEC 62443 direkt in CI/CD-Pipelines zu automatisieren. Vier Security Levels, sieben Foundational Requirements, sieben Pipeline-Stages.
Die NIS2-Richtlinie und der EU Cyber Resilience Act machen Security-by-Design ab 2026/2027 für Industrieunternehmen verpflichtend.
15 Jahre SPS.
Keine Patches.
Aber Cloud-Anschluss.
In der IT-Welt ist DevSecOps 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 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 grundlegend andere Strategien als in der IT.
IEC 62443 ist die internationale Normenreihe, die genau dieses Problem adressiert: Cybersecurity für Industrial Automation and Control Systems (IACS). DevSecOps ist der Ansatz, diese Anforderungen in automatisierte, reproduzierbare Prozesse zu überführen — statt sie manuell in Excel-Tabellen zu verwalten.
Regulatorischer Druck kommt hinzu: Die NIS2-Richtlinie und der EU Cyber Resilience Act machen Security-by-Design für Industrieunternehmen ab 2026/2027 verpflichtend. Wer jetzt DevSecOps integriert, schafft die Grundlage für NIS2-Konformität und die SBOM-Pflicht.
— Lebenszyklen: 15–30 Jahre
— Verfügbarkeit: 99,999 %
— Risiko: Personenschäden
— Protokolle: unverschlüsselt
— Als ergänzende Referenz: NIST CSF und MITRE ATT&CK for ICS
Colonial Pipeline.
Norsk Hydro.
TRITON/TRISIS.
Industrielle Systeme sind zunehmend Ziel von Cyberangriffen. Ransomware auf Produktionsanlagen, Manipulation von Steuerungssystemen und Datendiebstahl sind keine Theorie mehr — sie passieren regelmäßig.
- 2021 · Colonial Pipeline — Ransomware legt größte US-Kraftstoff-Pipeline lahm
- 2019 · Norsk Hydro — LockerGoga-Ransomware, 71 Mio. USD Schaden
- 2017 · TRITON/TRISIS — Angriff auf Safety-Instrumented Systems in der Petrochemie
Keine einzelne Norm.
Eine ganze Reihe.
Die IEC 62443 ist eine Normenreihe mit vier Teilen, die den gesamten Security-Lifecycle abdecken — vom Betreiber über den Integrator bis zum Komponentenhersteller. 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.
- /1-xGeneral
Grundlagen, Konzepte, Terminologie
- /2-xPolicies & Procedures
Anforderungen an den Betreiber (Asset Owner)
- /3-xSystem
Anforderungen an den Systemintegrator
- /4-xComponent
Anforderungen an den Komponentenhersteller (für DevSecOps besonders relevant)
Vier Stufen.
Eine Risikoanalyse entscheidet.
IEC 62443 definiert vier Security Levels. Nicht jedes System braucht SL 4 — der richtige Level hängt von der Risikoanalyse ab.
- SL 1
Zufällige Verletzung
Basis-Hygiene.
Schutz gegen unbeabsichtigte oder zufällige Verletzungen der Sicherheit. Standardpasswörter ändern, Basis-Firewalls, physische Zugangskontrollen.
- SL 2
Gezielte Angriffe — geringe Ressourcen
Rollen, Verschlüsselung, Audit-Logs.
Schutz gegen gezielte Angriffe mit begrenzten Ressourcen und allgemeinen Fähigkeiten. Rollenbasierte Zugriffskontrolle, verschlüsselte Kommunikation, Audit-Logging.
- SL 3
Gezielte Angriffe — moderate Ressourcen
MFA, IDS, Härtung, Monitoring.
Schutz gegen Angriffe mit spezifischen IACS-Kenntnissen, moderaten Ressourcen und mittlerer Motivation. Multi-Faktor-Authentifizierung, Intrusion Detection, Security-Monitoring, Härtung.
- SL 4
Gezielte Angriffe — hohe Ressourcen
Zero Trust, KI-Anomalie, Unidirectional Gateways.
Schutz gegen staatliche Akteure mit umfangreichen Ressourcen, tiefem IACS-Wissen und hoher Motivation. Zero-Trust-Architektur, KI-basierte Anomalie-Erkennung, Air-Gap und unidirektionale Gateways.
Sieben FRs.
Sieben Pipeline-Aktionen.
Die IEC 62443 definiert sieben grundlegende Sicherheitsanforderungen (Foundational Requirements). Unser Mapping bildet jede FR auf konkrete CI/CD-Pipeline-Aktionen ab — in über 18 Jahren Industrial-DevOps-Praxis entwickelt.
Sieben Stages.
Sieben Gates.
- /01
Secure Commit
FR 1 — Identification & Authentication
Pre-Commit-Hooks prüfen auf Secrets, Credentials und sensible Daten im Code. Keine API-Keys, keine Passwörter im Repository.
git-secrets, detect-secrets, pre-commit hooks
- /02
Static Analysis (SAST)
FR 3 — System Integrity
Statische Code-Analyse identifiziert Schwachstellen, unsichere Funktionsaufrufe und Compliance-Verstöße — bevor der Code kompiliert wird.
SonarQube, Semgrep, Fortify, Custom IEC-Regeln
- /03
Dependency Scanning
FR 3 — System Integrity
Automatische Prüfung aller Abhängigkeiten auf bekannte Schwachstellen (CVEs). Software Bill of Materials (SBOM) generieren.
OWASP Dependency-Check, Trivy, Grype, Syft (SBOM)
- /04
Build & Sign
FR 3 — System Integrity
Artefakte werden in einer kontrollierten Umgebung gebaut und kryptographisch signiert. Jedes Artefakt ist nachvollziehbar.
Jenkins / GitLab CI, cosign, Sigstore, Notary
- /05
Dynamic Testing (DAST)
FR 5 — Restricted Data Flow
Laufende Systeme werden auf Schwachstellen getestet: offene Ports, unsichere Konfigurationen, Authentifizierungs-Bypasses.
OWASP ZAP, Nessus, OpenVAS, OT-Scanner
- /06
Compliance Gate
Alle FRs — automatisierte Validierung
Automatisierte Prüfung gegen IEC-62443-Anforderungen. Policy-as-Code definiert, welche Security-Level erfüllt sein müssen.
Open Policy Agent (OPA), Compliance Scripts, Audit-Reports
- /07
Deploy & Monitor
FR 6 — Timely Response
Kontrolliertes Deployment mit Security-Monitoring. Anomalie-Erkennung, Log-Analyse und Incident-Response-Prozesse.
SIEM, Wazuh, Grafana + Prometheus, OT-spezifische IDS
Fünf Dimensionen.
Zwei Welten.
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.
Morgen anfangen.
Nicht nächstes Jahr.
Sie müssen nicht gleich die komplette IEC 62443 umsetzen. Diese fünf Maßnahmen liefern sofortigen Sicherheitsgewinn bei überschaubarem Aufwand.
- /01
Secrets aus dem Repository entfernen
Aufwand: NiedrigInstallieren Sie git-secrets oder detect-secrets als Pre-Commit-Hook. Kosten: 30 Minuten. Wirkung: sofort. Kein Credential landet mehr im Repository.
- /02
Dependency Scanning aktivieren
Aufwand: NiedrigTrivy oder OWASP Dependency-Check in die bestehende Pipeline einbauen. Ein zusätzlicher Stage, der alle Abhängigkeiten gegen CVE-Datenbanken prüft.
- /03
SBOM generieren
Aufwand: NiedrigMit Syft oder CycloneDX bei jedem Build eine Software Bill of Materials erzeugen. Regulatorisch zunehmend gefordert (EU Cyber Resilience Act).
- /04
Netzwerk-Segmentierung der Build-Umgebung
Aufwand: MittelJenkins-/GitLab-Server in ein eigenes VLAN. OT-Netzwerk nur über definierte Schnittstellen erreichbar. Kein direkter Zugriff aus dem Build-Netz auf Produktionsanlagen.
- /05
Security-Retrospektive einführen
Aufwand: NiedrigEinmal pro Quartal: Was waren unsere Security-Incidents? Welche Schwachstellen wurden gefunden? Was können wir verbessern? Gemeinsam mit IT und OT.
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 generieren Sie eine SBOM bei jedem Build — damit schaffen Sie die Grundlage für die kommende SBOM-Pflicht.
Weiterführende Informationen.
- International Electrotechnical Commission (IEC)
- Cybersecurity and Infrastructure Security Agency
- Norsk Hydro LockerGoga Incident Report (2019)Norsk Hydro ASA
- TRITON/TRISIS Malware Analysis — Targeting Safety Instrumented SystemsMandiant / FireEye
- National Institute of Standards and Technology
- MITRE Corporation
- NIS2-Richtlinie (EU) 2022/2555Europäisches Parlament und Rat
- EU Cyber Resilience Act — Regulation (EU) 2024/2847Europäische Kommission
Was Kunden
wirklich fragen.
- Q.01
- 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).
- Q.02
- 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.
- Q.03
- 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.
- Q.04
- 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.
- Q.05
- 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.
- Q.06
- 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.
- Q.07
- 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.
- Q.08
- 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.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance