What is yours to document and what Zephyr, Yocto and ESP-IDF already cover

If you ship firmware or a Linux image built on Zephyr, Yocto or ESP-IDF, each project already publishes guidance on its own vulnerabilities. This guide points you to that guidance first and then says, in our words, what it leaves to you. It is a factual comparison you can check against the linked pages. We have no working relationship with any of these projects, and nothing here speaks for them. It is a documentation aid, not legal advice.

For the detail on each platform, see our guides "The CRA for Zephyr developers", "The CRA for Yocto teams" and "The CRA for ESP-IDF teams".

Zephyr

Read first: the Zephyr security vulnerability reporting page (checked 8 October 2026). What it tells a maker:

• Vulnerabilities are reported through a draft security advisory on the Zephyr repository or by email to vulnerabilities@zephyrproject.org, and the project's security response team (PSIRT) handles them.
• The embargo is at most 90 days: 30 days inside the project to fix, 60 days for outside parties to apply the fix.
• Advisories and CVEs are tracked on GitHub security advisories and, after the embargo, on the project's vulnerabilities page.
• Per that page, fixes are backported to the current LTS release and the two most recent releases, so check which of those you build on.

Yocto

Read first: the Yocto Project security manual page on vulnerabilities (checked 8 October 2026). What it tells a maker:

• Yocto tracks unfixed CVEs in OpenEmbedded-Core packages and publishes a list of known vulnerabilities with patch status.
• A build-time check can produce a per-image report that sorts CVEs into patched, unpatched and ignored.
• For problems you find, the page recommends working with upstream maintainers and the Yocto contribution process rather than local workarounds.
• On stable branches the project prefers backward-compatible version updates, with patch backports where an update would break compatibility.

ESP-IDF

Read first: Espressif's advisories page (checked 8 October 2026). What it tells a maker:

• It lists security advisories, bug notices, compatibility notices and end-of-life announcements, which you can filter by ESP-IDF version and by chip series.
• Vulnerabilities are reported through Espressif's forms or its bug bounty address (bugbounty@espressif.com), and the page recommends encrypting reports with its published PGP key.
• The filters let you see which notices cover the ESP-IDF release and chip your product uses.

What none of these pages do, and what Declarable does

No upstream project can know your product. Declarable identifies the components in your product from its SBOM and matches them against known vulnerabilities, then asks you for a due-diligence decision on the ones it flags. Separately, your product's Annex III and IV category and its Annex I checklist come from the questions you answer, not from your components. Declarable prepares drafts of the five CRA documents from your answers and tracks your Article 14 deadlines once you log an incident. Everything it produces is a draft for your review, not legal advice.

What stays yours in every case

The project's page tells you about its code. The CRA puts the duty on the manufacturer of your product: the requirements analysis, the technical documentation, the declaration of conformity and the reporting clock under Article 14 are yours whichever platform you build on. See our guide "Article 14, step by step".

What is settled and what is not

Settled (evidence): the pages above say what is summarised here as of 8 October 2026. Not settled: these pages can change, and project policies such as embargo lengths or supported releases are theirs to change. Re-read the linked page before you rely on a detail.