Free as in Freedom: How OEMs Can Navigate EU Cybersecurity Rules Whilst Using Open Source

Pierre: Sure. So thanks a lot for the invitation. So I'm Pierre Gal. I'm working in embedded system and software for embedded system ecosystem for now 20 years. And today, as you introduced myself, I'm developing the Embedded Kit, a brand of kits that aims to deliver the off the shelf product ready to use to help our customer to go faster with higher quality and with higher cybersecurity for developing their equipment.

Ruth: Great. Michael?

Michael: I'm Michael. I'm responsible for Avnet Silica's Software and Services Group in EMEA. So what we do is we provide training, consulting, engineering services to our customers, and we are also connecting our customers with our engineering partners, such as, for example, Witekio. And the link between the software and the services is quite important because we work with customers on all system level engineering topics. So starting with security, what we are talking today up to vision. We create proof of concepts, demonstrators, but we also talk about stuff like, for example, creating long-term maintenance concepts for our customers, which is quite important. In terms of the CRA touches topics such as total cost of ownership. Usually when you cut down a component costs you look just at licence costs. It's not the cheapest solution in terms of total cost of engineering.

Ruth: Mm-hmm. Terrific. I'm sure many of our listeners must have come across a term CRA Cyber Resilience Act by this point. And we also had an episode last year, which was quite popular. I will link it again in the show notes. Maybe we start with a timeline. When do the different CRA obligations actually kick in? I guess they have kicked in by now.

Pierre: Yeah, absolutely. I can start to give some hints about that. So maybe the most two important dates that are coming is September, 2026, so it's coming in few months now it's about vulnerability reporting, so, mm-hmm. All equipment manufacturers will have to start managing the vulnerabilities and being able to report the state of vulnerability of the equipment that they have commercialised. The second important date will be December, 2027, where all the entire CRA regulation will have to be applied for the entire equipment manufacturers. So that's the two most important dates. Everybody is now waiting for the harmonised standards because the CRA is mainly law explaining the general rules, but everybody is waiting now for how you can concretely apply for this law with this harmonised standard that should come in the coming months. We are always waiting for more information. So, mm-hmm. That's the main dates we are managing today.

Ruth: Okay. And Michael, you said you work together with customers. Based on what you are hearing, what are their biggest challenges right now with this timeline?

Michael: Well, what Pierre mentioned, what right now really everyone is waiting for in terms of just the CRA is the harmonised standards. So 30th of August, we have a promise of the first general principles. Then we are moving to the third of October and this year waiting for the vertical standards, which for the first time will contain specific information for certain types of products, how to implement the CRA. But I think there are other timelines which are also interesting, in which a lot of our customers don't really have on the record as we expect them to. So when you're looking, for example, I mean, CRA is just one, one part, one puzzle piece in the complete EU security regulation scheme. So there are other acts which are somehow interlinked with the CRA on a more technical level, but there's also, for example, the Product Liability Directive upcoming, which has quite interesting concepts that you need to look at in conjunction with the CRA itself. Mm-hmm. So, for example, the concept of continuous control, which is quite interesting because if a manufacturer keeps products under their control, under the new Product Liability Directive, for example, by allowing remote updates mm-hmm. You have the issue that they remain responsible for these products and when you're thinking about CRA, which mandates stuff like remote updates, you automatically have that link and that implies that every product that falls under the CRA also means that manufacturers are continuously responsible under the Product Liability Directive for these products.

Ruth: Mm-hmm.

Michael: And at the same time, a product which is defective in terms of cybersecurity is defective in terms of the PLD as well. So this is quite interesting and this is quite important because it's causing challenges that probably nobody really has on the radar. Mm-hmm. So, coming back to your question about the customer challenges, I mean, I think the most evident challenge that customers right now have with the CRA is that it contains about one and a half pages of technical requirements, and the rest is legislation.

Ruth: Okay.

Michael: So what you really have to do is right now, while the harmonised standards, the vertical, the horizontal definitions are missing, is to somehow use these one and a half pages as an engineer to come up with technical requirements. What you can do. And mm-hmm. In the time while they're waiting for that one. In terms of preparing for the CRA, and the big answer to that is basically doing a risk assessment and deriving the requirements for your own products.

Ruth: Mm-hmm.

Michael: That's something that when you're working in security on a formal way, or when you have kind of a legal training, this is common. You take a look, you discuss, you derive the requirements. As an engineer, it's quite tough. We are used to specifications. We implement the specifications. If you follow the specifications, we are fine. But the CRA isn't a specification, it's a legislation. And that's, I think the most, the biggest challenge that our customers right now have.

Ruth: Mm-hmm. And I have sometimes come across when in technical projects people use the same words, but they don't mean the same thing. Yeah. Is that the case here? Like for example. Is it clear who a manufacturer is? Is it clear what control means? And how does that work with the CRA?

Pierre: That's an excellent question, an excellent remark. I think that's not clear, and maybe more particularly not clear on the software side. I'm delivering software for my customer that will be part of an equipment, so it's a piece of digital stuff that will be used from our customer inside the equipment. And there is always an open question about how should we apply these rules for our delivery? Mm-hmm. We are now in a mindset of applying the rules to help our customer to go to the compliance with the CRA, but that's really something that is always been able to be interpreted in regard of what is right into the official law of the CRA into the official regulation. So that's a pretty good question, and I'm sure that nobody has an official definition of who should apply what today. Mm-hmm. Even if we have a big vision of, yeah, we know that our customers that are creating an equipment will have to apply these CRA rules, but in software, that's something more interesting.

Ruth: Okay.

Pierre: I tend to differ.

Ruth: Oh, interesting. Yeah.

Michael: So, so from my point of view, I mean it's a legislation and it went through a lot of iterations and especially in terms of software and more specifically in terms of free open source software. So you have a complete section in the CRA, which is defining all of these terms. You just need to follow legal approaches. So basically interpreting them, looking at them, and that's of course tough, let's say from an engineering point of view. But when you think about that, more than half of the CRA is the recitals that make up the reasoning behind why the act was created, that we now have an official FAQ published by the European Commission, which is answering a lot of these questions and that we also have the draft of the harmonised standards. I think it's becoming pretty clear and pretty obvious, and especially when you're looking at the recitals, a lot of reasoning behind that. So I think it's clear. It's just not nice. So a lot of people are still hoping that what is clearly written there doesn't really apply. And the, the big issue that we see right now is 96% of all commercial products contain open source components in some way. They're not completely made up by open source, but they contain open source components and making available to the market in terms of the CRA really means that you use a component commercially. And that first commercial use is basically the point of time when you start to take responsibility. Mm-hmm. So if a free open source developer puts a FOSS product on the market, they don't make it available to the market in commercial terms. So they are not liable under the CRA, they are protected by the CRA, not to be liable. This was really important just to keep the innovation in the open source space going. Mm-hmm. But on the other hand, if now a commercial vendor builds a product that they plan to sell using that open source component, they need to take the liability for that component. Also, they didn't author it. They're just using or consuming it. Mm-hmm. And that's something when you think about one or two components that you use intensively, that's not a big issue. But when you think about complete operating systems such as GNU Linux made up out of complete open source components, so thousands of packages. This is quite tough taking. Mm-hmm. Responsibility for those ones. So it's a truth that nobody wants to hear, and that of course is, especially when you're thinking about small and medium enterprises, is hard to do. You need to find ways and approaches how to work around this. Joining communities, not just consuming from communities, but really actively contribute to communities and finding a way how to somehow take this up together and be successful together.

Ruth: Mm-hmm.

Pierre: That's an excellent remark. And today in the kits we are providing to our customer, Linux distribution based on the tools named Yocto that help our customer to build a custom Linux operating system with the appropriate configuration specialised for embedded system. And there is always this question about who is responsible for what and how we as a solution provider can help our customer to go further in this answering to the regulation. So that's why we take care about vulnerabilities and more particularly in these open source component we are using, we're using a lot. Including the Linux kernel, which is, as Michael said, a huge product. We are talking about thousands of vulnerabilities applicable to the Linux kernel, so how we can take care about that and helping our customer to take care about that by managing this vulnerability workflow lifecycle management to ensure that we know and we know what is included into the product and how to manage them. That's a big, big topic. We have also developed tools that helps to manage, detect vulnerabilities and manage the life cycle of them. Mm-hmm. But I'm pretty sure that we will talk more in detail after about management of vulnerabilities.

Ruth: Just for my understanding. To break it down again, so Linux is an open source software and you are using this open source software to develop another open source software that now Avnet Silica is using, for example, in a commercial way, that means Linux is not responsible technically under the CRA, you are not responsible. But at the end, Avnet Silica is or Michael's customer. How does this chain work?

Pierre: Linux is an open source operating system. Mm-hmm. Built by a community of people. We are providing with the Embedded Kit, a commercial product that integrates Linux with different other sub components. My objective, I aim to provide an integrated solution because when you are using this kind of different piece of open source software, there is always a work of integration. Okay? Because you take an operating system. You take an update solution, you take a component that allows you to display video, play audio. So there is a lot of different software parts that you have to make it all working together, and this is the objective of the Embedded Kit, having a kind of pre-integrated set of solutions, set of components that works altogether. And we are doing the glue between all of these components, okay? To ensure that everything is working well, and this integration is what our customer pays for. You need to implement this integration in the best way. It's a complex and long job. Okay. Also where you can integrate new bugs, but also new cybersecurity issues if you are not gluing correctly all of this, so this is our solution. It's a commercial product that integrates different pieces of open source solution to help our customer to go faster. Mm-hmm. With their operating system and all the ecosystem of their embedded solution working well together, more or less off the shelf and ready to be customised using the added value of open source solution because they are able to continue to customise their Linux kernel to enable or disable exactly the features they need, but they will have this pre-integrated environment ready to go.

Michael: I think what's really important probably to understand the complexity of this is when you're looking at the definition of a product with digital elements under the CRA.

Ruth: Mm-hmm.

Michael: Because there's not one product with digital elements that you're putting in a product, but it's a hierarchical thing. So what you basically do is you build probably as an end customer, a product with digital elements. That's your product, what you sell. That's a home internet router or something like that. But this PDE is composed out of multiple other PDEs. So you have hardware components which fall under the CRA, and you have software components that fall under the CRA. And if you're further breaking that down. Every software component. So what Pierre mentioned, for example, the Embedded Kit is again composed out of hierarchically, composed out of multiple PDEs that are contributed by other people like the community. Mm-hmm. So it's like a big tree, which is folding up a big tree of dependencies, which we call the software supply chain. Okay. And a lot of these components are created by free contributors, so basically by the community, so they don't fall under the CRA. And what we then do is basically we go down the supply chain until the first vendor, the first manufacturer, who is somehow getting commercial value out of using that open source component. And what the CRA now says is this first commercial use of the component, whoever basically gets money out of this, is also liable and responsible for fulfilling the CRA requirements. Doesn't mean that they have to do a full assessment. They're just responsible that the product that they're integrating it is fulfilling the CRA also, they consume that product, so they can't blame the original manufacturer or the author like the community member basically created this component, if there's a problem, an error, a vulnerability, that's one.

Ruth: Mm-hmm.

Michael: And commercial use is quite interesting because commercial use doesn't just mean you build a product. Commercial use can also happen through monetising services around that product. So if you compose these products together, if you sell that composition, if you sell consulting and training, what we also do at Avnet Silica towards our customers. You take this commercial responsibility and you're monetising this as a service, so you fall under the CRA for what you do. Okay? And this is quite an elegant concept to protect the community. It's quite important to do this just to keep the innovation going, but it can sometimes cause a lot of issues at people who consume a lot of stuff, but don't create a lot of stuff themselves. And that's okay. That's just important. So the first thing that you really have to do is take a look at your software supply chain, become aware of what you're consuming and for what you are liable. And somehow then use a risk-based approach to find a way of working with this liability and becoming compliant.

Ruth: Mm-hmm.

Pierre: And yeah, as Michael said, the concept of composition is a key concept. And in the CRA regulation and vulnerability management requirement, there is one key concept named SBOM software bill of materials that really becomes the backbone of the management of a system because you need to understand the entire composition of your solution from a software but could also be from a hardware point of view. And this is where you really understand when you are having a look on the software bill of material, on the equipment, you really understand the number of components that is used by your equipment. And we can easily, when we are in the Linux ecosystem, we can easily talk about hundreds of components that are all assembled together to create this final equipment that the user is using.

Ruth: The whole principle is called secure by design or secure by default, as I understand. And what do businesses need to understand? Like are there reporting obligations? There are things like you mentioned, risk assessment and certification. How does this affect your customers?

Michael: Well, it affects our customers by having to do it and probably by finding the right methodology for their product and also something that fits into their existing development processes to actually do it. And when you're thinking about what the CRA demands, right? It's technical measures like security by design, but it also has a lot of measures to protect against the classical vulnerabilities. So when you're thinking about classical attacks, 95% of all attacks involve a human factor. So something like people not changing secure by default passwords.

Ruth: Mm-hmm.

Michael: People not knowing about the right configuration steps. So you might remember that casino attack where they used the fish tank controller to basically exfiltrate data from a casino in 2017.

Ruth: Oh, I haven't heard about that.

Michael: Okay.

Ruth: Okay.

Michael: That's a quite interesting case study because it involves a lot of these things that the CRA now tries to change. The story is easy, right? And the story, it was published by Darktrace in 2017 and nobody knows if it really happened or if they just put it in there, but doesn't matter. It's a nice story. So a casino put a fish tank, so basically aquarium into the lobby, and this was controlled in terms of temperature, salinity by just an IoT controller. Mm-hmm. So basically this one connected to the internet, as you can imagine. Probably a nice step showing you how good your fish are and everything else. And they used that one as an entry point to the internal network of the casino. And they exfiltrated more than 10 gigabytes of data. Wow. And yeah, I mean, ouch. That's a classical thing. A product with digital elements, connected elements, as one vendor said. Mm-hmm. Once the beautiful thing about the internet, it is connecting a lot of people. The most terrible thing about the internet is it is connecting a lot of people and things together.

Ruth: Wow. And?

Michael: When you look at this, what happened? Right? It was missing documentation. Probably the people who put the aquarium there, they were happy once they found out, hey, I can see how my fish are feeling on my mobile phone. They were happy. They didn't know about, I need to change configurations. I need to change the default passwords.

Ruth: Yeah.

Michael: So they didn't have the required documentation. Then they were probably a bit lazy, like, okay, I'm fine with that configuration. I don't want to isolate this device in my network, and so on. So they weren't aware about what they had to do, and this in combination resulted in that issue. And cybersecurity is sometimes like an onion, lots of layers, and at some point you start to cry when you try to tackle all of these layers down. And the CRA tries to put the methodology around that by mandating a lot of these things. And some of them are pure technical, like do your risk assessment and so on. But others, like all the documentation requirements. Mm-hmm. Or the secure by default where you just say, okay, if I ship a device to an end customer, I ship it in a configuration which is secure. And if a customer afterwards wants to break that up and open that device up to the world. Okay, nice. Up to them. But we ship it as a secure by default configuration.

Ruth: Yeah.

Michael: And there are also advanced concepts. So for example, manufacturers even have to think about reasonable scenarios of misuse. So they have to make up their mind thinking about what could my average customer potentially do to make my device unsecured by misusing it in some way. So it's quite advanced and it all tries to somehow tackle also that human error thing that contributes to a lot of attacks.

Ruth: Hmm.

Pierre: Yeah, that's an interesting topic. Secure by default is one of the requirements of the CRA in this secure by design ecosystem. In fact, secure by design is quite a generic view. If we get a very big picture of the CRA, you need to perform a risk assessment to ensure you understand where your product will be put and who will use it and who could attack your product. That will help you to correctly design the product based on this risk assessment. Then you have all the secure by design approach during development, and then you have the vulnerability management. So secure by design is like a philosophy, a way of working. Hmm. And inside this secure by design approach, you have a set in the CRA I don't remember. There is something like 16 high level requirements. One is secure by default, as Michael described. You need to be sure that by default the system could not be misconfigured with results. Some others around authenticity of the software or protection of the data. So that's how the CRA tried to answer to this global problem around cybersecurity, analysing the context, put the appropriate answers, and then manage on a long time managing the vulnerability, but not only managing the vulnerability on a long time, because you also have to update your risk assessment all along the lifetime of your product. Mm-hmm. Because maybe the product will be used in a different context. So that's really think at the beginning, but also continue thinking about the cybersecurity all along the lifetime of your product.

Ruth: Yeah. Yeah. We are now in the middle of basically everything concerning implementation, I guess. And it used to be always like integration, testing, building release. There was like a cycle that you follow. Does the CRA change any of these standard processes?

Michael: Not really. Not really. It adds some flavour to it, I would say. Mm-hmm. But it's completely adapted to this cycle. So you need to do different things. And when you're looking at standards that also tries to follow that design cycle, like for example, IEC 62443, and so on. It's perfectly aligned. And if a customer is used to a secure product development cycle or to a secure product lifecycle or implementing a secure product lifecycle. There won't be any news. I mean, the CRA is not like adding a lot of crazy things that nobody ever thought about. It's basically just about implementing what you should be doing anyways.

Ruth: Yeah. You should have been doing all along, right? Yeah.

Michael: Exactly. Mm-hmm. And that's what I always tell my customers. It's an opportunity. You don't want to be in the news for violating any of these things, right? Yeah. So it's also an opportunity for Europe to differentiate. So from my point of view, it's a really good thing to follow. The problem is not so much what the CRA requires, it's more that the CRA itself is quite unspecific in how to achieve this. And I don't see our customers trying to avoid the CRA. I see them struggling with implementing it by not having the correct information or having problems in onboarding the right way within the required timeline to that one. Mm-hmm. That's the major issue. It's not that nobody wants to comply or that it's overly complicated. So once you get into these discussions and you look into what's required, usually the outcome is, hey, that's not so hard.

Ruth: Yeah.

Michael: We can do that. Or most of the times we are doing this anyway. So the major thing is really thinking about risk management. The risk assessment, mapping that to the product. There's no 100% fits all the same product in terms of functionality. Like a VPN gateway could have a completely different risk assessment, whether it is in a commercial or in a home environment, right? Mm-hmm. So it's the same product. It even falls under the same CRA categories. But the risk assessment is different, and what you have to do is different because it's mapped to your product. And this is a thought process, which I think is really important if you're the manufacturer of a product, just to know about this, to make up your mind, and the CRA is forcing you to consider this and also probably to reconsider what you were thinking about two or three years ago, continuously while your product is in the market. Mm-hmm. And this is powerful to create a good product.

Pierre: Yeah, and if I get back to your question regarding quality and test, as Michael said, there is no direct impact of the CRA. There is no additional requirement maybe except to being able to confirm that the cybersecurity requirement implementations are properly implemented in your product and more generally speaking, I'm working in this area from 20 years and we see trends of more and more quality and the quality is more and more important for all equipment manufacturers. I'm seeing more and more customers that are requesting automated testing. Ah, we would like to build a test bench to ensure that all the features we are delivering are fitting that and in the CRA context, our customers asking how I can validate that my secure boot that my implementation of the secure storage is working well. So that just brings new types of tests. Mm-hmm. But the concept of testing more and more and bringing more automation is something that is now more and more standard in product development. Okay. And we are using this kind of methodology during development of our product, and we deliver to our customers the capabilities to implement their own automated testing. And that's really good news because it brings more quality and we know that there is one topic in cybersecurity, which is bugs, usually a cybersecurity issue.

Ruth: Mm-hmm.

Pierre: A vulnerability is more or less a bug. It's something that you have not tested properly and that make the possibility for an attacker, yeah, to penetrate your system, to take the control of your system and then penetrate the network. So more quality probably means less bugs. Probably means increases the general cybersecurity of all the equipment we have.

Ruth: Hmm. Yeah. You mentioned vulnerability management quite often now, and this is probably the big topic in this as well, you have to identify, it's not a feature, it's a bug or the other way around. Depending on the viewpoint, I guess. Uh, you have to report it. You have to notify people, especially if you have rolled this out to many customers. How does this work? Can you elaborate on this a bit?

Pierre: I can try to give you a big picture on what could look like a methodology of vulnerability management.

Ruth: Hmm.

Pierre: You always start with a software bill of material to identify all the software you have inside your equipment. This is the basics to being able to then get a list of potential applicable vulnerabilities to your system. This is from the view of vulnerability management. In parallel, you will also perform some static code analysis on your system. For all the software that you are developing. You need to ensure that you are not having bugs that could become a security issue.

Ruth: Yeah.

Pierre: If I get back to the vulnerability existing in the public vulnerability database. We can name the NVD National Vulnerability Database, which is today the American one, which is the most standard database of vulnerability, okay, that a lot of tools are using. You will be able to understand what is applicable to your software, so to your equipment, and then you will have to analyse to assess what are the consequences for your product. Some vulnerabilities are applicable to the Linux kernel, to the specific, I don't know, TCP/IP stack. Mm-hmm. You have to understand in your context what does that mean for your product. Some of the vulnerabilities in the context that you are in are not applicable. For example, you remove a component or you have no network interface in your system. So a lot of vulnerabilities can be removed due to the context where you are using the product. Some others are applicable, and these ones, you will have to define a strategy. Should I fix them? By using a patch that exists or maybe trying to fix them by myself. Should I deploy a workaround disabling temporarily features, waiting for a fix for this vulnerability or accepting the risk and explaining what are the risks, giving to the final customer a way to understand what are the risks and how they can work on the risk. Mm-hmm. So what you will have to deploy at the end will be like a report that will explain for all the potential applicable vulnerabilities what you can do and what is applicable in your context. That's more or less what you need to do. Detect, assess, communicate.

Michael: And you need to have the process to do this because that's probably the one thing that creates the most issues. You don't do that when you release your product, but it's a continuous process. So as said, security is a process. It's not a product. So the process is what creates security. You can't just buy a secure product and if you have a product, which at one point of time you deemed to be secure. Trust me, it'll not be secure a couple of seconds later. And that's the dynamics in the whole game, right? Seconds.

Ruth: Seconds. Okay. As simple as that because?

Michael: And then you have a 10 to 15 year product life cycle. That's a lot of seconds. That's a lot of, that's a lot. That's a lot of seconds. And it's the real challenge. And you can't do that just by yourself. What's important, and this is part of the process, you need to know what you consume. That's what Pierre has said, and you need to put yourself into the notification chain. So if a vulnerability is exposed in one of these packages, then you need to know about this. And on the other hand, if you are fixing it, even the CRA itself mandates that you're playing that fix back into the community. So if you have a fix to a FOSS product, you play it back, you contribute, and this is what used to happen all of the time within the communities on a voluntary basis, and now it's part of what the CRA requires anyways. So it's a good thing, but it is a process and you need to put yourself into the right position in that process and also align your engineering resources to work with that process. That's the important thing.

Pierre: And with the question on how to do that, you are an equipment manufacturer and you want to start doing this routine of vulnerability management. You will have to define a process, define tools for doing that. This is also where we can bring value because in the Embedded Kit we are having CVE scan tools that is there to detect the vulnerabilities and manage the lifecycle of them. And we take care, are able to bring a service of doing vulnerability management for customers. So usually we see a lot of customers that come to us saying, we don't know how to manage that because that's quite new. Please help us to start. So we put the process in place. We help them with the right competencies because there is a matter of competencies. You need technical competencies and cybersecurity competencies. Analysing the vulnerability is not just a matter of, I read the text and I will understand everything. You will have to understand both the technical context and the cybersecurity context. Mm-hmm. So we help our customers to build their methodology. We can do that for them for a few quarters, few years, and after some years, they have been able to become more autonomous on this process and start to do them by themselves. So that's something where everybody has to understand that you need a process, you need some knowledge. But that's something doable.

Ruth: Hmm. What in your opinion, is the one critical mistake you want manufacturers to avoid when it comes to CRA compliance and open source?

Pierre: I would like to say don't think about composition.

Ruth: Okay.

Pierre: As we said, as an introduction. Digital equipment is a composition of multiple layers of multiple products. If you correctly think in term of composition, it'll drastically simplify your life. So if you start saying, I will redo everything from scratch. I don't want an issue. I will rewrite my own operating system. It would just become crazy for you and it could cost so much. And with all the hundreds of open source products we have today available with a nice community working on different products, answering different solutions. That's very interesting to think about composition and how you can simplify your life for doing your product equipment.

Ruth: Okay. Yeah.

Michael: Yeah, and probably seconding what Pierre says. Yes, composition is important, but composition doesn't mean that someone else is taking care of your problems and your responsibilities. And I think that's the major issue right now, that a lot of manufacturers are waiting for a magic bullet to come up that is resolving all of the issues. And that's part of the risk management process that I mentioned. So be aware what your responsibilities are is probably step one in that one. And then take a look at how you can somehow achieve compliance and get rid of that risk. And that can be risk transference, like for example, working with Pierre and his team on finding someone else who is helping you with that. It's a completely viable means to do this.

Ruth: Mm-hmm.

Michael: But you need to be aware. You can't just say, okay, I'm using that Linux kernel or whatever, and somehow they will make it happen that it is CRA compliant. CRA compliance is nothing that you can buy or get as a product. It's nothing you get for free. So take responsibility, work with the communities, work with the guys who are writing your software and contribute to it and become a part of the community.

Ruth: Terrific. Before we close this episode, is there anything I haven't asked you that you wish I had asked you? Did I miss anything?

Pierre: I was talking a lot about the added value of software composition and Michael raised some warning if you are using a lot of components. You also have to be careful about these components. There is one type of attack named supply chain attack, which is quite common today. Mm-hmm. Where we all have to be aware about it. It's a concept of you are using a component that is using another component that is using another component. So you are more or less not aware about the hidden component inside and this component could become something critical and you have to properly manage the vulnerability also in this component, we had a great example of an attack that happened on a compression library. The XZ one of the community start to be corrupted by a guy that tried to integrate like a backdoor inside this compression library. But his target was to manage a vulnerability inside SSH, which is the most standard protocol. Mm-hmm. For doing a secure communication and it started injecting something somewhere in a library performing compression to being able to take control of more or less, every server around the world. It have been detected. There is no official vulnerabilities. Okay. But this shows you that we are building blocks on top of blocks and one small piece could be a cybersecurity issue for the big one. So yes, composition is nice, but don't avoid to manage the vulnerability for the entire chain, and that's something important. Mm-hmm.

Michael: And it's quite interesting, so maybe a lot of our listeners are aware of the OWASP Top 10, which is basically the top 10 security problems in the 2025 edition software supply chain failures. Well in number three, so they weren't on that list before. And what's also interesting is that 50% of the votes voted it for number one. So there was a quite strong opinion about the criticality of that one, and it was probably also fuelled by the SolarWinds attack in 2020. That was a pure supply chain attack. And it all boils down to know what you consume and take responsibility for what you consume, even if you get it free of charge. Because the free and the free open source software is not free of charge. It's for freedom. You can do with it whatever you want. You can use it. But you can also take and show the part of the responsibility for it.

Ruth: Those are great last words. Thank you so much. Thank you, Pierre, and thank you Michael for this very enlightening, very interesting discussion. I'm sure many of our listeners now must feel more secure to navigate this whole CRA topic and leveraging open source software at the same time. It was really enlightening and interesting. Thank you for listening to We Talk IoT, stay curious and keep innovating.

Michael: Thank you. Thank you.

Ruth: This was Avnet's We Talk IoT. If you enjoyed this episode, please subscribe and leave a rating. Talk to you soon.