Public
Hi OpenAMP TSC,
Based on the March 2026 OpenAMP Board meeting, the OpenAMP System Reference working group has been discussing what needs to be done in preparation for the EU Cyber Resilience Act.
Conclusions:
* Given OpenAMP's very low membership fee and low level of contributor bandwidth, it is not currently feasible to set up a Security team & Security support will be on a reasonable-effort basis * We can at least set up security reporting using built-in GitHub functionalityhttps://www.google.com/url?q=https://docs.github.com/en/code-security/how-tos/report-and-fix-vulnerabilities/configure-vulnerability-reporting/configure-for-a-repository&sa=D&source=docs&ust=1788480603352857&usg=AOvVaw3LF6Nx5UE6NDYXKEvF9l1T to track what has been reported & evaluated * The OpenAMP System Reference working group has drafted a security policy below * For the repos in the OpenAMP org that are staging forks of some upstream project, we should have a different security.md pointing people to submit their advisories to the upstream & that the staging repos are not security-supported. * Based on Greg KH's Embedded Recipes talkhttps://youtu.be/u44eMQpGlxA?si=ZFgGuCZVBIYnbHi0&t=750 12:30-13:32, it sounds like this is sufficient for compliance: "Part of the CRA is going to require manufacturers to report vulnerabilities that they find. They have to report it to you, the creator of the software, and they have to report it to the EU through ENISA. They just need a way to contact you. And you don't have to fix the problem. They just have to contact you. They can provide a fix if they want, but you don't have to take the fix." * If any OpenAMP member disagrees with this level of support, they should contribute staffing and/or propose how to fund a higher level of support. * E.g. maybe it is less costly to the member(s) to implement these fixes upstream
Votes can be sent directly to me with Arnaud in CC. The rules for the vote are the same applied for Board voting, described in the charterhttps://www.openampproject.org/docs/OpenAMPProject_Charter_Approved2024AugEmailVote.pdf. TSC voting members will get a reminder in about a week & voting will close on 17th Sept, 2026.
=== Purpose This policy outlines how security issues in repos of the OpenAMP GitHub organization should be reported, how they are handled, and what users can expect from the OpenAMP Project.
Scope OpenAMP does not ship products or deployable binaries; it supplies source code and reference implementations only.
Because the project team has very limited visibility into how the code is incorporated downstream and very limited maintainer time, consumers of the OpenAMP code are responsible for implementing any security fixes, mitigations, or processes that meet their own regulatory or product-specific requirements. Organisations placing devices or software on the EU market under the CRA remain accountable for performing their own risk and conformity assessments, generating and maintaining any required SBOMs, and any other EU CRA compliance.
Fixes contributed for reported issues will be evaluated and merged on a reasonable-effort basis. The OpenAMP project welcomes patches that improve CRA alignment, provided they do not impose an unsustainable maintenance burden on the community.
Security support is limited to the next release: fixes will be added to the main branch of the relevant repositories. Earlier versions remain available as-is, but do NOT receive security updates.
Response targets Acknowledgement, assessment & publishing of advisories will occur on a reasonable-effort basis. If you need a faster turnaround, please consider contributing a fix or maintaining a downstream fork.
Reporting a Vulnerability If you discover a security vulnerability in OpenAMP, please report it privately and responsibly: open a confidential security issue on at https://github.com/OpenAMP/<repository-with-the-issue>/security/advisories
Please include:
* If you/your company is reporting this issue under embargo so that you have time to provide a fix. * If reported under embargo, OpenAMP will respect the reporter's request for a limited time (up to 90 days), after which public disclosure may occur. * A clear description of the vulnerability. * Steps to reproduce the issue. * Any relevant details (affected components and versions, possible impact, etc.) * If an AI tool was used to discover the issue (Assisted-by: [Agent Name]:[Model Version] [Tool1] [Tool2])
GitHub How-to documentation on privately reporting a security vulnerability can be found herehttps://docs.github.com/en/code-security/how-tos/report-and-fix-vulnerabilities/report-privately.
To keep this process safe and productive for everyone, all reports and related activities must comply with the OpenAMP Project code of conducthttps://www.openampproject.org/conduct.
No Pre-disclosure List
* OpenAMP does not maintain a pre-disclosure list or offer embargoed advisories to downstream users.
Publication of Security Advisories Advisories will be published at https://github.com/OpenAMP/<repository>/security/advisories.
Reported issues that are assessed to be purely theoretical and not applicable in any real hardware system will be documented as "[Fix not planned]".
Limitations of Liability & No Legal Advice This document is provided "AS IS" and does not constitute legal advice. The OpenAMP project members make no warranties regarding compliance with any law or regulation. Use at your own risk. ===
Thanks & regards, Nathalie