Merging Security and Compliance: Perspectives on Emerging Regulations and Best Practices

Merging Security and Compliance: Perspectives on Emerging Regulations and Best Practices

Speakers: Mike Lieberman, TAG Security Tech Lead at CNCF & OpenSSF Governing Board Member; Eddie Knight, CNCF Security Advisory Group & Leader at Fintech Open Source Foundation

Conference: VulnCon

YouTube: https://www.youtube.com/watch?v=H-7CKqjRH14

Overview

This talk, presented at VulnCon, delves into the intricate and increasingly vital intersection of security, compliance, and open source software, with a particular focus on emerging global regulations like the European Union's Cyber Resilience Act (CRA). Given by Mike Lieberman, a TAG Security Tech Lead at the CNCF and an OpenSSF Governing Board member, and Eddie Knight, who works with the CNCF Security Advisory Group and leads initiatives at the Fintech Open Source Foundation, the session illuminates the profound implications these legislative shifts have on software supply chains. The speakers, both co-authors of the Open Source Project Security Baseline, share insights from their work at the forefront of open source security, emphasizing the need for a unified approach to meet compliance obligations while enhancing real-world security.

The discussion highlights a significant paradigm shift: traditional boundaries between security and compliance are blurring, compelling organizations to adopt continuous security practices and robust vulnerability management strategies. The talk underscores that while open source maintainers are generally shielded from direct legal liability under the CRA, manufacturers leveraging open source in their commercial "products with digital elements" face stringent new responsibilities and severe penalties for non-compliance. This creates an urgent imperative for manufacturers to foster deeper engagement with upstream open source communities, moving beyond passive consumption to active contribution and collaboration.

The core message resonates with the growing awareness that global regulations are no longer just bureaucratic hurdles but powerful catalysts for driving concrete security outcomes across the software ecosystem. The speakers argue that while the initial prospect of the CRA was "scary" for many, its refined form, coupled with initiatives like the Open Source Project Security Baseline, offers a unique opportunity for legal systems to compel unprecedented collaboration within the cybersecurity community. This collective effort, they contend, is essential to raising the security bar for everyone, ultimately benefiting end-users and making it harder for malicious actors to exploit vulnerabilities.

Background

▶ Watch: Introduction to talk and speakers' security expertise (0:00)

The genesis of the discussion lies in the global proliferation of regulations designed to enhance cybersecurity, with the EU's Cyber Resilience Act (CRA) serving as a primary example. This legislation directly impacts any entity selling "products with digital elements" (PDEs) within the European Union, a broad category encompassing everything from software delivered over the internet to IoT devices. The speakers, having just presented a keynote on the CRA at KubeCon London, noted a stark contrast in awareness: while their VulnCon audience showed familiarity, a KubeCon crowd of 5,000 had only one person raise their hand when asked about the term "products with digital elements." This discrepancy underscores a critical challenge: despite the CRA's global reach, a significant portion of the software development community, particularly upstream open source maintainers, remains largely unaware or uncertain about its implications. Linux Foundation research, specifically the "Unaware and Uncertain" report, found that 62% of 600 interviewed upstream maintainers were "not familiar at all or were only slightly familiar" with the law, even among those from the US and EU.

A key point of clarification in the talk revolves around the three primary personas defined by the CRA:

1. Manufacturers: Entities that bring a product with digital elements to market in the European Union. These are the primary targets of the CRA and bear the direct legal liability for compliance.
2. Open Source Stewards: Organizations like the Linux Foundation, OpenSSF, or Eclipse. While not having direct legal liability, there are suggestions for their participation in the regulatory regime, often described as a "light touch."
3. Open Source Maintainers: Individuals or groups developing and maintaining open source projects. Crucially, if a maintainer is not bringing a product with digital elements to market in the EU, they have no direct legal liability under the CRA. Their code being publicly available on GitHub does not make them accountable to downstream users.

This distinction is vital because it shifts the burden of responsibility. Manufacturers can no longer simply "pass the buck" by blaming vulnerabilities in their open source dependencies. If they incorporate open source components, they become responsible for managing the security of those components within their commercial product. For example, a manufacturer using vanilla Kubernetes is accountable for its vulnerabilities, whereas a company purchasing a managed Kubernetes service from a cloud provider would see that provider assume the commercial and legal liability.

The CRA itself is a dense, nearly 100-page document, characterized by its precise but often convoluted language. The phrase "products with digital elements" appears hundreds of times, making it challenging to parse for non-legal professionals. This complexity often leads to confusion about how regulatory compliance translates into real-world security practices for product security teams and open source developers. The speakers acknowledge the common mantra "security is not compliance," but argue that this line is increasingly blurring due to the rapid pace of security development and the need for continuous compliance and continuous audits. Annual audits are no longer sufficient for software released multiple times a day; security, legal, and compliance teams must be tightly coupled to prevent costly misalignments and ensure ongoing adherence to evolving standards.

The CRA specifically focuses on two main areas relevant to the audience: Software Development Life Cycle (SDLC) practices, emphasizing secure by design and secure by default principles, and vulnerability management. The latter is of particular interest to the VulnCon audience, as it mandates specific practices for manufacturers and, to a lesser extent, stewards. The challenges of vulnerability management are immense, even for highly resourced projects like Kubernetes, where resolving a single vulnerability can consume "three days of dedicated focused effort from a massive team." For individual maintainers supporting hundreds of projects, this burden is simply unsustainable.

A critical challenge highlighted is the disconnect between manufacturers and upstream open source. Few commercial enterprises directly contribute to or interact with their upstream open source providers, creating a significant hurdle for meeting the CRA's demanding timelines. Manufacturers are tempted to fork open source projects and maintain them independently, but this is described as "one of the most risky and one of the most costly" practices. Modern open source projects like Kubernetes have rapid release cadences (e.g., every three months), meaning a fork quickly drifts four versions behind in a year, incurring massive maintenance and security debt. The solution, the speakers argue, lies in fostering better relationships with upstream projects, contributing resources, and collaborating through open source stewards to centralize efforts and fix vulnerabilities collectively.

Key Findings

▶ Watch: Determining if your organization faces potential CRA fines (6:00)

The talk presents several key findings and paradigm shifts driven by emerging regulations like the CRA:

• Global Reach and Unawareness: The Cyber Resilience Act (CRA) has globe-spanning implications, impacting any entity selling "products with digital elements" in the EU market, regardless of their physical location. Despite this broad reach, a significant majority (62%) of upstream open source maintainers remain "unaware and uncertain" about its requirements, posing a substantial risk to the broader software supply chain.
• Liability Shift to Manufacturers: The CRA fundamentally redefines legal liability, largely shielding individual open source maintainers (unless they are acting as manufacturers) and placing the onus squarely on manufacturers who commercialize software. This means manufacturers cannot externalize the risk of vulnerabilities in open source components; they are directly responsible for ensuring the security of their entire product stack.
• Mandatory Engagement with Upstream: To meet the CRA's stringent vulnerability management timelines (e.g., 24-hour notice for exploited vulnerabilities, 72-hour advisory), manufacturers are compelled to move beyond passive consumption of open source. They must actively engage, contribute resources, and build direct relationships with upstream open source projects. The costly and risky practice of forking projects is highlighted as an unsustainable alternative in a world of rapid open source development cadences.
• Blurring Lines Between Security and Compliance: The traditional separation of "security" and "compliance" is increasingly obsolete. Modern regulations, especially with the demand for continuous compliance, necessitate a tight coupling of security practices with regulatory requirements. Standards, guidelines, and frameworks are now seen as essential tools for achieving real-world security outcomes that also satisfy legal obligations.
• The Open Source Project Security Baseline (OSPSB) as a Solution: The talk introduces the OSPSB as a critical tool designed to bridge the gap between open source development and regulatory demands. This baseline provides clear, actionable security requirements for open source projects, mapped directly to CRA Annex 1 requirements, covering 19 out of 21 requirements. It serves as both a guide for maintainers and a blueprint for manufacturers' software ingestion and procurement processes.
• High Stakes for Non-Compliance: The financial penalties for non-compliance with the CRA are severe, reaching up to 2.5% of a company's total worldwide annual turnover for each incident. This significant financial risk underscores the urgency for manufacturers, particularly those in industries new to such strict regulation (e.g., telco), to adapt their security and compliance strategies.
• Collaboration as the Path Forward: The speakers emphasize that the CRA, despite its initial perceived threats, is forcing an unprecedented level of collaboration. By centralizing resources and working through open source stewards and foundations, the community can collectively address vulnerabilities, develop harmonized standards, and present a unified voice to regulators, ultimately producing better security outcomes for everyone.

Technical Deep Dive

▶ Watch: Manufacturer persona: Direct liability under CRA (7:05)

The technical core of the talk revolves around understanding the specifics of the Cyber Resilience Act (CRA) and how the Open Source Project Security Baseline (OSPSB) provides a practical framework for compliance and enhanced security.

Cyber Resilience Act (CRA) Mechanics

The CRA defines "products with digital elements" (PDEs) broadly, encompassing any software distributed over the internet or integrated into hardware devices. Its reach extends globally, impacting any entity that sells such products within the European Union.

CRA Personas and Liabilities:

• Manufacturers: These are entities bringing a PDE to the EU market. They bear direct legal liability for compliance. This includes responsibility for vulnerabilities in any open source components they integrate into their commercial products. The talk explicitly states, "You can't pass the buck anymore... No, it is your responsibility."
• Open Source Stewards: Foundations like the Linux Foundation, OpenSSF, or Eclipse. They face "light touch" regulation, with suggestions for participation but no direct legal liability for vulnerabilities. They are encouraged to facilitate security improvements.
• Open Source Maintainers: If a maintainer is not bringing a product to market (e.g., a hobbyist project), they have no legal liability. "Nobody can come sue you because you have a vulnerability in the project you were working on over the weekend."

Manufacturer Obligations under CRA:

The CRA mandates two primary areas of focus:

1. Software Development Life Cycle (SDLC): Emphasizing secure by design and secure by default principles throughout the development process.
2. Vulnerability Management: This is a critical area with strict timelines:

• 24-hour notification: For known exploited vulnerabilities or severe vulnerabilities (those impacting confidentiality, integrity, or availability, especially with PII/PHI). This is a fast-track requirement.
• 72-hour security advisory: Manufacturers must have a security advisory prepared, with a patch or at least a workaround "strongly encouraged."
• 1-month post-mortem: A full post-mortem analysis and final resolution plan.

Compliance Deadlines:

• Mid-2025: More clarity expected on specific details and measurements.
• December 11, 2026: Reporting requirements come into full effect.
• End of 2027: Full regulatory effect for the long list of regulated activities.

Non-Compliance Fines (Article 64):

The financial stakes are exceptionally high:

• Up to 2.5% of total worldwide annual turnover for non-compliance with general requirements (Article 64, Item 34).
• Up to 2% of global total revenue for non-compliance with specific obligations in Articles 14, 23, 28, 31, 32, 33, 39, 41, 47, 48, 49, and 53.
• 1% of global turnover for supplying incorrect, incomplete, or misleading information. These are "Euros, not dollars," as highlighted by the speakers, and apply per incident.

Product Classification:

The CRA categorizes PDEs with differing compliance stringencies:

• Critical Products: Hardware security devices. Require third-party conformance assessments and are subject to "very, very, very strict rules."
• Important Products: Split into two subcategories:
• Type 2: Includes container orchestrators (e.g., Kubernetes). Requires third-party conformance assessments, but "maybe a little less strict" than Critical Products.
• Type 1: Includes operating systems. Allows for self-assessment, but still requires adherence to a harmonized standard.
• Everything Else: Requires self-assessment and adherence to "reasonable security things." Audits can be requested if suspicions arise.

The status of Software as a Service (SaaS) under CRA is noted to still have an "asterisk," implying ongoing clarification.

Open Source Project Security Baseline (OSPSB)

The OSPSB, or "baseline," is presented as a direct response to the need for clear, actionable security guidance for open source projects, particularly in light of regulations like the CRA.

Purpose and Structure:

• Descriptive Name: "The most descriptive name we could possibly think of."
• Core Minimum: Defines a "core minimum that should be true for all open source projects."
• Requirements: A catalog of 41 requirements, clearly stated as "when something is true then some actor must perform some action."
• Maturity Levels:
• Level 1: Achievable by a single maintainer project.
• Levels 2 & 3: "Stretch goals" for higher accountability, often for projects under stewards like the Linux Foundation.

Development and Alignment:

The baseline's requirements were developed by "combing through things like the NIST Cyber Security Framework, the Secure Software Development Framework (SSDF), things like OpenChain." Crucially, it includes a direct mapping to CRA requirements.

• CRA Coverage: The OSPSB "has legs to stand on for 19 out of those 21 requirements" from CRA Annex 1.
• Gaps: It does not cover requirements around handling sensitive data or removing user data from a system because "upstream is really about the software the project. They're not really about a solution." Manufacturers must address these two additional points themselves.

General Good Security Practice:

Beyond CRA compliance, the OSPSB promotes good security practices for all open source projects, even those not directly subject to the CRA. Examples include:

• Security Documentation: Even if it states, "this project is not secure, please do not use it for security-sensitive applications," such documentation is valuable for downstream consumers.
• Basic Protections: Simple, low-effort, high-impact measures like enabling Multi-Factor Authentication (MFA) for GitHub credentials to prevent malicious code pushes and protect maintainer reputation.

Cross-Framework Mapping ("Compliance Crosswalk"):

The baseline's catalog includes a "massive crosswalk" mapping its requirements to other major cybersecurity frameworks, demonstrating that "you do the compliance once and how it's applicable in other frameworks and legislative organizations." This includes:

• NIST 853, 161
• FedRAMP
• PCI DSS (PCI DSS 4.0 currently being mapped)
• White House SSDF attestation
• Dora N 2
• Emerging AI laws (executive orders, EU AI Act)

The OSPSB fills a critical gap by providing guidance specifically tailored to the collaborative and distributed nature of open source development, unlike enterprise-focused frameworks (e.g., NIST 853 with its "guards with guns and dogs and cameras") or even the SSDF, which doesn't fully "dig deep into how modern software is developed." It holistically covers how software is developed, compiled, built, distributed, consumed, and maintained.

Tooling and Standardization

The talk briefly mentions projects like In-Toto from the Cloud Native Computing Foundation (CNCF). In-Toto allows for cryptographically attestable security practices, enabling projects to "sign records of hey I checked... I ran OSV scanner and that zero vulnerability showed up every day." Such attestations serve as crucial evidence for auditors.

Regarding standardization, the European Commission is actively working to point to internationally adopted best practices and standards for CRA requirements. Bodies like Etsy standardization and Senselac for standardization, along with an "expert group" of predominantly European cybersecurity experts and liaisons from foundations (Eclipse, Linux Foundation, OpenSSF), are involved in identifying and developing these harmonized standards. This process is complex, potentially involving 41 different standards, but aims to provide clear models for product security teams and coordinated vulnerability disclosure.

Demo / Proof of Concept

▶ Watch: Open Source Stewards: Suggestions, not direct legal liability (7:45)

This technical article is based on a conference talk that primarily focused on conveying information, legislative implications, and strategic advice. The speakers did not present a live technical demonstration or a proof of concept during this session. Their discussion centered on frameworks, regulations, and best practices rather than showing specific tools in action, though tools like In-Toto were mentioned as relevant for attestations.

Defensive Implications

▶ Watch: Open Source Maintainers: No liability if not selling products (8:00)

The insights shared in this talk present clear and actionable defensive implications for various stakeholders in the software supply chain, particularly in the context of emerging regulations like the CRA.

For Manufacturers (Commercial Enterprises):

• Understand Your CRA Exposure: Proactively assess if your products qualify as "products with digital elements" and if they are sold in the EU. Recognize that this applies regardless of your company's geographic location. Ignorance is not a defense; non-compliance carries severe financial penalties (up to 2.5% of global annual turnover).
• Deeply Engage Upstream Open Source: Shift from passive consumption to active contribution. This means providing resources, funding, and engineering time to the open source projects your commercial products depend on. Building strong relationships with maintainers is crucial for meeting the CRA's demanding vulnerability response timelines (e.g., 24-hour notification, 72-hour advisory). The speakers observed that few commercial enterprises currently do this, highlighting a significant gap.
• Evaluate and Prioritize Open Source Dependencies: Create a comprehensive list of your most critical open source components. You will be responsible for all of them, not just the top 10. Start small, understand their security posture, and grow from there.
• Avoid Costly Forking: Recognize that forking open source projects is a "risky and costly" strategy, especially given the rapid release cadences of modern projects (e.g., Kubernetes releases every three months). Maintaining multiple forks quickly leads to significant technical debt and security drift.
• Adopt the Open Source Project Security Baseline (OSPSB): Utilize the OSPSB as a blueprint for your internal secure development practices and for evaluating the security posture of your open source dependencies and suppliers. Integrate its requirements into your procurement and software ingestion processes. While it doesn't cover sensitive data handling or user data removal (two specific CRA requirements for manufacturers), it covers 19 out of 21 Annex 1 requirements, providing a strong foundation.
• Implement Attestation Tooling: Employ tools like In-Toto to cryptographically attest to your security practices (e.g., daily vulnerability scanning, secure build processes). These attestations provide verifiable evidence for auditors and market surveillance authorities, demonstrating due diligence.
• Prepare for Continuous Compliance: Move beyond annual audits. Integrate security, legal, and compliance teams to ensure continuous adherence to regulations. This proactive approach prevents "surprise" findings and costly remediation efforts.
• Leverage Open Source Stewards: Collaborate with foundations like the Linux Foundation, OpenSSF, and Eclipse. These stewards centralize resources and expertise, allowing manufacturers to collectively address common open source vulnerabilities and influence the development of harmonized standards.

For Open Source Maintainers:

• Embrace the Open Source Project Security Baseline (OSPSB): Even if not directly liable under the CRA, following Level 1 of the OSPSB is considered "just good security practice." It provides clear, low-effort steps to enhance project security and build trust with downstream consumers.
• Provide Clear Security Documentation: Even if it's simply a statement like "this project is not secure, please do not use it for security-sensitive applications," transparent documentation helps downstream users make informed decisions.
• Implement Basic Security Measures: Adopt straightforward, high-impact security practices, such as enabling Multi-Factor Authentication (MFA) for source code repositories (e.g., GitHub). This protects your project's integrity and your reputation from credential theft and malicious code injection.

For Open Source Stewards and Foundations:

• Facilitate Collaboration: Continue to provide platforms and mechanisms for manufacturers and maintainers to interact, share resources, and collectively improve the security of critical open source projects.
• Advocate for Open Source Realities: Maintain engagement with regulatory bodies (e.g., European Commission, ENISA, standardization bodies like Etsy and Senselac) to ensure that harmonized standards reflect the practical realities and unique collaborative nature of open source development. The "expert group" and liaison roles are crucial for this.
• Develop and Promote Standards: Continue the work on initiatives like the OSPSB and its cross-framework mappings, providing clear, internationally recognized specifications that help the entire ecosystem meet compliance requirements efficiently.

Ultimately, the defensive implication is a call to collective action. The CRA is transforming compliance from a checkbox exercise into a driver for genuine security improvements across the software supply chain, forcing a long-overdue convergence of security and regulatory efforts.

Key Takeaways

• The Cyber Resilience Act (CRA) is a pivotal regulation that significantly shifts legal liability for software vulnerabilities to manufacturers who commercialize "products with digital elements" in the EU, regardless of their origin.
• A substantial portion (62%) of open source maintainers are currently unaware of the CRA's implications, highlighting a critical need for education and engagement across the software ecosystem.
• The Open Source Project Security Baseline (OSPSB) offers a practical, multi-level framework for open source projects, providing clear security requirements that are highly aligned with the CRA (covering 19 of 21 Annex 1 requirements) and other major cybersecurity frameworks.
• Manufacturers must move beyond passive consumption of open source; proactive engagement, contribution, and collaboration with upstream open source projects and stewards are essential to meet CRA deadlines and manage vulnerability risks effectively.
• Non-compliance with the CRA carries severe financial penalties, including fines of up to 2.5% of a company's total worldwide annual turnover per incident, underscoring the urgent need for robust compliance strategies.
• The CRA is compelling an unprecedented convergence of security and compliance, forcing the industry to unite and collaborate through open source stewards and foundations to collectively enhance security outcomes across the global software supply chain.

About the Speaker(s)

Mike Lieberman is a prominent figure in the open source security community. He serves as a TAG Security Tech Lead at the Cloud Native Computing Foundation (CNCF) and is a Governing Board Member and TAC Member at the Open Source Security Foundation (OpenSSF). Mike is also an active open source maintainer for multiple projects, including Salsa and GUAC. His expertise extends to the policy and framework development space, where he is one of the authors of the Open Source Project Security Baseline. Additionally, he co-authored the book "Securing the Software Supply Chain."

Eddie Knight is deeply involved in security topics within the Cloud Native Computing Foundation (CNCF), specifically contributing to the Security Advisory Group. His background includes working in finance at tier-one banks, which led him to leadership roles at the Fintech Open Source Foundation. Eddie is a co-creator of the Open Source Project Security Baseline, demonstrating his commitment to supporting open source projects in delivering robust security features to their end-users.

Probe moderated the discussion and introduced himself as doing "security stuff on the internet," facilitating the conversation between the primary speakers.