The EU Cyber Resilience Act's impact on open source security

From communal effort to legal mandate

The world runs on open source. From the applications you use daily to the critical infrastructure powering our society, open source software is ubiquitous. However, this widespread adoption has brought with it an escalating need for robust security, a reality starkly highlighted by incidents like SolarWinds and the more recent XZ Utils vulnerability. While the open source community often demonstrates remarkable resilience and collaboration in addressing threats, a significant shift in responsibility is now underway, driven in part by legislation, such as the EU’s Cyber Resilience Act (CRA).

For decades, open source security was a communal effort, relying on the goodwill and expertise of contributors. As commercial entities increasingly integrate open source into their products, they’ve often overlooked security at the source (i.e. upstream), instead opting to bolt on fixes only at product release. Despite security engineers tirelessly advocating for practices like supply chain security, widespread adoption has been limited due to this afterthought mindset. Many organizations who are comfortable with their long-standing practices of consuming open source software have resisted re-evaluating their approach, operating under the dangerous and flawed assumption that since it worked fine for years and someone else always took care of it, there’s no need to change. This mindset ignores a fundamental truth: security isn’t about avoiding compromise, but about making it as difficult as possible for attackers when they inevitably strike.

Now the CRA has arrived, aiming to address these very issues from a top-down perspective. This legal framework mandates cybersecurity requirements for hardware and software with digital elements placed on the EU market. In particular, it requires “manufacturers” to prioritize security throughout a product’s lifecycle. While full enforcement is set for December 2027, reporting obligations for exploited vulnerabilities and severe security incidents begin as early as September 2026. While it may seem like there is plenty of time, the reality is that there is almost no gap between the completion of the complex CRA implementing documents and the start of actual enforcement. Let’s demystify some of the CRA intentions and clarify what it means for the entire open source ecosystem.

A cultural faux pas: Misunderstanding shared responsibility

The CRA’s intent is to formalize decades of security modernization efforts and ambitiously accelerate them within just a few years. It also shines a spotlight on new ‘stewardship’ obligations that the industry should have been collaboratively embracing all along. Historically, prominent open source projects were cultivated and governed by organizations like foundations, consortia, and major technology companies that have been involved for a considerable period.

For the first time, Open Source Software Steward is now an official role under EU law, expanding their responsibility beyond the light management several perform today. While community open source itself is technically “out of scope” when not monetized, the reality is far more nuanced. When commercial entities or individuals monetizing open technologies incorporate open source projects into their products, those upstream projects become directly or indirectly under the CRA’s purview, creating a complex web of new demands and expectations, many of which may be inappropriately placed on the projects themselves.

This leads to a growing cultural faux pas, where organizations are making demands of open source projects. Even before the CRA, open source projects occasionally received inquiries from commercial entities, such as requests for security practices or specific compliance requirements, often without any understanding of how a given project’s open source development works. These entities failed to grasp that whilst open source is a freely available, modifiable, and shareable common good, it also requires collaboration and contribution for global sustainability.

With the CRA, these inquiries are on the rise, often embodying the “check-the-box” security mentality, without taking into account the bigger picture of intent, context, and technology. Organizations are increasingly burdening open source maintainers with these types of requests rather than taking the initiative to understand and implement these security measures themselves. Alternatively, they could contribute these improvements back to the very projects they critically depend on, benefiting not only themselves, but the entire community.

This exacerbates a fundamental misunderstanding of the shared responsibility model, which heavily weights the obligation towards adopters of open source technologies to ensure the security they need when using the software.

From mismatched standards to an open source-first approach

A number of Red Hatters are actively engaged in the CRA policy (via trade associations and foundations) and standardization development (via the appointed European Standardization Organizations (ESOs)) to ensure a better technical understanding of open source. However, just like others, those enterprise security standards are sprawling, complex, and paywalled, which does not directly translate to the open source world. How can under-resourced communities, already battling burnout, be expected to meet the myriad industry-specific regulatory and compliance requirements?

These standards, often written for centralized, commercially controlled environments, frequently presume a black box development model that fails to consider the saturation of open source in all software, a notion utterly divorced from today’s software development process. Open source projects, by their very nature, are decentralized, publicly collaborative, and “as-is,” without the contractual obligations of proprietary software. By definition, open source projects owe you nothing, beyond what their license specifies, which, regarding software security, is often nothing at all.

This isn’t to say that enterprise security concepts can’t be adapted, following the clear incentives and benefits. Recognizing the unique characteristics of open source is crucial, including its public collaboration, component-based development, and the absence of universal training or expertise expectations. We must acknowledge the dwindling pipeline of security talent and the inherent friction between some traditional security concepts, such as security-through-obscurity, and the open source ethos of transparency.

The Open Source Project Security (OSPS) Baseline is an open source-first approach to recrafting industry standards and requirements into understandable, relevant security criteria that open source contributors and maintainers can apply to their project. The Baselines were designed to account for the different eras of open source software that characterize their source code practices, culture, and motivations. This ensures that regardless of what the project is and how it is historically developed, modified, or distributed, it has the opportunity, understanding, and choice to address security aligned with their values and motivations.

The Baselines are by no means a complete answer to CRA; they are a start. There is a critical need for quality, developer-centric open source tooling. This tooling should work together to help projects produce sufficient security information—such as supply chain metadata or a software bill of materials (SBOM)—regardless of where their source code is hosted. This information allows manufacturers and consumers of software to understand what security measures have already been implemented and what remains for them to do themselves. We have the opportunity to continue what we started with supply chain security, with a bottom up and top down approach that is meaningful and actually delivers more secure software for all.

Stewardship: Turning legislative burden into opportunity

The CRA can improve security for both enterprises and open source. It can promote good practices, due diligence, and encourage vulnerability reporting up the supply chain, fostering a much-needed dialogue between all ecosystem players. However, it cannot, and should not, force open source maintainers to become “suppliers” for commercial companies and no entity should be using CRA in this manner.

This is where stewardship becomes paramount. Red Hat does not view stewardship as a burden, but as a positive opportunity for all involved. However, this still requires collaboration within the community being “stewarded.” CRA and similar legislation can serve as a catalyst for organizations and projects to improve their security posture, which is often a low-priority task. These laws formalize a need that can prompt them to accept help.

This means providing systematic support to projects, especially with vulnerability reporting, clear and accessible documentation, and shielding them from external, CRA-related demands by working alongside the community to elevate security concepts and considerations into the design, governance, development, and availability of software. We cannot steward every project we interact with, however, we can do our part in fulfilling stewardship obligations and assist others by sharing how we approach stewardship within these critical projects and communities we all depend on.

Red Hat’s approach to stewardship is community-centric, aiming for minimal overhead to projects while producing practical materials and templates that drive “real security.” We stand by that position and advocate for it among our industry partners, working in communities such as OpenSSF Global Cyber Policy WG and Eclipse ORC WG, among others. This goes far beyond just CRA compliance; it’s a call for the entire open source ecosystem to unite, take action, and support one another. Regardless of your role as a steward, manufacturer, or maintainer, we invite you to join us!

A call for collective responsibility

There has never been a time when passive consumption was acceptable to open source or Red Hat. We have always tried to give back upstream to the projects and communities with which we engage. The security of technology is a shared and evolving expectation, requiring active participation from everyone involved throughout a product’s lifecycle. Adopters of open source have an obligation to be actively engaged and contribute within the realm and culture defined by each project.

This is not about shaming, but about recognizing a collective responsibility to do better in the face of change, to evolve yesterday’s often afterthought security to default expectations of today’s hyperdependent world. Open source maintainers are the backbone of our digital world. If open source was to be re-invented from scratch today, humanity would need to stump up US$8.8 trillion dollars (according to Harvard Report, 2024) Embrace the opportunity to uplift the security of your projects on your terms, not just for compliance, but for the fundamental health and resilience of the entire ecosystem.