CRA Explained: What the Cyber Resilience Act Means for Device Manufacturers

I know why people look at industrial controllers and say, "Well, this looks like, I mean, I've wanted the analogy. It looks a bit like if you have a PS5, and then you put a Game Boy next to it." That's about what a PSC looks like. It looks old-fashioned, but then again, it has to work in rough operational conditions. There's vibration, there is dust, there is heat, there's everything that IT does love. So, and these things still work for 20 years and counting. [MUSIC] Welcome back to episode 6. >> Thank you for today. >> Today, we got to do an episode on CRA, or EU Cyber-Resilience Act. And I thought, why not bring on a proper expert? I've talked a lot about CRA over the last year on the show, but I will bring on a real expert. So, today I'm with me, Sarah Flux. Welcome, Sarah. >> Hello, thanks for having me. >> Sarah, you are definitely an authority and you've been involved in CRA for quite some time. But before we dive into CRA and all the implications that it has to come with it for people who are selling at the European market, maybe let's start by giving people some backshow, but you saw, you've been in the tech world and around this world for a while. So, give people a look at our back stories. We can kind of shape the conversation, understand the context of where you've talked about it. >> Okay. Well, I work in OT Cybersecurity. So, my background really is in engineering, not in Cybersecurity. I'm one of the persons that were first in engineering and then kind of took the direction into Cyber. As we say nowadays. So, and I work for company, I'm a city of a company who does consulting in the OT Cybersecurity space. And we as the city, oh, I'm responsible for methodologies and for all the things that we do that make sure that we keep at the bleeding edge of what's going on in OT Cybersecurity. And that's why I'm always, I've always been involved in standardization because that plays a big role in Cybersecurity as we all know and also in regulation because it's just one of our driving factors. And I did a PhD in security by design for OT and during that time, there was exactly the time when CIA first came up. So, that's when I kind of stumbled upon CIA. I read monthly newsletter and that's always my time to read up on all the things that sound interesting. And back in 2022, I think nobody talked about CIA yet. And just the draft came up and I read through this and really was drawn into that because it was to go, "Wow, this is going to be a really big thing. "It's going to make a difference." And that's exactly the thing that I'm researching currently in my PhD. So, naturally, I was intrigued. Yeah, that's how I came to CIA and this year, I was selected to be on the CIA expert group for the EU Commission and that of course, it's great because you get a close up on all the debate that are going on around cyber, the cyber reserve effect. That, I mean, there's a lot to unpack there, but I think people have been, at least, well, I guess maybe people are not familiar with the OT world. Maybe they'll stop by there. What's OT? I mean, people come, they're, I guess, most of the audience watching, they're from the IT's cyber security space. OT, kind of a tangential industry with some overlap. So maybe we can stop unpacking that before we dive into that. Yeah, absolutely. I have sympathy for everybody who does know what OT is. So that's fine. When I started out in OT, OT wasn't even a world. So that's kind of new. And people that work in OT, that other people from the outside call as working in OT, don't see themselves as working in OT interestingly. So what's OT? OT, so the official legislation is Operation Technology. I also like to refer to it as the other technology so everything is not IT. So it's basically, and that's also how it came about. It is an IT people term for this change other technology that somehow also is on networks. And it's basically all the kind of electronic technology that operates some kind of physical process. So industrial plant or wastewater plant or production plant or our energy grid or all these things are operated by OT. So by controllers, microcontrollers, program or the logic controllers or control systems and all these things that belong to that. So that's OT. And how, I guess there is a, if you do an advanced diagram there you have industrial IoT, which is kind of like a, with moves somewhat into that space as well. Absolutely. Yeah. I guess it's murky. What were things belong I suppose, I guess is the-- Yeah, absolutely. And I'm not a fan of really getting too much call up in definitions on what belongs to OT and what doesn't, because it does really help. Yeah. And your push to being secure by the sign in this OT world, this, people who have had at least a little bit of expression in this world, they usually come away screaming because they realize that a lot of them are not very secure. Secure at very best is an afterthought, if it's a thought at all. How do you end up in that world at all? Because that's, it's almost, yeah, at CRA. As we will speak about it in a moment, we'll change this hopefully. But yeah, what's your exposure in that world? Like how do you get it drawn into that in the first place? It means security by design in general, or in OT. No, no, no. In the OT world, I guess, because that's-- It feels like security is actually bleeding the leading edge in the cyber security space in general. That's right. The OT world is 30 years behind in many ways. So merging these poles-- That's a very IT person thing to say, you know? It's actually-- well, it's been one of the long conversations of IT people who are saying, well, if OT could just do things like we've been doing that for 30 years, they would be fine. And the thing doesn't work that way. And at the same time, OT is ahead in other ways. So it's like it's a really specific kind of technology that is really good at specifically what it does. And it also-- if it's from an engineer's perspective, this always would bother me about IT when I first looked into IT. I was responsible for security engineering when I started out in consulting. And so I said down and said, OK, what is security engineering? And then I found out that IT people really have a very broad understanding of what engineering is called as engineering. So I mean, I'm a mechanical engineer. And then a process engineer. So when I think about engineering, I think about there's a problem we've got to do drawing, we've got diagram, we've got the methodology to solve this. We do some calculations. And then we've got a couple of options how to solve this. And then we engineer a solution. And in IT, it's more or less, well, here's you list of best practices. And you choose one. And then that's engineering. And that's kind of for an OT person. That's not how that works. So that feels like-- that feels like-- customizable looking, but not like engineering. It feels like witchcraft, but not like engineering. And that really, I think that is just the first difference that people need to understand when they say, both OT could just do things the same way. We didn't know they can because they-- I mean, the things that are OT in there, they're surrounded by a lot of more technology. And if you fuck something up there, then really they could have a nuclear power plant blowing up. Or you could have people's lives injured. So they are a lot more conservative about how things are and what the controllers can do and what the systems can do. And that's a good thing, not a bad thing. And also, they're very good at staying focused on the essential functionality of a certain component. And not having everything around that just because-- just because you can. And I think these are things-- so fundamental differences that people really need to understand before they judge about the other discipline. So it's the same for OT. So they also like to sneer at IT and say, well, this is not really-- that's not really engineering. It's not really-- that they change everything every day. And it's not made for decades. It's going to be exchanged in five years anyway. So it helps if you have a bit more respect from both sides to the other side. Thanks for the-- Thanks for the effort, Paul. I mean, I think you said something here, which is very interesting to me, which is the lifespan, the life cycle, which is very-- Like, if you're talking about cloud engineering or whatever you want to call it, these days, right? Like, that operates in weeks, months, years, maybe. But it's not-- you're not thinking that long term at all. Like, it's almost going back to the main framework analogy. Or I was like, they were built for long run. Card work, close to our femoral, and they will be replaced shortly, right? So the-- but this is really interesting. But tickly, if you talk about maintainability for a long time, zero trust in all these concepts, they talk a lot about how you are going to patch vulnerabilities. And how you're going to do life cycle management of these. Those comes to a very different endote world. How you do package managers are not necessarily a thing at all in that world, right? As a whole-- There's so fair work, too. differently in that word of time. Yes, exactly. And in every plant, in every industrial plant, when you work around, you find at least one person that says, look, and this PSE here that has been running for 20 years without a single day of downtime. Imagine that in IT. I mean, that's a superpower. Imagine we could do that in IT. And before I see managed to do that, I don't want to get advice from IT, how to do resilience systems, you know? Because it's really-- I get it. I know why people look at industrial controllers and say, well, this looks like-- I mean, I've wanted the analogy. It looks a bit like if you have a PS5, and then you put a Game Boy next to it. That's what the PSC looks like. It looks old-fashioned. But then again, it has to work in rough operation conditions. There's vibration. There is dust. There is heat. There's everything that IT does love. So-- and these things still work for 20 years and counting. Yeah, sorry. Sorry. I was just going to say, how do you view-- I mean, OTA being something that is kind of expected in the modern era of IoT and IOT, right? That's not necessarily some of the fits in traditional well-views from OT, right? Doing like pushing OTA updates over every few days or months or weeks or so. How does that kind of narrative fit into traditional OT? And you know what, because I guess that's the segment into CRA, which is tightly controlled that you must be able to do certain things like this, right? Yeah, right. And that's actually a hard thing to do for many, many people in OT because it's not like-- I mean, it's pretty clear that you can't just restart a nuclear power plant every two days. That was my-- So if there is a Windows patch day, and then next week there's a next Windows patch day, and that's something that drives engineers crazy in plans like that. But still, of course, there is this thing like IT and OT convergence. Of course, there is more and more commercial of the 12th technology and more and more normal IT technology being used in OT as well. I mean, at the end of the day, most control system service are around Windows. So it's not like we're immune against TENIO, these things. But still, if you-- the patching in general needs a different approach in OT, because oftentimes you lose vulnerabilities. If you just patch control systems, for example, you can't just put a patch on there. Because then the control system vendor says, OK, I'm out. No liability anymore taken because you've changed the system. Sometimes these systems have certifications. So for example, for safety certifications. So that really comes a-- that does a truth or someone else, so any kind of company who really certifies the software as is-- and you're not allowed to change a bit about that. Because otherwise, you lose certification and regaining certification as a process that can take months. So it's not as easy as saying, OK, well, then just deploy that patch and then you're good to go. And that's also one of the problems that many manufacturers in the industrial sector see currently when they look at CRA and say, OK, we're supposed to deliver products without exploitive vulnerabilities and also patch them immediately when they come up. That's actually a problem because we can't just take everything out of the market. And also, it's a problem for operators. We can't just always have three month standards just because there is a patch. And then we need to re-certify, for example. Yeah, because this is a complete polar opposite needs, because modern software assumes that you can do this stuff. But then there are-- That's right. You kind of-- I'm going to take a look. If you're using a bad example, like the JavaScript world, you just think things will be-- they have a six-month life cycle. Then there's a new library. Isn't it kind of weird that we accepted this normal? That your nature updates are fair, like five times a day? I mean-- It's crazy. You have zero. But we just-- Why is that become normal? I mean-- How is that supposed to be good engineering? But it is the way the things work in IT. That's right. Yeah, absolutely. I mean, but I guess what I'm saying is, with a looming pressure to be able to conduct these updates, there are completely bipolar requirements and the suppliers or the manufacturer of these devices, they're with a rocket heart plate. Because on the one hand, they need to have all these strict compliance regulations from that they cannot change things. And simultaneously, they have to change things. So-- Yeah, that's right. That's very different from, say, software, which is like update. It is absolutely. Yeah. And the approach that's very likely going to be taken-- that's also the approach that already is being taken towards patch management and OT-- that you just don't have this patch everything as soon as possible approach. But you do a lot more of down to earth prioritization of, OK, what really needs to be patched and what really is a risk because there is going to be other side. So there's always-- I mean, the risk for down patches is kind of clear because then you have the vulnerability. But in OT, there's also a large risk of patch because if you patch, there's also-- I mean, there's cost because sometimes there needs to be downtime for these patches. And there's also a risk of things not working. And then patches need to be rolled back and things like that. So that's just a risk equation that goes a lot more towards not patch-- even doubt not don't patch-- or have kind of compensating measures. Or also, and that's also how things work in CRA. For some systems, you just limit where they can be operated, what their intended purpose is. So you can say, OK, this is something that absolutely cannot be connected to the internet, for example. And then you can afford to not patch as fast as you would for other systems, for example. Yeah, because I mean, it's all like to use a cloud L. You don't have a staging new clear facility where you can use to run your tests. And then you-- All right. If you blow that up then-- Yeah, it doesn't matter that much. Exactly. Things just don't work that way in OT. That's right. Yeah. So it's very different than what. But all right. So we kind of worked-- we mentioned our CRA multiple times. And maybe you being kind of a much more domain expert than myself in this domain. What's CRA? Let's give people-- assume people do not know what it is. Assume that you're a company selling in hardware into European markets. And you have never heard of this, which I literally had a conversation this week with-- well, last week, sorry, with a vendor that knows what you're about this stuff. A lot of people still, even though ratification is starting next year, are very unaware what this even means to them. So let's start there. You're a vendor selling it to the European market. What do you need to know? Like explain it as I know nothing about this. I think the most important thing to mention is that there are certain cybersecurity requirements. If you don't meet them, then you won't be able to sell your product anymore into the European Union. And that's also the first thing that especially companies that are not from the European Union really have to think a bit and to swallow, because how can they even bring me from some selling products about yes they can. And they can base cybersecurity. And that indeed is something very new. I think that's indeed something unique globally. I'm not aware of any other region who has such strict cybersecurity requirements for products that even can prevent people from placing the product on the market. And I like to explain it best, I think, compared to other products, because essentially, in the European Union, we've had this very same mechanisms for a long time for other products. It's always been for safety reasons. So it's always when a product is at risk, can put its buyer or its user at risk, then there are some, there is a CE marking, stands for conformity European. So for European conformity, let's see into E and I've probably seen that before. And let's take for example, it's on sunglasses. So if you buy sunglasses, then of course, there needs to be proper UV protection, because otherwise people put them on. And if you don't have the protection, they assume they have the protection, then they can hurt their eyes. So that's why there is a CE marking on these sunglasses and that's that this CE marking means that manufacturers pledge to be in conformity with the relevant European regulations for this type of product. And what's new about CRA now is that really, such as the E marking gets applied on pretty much everything you have on your desk. So I read it to a product. And so from smartphones and laptops and-- My mind was pretty much-- Pretty much everything. Like even that would-- Well, well, well, then. Maybe that's what-- Yeah. So that's going to be a CE marking on that. And the CE marking is going to mean that's in conformity with all European Union regulations, including the cyber reserve against that. So you spent a lot of time doing advisory work with companies and in your consulting work. You now need to go. in form. So that's clear. But what did that actually mean? If you're selling the terminology is device, I'm forgetting. I'm pronouncing elements. That's that's exactly. You're selling you probably digitally and you're going into the European market. You have now assessed that I can't ignore the European market for strategic reasons or whatnot, right? And you now got to sell it. Where do I start to even become compliant as a vendor? So obviously the first step is as a vendor, which of your products actually need to be compliant. There are some categories of important and critical products that have some strict, not requirements, but they strict requirements for approving the conformity. The requirements are the same for when you've done that, what you have is the basis of the CRA, if you only want to read two pages of the CRA take nx1 because that's the essential requirements and that's the requirements that actually you need to be in conformity with. So and that's two parts. The first part is basically technical requirements that were very broadly. So there are things like integrity protection or make sure personal data is protected. So nothing that comes up as a surprise for a security person to be honest. And then the second part is about vulnerability handling because CRA really a large part of CRA is about vulnerability handling and that also makes it different from all the other product legislation we have in the European Union because obviously I mean if a product, if you think about product safety then you produce it in conformity with some kind of legislation and test these UV protection for example and then you're done unless you find an in-be-stake in your production and or something but that's really not that not that often but it's cybersecurity. We have vulnerabilities that can come up anytime and that really makes CRA so different. So the thing that think that's most maybe hardest for manufacturers to believe and also to me is that they actually have to have a support period defined for the products that has to be at least five years or as long as the products lifecycle lifespanners and they have to deliver security updates for free during that lifespan and that's a big one of course because yeah and there's a lot to impact there right for the first one is five years and that is even if you're a product today with existing skew and that's the place in the market the clock and this is where I've seen a lot of people confused about CRA like when that five year time period starts if I have a product that I've already had a manufacturing and I'm placing that on the market today and selling that today with an existing skew that's the clock start from the first customer buys it does it start when I first started manufacturing so like it's three years from that period like how does that actually clock work? Yeah the concept of placing on the market is a bit hard to hard to grasp also because it has a lot of legal deep dives you could do and say okay in that case in that case but generally you can say placing on the market is when a manufacturer first sells that product to someone it can be a distributor it can be the end customer but it is the first time it leaves the manufacturer's facilities a contract assigned to sell the product to someone whoever it is and what's also important for the CRA to understand CRA is there's no such thing as a product type or anything so the CRA always applies to each individual product that also means if you buy a laptop CRA doesn't apply now but if you buy a laptop on the first of January 2028 then it has five years of support period and that ends on the first of January 23rd 3 and if you buy it six months later then that laptop you buy six months later has a support period that ends six months later so it's actually for every instance that sold this is extremely complicated in supply chain because US manufacturer do not control your entire supply chain per se that you might have sold it to a distributor who sit on these for three years and then they finally sell them but US manufacturer still obligated to support it when it gets to the hand of the customer no no you're not you're not not you're because that could be could be impossible for manufacturers to control as you say so US manufacturer you're obliged to support the product for the five years or whatever the support period is starting when you so it's said to the distributor so if it sits as the distributor serves for five years then theoretically you could buy a product as an end customer that doesn't have any support and you know right so it's void and void as the clock starts when you ship it off to your distributor or your end customer depending on yeah that's perfect because otherwise there's no way for the manufacturer to know that was kind of my point because then you have like essentially infinite life cycle for a given device which is not really complicated enough as is so because theoretically you have for a single product you can have multiple endlessly many different dates of end of support period and I actually think there will be pragmatic ways how many factors to you with it so when I when I discuss that the most likely cases that I say okay we just have an end of support date and the first product that we sell if someone sells buys it by its earlier then they just get longer support but the guarantee support is just five years and then so that you don't have to maintain multiple support and dates for the same type of product about different instances because you're getting crazy how I'm demonstrating that yeah yeah exactly and that's yeah it gets really difficult and also now let's talk about what that actually means to make sure you provide security updates for these devices that you send because we talk about vulnerabilities of patching all those things if not really a solve problem today to do like there's not a unified way of doing software and security updates across products in the market right it varies a lot like the way you do that for a light bulb is very different than you do from a laptop which is very different from a camera right what have you seen so far like in terms of I mean are you expecting to see more involvement in that space because right now like iot is kind of very fragmented to say the least when it comes to the OTA and an update and how I mean how do you expect this to kind of change the landscape really because it does yeah you can't really expect people probably USB sticking up those things right and that's not really well and then an OT so the thing really is CIA doesn't cry power updates actually we wrote out so I know that another relationship I think also for automotive there are requirements to do it over the air there's no such requirement in the CIA there is a requirement that you can do it that you must be able to do it automatically if technically feasible and also and that's something that came in after a lot of industry feedback and also that there must be a way to turn off the automatic updates because that again in OT really matters and we have a lot of so if you're looking at industrial manufacturers so automatic updates are great for consumer devices and having in turn to all is great for consumer devices unless the consumer chooses not to connect them to the internet which is sometimes security wise so then you have this conflicting advice of to connect don't connect to the internet but do enable the automatic updates and then well that's a deadlock but for industrial manufacturers oftentimes customers don't at all want automatic updates so it's like the worst thing that can happen to them because then they I mean we've talked about software not being not being changed and certifications and doing that automatically this is even worse so we do have a lot of industrial manufacturers as customers to actually say the default for us is not doing it automatically and we're putting in our user instructions information that we don't do it automatically because it doesn't make any sense it would just increase risk and not lower risk. Okay and then yes people walk in with USB sticks and update devices that's how it works. Sometimes even in industrial space sometimes even customers aren't even allowed or don't even know how to update these things themselves they call any kind of contractor or service provider and they walk in with the so-called USB stick and update devices so that is completely normal. Yeah it's very different world. It's a different world yes. Yeah I think it's hard not to move on to S-bombs from here I guess which is the litmus test for if you know yourself or supply chain. I've had Alan Friedman on the show I just used to spring it on the show and I had a bunch of people in the S-bombs world who have spoken about this. I guess if people really want to know about S-bombs they they should probably go back and watch those episodes. But what I'm, I assume people do know what an espim is by now. And people who are watching this from your side of the world, like in the your side of the world, in the sense of the OT world, building us problems for a Python application or a rust application is fairly straightforward. Doing that for them, but the world, very different problem space, right? I, I call it one of the system working groups for espim generation with the guy from Lockheed and they are now trying to figure out how to do espim from like 30 year old C code, right? And that's a very different problem. I'm sure you've seen something similar. Like what, what have you seen there in, in people's journey to try to generate espim for what, what generally we call legacy systems, right? Yeah. I mean, I'm probably you have a lot of more, more hands on experience on that. I would be really interested in in hearing what you experience on generating embedded espim. This, I think the first thing is that people start to realize that they need to do the espim at all, because I mean, it's the first time there really is a requirement to have an espim and a lot of discussions that I see a first base around, okay, we create the dashboard. I mean, we're not, they're not obliged by the CRA to also share it with our customers, but of course, many customers would like, would like to have it because they themselves are also CIA regulated, so if they use the product for, for using it into another product. So that's a big discussion with a lot of manufacturers saying we don't want to share it because it doesn't even help you because then you get the updates from us anyway about vulnerability. So why would we even share it? I would be interested in your opinion on that actually, but what's in there? This is a conversation I've had many times and a lot of people have very short opinions either side, right? Yeah. It's an espim good to be shared publicly. The answer is the patterns, right? And I think to me, the reason why it's important to start with is it's a litmus test. Do you actually understand what goes into your software? I think that's a good starting point, right? And I think dealing with that in the legacy world is very difficult, but I think the sharing side of it is something that I will see if the app that increases for it over time, I think we're going to have, I mean, you have the requirement, I believe you need to archive it for five years. I think for every release, right? Yeah, I think five, ten, yeah. It's something like that. Yeah, but that means that regardless how you generate the set espim for your product, you still need to have a lifecycle part of it, right? You need to build and store it somewhere. And I mean, we have just referenced the Sysa sharing primer, which I'm sure you've read as well for espim. The share of the problem that was written a few years ago, it's not a problem. People don't actually do it properly. Like I've spoken so many Sysos and they're like, yeah, I get a mass bombs. I chucked them at the SharePoint. And that's it. So the lifecycle things is a problem that I'm passionate about, I try to solve myself, because I think that's a big part. And also then the version management and the differences. So how do I quickly track the difference between an S-bomb from five years ago and two years ago? And not only that, because what I discover when we started doing S-bombs in the real world is that in a real product, you're not going to have one S-bomb. Like you're going to have 10, 15 of S-bomb for different parts of your product, because a product is a composition of multiple components. And when you started to release things, you might use four of these, but this component changed. But the top level S-bomb is no different. Right? So the release management is becoming much more difficult to do and shame the self plug. That's what we saw with Spotify. But that's kind of the hard part really. It's like how you do that scale, because if your top level obligation is that you need to provide an S-bomb for a product of a given version, you need to have in four years from now, we would say, oh, version 432 had these S-bombs. And that's the tricky part. Yeah. And then also I think that the, of course, there's a requirement to have an S-bomb period, but in the end, just having an S-bomb doesn't help you at all. So you need to be able to do something with that. And that's where a lot of conversation starts also in the industrial sector, and I believe everywhere, because people say, OK, now if I have the S-bomb, now what? Because if now a vulnerability comes up, I would expect my S-bomb to quickly tell me, am I a factor or am I not a factor? But for that, you need not just an S-bomb, you also need to have the vulnerability reporting in a format that actually corresponds to S-bomb format. And that's also one of the big, big things we're talking about. So here, at least in Europe, and in the industrial space, the German PSI also supports it. There's a lot of discussion about CSF. So a machine-readable vulnerability. Sharing format. So we will say, OK, let's share vulnerabilities and security advisories in a way that is kind of standardized and machine-readable so that they can be tied into the S-bomb mapping and all that thing. All those things can theoretically be done automatically, because nobody wants to read all these vulnerability advisory PDFs and then try to make sense of that. So I think these are all the kinds of things. I mean, an S-bomb is great, but you also need the entire ecosystem around that for it to work and not just be a giant data dump. Well, yeah, but I think there's one even equal important point here, which is garbage and garbage out, right? Like the quality of the S-bomb ultimately determines how useful this. And I think that's a lot of people have gone through the motion to generate S-bombs just to take the regular to requirements. But I think, and I'm curious about your thoughts on that, because unlike, say, NTIA minimum amount or a system minimum amount, and now that's in draft, the C-A-ray doesn't explicitly state what the S-bomb should look like, right? It doesn't, NTIA minimum and system minimum, they go into very specific details. It should capture this data. It should capture this data, but C-A-ray is much more vague on what needs to capture, right? They are thinking about, so the European Commission is on NISA actually thinking about releasing some more guidance on what it should look like also because to achieve some kind of harmonization of how S-bombs look like across different products. There's currently actually a study carried out by NISA requesting industry to submit on all manufacturers in general to submit what they are currently doing regarding S-bombs and what their preferred formats are, things like that, in order to make sure that the guidance that they are drafting kind of reflects the reality and not has like the most cutting-edge best ideas for S-bombs that nobody can follow in reality because that's really not what everybody is aiming at. Even the EU Commission isn't aiming at that, sometimes we need to stress that. Yeah. I think I really think if manufacturers are worried about unrealistic S-bombs requirements, go to that study and participate and really have a. You don't have to shine there, just say what works for you and what doesn't work for you because they're really trying to do that guidance in a way that actually reflects industry needs. I mean, I think the S-sign and N-T-I-A in my elements are pretty good, because I think they are. I would say they are the gold standards as things stand right now. Are they hard to meet? Well, that exactly is what we tried to set out to test in the working group that we co-led, right? And the answer is yes, it is rather challenge to do it. It can be done, but it's rather challenging to do it. And again, coming back very much to what ecosystem are you in? Like doing it for a web app is very straightforward, rather straightforward. Doing it for embedded C code. A lot more challenging, right? That's a problem because many of these things are always tested in like, okay, let's take just the most basic thing that we have in tested and then it works fine. And then all the other product manufacturers come and say, "Well, our product isn't that simple so we don't have to stand on a web app. How about us?" Yeah. I mean, there are some. I mean, what I've seen at least from the embedded world, there are some good things coming out of this. Conan, the Package Manager for C, is almost like a direct response to that. I mean, I'm sure it predates the whole CR-8, but it's a good slot-in way of. If bringing something that you can work with as a package rather than just a file you copy and run, which is tradition, speaking how a lot of embedded has been, right? Like, you include this library that you had on some file share. That is not even versioned. And how you possibly go to a CV scan about, I guess you could just add a codenosis, but it gets a lot more murky, right? But what have you seen on that? Like, when you advise companies, imagine a lot of them do have large legacy code basis, right? Much of it, I would imagine, given how T being C code, I would imagine, right? How are they reacting to this? Are they like. Oh, we got to solve this, or are they trying to. that I put their head in the sand and just try to I know the problem altogether. - Well, at least what I can, what I see, there's always the prejudice that manufacturers are just sitting out and not doing anything and things like that. At least that might be biased because people I work with obviously care about CLA and aware of CLA. But all the manufacturers I see are really trying to take that seriously and also often trying to use it as a vehicle to improve on product-saving security. Often, further in projects, they've been trying to promote for years and now they have a reason to do that. So I mean, the NASBOM isn't, if done right, I mean, it's not just a compliance thing to do or something that you do in the tick of the box and then file a site. But it's also something that really helps you doing some of that quality, doing management, doing dependency management or these things. So developers usually have an intrinsic motivation to do something like that because they want to get their code in order. So they're trying to find ways to do that actually. - Yeah. - So it's, yeah, that's okay. - No, it's good to say to me, an NASBOM is just a good litmus test of what you know. Can you actually tell me what goes into your software? It might not be fully complete and we all know that. Like the cause of completeness in NASBOM is, like you can't measure completeness because that's an impossible thing to state that it's complete because how do you know? But it's bad. - And that's here, it doesn't even say it needs to be complete. Just say, do your top level dependencies at least? - So no transient dependencies are required at all? - No, it says, it explicitly says at least the top level dependencies. - Okay. - I think also to make it more doable for companies who are going at it the first time. - Yeah, I mean, I think for me at least that I, it becomes a good, like once you start generating these things, you can start utility, then you can start using S-BOM's operational decisions, right? You get to the good way of expressing your posture, like CV being one of them, but also like other things, like license audits, that's something that people should care about. Like do you have some open source libraries that breaches my contract obligation with other things, right? That those are things now you can start doing. And that gets even more complicated in NASBOM. - It's often the case in cybersecurity that, for an owner who does cybersecurity well, you do need to do all the quality things that into documentation things that shouldn't be cybersecurity's job, but they are because nobody did it before. And I think there's the same with S-BOM's, and I see a lot of parallels in the entire risk assessment discussion that we're having around CRI, because that's kind of the same. It like for S-BOM's, there are a lot of analogies there. You can do an S-BOM just to check off the box, and then you have the S-BOM, and never look at it again, or you can use it to actually improve your decision making. And it's the same with the risk assessment. The CRI says you need to do a risk assessment. You can just do a risk assessment, fight it away, and never look at that thing again. There's probably going to be not the best experience, or you can actually use it and see it as a tool and embrace it in order to do better and more informed decisions. And that's, I think, if there's one bottom line, if I should differentiate between manufacturers who are doing CRI compliance well, and those who struggle, then that's really that mindset saying, okay, there are these things in the compliance, but I don't look at them for compliance purpose, but I take them and try to use them for my security posture. And then the compliance just pops out in the end, because I think that's what the great thing about CRI is. There wasn't any critical debate on the requirements in CRI. It's like the wish list for every cybersecurity practitioner in the world. I mean, it's risk-based, there's an S-BOM requirement. There's all the cybersecurity-based, assessment-based handling. So none of that is debatable, like from a common sense point of view. So you can really take all that and use that to better your cybersecurity posture and do it well and achieve cybersecurity CRI compliance on the way that is entirely possible. Yeah, I mean, to me, it's very clear the direction we're heading right. Like we, we, S-BOMs will come, at least if I were to hypothesize, a core requirement in almost any compliance framework going forward, like CRI can leave in the way. PCI DSS 4.0 starts asking for a software inventory, which is just S-BOM codified, right? And I mean, I would be surprised if, if SOC2, when the next update comes around, does an ashyp-bombs, same with ISO, right? I expect them to follow, right? And that becomes the universal litmus test in a way. But I think there are some issues. And also, I mean, if you have a software manufacturer who's not able to draw a BNS bomb, then you should raise serious questions about how they actually code that software, right? So that's. Yes, but the code. It's kind of a software quality thing as well. I totally understand. I have sympathy for everybody who hasn't done it yet, because it just wasn't a requirement. It's kind of new, but every developer who strives to good, good quality code should get excited about that somehow. Oh, yeah. No, I guess my only compromise, that sometimes you depend on other vendors who do not provide that. Yeah, that's true. And that's where it's tricky. You might want to do the best. But then he used to go think about C-R-A, all your vendors fall under C-R-A as well. Yes, so they need to have an S-BOM as well. And that's also one thing that I see currently in the industry, if that's why I ask about sharing your opinion on sharing S-BOMbs, because people know that all manufacturers have to draw up the S-BOM anyway. They start requesting it from their manufacturers, because they say, well, you're obliged to do that anyway, so why don't you share it with us? And there's always, I think, C-R-A is also strengthened by the awareness of customers that certain things need to be done at the manufacturer, so they can as well ask for that to be shared. That holds true for the S-BOM, forest assessment, for vulnerabilities, for all these kind of information that kind of people had to back for and dig for in the past. And now it has to be there, so it can as well be shared. And that's a real difference that I see. Yeah, and I think let's go back to the sharing, because I think there is more time to unpack it, because I think there is, it's how you share, right? I mean, what you mentioned already, like, what, how much should you share? Because that's an open debate. Is it in the public, is it gated? There are many ways to do sharing, right? But I think the one thing that I'm really excited about around sharing is, is, is how we automate that scale, right? So I'm, I'm working with a pretty called Psych-Transparent Exchange API under Cyclone DX, where we try to like standardize the way you discover S-BOMS and secure the artifacts. And I think that's an interesting way of doing that, because again, going back to, if you, in turn, depend on other companies that are part of your supply chain, do you need to be able to discover their S-BOMS in a programmatic way? You can't just go and say, oh, we just kept in release, which requires a new verse of this. Email me your S-BOMS. Like, it doesn't work. It needs to be an automated process that's fully like, oh, I'm, I'm requiring this version of your product, now give me the S-BOMS for that version of that product, right? And that's a good way. And that's also a really smart thing, that the CRA does, I think, because they say, okay, a manufacturer is responsible for this entire product, including all components. So you're responsible for security of your products, including all the components. So you need to, you better make sure that the components that you have also meet certain cybersecurity standards, so that like trickles down the entire supply chain. And that also holds true for open source components. Yes. And I think that's, I mean, that's a tricky discussion, because I think that's really at a crossroad here. So either it really strengthens the open source community, because manufacturers are forced to contribute more, or it weakest the open source community, because manufacturers say, oh, I can't take responsibility for that thing, because it's open source. So I'm really curious looking what that is going to look like in the in the future. That's a big kind of word, but it's probably word to its own episode, I think, because I think that is, there's a lot to talk about there, right? Absolutely. It's completely unrealistic to expect that a one guy, or girl, library to have the same like SLA for fixing things as a multinational. But it's not required, right? The thing is, I think what the CRA does right, is I don't want to come across as a CLA Fango. I'm just trying to take an optimistic view and to help people see the chances in that. What the CRA does right, I think, is that it, or the advantage of the big chance for the open source community is that it really brings that responsibility and accountability question into the open. Because currently, what manufacturers often do, they just use the open source components because they're free. But they didn't really contribute anything. They didn't really take responsibility for the policy because everybody is using it. So we can use it like everybody else. And now, the CRA just makes it very explicit who has responsibility. And with that, manufacturers also need to decide how they live up to this responsibility. Do they commit to the open source project that they're using? Do they support it if they can't commit? That's also a way to do it. Do they support the ecosystem around that? Or do they say, okay, that's all much more expensive than building it ourselves? Well, then fine, then, of course, there wasn't a business case for the open source project. I mean, that's fine because it just brings all this, that was implicit, it brings all of these conversations out in the open. Yeah, no, no, I mean, I am generally speaking optimistic about CRI. I think I'm not one for heavy regulation in general, but I think it's painstakingly clear the fact that security in the, has been a market failure. If there's, if nothing has changed, if nothing will change, we will still have the same debate in 10 years about IoT device with default passwords getting compromised or like nothing will change unless the regulatory pressure to change. So I'm not, like, I'm not favor of, of doing heavy-handed regulation, but I'm also painstakingly, I think it's basically obvious that something got to change if we're asked to make a difference. Me neither. And I think in a deal word, we didn't need any of those. Right. So in the deal, but we didn't need any law at all because people wouldn't murder each other, right? Right. But the problem is, right now it's unfair because right now we have security regulation for critical infrastructures, for example. And they have this problem because they say there's also a lot of industrial sector. And they have this problem because they say, okay, well, we are supposed to take responsibility for the security for critical infrastructures and then we buy all these components that are complete black box and we don't have any rights to claim anything from the vendors and it's so hard to make them share information about cybersecurity and to live up to minimum standards and things like that. So I think it's a bit of putting a bit, a bit tilted version of regulation more upright because now all manufacturers also have to do their part. Yeah, and I mean, it definitely, I mean, I doubt would have fair bit of manufacturers in China and so forth. And obviously in particular, when you're buying software and hardware from there, the security attitude is very different as well. And I think that has put generally speaking and disadvantage for Western tech companies in general. In particular, you look at like, I mean, baby cameras are good example of something like that. Like where it's usually like the cheapest one is the one who sells them out list because people don't really average by a compel difference. And security is so hard to communicate and so hard to grasp. Yes, exactly. Like people are like, yes, I can see my baby on my phone. Problem solved. Can the rest of the world also do that? Yes, and that's the difference. Yeah, and then there are a lot of people who say, no, I don't use that baby cam on the phone at all because it sure is insecure. And that's also not great. So finding like a middle ground where we say, OK, we make it transparent. What kind of security should be there? So that's something that people who care can request and can take a look at. And also some others that don't give a shit about security are just pushed out of the market. I don't think that's a bad thing, to be honest. So I always had a lot of conversations with manufacturers saying, oh, now we're putting European manufacturers as disadvantage, but that's not true. Actually, I put them at an advantage because at least if they're holding up to higher security standards because CLA doesn't just apply to European manufacturers, but to all manufacturers who sell to Europe. I mean, it all comes down to our day because I've had this conversation with a lot of people over the last few years and really comes down to once this takes-- is ratified in-- because I mean, Germany was starting on the first one to actually put their draft together, for how actually the law is going to look like. It's not that surprising, but now once we entered the actual time window for way to enforce-- and it's then going to come down to will this actually be enforced. Because if you will not be enforced, and there will not be any examples made out of this, then no vendor's going to actually care in them. And that's going to be the tricky part at the end. Will they care? The good thing is that it's not just upon market surveillance authorities to enforce it because I am always-- many manufacturers are currently asking me OK when our like, early market surveillance authority is knocking on our door and trying to pro-products. And of course, that can happen. But that's not the most likely case to what that should be afraid of, because I think the much more likely cases that security researchers that's already been there, or also competitors of these manufacturers, take the product support and find long-conformity claims at the market surveillance authorities. And then they need to go after that. So it's really all the things that security researchers have done for ages anyway, they now have something to like a tool to say, OK, if they really find something that puts the product at non-conformity with the CRA, there's actually a tool for market authorities that-- to force market authorities to go after that. And this is like the hardest penalty you can give to any manufacturers that they can't sell their product anymore. I've also heard people saying, hey, what, but the fines are not high enough, but this is not about the fines. This is about not being able to place a product on the market. That's the highest fine you can get. Yeah, I guess my war, I guess, is some extent, which is voiced by, is this going to get stuck in court for five years before we see the first actual verdict? And then nothing is going to happen in the in between, I guess, I guess there are lots. There's a lot of crowd happening now, right? Co-tapping, yes. But then at least you've got to start somewhere. So maybe let's start these five years of doing nothing now. Let's find out. The last thing I wanted to wrap up here about is talking about like communicating all the abilities because that's a big part of the CRAs. Like how do you communicate all the abilities? And there are anybody who works in sub-security or if it's like the CVE process and how that works as full or it may or may not be, that's a different debate altogether. But communicating that both to consumers and the EU side of that, like walk me through the requirements for the CVE side of the CRA. Like how does that look like? And what does it look like for a manufacturer who's bringing it over to the market? What does that look like? Because the CVE process is very different. It can be fed in, I suppose. But most vendors are not familiar with the CVE management side of things. So what does the vulnerability communication look like? Is that a question or any-- No, my question is more like, if you're a manufacturer selling it to the market, and if you're a small manufacturer, you have probably never have to dealt with CVEs. Right? Or you've dealt with them in your supply. Which is about, you've never then had CVEs issued against you. So you are not familiar with the process around that. When you have to get the market to work. It's closure and all these kinds of things. Exactly. Yes. So what they have to do is-- there's always, I think, there's one basic distinction that people need to be aware of. It's a word that's not that great in the CVE. I think there are exploitable vulnerabilities. These are like the things that must not be in your product. And if the exploitable vulnerability is in your product, then you must stop selling it. And then there are the actively exploited vulnerabilities. And this really is more like a security incident. So it's really something has happened to your product. So somebody has actually exploited something. So it's not just a vulnerability. It's more like really a security incident. And for the latter, manufacturers have to report them actually to authorities, to Anisa, and to the National Seasurps, by National Search. And for the former, they have to-- well, they have to scan for vulnerabilities. And first, they have to find out which of those are exploitable. Which is kind of a term that manufacturers can somehow shape themselves. So they must decide what is exploitable to the cloud is exploitable for their products, on their circumstances. And for those, well, that's basically the normal responsibility, disclosure, and also the normal vulnerability handling process that people know that people use. I don't think there's big changes in there. So you need to have a fix or a patch. You need to communicate to your customers. You actually need to have security advisories or all these kind of things. And you also have to have contact point that people can approach you about vulnerabilities, as a response to this closure. And I think if manufacturers haven't had any vulnerability management process before, then probably the hardest part is really establishing a process to efficiently work on your way of the big the pilot for the abilities that's going to come up if you start doing that. So that probably is the most difficult thing to do in the beginning. As someone who runs the ability programs, I can, I think a lot of people underestimate the workload that comes from managing a vulnerability program with responsible disclosures in particular now in the day of AI. I mean, I can see one of my cohorts screen, we get so many vulnerability disclosures every day. Okay, you need to deal with all of those. Yeah, the problem is the signal to noise ratio, right? Because yes, you might get a hundred reports. And 99% of them are just AI filings essentially, but there might be a super severe one on the one, right? That's exactly what I mean. So like a efficient mechanism for getting this big pile of information down to what actually matters. So I think that's the biggest challenge in there because I mean, the former reporting, well, find there's a reporting for reporting portal going to be and you need to file a report there. That's fine. So that's all things that are doable, but really managing this influx of information. That's the hardest part, I think. The tree arching is the hard part. Find the signal to noise. That's the hard part. Finding a way to actually, I think an efficient way to define for yourself what an exploit your vulnerability is. So that and making that decision to what needs to be patched and what doesn't and then communicating that well. I'm hoping that we're getting good industry standards so that people say, okay, like this is how you actually, how actually customers want to see vulnerability information and advisories so that we get somehow a standard. I've seen many people or think Cesar also does it using my data tech, for example, saying, okay, we this refers to these micro tech techniques. And this is what we recommend you to do. So any any kind of structure that is reproducible, I think that would really help. Yeah, I think that there is a push right now for kind of a more global non-US centric view of CV publishing, right? Because that's been kind of on particular with, well, I don't know where we stand right now. It's just a vulnerability basis and where I, but yeah, like not the last like having a global one that is non-US centric is probably a healthy balance, I guess as well. Now you can you even has also a nice eyes also published its own. Yeah, UVD. So yeah, it's not really a known database, but it's an own, an own display of the information, right? So they're not collecting their own information. But that again, that is not the most important part being similar to managing vulnerabilities. It's not it's not hard to write a software to put them in a beautiful table. It's hard to find a way to actually manage that, find a process to manage that at the same time. It's I think that's what's behind the CV, the CV database that really is all the work is collecting all these vulnerabilities and writing the advisories and filling the database meaningfully. And I think that is still unanswered who's going to that. And I can tell you firsthand working with like both projects like OSV from Google and dependency track from Cyclone DX. The problem is you will have false positives, right? Because they are not super clean data sets and you will have duplicate names. Like I can give you example, we had a higher load firing like that a week, say like super high vulnerability. They're like on this package. They're like, well, we use this package, but it's a completely different ecosystem. You just have to have the same name. It's just like this full of it was like a Java package and we had like a Python package, but like they had the same name. That's something that I could somehow sort of mean find duplicates or something like that. You would think they will get there one day. But I mean, at least people started using them more and more, right? And that's kind of how building up these tools and make them better and making the data so it's better and more useful. So now this, this, I hope that we'll have a better place in a year from now. And when things are starting to start to shape up. So Sarah, we can we up the top hour here. What would you like to say to people that are getting into this like last failed words for people who are looking into getting the CRA cards sorted? Any final words of where they need to get it off with you or what's your one advice? But what I always wanted to take us one of the first steps is to find their showstoppers in their products because product life cycles development life cycles take a long time. And it really makes sense to write in the beginning. Really run your products high level through the CRA requirements. Don't wait for any harm. And I said, I take the CRA requirements and see where you might have major show showstoppers and work on those because these are the things that are going to take time. And then second, start doing the risk assessment cause that really is to linchpin and CRA that you need to make all decisions. And if you start with those two things quickly, plus the vulnerability handling, then the rest will fall into place. I think wise words. Thank you so much. Sarah, thank you for coming on the show. Have a good one. Thank you for having me.