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 September 2026 müssen aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden an ENISA gemeldet werden. Ohne automatisiertes Monitoring ist das nicht zu schaffen.
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
- CycloneDX 1.5 & SPDX 2.3 — beide CRA-konform
- 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 + NVD + CISA KEV als Datenquellen
- 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
- 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
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 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
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.