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 functionality<https://www.google.com/url?q=https://docs.github.com/en/code-security/how-t…> 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 talk<https://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 charter<https://www.openampproject.org/docs/OpenAMPProject_Charter_Approved2024AugE…>. 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 here<https://docs.github.com/en/code-security/how-tos/report-and-fix-vulnerabili…>.
To keep this process safe and productive for everyone, all reports and related activities must comply with the OpenAMP Project code of conduct<https://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
Public
Hi all,
Notes from the call are posted at:
https://github.com/OpenAMP/openamp-system-reference/wiki/OpenAMP-System-Ref…
Summary of action items:
* Arnaud: Review openamp-system-reference PR #115<https://github.com/OpenAMP/openamp-system-reference/pull/115>
* Arnaud: Confirm whether openamp-system-reference PR #117<https://github.com/OpenAMP/openamp-system-reference/pull/117> has impact on docs & open-amp CI
* Tanmay: Create new PR for udev access rules only (splitting from openamp-system-reference PR #101<https://github.com/OpenAMP/openamp-system-reference/pull/101>)
* Tanmay: Review openamp-system-reference PR #94<https://github.com/OpenAMP/openamp-system-reference/pull/94> latest updates from Ben
* Tanmay: Come up with plan for DCache build option deprecation (introduce in libmetal, remove from OpenAMP, support both in parallel for one release)
* Tanmay: Send v8 of Linux kernel reset mechanism patch (task 4) based on Mathieu's review of v7
* Andrew or Tanmay: Open PR to remove D-cache option from OpenAMP once libmetal option is in place
* Nathalie: Check status of security policy and report back
* Nathalie: (IN PROGRESS) Ping Mark Hatle on Slack re meta-openamp PR #51 (Bill proposed closing)
* Nathalie: (DONE) Send updated meeting invitation to shift next call to Tuesday
Please let us know if you spot any errors or important omissions.
Notes were AI assisted.
Thanks & regards,
Nathalie
Hi all,
Notes from the call are posted at: https://github.com/OpenAMP/openamp-system-reference/wiki/OpenAMP-System-Ref…
Summary of action items:
* Ben: Review meta-openamp PR #53; do test builds
* Bill: Open meta-openamp PR for released library recipes from 2026.04
* Bill: Ask Dave (Zephyr security lead) to join the next System Reference call to share how Zephyr manages security advisories
* Tanmay: Close openamp-system-reference PR #100; open new one once Linux kernel reset mechanism is finalized
* Tanmay: Review libmetal PR #365 in about a week
* Tanmay: Address Iulia's comments on open-amp PR #684 / openamp-system-reference PR #106 once Linux kernel side is finalized
* Tanmay: open-amp PR #684 - can review after next release
* Arnaud: Add comment to openamp-system-reference PR #111
* Arnaud: Review current version of security policy document this week or early next week
* Arnaud: Finalize and enable GitHub security advisory / vulnerability reporting on open-amp repo; publish security policy
* Ben: Come back to open-amp PR #687 in a few weeks
* Ben: Post update to openamp-system-reference PR #94 on status of system DT release to public
* Nathalie: Review security policy document for any remaining open comments before publishing
* Nathalie: Add guidance in security policy on how to file a vulnerability report properly
* Nathalie: Schedule separate call for same slot next Wednesday July 22 for updating OpenAMP contributor & external collaborator lists (Arnaud, Bill)
Please let us know if you spot any errors or important omissions.
Notes were AI assisted.
Thanks & regards,
Nathalie