Cyber Resilience Act und Open Source: Was auf dich zukommt, wenn dein Produkt Software enthält
Der CRA trifft dich als Hersteller, sobald du Software mit digitalen Elementen in Verkehr bringst, auch wenn Open Source darin steckt. Wer jetzt eine belastbare Stückliste seiner Komponenten aufbaut, hat den größten Teil der Vorarbeit erledigt.
Warum der CRA gerade jetzt Druck macht
Der Cyber Resilience Act ist seit dem 10. Dezember 2024 in Kraft. Ab dem 11. September 2026 gelten die Melde- und Schwachstellenpflichten, die vollständige Konformität mit CE-Kennzeichnung ist ab dem 11. Dezember 2027 fällig. Betroffen ist jedes Produkt mit digitalen Elementen, das in der EU auf den Markt gebracht wird, also die Steuerung im Maschinenbau genauso wie ein Medizingerät mit Embedded Linux, eine On-Premises-Software oder ein Gateway mit Yocto-Image. Wer bisher davon ausging, dass ihn Cybersicherheitsregulierung nur im eigenen Rechenzentrum trifft, verwechselt den CRA mit NIS2.
Der erste Schock ist meist die Rollenfrage. Hersteller im Sinne der Verordnung ist, wer ein Produkt unter eigenem Namen oder eigener Marke in Verkehr bringt, und dazu gehört auch der komplette Open-Source-Anteil im Auslieferungsstand. Ein Kernel, eine BusyBox, eine OpenSSL-Version oder ein Python-Paket aus dem Build kommen zwar von außen, die Verantwortung für Schwachstellenmanagement und Updates bleibt aber beim Inverkehrbringer. Für rein nicht-kommerzielle Open-Source-Entwicklung sieht der CRA Ausnahmen vor, und für Open-Source-Software-Verwalter gilt ein abgeschwächtes Regime, das entlastet dich als Produkthersteller jedoch nicht.
Typische Fehler sehen wir immer an denselben Stellen: Die SBOM wird einmalig als PDF erzeugt statt maschinenlesbar in CycloneDX oder SPDX aus dem Build-Prozess, sie deckt nur die direkten Abhängigkeiten der Applikation ab und ignoriert das Basis-Image oder das Root-Dateisystem, und niemand kann sagen, welche Firmware-Version bei welchem Kunden läuft. Wenn dann eine aktiv ausgenutzte Schwachstelle bekannt wird, fehlt der Nachweis der Betroffenheit, und die 24-Stunden-Frist für die Erstmeldung an ENISA und das zuständige CSIRT läuft trotzdem.
Von der Komponente zur CRA-Konformität
- 01 Rolle und Produktklasse bestimmen
- 02 SBOM aus dem Build erzeugen
- 03 Schwachstellen bewerten und VEX pflegen
- 04 Meldewege für 24 und 72 Stunden
- 05 Signierte Updates über den Supportzeitraum
- 06 Technische Dokumentation und CE-Kennzeichnung
So bekommst du CRA-Konformität technisch in den Griff
Der CRA lässt sich nicht durch ein Compliance-Dokument erledigen, er verlangt Prozesse und Artefakte aus der Build- und Betriebskette. Die folgenden Schritte haben sich in Projekten bewährt, in denen Linux-basierte Produkte und Container-Images ausgeliefert werden.
Rolle und Produktklasse sauber bestimmen
Kläre zuerst, ob du Hersteller, Einführer oder Händler bist und ob dein Produkt in die Standardkategorie oder in die wichtigen beziehungsweise kritischen Klassen nach Anhang III und IV fällt. Davon hängt ab, ob eine Selbstbewertung reicht oder eine benannte Stelle eingebunden werden muss.
SBOM automatisiert aus dem Build erzeugen
Erzeuge die Stückliste maschinenlesbar in CycloneDX oder SPDX direkt in der Pipeline, etwa mit Syft oder Trivy für Container-Images und mit den SBOM-Klassen von Yocto für Embedded-Images. Nur so bleibt die SBOM mit jedem Release aktuell und lässt sich einer konkreten Artefakt-Signatur zuordnen.
Schwachstellen kontinuierlich gegen die SBOM prüfen
Gleiche die Komponentenliste laufend gegen NVD, OSV und die Advisories deiner Distribution ab und bewerte die Treffer statt sie nur zu zählen. Mit VEX-Dokumenten dokumentierst du nachvollziehbar, warum eine CVE dein Produkt nicht betrifft, zum Beispiel weil der verwundbare Codepfad nicht kompiliert oder nicht erreichbar ist.
Meldeprozess mit belastbaren Fristen aufsetzen
Definiere, wer eine aktiv ausgenutzte Schwachstelle oder einen schwerwiegenden Sicherheitsvorfall erkennt, wer meldet und wer freigibt. Der CRA verlangt eine Frühwarnung binnen 24 Stunden, eine inhaltliche Meldung binnen 72 Stunden und einen Abschlussbericht, das funktioniert nur mit benannten Rollen und einer Rufbereitschaft.
Update-Fähigkeit über den Supportzeitraum sicherstellen
Sicherheitsupdates müssen über den erwarteten Produktlebenszyklus verfügbar sein, mindestens fünf Jahre, sofern die Nutzungsdauer nicht kürzer ist. Praktisch heißt das signierte Update-Pakete, ein A/B-Update-Mechanismus oder Live Patching, eine gepflegte Kernel-Version und eine klar kommunizierte Support-Ende-Politik.
Secure by Design im Produkt nachweisen
Härtung ist Teil der grundlegenden Anforderungen: minimale Angriffsfläche im Image, keine Default-Passwörter, Secure Boot und signierte Artefakte, Least Privilege über systemd-Sandboxing und SELinux sowie sichere Standardkonfiguration. Diese Maßnahmen gehören dokumentiert in die technische Dokumentation, nicht nur in das Ticketsystem.
Kurse zu Cyber Resilience Act bei cmt
Diese Kurse vertiefen genau das, an echten Systemen statt nur an Folien. Als Präsenz oder Live-Online, auf Wunsch auch Inhouse für dein Team.
Häufige Fragen zu Cyber Resilience Act
Noch etwas offen? Wir sind ohne Warteschleife für dich da.
Frag uns direktGilt der Cyber Resilience Act auch für Open-Source-Software?
Ab wann gelten die Pflichten aus dem CRA konkret?
Was muss eine SBOM nach dem CRA enthalten?
Was ist der Unterschied zwischen CRA und NIS2?
Reicht ein Scanner wie Trivy für die CRA-Konformität aus?
Zuletzt geprüft am 26. Juli 2026.
Verwandte Linux-Themen
Alle Linux-Themen im ÜberblickPasst dazu: Weiterbildung für den öffentlichen Dienst
Echte Stimmen aus unseren IT-Kursen
Es war eine sehr gute Lernatmosphäre und der Trainer verstand sein Thema sehr gut.
Die Schulung war genau das richtige, um mein Verständnis zu erweitern. Vielen Dank an den Trainer!
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.
Bring dein Team auf den CRA-Stand
In unseren Schulungen üben wir genau die Bausteine, die der Cyber Resilience Act voraussetzt: SBOM-Erzeugung, Schwachstellenbewertung und Signaturen im Trivy-Kurs zu Container, Kubernetes, IaC und SBOM, Systemhärtung im Linux Security Intensivkurs und in den SELinux-Trainings sowie reproduzierbare, updatefähige Geräte-Images im Yocto Intensivkurs. Alle Kurse gibt es als Live-Online-Termin oder als Inhouse-Variante mit deinen eigenen Produkten und Build-Pipelines. Schreib uns kurz, welche Produkte betroffen sind, dann stellen wir dir einen passenden Weg zusammen.