Der CRA für Zephyr-Entwickler: was das Gesetz verlangt, was west spdx liefert und was übrig bleibt

Wenn Sie ein vernetztes Produkt auf Basis von Zephyr bauen und in der EU verkaufen, gilt der Cyber Resilience Act (CRA, Verordnung (EU) 2024/2847) für Ihre Firmware. Dieser Leitfaden beschreibt, was das Gesetz von einem Firmware-Team verlangt, was der Zephyr-eigene Befehl west spdx bereits liefert, welche Lücken dazwischen bleiben und was Sie als Nächstes tun können. Er ist eine Dokumentationshilfe, keine Rechtsberatung.

Die wichtigen Termine

Der CRA gilt in Stufen. Die Meldepflicht nach Artikel 14 gilt seit dem 11. September 2026; der Rest der Verordnung, darunter die wesentlichen Anforderungen, die technische Dokumentation, die EU-Konformitätserklärung und die CE-Kennzeichnung, gilt ab dem 11. Dezember 2027, und die Vorschriften über notifizierte Stellen in Kapitel IV gelten seit dem 11. Juni 2026 (Artikel 71 Absatz 2; EUR-Lex-Text geprüft am 8. Oktober 2026).

Die Meldepflicht beschränkt sich nicht auf neue Produkte. Nach Artikel 69 Absatz 3 gelten die Pflichten aus Artikel 14 auch für jedes Produkt im Anwendungsbereich, das vor dem 11. Dezember 2027 in Verkehr gebracht wurde. Ein Zephyr-Gerät, das Sie letztes Jahr ausgeliefert haben, fällt also heute schon unter die Meldevorschriften.

Was der CRA von Firmware verlangt

Die wesentlichen Anforderungen stehen in Anhang I. Teil I betrifft die Eigenschaften des Produkts; Teil II betrifft die Behandlung von Schwachstellen. Unsere Lesart (Argument): Für ein Firmware-Team machen fünf Punkte den größten Teil der Arbeit aus.

• Wissen, was drin ist (Anhang I Teil II Nummer 1). Sie müssen die Komponenten und Schwachstellen des Produkts erkennen und dokumentieren, unter anderem durch eine Software-Stückliste in einem gängigen, maschinenlesbaren Format, die zumindest die Abhängigkeiten auf oberster Ebene abdeckt (sinngemäß wiedergegeben; maßgeblich ist der Wortlaut der Verordnung).
• Ohne bekannte ausnutzbare Schwachstellen ausliefern (Teil I Nummer 2 Buchstabe a). Auf der Grundlage Ihrer Cybersicherheits-Risikobewertung und soweit anwendbar darf ein Produkt nur ohne bekannte ausnutzbare Schwachstellen auf dem Markt bereitgestellt werden.
• Ohne Verzögerung beheben (Teil II Nummer 2). Schwachstellen werden im Hinblick auf die Risiken im Zusammenhang mit Ihrem Produkt unverzüglich behandelt und behoben, auch durch Sicherheitsupdates; wo technisch möglich, werden Sicherheitsupdates getrennt von Funktionsupdates bereitgestellt.
• Aktualisierbar sein (Teil I Nummer 2 Buchstabe c). Schwachstellen müssen sich durch Sicherheitsupdates beheben lassen, soweit anwendbar automatisch und standardmäßig aktiviert, mit einer klaren und leicht bedienbaren Möglichkeit zum Abschalten.
• Updates sicher verteilen (Teil II Nummer 7).

Die Verordnung definiert eine Software-Stückliste (SBOM) als förmlichen Datensatz mit Einzelheiten und Lieferkettenbeziehungen der Komponenten, die in den Softwareelementen enthalten sind (Artikel 3 Nummer 39, sinngemäß wiedergegeben). Ein Format nennt sie nicht. Die Technische Richtlinie TR-03183-2 des BSI in Version 2.1.0 ist eine nationale Vorgabe und nicht bindend; nach unserer Lesart (Argument) ist sie die ausführlichste heute verfügbare Referenz. Sie ordnet die verlangten Felder SPDX und CycloneDX zu und hat die Mindestversionen auf CycloneDX 1.6 und SPDX 3.0.1 angehoben.

Was west spdx liefert

Zephyr bringt einen SBOM-Generator mit. Laut Zephyr-Dokumentation erzeugt west spdx eine Software-Stückliste für einen Zephyr-Build als Satz von SPDX-Dokumenten und erfasst Quelldateien, Build-Artefakte, die Beziehungen zwischen ihnen sowie Lizenz und Urheberrecht jeder Datei.

Die Schritte sind kurz:

1. CONFIG_BUILD_OUTPUT_META in Ihrem Projekt einschalten.
2. Mit west build bauen.
3. west spdx -d BUILD_DIR ausführen.

Es schreibt vier Dokumente nach BUILD_DIR/spdx/:

• app: die im Build verwendeten Quelldateien der Anwendung;
• zephyr: die verwendeten Zephyr-Quelldateien;
• build: die gebauten Ausgabedateien;
• modules-deps: ein Verweiseintrag für jedes Modul im Workspace, unabhängig davon, ob Ihr Build es verwendet hat.

SPDX 2.3 ist die Voreinstellung. Die aktuelle Zephyr-Dokumentation, die dem Entwicklungszweig folgt, nennt 2.2, 2.3 und 3.0 als Auswahl über --spdx-version, 3.1 ist als experimentell gekennzeichnet; das neueste Release am 8. Oktober 2026, Zephyr 4.4.2, bietet nur 2.2 und 2.3. --analyze-includes fügt die tatsächlich eingebundenen Header-Dateien hinzu, und zusammen damit fügt --include-sdk ein Dokument sdk für die Header der Toolchain hinzu.

Das ist ein echter Vorsprung: ein dateigenauer, zum Build passender Nachweis, den die meisten Firmware-Stacks von sich aus nicht erzeugen.

Was fehlt

Kennungen, die eine Schwachstellendatenbank zuordnen kann. Ein Schwachstellen-Feed ordnet Komponenten über eine Kennung zu, meist einen CPE-Namen (das Schema der US-amerikanischen National Vulnerability Database) oder eine Package URL (purl). Die Zephyr-Dokumentation erlaubt es einem Modul, diese in einem Abschnitt security: external-references: seiner Datei zephyr/module.yml anzugeben, in der Form CPE 2.3 oder purl; das eigene Beispiel lautet cpe:2.3:a:arm:mbed_tls:3.5.2:*:*:*:*:*:*:* und pkg:github/Mbed-TLS/mbedtls@V3.5.2. Diese Verweise landen im Dokument modules-deps. In Zephyr 4.4 erscheint ein Modul, das sie nicht angibt, auch Ihr eigenes und viele Hersteller-HALs, ohne zuordenbare Kennung. Der Entwicklungszweig ergänzt zusätzlich eine purl, die aus dem Git-Remote des Moduls und dem festgelegten Stand gebildet wird; nach unserer Lesart (Argument) hilft das nur dort, wo eine Schwachstellenquelle genau dieses Repository verfolgt. Code, der in den Baum kopiert statt als Modul eingebunden wurde, wird gar nicht als Komponente genannt.

Eine Release-Nummer für jedes Modul. Eine Schwachstellenabfrage braucht neben dem Namen auch eine Version. Zephyrs eigene west.yml legt jedes Modul auf eine Commit-Kennung und nicht auf ein Release-Tag fest, deshalb erreicht ein Modul die SBOM oft ohne jede Release-Nummer. Eine Commit-Kennung benennt den Code, ist aber keine Release-Nummer: ein Scanner kann sie nicht mit „betroffen vor 3.6.2“ vergleichen. Eine Kennung allein, nur mit Namen, lässt also weiterhin ein leeres oder bedeutungsloses Ergebnis zurück; genau das hat ein Hersteller in zephyrproject-rtos/zephyr#106620 berichtet (offen, zum Zeitpunkt unserer Prüfung ohne akzeptierte Antwort). Um eine Nummer zu bekommen, lesen Sie sie aus der Versionsdatei des Moduls, aus dem Upstream-Tag, das auf den von Ihnen festgelegten Commit zeigt, oder aus einem Hersteller-SDK-Manifest, das Tags festlegt. Schreiben Sie die Nummer neben das Modul; raten Sie sie nicht aus einem Commit.

Ein Name, den die Schwachstellendatenbank verwendet. Der Name in der SBOM ist oft nicht der Name, den die Datenbank verwendet. Eine Antwort in derselben Diskussion weist darauf hin, dass selbst vollständige Dateien Scanner an Herstellernamen scheitern lassen, etwa mbedtls gegen trustedfirmware oder arm. Das Mbed-TLS-Beispiel oben zeigt dieselbe Lücke. Firmware SBOMs that actually match CVEs (auf Englisch) erklärt, warum das so ist und wie Sie es prüfen.

Eine Formatversion, die zu den heutigen Referenzen passt. Die Standardausgabe ist SPDX 2.3. BSI TR-03183-2 v2.1.0 verlangt für eine neue oder aktualisierte SBOM SPDX 3.0.1 oder CycloneDX 1.6 oder höher. Folgt ein Kunde oder eine Behörde dieser Richtlinie, sollten Sie eines dieser Formate erzeugen oder dorthin umwandeln.

Binärblobs. Funkstacks, Bluetooth-Controller und Modem-Firmware kommen oft als vorkompilierte Bibliotheken. west spdx erfasst Dateien, die der Build verwendet hat; es weiß nicht, wer einen Blob geliefert hat, welche Version er hat oder welche Hinweise zu Schwachstellen ihn betreffen. Lieferant, Name und Version jedes Blobs müssen Sie von Hand oder aus den Release-Hinweisen Ihres Herstellers erfassen.

Schwachstellen. Eine SBOM listet Komponenten auf. Sie sagt nicht, welche davon bekannte Schwachstellen haben, welche davon Ihre Konfiguration betreffen oder was Sie entschieden haben. Anhang I Teil II Nummer 1 verlangt, außer Komponenten auch Schwachstellen zu erkennen; Sie brauchen also einen Abgleichschritt und eine Aufzeichnung Ihrer Entscheidungen.

Alles außerhalb der SBOM. Die Meldung nach Artikel 14, eine Richtlinie zur koordinierten Offenlegung von Schwachstellen, der Unterstützungszeitraum, die technische Dokumentation und die Konformitätserklärung entstehen in keinem Build-Werkzeug.

Was Ihre SBOM nicht zeigt

Laut Zephyr-Dokumentation erfasst west spdx die Quelldateien, die in den Build eingegangen sind, gesammelt über die CMake-File-API. Drei Dinge, nach denen Firmware-Teams fragen, liegen an deren Rand.

Code, der kein Zephyr-Modul ist. Der Build behandelt ein Projekt als Modul, wenn es eine zephyr/module.yml hat oder sowohl zephyr/CMakeLists.txt als auch zephyr/Kconfig. West findet Module über Ihr Manifest, und EXTRA_ZEPHYR_MODULES ergänzt Module von außerhalb des West-Workspace (Zephyr-Dokumentation zu Modulen). Ein über EXTRA_ZEPHYR_MODULES ergänztes Modul ist weiterhin ein Modul und kann deshalb security: external-references tragen; prüfen Sie, ob es das tut. Code, der den Build auf einem anderen Weg erreicht, etwa eine Bibliothek, die Ihr eigenes CMake herunterlädt, ein Hersteller-SDK auf einem lokalen Pfad oder eine vorgebaute Bibliothek, die Sie dazulinken, ist kein Modul. Unsere Lesart (Argument): Seine Dateien können in den Build-Dokumenten auftauchen, aber es wird nicht als Komponente mit Lieferant und Version genannt, also ordnet ihm kein Schwachstellen-Feed etwas zu. Erfassen Sie Lieferant, Name und Version für jedes davon von Hand. Module können ihre Binärblobs mit Version und Prüfsumme im Abschnitt blobs der module.yml beschreiben; dort fängt diese Liste gut an.

Module, die nicht gebaut wurden. Die Modulliste kann weiter sein als der Build. Im Zephyr-Quellcode, den wir gelesen haben (scripts/pylib/zspdx/walker.py, Entwicklungszweig), bekommt das Dokument modules-deps ein Paket für jedes Modul in den Workspace-Metadaten, mit einem Kommentar, dass es erzeugt wird, unabhängig davon, ob sein Code gebaut wird; nichts darin filtert nach dem, was kompiliert wurde. Ein Hersteller hat das in zephyrproject-rtos/zephyr#108287 angesprochen (30. April 2026, zum Zeitpunkt unserer Prüfung ohne akzeptierte Lösung). Lesen Sie die Modulliste also nicht als Liste dessen, was Ihre Firmware enthält. Ein Treffer gegen ein Modul, das Ihr Build nicht verwendet hat, braucht dieselbe Entscheidung „nicht betroffen, nicht gebaut“ mit Nachweis wie jeder andere: siehe Only what you built (auf Englisch).

Code, den Kconfig abschaltet. Weil west spdx die Dateien auflistet, die der Build verwendet hat, stehen Quelldateien eines Subsystems, das Ihr Kconfig abschaltet, nicht in den dateigenauen Dokumenten, auch wenn das Modul, das sie enthält, weiterhin in modules-deps gelistet sein kann. Ein Schwachstellen-Feed ordnet aber einem Modul und seiner Version zu, nicht einer Datei (Argument), deshalb kann eine CVE in mbedTLS oder in Zephyr selbst zutreffen, obwohl der betroffene Code in Ihrer Konfiguration nicht gebaut wird. Wenn Sie entscheiden, dass eine CVE Sie aus diesem Grund nicht betrifft, halten Sie die Entscheidung und ihre Begründung fest und bewahren Sie die build/zephyr/.config jedes Releases als Nachweis bei seiner SBOM auf.

MCUboot oder ein Hersteller-Bootloader. Mit sysbuild hat jedes Image sein eigenes Build-Verzeichnis, etwa build/mcuboot und build/<app>, und die Dokumentation zu west spdx sagt, Sie sollten genau die Anwendung ansprechen, für die Sie die SBOM erzeugen wollen. Ein Lauf beschreibt also ein Image. Unsere Lesart (Argument): Führen Sie west spdx auch auf dem Build-Verzeichnis von MCUboot aus, mit CONFIG_BUILD_OUTPUT_META für dieses Image eingeschaltet, und bewahren Sie beide Sätze beim Release auf. Ein Bootloader, den der Chip-Hersteller als Binärdatei liefert oder den Sie in einem getrennten Baum bauen, steckt in keinem von beiden: listen Sie ihn neben der SBOM mit Lieferant, Name und Version auf.

Wo Declarable hilft

Wenn Sie einen Zephyr-Build hochladen, schreibt Declarable die Upstream-CPE und -purl auf jedes Modul, das es kennt, damit eine Schwachstellenabfrage es zuordnen kann. Enthält Ihr Upload eine west.yml, die Release-Tags festlegt, wie es viele Hersteller-SDKs tun, liest Declarable die Version des Moduls aus diesem Tag. Es erfindet keine Release-Nummer aus einer Commit-Kennung: was mit einem Commit geschieht, hängt davon ab, wie es die Version dieses Moduls liest. Bei einem Modul, dessen Version es aus dem Commit liest, übernimmt es die ersten sieben Zeichen der Commit-Kennung, die den genauen Code benennen, und die Komponentenseite kennzeichnet diese Version als inferred (abgeleitet). Das ist keine Release-Nummer, deshalb behandelt eine Schwachstellenabfrage sie auch nicht als eine, und sie löst keinen Hinweis aus. Bei einem Modul, dessen Version es aus einem Release-Tag liest, ergibt ein Commit gar keine Version, weil eine Commit-Kennung kein Release ist, und der Upload trägt einen Hinweis, dass das Modul auf einen Commit oder einen Zweig und nicht auf ein Release-Tag festgelegt ist. Legen Sie in diesem zweiten Fall ein Release-Tag in der west.yml fest oder setzen Sie die Version auf der Komponentenseite von Hand. In beiden Fällen gilt: Wissen Sie, welchem Upstream-Release der Commit entspricht, prüfen Sie die Schwachstellentreffer für dieses Modul selbst. Module, die Ihr Build nicht verwendet hat, entfernt Declarable nicht, prüfen Sie deren Treffer also selbst. Die Entscheidung über jeden Treffer bleibt bei Ihnen.

Startet eine Kernel-CVE die 24-Stunden-Frist?

Von sich aus nicht, ob die CVE im Zephyr-Kernel oder in einem Modul steckt. Nach Artikel 14 Absatz 1 meldet ein Hersteller jede aktiv ausgenutzte Schwachstelle, die in dem Produkt mit digitalen Elementen enthalten ist und von der er Kenntnis erlangt; Artikel 14 Absatz 2 Buchstabe a verlangt die Frühwarnung unverzüglich und in jedem Fall innerhalb von 24 Stunden, nachdem der Hersteller davon Kenntnis erlangt hat (beide sinngemäß wiedergegeben; maßgeblich ist der deutsche Wortlaut der Verordnung). Der CRA bestimmt eine aktiv ausgenutzte Schwachstelle als eine Schwachstelle, für die es belastbare Belege dafür gibt, dass ein Angreifer sie in einem System ohne Erlaubnis des Systemeigentümers ausgenutzt hat (Artikel 3 Nummer 42, sinngemäß wiedergegeben). Eine veröffentlichte CVE sagt, dass ein Fehler besteht; über eine Ausnutzung sagt sie nichts, deshalb startet eine neue CVE gegen Zephyr oder mbedTLS von sich aus keine Frist. Was sie startet, ist die Kenntnis belastbarer Belege dafür, dass eine in Ihrem Produkt enthaltene Schwachstelle ausgenutzt wurde. Unsere Lesart (Argument): Diese Belege müssen nicht von Ihren eigenen Geräten kommen, deshalb ist ein glaubwürdiger Bericht über eine Ausnutzung in der Praxis bei einem Fehler in Code, den Ihre Firmware baut, der Zeitpunkt, den Sie als Beginn behandeln sollten; eine CVE in Code, den Ihr Kconfig nicht baut, ist nach unserer Lesart nicht in Ihrem Produkt enthalten. Die Verordnung bestimmt „Kenntniserlangung“ nicht näher, halten Sie deshalb fest, wann und wie Sie von jedem Bericht über eine Ausnutzung erfahren haben und was Sie entschieden haben. Davon unabhängig muss jede Schwachstelle, die Sie ausliefern, weiterhin im Hinblick auf die Risiken im Zusammenhang mit Ihrem Produkt unverzüglich behandelt und behoben werden (Anhang I Teil II Nummer 2), ausgenutzt oder nicht. Article 14, step by step (auf Englisch) geht die Meldungen und ihre Fristen durch.

Was Sie jetzt tun können

1. west spdx in der CI einschalten für jeden Release-Build und die vier Dokumente bei den Release-Artefakten aufbewahren. Die SBOM eines Releases sollte die sein, die aus dem Build dieses Releases entstanden ist.
2. security: external-references ergänzen in der module.yml jedes Moduls, das Sie selbst pflegen, und prüfen, ob die Upstream-Module, von denen Sie abhängen (mbedTLS, LittleFS, LVGL, TF-M und so weiter), sie enthalten. Wo nicht, führen Sie eine eigene Zuordnung von Modul zu CPE oder purl und halten Sie für jedes Modul eine Release-Nummer fest, denn ein festgelegter Commit ist keine.
3. Ihre Blobs auflisten mit Lieferant, Name und Version und die Liste neben der SBOM aufbewahren.
4. Das Ausgabeformat festlegen. Brauchen Sie SPDX 3.0.1 oder CycloneDX 1.6, erzeugen oder wandeln Sie es um und prüfen Sie das Ergebnis.
5. Bei jedem Release und nach Zeitplan mit Schwachstellendaten abgleichen und für jeden Treffer eine Entscheidung festhalten: betroffen, nicht betroffen (mit Begründung) oder behoben.
6. Sich jetzt auf Artikel 14 vorbereiten, denn er gilt bereits: wissen, wer im Unternehmen die Meldung an die ENISA übernimmt und wie Sie eine Frühwarnung innerhalb von 24 Stunden schaffen würden. Siehe unseren Leitfaden „Article 14, step by step“ (auf Englisch).
7. Einen Unterstützungszeitraum festlegen und veröffentlichen, mindestens fünf Jahre, es sei denn, das Produkt wird voraussichtlich kürzer genutzt (Artikel 13 Absatz 8). Siehe „What the support period means“ (auf Englisch).

Was feststeht und was nicht

Steht fest (Beleg): die Termine in Artikel 71, die Pflichten aus Artikel 14 und ihre Wirkung auf Produkte, die schon auf dem Markt sind, sowie die SBOM-Anforderung in Anhang I Teil II Nummer 1.

Steht noch nicht fest (Stand: 8. Oktober 2026): Im Amtsblatt ist keine harmonisierte Norm zum CRA veröffentlicht, und die Kommission hat keinen Durchführungsrechtsakt zu einem SBOM-Format erlassen. Die BSI-Richtlinie ist eine nationale Referenz, keine EU-Vorschrift. Wir aktualisieren diesen Leitfaden, wenn sich eines davon ändert.