Case Study: Conquering the EU Cyber Resilience Act (CRA) with 1,400 Upstream Security Fixes

Ericsson Software Technology successfully met the stringent obligations of the EU Cyber Resilience Act by fundamentally changing their engineering strategy. Instead of maintaining private forks, the team engaged in upstream collaboration guided by OpenSSF principles. They contributed 214 direct security fixes and over 1,400 dependency updates to open source communities, significantly lowering lifecycle costs and strengthening the global supply chain against vulnerabilities.

This case study is based on the YouTube presentation “Upstream Collaboration for the Win (of the CRA)!” delivered by Georg Kunz and Jan Melen. Links to the presentation and resources are provided at the end of this page.

What were the challenges with Cyber Resilience Act compliance?

The EU Cyber Resilience Act introduces strict obligations that require software manufacturers to evaluate how they manage open source components. Failing to meet these requirements presents a severe risk where companies might abandon open source entirely in favor of closed development. This shift would fragment the ecosystem and destroy the value generated by collaborative development.

CRA Article Regulatory Requirement Challenge for Manufacturers
Article 13 (5) Exercise due diligence Manufacturers must understand the security posture of all subcomponents. This creates a massive scalability issue due to the thousands of heterogeneous open source components in modern software.
Article 13 (6) Share vulnerability fixes If a manufacturer develops a fix, they must share it with the upstream project. Friction occurs because many developers lack training in upstream contribution processes.
Article 13 (8) Effective vulnerability handling Manufacturers must actively handle vulnerabilities affecting their products. The volume of reported vulnerabilities requires significant resources to manage effectively.

What was the CRA solution using OpenSSF principles?

To address these regulatory pressures, Ericsson Software Technology launched an initiative to overhaul their engineering practices. Instead of maintaining private forks for their products, the team focused on institutional reinvention by engaging directly with upstream open source communities.

The initiative applied principles championed by the OpenSSF to create a more secure ecosystem. The core actions included the following steps:

  • Eliminating private forks: The team stopped applying temporary local patches to their releases and committed to fixing issues directly at the source.
  • Automating dependency updates: Developers used automated tools to push pull requests forward, ensuring projects continuously ran on the most secure versions.
  • Improving security fundamentals: The team added TLS support for unencrypted interfaces and documented best security practices for hardening components based on OpenSSF guidelines.
  • Deploying scanning tools: They exposed upstream projects to public scanning tools to help maintainers automatically identify out of date dependencies and known vulnerabilities.

What were the results of this upstream engagement?

By shifting their focus to community support and OpenSSF best practices, Ericsson achieved measurable security improvements across a massive portion of the open source ecosystem.

  • 214 security pull requests submitted.
    • Why this matters: Having the open source community review and accept direct vulnerability fixes ensures a higher standard of security. It allows the entire ecosystem to receive the exact same fix simultaneously.
  • Over 1,400 dependency bump pull requests merged.
    • Why this matters: Automating and resolving transitive dependency vulnerabilities at the source lowers the compliance cost and security risk for any manufacturer utilizing those open source projects in their commercial products.
  • Zero private forks maintained.
    • Why this matters: Removing the burden of maintaining custom patches for every product release reduces engineering overhead and long term lifecycle costs.

“So if you want to start on this – and I hope you do – the quick win is to actually tackle those dependency bumps, scanner integrations, and documentation fixes that exist across many of the projects. OpenSSF has good guidelines on how they should be done.”

Jan Melen, General Manager, Ericsson Software Technology

Where can you learn more?

  • Watch the Presentation: View the full YouTube presentation Upstream Collaboration for the Win (of the CRA)! and view the slides for complete details and strategies.
  • Project References: Learn more about OpenSSF Premier membership here. Membership includes access to private, Chatham House Rule initiatives such as the CRA. Explore Best Practices group and the Global Cyber Policy Working Group here.
  • Member Organization: Visit Ericsson to learn more about their software technology initiatives and open source program office.