CHAOSS OSPO Working Group, January 8, 2026

CHAOSS OSPO Working Group, January 8, 2026 ![rw-book-cover](https://img.youtube.com/vi/WQ8xgIB4U6E/maxresdefault.jpg) 🔗 **Source:** [CHAOSS OSPO Working Group, January 8, 2026](https://www.youtube.com/watch?v=WQ8xgIB4U6E) > [!note]+ Document Notes > tags: #cybersecurity #european-regulation #open-source #compliance #digital-sovereignty > author: CHAOSS Community > source: YouTube > reference: https://www.youtube.com/watch?v=WQ8xgIB4U6E > date created: 2026-01-08 00:00 > > # 🏷️ Title: CHAOSS OSPO Working Group: CRA Impact on OSPOs and Digital Sovereignty >  ## 🧰 Action Inbox - [H1] Review CRA compliance obligations for products with open source components — 05:23 #cybersecurity - [H2] Assess digital sovereignty risks in technology selection decisions — 23:45 #digital-sovereignty - [H3] Join open regulatory compliance working groups to stay informed — 47:15 #open-source ## 🧭 Table of Contents - [[#📝 Summary]] - [[#📖 Main Content]] - [[#🗒️ Notes]] - [[#📚 References]] - [[#🗣️ Paraphrase]] - [[#📰 Newsletter]] - [[#✅ Action Items]] - [[#🧪 Hypotheses]] - [[#📊 Methodology]] - [[#❓ Questions]] - [[#🔮 Future Research]] - [[#💡 Implications]] - [[#🧠 Learning Styles Assessment]] - [[#📊 Accessibility Assessment]] - [[#🌍 DEIB Assessment]] - [[#✅ Logical Validity]] - [[#🛡️ DARVO Analysis]] - [[#🎯 Conclusion]] ### 🔗 References - [Open Regulatory Compliance Working Group](https://openssf.org/) - [CNCF Cloud Programs](https://cncf.io/) ## 📝 Summary - Juan Rico presented how the EU Cyber Resilience Act (CRA) affects Open Source Program Offices and digital sovereignty strategies - CRA targets manufacturers and retailers, not open source projects directly, but creates new obligations for vulnerability management - Digital sovereignty concerns degree of freedom in technology choices, separate from but related to CRA compliance - New roles include open source software stewards who can provide voluntary security attestations - Organizations need frameworks to evaluate open source components considering both regulatory compliance and autonomy risks ## 📖 Main Content The Cyber Resilience Act represents a fundamental shift in how the EU regulates digital products, driven by €5.5 trillion annual cybercrime impact. The regulation establishes three key obligations: products must be placed in market with no known vulnerabilities, vulnerabilities must be reported and fixed throughout product lifecycle, and manufacturers become responsible for entire supply chains including open source components. The CRA defines four product categories (default, important, critical, and free/open source software) with varying assessment requirements. Crucially, it introduces "open source software stewards" as a new role - foundations or companies that manage open source projects without monetizing them directly. These stewards can provide voluntary security attestations that help downstream manufacturers demonstrate compliance. Digital sovereignty, as Rico frames it, concerns maintaining freedom in technology choices rather than geographic origin of development. This intersects with CRA compliance as organizations must evaluate both regulatory obligations and long-term autonomy when selecting open source components. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/WQ8xgIB4U6E?t=0) — [H1] Introduction and agenda - Key idea: Meeting focuses on CRA impact on OSPOs and digital sovereignty - Evidence: "Impact to OSPOs for digital sovereignty and the CRA" #### ⏱️ [05:23](https://youtu.be/WQ8xgIB4U6E?t=323) — [H2] CRA objectives and scope - Key idea: CRA aims to protect European consumers from €5.5 trillion cybercrime impact - Evidence: "Cyber crime has an impact of 5.5 trillion euros yearly" #### ⏱️ [08:45](https://youtu.be/WQ8xgIB4U6E?t=525) — [H3] Key CRA obligations for manufacturers - Key idea: Manufacturers responsible for vulnerability-free products throughout lifecycle - Evidence: "Making them responsible for every single element in the products they are placing in the market" #### ⏱️ [12:15](https://youtu.be/WQ8xgIB4U6E?t=735) — [H2] Implementation timeline challenges - Key idea: Three years to develop 41 new standards for CRA compliance - Evidence: "It implies 41 new standards that were are completely new and that is super challenging" #### ⏱️ [16:30](https://youtu.be/WQ8xgIB4U6E?t=990) — [H3] Product categories and assessment requirements - Key idea: Four categories with different compliance requirements from self-assessment to certification - Evidence: "95% of the products will fall under this category and that's good news" #### ⏱️ [19:45](https://youtu.be/WQ8xgIB4U6E?t=1185) — [H1] New roles: stewards vs manufacturers - Key idea: Open source software stewards distinct from manufacturers based on monetization - Evidence: "Companies can play the same for the same code base they could be manufacturers and stewards" #### ⏱️ [23:45](https://youtu.be/WQ8xgIB4U6E?t=1425) — [H2] Digital sovereignty definition - Key idea: Digital sovereignty is degree of freedom in technology choices - Evidence: "My degree of freedom with the technology choices I make" #### ⏱️ [27:20](https://youtu.be/WQ8xgIB4U6E?t=1640) — [H3] Open source strengths and risks - Key idea: Open source offers transparency but creates dependency and responsibility gaps - Evidence: "Transparency collaboration and innovation" vs "dependencies...fragmentation...responsibility gap" #### ⏱️ [32:10](https://youtu.be/WQ8xgIB4U6E?t=1930) — [H2] Technical vs non-technical impacts - Key idea: Regulations affect both implementation and decision-making processes - Evidence: "Technical impact so new features more documentation new processes...non-technical ones" #### ⏱️ [35:40](https://youtu.be/WQ8xgIB4U6E?t=2140) — [H1] Three evaluation categories for components - Key idea: Governance, vulnerability handling, and supply chain hygiene assess component health - Evidence: "Governance and stewardship...vulnerability handling and transparency...supply chain hygiene" #### ⏱️ [41:25](https://youtu.be/WQ8xgIB4U6E?t=2485) — [H2] Security policies and attestations - Key idea: Projects need security policies; stewards can provide voluntary attestations - Evidence: "Security policy is probably I would say the most important one" #### ⏱️ [44:50](https://youtu.be/WQ8xgIB4U6E?t=2690) — [H3] Implementation challenges - Key idea: Text clarity, regulator interface, and standards contribution need improvement - Evidence: "Text is not written by people who are experts on open source" #### ⏱️ [47:15](https://youtu.be/WQ8xgIB4U6E?t=2835) — [H2] Call to action for community involvement - Key idea: Join existing regulatory compliance initiatives rather than waiting - Evidence: "Don't wait join existing initiatives...act as a group" #### ⏱️ [49:30](https://youtu.be/WQ8xgIB4U6E?t=2970) — [H1] Key takeaways for OSPOs - Key idea: Project participation easiest path to compliance, resilience, and sovereignty - Evidence: "Being part of the project is the easiest way to assume compliance resilience and sovereignty" ## 📚 References - [EU Cyber Resilience Act](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52022PC0454) - [CNCF Open Regulatory Compliance Working Group](https://github.com/cncf/tag-contributor-strategy) - [CHAOSS Metrics Models](https://chaoss.community/metrics/) ## 🗣️ Paraphrase - The CRA fundamentally changes manufacturer liability by making them responsible for all components including open source throughout product lifecycles - Digital sovereignty focuses on maintaining technology choice freedom rather than geographic development origins - Open source stewards provide a new compliance pathway through voluntary security attestations that benefit downstream manufacturers ## 📰 Newsletter The EU's Cyber Resilience Act is reshaping how organizations approach open source compliance and digital sovereignty. Juan Rico from the CNCF presented a comprehensive framework for OSPOs to evaluate both regulatory obligations and technology autonomy. Key insight: The CRA doesn't directly regulate open source projects but creates new obligations for manufacturers using open source components. Organizations can mitigate risks by participating in projects as stewards or contributors rather than passive consumers. Practical benefit: New evaluation frameworks help OSPOs assess components across governance, security policies, and supply chain practices - going beyond functionality to include compliance readiness. The regulatory landscape will continue evolving, making community participation in working groups like OpenSSF's Open Regulatory Compliance essential for staying ahead of requirements. Resources: [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/), [WP-CLI](https://wp-cli.org/) ## ✅ Action Items #### OSPO - Policy & Governance: Develop CRA compliance assessment frameworks for open source components - Security Management: Establish vulnerability monitoring across open source dependencies - Software Inventory: Map open source components to CRA product categories and assessment requirements - Developer Support: Train teams on steward vs manufacturer role implications - Community Engagement: Participate in regulatory compliance working groups and standards development - Strategic Alignment: Align digital sovereignty strategy with technology selection criteria #### Community - Maintainers: Implement security policies aligned with CRA standards development - Contributors: Engage in regulatory compliance discussions and standards contributions - Sponsors: Support steward organizations providing security attestations - Ecosystem: Coordinate cross-project approaches to regulatory compliance #### WordPress - Core: Assess CRA implications for WordPress as infrastructure component in commercial products - Community: Develop guidance for WordPress-based product manufacturers on CRA compliance - Security: Enhance vulnerability disclosure and tracking processes to support downstream compliance - Documentation: Create educational resources on regulatory compliance for WordPress ecosystem - Hosting: Clarify steward vs manufacturer roles for different hosting models ## 🧪 Hypotheses - Organizations participating as stewards or contributors in open source projects will demonstrate CRA compliance more efficiently than passive consumers - Digital sovereignty concerns will drive increased investment in open source project governance and sustainability - Security attestation markets will emerge as economic mechanisms connecting steward organizations with manufacturers - Regulatory compliance requirements will accelerate adoption of software bill of materials and vulnerability tracking practices ### 📊 Methodology - Comparative analysis of compliance costs between steward participants vs passive consumers - Survey research on technology selection criteria changes post-CRA implementation - Economic analysis of attestation pricing models and market dynamics - Longitudinal study of SBOM adoption rates across different regulatory jurisdictions ### ❓ Questions - How will market surveillance authorities distinguish between steward and manufacturer roles in practice? - What economic models will sustain security attestation provision by steward organizations? - How will smaller open source projects without formal stewards navigate CRA compliance requirements? ### 🔮 Future Research - Cross-jurisdictional comparison of regulatory interpretation and enforcement approaches - Development of automated tooling for CRA compliance assessment and monitoring - Investigation of federated attestation models across project ecosystems ### 💡 Implications - Practice: OSPOs need comprehensive frameworks evaluating both compliance and sovereignty risks in technology selection - Policy: Regulatory compliance working groups require sustained participation from open source community representatives - Security: Vulnerability management processes must support full product lifecycle obligations - Education: Technical teams need training on regulatory implications of open source consumption patterns - Funding: Security attestation and steward organization sustainability require new economic models ### 🧠 Learning Styles Assessment Reading level estimate: Grade 14-16 (Advanced undergraduate/graduate) #### 👀 Visual learners - Present: Clear categorization diagrams of CRA product types and roles - Improve: Process flow diagrams showing steward vs manufacturer decision trees #### 🔊 Aural learners - Present: Comprehensive verbal presentation with Q&A session - Improve: Podcast-style discussion format for complex regulatory topics #### 🗣️ Verbal learners - Present: Technical terminology clearly defined with examples - Improve: Analogies connecting regulatory concepts to familiar technology practices #### 🧩 Kinesthetic learners - Present: Interactive Q&A allowing exploration of specific scenarios - Improve: Workshop format with hands-on compliance assessment exercises #### 🧠 Logical learners - Present: Structured framework with clear categories and decision criteria - Improve: Decision matrices and risk assessment templates #### 🧑‍🤝‍🧑 Social learners - Present: Working group participation encouraged with community discussion - Improve: Peer review sessions for compliance strategies #### 🧘‍♀️ Solitary learners - Present: Comprehensive reference materials and white papers provided - Improve: Self-assessment checklists and individual study guides #### 🌿 Naturalistic learners - Present: Ecosystem thinking about interconnected project dependencies - Improve: Sustainability frameworks for long-term compliance approaches ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure and logical content flow - Improve: Enhanced alt text for regulatory framework diagrams #### Keyboard navigation - Present: Standard video player controls accessible via keyboard - Improve: Skip links for navigating long presentation sections #### Contrast and readability - Present: Standard video presentation format - Improve: High-contrast slide templates for regulatory content #### Text resizing and reflow - Present: Standard responsive video embedding - Improve: Ensure transcript text reflows properly at 200% zoom #### Media and captions - Present: Full transcript provided for accessibility - Improve: Professional captions with regulatory terminology accuracy #### Forms and interactions - Present: Basic meeting format with Q&A interaction - Improve: Accessible polling for audience engagement #### Standards reference - WCAG 2.2 AA compliance for transcript formatting and video embedding ### 🌍 DEIB Assessment #### Cultural breadth - Present: EU-focused regulatory perspective with global implications - Improve: Include perspectives from other regulatory jurisdictions #### Inclusive language - Present: Professional terminology with technical definitions - Improve: Reduce regulatory jargon with plain language alternatives #### Neurodiversity support - Present: Clear structure with defined agenda and time management - Improve: Content warnings for complex regulatory topics #### Representation - Present: Technical expertise from diverse organizational backgrounds - Improve: Include voices from smaller organizations and developing regions #### Psychological safety - Present: Encouraging tone about community participation - Improve: Explicit acknowledgment of regulatory complexity and learning curve ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Clear logical progression from CRA requirements to implementation obligations - Inductive strength: Examples from standardization experience support general conclusions about regulatory challenges - Causal reasoning: Strong connection between cybercrime costs and regulatory response motivations - Analogical strength: Effective comparison between technical and non-technical compliance impacts #### Fallacies - Appeal to consequences: Minor tendency to emphasize negative outcomes without balanced risk assessment - False dichotomy: Slightly oversimplified presentation of steward vs manufacturer roles #### Tone of voice - Overall tone: Professional, educational, and encouraging community participation while acknowledging complexity ### 🛡️ DARVO Analysis - Deny: No denial patterns observed - transparent about regulatory challenges - Attack: No attacks on accusers - collaborative approach with regulators - Reverse victim/offender: No victim/offender reversal patterns - Emotional cues and rhetoric: Balanced presentation acknowledging both opportunities and challenges ## 🎯 Conclusion The CRA represents a fundamental shift requiring OSPOs to develop comprehensive evaluation frameworks that balance regulatory compliance with digital sovereignty. Success depends on active community participation in standards development and regulatory interpretation rather than passive compliance strategies. Organizations should prioritize steward participation in critical open source dependencies while building internal capabilities for vulnerability management across product lifecycles. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad Purpose: Stage CEE units that become Literature notes. Split level: H3 ### [H1] CRA creates manufacturer liability for open source components throughout product lifecycle > [!quote] [CHAOSS OSPO Working Group: CRA Impact on OSPOs and Digital Sovereignty](https://www.youtube.com/watch?v=WQ8xgIB4U6E) by [[CHAOSS Community]] via [[YouTube]]. Published 2026-01-08. Accessed 2026-01-08. --- ## Full Transcript [00:01] There we go. Uh so welcome everyone to [00:06] the Chaos OSPO working group meeting for [00:09] Thursday, January 8th. Um happy new [00:12] year. Uh welcome back. It's good to see [00:14] everyone. [00:16] Um so we have today we have a couple of [00:20] things on the agenda. Um hopefully we [00:22] can get to hopefully we can get to both [00:24] of them. Um if not we might uh Natalya [00:27] need to bump the CMS update to next the [00:30] next meeting but we'll we'll try to get [00:32] to it. Um but the first thing we have on [00:34] the agenda is uh Juan Rico is here and [00:38] is going to talk about the impact to [00:41] OSPOS for digital sovereignty and the [00:44] and the CRA. So with that I will stop [00:47] sharing so that uh Juan can take it from [00:51] here. [00:52] >> All right. [00:54] Okay. Could you confirm if you see my [00:58] screen? [00:59] >> Yeah, looks great. Thanks. [01:01] >> Okay, perfect. So, first of all, thank [01:03] you for having me and thank you for the [01:04] invitation. Uh, it's always nice to [01:07] share what we are doing in this in this [01:09] area. Um, I was commenting previously [01:11] with uh Don. Uh, yeah, we target a [01:15] specific time for the presentation, but [01:17] then the questions always get wild. So [01:20] I'm ready for that and also for for [01:22] taking some of them offline. [01:25] Um okay so um just the objectives that [01:29] um I've set for the presentation it's [01:32] the first one is navigate the regulatory [01:34] waters of the CRA. This is something [01:37] new. It's changing the way the IT [01:39] industry is working and it's important [01:41] to understand what are the things that [01:42] are happening and how we can rely on [01:45] them or what are the the role that [01:47] opensource has and specifically um yeah [01:51] the different actors that are [01:52] considering the in the CRA. And the [01:55] second one is to prepare um ourselves [01:58] and the companies or institutions we are [02:00] representing to align with the [02:02] objectives of different legislative [02:04] initiatives. And that that's really [02:05] important. It's not only about the the [02:07] text, the legal text that uh this is [02:11] probably things like um that lawyers [02:13] should uh take care of but understanding [02:16] what are what is the philosophy behind [02:18] all those regulations and how we can [02:21] align what they are trying to achieve [02:23] what the things that we need to [02:24] implement. Um yeah I will share my [02:26] vision of uh the key components for a [02:29] healthy and sustainable open source [02:30] ecosystem because especially the CRA [02:33] this is one of the main objectives that [02:35] is uh pursuing and finally how to become [02:38] an active party in this new scenario. a [02:41] bit of myself. Yeah. Um working for the [02:44] CLI Foundation as senior manager for OC [02:46] on cloud programs. I'm also member of [02:48] the CRA expert group and involved in the [02:51] standardization efforts both on Etsy and [02:54] and Sense for the CRA. I have been [02:56] involved uh in IoT for my whole life. [02:59] And the most important thing of this [03:01] slide is I'm not sharing any legal [03:03] advice. uh this is just my understanding [03:05] of um of how uh the CRA and and the [03:09] topics I I'm going to share um yeah can [03:11] be uh implemented. [03:14] So um yeah the CRA that's the first um [03:17] and probably most important aspect I'm [03:20] going to share today and the most [03:23] important thing is that CRA is all about [03:25] protecting European consumers and [03:26] businesses. This is the thing that all [03:29] of us should have in mind. And when they [03:31] started to build the CRA, it was because [03:34] um they did um a research and they found [03:37] in 2021 that um cyber crime has an [03:41] impact of 5.5 trillion euros uh yearly. [03:45] So that's a huge thing and and the [03:48] impact on the on the businesses and then [03:50] the consumers in Europe is was huge. So [03:54] uh for that main reason they started to [03:56] think on how they can uh provide means [03:59] tools and regulations uh to reduce uh [04:02] the impact cyber crime has in in Europe [04:05] and yeah try to understand in the best [04:08] way they could uh how the IT industry [04:11] works uh to create this uh regulation. [04:14] So yeah uh let's say that the objective [04:17] is really good and uh what they need or [04:20] what we need is to work together to find [04:22] a way of uh achieving it. Um why the CRA [04:27] is concentrating so much attention. So [04:29] it's not only the high level objective [04:30] which is of course fine and I think [04:33] everyone agrees on it's uh also on what [04:36] are the obligations they are putting on [04:38] the manufacturers and retailers and [04:40] that's important. What the CRA is [04:42] targeting is manufacturer and retailers. [04:44] So it's not the open source projects. [04:46] It's not the open source community. It's [04:48] not developers. It's only manufacturers [04:51] and and retailers. And the CRA is making [04:54] them responsible for every single [04:56] element in the products they are placing [04:58] in the market. That's also a significant [05:01] change compared to what happened before. [05:04] Also, they are responsible through the [05:07] um and the whole product life cycle. So [05:09] it's not uh how you prepare the product [05:11] to be put in the market is what [05:13] happening what is happening to to it [05:16] once it's uh used by by your customers. [05:19] And finally because this is something um [05:23] yeah different and and impacts [05:26] especially the open source part is that [05:29] the CRA is making responsible [05:31] manufacturers or retailers for working [05:34] on reporting vulnerabilities and fixing [05:36] them. So those are three of the most [05:40] important changes that um that the CRA [05:43] is providing and why or one of the [05:45] reasons for uh making it so relevant and [05:48] all the noise that is um around it has [05:52] been uh created. [05:55] So yeah we have a clear high level [05:57] objective we have uh well clear [06:01] definition of what are the [06:02] responsibilities and who are the ones [06:03] that should be working on on them. how [06:07] to implement the CRAAS when things get a [06:10] bit more complicated and we are starting [06:12] with um a challenging implementation [06:14] timeline here what I'm sharing is just [06:18] um uh yeah the standardization pyramid [06:22] and basically when the CR was approved [06:25] it was um entering force 11th December [06:29] uh 2024 [06:32] um we have three years to define all the [06:35] things uh that need to be implemented [06:38] and among those things uh it implies 41 [06:42] new standards that um were are [06:45] completely new and that is super [06:48] challenging because we are um addressing [06:52] a new regulation. We are speaking about [06:55] new economic actors. We need to involve [06:58] new people in the development of the [06:59] standards that usually are not [07:01] contributing to them and we need to make [07:04] the people who is um traditionally [07:06] contributing to a standards to [07:08] understand how open source work. So that [07:12] is [07:13] challenging for not saying crazy um and [07:16] that's something that um yeah needs to [07:19] be done. Uh that's the reality. What the [07:22] CRA is is uh requesting is us to work [07:25] together to to build this um these [07:28] different standards. [07:30] I'm not going to get into the the [07:31] standards but um what is important is [07:34] there are like two main types well two [07:38] main groups. Uh the types are different [07:41] um term but the ones that are horizontal [07:44] that basically affects everyone and it's [07:47] basically um yeah obligations that [07:49] should be uh implemented by every single [07:52] product and we have the verticals that [07:54] uh basically affect a specific um uh [07:57] products [07:59] also for yeah understanding the [08:01] difference between uh horizontal and [08:04] verticals we have the product categories [08:07] and that's also So um yeah related to to [08:10] the previous pyramid and we have the [08:12] full category 95% [08:15] of the products will be fall under this [08:17] category and that's a good uh good news [08:20] in terms of uh the the number of new [08:24] obligations that should be put in place [08:26] or the yeah extra uh work and and money [08:30] that you should put to to launch [08:32] products to the markets because they are [08:34] um um yeah you can self assess that your [08:38] product is comply with the complies with [08:40] the with the CRA. [08:42] We have the important products uh which [08:45] basically has uh two main categories and [08:48] for this um that requires a third party [08:51] assessment of the key elements of the [08:53] system. So it's some of the parts could [08:55] be self assess some others should go [08:57] through third party assessment for the [09:01] critical products. Yeah. Uh probably [09:04] they will have uh certification [09:06] requirements. So also through third [09:09] party and they are uh covered by the by [09:12] the by the different vertical standards [09:15] and finally we have the free and open [09:17] source um software which is self [09:19] assessment as the the default category [09:22] unless they are categorized as uh [09:23] critical products. So the definition of [09:27] um of those categories is important [09:30] because depending on what are the [09:32] products that you are building how they [09:34] fall under um this categorization [09:37] and what is uh what you are trying to [09:40] build with them because yeah I'm not [09:42] including it here to not make it it [09:44] super complex but uh yeah we have some [09:47] products that combines multiple [09:49] functionalities and can make or create [09:53] doubt of uh whether this is crit [09:55] critical or important or is it default. [09:58] So yeah, it's important to understand [10:00] that we have these four categories. [10:02] Depending on which is the category your [10:05] product are falling under, you need to [10:07] implement a specific things to [10:08] demonstrate compliance with the CRA. And [10:11] also it's important to know if uh you [10:13] can self assess your products or you [10:15] should trust on third party [10:17] certification. [10:19] And yeah, something that is new under [10:22] the CRA is the roles define. And when I [10:26] refer to roles, we have manufacturers [10:28] and retailers. That's something that [10:30] everyone knows. Um, but basically are [10:33] the ones placing products in the on the [10:35] market on the European market. The [10:37] second category is open source software [10:39] stewards and they are actually uh [10:43] co-hosting foundations or for profits [10:46] that can be um stewards too if they are [10:49] not monetizing the pro the the project. [10:52] This is probably one of the most [10:54] important [10:57] categories. I'm I'm I'm going to justify [11:00] the most important um statement. The [11:04] point is that um yeah for uh open source [11:08] foundation it's clear they are going to [11:10] be stewards and especially if they are [11:12] hosting code they they are stewards by [11:14] by definition if they decide to to take [11:16] this role but for companies they can [11:19] play um the same for the same code base [11:23] they could be manufacturers and [11:25] stewards. How to identify the role you [11:28] are playing depends on your monetization [11:29] strategy and how you are um managing um [11:33] those two um separate uh projects or [11:37] products and yeah the line that um is [11:42] between uh the two things is really thin [11:45] but um is well defined uh by the [11:48] European Commission in the different uh [11:50] guidance documents that they are uh [11:53] preparing. So yeah, we should not have [11:56] in mind that tests are only open source [11:58] foundations. It's basically everyone [12:01] that is in charge of um of an open [12:04] source um project that wants to play the [12:08] role of a steward and um yeah can [12:11] implement it based on the rules that [12:13] have been defined for stewards. And [12:16] finally the last category is open source [12:18] maintainers which is basically hobist [12:21] whose projects are not in scope but um [12:24] they are widely uh adopted so they don't [12:27] have any direct obligations but they are [12:30] indirectly impacted by by the CRA. [12:34] So some specific challenges in terms of [12:37] uh cyber security uh what we have uh [12:40] covered so far it's basically what are [12:43] them uh the framework. Now there are a [12:46] specific challenges that affects the [12:48] first one is the viceogenity. Uh the [12:50] second one is full life cycle life cycle [12:53] management uh how to deal with the [12:56] supply chain complexity and how to [12:58] manage u the development and release of [13:01] of the different patches. So there are [13:04] specific uh problems on top of um new [13:07] legislative framework that uh should be [13:09] also addressed and well understood to [13:12] provide um yeah an effective uh [13:15] implementation of the of the CRA. So [13:19] this is basically the CR in a nutshell. [13:21] Of course, there are a lot of u um yeah [13:24] uh side topics that have not been [13:26] covered in the in the slides that are [13:29] important and I'm happy to take them uh [13:32] in the in the questions but um yeah for [13:36] now it's basically to understand what is [13:38] the high level objective what are the [13:41] roles that have been defined what are [13:42] the different categories that the CRA is [13:45] defining and the actors and what are the [13:48] means that we have to comply with what [13:50] the CRA is um is requesting. [13:53] The other topic is uh digital [13:55] sovereignty and for me this is something [13:59] completely different to the CRA. While [14:01] the CRA is super technical and it's [14:04] basically a list of requirements that [14:06] should be um implemented. Uh there would [14:09] be uh a standards that uh will help uh [14:13] everyone to understand how to comply [14:15] with uh those obligations. [14:18] digital sovereignity. Um the way I see [14:21] it is uh my degree of freedom with the [14:24] technology choices I make and that's [14:27] also important because [14:30] both things are happening in parallel. [14:32] Um but they have like different um [14:35] different approaches. One is more [14:38] technical, the other one is more related [14:41] to the choices you make when you are [14:43] start building um building products. And [14:47] well, I'm [14:49] not a big fan of um yeah [14:53] for for digital sovereignty in terms of [14:55] uh where things are developed but [14:58] actually what are the main elements that [15:00] will allow me um yeah to continue [15:03] development of an specific technology or [15:06] to change a specific component for [15:08] other. So it's how reliable are the [15:12] components that I'm uh using and how [15:15] much I or how free I am to um yeah keep [15:20] using it or the risk I'm exposed if uh [15:24] if I select an specific component uh [15:26] versus other. So yeah those uh both [15:30] things are um yeah the key components [15:33] for the next part of of the presentation [15:35] and the main thing is that we are living [15:37] in a growing regulated world and that's [15:40] something that uh I have discussed with [15:42] uh many people yeah the CRA looks scary [15:45] uh especially at the beginning the first [15:47] time you you face it but um I don't know [15:51] if the good or bad news is that u yeah [15:53] it's the first but there will be more so [15:56] the sooner we started [15:58] uh the sooner we get ready for this kind [16:00] of of a scenario and something that is [16:03] also important is the trans the [16:05] transformation cap capacity of open [16:07] source for the regulations and open [16:10] source has many many good things to [16:13] comply with um the things that the the [16:16] CRA for instance has uh is requesting [16:19] but uh we need also to understand what [16:21] are the benefits or the strengths what [16:24] are the risks and what are the elements [16:25] that have been already covered by um by [16:29] open source communities for a long time [16:32] that uh will help us uh to guide and [16:35] share with um yeah with the European [16:38] Commission in this case but with the [16:39] industry in general how compliance can [16:41] be made. So as part of the strengths um [16:46] yeah it's transparency collaboration and [16:48] innovation. Uh basically we are trying [16:50] to build through the regulations um more [16:52] cyber secure cyber resilient um space [16:56] and this can be easily um achieved if uh [17:00] things are transparent uh the [17:01] collaboration happen. Yeah. Um and yeah [17:06] the innovation one of the main drivers [17:08] for innovation is open collaboration. So [17:10] that that those are three elements that [17:12] um makes open source a strength in terms [17:14] of comply with um with regulations that [17:17] are trying to achieve uh cyber security. [17:20] But at the same time we have uh some [17:22] risks. Uh the first one is dependencies. [17:24] Uh yeah many products uh rely on [17:27] upstream open source libraries but um we [17:31] are just picking them because they feel [17:33] a functionality and we don't know what [17:35] is happening uh yeah behind that. We [17:38] don't know if the project is healthy or [17:41] not. If there are many people actively [17:44] supporting and maintaining it, we just [17:46] sometimes uh focus on the [17:48] functionalities and that's probably [17:50] something we need to change. The second [17:52] element is fragmentation. Uh especially [17:55] with project with open source projects [17:56] are forked is difficult to track. uh [17:59] when we go to vulnerabilities [18:01] whether my uh version is uh part of uh [18:05] has the the vulnerability already [18:07] covered or is vulnerable. So that that's [18:11] um uh one of the risks that uh we need [18:13] to to address and and understand when we [18:15] integrate open source components and we [18:18] need to be compliant with the with the [18:20] CRA. And the third element is probably [18:23] for me the most important is the [18:24] responsibility gap. um we cannot or [18:28] manufacturers cannot request open source [18:30] to work uh for them. It's uh actually [18:34] open source is uh trying to define their [18:36] own road maps and and create the [18:38] functionalities they think they are [18:40] important for um for them not trying to [18:44] field the needs of uh those who are [18:46] consuming those projects. So that [18:49] responsibility gap is also important to [18:52] um try to define a new way of uh [18:54] exchange or participate or get involved [18:57] in open source communities. The last [18:59] part is more related to uh how [19:03] secure supply chain can be managed. [19:05] That's something that um yeah opensource [19:08] have been doing uh for many many years. [19:10] So yeah, sbombs and vulnerability [19:13] tracking the CVS kind of things are [19:16] quite um uh well addressed by by the [19:19] open source community. So yeah, I think [19:21] that's [19:23] something that we can share with uh with [19:25] the manufacturer especially in those [19:26] industries that are not related or not [19:29] so close um to how those um areas work. [19:34] So uh in summary regulation impacts [19:38] implementation and decision making and [19:41] I'm trying to split those um two things [19:44] between the technical impact so new [19:46] features more documentation new [19:48] processes those those things that affect [19:51] directly uh to how the products are [19:53] developed and the other one are the [19:56] non-technical ones. So what's the level [19:58] of dependency when we select an specific [20:01] component? Who is the owner? Uh what is [20:04] the participation I'm going to have in [20:07] the in the development of the [20:09] components? I'm confus I'm um consuming [20:13] what's the impact if I uh select uh one [20:16] component versus other my liability if [20:19] I'm using uh a specific things. So it's [20:22] important to separate what are the [20:25] changes that we need to implement on the [20:26] technical side and how we are going to [20:28] assess when we are uh using or consuming [20:31] or contributing to opensource um [20:34] projects from the technical perspective [20:36] and what are the areas that we are going [20:38] to analyze from the nontechnical [20:39] perspective because they are going to [20:41] impact you as well and it's important [20:43] also to uh yeah have a clear view on on [20:48] all of them. So before speaking about [20:50] metrics um just a few obligations that [20:54] will help uh yeah to to go deeper into [20:56] the metric size and the first one is uh [20:59] obligation. So as I said at the [21:01] beginning products should be placed in [21:03] the market with no known [21:04] vulnerabilities. So that's an [21:07] obligation. So we need to um be sure [21:10] that the things that we are putting in [21:12] the market has gone through an [21:14] assessment to demonstrate that this is [21:16] happening. [21:18] The second uh part is product with with [21:20] vulnerabilities must report and fix [21:23] them. So how we are going to identify [21:25] that our product is affected by a [21:27] vulnerability because if we are not [21:29] aware or not being aware is not an [21:32] excuse. You should be um uh actively [21:36] monitoring the the health of your [21:38] products and uh for fixing them how you [21:41] are going to contribute to that because [21:42] you are obliged to fix uh [21:44] vulnerabilities if um a component or an [21:48] open source component that you are using [21:49] in your products uh has um a [21:52] vulnerability. [21:54] So understanding what are the things [21:56] that you can uh identify to um be more [22:01] more effective or more efficient uh with [22:04] uh these two topics is uh also important [22:06] something you need to check before uh [22:08] consuming a specific components and the [22:11] third element is uh product must be [22:13] protected during the third during its [22:15] entire uh life cycle. So it's important [22:19] to know uh whether uh the project is [22:22] something that is run by one party or [22:24] this is a communitydriven effort. So [22:27] there are different elements that should [22:29] be considered is again not the [22:31] functionality or not only the [22:32] functionality but all the different [22:35] risks that you are now exposed when you [22:38] need to comply with the specific [22:39] regulations [22:41] on the need size is how to maximize your [22:46] digital autonomy. If something is not [22:48] working, what I'm going to do if [22:49] something decides or someone uh decides [22:52] to change the license of an specific [22:54] component that can clearly um affect my [22:57] product, how can I react to that? So [23:01] yeah, there are obligations and and it's [23:03] again linked to what I said before about [23:05] the technical and not technical. But in [23:08] terms of um [23:11] yeah evaluation or a framework or or [23:14] creating a framework for evaluating uh [23:16] what are the things that you need to [23:18] consider? Um yeah uh you need to cover [23:22] uh both things those uh that are closer [23:25] to the um compliance to the technique to [23:28] the different regulations that are [23:31] usually uh technical as I said before [23:34] before but also if you want to create um [23:37] yeah a resilient product what are the [23:40] the elements that I need to consider to [23:43] maximize my digital autonomy. [23:46] So for the indicators to check I have [23:50] split uh in three categories. Um you are [23:55] more expert than me on uh the [23:58] indicators. Uh but uh I prefer to focus [24:01] on the categories and and why they are [24:04] important and of course we we can [24:06] discuss uh later about all the other [24:08] topics. So the first one is governance [24:10] and stewardship. um why it's important [24:13] to identify the steward of the [24:14] supporting organization because as we [24:16] said before we have now obligations on [24:19] reporting the vulnerabilities and fixing [24:21] them. So usually when projects or are [24:25] stewarded uh they have a cyber security [24:27] policy and they have ways that will [24:30] simplify the our work or the work of [24:33] manufacturers that are consuming um [24:36] those components if a vulnerability is [24:39] um identified. Also the public [24:42] governance and maintainership is [24:44] important in a sense that um yeah you [24:46] need to be sure on how decisions are [24:48] made. What are the risks you are exposed [24:51] and how uh this what are the number of [24:55] risks that you are exposed when when you [24:57] are selecting um an specific component [25:00] and the third um element is the number [25:04] of active maintainers and the continuity [25:06] signals. I'm using a project that is [25:09] barely maintained or this is a really [25:11] active community that is uh looking [25:14] forward to be consumed and uh to engage [25:17] with um with manufacturers. [25:20] So that that would be for me the first [25:22] category. The second one is a bit more [25:25] technical which is um more related to [25:28] the specific requirements that the CRA [25:30] is uh imposing and could be uh [25:33] vulnerability handling and transparency. [25:36] Yeah. The security policy is probably I [25:39] would say the most important one uh [25:42] considering what the CRA is requesting [25:44] because that should list what is the [25:46] approach towards um comply with [25:49] different regulation of how an specific [25:51] project will be working on on that but [25:55] um yeah and and this is something that [25:57] is trying to be covered by the by the [26:00] standards in in the CRA but it's also [26:03] important [26:04] um to know how the different open source [26:07] projects are going to uh deal with it [26:10] first because uh open source projects [26:12] are not obliged to follow the standards. [26:14] Um but you as manufacturer need to [26:17] demonstrate compliance. So those things [26:19] that are already done by projects um [26:22] don't need to be done by the by the [26:24] manufacturers and yeah in terms of risk [26:27] management uh your due diligence [26:30] processes and the number or the effort [26:33] that you should put um on creating your [26:36] product before launching them to the [26:37] market. It's important to to analyze all [26:39] these uh elements. [26:41] So um yeah part of the security policy [26:44] is usually the clear reporting channel [26:46] how uh vulnerabilities are reported and [26:49] how they are communicating [26:51] the uh development of the fixes the [26:54] coordinated vulnerability disclosure [26:56] process uh the track record of um [26:59] advisories fixes uh public security [27:02] advisories or chain locks and the use of [27:06] standard formats. So uh yeah that that's [27:09] super important because it's not only [27:12] about uh what the project is doing uh [27:15] for you but also how easy will be for [27:18] you also to demonstrate that you comply [27:20] with the CRA and in case there are any [27:23] problem how you can cooperate with the [27:26] with the project to be sure that um yeah [27:30] and then then the amount of effort that [27:32] you should uh put to keep compliant with [27:34] the with the regulation is not well it's [27:38] the lowest possible to to to be [27:40] completely or to simplify it um a lot. [27:43] Um again if you have a project that uh [27:46] has a good list of uh who are using this [27:49] component and vulnerabilities found you [27:52] can work together with all the other um [27:54] entities that are using that that [27:56] component. If you don't have that, you [28:00] need to demonstrate that you have start [28:01] working on yourself or by yourself on [28:04] developing fixes for uh vulnerabilities. [28:07] So yeah, then the number of options and [28:09] and the list of things that uh are [28:11] important now especially when when [28:14] focusing on the on supporting the full [28:16] uh life cycle uh for those products, [28:20] yeah, are completely different than when [28:22] we thought on how to build the product [28:25] until it is released. So yeah those [28:28] those elements are uh super super um [28:31] important right now. And the third [28:34] category is um yeah supply chain hygiene [28:38] uh secure development and operational [28:40] security. And here I can start with an [28:42] infinite list. Um yeah the dependencies [28:45] the bombs uh code reviews release [28:49] controls. I mean, yeah, I put just a few [28:52] here, but um probably these are the the [28:55] things that are more operational to the [28:57] uh to the projects, but gives a clear [29:00] indication of uh if again if something [29:03] happens, which is uh the case um how [29:08] much I can trust the project I'm using. [29:11] And this is an important um element to [29:14] yeah to decide uh well between two [29:19] components which is the one that uh will [29:21] work better for my my needs. [29:24] So those are the three categories. There [29:26] are yeah a lot of things that I have not [29:29] covered today but um there will be uh or [29:32] there are super important. The role of a [29:35] stewards. Uh well, I have a link to the [29:38] white paper that we have created in in [29:40] OC. Who can be a steward? What are the [29:43] responsibilities? How they interact with [29:46] uh with the different uh institutions [29:48] that uh uh they need to do voluntary uh [29:54] security at stations. That's probably [29:56] the key element to assure um a [29:59] sustainable open source ecosystem [30:00] because the attestations will be like [30:04] documents or assets that will [30:06] demonstrate uh the posture of the pro of [30:08] the projects towards the [30:12] uh the compliance with the different [30:13] regulations. And that's something that [30:15] is supposed to be um purchased somehow [30:20] uh could be uh by contributing to the to [30:24] the project or basically pay for for [30:27] that to demonstrate that the pro the [30:28] project you are consuming is well [30:30] aligned with the CRA so that the [30:32] obligations uh in the due diligence [30:34] process will uh be much lower if you can [30:38] count on on attestation. So just two [30:41] super big topics that uh will well some [30:45] of them will have specific sessions [30:47] during force them for a few hours. So [30:50] those are important elements that I'm [30:52] not covering but um yeah you should take [30:55] a look and I'm I'm including here um a [30:58] couple of links that can help to to [31:00] start and yeah that's also an important [31:03] thing uh the work just started it's not [31:07] uh finished is not even close to be [31:09] finished and yeah we are using the CRA [31:13] as um a way of identifying also the [31:16] challenges that um opensource community [31:19] will will face and we have identified um [31:23] just for naming a few uh clarity on the [31:26] text. Uh the text is not written by [31:29] people which uh who are experts on open [31:32] source and try to understand I mean we [31:36] started in in the open regulatory [31:38] compliance the FAQ and it took less than [31:41] a week to be on 100 questions. So uh 100 [31:48] active conversations trying to identify [31:50] uh what the text is referring to. So [31:54] that that was one of the challenges and [31:56] yeah my my prediction is that um this [32:00] will happen every time a new regulation [32:02] is um is launched because the ones that [32:05] are writing the laws are not um [32:08] technical experts and there are a lot of [32:10] great zones. So it's important to define [32:13] how we can as as a community um yeah [32:17] identify what um what they want to say [32:20] and how we can propose um a solution for [32:23] them. [32:24] Second thing is the interfacing with the [32:26] regulators and that that's super [32:28] important because um if you just [32:31] identify the gray songs but you are not [32:32] reporting them back to uh the regulators [32:36] yeah we are not making a a huge um [32:40] advance. So it's important to define how [32:43] to effectively communicate with the [32:45] regulatory bodies as well as contribute [32:47] to the standards. uh as I said at the [32:49] beginning, open source has not been yet [32:53] very much involved in the [32:54] standardization. Now I'm super happy to [32:57] see how many of uh um the colleagues of [33:01] the open source community are actively [33:03] contributing both to the horizontal and [33:05] vertical um standards. [33:09] Still there is a lot of uh things that [33:11] needs to be updated because standards [33:14] are quite old [33:16] organizations and they are not um used [33:19] to work in or the way open source work [33:21] and standards are [33:23] not the same and and that that's a [33:26] challenge and finally raise awareness um [33:29] that that's uh [33:32] yeah the last uh point I I I I [33:36] included in the slide but it's probably [33:38] one of the most important important. Uh [33:40] one of the things that we are seeing is [33:42] that um people is not aware of what is [33:45] coming. So they cannot contribute back [33:47] to uh to the the proposal or to propose [33:51] solutions to to it. So yeah, basically [33:55] this is what we are trying to achieve [33:57] with the open regulatory compliance. I'm [33:58] not going to make a sales speech of the [34:01] working group but just to mention it. Um [34:04] yeah basically uh what we are trying to [34:07] to do is f five things uh to create a [34:11] neutral forum uh one of the things is um [34:14] yeah regulations affects too many people [34:16] and too many stakeholders and how to [34:18] create some some space that uh will [34:20] allow them to to work together work on [34:24] regulatory awareness and ecosystem [34:26] impact uh best practices and sustainable [34:29] solutions we don't need to reinvent the [34:31] wheel and as I said at the [34:34] uh with the ESBON case um we have [34:36] already solved some of the challenges [34:38] that the regulation are um are putting. [34:41] So the the role we have is also share [34:44] those things with um with uh with the [34:46] regulators and and and the and the [34:49] industry. Yeah. Education and [34:51] implementation and institutional [34:52] collaboration. Um yeah we are a lot of [34:55] people already working on on it but um [34:59] yeah probably the most important thing [35:01] and I want to close before the [35:04] conclusions with that is yeah don't wait [35:08] uh join existing initiatives of course [35:10] if you join uh or the open regulatory [35:13] compliance I will be super happy and you [35:15] will be welcomed by a great group of [35:17] people but there are other initiatives [35:19] also working on on on this domain and [35:22] it's important to act as a group because [35:25] this is where um the strength of the [35:27] open source community will come. So join [35:31] some of the initiatives that are working [35:32] on on this topic. And yeah to close [35:37] the first [35:39] thing is that the regulatory obligations [35:41] make more important than ever [35:43] understanding the dynamics of open [35:44] source projects. um because as I [35:47] explained uh that they have multiple [35:49] implications and uh the decisions are um [35:53] yeah are going to impact you not only [35:57] could make you liable uh let's put it [35:59] like that the second is being part of [36:02] the project is the easiest way uh to [36:04] assume compliance resilience and [36:06] sovereigntity and that that's something [36:08] I want to highlight uh usually is not to [36:11] to yeah consume and and support [36:14] communities but also being part of uh of [36:17] it. So that that's super uh or a key [36:21] element in terms of facilitating your uh [36:23] compliance journey. The third um element [36:26] is that there are multiple roles you can [36:29] play and um it's important to decide [36:32] based on the risk you are exposed to. Of [36:34] course, you should not put uh 10 [36:36] developers in each of the projects you [36:38] are consuming, but um uh define what are [36:42] the key ones that uh you need to get [36:44] involved and and the level of [36:45] involvement that you have based on yeah [36:48] your exposure to to that and keep [36:51] contributing and developing open source. [36:53] Uh there are a lot of uh questions about [36:56] uh yeah I should shut down my projects. [36:59] No, that's super clear. uh the object of [37:02] the regulation is building a sustainable [37:04] ecosystem uh both in terms of uh [37:06] security but also in terms of um of [37:10] economic sustainability. So yeah that's [37:14] my presentation. Um now I'm open to get [37:19] questions. [37:22] >> Okay, thank you so much. We have eight [37:24] minutes for for questions since we end [37:27] this meeting at at 10 till the hour. Um [37:29] just a note that a few of us have been [37:31] dropping notes in the uh meeting doc [37:34] with some links to chaos metrics models [37:38] guides that apply to uh the indicators [37:41] that Juan mentioned along with some [37:43] links to some of the open regulatory [37:45] compliance working group stuff. Um so [37:48] who has who has questions? [37:58] Hi Don and hi Juan. Thank you so much [38:01] for that presentation. It was really [38:02] excellent and I need to dig into the [38:05] white paper. One of the questions I have [38:08] in terms of encouraging stewardship [38:14] is the value prop to the steward [38:18] why they want to take on that [38:19] responsibility. [38:21] Do you have any thoughts on that or is [38:23] there work that has already been done in [38:25] OC around that specific [38:30] use case? [38:31] >> Yeah. Mhm. Um [38:35] the there are two ways of approaching [38:38] the stewardship. Um and um I'm going to [38:41] skip completely one which is for open [38:44] source foundations because there is no [38:48] risk of uh being accused of monetizing [38:50] things. So um for open source is quite [38:54] uh simple. I think it's important for [38:56] manufacturers [38:58] and that's probably one of the [39:02] biggest decisions that manufacturers [39:04] should make with the open source [39:05] projects they are um actively [39:08] maintaining because if you are a steward [39:10] the level of um obligations that you [39:13] have are lower. Uh the liabilities uh [39:16] basically you don't have any liability. [39:18] You just need to demonstrate that you [39:19] have your cyber security policy in [39:21] place. you are not monetizing any um [39:25] service um related to that specific [39:30] component or project and yeah I I think [39:34] that um [39:38] it's a matter and depends a bit on on uh [39:41] what is the the country that you are [39:43] operating because the biggest risk is [39:45] that um a market surveillan authority is [39:49] telling that you are monetizing um uh an [39:52] open source project and they force you [39:55] to become a manufacturer instead of [39:57] steward. That that's the because that [40:01] that change implies that uh basically [40:03] you have to do everything and [40:05] demonstrate that you are compliance in a [40:07] completely different way. [40:10] But besides that and and that's um well [40:15] in terms of the questions that we are um [40:18] sharing with the European Commission for [40:19] the guidance that that's probably the [40:21] most important uh or the biggest group [40:24] of questions that we are going or we are [40:26] sharing already is related to that. Um [40:29] and we have asked to provide uh specific [40:32] examples [40:34] because yeah we have a lot of companies [40:37] uh in the working group that are uh [40:39] super concerned about uh this and they [40:41] don't want to get any any issue. I think [40:44] that the main incentive um yeah again is [40:47] is try to demonstrate that you are [40:49] creating a good uh community around of [40:52] um of an specific project. reduce uh the [40:55] number of obligations by uh creating [40:57] this community or the number of [40:59] activities by creating those those [41:01] community not obligations [41:03] and [41:05] yeah that will be like the main um the [41:08] main the main element but this is [41:11] something that is still [41:14] I would say we need more examples from [41:16] the European Commission uh basically to [41:19] make sure that um uh manufacturers that [41:21] decide to become stewards of a specific [41:23] projects uh are not going to face any uh [41:27] problem when when it comes to yeah a [41:31] request from the specific market [41:32] surveillance authority. [41:35] I'm wondering if there's also a carrot [41:38] that is [41:41] being offered within [41:44] the European Commission that if there is [41:48] a steward for a specific project that [41:51] that would allow a subsequent [41:53] manufacturer or consumer of that project [41:56] to be able to sign off on certain [42:00] obligations or be able to say, "Hey, [42:03] this box is already checked. [42:05] For instance, there's a security policy [42:07] already associated with the project. But [42:10] since there's no [42:13] stick associated with the steward, [42:16] there's no real metric to say, hey, the [42:18] steward has to reach this certain level [42:20] of security compliance or if if they [42:24] fail to do so, there's nothing that [42:27] sticks back to them. So I I don't know [42:30] if it really does come to fruition as [42:33] being something that a non-steward or a [42:36] consumer could rely on. [42:39] >> Well, I the steward needs to demonstrate [42:41] that the security policy that they are [42:44] implementing on the projects they are [42:45] stewarding um complies with the or is [42:49] aligned with the with the regulation. So [42:51] that that's an important point. is not [42:53] uh yeah the the the the security or the [42:58] cyber security policy should demonstrate [43:01] should provide enough means um for the [43:04] ones that are consuming those projects [43:06] uh to be sure that u yeah this is [43:09] something safe I I can rely on the other [43:13] thing is at the stations uh we haven't [43:15] gone through at the stations but the [43:17] attestations is should or the commission [43:19] has defined it as um as an economic [43:22] mechanism ISM uh to make uh the projects [43:26] more sustainable. So they can through [43:28] the stationation or the money they get [43:30] through at the stations uh pay uh for [43:33] implementing the security features that [43:35] um that the projects will require. So [43:39] there are multiple things. is not only [43:41] uh one element that will make uh yeah [43:45] decide whether I should be a steward or [43:47] not but um to consider what is the whole [43:50] thing and what is my level of exposure [43:53] to an specific uh project if it's [43:56] something that is not core for my [43:57] business probably I can basically [44:00] steward it uh steward it and then open [44:04] uh open source it and yeah try to create [44:07] a community around it if it's something [44:09] that yeah is not critical and probably [44:11] we have a diverse community. This is [44:13] something I can donate and I reduce my [44:15] exposure to any potential liability that [44:18] um market super authorities because [44:22] that's the next uh the next challenge [44:24] that we are facing in OC and it's one of [44:27] the big objectives for this year is [44:28] start engaging with the national [44:30] countries. We have done I think uh or [44:33] the open source community has done a [44:34] great job with um with the European [44:37] Commission on educating them and make [44:39] them understand how open source work. [44:42] Now we need to do the same for all the [44:43] other countries. Uh because the first [44:45] text that we have read from uh yeah [44:48] different countries are not very I mean [44:51] it is the same feeling we had when we [44:53] first uh read the drafts of the CRA. So [44:56] it's the same level of misconceptions [44:59] and yeah that that that's that's [45:01] important and if there is no extension [45:05] on the deadline for um the imple the um [45:09] entry force of the of the CRA I'm sure [45:13] that there will be countries that um [45:15] will be regulating uh yeah the the IT [45:19] industry without a clear understanding [45:20] of the of the open source world and [45:23] that's [45:25] from my point of you a big risk. [45:30] >> Okay, we are about out of time. We could [45:33] we could squeeze in one more quick [45:34] question if somebody has a a quick one. [45:42] Okay. Um just two quick reminders. Uh [45:45] Chaoscon EU is January 29th. That is the [45:50] Thursday right before Fazda. We are in [45:52] the heart of Brussels uh near the [45:55] central train station. It's not too late [45:57] to register. So we'd love to have more [45:58] people at at Chaos Con EU. So if you're [46:01] going to be around, feel free to [46:02] register. And also just a quick note [46:05] that the Open Source Summit North [46:06] America opened their CFP. So it closes [46:09] on February 8th, so people don't have a [46:12] ton of time. The event itself is in May [46:14] in Minneapolis. Uh so if people are [46:16] interested in submitting a talk for that [46:18] uh the CFP is open [46:21] and with that uh thank you so much Juan [46:25] for coming and spending time for with us [46:26] and thank you everybody for for coming. [46:29] This was a really I think a really [46:30] interesting meeting. So I hope to see uh [46:33] more of you in some of these meetings [46:34] every other every other week same time [46:37] same place. Thanks everybody. [46:40] >> Thank you. All right. Bye [46:42] >> bye.  📄 **Full text:** ![[Full Document Contents/Articles/CHAOSS OSPO Working Group, January 8, 2026.md|CHAOSS OSPO Working Group, January 8, 2026 by YouTube]] ## Highlights - CRA is all about protecting European consumers and businesses. This is the thing that all of us should have in mind. And when they started to build the CRA, it was because um they did um a research and they found in 2021 that um cyber crime has an impact of 5.5 trillion euros uh yearly. ([View Highlight](https://read.readwise.io/read/01kp8q8y65bk9zk1vfmjsadevm)) - targeting is manufacturer and retailers. So it's not the open source projects. It's not the open source community. It's not developers. ([View Highlight](https://read.readwise.io/read/01kp8q9thr292jd1yhv1zxkzra)) - them responsible for every single element in the products they are placing in the market. That's also a significant change compared to what happened before. Also, they are responsible through the um and the whole product life cycle. ([View Highlight](https://read.readwise.io/read/01kp8qbhbnkte41s77hmpgg8vq)) - new standards that um were are completely new and that is super challenging because we are um addressing a new regulation. We are speaking about new economic actors. We need to involve new people in the development of the standards that usually are not contributing to them and we need to make the people who is um traditionally contributing to a standards to understand how open source work. ([View Highlight](https://read.readwise.io/read/01kp8qd1fb3jk2w555tf5p96n6)) - stewards and they are actually uh co-hosting foundations or for profits that can be um stewards too if they are not monetizing the pro the the project. ([View Highlight](https://read.readwise.io/read/01kp8qe487mtheshfnp5cy71s5)) - play um the same for the same code base they could be manufacturers and stewards. How to identify the role you are playing depends on your monetization strategy and how you are um managing um those two um separate uh projects or products and yeah the line that um is between uh the two things is really thin ([View Highlight](https://read.readwise.io/read/01kp8qf0xbhgke7de5j0vqt9nc)) - the CRA looks scary uh especially at the beginning the first time you you face it but um I don't know if the good or bad news is that u yeah it's the first but there will be more so the sooner we started uh the sooner we get ready for this kind ([View Highlight](https://read.readwise.io/read/01kp8qgar6k5dtczass15n164q)) - responsibility gap. um we cannot or manufacturers cannot request open source to work uh for them. It's uh actually open source is uh trying to define their own road maps and and create the functionalities they think they are important for um for them not trying to field the needs of uh those who are consuming those projects. ([View Highlight](https://read.readwise.io/read/01kp8qfffe60bm46s5jrdqxcec)) - the attestations will be like documents or assets that will demonstrate uh the posture of the pro of the projects towards the uh the compliance with the different regulations. And that's something that is supposed to be um purchased somehow ([View Highlight](https://read.readwise.io/read/01kp8qjkzkhaf3zkbyjj76hxnn)) - it's important to act as a group because this is where um the strength of the open source community will come. ([View Highlight](https://read.readwise.io/read/01kp8qmb6wvazq6fz30m6kqakp)) - the project is the easiest way uh to assume compliance resilience and sovereigntity and that that's something I want to highlight uh usually is not to to yeah consume and and support communities but also being part of uh of it. So that that's super uh or a key element in terms of facilitating your uh compliance journey. ([View Highlight](https://read.readwise.io/read/01kp8qhb80yeb7my3yvt5fqadg)) - I should shut down my projects. No, that's super clear. uh the object of the regulation is building a sustainable ecosystem uh both in terms of uh security but also in terms of um of economic sustainability. ([View Highlight](https://read.readwise.io/read/01kp8qhny8m0mez39rmgk0r11h))