Keynote: Cutting Through the Fog: Clarifying CRA Compliance in C... Eddie Knight & Michael Lieberman

Keynote: Cutting Through the Fog: Clarifying CRA Compliance in C... Eddie Knight & Michael Lieberman

Speakers: Eddie Knight, OSO Lead at Sonatype, Co-chair CNCF TAG Security; Michael Lieberman, CTO of Kusari, TAG Security Lead, OpenSSF Governing Board Member

Conference: KubeCon EU

YouTube: https://www.youtube.com/watch?v=A1HGYh0Wz9U

Overview

The European Union's Cyber Resilience Act (CRA) is poised to fundamentally reshape the landscape of cybersecurity for products with digital elements across the globe. In this KubeCon EU keynote, Eddie Knight and Michael Lieberman expertly navigate the complexities of this far-reaching legislation, aiming to demystify its implications for a predominantly open-source-centric audience. Despite a recent Linux Foundation survey indicating that 62% of attendees were unfamiliar with the CRA, the speakers assert that this regulation, ultimately intended to protect consumers and businesses from cyber threats, presents a significant opportunity for global cybersecurity improvement, rather than a cause for fear.

Knight and Lieberman, both deeply embedded in open-source security initiatives like the CNCF TAG Security and OpenSSF, bring a unique perspective to the CRA. Their talk focuses on clarifying the often-conflated roles and responsibilities of open-source maintainers, manufacturers, and stewards under the new regime. A central theme is the unexpected positive clarity the CRA introduces, particularly in distinguishing between individual open-source contributions and commercial activities, thereby enabling better risk planning and fostering a more secure software supply chain.

This detailed article delves into the core tenets of the CRA as presented by Knight and Lieberman, exploring its scope, timeline, and the nuanced definitions that determine liability. It examines the practical steps businesses and open-source projects must take to prepare for compliance, highlighting the critical support structures being built by organizations like the Linux Foundation and OpenSSF. By dissecting the legislation's impact on entities ranging from individual contributors to large enterprises distributing open-source products, the article provides a comprehensive guide to understanding and leveraging the CRA for enhanced cyber resilience.

Background

▶ Watch: Introduction to CRA and its core purpose (0:00)

The Cyber Resilience Act (CRA) is a landmark piece of European Union legislation designed to bolster cybersecurity for hardware and software products. Its primary objective is to protect consumers and businesses within the EU from the escalating threat landscape by mandating security requirements for products with digital elements sold in the European market. This regulatory push stems from a recognition that the increasing interconnectedness of devices and reliance on software necessitates a stronger, standardized approach to security throughout the product lifecycle.

The concept of a "product with digital elements" is broadly defined by the CRA as any product whose intended or foreseeable use includes a direct or indirect data connection to a device or network. In practice, as the speakers simplify, "pretty much if you ship hardware or you ship software, it generally falls under the purview of the CRA." However, there are notable exceptions and ongoing clarifications. Products already covered by other EU regulations, such as those in the automotive or medical device industries, are exempt. Furthermore, Software-as-a-Service (SaaS) generally falls outside the CRA's scope, though specific edge cases exist, particularly if a piece of shipped software can only operate with a proprietary SaaS offering. These definitions are still being refined, with ongoing discussions among EU working groups to close potential loopholes and provide greater precision.

The CRA's implementation follows a staggered timeline, designed to provide organizations with a period of adjustment. While the legislation goes into full effect in 2027, mandating comprehensive security responsibilities including the provision of Software Bill of Materials (SBOMs) and adherence to general good security practices for software and its dependencies, earlier milestones are critical. By mid-2026, conformity assessment bodies will begin locking in the precise details of assessment criteria. Crucially, the first concrete responsibility takes effect on December 11th, 2026, requiring the reporting of any known exploitable vulnerabilities in products with digital elements. This phased rollout underscores the EU's intent to allow industry time to adapt, while also establishing an early focus on vulnerability transparency. The speakers highlight the global impact of this EU legislation, noting that businesses worldwide will need to comply if they intend to sell products in the European market, making this a pivotal topic for the diverse KubeCon audience.

Key Findings

▶ Watch: Clarifying 'Product with Digital Elements' under CRA (3:20)

The central finding of this talk is the unprecedented clarity the CRA brings to the roles and responsibilities within the software supply chain, particularly for the open-source community. For years, the question of liability for open-source components has been a source of significant fear, uncertainty, and doubt (FUD). The CRA, as interpreted by Knight and Lieberman, provides a definitive answer: individual open-source maintainers have no legal liability under the legislation. This is a critical distinction that aims to protect the vast volunteer efforts underpinning much of modern software.

However, this protection for individual maintainers comes with a crucial caveat. If an entity's business involves maintaining open source and bringing it to market as part of a commercial activity, even if the open-source product itself is free, that entity is considered a manufacturer and assumes legal liabilities. This distinction clarifies that commercialization, not just contribution, triggers responsibility. The speakers emphasize that this clarity is "extremely good news" and will "unlock positive business activity" by allowing businesses to understand and plan for their obligations.

Another key finding is the introduction of the steward role, a category designed for non-profit organizations that manage open-source projects where any funds generated are reinvested back into the open source itself. Stewards are subject to a "light touch, custom-tailored regulatory regime" that will be determined on a case-by-case basis. This acknowledges the unique structure of many foundational open-source projects and provides a pathway for their continued operation without the full regulatory burden of a commercial manufacturer.

Finally, the talk highlights the CRA's categorization of products with digital elements based on their criticality and associated assessment requirements:

• Critical products: These include specific types of security hardware and require third-party conformance assessments.
• Important products (Class 2): This category includes container orchestrators (like enterprise Kubernetes flavors) and also mandates third-party security assessments.
• Important products (Class 1): Surprisingly, this category includes operating systems and has fewer requirements, primarily mandating self-assessment of security practices.
• Everything else: All other products sold in the EU fall under a general category with self-assessment requirements.

This tiered approach allows for differentiated regulatory burdens based on the potential impact of a product's compromise, providing a structured framework for compliance. The ability to shift risk and liability through commercial support contracts for open-source components is also identified as a significant benefit, fostering a more mature and accountable ecosystem.

Technical Deep Dive

▶ Watch: Products and services generally excluded from CRA (4:10)

The Cyber Resilience Act (CRA) introduces a structured framework for securing products with digital elements, demanding a granular understanding of definitions, roles, and compliance requirements. At its core, a "product with digital elements" is broadly interpreted as any software or hardware product with an intended or foreseeable direct or indirect data connection to a device or network. This expansive definition means that most developers and distributors of modern technology will likely fall under its purview. Key exclusions exist for products already regulated by sector-specific EU legislation (e.g., automotive, medical devices). Furthermore, Software-as-a-Service (SaaS) is generally excluded, though the lines blur if a shipped software product is inextricably linked to a specific SaaS offering. The ongoing clarification of these boundaries by EU working groups underscores the dynamic nature of the legislation as it adapts to the nuances of the digital economy.

The CRA fundamentally redefines accountability by delineating three primary roles: maintainers, manufacturers, and stewards.

• Maintainers: For individual contributors to open-source projects, the CRA provides significant relief. The speakers explicitly state that there is no legal liability for maintainers acting in a non-commercial capacity. This crucial distinction addresses widespread concerns that the legislation might stifle open-source innovation by burdening volunteers with legal obligations.
• Manufacturers: This category encompasses any entity that sells a product with digital elements in the EU. Crucially, if a business maintains open source and brings it to market as part of a commercial activity, even if the open-source product itself is free, that entity is classified as a manufacturer. This means they bear legal liabilities and cannot "pass the buck" to upstream open-source maintainers. An example cited is an enterprise distribution of Kubernetes: if a company distributes Kubernetes as part of a commercial product, they assume the manufacturer's responsibilities. These responsibilities include ensuring general good security practices, providing Software Bill of Materials (SBOMs), and managing dependencies securely.
• Stewards: This new category is tailored for non-profit organizations that manage open-source projects, where any revenue generated is reinvested directly back into the open-source ecosystem. Stewards will be subject to a "light touch, custom-tailored regulatory regime," with compliance requirements determined on a case-by-case basis. This recognizes the unique operational model of many foundational open-source foundations and projects.

The CRA categorizes products into tiers based on their criticality, each with corresponding assessment requirements:

1. Critical Products: These are defined as specific types of security hardware. They require a third-party conformance assessment, indicating the highest level of scrutiny.
2. Important Products (Class 2): This category includes products like container orchestrators. These also necessitate a third-party security assessment, reflecting their integral role in modern infrastructure.
3. Important Products (Class 1): This somewhat counter-intuitively includes operating systems. While deemed "important," they currently have fewer stringent requirements than Class 2, primarily requiring self-assessment of security practices. The speakers note that this categorization is still "being sorted out."
4. Everything Else: Any other product with digital elements sold in the EU falls into this general category, requiring self-assessment.

The timeline for CRA compliance is phased:

• Full Effect (2027): All security responsibilities, including SBOMs and general good practices for software and dependencies, become mandatory.
• Mid-2026: Conformity assessment bodies will finalize the precise details and criteria for assessments.
• December 11th, 2026: The first specific responsibility takes effect: mandatory reporting of any known exploitable vulnerabilities in products with digital elements. This early requirement emphasizes proactive vulnerability management and transparency.

A significant benefit highlighted by the speakers is the ability for businesses to strategically shift risk and liability. For example, a company building a product using an open-source component can leverage enterprise support services or commercial distributions of that component. By doing so, the commercial provider assumes some of the legal liability under the CRA, which the product builder can then offset. This facilitates better contractual agreements and a more predictable risk landscape for businesses integrating open-source into their commercial offerings. The clarity introduced by the CRA empowers businesses to make informed decisions about assuming or mitigating business risk associated with their software supply chain.

Demo / Proof of Concept

▶ Watch: Introducing 'stewards' for non-profit open source projects (7:00)

The keynote itself did not feature a live demonstration or a technical proof-of-concept of a vulnerability or a compliance tool. Instead, the speakers focused on elucidating the legislative framework and its implications. However, they dedicated a significant portion of their discussion to the ongoing efforts by organizations like the Linux Foundation, CNCF, and OpenSSF to provide tools, guidance, and support structures to aid the open-source community and commercial entities in achieving CRA compliance. These initiatives effectively serve as the "proof of concept" for how the industry can collectively respond to the CRA.

Michael Lieberman detailed how the Linux Foundation is "very, very, very invested in making this as easy as possible for absolutely everybody." This includes the upcoming rollout of LFX Insights in the summer, which is expected to provide valuable data and tools to streamline the adoption of secure practices and enhance accountability within open-source projects. This platform aims to make tangible, impactful security improvements measurable and actionable.

Eddie Knight further elaborated on the OpenSSF Baseline, a crucial project co-authored by both speakers. This initiative aims to codify "the minimum necessary security practices that every single open-source project should do." By translating these practices into "control language" and making them measurable, the Baseline provides a concrete, actionable framework for projects to assess and improve their security posture. This is particularly relevant for projects that may eventually be incorporated into commercial products and fall under CRA scrutiny.

Beyond these tools, the Linux Foundation and OpenSSF are actively engaged in practical, hands-on work with specific projects. The speakers mentioned recent collaborations with OpenTelemetry, Flux, Measurery, and OSCAL Compass to implement tangible security improvements. This proactive engagement is designed to prepare these projects for future accountability requirements under regulations like the CRA. Furthermore, the OpenSSF is developing recommendations for assessments, which will guide projects on the best ways to conduct self-assessments and identify areas for security enhancement. These collective efforts represent a comprehensive strategy to equip the open-source ecosystem with the resources needed to navigate the CRA successfully, transforming potential regulatory burdens into opportunities for enhanced security.

Defensive Implications

▶ Watch: CRA product categories: Critical, Important (Class 1 & 2) (8:30)

The Cyber Resilience Act (CRA) presents significant defensive implications for all entities involved in the software supply chain, from individual developers to large enterprises. Understanding and proactively addressing these implications is crucial for mitigating risk and ensuring continued market access in the EU.

For manufacturers and businesses developing or distributing products with digital elements, the primary defensive strategy is proactive compliance. This involves:

1. Scope Assessment: Immediately identifying if their products fall under the CRA's definition and which criticality category they belong to (Critical, Important Class 1/2, or general). This includes understanding the nuances around SaaS and other exemptions.
2. Vulnerability Management: Preparing for the December 11th, 2026, deadline for reporting known exploitable vulnerabilities. This necessitates robust internal processes for vulnerability discovery, assessment, and disclosure, potentially including bug bounty programs or coordinated vulnerability disclosure policies.
3. Supply Chain Transparency: Implementing mechanisms to generate and maintain Software Bill of Materials (SBOMs) for all products. This allows for clear visibility into third-party and open-source dependencies, enabling faster response to vulnerabilities originating upstream.
4. Security by Design: Embedding good security practices throughout the product development lifecycle, as mandated by the CRA. This includes secure coding practices, threat modeling, security testing, and maintaining secure configurations.
5. Risk Transfer Mechanisms: Strategically utilizing commercial support contracts and enterprise distributions of open-source components to shift legal liability. This allows businesses to consciously assume or mitigate risk based on their operational model and contractual agreements.
6. Engagement with Conformity Bodies: Monitoring the developments from conformity assessment bodies as they lock in assessment details by mid-2026, and preparing for either self-assessment or third-party audits based on product categorization.

For open-source projects and their maintainers and stewards, while individual maintainers are largely shielded from legal liability, there are still strong defensive reasons to engage with CRA-driven security improvements:

1. Adoption of Best Practices: Actively embracing guidelines like the OpenSSF Baseline for minimum necessary security practices. While not legally mandated for individual contributors, adhering to such baselines makes projects more robust, trustworthy, and attractive to commercial users who are subject to the CRA.
2. Tooling and Guidance: Engaging with and contributing to the development of tools and recommendations from organizations like the Linux Foundation and OpenSSF (e.g., LFX Insights, recommendations for assessments). These resources will streamline security improvements and facilitate easier integration into compliant commercial products.
3. Community Collaboration: Participating in working groups and discussions to help shape future interpretations and tools related to the CRA. This ensures that the open-source community's unique needs and capabilities are considered in the evolving regulatory landscape.
4. Enhanced Project Health: Proactively improving security posture reduces the likelihood of exploitable vulnerabilities in open-source components, which benefits the entire ecosystem and reduces the downstream burden on manufacturers.

In essence, the CRA forces a maturation of cybersecurity practices across the digital supply chain. Defenders must move beyond reactive measures to a proactive, integrated approach that considers security from initial design to post-deployment vulnerability management, leveraging the clarity and support provided by industry initiatives to build a more resilient digital future.

Key Takeaways

• CRA's Purpose and Scope: The European Union's Cyber Resilience Act (CRA) aims to protect consumers and businesses from cyber threats by mandating security requirements for products with digital elements sold in the EU, globally impacting hardware and software vendors.
• Clarity for Open-Source Maintainers: Individual, non-commercial open-source maintainers are explicitly not legally liable under the CRA, addressing significant prior concerns about stifling innovation.
• Manufacturer Responsibilities: Entities that commercially distribute or bring to market open-source projects or other products with digital elements are classified as manufacturers and bear significant legal liabilities, including requirements for SBOMs and good security practices.
• Phased Implementation and Key Dates: The CRA goes into full effect in 2027, but critical milestones include conformity assessment body details locking in by mid-2026, and mandatory reporting of known exploitable vulnerabilities starting December 11th, 2026.
• Product Categorization and Assessments: Products are categorized into Critical, Important (Class 1 & 2), and general, dictating whether self-assessment or third-party security/conformance assessments are required.
• Industry Support and Tools: Organizations like the Linux Foundation and OpenSSF are actively developing tools and guidance, such as the OpenSSF Baseline and LFX Insights, to help projects and businesses achieve compliance and enhance overall cybersecurity.

About the Speaker(s)

Eddie Knight is a prominent figure in the open-source security community, serving as the OSO Lead at Sonatype. His deep involvement extends to the Cloud Native Computing Foundation (CNCF), where he co-chairs the TAG Security, influencing security best practices across cloud-native projects. Knight is also recognized for his contributions to the OpenSSF Baseline, a key initiative to codify minimum security practices for open-source projects, reflecting his commitment to improving the security posture of the broader ecosystem.

Michael Lieberman holds the position of CTO at Kusari, a company focused on securing the software supply chain. He is also deeply involved with the CNCF TAG Security, working alongside Eddie Knight, and is a governing board member of the Open Source Security Foundation (OpenSSF). Lieberman's expertise in open-source security is further underscored by his co-authorship of the OpenSSF Baseline, demonstrating his dedication to providing actionable guidance for secure open-source development and consumption. Both speakers bring extensive experience from the United States to a discussion on European Union legislation, highlighting the global reach and impact of the CRA.