Security BSP Releases

Dedicated security releases for EZ BSP address critical and high-severity vulnerabilities outside of the regular feature release cadence. Each release includes full patch notes, affected modules, and upgrade instructions.

Security-BSP-Releases-Icon-White-Outline.png

Software Vulnerability Management for Long-Term Linux Platforms

Keeping your Linux-based device secured across a long product lifetime — from initial image build through continuous CVE monitoring and remediation.

EZ BSP
1
Select EZ BSP Release

Pick an Ezurio EZ BSP release for your platform and target product lifetime.

→
EZ BSP
2
Build Initial Image & Generate SBOM

EZ BSP builds your initial image and generates a full Software Bill of Materials.

→
EZ BSP
3
Vulnerability (CVE) Monitoring & Reporting

Your SBOM feeds into CVE monitoring tools that track every package against upstream vulnerability feeds.

4
CVE Triage

Triage known CVEs and decide whether each vulnerability applies to your specific product and use case.

→
5
CVE Remediation Decision

Choose your fix path: per-package patching, merging LTS kernel and Yocto / Buildroot updates, or moving to a new major release.

→
6
Merge in Code Updates

Merge the code changes required by your chosen remediation strategy. Ezurio can perform this as a paid service based on integration effort.

EZ BSP Security BSP Releases
7
Rebuild Image, QA & Release

Build the patched image, complete QA, and release the updated image to your OTA update system.

→
EZ BSP Security BSP Releases
8
Release Image to the Field

Your OTA system delivers the update to devices already in service — and the cycle continues.

Back to step 1 ↑

SBOM Generation for Vulnerability Management

From steps 2 and 3 above

Yocto- and Buildroot-based BSPs generate standard SBOMs for whatever CVE tool you already run — no vendor lock-in.

1
Build Ezurio BSPs built on Yocto & Buildroot
→
2
Generate SBOM Standard SBOM emitted automatically at build time
→
3
Scan & Monitor Upload to the CVE tool you already run

Yocto & Buildroot SBOMs

  • Yocto SPDX 2.2 & 3.0 (JSON / JSON-LD, VEX in 3.0), generated at build time.
  • Buildroot CycloneDX 1.6 via make show-info, plus SPDX license data from legal-info.

Compatible CVE Scanning Tools

  • IT & cloud Dependency-Track, Grype + Syft, OSV-Scanner, Snyk, Black Duck, FOSSA, JFrog Xray.
  • Embedded Lynx Vigiles, ONEKEY, The Embedded Kit CVE Scan, cve-bin-tool.

Compliance-Ready

  • Regulatory mandates EU CRA, US EO 14028, NTIA minimum elements.
  • Industry standards IEC 62443 (industrial) & IEC 62304 (medical SOUP).

Built-in CVE Checkers in Yocto and Buildroot

From step 3 above

Yocto and Buildroot each ship a native CVE checking tool that checks your SBOM against the National Vulnerability Database (NVD) for known vulnerabilities — at no extra cost, at build time.

Yocto — cve-check

  • Enable Add INHERIT += "cve-check" to map every recipe to the NVD during the BitBake build.
  • Output cve-summary.json in tmp/deploy/cve — each CVE flagged as Patched / Unpatched / Ignored, with CVSS scores and NVD links.
  • Suppress false positives Auto-marks fixes found in patch filenames or CVE: tags; tune with CVE_STATUS flags and CVE_CHECK_SKIP_RECIPE.

Buildroot — make pkg-stats

  • Run make pkg-stats (with --nvd-path) scans the whole config in a single pass.
  • Output HTML + JSON listing packages affected by CVEs and total counts — plus upstream-version drift, license, and patch data.
  • Suppress false positives Silence known false positives with _IGNORE_CVES; sharpen matching via _CPE_ID_* variables.

These results are NVD-based and point-in-time, with many false positives — the kernel especially. They are a useful first check, but not a substitute for enterprise scanning tools such as Lynx Vigiles without significant additional customer tooling.

BSP Releases

EZ BSP ships new LTS BSPs annually — each with two standard releases on a six-month cadence. When CVEs require a fix outside that planned roadmap, Ezurio delivers additional security BSP releases under an NRE model.

New BSPs every year

New Yocto and Buildroot BSPs annually — including the Linux kernel.

2 standard releases

Six-month cadence per BSP — the foundation of your security lifecycle.

Increased frequency available

More frequent security releases beyond the standard cadence, available per commercial agreement.

Additional years of support for LTS kernel / Yocto / Buildroot

Further releases after the two standard releases per major BSP, available via commercial agreement.

Security BSP Release Roadmap

BSP Track This Year Next Year Year +2 Year +3
Q1Q2Q3Q4 Q1Q2Q3Q4 Q1Q2Q3Q4 Q1Q2Q3Q4
Current Kernel, Yocto, Buildroot R1 R2 Further releases under NRE
Next Kernel, Yocto, Buildroot R1 R2 Further releases under NRE
Following Kernel, Yocto, Buildroot R1 R2 Further releases under NRE
R1 Release 1 R2 Release 2 Shaded cells = further releases available under NRE agreement
Out-of-cycle releases are extra work beyond the planned roadmap above. Because they fall outside the standard cadence, they are delivered per consultation under an NRE (time & materials) model — resource and time intensive.
From Step 5 — CVE Remediation Decision
From Steps 6 and 7 — Merge in BSP Updates, Rebuild Image, QA
1
BSP Update Path Decision

Decide the fix path: per-package patching, merge in LTS kernel + LTS Yocto / Buildroot, or jump to a new major kernel + Yocto / Buildroot.

2
Updated BSP Release

Updated BSP releases out of our normal cycle to address CVEs.

3
QA Re-test

Ezurio QA re-tests the BSP and hardware combination to preserve features.

4
Outsource Retesting

You outsource the burden of retesting core BSP functionality to Ezurio.

BSP Releases

EZ BSP ships new LTS BSPs annually — each with two standard releases on a six-month cadence. When CVEs require a fix outside that planned roadmap, Ezurio delivers additional security BSP releases under an NRE model.

New BSPs every year

New Yocto and Buildroot BSPs annually — including the Linux kernel.

2 standard releases

Six-month cadence per BSP — the foundation of your security lifecycle.

Increased frequency available

More frequent security releases beyond the standard cadence, available per commercial agreement.

Additional years of support for LTS kernel / Yocto / Buildroot

Further releases after the two standard releases per major BSP, available via commercial agreement.

Security BSP Release Roadmap

BSP Track This Year Next Year Year +2 Year +3
Q1Q2Q3Q4 Q1Q2Q3Q4 Q1Q2Q3Q4 Q1Q2Q3Q4
Current Kernel, Yocto, Buildroot R1 R2 Further releases under NRE
Next Kernel, Yocto, Buildroot R1 R2 Further releases under NRE
Following Kernel, Yocto, Buildroot R1 R2 Further releases under NRE
R1 Release 1 R2 Release 2 Shaded cells = further releases available under NRE agreement
Out-of-cycle releases are extra work beyond the planned roadmap above. Because they fall outside the standard cadence, they are delivered per consultation under an NRE (time & materials) model — resource and time intensive.
From Step 5 — CVE Remediation Decision
From Steps 6 and 7 — Merge in BSP Updates, Rebuild Image, QA
1
BSP Update Path Decision

Decide the fix path: per-package patching, merge in LTS kernel + LTS Yocto / Buildroot, or jump to a new major kernel + Yocto / Buildroot.

2
Updated BSP Release

Updated BSP releases out of our normal cycle to address CVEs.

3
QA Re-test

Ezurio QA re-tests the BSP and hardware combination to preserve features.

4
Outsource Retesting

You outsource the burden of retesting core BSP functionality to Ezurio.

EZ BSP Device Side OTA Framework

One device-side framework, many backends. SWUpdate's hawkBit interface lets you choose the management system.

Managed cloud service

Memfault — OTA + device monitoring & crash reporting

Bosch IoT Rollouts — managed service from the hawkBit maintainers

Microsoft Azure Device Update — official SWUpdate handler for IoT Hub

AWS IoT — full-system updates via IoT Jobs

Qbee — OTA + device monitoring via Qbee agent

Self-hosted · free & open source

Eclipse hawkBit — run on-prem or in your own cloud, no license fees, no per-device SaaS

Rollout campaigns, device groups & staged deployments via REST Management API

Production-proven — the basis of the commercial managed services

How it connects

suricatta mode speaks the hawkBit DDI standard — polls, downloads, verifies, installs A/B, reports status

Same signed .swu image regardless of backend

Supports local / USB / manual install — no server needed

Switching backends does not change the device image

Device Management Cloud Memfault / Azure / hawkBit / AWS IoT
▼
SWUpdate suricatta polls · downloads · verifies · installs
Updates applied: 0
Idle
→
Download
→
Verify
→
Write
→
Reboot
→
Switch
Ready to update · Bank A is active
Bank A
Full Linux OS
● ACTIVE
bootloader_a v1.4.2
kernel_a 6.12.x
rootfs_a v1.4.2
Bank B
Full Linux OS
○ STANDBY
bootloader_b v1.4.1
kernel_b 6.12.x
rootfs_b v1.4.1
/data — Shared user data · persists across every update
Accelerate Dev Built-in update tooling — no DIY plumbing
Powered by SWUpdate Open-source OTA engine · signed images
Any Backend Memfault · Azure · AWS IoT · hawkBit · self-hosted
Chain of Trust icon

Chain of Trust

  • Device security framework using secure boot with hardware root of trust and secure device storage
  • Production-Grade Image Signing - Secure signing service for generating signed firmware and certificates, backed by AWS
  • Manufacturing Provisioning -Mass programming of hardware root of trust and secure image programming with optional provisioning of customer-specific application keys, certificates, and credentials
Security BSP Releases icon

Security BSP Releases

  • LTS Linux kernel, Yocto, and Buildroot releases out of our normal cycle to address CVEs
  • Ezurio QA re-tests the BSP/hardware combination to preserve features
  • Customer outsources the burden of retesting core BSP functionality
  • Yocto & Buildroot generate SBOMs for use in customer’s CVE scanner or each build system’s built in CVE scanner.
  • Supports EU CRA, EO 14028 & NTIA SBOM compliance
FIPS Cryptographic Modules icon

FIPS Cryptographic Modules

  • FIPS 140-3 Level 1 certified
  • Wi-Fi data-in-transit
  • TLS data-in-transit
  • Currently on 60 Series SOM
  • In design for Carbon AM62L
  • Required for medical, government, defense