Security, Regulatory and CRA Discussion

← Agenda · ZMF#2 · 2026-10-06 · 3:45 PM - 5:30 PM

Key Speakers, Leads, and Required Attendees

• Martin Jäger, A Labs & Libre Solar (Lead Organizer & Moderator) *
• Kate Stewart, Linux Foundation (Co-host) *
• David Brown, Linaro (Security Chair)
• Flavio Ceolin, Hubble Network (Security Architect)

Decision or Outcome Sought

By the end of this session, participants should have:

• Agreed on:
  • Process how vulnerabilities can be automatically matched with a specific Zephyr application
  • To what extent the project shall support product developers with necessary steps for certification
  • How the Zephyr Project itself can fulfill the reporting obligations for CRA
• Identified:
  • Gaps in documentation for CRA process
  • Gaps in tooling / infrastructure for the Zephyr Project itself
  • Possible areas for improvement in subsystems to provide technical foundation for secure devices
• Assigned:
  • [Owner and next action]

Problem Statement

The EU Cyber Resilience Act imposes obligations on open source projects and manufacturers of products with digital elements for the EU, with vulnerability-reporting obligations applying from September 2026 and the main essential requirements from December 2027.

Zephyr already has tools e.g. for SBOM generation in place. However, becoming (and staying) CRA compliant requires much more:

• Risk Assessment considering possible threats and attack vectors of a particular product
• Continuous monitoring of published vulnerabilities and matching with used software components (based on the SBOM)
• Reporting, fixing of vulnerabilities and deploying the fixes to devices in the field

Relevant issues and PRs:

• Documentation
  • RED Cybersecurity Requirements (EN 18031-x) Issue: https://github.com/zephyrproject-rtos/zephyr/issues/85687 PR: https://github.com/zephyrproject-rtos/zephyr/pull/120713
  • WIP Harmonized Standards for CRA (EN 40000-1-x) PR: https://github.com/zephyrproject-rtos/zephyr/pull/120742
• SBOM, SPDX and Metadata
  • Vulnerabilities/CVE in Zephyr modules https://github.com/zephyrproject-rtos/zephyr/issues/53479
• Automated Vulnerability Tracking
  • Yocto project cve-check equivalent for vulnerability check at build time https://github.com/zephyrproject-rtos/zephyr/issues/85570

Tools:

• Benjamin's SBOM visualizer: kartben.github.io/spdx3_viz/
• Dependency Track dependencytrack.org
• VulnScout vulnscout.io

Scope

In scope

• Regulatory frameworks (RED and CRA) and their requirements
• Defining guidance / best practices for vulnerability monitoring
• Available and necessary tools specifically for the Zephyr ecosystem
• Gaps in documentation, tooling and subsystems

Out of scope

• The inbound side of vulnerability reporting (see ZMF#4)
• Risk assessment and any product-specific processes and tools

Questions Requiring Agreement

Decision 1: Mapping between Regulatory Requirements and Zephyr Features

Decision required:

Do we want to provide explicit guidance for Zephyr users with pointers to subsystems that help them fulfilling specific requieremenst?

If yes, we need to keep this up to date and somehow state which feature is supported on which hardware (if possible at all).

Possible outcomes:

• Yes and the open PRs can be used for further discussion (in the PR).
• No, leave this to product developers.

Decision 2: Vulnerability Exploitability eXchange (VEX)

Decision required:

Do we want/need to create VEX for every reported vulnerability?

Related: https://github.com/kartben/zephyr/pull/541

Possible outcomes:

• Yes.
• No, [state reason here]

Decision 3: CRA Reporting Obligations

Decision required:

With the huge incoming numbers of bug reports and CVEs, which process do we want to establish for automated reporting to the CSIRT and ENISA?

Possible outcomes:

• [Option]
• [Option]
• [Option]

Proposed Session Agenda

• Regulatory Frameworks (15 min)
• Processes and Tooling (15 min)
• Discussion (1 hours)
• Wrap-up (15 minutes)