Open Resource Discovery  ## Metadata - Author: [[The Open Source Way]] - Full Title: Open Resource Discovery - Category: #podcasts - URL: https://share.snipd.com/episode/b91ddf1a-d365-4a03-bf4c-69e17c12695b ## Document Notes ## Highlights - **CRA Regulates Cybersecurity Across Europe** - The Cyber Resilience Act (CRA) is the first EU-wide regulation for cybersecurity that affects all digital product manufacturers and open source communities. - It aims to reduce vulnerabilities, maintain security through product lifecycles, and empower consumers with informed decisions. Transcript: Speaker 3 Yeah, sure. Speaker 2 So, the Cyber Resilience Act CRA establishes essential cyber security requirements that all businesses and open source communities that operate in Europe will have to implement. It's the first EU-wide cyber security regulation, and it explicitly defines separate roles for manufacturers and for open source software stewards, meaning foundations like us. And if you think about that, if we change this to playing field for collaborative development of software and reshapes the relationship between the stewards or foundations and the Companies that are participating in development and later using the software, the CRA has three policy goals. Of course, to reduce vulnerabilities in digital products, meaning hardware and software, that's important here, to ensure cyber security is maintained throughout the product's Life cycle and to enable users, consumers, to make informed decisions when they select and operate devices. It's a horizontal regulation, meaning it affects everybody who basically does business in Europe. It doesn't matter if the company sits in Europe or if the open source community sits in Europe. If your products are available in Europe, then it's relevant to you. The BB-1 last point here is important that do you really intend to play an internationally leading role with this regulation, meaning the regulation is not just meant to affect how People operate in Europe but really we want to export cybersecurity practices. I think this indicates why the CRA is so important for essentially everybody who contributes to digital products. All right. Speaker 1 Yeah, I agree with everything Mirko said, but just want to re-emphasize one point, which is it's not whether you are a European company or open source community. If you are making software or a cyber physical device available in the European single market, then this applies to you. Speaker 3 All right. So it's in that way similar to any trades and goods regulation for foods or whatever that are imported into the EU or data protection acts and whatsoever, right? Exactly. Speaker 2 I think it kind of makes digital products more similar to physical products, as you said, like food and other physical products. There's a change for the software ecosystem because then until now, software has been excluded from regulation regularly differently from physical goods. And I think it's just this term digital products in this year, where you already indicates that it's kind of all encompassing. Everything that has some sort of processor in it and software on it is a digital product. Speaker 3 And was that triggered by current geopolitical things happening or as I've been brought on its way way earlier? Speaker 1 I think it started earlier. So the original impetus, as I understand it, is we can all remember there's a camera with exactly which attacker was, but sort of a very widely known DDoS attack that took advantage of Webcams. And that was one of the epithetes. And the original scope of the CRA when they first started was really around cyber physical devices, but a particular consumer IoT devices. And I think, through a large degree, you can really think of this as the initial impetus is we need to protect European consumers from shoddy, cyber physical goods, particularly with The miracle mentioned, the lifecycle aspect of this. And that's very important. It's not just about shipping a device which is secure at the moment you ship it, it's keeping that device secure for the life of the device. So that was the original impetus. And honestly, if it had stayed that way, the CRA would not have been that big of a deal. But then while, again, this is sort of like second-hand, but as I understand it, while a miracle may be no correct among any of my mistakes, but while they were drafting it, log for shell Happens. There was a recognition that, oh my gosh, you know, this cybersecurity issue goes beyond just cyber physical devices, we need to actually think about including pure software within The scope of this regulation. And it was the extension of the original remit of the CRA to include pure software, which I think really caught the attention of a lot of people because that's a game changer. Like the regulation of electronic devices has been around since as long as we had electronic devices. I mean, that's nothing new. But the regulation of pure software is something which is very new. And I think that's one of the things to really keep in mind is what the CRA is doing is for the first time in history, regulating the software industry in its entirety. Gold, pretty. And so the impacts of that are very, very far reaching. We're here to talk about open source. We're part of the larger software in technology industry. That's why we're here and how it impacts the open source communities that help support the greater software industry. Speaker 3 Yep, I was just going to turn it to that and remind everyone that this is not a device or an overall software podcast, but an open source podcast. So the CRA is that especially relevant for open source software or is it just also relevant for open source software, Mike? Speaker 1 I would say at this point, as it has come to pass, the final version of the CRA, I would say it's more the latter. It's like open source is included. The original draft of the CRA, I would describe it as an existential threat to not only open source, but honestly to ([Time 0:02:32](https://share.snipd.com/snip/b4bb4052-0df3-4ef2-87c0-cb29afd77886)) - **Software Included in CRA Scope** - Including pure software within the CRA was a significant shift triggered by major cybersecurity events like Log4Shell. - This extends regulation beyond hardware to encompass the entire software industry for the first time. Transcript: Speaker 1 I think it started earlier. So the original impetus, as I understand it, is we can all remember there's a camera with exactly which attacker was, but sort of a very widely known DDoS attack that took advantage of Webcams. And that was one of the epithetes. And the original scope of the CRA when they first started was really around cyber physical devices, but a particular consumer IoT devices. And I think, through a large degree, you can really think of this as the initial impetus is we need to protect European consumers from shoddy, cyber physical goods, particularly with The miracle mentioned, the lifecycle aspect of this. And that's very important. It's not just about shipping a device which is secure at the moment you ship it, it's keeping that device secure for the life of the device. So that was the original impetus. And honestly, if it had stayed that way, the CRA would not have been that big of a deal. But then while, again, this is sort of like second-hand, but as I understand it, while a miracle may be no correct among any of my mistakes, but while they were drafting it, log for shell Happens. There was a recognition that, oh my gosh, you know, this cybersecurity issue goes beyond just cyber physical devices, we need to actually think about including pure software within The scope of this regulation. And it was the extension of the original remit of the CRA to include pure software, which I think really caught the attention of a lot of people because that's a game changer. Like the regulation of electronic devices has been around since as long as we had electronic devices. I mean, that's nothing new. But the regulation of pure software is something which is very new. And I think that's one of the things to really keep in mind is what the CRA is doing is for the first time in history, regulating the software industry in its entirety. ([Time 0:05:28](https://share.snipd.com/snip/75194ca1-ac89-46ee-9d1f-41d09657be74)) - **CRA Encourages Upstream Collaboration** - CRA creates an economic incentive for companies to support and collaborate with open source projects. - This may improve sustainability of open source communities through shared security responsibilities. Transcript: Speaker 3 Absolutely correct. Speaker 1 Thinking forward, I think that there's some, this is, I mentioned opportunities. You know, one of the things that is, I think a potential opportunity here is today corporations can embed open source software in their products without ever really paying any attention Whatsoever to the health of the upstream project that they are using. And the CRA is going to change that in that they are now going to have some responsibilities that for the lifetime of the product that they're going to have to be able to, you know, take That open source software and make sure that is securely used within the context of their product. And when you multiply that across, you know, when you have an open source project that's potentially used by tens of companies and hundreds of products or sometimes even, you know, Hundreds of companies and thousands of products, it's going to make a lot more economic sense for these companies to collaborate on the security work in the upstream project as opposed To every single company replicating all of this effort themselves in their use of that open source project. I think the opportunities that stems from this regulation is that there is a new economic nudge for corporations to subtly change their behavior and their relationship with upstream Open source projects. Everybody's been involved in open source for any length of time knows that we have a sustainability problem with many open source projects. And I'm not saying this is the solution, but I'm saying that there is a new, like I said, economic nudge that could have beneficial implications for the sustainability of open source Projects down the road that didn't exist before this regulation. So that's going to be a really interesting thing to see how it plays out over the next, you know, decade. It's this is not going to happen. This is not going to transform overnight. But I do think that it's going to subtly change behavior in ways that we don't quite know yet, but I think at least at first glance seemed to have positive ([Time 0:15:18](https://share.snipd.com/snip/cd54be33-3997-449d-a90c-f9e039bd2429)) - **Manage Open Source Responsibly** - Corporations must manage their use of open source actively, ensuring sustainable development and vulnerability management. - Integrate open source responsibly to comply with regulations and maintain product security. Transcript: Speaker 1 Lifetime of the product that they're going to have to be able to, you know, take that open source software and make sure that is securely used within the context of their product. And when you multiply that across, you know, when you have an open source project that's potentially used by tens of companies and hundreds of products or sometimes even, you know, Hundreds of companies and thousands of products, it's going to make a lot more economic sense for these companies to collaborate on the security work in the upstream project as opposed To every single company replicating all of this effort themselves in their use of that open source project. I think the opportunities that stems from this regulation is that there is a new economic nudge for corporations to subtly change their behavior and their relationship with upstream Open source projects. Everybody's been involved in open source for any length of time knows that we have a sustainability problem with many open source projects. And I'm not saying this is the solution, but I'm saying that there is a new, like I said, economic nudge that could have beneficial implications for the sustainability of open source Projects down the road that didn't exist before this regulation. So that's going to be a really interesting thing to see how it plays out over the next, you know, decade. It's this is not going to happen. This is not going to transform overnight. But I do think that it's going to subtly change behavior in ways that we don't quite know yet, but I think at least at first glance seemed to have positive implications. Speaker 4 Okay. Yeah, but I would absolutely agree here. So I'm also really looking forward to these changes. And honestly, I hope that open source foundations can and will play a larger role in comparison to previous years. Of course, they have already played a big role in the open source ecosystem in the open source communities, but I completely agree here. And when it comes to corporations taking the just open source components or projects and integrating them, I have to add a little bit to that, at least for SAP. I can only speak for SAP, but individually for us. We've already had quite some, let's say, similar internal regulations when it comes to consuming open source projects with respect to managing vulnerabilities with respect to reporting And other things. So we tell our product owners and the responsible colleagues, if you take something from somewhere, it doesn't even necessarily need to be open source. But especially for open source, the time you are taking that and integrating into a product and shipping it, you assume responsibility over the whole product. And that, of course, also includes the open source components. So you need to be sure that you, let's say, take the right component that is in sustainable development, that you potentially also have some knowledge that you ideally also can contribute To. If something happens, to ensure ([Time 0:15:51](https://share.snipd.com/snip/c2f6024e-2282-4ffb-901f-9c29fcf7882f)) - **Prepare for New Security Standards** - The CRA implementation requires new European harmonized standards for secure software development. - Start preparing now by aligning processes with these anticipated standards and training auditors. Transcript: Speaker 1 Well, that's actually one of the challenges is because in order to fully implement the CRA, we are going to need some new European harmonized standards for secure software development. And there's really sort of two aspects to security that the CRA touches upon that I think you kind of have to separate in your mind. And one is secure by design, so how to write secure software. And the other one is supply chain security. Everything from software build materials to making sure that you know everything that is all the component pieces that are going into your own. And so in the end, if you are a manufacturer, replacing a product that contains software on the European market once the CRA is in full effect, you're going to have to fix a CE mark to your Product. And in order to put that CE mark on your product, you're going to have to conform to the requirements of the CRA. Now typically the way that's done in other economic sector, industrial sectors is that there is a harmonized standard that if you conform to that standard, then you are given a presumption Of conformance with the regulation. Right now, these standards don't exist. And when it comes to standards development, three years goes to the cost of the system. Right now, these standards don't exist. And when it comes to standards development, three years goes by in the blink of an eye. Speaker 2 So that is up. Speaker 1 And in addition to creating these standards, then companies have to put in the practices to follow those standards. In addition for important products with digital elements, which are described in the annexes of the CRA, there is going to be a requirement to use an external auditor from a notifying Body in order to get the authorization to affix the CE mark. So over the next three years, we have to develop a bunch of standards. We have to implement a bunch of standards and we have to train a whole pile of auditors in order to allow products to continue to ship in the European Union. And like I said before, those three years are going to go by in the blink of an eye. And on top of all that, I think, and I'm sure Mirko of Reasoning, from our perspective, a lot of these standards bodies, historical standards bodies, don't have a long tradition in software And particularly don't have a long tradition of history with open source development practices. And so making sure that the way that we do things in open source are properly reflected in these standards is a concern and something that we're going to be keeping an eye on. So I think from a certain perspective, we can claim, I think, justifiably that we did a good job in having the regulation amended. But now there's a thousand implementation details, any which could potentially cause pretty significant issues down the road. So there's going to be a lot of time and investments spent by our respective organizations in making sure that open source software developers are ([Time 0:22:52](https://share.snipd.com/snip/463ad31b-03d4-4603-ba31-981e64b4bad0))