CRA-compliant release management for embedded teams.
SBOM generation, vulnerability tracking, and compliance documentation in one CLI. Integrates with Yocto and Buildroot. Fully self-hosted.
embtrace doesn't replace your build system. Yocto builds, embtrace manages — SBOM, compliance, and release traceability on top, without changing your workflow.
The Problem
Yocto's create-spdx is just the start
Yocto generates SPDX per recipe — but no tool merges them into a product SBOM, checks against CVEs, or generates CRA-compliant documentation from them.
CVE flood without context
200+ CVEs per embedded Linux image. Most affect disabled kernel modules or already-patched versions. Manual triage takes weeks.
September 2026: 24h reporting obligation
From September 2026, actively exploited vulnerabilities must be reported to ENISA within 24 hours. Impossible without automated monitoring.
Modules
Four core modules for CRA compliance. Three more for the complete release workflow.
SBOM
Automatic SBOM generation from Yocto, Buildroot, Conan and manual deps
- Yocto SPDX import, Buildroot integration, Conan/vcpkg lockfiles
- CycloneDX 1.5 & SPDX 2.3 — both CRA-compliant
- SBOM merge across project boundaries
- BSI TR-03183 policy audit with mandatory field checks
embtrace sbom import | generate | merge | audit | diff
Vulnerability
CVE scanning with context: kernel config filtering, patch tracking, VEX lifecycle
- OSV.dev + NVD + CISA KEV as data sources
- Intelligent triage: auto-classify non-exploitable CVEs
- VEX documents (OpenVEX) for audit trails
- Offline cache for air-gapped environments
embtrace sbom vuln | triage
Release
Traceable releases with manifest, changelog and signing
- Release manifest with full Git traceability
- Automatic changelog from Conventional Commits
- SBOM diff between releases
- Traceability report (HTML + JSON) for authorities
embtrace release create | diff | changelog | verify
Compliance
CRA audit, BSI TR-03183 validation, ENISA reporting, evidence packages
- Traffic-light audit (Green/Yellow/Red) per CRA + BSI TR-03183
- ENISA 24h report generator (Art. 14)
- Technical documentation (Annex VII) — 10-year archival
- Evidence package for conformity assessment
embtrace comply audit | enisa-report | documentation | evidence
Additional Modules
Artifact
Artifact management with tree-hash deduplication and release manifest traceability
Update
Secure firmware packages (.run + .empkg) with Ed25519 signing, AES-256-GCM, A/B fail-safe and delta updates
Image
Flash and SD card images with A/B partitioning, board profiles and QSPI support (Zynq UltraScale+, Zynq-7000, RPi)
In Practice
A typical CRA compliance workflow from Yocto build to evidence package.
# Import and merge SBOM from Yocto build embtrace sbom import --source yocto --build-dir ./build embtrace sbom merge --output product-sbom.cdx.json # Check against known CVEs embtrace sbom vuln --sbom product-sbom.cdx.json --output vex.json → 12 CVEs found, 9 classified irrelevant via kernel config filtering → 3 CVEs open: 1 HIGH, 2 MEDIUM # Check BSI TR-03183 compliance embtrace sbom audit --policy bsi-tr-03183 → ✓ 47/47 mandatory fields present → ✗ 2 components without supplier information # Generate CRA evidence package (for conformity assessment) 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
The Pipeline
embtrace attaches to your existing build output — no workflow change required.
Yocto / Buildroot
builds the image
embtrace replaces nothing here.
SBOM Import
+ CVE Triage
Artifact Publish
+ Traceability
Release Create
+ Changelog
CRA Evidence
+ Monitoring
Heterogeneous Embedded Platforms
One SoC, multiple processors, different operating systems — one tooling.
Multi-Processor SoCs
APU (Cortex-A53, LynxOS/Linux) + RPU (Cortex-R5F, bare-metal) + FPGA in a single flash image. Synchronized A/B updates with automatic rollback.
A/B Fail-Safe Updates
Two firmware slots per processor. Boot counter + watchdog = automatic rollback after 3 failed attempts. No device gets bricked.
Signed + Encrypted
Ed25519 signatures and AES-256-GCM on every update package. Secure boot chain from BootROM to application. CRA Annex I compliant.
# Create flash image (APU + RPU + FPGA in one 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 # Create signed field update 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
What embtrace is not
Not a build system. Yocto, Buildroot, and your CI stay exactly as they are. embtrace builds nothing itself.
Not an OTA cloud platform. For Linux devices, Mender/SWUpdate/RAUC remains the OTA mechanism. For bare-metal and RTOS, embtrace provides its own A/B updates with signing and rollback.
The missing layer in between: From build output to CRA-compliant release — SBOM, compliance and traceability, without replacing your existing stack.
EU Cyber Resilience Act
What CRA requires
- Machine-readable SBOM for all products (Art. 13(15))
- Active vulnerability management (Art. 13(6))
- Technical documentation, 10-year retention (Art. 13(12), Annex VII)
- ENISA reporting for actively exploited vulnerabilities (Art. 14)
- At least 5 years of security support (Art. 13(8))
What embtrace delivers
-
embtrace sbom import | merge— CycloneDX & SPDX from Yocto/Buildroot/Conan -
embtrace sbom vuln— CVE check against OSV.dev + NVD -
embtrace comply documentation— Art. 13 / Annex VII, 10 years -
embtrace comply enisa-report— Art. 14 initial report within 24h -
embtrace comply audit --policy cra— support period check
Integrations
embtrace speaks the language of your embedded stack.
Build Systems
Hardware Platforms
CI/CD
Standards & Data Sources
No external services required. Fully self-hosted. Runs on Linux — where embedded development happens. GDPR-compliant. No US CLOUD Act.
Developed by Innomatica GmbH — based on over 10 years of experience in embedded software development and process consulting for industrial customers. GDPR-compliant. No cloud dependency. No US CLOUD Act.
Ready for CRA compliance?
We guide embedded teams to CRA conformity — from the first audit to a certified release.