Open source software faces significant regulatory shifts, making "secure by design" development practices increasingly important. The Cyber Resilience Act (CRA) takes effect on December 11, 2027, and as of September 11, 2026, the first CRA vulnerability and incident reporting obligations were live. These new cybersecurity regulations impact all companies that sell software or hardware to the European market and will have a huge impact on open source as a whole.

The readiness gap and the cost of inaction

Despite the looming deadline, the software industry remains unprepared. According to The Linux Foundation’s 2026 CRA Awareness and Readiness Report, 66% of companies remain unfamiliar with the CRA and only 41% expect to be fully compliant by December 2027.

The CRA regulates products with digital elements placed on the EU market, and open source software underpins most modern software products including cloud infrastructure, operating systems, and AI frameworks. According to the 2026 Open Source Security and Risk Analysis Report, it’s estimated that over 97% of the code in most codebases comes from open source. As a result, it's important that organizations understand how they are dependent on open source software.

How organizations can prepare

Organizations who are impacted by the CRA must first understand the software being used in their products. They need to identify known vulnerabilities, assess potential risk, respond to incidents, and communicate information across their software supply chain.

They must be able to answer questions such as:

What open source components are my products using?
How are those components maintained? Who maintains them?
How are vulnerabilities discovered and disclosed?
How active and responsive are the upstream communities?
How quickly can affected products be identified when a vulnerability emerges?
What’s the process for responsible outreach to the open source communities involved so vulnerabilities can also be fixed upstream?

Under the CRA, manufacturers must collaborate with open source communities, with specific mandates to disclose vulnerabilities and share fixes developed upstream. While the CRA doesn't prohibit private forks of software, there is now a cost of carrying divergence, as the related security risks of doing so are inherently higher. Additionally, organizations that choose to maintain private forks of software will face increased labor costs, upward of $258,000 based on . Participating in upstream community development will not only become the more secure path toward CRA compliance, but also the more economical one.

By contributing upstream and participating directly in open source development, organizations will also improve transparency, reduce duplication of effort, while helping improve the security posture of the projects they rely on.

Red Hat is an Open Source Software Steward

So developers can continue to focus on innovation rather than compliance, Red Hat has stepped up to become an Open Source Software Steward.As a Steward, we're helping open source projects implement CRA-compliant security practices, and assist with vulnerability management and reporting, security tooling, infrastructure support, and documentation for some of the key open source projects we support, including Ansible and Fedora.

How to approach "secure by design" for open source

Although open source is formally out of scope of the CRA, commercial companies have higher expectations for the open source software they rely upon, which will in turn increase the burden on upstream communities.

To help address these increased expectations, upstream maintainers can voluntarily embrace "CRA-friendly" practices and adopt secure by design development principles. Red Hat collaborated with other industry leaders and the OpenSSF to produce the CRA Readiness Guide for Maintainers and Developers. This guide centers on proactive project hygiene, such as publishing clear vulnerability handling policies, clearly defining license requirements, and documenting support and release expectations. While maintainers should exercise caution to avoid accepting manufacturer liabilities or signing downstream compliance declarations, implementing these baseline security principles can speed and simplify supply chain risk assessments and compliance evaluations.

A collective effort

Now that reporting obligations under the CRA are in effect, open source governance and upstream community health matter more than ever. We need to collaborate across the open source ecosystem to build compliance and security controls into the software supply chain from the start—practices that, at their core, are simply good engineering. By aligning proactively on these standards, we'll help keep open source software trusted worldwide.