Presenters

Source

Navigating the Cyber Resilience Act (CRA): Why Upstream Collaboration is Your Secret Weapon 🛡️🤝

The digital world is evolving at lightning speed, and with it, the complexities of securing our software supply chains. Enter the Cyber Resilience Act (CRA), a formidable new regulation poised to reshape how software manufacturers operate. But what if this challenge isn’t just a hurdle, but a golden opportunity?

Today, we’re diving deep with Georg Kunz, from Ericsson’s Open Source Program Office and an active contributor to the OpenSSF, and Jan Melen, General Manager at Ericsson Software Technology Finland and CNCF Governing Board Vice Chair. They reveal how strong upstream collaboration isn’t just a nice-to-have, but a powerful tool to meet CRA compliance and secure the future of open source.

The CRA’s Gauntlet: Three Key Challenges for Software Manufacturers 🎯

The CRA imposes significant obligations on software manufacturers, especially concerning the open-source components that form the backbone of modern applications. Georg and Jan highlighted three particularly challenging articles:

1. Exercise Due Diligence (Article 13(5)) 🕵️‍♀️

Manufacturers must know what they put into their products, consciously understanding the security posture of every subcomponent.

  • The Challenge: Modern applications comprise hundreds, even thousands of open-source components. This extreme heterogeneity makes exercising due diligence a massive scalability issue.

2. Sharing Vulnerability Fixes (Article 13(6)) 🌐

If a manufacturer develops a fix for a security issue, they should share it with the upstream project or maintainer, not keep it private.

  • The Challenge: Again, the sheer diversity of open-source projects and maintainers, coupled with many in-house developers being unfamiliar with upstream workflows, creates significant potential for friction in the ecosystem.

3. Effective Vulnerability Handling (Article 13(8)) 🛠️

Manufacturers must take care of vulnerabilities affecting their products by fixing them.

  • The Challenge: The sheer number of vulnerabilities has exploded in recent years. This isn’t necessarily because software is less secure, but because more issues are reported (e.g., bug reports now treated as vulnerabilities). This significantly increases the risk and effort of dealing with open-source software.

The Looming Trade-off: Open Source vs. In-house Code ⚖️

Jan pointed out a critical shift in corporate incentives. The burden of meeting CRA obligations, like achieving “zero CVE code” (fixing all known vulnerabilities), can make companies more selective about which open-source components they adopt. This could lead to a decreasing incentive to use open source and a greater reliance on in-house code.

The rise of AI and WIP (Work-in-Progress) coding further complicates this. While these tools can reduce the market cost of creating code, the lifecycle cost of maintaining it remains. Companies face a constant trade-off between leveraging the vast open-source ecosystem and building minimal source code internally.

Two Futures for Open Source: Fragmentation or Reinvention? 🔮

These pressures paint two starkly different future scenarios for the open-source ecosystem:

Scenario 1: The Fragmented Future 💔

If legal, geopolitical, and geoeconomic forces overwhelm companies, they might turn inward. This could lead to:

  • Ecosystem Fragmentation: More incompatible versions of components.
  • Mega-corps: Re-developing entire platforms in-house, or relying on 3PPs and AI for dependencies.
  • Burdened Maintainers: Remaining open-source maintainers would face even greater obligations without corporate backing.
  • Erosion of Value: The immense value open source adds to the global economy (estimated at $8.8 trillion) could be slowly eaten away.

Scenario 2: Institutional Reinvention ✨

Alternatively, institutions like the OpenSSF and CNCF could step up, helping projects and maintainers meet regulatory requirements. This would involve:

  • Clear Separation: Defining a “code of commons” (globally used code) and “deployment sovereignty” (region-specific regulations).
  • Healthy Growth: Continuing the growth of open source, albeit potentially at a slightly slower pace.
  • Built-in Trust: Trust in open source would be built at a foundational or institutional level, ensuring companies can rely on components.
  • Global Backbone: Open source would remain a global backbone for innovation.

Ericsson firmly believes we must strive for the second scenario.

Ericsson’s Blueprint: Strong Upstream Collaboration as the Solution 🚀

Georg emphasized that achieving the “Institutional Reinvention” scenario requires a cultural shift, starting with open-source consumers. OSPO teams play a crucial role in anchoring the understanding that securing the supply chain demands “boots on the ground” – developers actively working in upstream projects, fixing issues, and supporting maintainers.

This involves:

  • Updating Company Strategies: Aligning with proactive upstream engagement.
  • Training Developers & Managers: Equipping teams with the skills and mindset for effective collaboration.
  • Streamlining Contribution Processes: Making it easier for internal developers to contribute to open source.

Why Does Upstream Collaboration Win? 🏆

Georg highlighted how strong upstream collaboration directly addresses the three CRA obligations:

  1. Exercising Due Diligence: While scanning tools are valuable, having people in the community building networks among maintainers provides far higher quality insight into an open-source project’s security posture and roadmap.
  2. Sharing Vulnerability Fixes: The challenge isn’t just creating a fix, but developing one that is valuable to the upstream maintainer and conveying it effectively. Collaborating directly with maintainers ensures fixes are adopted, reducing friction and benefiting the entire ecosystem.
  3. Effective Vulnerability Handling: Many vulnerabilities stem from transitive dependencies. Supporting maintainers in bumping versions to eliminate these vulnerabilities is highly appreciated and a practical way to contribute value, making the ecosystem more secure for everyone.

Ultimately, Georg argued, this investment lowers risk and cost for businesses, a language every stakeholder understands.

Real-World Impact: Ericsson’s Quantified Success 📈

Jan provided compelling evidence from Ericsson’s own journey with their Kubernetes distribution product. Their goal was simple: fix issues at the source, upstream all security fixes, and eliminate internal forks.

Here’s what they achieved:

  • Ecosystem Reach: Ericsson’s team touched roughly half of the entire Kubernetes ecosystem with their contributions.
  • Key Activities: They automated dependency bumps (using tools like Dependabot), pushed PRs for version updates, fixed TLS encryption on interfaces, documented best security practices, and introduced public scanning tools to projects.
  • Quantified Contributions:
    • 214 Pull Requests (PRs) directly addressed first-level security fixes (including, but not limited to, CVEs).
    • Over 1,400 PRs focused on bumping dependencies, from small libraries to larger Go dependency uplifts.

Tangible Benefits for Ericsson:

  • No Internal Forks: They eliminated the need for internal patches, simplifying their release cycles.
  • Community Review: Fixes received scrutiny and validation from the wider community, enhancing quality.
  • Wider Impact: Their contributions benefited not just Ericsson, but all participants in the ecosystem, fostering trust and shared security.

Jan emphasized that quick wins include starting with dependency bumps, scanner integrations, and documentation fixes, many of which have guidelines from organizations like OpenSSF.

Your Call to Action: Let’s Build a Stronger Open Source Together! 💪

Georg closed with a powerful invitation. Ericsson’s experience demonstrates that investing in upstream collaboration yields tangible results: saved costs and reduced risk. But we can achieve even more by working together.

He urged companies to:

  • Join the Network: Collaborate with Ericsson and other like-minded organizations to build a stronger, more secure, interoperable, and non-fragmented open-source ecosystem.
  • Engage in Dialogue: Discuss common challenges, even sensitive security topics, in safe environments like the OpenSSF.
  • Foster Joint Efforts: Create networks among OSPO professionals and product development teams to jointly address open-source security concerns with the community.

Addressing the Licensing Conundrum 💡

During the Q&A, an audience member raised a valid concern: what about open-source providers changing licenses, jeopardizing project availability? Georg acknowledged that while business rationale drives such decisions, coming together as a community provides a platform for discussion and potential solutions. Whether it’s considering a fork or rallying support for an alternative, having “speaking partners” is crucial. This collaborative approach extends beyond security to broader ecosystem sustainability challenges.

The CRA is here, and it demands our attention. But by embracing strong upstream collaboration, we can transform a regulatory challenge into an unprecedented opportunity to secure, sustain, and strengthen the open-source backbone that powers our digital world. Let’s innovate and secure our future, together!

Appendix