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 11 September 2026, actively exploited vulnerabilities must be reported to ENISA within 24 hours. The first question is not “how do I report?” but “is one of my flaws being exploited at all?”
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
- FPGA IP cores from Vivado, Libero SoC and Quartus — not just the processor side
- CycloneDX 1.6 & SPDX 3.0.1 — recognised by BSI TR-03183, legacy output 1.5/2.3
- 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, CISA KEV and EPSS as data sources — NVD optional via curated CPE mapping
- 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
- Supply-chain evidence per the ENISA Secure-by-Design Playbook: per-release SBOM, scans, signing, supplier questionnaires, exception log — all six artefacts required for principle 14
- 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
In force from 11 September 2026
Which of your vulnerabilities is being exploited right now?
From 11 September 2026, actively exploited vulnerabilities must be reported within 24 hours. A CVSS score does not answer that question — it tells you how bad a flaw would be, not whether it is being exploited.
embtrace checks every finding against the CISA KEV catalog — the official register of vulnerabilities demonstrably under active exploitation (1,685 entries as of 28 Aug 2026) — and annotates the EPSS exploitation probability on every finding, with context.
One hit escalates everything
Report, exit code and audit status all go red — regardless of the CVSS score. The finding leads the report instead of sitting on page 7.
Including a flaw you had already closed out
If you assessed a finding as “not affected” with a reason and it later appears in the KEV catalog, embtrace reopens that assessment. Active exploitation changes the risk picture — the decision has to be confirmed again, explicitly, with a date and in version control.
Offline, nothing is claimed
If the catalog cannot be reached, the field stays empty. “Not exploited” never appears where nothing was checked — air-gapped networks included.
Whether a given case must be reported is your call. embtrace supplies the basis, the timestamp — and with embtrace comply enisa-report the notification itself.
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 sits inside the FPGA belongs in the bill of materials
Almost every tool reads the processor side. Third-party IP inside the FPGA usually stays invisible — although it is third-party code in your product and belongs in the bill of materials under the CRA. embtrace reads it straight from your toolchain’s project.
AMD/Xilinx Vivado — IP cores detected automatically, with version and supplier.
Microchip Libero SoC — IP cores detected automatically with supplier and version; the version comes from the generated project. Only in repositories that were never generated does it stay open — and then it is flagged as open, not guessed.
Intel/Altera Quartus Prime — the IP definitions held in the project tree, with version and supplier. Which of them a Platform Designer system actually instantiates is not yet resolved.
The bitstream itself — recorded as a traceable artifact with SHA-256, design name, target device and build date.
And embtrace says what it cannot do: FPGA IP cores cannot be matched against vulnerability databases. embtrace marks those components as unchecked rather than showing you a green light for something that was never checked.
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
FPGA Toolchains
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.