CRA-konformes Release-Management für Embedded-Teams.
SBOM-Generierung, Vulnerability-Tracking und Compliance-Dokumentation in einem CLI. Integriert sich in Yocto und Buildroot. Vollständig selbst-gehostet.
embtrace ersetzt nicht euer Build-System. Yocto baut, embtrace verwaltet — SBOM, Compliance und Release-Traceability obendrauf, ohne euren Workflow zu ändern.
Das Problem
Yoctos create-spdx ist nur der Anfang
Yocto generiert SPDX pro Recipe — aber kein Tool vereinigt sie zu einem Produkt-SBOM, prüft gegen CVEs oder erzeugt CRA-konforme Dokumentation daraus.
CVE-Flut ohne Kontext
200+ CVEs pro Embedded-Linux-Image. Die meisten betreffen deaktivierte Kernel-Module oder bereits gepatchte Versionen. Manuelle Triage kostet Wochen.
September 2026: 24h-Meldepflicht
Ab dem 11. September 2026 müssen aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden an ENISA gemeldet werden. Die erste Frage ist dabei nicht „wie melde ich?", sondern „wird eine meiner Lücken überhaupt gerade ausgenutzt?".
Module
Vier Kernmodule für CRA-Compliance. Drei weitere für den vollständigen Release-Workflow.
SBOM
Automatische SBOM-Generierung aus Yocto, Buildroot, Conan und manuellen Deps
- Yocto SPDX-Import, Buildroot-Integration, Conan/vcpkg-Lockfiles
- FPGA-IP-Cores aus Vivado, Libero SoC und Quartus — nicht nur die Prozessorseite
- CycloneDX 1.6 & SPDX 3.0.1 — von BSI TR-03183 anerkannt, Legacy-Ausgabe 1.5/2.3
- SBOM-Merge über Projektgrenzen hinweg
- BSI TR-03183 Policy-Audit mit Pflichtfeldprüfung
embtrace sbom import | generate | merge | audit | diff
Vulnerability
CVE-Scanning mit Kontext: Kernel-Config-Filtering, Patch-Tracking, VEX-Lifecycle
- OSV.dev, CISA KEV und EPSS als Datenquellen — NVD optional über kuratierte CPE-Zuordnung
- Intelligente Triage: nicht ausnutzbare CVEs automatisch klassifizieren
- VEX-Dokumente (OpenVEX) für Audit-Trails
- Offline-Cache für air-gapped Umgebungen
embtrace sbom vuln | triage
Release
Nachvollziehbare Releases mit Manifest, Changelog und Signierung
- Release-Manifest mit vollständiger Git-Traceability
- Automatischer Changelog aus Conventional Commits
- SBOM-Diff zwischen Releases
- Traceability-Report (HTML + JSON) für Behörden
embtrace release create | diff | changelog | verify
Compliance
CRA-Audit, BSI TR-03183 Validierung, ENISA-Reporting, Evidence-Packages
- Traffic-Light-Audit (Grün/Gelb/Rot) nach CRA + BSI TR-03183
- Lieferketten-Nachweise nach dem ENISA Secure-by-Design-Playbook: SBOM je Release, Scans, Signierung, Lieferanten-Fragebogen, Ausnahmeregister — alle sechs für Prinzip 14 geforderten Belege
- ENISA 24h-Report-Generator (Art. 14)
- Technische Dokumentation (Annex VII) — 10-Jahres-Archivierung
- Evidence-Package für Konformitätsbewertung
embtrace comply audit | enisa-report | documentation | evidence
Weitere Module
Artifact
Artefakt-Management mit Tree-Hash-Deduplizierung und Release-Manifest-Traceability
Update
Sichere Firmware-Pakete (.run + .empkg) mit Ed25519-Signierung, AES-256-GCM, A/B Fail-Safe und Delta-Updates
Image
Flash- und SD-Card-Images mit A/B-Partitionierung, Board-Profilen und QSPI-Support (Zynq UltraScale+, Zynq-7000, RPi)
In der Praxis
Ein typischer CRA-Compliance-Workflow vom Yocto-Build zum Evidence-Package.
# SBOM aus Yocto-Build importieren und zusammenführen embtrace sbom import --source yocto --build-dir ./build embtrace sbom merge --output product-sbom.cdx.json # Gegen bekannte CVEs prüfen embtrace sbom vuln --sbom product-sbom.cdx.json --output vex.json → 12 CVEs gefunden, davon 9 durch Kernel-Config-Filtering irrelevant → 3 CVEs offen: 1 HIGH, 2 MEDIUM # BSI TR-03183 Compliance prüfen embtrace sbom audit --policy bsi-tr-03183 → ✓ 47/47 Pflichtfelder vorhanden → ✗ 2 Komponenten ohne Supplier-Information # CRA Evidence-Package erzeugen (für Konformitätsbewertung) embtrace comply evidence --frameworks cra,bsi-tr-03183 --output evidence/ → evidence/sbom.cdx.json → evidence/vex.json → evidence/audit-report.html → evidence/technical-documentation.pdf
Die Pipeline
embtrace dockt an euren bestehenden Build-Output an — kein Workflow-Wechsel nötig.
Yocto / Buildroot
baut das Image
embtrace ersetzt hier nichts.
SBOM Import
+ CVE-Triage
Artifact Publish
+ Traceability
Release Create
+ Changelog
CRA Evidence
+ Monitoring
Ab 11. September 2026 scharf
Welche Ihrer Schwachstellen wird gerade ausgenutzt?
Ab dem 11. September 2026 müssen aktiv ausgenutzte Schwachstellen binnen 24 Stunden gemeldet werden. Ein CVSS-Wert beantwortet diese Frage nicht — er sagt, wie schlimm eine Lücke wäre, nicht ob sie gerade ausgenutzt wird.
embtrace prüft jeden Fund gegen den CISA-KEV-Katalog — das amtliche Verzeichnis nachweislich aktiv ausgenutzter Schwachstellen (Stand 28.08.2026: 1.685 Einträge) — und annotiert zu jedem Fund die EPSS-Ausnutzungswahrscheinlichkeit samt Einordnung.
Ein Treffer eskaliert alles
Report, Exit-Code und Audit-Ampel gehen auf Rot — unabhängig vom CVSS-Wert. Der Fund steht ganz oben, nicht auf Seite 7.
Auch eine Lücke, die Sie schon abgehakt hatten
Haben Sie einen Fund begründet als „nicht betroffen" bewertet und er taucht später im KEV-Katalog auf, hebt embtrace die Bewertung wieder auf. Aktive Ausnutzung ändert die Risikolage — die Entscheidung muss ausdrücklich erneut bestätigt werden, mit Datum und in der Versionsverwaltung.
Ohne Internet wird nichts behauptet
Ist der Katalog nicht erreichbar, bleibt das Feld leer. „Nicht ausgenutzt" steht nirgends, wo nicht geprüft wurde — auch im abgeschotteten Netz nicht.
Ob im Einzelfall gemeldet werden muss, entscheiden Sie. embtrace liefert die Grundlage, den Zeitstempel — und mit embtrace comply enisa-report die Meldung selbst.
Heterogene Embedded-Plattformen
Ein SoC, mehrere Prozessoren, verschiedene Betriebssysteme — ein Tooling.
Multi-Prozessor SoCs
APU (Cortex-A53, LynxOS/Linux) + RPU (Cortex-R5F, Bare-metal) + FPGA in einem Flash-Image. Synchrone A/B-Updates mit automatischem Rollback.
A/B Fail-Safe Updates
Zwei Firmware-Slots pro Prozessor. Boot-Counter + Watchdog = automatischer Rollback nach 3 Fehlversuchen. Kein Gerät wird gebrickt.
Signiert + Verschlüsselt
Ed25519-Signaturen und AES-256-GCM auf jedem Update-Paket. Secure Boot Chain vom BootROM bis zur Applikation. CRA Annex I konform.
# Flash-Image erstellen (APU + RPU + FPGA in einem Binary) embtrace image create-flash --board zynq-ultrascale-baremetal \ --slot apu_a:lynxos.elf --slot rpu_a:rpu_fw.elf \ --slot fpga:design.bit --output flash.bin # Signiertes Feld-Update erstellen embtrace update bare-metal \ --target apu:lynxos-v2.1.elf:2.1.0 \ --target rpu:rpu-fw-v2.1.elf:2.1.0 \ --output firmware-v2.1.0.empkg embtrace update sign --key release.key --input firmware-v2.1.0.empkg embtrace update encrypt --key-env ENCRYPT_KEY --input firmware-v2.1.0.empkg
Was im FPGA steckt, steht in der Stückliste
Fast jedes Werkzeug liest die Prozessorseite. Die fremde IP im FPGA bleibt dabei meist unsichtbar — obwohl sie fremder Code in eurem Produkt ist und nach CRA in die Stückliste gehört. embtrace liest sie direkt aus dem Projekt eurer Werkzeugkette.
AMD/Xilinx Vivado — IP-Cores automatisch mit Version und Lieferant.
Microchip Libero SoC — IP-Cores automatisch mit Lieferant und Version; die Version kommt aus dem generierten Projekt. Nur in nie generierten Repos bleibt sie offen — dann wird sie als offen ausgewiesen, nicht geraten.
Intel/Altera Quartus Prime — die im Projektbaum hinterlegten IP-Definitionen mit Version und Lieferant. Welche davon ein Platform-Designer-System tatsächlich einbindet, löst embtrace noch nicht auf.
Der Bitstream selbst — als Artefakt mit SHA-256, Design-Name, Zielbaustein und Build-Datum rückverfolgbar erfasst.
Und was nicht geht, sagt embtrace auch: Gegen Schwachstellendatenbanken sind FPGA-IP-Cores nicht prüfbar. embtrace weist diese Komponenten ausdrücklich als ungeprüft aus, statt euch eine grüne Ampel für etwas zu zeigen, das gar nicht geprüft wurde.
Was embtrace nicht ist
Kein Build-System. Yocto, Buildroot und euer CI bleiben wie sie sind. embtrace baut nichts selbst.
Keine OTA-Cloud-Plattform. Für Linux-Geräte bleibt Mender/SWUpdate/RAUC der OTA-Mechanismus. Für Bare-metal und RTOS liefert embtrace eigene A/B-Updates mit Signierung und Rollback.
Die fehlende Schicht dazwischen: Vom Build-Output zum CRA-konformen Release — SBOM, Compliance und Traceability, ohne euren bestehenden Stack zu ersetzen.
EU Cyber Resilience Act
Was der CRA verlangt
- Maschinenlesbares SBOM für alle Produkte (Art. 13(15))
- Aktives Vulnerability-Management (Art. 13(6))
- Technische Dokumentation, 10 Jahre Aufbewahrung (Art. 13(12), Annex VII)
- ENISA-Meldepflicht bei aktiv ausgenutzten Schwachstellen (Art. 14)
- Mindestens 5 Jahre Sicherheitssupport (Art. 13(8))
Was embtrace liefert
-
embtrace sbom import | merge— CycloneDX & SPDX aus Yocto/Buildroot/Conan -
embtrace sbom vuln— CVE-Check gegen OSV.dev + NVD -
embtrace comply documentation— Art. 13 / Annex VII, 10 Jahre -
embtrace comply enisa-report— Art. 14 Erstmeldung in 24h -
embtrace comply audit --policy cra— Support-Zeitraum-Prüfung
Integrationen
embtrace spricht die Sprache eures Embedded-Stacks.
Build-Systeme
FPGA-Werkzeugketten
Hardware-Plattformen
CI/CD
Standards & Datenquellen
Keine externen Dienste erforderlich. Vollständig selbst-gehostet. Läuft auf Linux — dort wo Embedded-Entwicklung stattfindet. Kein US CLOUD Act. DSGVO-konform.
Entwickelt von Innomatica GmbH — basierend auf über 10 Jahren Erfahrung in Embedded-Software-Entwicklung und Prozessberatung für Industriekunden. DSGVO-konform. Keine Cloud-Abhängigkeit. Kein US CLOUD Act.
Bereit für CRA-Compliance?
Wir begleiten Embedded-Teams auf dem Weg zur CRA-Konformität — vom ersten Audit bis zum zertifizierten Release.