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.
Jochwacht doesn't replace your build system. Yocto builds, Jochwacht 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
Since 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
sbom import | generate | merge | audit | diff
Vulnerability
CVE scanning with context: kernel config filtering, patch tracking, VEX lifecycle
- OSV.dev, CISA KEV, EUVD 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
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
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
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 sbom import --source yocto --build-dir ./build sbom merge --output product-sbom.cdx.json # Check against known CVEs 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 sbom audit --policy bsi-tr-03183 → ✓ name, version, licence, PURL: 47/47 → ⚠ supplier: 45/47 — mandatory field incomplete → Result: YELLOW. The report names the gap instead of claiming conformity. # Generate CRA evidence package (for conformity assessment) 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
Jochwacht attaches to your existing build output — no workflow change required.
Yocto / Buildroot
builds the image
Jochwacht replaces nothing here.
SBOM Import
+ CVE Triage
Artifact Publish
+ Traceability
Release Create
+ Changelog
CRA Evidence
+ Monitoring
In force since 11 September 2026
Which of your vulnerabilities is being exploited right now?
Since 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.
Jochwacht checks every finding against two lists: the US one (CISA KEV) and the European one (EUVD) — 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 on either list, Jochwacht 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. Jochwacht supplies the basis, the timestamp — and with comply enisa-report the notification itself.
We know both worlds
A modern device is rarely just one thing. Underneath runs C firmware from a Yocto or CMake build. On top sits a service layer in Python or Node.
The usual tools handle one or the other. If you have both, you run two tools and merge the results by hand. That is where the gaps appear.
We read both in one run. One bill of materials, one report, one timestamp.
Supplier and licence rarely appear in the build
The report carries them anyway. We fill them in from a curated knowledge base: over 50,000 entries across both worlds, from npm and Cargo to Yocto, Buildroot and CMake. That happens on our side, when the report is generated — the file in your project folder stays what your build gives you.
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) 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 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 update sign --key release.key --input firmware-v2.1.0.empkg 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. Jochwacht 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 Jochwacht says what it cannot do: FPGA IP cores cannot be matched against vulnerability databases. Jochwacht marks those components as unchecked rather than showing you a green light for something that was never checked.
What Jochwacht is not
Not a build system. Yocto, Buildroot, and your CI stay exactly as they are. Jochwacht builds nothing itself.
Not an OTA cloud platform. For Linux devices, Mender/SWUpdate/RAUC remains the OTA mechanism. For bare-metal and RTOS, Jochwacht 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.
Two duties, two clocks
Since 11 September the reporting duty applies. If a component from your device appears on a list of actively exploited vulnerabilities, you have 24 hours for the early warning. The first question is always the same: which of my products contain that component?
By December 2027 the conformity evidence follows. An audit report, the supporting records, a signed archive that still shows years later what went into which shipment.
Both work on the same data. It is the same bill of materials. It answers the 24-hour question in an emergency and carries the evidence in 2027. Become able to report today and most of the road is behind you.
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 Jochwacht delivers
-
sbom import | merge— CycloneDX & SPDX from Yocto/Buildroot/Conan -
sbom vuln— CVE check against OSV.dev + NVD -
comply documentation— Art. 13 / Annex VII, 10 years -
comply enisa-report— Art. 14 initial report within 24h -
comply audit --policy cra— support period check
Integrations
Jochwacht 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?
The free check shows you within 24 hours which components are in your product and where the known gaps are. One command, one report, no strings attached.