Podcast
Join Viktor, a proud nerd and seasoned entrepreneur, whose academic journey at Santa Clara University in Silicon Valley sparked a career marked by innovation and foresight. From his college days, Viktor embarked on an entrepreneurial path, beginning with YippieMove, a groundbreaking email migration service, and continuing with a series of bootstrapped ventures.
Links
Follow Me
Follow Me
Join Viktor, a proud nerd and seasoned entrepreneur, whose academic journey at Santa Clara University in Silicon Valley sparked a career marked by innovation and foresight. From his college days, Viktor embarked on an entrepreneurial path, beginning with YippieMove, a groundbreaking email migration service, and continuing with a series of bootstrapped ventures.
CRA Explained: What the Cyber Resilience Act Means for Device Manufacturers with Sarah Fluchs
Play On
16 DEC • 2025
1 hour 6 mins
Share:
What happens when long-lifecycle hardware meets modern cybersecurity expectations? In this episode of Nerding Out with Viktor, I sit down with Sarah Fluchs, CTO and OT cybersecurity expert, to break down how the Cyber Resilience Act (CRA) is shifting the way secure products are built, maintained, and supported across the EU market.
Sarah began her career as a mechanical and process engineer before moving into OT security, eventually earning a PhD in security-by-design. Her research intersected directly with the early drafts of the CRA, which led to her appointment on the EU Commission’s CRA expert group. That first-hand involvement gives her a rare blend of technical and policy perspective on a piece of legislation that touches every device manufacturer.
As the conversation unfolds, we explore the friction between CRA’s security goals and the practical realities of embedded systems. From OTA update limitations to certification constraints, Sarah outlines the challenges manufacturers face and how they’re adapting. We dig into why “patch it fast” doesn’t scale in OT environments, and how CRA’s five-year support requirement forces companies to rethink lifecycle planning from the ground up.
The discussion also turns to SBOMs: what they are, why they matter, and the very real difficulty of generating them in legacy systems. Along the way, we touch on tooling, data quality, versioning, and the operational mess behind making software components traceable and auditable across complex supply chains.
Underlying it all is a simple message: CRA compliance isn’t about ticking boxes. Done right, it’s a path to stronger engineering practices, deeper supply chain accountability, and better product security. For anyone building secure, connected devices in a regulated world, this episode offers a practical guide to what’s coming and how to prepare.
Links
- EU Cyber Resilience Act - Official EU page on the Cyber Resilience Act
Transcript
Show/Hide Transcript
I know why people look at industrial controllers and say, well, this looks like, I mean, I once had 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 a PSA 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 doesn't love.
Right.
So.
And these things still work for 20 years and counting.
Welcome back to another episode of Nerding out with Viktor. 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 want to 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 into the European market, maybe let's start by giving people some backstory about yourself.
You've been in the tech world and kind of around this world for a while, so give people a kind of backstory so we can kind of shape the conversation, understand the context of where you're coming from.
Okay, well, I work in OT cybersecurity, so my background really is in engineering, not in cyber security.
I'm one of the persons that were first in engineering and then kind of took the direction into cyber as we say nowadays.
And I work for company, I'm the CTO of a company who does consulting in auto cybersecurity space.
And we, as the cto, 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'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 that was exactly the time when COA first came up.
So that's when I kind of stumbled upon coa.
I write a 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 CRA yet and just a draft came up and I read through this and really was drawn into that because I was like, oh, 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 my PhD.
So naturally I was intrigued.
Yeah, that's how it was how I came to cra.
And this year I was selected to be on the CRA expert group for the EU Commission.
And that of course is great because you get a close up on all the debates that are going on around cyber.
The Cyber Resilience Act.
I mean, there's a lot to unpack there, but I think people have been at least.
Well, I guess maybe for people who are not familiar with the OT world, maybe we stop by there.
Like what's ot?
I mean, people come.
I guess most my audience we're watching, they're from the it, cyber security space.
Ot, kind of a tangential industry with some overlap.
So maybe we can stop unpacking that before we dive into the.
Yeah, absolutely.
I have sympathy for everybody who doesn't know what OT is.
So that's fine.
When I started out in ot wasn't even a word.
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 translation is operation technology.
I also like to refer to it as the other technologies.
So everything is not it.
So it's basically.
And that's also how it came about.
It was an IT people term for this strange other technology that somehow also is our 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 a production plant or our energy grid or all these things are operated by ot, so by controllers, microcontrollers, programmable 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.
I guess if you do a Venn diagram there you have industrial Iot, which is kind of like a.
Which moves somewhat into that space as well.
Absolutely.
Yeah.
I guess it's murky what.
Where things belong, I suppose.
I guess.
Yeah, absolutely.
And I'm not a fan of really getting too much caught up in definitions on what belongs to OT and what doesn't because it doesn't really help.
Yeah, and.
And your PhD being secure by design in this OT world or this.
People who have had at least a Little bit of exposure to 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, cra I, as we will speak about in a moment will 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?
You mean security by design in general.
In the OT world?
I guess because that's.
It feels like security is 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 portals, that's a very.
IT person thing to say.
You know, it's actually.
Well, it's.
It's been one of the long conversations of IT people always saying, well, if OT could just do things like we've been doing then for 30 years, they would be fine.
And the thing is it 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.
That's always what bothered me about it when I first looked into IT responsible for security engineering when I started out in consulting.
And so I sat down and said, okay, what is security engineering?
And then I found out that IT people really have a very broad understanding of what engineer counts as engineering.
So if, 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, we do a drawing, we've got diagram, we've got a methodology to solve this, we do some calculations and then we've got couple of options how to solve this.
And then we engineer a solution and in it's more or less, well, here's your 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 chrystal ball 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 OT could just do things the same way.
Like we didn't know they can because I mean the things that are OT in there, they are surrounded by a lot of more technology.
And if you frog 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 you can.
And I think these are things so fundamental differences that people really need to understand before they judge about the other disciplines.
So it's the same for ot.
So they also like to sneer at it and say, well that's not really engineering.
It's not really that they change everything every day and it's not made for decades.
It's, it's going to be exchanged in five years anyway.
So it helps if you have a bit more respect from both sides towards the other side.
Actually that's a very fair point.
I mean, I think you said something here which is very interesting to me, which is the whole, the lifespan, the life cycle which is very like, if you're talking about like 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 kind of almost going back to the mainframe world analogy, right?
Like they were built for the long run.
Cloud workloads are ephemeral and they'll be replaced shortly, right?
So the, but this is really interesting, particularly if you talk about maintainability for a long time, right?
Zero trust in all these concepts.
They talk a lot about like how you are going to patch vulnerabilities and how you got to main do lifecycle management of these.
Like those concepts are very different in OT world, right?
How, how you do like package managers are not necessarily a thing at all in that world, right?
Software works differently in that world of times.
Yes, exactly.
And it's in every plant, in every industrial plant.
When you work around you find at least one person that says look, and this PLC 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 it managed to do that, I don't want to get advice from it how to do resilient systems, you know, because that's it's really, it's.
I get it.
I know why people look at industrial controllers and say, well, this looks like.
I mean, I once had 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 a PSA 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 doesn't love.
Right, so.
And these things still work for 20 years and counting.
Yeah, sorry, I was just going to say, like, how.
Do you view.
I mean, OTA being something that is kind of expected in the modern era of IOT and IIoT.
Right.
That's not necessarily something that fits in traditional worldviews 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 in your world?
Because I guess that's the segue into cra, which is very 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 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.
Doesn't work.
So if there's a Windows patch day and then next week there's the next Windows patch day, then that's something that drives engineers crazy in plants like that.
But still, of course there is things like IT and OT convergence.
Of course there is more and more commercial off the shelf technology and more normal IT technology being used in OT as well.
I mean, at the end of the day, most control system servers are run on Windows, so it's not like we're immune against any of these things.
But still, if you.
Patching in general needs a different approach in ot because oftentimes you lose warranties or liabilities.
If you just patch control systems, for example, you can't just put a patch on there because then the control system vendor says, okay, 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 there really comes a.
Or someone else or 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 is a process that can take months.
So it's not as easy as saying, okay, 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 okay, we're supposed to deliver products without exploitable 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 standstills just because there is a patch and then we need to recertify for example.
Yeah, because it's complete polar opposite needs.
Right.
Because I mean modern software kind of assumes that you can do this stuff but then there are.
That's right, yeah.
You kind of in particular if you're using a bad example like the JavaScript world where you're like, it just thinks like things will be, they have a six month life cycle then like this new library.
Isn't it kind of weird that we accept it as normal that you need to update software like five times a day?
I mean.
Oh yeah, it's kind of crazy.
You're absolutely right.
How has 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 like with looming pressure to be able to conduct these updates, there are completely bipolar requirements and the suppliers or the manufacturer of these devices, there must be a rock and hard place.
Right.
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.
Yeah, that's right.
It must be, that's very different from say software which is like updates.
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 okay, what really needs to be patched and what really is a risk because the risk on the other side.
So there's always, I mean the risk for don't patch 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, if in 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 the intended purpose is.
So I can say, okay, 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 not like to use a cloud.
You don't have a staging nuclear facility where you can just run your tests and then you.
Right, so if you brought that up, then it doesn't matter that much.
Exactly.
So things just don't work that way in ot.
That's right, yeah.
Yeah.
So it's very different the world, but.
All right, so we kind of have worked.
We mentioned our CRA multiple times and maybe you became a much more domain expert than myself in this domain.
What's a cra?
Let's give people assume.
People do not know what it is.
Assume that you're a company selling in hardware into European market and you have never heard of this, which I literally had a conversation this week with.
Well, last week, sorry.
With a vendor that have no idea about this stuff.
And a lot of people still, even though ratification is starting next year, are very unaware what this even means to them.
Right, so let's start there.
You're a vendor selling into 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.
Let's sink in a bit and to swallow because how can they even prohibit me from selling products?
But yes, they can and they can based on 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, that's a, C and E, and I've probably seen that before.
And let's say, 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 they don't have the protection, they assume they have the protection, then they can hurt their eyes.
So that's why there is a CD marking order on these sunglasses.
And that's.
And the 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 a CE marking gets applied on pretty much everything you have on your desk.
So on every digital product.
So from smartphones and laptops and pretty much everything.
Bluetooth.
So like even that one?
Yeah, well.
Well, then maybe that as well.
Yeah.
So there's going to be a CE marking on that and the CE marking is going to mean it's in conformity with all the European Union regulation, including the Cyber Resilience Act.
So you spent a lot of time doing advisory work with companies and in your consulting work you now need to conform.
So that's clear.
But what does that actually mean?
If you're selling?
The terminology is device, but I'm forgetting.
The product with digital elements.
That's exactly.
You're selling, probably, 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're not going to sell it.
All right.
Where do I start to even become compliant as a vendor?
Yeah.
So obviously, first step is, as a vendor, see which of your products actually need to be compliant.
There are some categories of important and critical products that have some stricter not requirements, but a stricter requirements for proving the conformity.
The requirements are the same for all.
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 Annex 1, 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.
They're worded very broadly.
So there are things like integrity protection or make sure the personal data is protected.
So nothing that comes as a surprise for a security person, to be honest.
And then the second part is about vulnerability handling because 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 this UV protection for example, and then you're done.
Unless you find a mistake in your production and, or something.
But that's really not that often.
But in 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 meet 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 lifespan is.
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 unpack there.
Right.
For the first one is five years.
And that is even if you have a product today with existing SKU and that's placed in 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 manufacturing and I'm placing that in the market today and I'm selling that today with an existing sku, does a 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 grasp also because it has a lot of legal deep dives you could do and say okay, 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 manufacturers 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, see how it doesn't apply now, but if you buy a laptop on the 1st of January 2028, then it has five years of support period and that ends on the 1st of January 2033.
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's sold.
This is extremely complicated in supply chain because you as a manufacturer do not control your entire supply chain per se.
You might have sold it to a distributor who sit on these for three years and then they finally sell them.
But you as a manufacturer still obligated to support it when it gets to the hand of the customer.
No, no you're not.
No, you're not.
No, you're not.
Because that could be.
Would be impossible for manufacturers to control as you.
Right.
So you as a manufacturer, you're obliged to support the product for the five years or whatever the support period is starting when you sell it to a distributor.
So if it sits as a distributor serves for five years, then theoretically you could buy a product as an end customer that doesn't have any support anymore.
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.
On that first.
Because otherwise there's no way for the manufacturers to know.
That was kind of my point.
Right.
Because then you have like essentially infinite life cycle for a given device which.
Is not relative 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 manufacturers deal with it.
So when I discuss that, the most likely case is that I say, okay, we just have an end of support date and the first product that we sell, if someone sells, buys it earlier, then they just get longer support, but the guaranteed support is just five years.
And then so that you don't have to maintain multiple support end dates for the same type of product, but different instances because you're getting crazy administrating there.
Yeah, yeah, exactly.
And that's.
Yeah, it gets really difficult.
And also.
So now let's talk about what that actually means to make sure you provide security updates for all these devices that you send.
Because we talk about vulnerabilities and patching all those things.
It's not really a solved problem today to do like.
There's no 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. I don't know, 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 OTA and updates.
How, I mean, how do you expect this kind of change the landscape really?
Because it does.
You can't really expect people walk around with USB stick and update things.
Right?
That's not really.
Well, and then an ot, the thing really is CRA doesn't prescribe how updates are to be rolled out.
So I know that in other legislations, I think also for automotive, there are requirements to do it over the air.
There's no such requirement in the cra.
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 them turned on is great for consumer devices unless the consumer chooses not to connect them to the Internet, which is sometimes security advice.
So then you have this conflicting advice of do 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 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 changed and certifications and doing that automatically is even worse.
So we do have a lot of industrial manufacturers as customers who 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.
And sometimes even 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 the devices.
So that is completely normal.
Yeah, it's a very different world.
It is a different world.
Yes, it is.
I think it's hard not to move on to SBOMs from here, I guess.
Which is.
The litmus test for if you know your software supply Chain.
I've had Alan Friedman on the show, I had Steve Springett on the show and had a bunch of people in the S bomb world who've spoken about this.
I guess if people really want to know about SBOMs, they should probably go back and watch those episodes.
But.
But what?
I'm.
I assume people do know what an SBOM is by now and people who are watching this from your side of the world, like in your side of the world in the sense of the OT world.
Building sboms for a Python application or a Rust application is fairly straightforward.
Doing that for the embedded world, very different problem space.
Right.
I co led one of the CIS like working groups for SBOM generation with the guy from Lockheed and they are now trying to figure out how to do S bombs 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 have you seen there in.
In people's journey to try to generate SBoMS for what generally we call legacy systems.
Right?
Yeah.
I mean probably you have a lot of more hands on experience on that.
I would be really interested in what your experience on generating embedded SBoM is.
I think the first thing is that people start to realize that they need to do their SBOM at all.
Because I mean it's the first time there really is a requirement to have an SBoM.
And a lot of discussions that I see are first based around, okay, we create that SBoM.
I mean, they're not obliged by the CRA to also share it with their customers.
But of course many customers would like to have it because they themselves are also coa regulated.
So if they use the product 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 vulnerabilities.
So why would we even share it?
I would be interested in your opinion on that actually.
What's in there?
This is a conversation I've had many times and a lot of opinions either side.
Right.
Is an SBOM good to be shared publicly?
The answer is it depends.
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.
Difficult.
Right.
But I think the sharing side of it is something that I will see if the appetite 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, but that means that regardless how you generated set S bomb 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 CISA Sharing Primer, which I'm sure you've read as well for SBoM, the share primer that was written a few years ago.
It's not a solved problem.
People don't actually do it properly.
Like I've spoken with so many CISOs and they're like, yeah, I get as mess bombs, I chucked them at SharePoint and that's it.
And so the lifecycle of things is a problem that I'm passionate about, like trying to solve myself because I think that's a big problem.
Like, 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 discovered when we started doing S boms in the real world is that in a real product, you're not going to have one S bomb.
Like you got to have 10, 15 different S BOMs for different parts of your product.
Because a product is a composition of multiple components and when you start to release things, you might use four of these, but this component changed.
But the top level ASP is now different.
Right.
So the release management is becoming much more difficult to do and shamed off self plug.
That's what we saw with Spamify.
But that's kind of the, that's the hard part really.
Right.
It's like how you do that scale.
Because if your top level obligation is that you need to provide an SBOM for a product of a given version, you need to have in four years from now be able to say, oh, version 4.3.2 had these SBOMs.
Right.
And that's the tricky part.
Yeah.
And then also I think that the, of course there's a requirement to have an SBOM period, but in the end just having an SBOM doesn't help you at all.
So you need to be able to do something with it.
And that's where a lot of conversation starts also industrial sector and I Believe everywhere because people say, okay, now if I have that SBoM, now what?
Because if now a vulnerability comes up, I would expect my SBOM to quickly tell me am I affected or am I not affected.
But for that you need not just an SBoM, you also need to be, need to have the vulnerability reporting in a format that actually corresponds to your SBOM format.
And that's also one of the big things we're talking about.
So here, at least in Europe and in the industrial space, the German BSI also supports it.
There's a lot of discussion about csof.
So a machine readable vulnerability sharing format.
So where you say okay, 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 SBOM 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 BOM 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 it's.
I think there's one even equally important point here which is garbage in, garbage out, right?
Like the quality of your S bum ultimately determines how useful it is.
And I think that's.
A lot of people have gone through the motion to generate S bombs just to tick the regulatory requirements.
But I think, and actually I'm curious about your thoughts on that because unlike say NTIA minimum amount or CISA minimum element, now that's in draft, the cis, sorry, the CRA doesn't explicitly state what the SBOM should look like.
Right?
It doesn't MTA element and system, they go into very specific details.
It should capture this data.
It should capture this data.
But CRA is much more vague on what that needs to capture.
Right.
They are thinking about.
So the European Commission is, are actually thinking about releasing some more guidance on what it should look like also because to achieve some kind of harmonization of how S BOMs look like across different products.
There's currently actually a study carried out by NISA requesting industry to submit all manufacturers in general to submit what they are currently doing regarding S BOMs 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 SBOM 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.
I really think if manufacturers are worried about unrealistic ASPOM 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, I think the CISA and NTIA minimum elements are pretty good, right?
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 code led.
Right.
And the answer is yes, it is rather challenging to do it.
It can be done, but it's a 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, relatively straightforward.
Doing it for embedded C code, a lot more challenging.
Right?
That's the problem because many of these things are always tested in like, okay, let's take just the most basic thing that we have and test it and then it works fine.
And then all the other product manufacturers come and say, well, but our product isn't that simple so we don't have to stand our 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 CRA debate, but it's a good slot in way of bringing something that at least you can work with as a package rather than just a file you copy and run, which is traditional speaking.
How, 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 are you possibly going to do a CV scan about.
I guess you could do static code analysis but it's, it gets a lot more murky.
Right, but what have you seen on that side?
Like what, how when you advising companies, I'd imagine a lot of them do have large legacy code basis, right?
Much of it is I would imagine, given OT being C code, I would imagine, right?
How, how are they reacting to this?
Like are they like, oh, we gotta solve this or like are they trying to put their head in the sand and Just try to ignore the problem altogether.
Well, they.
At least what I can.
What I see, there's always the prejudice that manufacturers are just sitting it out and not doing anything and things like that.
At least that might be biased because people I work with obviously care about CRA and are aware of cra, 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 cybersecurity, often furthering projects they've been trying to promote for years and now they have a reason to do that.
So I mean, an S. BOM isn't if done right, I mean, it's not just a compliance thing to do.
It's something that you do and then tick off the box and then file aside.
But it's also something that really helps you doing software quality, doing version management, doing dependency management, all 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, yeah, no, that's okay.
No, I was just gonna say to me, an SBOM is just a good litmus test of what, you know, do you.
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 SBOM is like you can't measure completeness because you.
That's an impossible thing to state that it's complete because how do you know?
But, but it's.
And then CRA 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 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 I.
It becomes a good.
Like once you start generating these and you can start utility, then you can start using SBoM for operational decisions.
Right.
You get to a 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 I have some open source libraries that breaches my contractual obligation with my other things?
Right.
Those are things now you can start doing.
And that gets even more complicated.
It's so often the case in cybersecurity that in order to do cybersecurity well, you do need to do all the quality things and documentation things that shouldn't be cybersecurity's job, but they are because nobody did it before.
And I think that's the same with SBOMs.
And I see a lot of parallels in the entire risk assessment discussion that we're having around cra because that's kind of the same like for an S pump.
There are a lot of analogies there.
You can do an SBOM just to check off the box and then you have the SBOM 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 CRA says you need to do a risk assessment.
You can just do a risk assessment, find 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 CRA 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 improving my security posture.
And then the compliance just pops out in the end.
Because I think that's what the great thing about CRA is.
There wasn't any critical debate on the requirements in cra.
It's like the wish list for every cybersecurity practitioner in the world.
I mean, it's risk based.
There's an SBoM requirement, there's all the cybersecurity basics, there's vulnerability 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 cyber CRA compliance on the way.
That is entirely possible.
Yeah.
I mean, to me it's very clear the direction we're heading.
Right.
Like sboms will come at least if I were to hypothesize a core requirement in almost any compliance framework going forward.
Right.
Like CRA kind of leading the way.
A PCI DS has 4.0 starts asking for software inventory, which is just s bom codified.
Right.
And I mean, I would be surprised if SOC2, when the next update comes around, doesn't ask for S bomb.
Same with ISO.
Right.
I expect them to follow.
Right.
And that's, that becomes a universal litmus test in A way.
But I think there are some interesting.
And also, I mean, if you have a software manufacturer who's not able to draw up an S bomb, then you should raise serious questions about how they actually code desktop software.
Right.
So that's.
Yes, but 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's, it just wasn't a requirement.
It's kind of new.
But every developer who strives to good quality code should get excited about that.
Oh yeah, no, I, I guess my only comment on that is that sometimes you depend on other vendors who do not.
That's true.
And that's where it's tricky.
Like you might want to do the best.
But then here's the great thing about cra.
All your vendors fall under CRA as well.
So they need to have an SBOM as well.
And that's also one thing that I see currently in the industry.
That's why I asked about sharing your opinion on sharing SBOMs, because people know that all manufacturers have to draw up the SBOM anyway.
They start requesting it from their manufacturers in turn because they say, well, you're obligated, obliged to do that anyway, so why don't you share it with us?
And there's always.
I think CRA 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 SBoM for risk assessment, for vulnerabilities, for all these kind of information that kind of people had to beg 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 to unpack there because I think there are.
Is how you share.
Right, Right.
I mean, you mentioned already like what.
How much should you share?
What's like.
Because that's an open debate.
Like 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 Run sharing is he's how we automate that scale.
Right.
So I'm, I'm working with probably called Transparency Exchange API under Cyclone dx where we try to like standardize the way you discover S pumps and security 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, you need to be able to discover their SBOMs in a programmatic way.
You can't just go and say, oh, we just cut the new release which requires a new version of this.
Email me your sbom.
Like, it doesn't work.
It needs to be an automated process that's fully like, oh, I'm requiring this version of your product.
Now give me the SBOM for that version of that product.
Right.
And that's.
Right.
And that's also one of the really smart things 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, 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 weakens the open source community because manufacturers say 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 worm.
That is probably words, its own episode, I think.
Because I think that is.
There's a lot to talk about there, right?
Because absolutely, yes.
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 CRA fangirl.
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 or 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 did is they just use the open source components because they were free, but they didn't really contribute anything.
They didn't really take responsibility for the components we're using 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 obviously 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, it brings all of these conversations out in the open.
Yeah, no, I, I, I mean I am generally speaking optimistic about cra.
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.
Right.
If there, if nothing has changed, if nothing will change, we will still having 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.
Right.
So like I'm not, like, I'm not favor of doing heavy handed regulation, but I'm also painstakingly, I think it's basically obvious that something gotta change for us to actually make it make a difference.
Me neither.
And I think I, in an ideal world we didn't need any of those.
So in the deal 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 of our critical infrastructure 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 cyber security and to live up to minimum standards and things like that.
So I think it's a bit of putting a bit tilted version of regulation more upright because now manufacturers also have to do their part.
Yeah, and I mean it definitely, I mean I, I've dealt with a 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, and I think that has put generally speaking a disadvantage for western tech companies.
In general particular, if you look at like, I mean, baby camera is a good example of something like that.
Like where it's usually like the cheapest one is the one who sells the most because people don't really, the average buyer can't tell the difference.
Right.
And security is so hard to communicate and so hard to grasp.
Right?
Yes, exactly.
Like they're 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 also a lot of people who say, no, I don't use that baby cam on the phone at all because it sure is unsecure.
And that's also not great.
So.
Right.
So finding like a middle ground where we say, okay, we make it transparent what kind of security should be there.
So that is something that people that, who care can request and can take a look at.
And also some others that don't, don't give a, 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 at a disadvantage.
But that's not true, actually.
COA puts them at an advantage because at least if they're holding up to higher security standards, because CRA doesn't just apply to European manufacturers, but to all manufacturers who sell to Europe.
I mean, I, it all comes down to at the end of the 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 the car.
I mean, Germany was starting one, the first one to actually put their drafts together.
Right.
For, for how actually the law is going to look like was not that surprising.
Now, now once we enter the actual time window for like where to enforce and it's then going to come down to will this actually be enforced?
Right.
Because if it will not be enforced and there will not be any examples made out of this, then no vendor is going to actually carry them.
Right.
And that's going to be the tricky part at the end, like 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, okay, when are like early market surveillance authorities knocking on our door and trying to probe products?
And of course that can happen, but that's not the most likely case.
What they 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 file non 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 okay, if they really find something that puts the product at non conformity with the cra, there's actually a tool for market authorities that 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, but the fines are not high enough.
But it's not about the fines, it's about not being able to place a product on the market.
That's the highest fine you can get.
Yeah, I guess my worry I guess is some extent which is voiced by it.
It's like 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 those, in the, in between.
I guess like, I guess there are lost com, there's a lot of pr, right?
Could happen, yes, but then at least you got to start somewhere.
So you better start these five years of doing nothing now.
That's fair enough.
The last thing I wanted to kind of like wrap up here about is talking about like communicating vulnerabilities because that's a big part of the CRA is like how do you communicate vulnerabilities?
And, and there are, I mean anybody who works cyber security, often it's like the CVE process and how that works as flawed or it may or may not be.
That's, that's a different debate altogether.
But communicating that both to consumers and, and the EU side of that, like how, walk me through the, the requirements for the CVE side of ec.
Like how does that look like?
And, and what does it look like for a manufacturer who's bringing something to the market?
Like what does that look like?
Because the CV for us is very different.
Can be fit in I suppose.
But most vendors are not familiar with the CV management side of things.
So what does the vulnerability communication look like?
Is that your question or.
No, my question is more like if you're a manager manufacturer selling it to the market and if you're a small manufacturer you have probably never have to dealt with cvs.
Right.
Or you probably dealt with them in your supply chain.
But you've never been had series issued against you.
So you are not familiar with the process around that when you're entering the market.
Disclosure and all these kind of things.
Exactly, yes.
So I mean 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 worded not that great in the cra.
I think there are exploitable vulnerabilities.
These are the things that must not be in your product.
And if exploitable vulnerability is in your product and you must stop selling it, then there are the actively exploited vulnerabilities.
This really is more like a security incident.
So it's really something has happened to your product or somebody has actually exploited something.
So it's not just a vulnerability, it's more like really a insecurity incident.
And for the latter, manufacturers have to report them actually to authorities, to ANISA and to the national CSERTs or National Certs.
And for the former they have to, well, they have to scan for all 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.
Exploitable for their products, on the circumstances and for those.
Well, that's basically the normal responsible 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 have security advisories, all these kind of things.
And you also have to have kind of a contact point where people can approach you about vulnerabilities.
That's the responsible disclosure.
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 down your way of big pile of vulnerabilities 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.
Some of us run vulnerability programs.
I think a lot of people underestimate the workload that comes from managing a vulnerability program with responsible disclosures in particular.
Now, now in the day of AI, I mean, I can see in one of my coworkers with Screenly, we get so many vulnerability disclosures every day.
Right.
Okay, you need to deal with all of those like, yeah, the problem.
Is the signal to noise ratio, right.
Because yes, you might get 100 reports and 99 of them are just AI filings essentially.
But there might be a super severe one.
That's exactly what I mean.
So like an 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 formal reporting, well fine, there's a reporting for reporting portal going to be and you need to find a report there.
That's fine.
So that's all things that are doable about really managing this influx of information.
That's the hardest part.
I think the triaging is the hard part.
Finding signals and noise.
That's.
I think that's the hard part.
Finding a way to actually, I think an efficient way to define for yourself what an exploitable vulnerability is.
So that, and making that decision to what needs to be patched and what doesn't and then communicating that well, yes.
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 I think CISA also does it using mitre, ATT and CK for example, saying okay, this refers to these mitre, ATT and CK techniques and this is what we recommend you to do.
So 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 in particular with.
Well, I don't know where we stand right now which is vulnerability databases and where, but yeah, like, nonetheless, like having a global one that is non US centric is probably a healthy balance I guess as well.
The European Union has also, NISA has also published its own.
Yeah, euvd.
So yes, it's not really a known database but it's an own display of the information.
They're not collecting their own information.
But that again that is not the most important part.
Similar to managing vulnerabilities, 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 and find a process to manage that at the same time.
I think that's what's behind the CVE 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 do 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 high alert firing like the other week saying like super high vulnerability.
Then you're like on this package and you're like well we're using this package but it's a completely different ecosystem.
It just happens to have the same name.
It's just like this for a bit was like a Java package and we had like a Python package but like they had the same name.
Isn't that something that AI could somehow solve?
I mean finding duplicates or something like that.
You would think maybe we'll get there one day but I mean at least people started using them more and more right.
And that's going to help building up these tools and make them better and making the data sets better and more useful.
So no, this hopefully will a better place in a year from now and when things are starting to shape up.
So Sarah, we're coming up at the top of the hour here.
What would you like to say to people that are getting into this?
Like last final words for people who are looking into getting the CRA cards sorted?
Any final words of where they need to.
Yeah, get in touch with you or what, what's your advice?
Well what I always advise them to take is 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 right in the beginning really run your products high level through this CRA requirements.
Don't wait for any harmonized standard.
Take the CRA requirements and see where you might have major showstoppers and work on those because these are the things that are going to take time.
And then second start doing the risk assessment because that really is the 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.
Cheers.
Thank you for having me.
It was lot fun.
Found an error or typo? File PR against this file or the transcript.