council/tickets

Fork 0

The EU CRA Stewardship and Readiness proposal for Fedora community #559

New issue

Open

opened 2026-03-10 17:01:11 +00:00 by rzhukov · 4 comments

rzhukov commented

2026-03-10 17:01:11 +00:00

Summary

Request to review the EU CRA Stewardship and Readiness proposal

Background

Summary

The European Union's Cyber Resilience Act (CRA) introduces statutory cybersecurity requirements for software, prompting Red Hat to formally propose assuming the role of Open Source Software Steward to shield Fedora's volunteer contributors from regulatory liability. Operating on principles of minimal disruption and developer-centric pragmatism, Red Hat intends to absorb the administrative compliance burden by helping and automating necessary security hygiene rather than imposing unreasonable mandates on the community. To execute this, Red Hat will collaborate with Fedora maintainers to first conduct a gap analysis of existing vulnerability management, incident response, and SBOM processes, followed by establishing actionable CRA Readiness Roadmap.

Action Requested from the Council

Please review our proposed Stewardship approach to the Fedora CRA Readiness Roadmap.
Consider to schedule a brief segment during one of the upcoming Council meeting to answer any technical, legal or other CRA questions.
Provide feedback to ensure this Stewardship model aligns with the Council's strategic vision and community practices.

Details

The New Regulatory Era for SW

The enactment of the European Union's Cyber Resilience Act (CRA) marks a definitive turning point in the governance of the global software supply chain. For decades, the open source ecosystem has operated on a foundation of voluntary collaboration, best-effort security practices, and a distinct lack of warranty or liability. The CRA fundamentally alters this landscape by introducing statutory cybersecurity requirements for products with digital elements (PDEs) placed on the European market. While the regulation primarily targets commercial manufacturers who monetize software, the interconnected nature of modern software development means that upstream open source projects, specifically those that serve as the foundation for everything around us like Fedora operating system, can no longer operate in a regulatory vacuum. The CRA introduces a novel legal actor: the Open Source Software Steward (you can read more in Red Hat blog). This role was specifically architected by EU legislators to recognize the critical infrastructure provided by open source foundations and corporate sponsors, while simultaneously shielding individual contributors and non-commercial projects from the crushing weight of full manufacturer compliance. We can't sit aside and do nothing. Red Hat experts are leading CRA efforts in Open Source Communities (like OpenSSF and Eclipse) and EU Official Standardization bodies to make sure the entire open source ecosystem can support CRA compliance in a healthy and sustainable manner.

CRA Stewardship and Critical Role of Fedora Community

It is critical to establish a fundamental fact upfront: Free and Open Source Software (FOSS) projects and individual volunteer contributors have no legal obligations under the CRA's commercial manufacturer mandates. However, as a long-time supporter of Fedora and to execute our commitment to continue doing so, Red Hat proposes to formally assume CRA Stewardship role for Fedora. We believe Fedora already follows excellent security practices, including incident response, and robust community governance, so our objective is not to overhaul your workflows, but to assist in elevating, automating, and verifying those practices. By taking on this role, Red Hat doesn't not only fulfill its Stewardship obligations, but also absorbs some of the administrative and regulatory burdens of the CRA, guiding and allowing Fedora to become an even stronger, verified upstream without inadvertently exposing community to commercial compliance risks. Fedora is a unique, diverse and one of the strongest community, that always leads by example as a role model for entire open source ecosystem.

Core Principles

There is a good thing about CRA - we have an enormous opportunity to work on real things to improve overall quality and security posture of Fedora for our users. Red Hat strongly believes in its role of Responsible CRA Steward. We suggest to approach CRA Stewardship with the following core principles:

Listen First, Act Second. We start by learning your existing community practices, governance, processes, and tools. We do not assume we know better than the maintainers who built the project. We meet you where you are, not where a regulation says you should be.
Minimal Disruption. Compliance efforts must be workflow-native. We aim to integrate seamlessly into your existing development pipelines and governance structures. If a requirement breaks a developer's flow, it is the wrong requirement and we are committed to partnering with the project to satisfy the intent without breakage.
Security First, Compliance Follows. We prioritize genuine security improvements over box-checking. By focusing on overall security hygiene and engineering excellence (as per the spirit of the CRA), we ensure that compliance becomes a natural consequence of doing the right thing for the software and its users.
Gap-Filling Support . We are here to collaborate, not to take over. We will provide resources, tooling, or part-time personnel only to fill specific compliance gaps that the community cannot handle. If you are already doing it, let’s simply document it.
Pragmatic & Developer-Centric. All compliance requirements must make technical sense. We filter out bureaucratic noise and focus on actions that genuinely improve security and quality without burdening the contributor.
We propose to begin our gap analysis and process documentation by focusing first on existing vulnerability management and incident response processes and supporting tooling (like SBOMs), followed by agreed CRA Readiness Roadmap, with close collaboration with Fedora maintainers.

Summary

Executing CRA Stewardship roadmap will shield Fedora's volunteer contributors from regulatory compliance burdens while delivering a structurally more secure, transparent, and resilient operating system to all users through enhanced, automated supply-chain security practices.

### Summary Request to review the EU CRA Stewardship and Readiness proposal ### Background ### Summary The European Union's Cyber Resilience Act (CRA) introduces statutory cybersecurity requirements for software, prompting Red Hat to formally propose assuming the role of Open Source Software Steward to shield Fedora's volunteer contributors from regulatory liability. Operating on principles of minimal disruption and developer-centric pragmatism, Red Hat intends to absorb the administrative compliance burden by helping and automating necessary security hygiene rather than imposing unreasonable mandates on the community. To execute this, Red Hat will collaborate with Fedora maintainers to first conduct a gap analysis of existing vulnerability management, incident response, and SBOM processes, followed by establishing actionable CRA Readiness Roadmap. ### Action Requested from the Council 1. Please review our proposed Stewardship approach to the Fedora CRA Readiness Roadmap. 2. Consider to schedule a brief segment during one of the upcoming Council meeting to answer any technical, legal or other CRA questions. 3. Provide feedback to ensure this Stewardship model aligns with the Council's strategic vision and community practices. ### Details ### The New Regulatory Era for SW The enactment of the European Union's Cyber Resilience Act (CRA) marks a definitive turning point in the governance of the global software supply chain. For decades, the open source ecosystem has operated on a foundation of voluntary collaboration, best-effort security practices, and a distinct lack of warranty or liability. The CRA fundamentally alters this landscape by introducing statutory cybersecurity requirements for products with digital elements (PDEs) placed on the European market. While the regulation primarily targets **commercial manufacturers who monetize software**, the interconnected nature of modern software development means that upstream open source projects, specifically those that serve as the foundation for everything around us like Fedora operating system, can no longer operate in a regulatory vacuum. The CRA introduces a novel legal actor: the Open Source Software **Steward** (you can [read more in Red Hat blog](https://www.redhat.com/en/blog/eu-cyber-resilience-acts-impact-open-source-security)). This role was specifically architected by EU legislators to recognize the critical infrastructure provided by open source foundations and corporate sponsors, while simultaneously shielding individual contributors and non-commercial projects from the crushing weight of full manufacturer compliance. We can't sit aside and do nothing. Red Hat experts are leading CRA efforts in Open Source Communities (like OpenSSF and Eclipse) and EU Official Standardization bodies to make sure the entire open source ecosystem can support CRA compliance in a healthy and sustainable manner. ### CRA Stewardship and Critical Role of Fedora Community It is critical to establish a fundamental fact upfront: Free and Open Source Software (FOSS) projects and individual volunteer contributors **have no legal obligations under the CRA**'s commercial manufacturer mandates. However, as a long-time supporter of Fedora and to execute our commitment to continue doing so, **Red Hat proposes to formally assume CRA Stewardship role for Fedora**. We believe Fedora already follows excellent security practices, including incident response, and robust community governance, so our objective is not to overhaul your workflows, but to assist in elevating, automating, and verifying those practices. By taking on this role, Red Hat doesn't not only fulfill its Stewardship obligations, but also absorbs some of the administrative and regulatory burdens of the CRA, guiding and allowing Fedora to become an even stronger, verified upstream without inadvertently exposing community to commercial compliance risks. Fedora is a unique, diverse and one of the strongest community, that always leads by example as a role model for entire open source ecosystem. ### Core Principles There is a good thing about CRA - we have an enormous opportunity to work on **real things** to improve overall quality and security posture of Fedora for our users. Red Hat strongly believes in its role of **Responsible** CRA Steward. We suggest to approach CRA Stewardship with the following core principles: - **Listen First, Act Second**. We start by learning your existing community practices, governance, processes, and tools. We do not assume we know better than the maintainers who built the project. We meet you where you are, not where a regulation says you should be. - **Minimal Disruption**. Compliance efforts must be workflow-native. We aim to integrate seamlessly into your existing development pipelines and governance structures. If a requirement breaks a developer's flow, it is the wrong requirement and we are committed to partnering with the project to satisfy the intent without breakage. - **Security First, Compliance Follows**. We prioritize genuine security improvements over box-checking. By focusing on overall security hygiene and engineering excellence (as per the spirit of the CRA), we ensure that compliance becomes a natural consequence of doing the right thing for the software and its users. - **Gap-Filling Support** . We are here to collaborate, not to take over. We will provide resources, tooling, or part-time personnel only to fill specific compliance gaps that the community cannot handle. If you are already doing it, let’s simply document it. - **Pragmatic & Developer-Centric**. All compliance requirements must make technical sense. We filter out bureaucratic noise and focus on actions that genuinely improve security and quality without burdening the contributor. We propose to begin our gap analysis and process documentation by focusing first on existing vulnerability management and incident response processes and supporting tooling (like SBOMs), followed by agreed CRA Readiness Roadmap, with close collaboration with Fedora maintainers. ### Summary Executing CRA Stewardship roadmap will shield Fedora's volunteer contributors from regulatory compliance burdens while delivering a structurally more secure, transparent, and resilient operating system to all users through enhanced, automated supply-chain security practices.

rzhukov added the

needs

triage

label

2026-03-10 17:01:11 +00:00

jflory7 added

⌛ TL;DNR

The main takeaway is that while the guiding principles for CRA stewardship are solid, the Council and the wider community need a much more concrete, actionable proposal to actually review and discuss. (This also echoes a bit of the 11 March 2026 Fedora Council meeting discussion about this. I didn't manage to get the follow-ups posted from that Council meeting into this ticket.)

📆 April to June focus: Light Stewardship

To make this manageable and ensure it fits our 6-month release rhythm, I suggested we focus immediate Q2 efforts strictly on achieving the "Light Stewardship" baseline—the absolute minimum requirements—before exploring any advanced tasks. Dave Russo is currently drafting a community-friendly version of this proposal that will clearly define the deliverables, timelines, and a responsibility matrix so we all know exactly where Red Hat engineering is providing support versus what falls to community contributors (e.g., responsibly reporting an exploit in our production build infrastructure versus reporting a CVE in a single package).

👣 Next steps

I know Dave is working on this, but we did not lock in a firm deadline since @jspaleta is out sick and @rzhukov is on PTO. So, we will likely need to circle back to this when both of them are back, but I would love to have something soon for an upcoming Fedora Council meeting.

@bookwar wrote in #559 (comment):

So far the ticket doesn't mention any practical steps, only a generic stance. And I would be in favor of accepting it. And moving on to the details and the specific initiatives and workflows proposed in follow-up tickets.

I would like to see @rzhukov and folks come up with an actionable proposal with some real teeth, and then we can formally take a vote and ratify some sort of action plan. Based on the public Council discussion on 11 March and today's side-meeting, I think we are hard-pressed to find someone who is against this proposal. The proposal is more of a philosophical statement on how this collaboration and teamwork on CRA compliance could work. Easy enough, I like it!

For us to have the real, in-depth conversations this topic requires, we need a concrete, draft proposal with milestones and a timeline that we could commit project resources and time for, across the next two Fedora release cycles. The proposal should not be perfect, since we will likely end up debating it and suggesting changes. But it is always easier to give feedback when there is something tangible versus when it is all abstract and theoretical.

_Discussed in 2026-03-30 meeting with @jflory7, @blc, @humaton, Dave Russo, and folks from Red Hat Product Security_. --- ## ⌛ TL;DNR The main takeaway is that while the guiding principles for CRA stewardship are solid, the Council and the wider community need a much more concrete, actionable proposal to actually review and discuss. (This also echoes a bit of the [11 March 2026 Fedora Council meeting discussion](https://meetbot.fedoraproject.org/meeting-2_matrix_fedoraproject-org/2026-03-11/council.2026-03-11-15.03.html) about this. I didn't manage to get the follow-ups posted from that Council meeting into this ticket.) ## 📆 April to June focus: Light Stewardship To make this manageable and ensure it fits our 6-month release rhythm, I suggested we focus immediate Q2 efforts strictly on achieving the "Light Stewardship" baseline—the absolute minimum requirements—before exploring any advanced tasks. Dave Russo is currently drafting a community-friendly version of this proposal that will clearly define the deliverables, timelines, and a responsibility matrix so we all know exactly where Red Hat engineering is providing support versus what falls to community contributors (e.g., responsibly reporting an exploit in our production build infrastructure versus reporting a CVE in a single package). ## 👣 Next steps I know Dave is working on this, but we did not lock in a firm deadline since @jspaleta is out sick and @rzhukov is on PTO. So, we will likely need to circle back to this when both of them are back, but I would love to have something soon for an upcoming Fedora Council meeting. @bookwar wrote in https://forge.fedoraproject.org/council/tickets/issues/559#issuecomment-579445: > So far the ticket doesn't mention any practical steps, only a generic stance. And I would be in favor of accepting it. And moving on to the details and the specific initiatives and workflows proposed in follow-up tickets. I would like to see @rzhukov and folks come up with an actionable proposal with some real teeth, and then we can formally take a vote and ratify some sort of action plan. Based on the public Council discussion on 11 March and today's side-meeting, I think we are hard-pressed to find someone who is _against_ this proposal. The proposal is more of a philosophical statement on how this collaboration and teamwork on CRA compliance could work. Easy enough, I like it! For us to have the real, in-depth conversations this topic requires, we need a concrete, draft proposal with milestones and a timeline that we could commit project resources and time for, across the next two Fedora release cycles. The proposal should not be perfect, since we will likely end up debating it and suggesting changes. But it is always easier to give feedback when there is something tangible versus when it is all abstract and theoretical.

jflory7 added this to the Council Meeting Planner project

2026-04-08 23:47:35 +00:00

rzhukov commented

2026-04-29 22:32:38 +00:00

Author

TL;DR

Hey Fedora Community! 👋 I'm following up with more detailed breakdown and next steps regarding the proposed CRA roadmap.

🚨 Incident & Vulnerability Reporting. Red Hat’s Product Security team handles the official legal reporting; community only job so far is to continue collaborating.

📝 Security Policies & security.md. We need to review our central security policies and push short, discoverable security.md files to agreed repositories outlining basic contact info and reporting processes.

📦 SBOMs (Software Bill of Materials). While Red Hat handles internal SBOMs on our behalf for incident response, exploring public-facing SBOM generation (like adopting Konflux) will be a longer-term, community-driven journey to improve downstream security, with due dates determined by Fedora. We suggest starting exploration now.

Please take it as first necessary steps with the intention to expand further after we ensure the minimum mandatory compliance.

Details

Item	Description	Actions	Due Date
Reporting Actively Exploited Vulnerabilities and Severe Incidents to national CSIRTs and ENISA	By law, Stewards are required to report severe incidents and actively exploited vulnerabilities they become aware of by 11 September 2026. We need to test everything in advance.	Red Hat: The Steward (Red Hat Product Security team) will develop, communicate and implement process for actively exploited vulnerabilities and severe incidents we are aware of as part of our internal Incident Response. Fedora Project: No specific actions besides collaboration are required. Value add - if the Fedora Project decides to report anything else they can inform Red Hat (in which case we report).	June 30, 2026
Cybersecurity, Vulnerability Management and Incident Response Policy	A published policy must, at a minimum, address: 1) Secure development practices. 2) Contact information for security questions, vulnerabilities and incidents reporting. 3) Contact information of the project’s Steward (cra-steward@redhat.com). 4) The processes for vulnerability reporting, identification, remediation, patching, and coordinated disclosure (CVD). 5) The process for handling incidents for underlying infrastructure and tooling used. 6) Intended support period for addressing vulnerabilities and the end-of-life process. 7) Publish security.md file in each repo, containing minimum information (see above) for easy discoverability.	Fedora Project: 1) Review existing security-related policies. 2) Make sure they contain all essential information. 3) Identify relevant repos and push short security.md files, which must contain the minimum information, but can link to the detailed policy in a central location. Red Hat: Provide consultations, examples, best practices and guides along the way.	June 30, 2026
SBOMs - generate and publish	SBOMs as easily discoverable artefacts for each release or tag. If building binaries, build-time SBOMs are recommended. Although this is not a direct requirement from the CRA, it is essential in order for Red Hat to perform incident response for Fedora and beneficial for Project’s longer term security roadmap.	Red Hat: Create and store SBOMs internally, as part of the incident response function that we perform on behalf of Fedora. Interface: Because of how the Red Hat infrastructure is organized it is not currently possible for the Fedora community to see the data that we produce. We might be able to provide ad-hoc exports of the data if needed. Fedora Project: SBOMs are an essential part of incident response. Better SBOMs mean better response. Thus, it’s recommended to explore the following SBOM path: 1) Explore, research, learn. Once Fedora is ready to do SBOMs as part of the security journey, Red Hat will share the tools and methods we use, but the priority and due dates will be driven by the community. 2) Adopt Konflux. Building in Konflux is not easy at the start, but it makes SBOM generation easier and brings a lot of other long-term security benefits that users expect (like provenance, reproducible builds, etc.). 3) Continuous improvement. We’re confident generating and publishing SBOMs will be beneficial for downstream Fedora consumers (including Red Hat, indeed). Red Hat and other supporters of Fedora Project can advise on tooling and methods to ensure top quality of Fedora SBOMs.	The Due Date is TBD by Fedora.

Collaboration is key. Because Red Hat is acting as a Steward under the CRA, they are absorbing the heavy lifting for legal liability and official vulnerability reporting, leaving Fedora community itself to drive the long-term security posture improvements. We are happy to help moving forward, indeed. 🤝

### TL;DR Hey Fedora Community! 👋 I'm following up with more detailed breakdown and next steps regarding the proposed CRA roadmap. 🚨 **Incident & Vulnerability Reporting**. Red Hat’s Product Security team handles the official legal reporting; community only job so far is to continue collaborating. 📝 **Security Policies & security.md**. We need to review our central security policies and push short, discoverable security.md files to agreed repositories outlining basic contact info and reporting processes. 📦 **SBOMs (Software Bill of Materials)**. While Red Hat handles internal SBOMs on our behalf for incident response, exploring public-facing SBOM generation (like adopting Konflux) will be a longer-term, community-driven journey to improve downstream security, with due dates determined by Fedora. We suggest starting exploration now. Please take it as first necessary steps with the intention to expand further after we ensure the minimum mandatory compliance. ### Details | Item | Description | Actions | Due Date | |---------|---------|---------|---------| | Reporting Actively Exploited Vulnerabilities and Severe Incidents to national CSIRTs and ENISA | By law, Stewards are required to report severe incidents and actively exploited vulnerabilities they become aware of by 11 September 2026. We need to test everything in advance. | **Red Hat**: The Steward (Red Hat Product Security team) will develop, communicate and implement process for actively exploited vulnerabilities and severe incidents we are aware of as part of our internal Incident Response. **Fedora Project**: No specific actions besides collaboration are required. Value add - if the Fedora Project decides to report anything else they can inform Red Hat (in which case we report). | June 30, 2026 | | Cybersecurity, Vulnerability Management and Incident Response Policy | A published policy must, at a minimum, address: 1) Secure development practices. 2) Contact information for security questions, vulnerabilities and incidents reporting. 3) Contact information of the project’s Steward (cra-steward@redhat.com). 4) The processes for vulnerability reporting, identification, remediation, patching, and coordinated disclosure (CVD). 5) The process for handling incidents for underlying infrastructure and tooling used. 6) Intended support period for addressing vulnerabilities and the end-of-life process. 7) Publish security.md file in each repo, containing minimum information (see above) for easy discoverability. | **Fedora Project**: 1) Review existing security-related policies. 2) Make sure they contain all essential information. 3) Identify relevant repos and push short security.md files, which must contain the minimum information, but can link to the detailed policy in a central location. **Red Hat**: Provide consultations, examples, best practices and guides along the way. | June 30, 2026 | | SBOMs - generate and publish | SBOMs as easily discoverable artefacts for each release or tag. If building binaries, build-time SBOMs are recommended. Although this is not a direct requirement from the CRA, it is essential in order for Red Hat to perform incident response for Fedora and beneficial for Project’s longer term security roadmap. | **Red Hat**: Create and store SBOMs internally, as part of the incident response function that we perform on behalf of Fedora. **Interface**: Because of how the Red Hat infrastructure is organized it is not currently possible for the Fedora community to see the data that we produce. We might be able to provide ad-hoc exports of the data if needed. **Fedora Project**: SBOMs are an essential part of incident response. Better SBOMs mean better response. Thus, it’s recommended to explore the following SBOM path: 1) **Explore, research, learn**. Once Fedora is ready to do SBOMs as part of the security journey, Red Hat will share the tools and methods we use, but the priority and due dates will be driven by the community. 2) **Adopt Konflux**. Building in Konflux is not easy at the start, but it makes SBOM generation easier and brings a lot of other long-term security benefits that users expect (like provenance, reproducible builds, etc.). 3) **Continuous improvement**. We’re confident generating and publishing SBOMs will be beneficial for downstream Fedora consumers (including Red Hat, indeed). Red Hat and other supporters of Fedora Project can advise on tooling and methods to ensure top quality of Fedora SBOMs. | The Due Date is TBD by Fedora. | Collaboration is key. Because Red Hat is acting as a Steward under the CRA, they are absorbing the heavy lifting for legal liability and official vulnerability reporting, leaving Fedora community itself to drive the long-term security posture improvements. We are happy to help moving forward, indeed. 🤝

rzhukov referenced this issue from security/tickets

2026-07-09 17:38:31 +00:00

Review Fedora security documents to align with "Vulnerability and Incident Policy" CRA requirement #14