Was ist der Cyber Resilience Act?
Der Cyber Resilience Act (CRA) ist eine EU-Verordnung, die Cybersicherheitsanforderungen für Produkte mit digitalen Elementen definiert. Seit dem Inkrafttreten müssen Hersteller nachweisen, dass ihre Produkte über den gesamten Lebenszyklus hinweg sicher sind -- von der Entwicklung über den Verkauf bis zum End-of-Life. Für den Maschinenbau hat das weitreichende Konsequenzen, denn moderne Maschinen sind voller Software: Steuerungen, HMIs, IoT-Gateways, Cloud-Anbindungen.
Die Verordnung betrifft nicht nur IT-Produkte im engeren Sinne. Jede Maschine mit vernetzter Software -- und das sind heute die meisten -- fällt potenziell unter den CRA. Maschinenbauer, die bisher Cybersicherheit als nachrangiges Thema behandelt haben, müssen umdenken.
Konkrete Anforderungen für Maschinenbauer
Sichere Entwicklungsprozesse
Der CRA fordert "Security by Design" -- Sicherheit muss von Anfang an in den Entwicklungsprozess integriert sein, nicht als nachträglicher Audit aufgesetzt werden. Konkret bedeutet das:
- Threat Modeling: Bedrohungsanalysen für jede Softwarekomponente, die in der Maschine läuft
- Sichere Coding-Richtlinien: Dokumentierte Standards, nach denen entwickelt wird
- Code Reviews mit Sicherheitsfokus: Nicht nur funktionale Korrektheit, sondern auch Sicherheitsaspekte prüfen
- Automatisierte Sicherheitstests: Static Application Security Testing (SAST) und Dynamic Application Security Testing (DAST) in der CI/CD-Pipeline
Software Bill of Materials (SBOM)
Eine zentrale Anforderung ist die Software Bill of Materials -- eine vollständige Liste aller Softwarekomponenten, die in einem Produkt enthalten sind. Einschliesslich Open-Source-Bibliotheken, deren Versionen und bekannter Schwachstellen.
Für den Maschinenbau ist das eine neue Disziplin. Während IT-Unternehmen längst mit Dependency-Management und Vulnerability-Scanning arbeiten, ist in vielen OT-Umgebungen nicht einmal dokumentiert, welche Softwareversion auf welcher Maschine läuft.
Tools wie Syft, Grype oder CycloneDX können SBOMs automatisiert generieren und in die CI/CD-Pipeline integriert werden:
# SBOM generieren mit Syft
syft dir:./firmware-build -o cyclonedx-json > sbom.json
# Schwachstellen prüfen mit Grype
grype sbom:sbom.json --fail-on critical
Vulnerability Management
Der CRA verlangt, dass Hersteller bekannte Schwachstellen innerhalb definierter Fristen beheben und Sicherheitsupdates bereitstellen. Das setzt voraus:
- Ein Prozess zur kontinuierlichen Überwachung von CVEs (Common Vulnerabilities and Exposures) in den verwendeten Komponenten
- Die Fähigkeit, Sicherheitsupdates zeitnah zu entwickeln, zu testen und auszuliefern
- Eine Möglichkeit, Updates an Maschinen im Feld zu verteilen (OTA oder zumindest ein dokumentierter manueller Prozess)
Für Maschinenbauer, deren Release-Zyklen bisher in Jahren gemessen wurden, ist das eine fundamentale Änderung.
Was das für die Softwareentwicklung bedeutet
CI/CD wird zur Pflicht
Ohne automatisierte Build- und Test-Prozesse lassen sich die CRA-Anforderungen kaum erfüllen. Wenn jedes Sicherheitsupdate einen manuellen Build-Prozess mit wochenlanger Validierung erfordert, können Schwachstellen nicht zeitnah behoben werden.
Das bedeutet: Maschinenbauer müssen in CI/CD-Infrastruktur investieren. Automatisierte Builds, automatisierte Tests, automatisierte SBOM-Generierung und automatisierte Schwachstellenscans -- das alles muss Teil der normalen Entwicklung sein, nicht ein zusätzlicher Schritt vor dem Release.
Versionierung und Nachvollziehbarkeit
Jede Softwareänderung muss nachvollziehbar sein: Wer hat was warum geändert? Welcher Stand läuft auf welcher Maschine? Welche Schwachstellen wurden in welchem Release behoben? Git als Versionskontrollsystem und ein Artefakt-Repository für Build-Ergebnisse bilden die Grundlage für diese Nachvollziehbarkeit.
Langfristiger Support
Der CRA fordert Sicherheitsupdates über die erwartete Lebensdauer des Produkts. Für eine Maschine, die 20 Jahre in Betrieb ist, bedeutet das: 20 Jahre Softwarepflege. Das hat Auswirkungen auf die Architektur (modulare, aktualisierbare Softwarekomponenten), die Toolwahl (langfristig unterstützte Plattformen) und die Ressourcenplanung.
Zeitplan und Übergangsfristen
Der CRA sieht Übergangsfristen vor, aber die Zeit läuft. Hersteller sollten jetzt mit der Umsetzung beginnen, nicht erst wenn die Fristen ablaufen. Insbesondere die Einführung von CI/CD-Prozessen, SBOM-Generierung und Vulnerability Management braucht Zeit -- nicht nur technisch, sondern auch organisatorisch.
Fazit
Der Cyber Resilience Act verändert die Spielregeln für Maschinenbauer mit Software in ihren Produkten. Die Anforderungen sind anspruchsvoll, aber sie spiegeln wider, was in der IT-Welt längst Standard ist. Für den Maschinenbau ist das ein Anstoss, Software-Entwicklungsprozesse zu professionalisieren -- mit langfristigem Nutzen für die Produktqualität und die Sicherheit der Kunden.
Unser CI/CD Training für PLC/SPS Entwicklung vermittelt die Grundlagen für automatisierte Build- und Test-Prozesse in der industriellen Softwareentwicklung -- ein wichtiger Baustein für die CRA-Compliance.
