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.
SBOMs & CRA Compliance with Olle Johansson and Anthony Harrison
Play On
24 MAR • 2026
1 hr 21 min
Share:
What happens when cybersecurity stops being an afterthought and becomes a legal obligation? In this episode of Nerding Out with Viktor, I’m joined by Olle Johansson, CycloneDX member and lead of the Transparency Exchange API, and Anthony Harrison, a UK-based software supply chain security consultant and open source SBOM tooling author, to explore how SBOMs, the Cyber Resilience Act, and the Product Liability Directive are reshaping how secure products are designed, maintained, and brought to market.
Both guests come from hands-on engineering backgrounds. Olle built open source telephony systems that ended up in critical infrastructure - air traffic control, emergency services, elevators - and now works on TC54 standardization and the Transparency Exchange API within CycloneDX. Anthony moved from building complex systems into focusing on software supply chain risk, running his own consultancy and contributing open source SBOM tools. Together they co-founded SBOM Europe, a community effort to improve software transparency practices across the continent. Incidents like Log4j and SolarWinds were turning points - not just because of the vulnerabilities themselves, but because the industry couldn’t quickly answer a basic question: where are we exposed? That gap is what SBOMs are meant to close.
We unpack how CRA differs from NIS2 and DORA, and why that distinction matters. CRA targets products placed on the market, while NIS2 is a directive implemented differently across member states. The new Product Liability Directive now includes software for the first time, meaning manufacturers face real consequences if their products cause harm. Liability follows the integrator - if you ship firmware, hardware, or open source components, you own the whole stack. Unlike traditional CE marking, which is a one-time checklist, CRA demands ongoing process compliance: risk analysis, threat modeling, and maintenance for the entire declared product lifetime. The upcoming EU Omnibus proposal aims to simplify this cross-border regulatory patchwork, but for now, compliance is less about submitting a perfect document and more about building processes that demonstrate due diligence.
The conversation also turns to what this means for engineering teams day to day. SBOM tooling is inconsistent - the practical advice is to never rely on a single tool, since different tools produce different dependency counts for the same codebase. Anthony discusses the UK’s Software Security Code of Practice and its limitation as a voluntary framework without enforcement teeth. Olle raises the looming challenge of post-quantum cryptography, arguing that products need crypto agility - the ability to swap cryptographic engines during a product’s lifetime - which most companies have not considered. AI can improve code quality and auditing, but it risks eroding the deep engineering knowledge needed when automated tools fall short. Security can no longer be a late-stage checkbox - it has to be built into product development from the start.
One principle anchors the discussion: any SBOM is better than no SBOM. Perfection is not the expectation. Demonstrable effort is. For founders, embedded engineers, and product teams navigating the new regulatory landscape, this episode offers a practical look at what CRA compliance actually demands and where to start.
Links
Transcript
Show/Hide Transcript
I'm not a fan of legislation in general, but security and supply chain security at large is a market failure, no doubt.
Right.
Because that will not be solved without legal pushbacks from the government bodies right there.
No way.
If I operated a commercial company, I can clearly see that investment in cyber security didn't give me more market share or more Morgans.
But because customers have no knowledge, they don't require it, but they require new cool features, I focus on new features.
Welcome back to another episode of Nerding with Victor.
Today I'm joined by Ole and Anthony who are definitely a big names in the European SBOM world.
So welcome Ole and Anthony.
Thank you, thank you.
I mean we've been running in the same circles quite a while right now.
Ola, you are leading up the Transparent Exchange API.
So I see your face every other week at least on the meetings there.
And Anthony, anything that's SBOM related, I tend to see your name as well.
So you guys are very much, highly in the S world.
But for those not familiar with you guys, I'll let you start off with giving a quick introduction to yourself.
Well, I'm a gardener living in Solentuna, Sweden, but in my spare time I. I do a lot of stuff related to the Cyber Resilience act and software transparency.
I'm a member of Cyclone DX.
As you pointed out, we're working TC54 to standardize software transparency with S BOMs, the Cyclone DX format, the CLE format and many others.
I'm also engaged in ORC, VG on CRA related issues and OpenSSF.
Good stuff.
Thanks Ola.
Anthony, you want to do a quick pitch about what you're doing and who you are?
Yeah.
Okay.
So I'm Anthony Harrison from the uk.
So looking outside the EU and the regulations that are changing weekly as we all got to talk about.
So yeah, I've got a background in building complex systems and now I run my own business which is looking at the software supply chain and the software risk about developing software.
And I write one or two open source software tools in the SBOM space which seems to get some traction which is always very nice, very cool.
So it wasn't clear there's going to be an episode on SBoM.
We've done more than we basically had.
Anybody who's anything in the SBOM world except, well, I can think of a few names that I still should get on there.
But most people that are in the SBOM world have been on the podcast before.
But this is essentially a follow up to the episode with Sarah Fluchs on CRA and thesis for this episode and what I want to cover in this episode is really all things in the surrounding universe of CRA.
Right.
Because CRA is a big thing.
But CRA kind of talks about a lot of other things and it's kind of one piece in a bigger puzzle. And.
Ooh.
There are, I mean, just to name a few.
Like there is NIST 2, there is Dora.
Where do you guys want to start to unpack this whole complex web of acronyms?
I'm not a lawyer and I have a history and being a consultant.
So when I started studying this, I realized that there was a few people in the Euro saying that the EU is leading in regulation.
Yeah.
Surprised me.
I didn't know there was a world championship going on and I don't know, I haven't seen that.
I haven't seen that.
But it is a complex world and the more years time you spend it on it, both the process within eu, which is confusing when you start.
I followed the CRA through all the hoops and mistakes until it became an active act to say.
But as you say, the whole regulation landscape can be confusing.
There are so much happening and there's an organization called Open Forum Europe that tries to follow this and inform us in the open source world.
Because we haven't really paid much attention until the CRA.
No.
When the first proposal CRA came, we realized that we had to engage and the commission were a bit surprised because we came late into the game.
All the other mayor players had lobbyists in Brussels, open source.
We didn't have the money, we didn't have the people, but we changed that by working together.
And I think that's amazing.
But that also means that we're constantly now looking into the regulation landscape.
And I can't say I follow all the details, but there is a lot of things happening.
Yeah.
And I think we can sort of see, you know, the US started taking an interest, shall we say back 2021, because of things like solar winds and obviously because of where solar winds hit, then people started realizing software and systems are very complex, it's very intertwined and that transparency wasn't visible.
And then when you now start looking at, you know, our critical systems that we have in many countries, you know, our utilities or finance systems, etc, any one of those, any weaknesses in any one of those could have, you know, catastrophic effects on society.
So actually having that greater visibility is, is desirable for everybody to manage that Risk?
Yeah.
I mean going back, I would say that much of this work started with log 4J and SolarWinds.
I, I, when I do trainings, when I do talks, I quite often start with log 4j.
And the cost for society to find out if we had log 4J in our systems, not mitigation, not cost for the cybercrime caused by this bug, but the cost of finding out.
I mean, I myself was called into the office on a Sunday to go through systems and check for this.
A consultant on a Sunday, that's not cheap business.
And were many consultants and employees in the office and the number of mail we got being engaged as open source developers from users, I mean the cost of that was too high.
But going back to the starting point for CRA, the commission says the cost for society for all these cybercrimes is way too high and it's time to fix this and the open free market can't fix this by itself.
Yeah, I think that's so important to stress because I think to me, and I've said this on previous episodes, right, I'm not a fan of legislation in general, but security and supply chain security at large is a market failure, no doubt.
Right.
Because that will not be solved without legal pushbacks from the government bodies.
Right.
There's no way.
If I operate at a commercial company, I can clearly see that investment in cybersecurity didn't give me more market share or more Morgans because customers have no knowledge, they don't require it, but they require new cool features.
I focus on new features.
And the commission clearly says in the CRA that for a while now, vendors need to focus on security.
And I think that goes across all of their legislation that we need to focus on this and lower the cost for society.
They also say that, well, we acknowledge that prices for products will go up because we're basically changing model for vendors, right, Both with these two and with CRA.
But long term, the cost for all of us will go down.
And I think that's important to remember when we look at this, that they realize that the vendors are doing the right thing from their point of view.
And the only way to change the focus and protect society is legislation.
But I think that's interesting because I think everybody assumes engineers, and we're all engineers really, we practice, we know the, we know what we should be doing, so we do it.
But clearly we're not doing it well enough and the evidence isn't there.
So therefore the regulation comes along to try and sort of, you know, demonstrate your behaviors rather than just saying trust you, trust you're doing the right job.
Because I think too many times we just relied on people to do the right thing without telling them what's what that benchmark is.
Yeah, and that's okay.
That's why this.
Let's have a debate.
But yeah, it is the issue.
I think everybody knows what.
And then a good engineer knows how to write good code, good systems.
But there's plenty of engineers that don't do that if they can get away with doing it because they don't have to.
But this.
Yeah, yeah,
The process that doesn't really work in many projects I've been involved with as a consultant that the developers, they know their stuff, they can do secure software, but the priorities are different.
So when we do our scrum meetings and set the priorities, the product manager puts everything about security so far down the list.
Had one product manager found out how to delete tickets in the.
The ticket system.
So they didn't show up on the proof.
So I think this, when I talked with the developers, because I had to go through security for a product they knew very well, but the product marketing and management, they prioritized otherwise.
Yeah, I mean, it's funny, I. I was on a podcast yesterday and we talk about security, and to me, security is culture.
And culture starts from the top.
And essentially security culture is.
And I like to use this litmus stuff for security culture, which is security culture is what happens when nobody's looking.
Right.
That's what your engineers do when nobody's watching over their shoulders.
Right.
A good testament to good security culture is that they write secure code file best practices.
And that overhead that you're referring to, Ola, which is very true, is just expected.
It's expected that you do not cut those corners.
And that is the litmus test for good security culture.
Right?
Yeah.
The problem now we have legislation coming in December 2027, and there's a lot of things that needs to happen, and it's very short time.
But that's considering the technology path.
We have to fix the code, we have to fix the response, we have to fix security issues, we have to add encryption, all that.
But changing how the company people think and prioritize, that will take much more time.
And that's going to be the problem with all of this.
That culture is a lot slower than code.
And if things are not mandated, it doesn't get done.
Because, you know, if you can do shortcuts, People will do shortcuts.
You know, we all want to get paid and if we can get paid quicker for not doing stuff that's not required, we will, we won't do it.
And that's, you know, for us to have the right behavior, which ultimately I think is.
The EU is trying to do with CRA and this and Dora, et cetera.
It is trying to make sure how people have a consistent behavior.
And we saw that with GDPR 10 years ago.
Let's look at personal data.
So I think everybody knew what they should be doing, but nobody was doing it quite rightly or consistently.
So this is probably similar where we are with cyber and we know what we should be doing, we know what the consequences are.
But are we doing it correctly?
And does everybody understand the consequences of not doing it?
Which then brings things like accountability, which brings the organizational culture into that is, you know, you're going to get.
Some organizations are going to fast them fast and loose, some are going to be very rigorous.
How do we get everything aligned.
But if we move back from this array, which of course is a favorite topic and look at, there's a whole umbrella and you mentioned Denise 2 directive NISTU is a directive.
CRA is an act.
An act is a law in all member countries at the same time.
Nice2 has to be implemented in each and every member country.
So they can make variants.
They're allowed to make variants and change it a little bit since Sweden, we got our variant in January 15 this year were late, very late.
And the problem is if you're a company that works in multiple, I mean countries, it's hard to say that you're these two compatible because it can be different.
Now the EU is publishing something called the Omnibus.
Well, it will try to change that.
So if you're operating multiple countries, you can operate with an ESA instead of the country level.
But, but they're making it a bit more easy to handle.
But Nistu is interesting because that's for critical services in the society.
You have aerospace, universities and many other sectors, food, everything that's critical in society needs to have resilience.
They need to have cyber security and they need to control the software supply chain.
The regulation doesn't say S bond but if you read it's very clear that you need S bonds and you need due diligence.
You need control of stuff.
There is also needs to.
For the IT sector.
Everyone that delivers services over a certain size is affected.
So if you're a Software as a service company only you will be affected by these two and how to follow that.
And the interesting thing with these two is that law points directly to the management.
The management will be responsible.
The management has to prove that.
Cyber security training and in Sweden they even added that if there's a problem, you not only get fines, but.
But the CEO can be banned from being a CEO for a number of years within the company register.
Interesting.
It's very personal, Denise, to CRA isn't.
Yeah.
There's a lot to unpack here.
So one thing is CRA needs to.
Let's do a Venn diagram.
Right.
What's the overlap?
If you need to do one, how much do you cover off the other?
Because I think that's a lot confusion.
I mean, even to myself.
Like it's like it's not a do this and you've done.
Right.
Because you need to wrap your head around a lot of different frameworks that.
Yeah, there are Venn diagrams.
They're not like the same.
Right.
So talk to me about how you guys see that and like path towards compliance really.
Well, it's kind of interesting.
CRAy is a product legislation.
Primarily it is software or hardware.
With software, you sell something with a digital connection to a network.
Doesn't have to be the Internet.
A network.
Right.
And we already have the.
The radio directive that got a delegated act in August last year that required cyber security.
And that part will be replaced by the CRA later on.
But the CRA involves remote data processing.
So if your product requires some cloud service, that cloud service is affected by the CRA.
And if you're large enough, that cloud service is also, I would say, regulated by these two.
And if you're a bank or insurance company, that cloud service, the backend systems, is regulated by DORA all around.
But many companies, when I've been out talking about this, say, oh, we're a car manufacturer, we're not affected.
And I look at my phone and say, I have an app from you because I'm renting car when I travel.
So I have many apps.
That app is not regulated as a car with four wheels and an engine.
So.
And you need to do your homework.
Yeah, I guess my angle was more if you follow one of these guidelines, let's say hypothetically, you are CRA compliant, which is not quite a thing because again, like BSI got their implementation of cri, so it's like it's not quite that simple.
Right.
But let's say hypothetically you were to Be compliant with whatever that means.
How much is covered, how much of that will make you covered by NIST2 or Dora?
I think they're coming from slightly different things because obviously I think dora's coming from a sector perspective, the financial market.
This is coming from the criticality of services to society and CRA is coming from product.
So they're all very, they're all looking at.
There is a common problem which is how, you know, cyber security is one of the, you know, a horizontal thing that goes across all three.
Yeah.
And organization goes across all of them as well because of who's, you know, who's insuring them for the governance.
Yeah.
But actually what they're trying to achieve and how they achieve it are very different.
No, but if we sandbox just a cyber security component of these compliant compliance networks.
NIECE is the old kid on the block.
Right.
We had knees that still haven't really got implementation guidelines for all sectors.
In Sweden, the, the legislators didn't.
The authorities didn't understand it or didn't get resources.
I don't know really what was problem was and was replaced by niece too.
They're trying to align all of this.
On top of it all is an umbrella act.
And this is getting more and more fun.
The Cyber Security act which is updated now they're updating things to make it the puzzle fit better.
Right, right.
And simplify because needs to hit very small companies doing some IT services like DNS hosting, which I mean would just be stupid.
But the Cyber Security act is what authorized anisa.
NISA got the resources of the Cyber Security from the Cyber Security Act.
It also stipulated the certification for that applies to many of these.
If you're in an area that needs a certification, you have a high degree of criticality.
But they're updating the Cybersecurity act as well.
And an interesting little directive that runs on the side is the Product Liability Directive.
Have you heard about that?
I have not heard about that.
No.
They added software and this is when there's a danger to a person, when something happens, really bad happens to a person, the manufacturer is liable.
Software has been excluded, has never been regulated before and suddenly we get used to CRA and the product liability directed.
so that, so that sort of has a big impact on things like open source where you get, you know, no warranty, you know, use it as you think and you know, and as developers.
Yes.
We can only go through so much.
You never know.
As a developer of open source where I mean I started 20 years ago contributing to an open source telephone branch exchange, a pbx.
Right.
Many carriers took that up.
That was the starting point.
And businesses, of course, we basically killed a lot of PBX vendors by delivering more functionality for a lower price.
Zero.
Yeah, Very interesting.
Bad business idea delivery.
Anyway, we did later on I found that this was used in air traffic control.
Oh wow.
It was used in 112 systems, elevator systems.
And if we had liability according to PLD, that would be very dangerous with elevators.
So open source is actually excluded luckily from this.
But if a vendor includes open source, they are liable for the life of people.
So that takes it into sort of the integration role, doesn't it?
And you know, and you look at CRA, the manufacturer is the integrator of components, software, hardware, whatever.
And I presume the same is true of things like a financial system that's been sold to the bank, that's been integrated by many products.
And this again is, you know, there's an operator of the, you know, the water system, but actually that's a whole load of systems that are contributing to that water system.
So it's all these sorts of things coming together and who's responsible.
It's about responsibility and who's accountable and how much due diligence do they have to go and how deep do they go?
Do they just go to the first level?
So the operator talks to who they bought the product from or does he have remit to go all the way down that supply chain?
And that I think is, you know, going back to log 4J.
That's really what I think recognized to me was how deep the software supply chain has become in terms of how obscure it has become.
A lot of people didn't know what was being used by whom.
So I think, you know, this is what all these regulations are, sort of bringing these to the surface.
I don't know whether we have a.
The right way forward.
We've got different approaches, you know, like for, you know, assessments, self assessments, etc.
But it's actually trying to make sure that people do say some responsibility.
Yeah.
How long ago was log 4J?
August December 11th.
There's one thing.
20, 20, 21.
Okay.
Have we come much further since then?
If I operate an IT system, I mean, I usually in my trainings and talk start with I'm lactose intolerant.
So when I buy food I need to have that list of ingredients.
That doesn't mean I can cook the same food or bake the same bread, but I need the ingredient list.
We need that kind of transparency for products and services.
We say, I usually try to joke and say I'm allergic to curl.
Curl.
Don Steenberg's a really good product.
Right.
So when I buy stuff in my electronics favorite shop, how do I know if there's curl inside?
I need to know, right?
Yeah, I mean I think that's a good analogy for S pumps in general.
Yeah.
But we the IT systems in out in the industry, in society, they need transparency.
We need to prepare for the next log for and we're still far away.
But these two actually indirectly points to this.
They need to have control over the software supply.
But ultimately what they're trying to do and I think for all three of them trying to pull it together.
Back to your visual question from about 5 minutes ago Victor is all of them want to assess impact, right.
If there is a problem, they want to know who's affected and then how do I then remediate that quickly, et cetera, how do we stop the problem?
And without that sort of understanding of all those dependencies, you're not going to be able to understand that the full extent of that impact because otherwise it's a bit like playing whack a mole.
You think you've stopped it and then it pops up somewhere else.
So you need to just think about all those impact assessments and it's you know, classic change management, classic risk management.
Ultimately the fact it's software is interesting for us but ultimately this is just understanding if something happens, how do I control it.
Yeah, yeah.
I mean there are interesting hidden things that people when you start digging into this like when you buy a server that there's a server management software which is today a full operating system, basically Linux operating system running on a server.
How much do we know about these?
Oh, very little.
I mean I, I've had episodes with the core boot guys for instance.
Right.
Who have wealth of experience.
This is the IPMI software, right?
Yeah.
The IP is just a separate subset like even but even bias which even.
smaller connected to the network port.
Sometimes it shares network ports with the Internet board.
Yeah, yeah.
All kinds of hidden things are scary and especially if you're in the Easter world all the ot.
How many times have you gotten a team viewer over a email, unencrypted email and say log in here and check and someone connected a laptop somewhere to an OT system and you need to check something.
We need to change culture, we need to change behavior and these two points to that many people are afraid that our bugs will be illegal or Incidents will be legal.
No, it's not about that.
It's about your process and your transparency.
If hits the fan, you're gonna talk with your customers and you're gonna in many cases talk with authorities so they can talk with other While you fix your stuff, they will help you fix the rest and protect society.
But that will take some time to change the culture.
And I think that's why these two points, both to the management, but they also in many cases, when you start reading the implementation guide, they point to the organization and roles you must have in your organization.
Yeah, I mean ultimately these frameworks will live or die by how enforceable they are in the real world.
We can draft the best legislation in the world.
But let's just go back to gdpr, which is the obvious comparison, right.
How much has actually happened there method.
Those guys are stuck in court for another 10, 15 years before we actually get some outcomes from that.
If TRA is the same story, then have we actually raised the bar?
I think every little step that CRA changes, I don't believe for a minute that all products with a CE mark by 2027 will be secure.
Won't will follow all the requirements and have a release analysis, have an.
But every little step is for the better.
Every discussion where developers meet product managers and win the security discussion saying we need encryption here, we need authentication here, we need to protect the user data, we need secure by default.
Every little win is a is for the better for all of us.
But since it's about people, I realize this will take more time than we expect,
I think.
Yeah, I mean the fines are there as a sort of a inverted common threat, aren't they?
To try and say okay, comply if you don't come.
If you don't comply, then you know, we'll confine you.
And I know certainly the GDPR, you know, small businesses SMEs that I work with, GDPR is very much front and center of their thought process because they don't want to be taken to court and fined because that's out of business.
Whether larger businesses have a slightly different view, I don't know whether CRA will be similar, whether CRA will actually hit the smaller businesses harder than the larger businesses.
Who knows, It'd be interesting.
Nissan Dora probably it is only generally large business, large enterprises that are really in scope.
I mean the supply chain might be, but ultimately it's the operators that are going to see it.
But, but the thing with CRA and fines, I think the funds will come if you lie and cheat and you don't follow the authorities.
One thing people miss, they look at the fines and they look that, well, if you're a small business, the fine has to be adjusted to fit your business and so on.
But the worst weapon the authorities have is actually forbid your distribution of your product.
Stop it in all change all your distributors, resellers, not allowed to sell a single item.
That's going to hurt small businesses really bad.
The fines, that's an insurance issue, right?
Live or die, but that's someone else.
But if your product is forbidden on the market, that's going to be really hard to explain to stock owners.
Yeah, you're bored.
This is true.
This is true.
I mean.
it's looking at the consumer landscape in Europe today where so much of the stuff that you buy on Amazon or even if you go direct AliExpress and Alibaba and all these sources, right.
You'll be lucky if you find android device that is not end of life when you buy it from China.
Right.
Most of it is already end of life by the time you buy it.
So good luck with CRA on that one.
But I guess the point, the reason why I'm raising it is because the change to all these resellers is going to be massive because so many vendors, I mean I can't speak to myself or myself in the digital signage world with screenly, right.
So many vendors out there just white label from China and put some software.
Then you're basically a manufacturer in the eyes of them.
Yeah, but I guess this combined, I spoke with Sarah about this as well.
But when you speak into the real world out there, outside of our little bubble in the SBoM world, when you go and ask them about CRA, they'd be like, CR what?
They have no idea.
I met lawyers, I met business people and they're aware of me too, because large, I would say legal companies, legal advisors, financial advisors have been talking about that for a year or two.
But CRA is totally under the radar.
Yeah, I think it's sort of percolating from the bigger organizations downwards.
And I think, you know, I don't think it's meeting the sort of the, you know, the small SMEs, you know, 50 to 100 employee type businesses who have probably got quite a little niche market.
I think one problem is the fact that we're talking about the CMRC and the C mark for the radio directive and hardware has to be.
Has been about electricity and radio leaking and other things.
It's a test you do once before you launch a new product or when you upgrade, you do it once more.
But it's a checklist and you're done, right?
Yeah.
Well, it's also outsourced fully.
Yeah.
And people believe that the CRA and the C mark is the same, but the CRA points much more to your process.
You have to do risk analysis and you have to do mitigations.
There's no checklist according that fulfills your risk analysis and your threat model.
And then you have to maintain the product during the whole lifetime.
And you can't define the lifetime all by yourself.
The market authorities will have a say in that.
So if you're in a market where you sold products that exist out there in otis system for 15 years, you can't say three years.
You have to have at least 10 or 15 years of free software upgrades and security maintenance for that.
So do you think the CRA, some of the things that the CRA is pushing because the CRA is the latest thing on the, you know, the newest idea.
Do you think some of the stuff will actually have an impact on things like NIST2 and Dora to try and bring some of the things together?
Because if you're an organization who is serving in multiple markets, really you want to have something that's common.
And one of the challenges I see is software and digital is generally a global thing rather than just an EU issue or US or UK issue.
So really what we want is we want single, I have to say benchmark, but choose that as a starting word which we all have to achieve and demonstrate.
So we'll get to that.
Or do you think we're, you know, is that 10 years off?
There's only two things in that question.
One needs to points specifically to CRA.
The purchases even before CRA is active, needs to points to CRA and CRA compatibility.
And they also changed a law for medical journal systems, I believe to point to CRA after the CRA was published.
So they already changed the CRA a little bit.
So they're going to use CRA for products in other regulations.
Interesting.
Now I've forgotten about the second part.
So the thing was.
So the question is more about the global impact.
Oh yeah.
In terms of, you know, that part.
That, that's interesting in fact that the CRA, you, you know that they're working on horizontal and vertical standards.
Horizontal are for all products, vertical are for special product niches, especially those that are in the classes this area talk about as important or critical products.
But many people who earn money from these standards because you have to buy them like standards claim that you have to certify according to these.
That's not the case.
You can certify you self certified 99% of the products and you can certify according to the CRA law text.
But the law also says that there will be agreements, multi or what they say, bilateral agreements.
So if you're certified according to a law that is compatible with the CRA, requirement wise you'll be also certified for the CRA.
And there was a meeting a few years ago between EU and us.
I believe maybe it was cisa.
I don't think that discussion have continued because since I've lost so much employees they don't have time for that.
But the US government worked with something called the cyber trust mark for IoT and I believe they try to align the processes a bit.
So if you that I think the vision was if you had the cyber Trust mark, you would also have the CE mark.
But it was, I mean that was one of the big EU talking points coming out Davos this year was about Fed like making the European market more compatible, for lack of a better word, where it is extremely fragmented today.
Like if you work in the German market and you're trying to work with like northern Europe, like it's a completely different framework to operate.
So that was a of part both from a financial perspective but also from like a legal framework perspective.
Right.
So there are some talking heads at the top that is trying to at least drive that narrative.
Yeah, I mean that's why they're changing a little bit on these two.
They're taking things back.
I think they've seen that each country is making changes that makes it really hard to work cross border.
Yeah, they're gonna take in the omnibus now.
They're gonna take things back.
So these two will be more of the same and very small variants.
Yeah, that's gonna take some time.
If it took us multiple years to get these two into the switch law.
And then if you look at countries outside the eu, uk.
Yes, yes.
You know, there's no equivalent to the CRA other than the CRA in Europe.
It doesn't exist in the other 200 countries or how many countries we've got in this world these days.
So if you are a manufacturer who wants to sell globally, are you then having.
Is CRA providing a huge overhead, additional overhead on selling to the us, selling to Asia or wherever.
What we need to really think about is well, is a CRA the best everybody should adapt to, or is it the one that people will make a decision?
I don't want to go to Europe because it's too onerous, it's too hard.
So I'll go outside Europe and the European Community has less options.
I mean, we used to have a polarized world even before CRA.
Right.
So if you look at security compliance companies selling into the US market, they tend to do SoC2.
People selling into the European market, they do ISO2701.
Right.
Companies that play on both sides tend to do both.
Right.
But CRA then becomes, does that become the North Star?
That kind of supersedes.
Because honestly, like I call a lot of the ISO sock 2 stuff because it's just paperworking nonsense.
But I'm curious about how.
It's a bit like gdpr, isn't it?
You've got the gdpr which has sort of things, but I know the US has got different, similar things.
The states have different things.
California.
guys, Europe is in the lead here.
Hello.
Yeah, right.
All righty.
Laws.
Yeah, absolutely, yeah.
But jokingly aside, I have a friend who works worldwide with this kind of certification and he makes it very clear if you want to avoid being regulated when you sell products, there's not many countries you can go to.
Even China is working on regulation.
Not exactly the same, but regulation for cyber security and products you sell.
So there are very few places you can escape to.
Maybe CRA is going far because other countries start with IoT or other vertical sectors.
The medical industry has been regulated for a long time.
Even in Europe, automotive has been regulated for a long time.
But we believe when they started talking about this array that they were going to regulate iot, then they expanded and suddenly the regulated mobile app and everything, toys, other things.
So.
But yeah, it's an interesting narrative though because like you look at countries like South Korea is extremely progressive when it comes to like S bomb work, for instance.
Right.
And.
But are we ending up with a very fragmented world now where it becomes like almost impossible to operate in this, all this many markets because everyone has their own implementation and nuances to this stuff.
Like I say love it or hate sock 2 and ISO, at least it's a new global standard.
Right.
I think we've got to be careful about.
And I've been a great one for standards because I think standards are great for interoperability and great, you know, for market access, but I'm not.
I want things that are freely available as well that are also that everybody sees.
So there's a little bit of a, if standards go behind paywalls, then the adoption I think can becomes a tariff ultimately and people will try and short circuit it, you know and we look at things like the RFCs and the web, all those standards are freely available and I think we've seen the great success that how standards come together because people collaborate and make them better friends.
You, you have to understand, I mean I, I really admire the business idea of sense and elect.
In the standard bodies you pay to get in, you contribute with time with it getting paid, but you're not even getting the documents you're writing for free.
Then you have to pay to get the document.
You get paid in both ends.
It's a brilliant business idea, but it doesn't really help the world.
No.
IPF publish open standards, ECMA International, the Cycle DX specification, the Pearl, the cle, all freely available.
And I believe that helps implementations from very small companies, open source project up, large corporations.
I think that's really important and I think that the other business idea will hopefully go away.
But one thing, unless I steal that idea, such a new Johansson Standard Institute.
No, but one thing that's important to talk about when you talk about compliance standards is really the concept of self certification versus a certification body that in turn outsources their work to some kind of compliance organization.
Right?
CRA is a self certified standard.
Yeah, yeah.
But there are other standards that are similar.
Whereas this is not true for ISO or SoC2 for instance.
It's not.
You cannot self certify and say hi, I'm compliant, you can do it.
Soc 2 Type 1 I think is self certified.
Type 2 is not if I'm not if I got my lingo right.
But Anthony, you kind of brought the UK into the question.
But let's take the turns a little bit and turn into the UK market.
It is a bit of an oddball because it's kind of, it is Europe but not Europe.
So let's unpack.
The good thing that you said it,
Victor, I would be a very bad spot if I said something.
Yeah, I mean I hey, I'm belly in from the uk so like hey, I can take the battle but my point is there've been a lot of stuff work like GCHQ and so on, they didn't put out a lot of stuff.
And good documentation, good recommendations around, secure by default, secure design, but it doesn't quite have any teeth.
Let's pick up on that.
Where's your head at that.
How long have we got?
I think you're right that basically.
the.
UK works very globally with, you know, the US etc.
And we all, you know the problems the UK has in France and US has in terms of cyber security.
Yeah.
We all suffer and they are doing things to keep, to protect the nations safe and secure.
Fine.
When I have an issue with things like the CRA, which is now.
The CRA has now gone down to digital products, you know, consumer devices, quite small devices, you know, your baby monitors, your light bulbs.
We don't have anything equivalent in the uk.
Now the UK issued last year the Software Security Code of Practice.
Yeah.
And they claim it aligns with the CRA and it comes out with 14 principles and it says you need to have knowledge of your supply chain, you need to do, you know, get governance control, etc.
Understand vulnerability management, etc.
But it's voluntary.
There is no compulsion for anybody to demonstrate they are compliant with that.
I was involved in the, when it came out in draft and we gave them comments about.
Because they called it the Software Code of practice and it was aimed at software, what we call software vendors.
I said it's going to miss the target audience because the target audience means the people who are using software, not just a software vendor like a Microsoft just use a vendor as just creating a software product is.
The integrated product was missing out.
So I've raised it.
I said that the voluntary, if it's voluntary, you will not get the behavior changes that you require to deliver secure projects.
And this is exactly the same way the US went with the medical device market in terms of they promoting secure by design, exactly the same way the UK has.
But the manufacturers were not complying until the regulation came along and then they got the required evidence.
So when I've been talking to people about secure by design, there's some companies starting to think about secure by design, but there's no benchmark and it's not a case of, well, do you go to a consultant to say, do I get a tick in the box?
Nobody knows what good looks like yet.
And that's the challenge I think we have.
We know what we should be doing, but there's no exam to pass yet.
And people love a checklist ultimately.
And I don't like checklists because it's evidence based, but people want that checklist so they can stick in the box and say, I am now, you know, CRA UK compliant.
And that's what people tend to look for.
It's the Easy A.
So I wish the UK would align with the, with what's happening globally, but I know there are challenges getting the industry aligned.
And I think the big challenge probably is the public sector getting the public sector to align with the requirements of such things like that, because it's really difficult to get them to move.
That's the big irony.
I forgot which piece of legislation it was.
I think it was Sweden or was it somewhere else.
But they basically put that mandate that everybody needs to do is secure by the side except the government.
And she's like, wait, shouldn't you lead by example?
And I personally, I agree, Victor, is that when I've presented S bombs and things like that, and I said we need somebody like the government.
Yeah.
To take, to take the example.
And then in the same way that US has done is people contracting to the Fed, they get it, then it becomes part of the, you know, the ecosystem because the government is the, you know, is the biggest customer of anything.
I mean, just to use kind of analogy here, like UI UX for instance, I mean, for those not in the UK are probably not familiar with this, but the UK government got a UI UX guideline that every single UK government portal must adhere to.
So they have like a design UI UX kit that every single UK government service follows, which I think is actually great.
Like you might like or dislike the UI ux, it doesn't really matter, but it is thought through and it follows best practices for most things.
We kind of need the same thing for cybersecurity now.
Now, one of the things I was involved, there was a survey and they were asking, do I use software that's come from outside the uk?
Well, what does that even mean?
What does that mean?
That's a good question.
But.
And the analogy I was saying when I had a chat with somebody said if I write my software in my laptop in Manchester and then I take my laptop and write it, that when I go to Paris, am I now writing software in Paris and am I using software that's now come from the outside the uk?
It doesn't make sense because, you know.
But why that.
Why is not a question they were thinking that's relevant.
Well, I mean, we've had a lot of those conversations.
When I was involved with cisa, a lot of the working groups, one of the talking points around that is around who wrote the code.
Right.
This is kind of nest bombs, right.
Like what's the GitHub handle?
It doesn't matter where they're writing it.
Who's writes it?
Isn't it?
Well yeah, but, but also how do you do attribute like it's almost impossible.
But shall we take another.
I mean if you look at these two CRA and everything it's.
And secure by design.
One trend that was discussed heavily a year ago or more was shift security left.
Yeah.
The question is who do we shift left?
Because they don't exist in most organizations.
And we also had a discussion at my conference last time about legal needs to be in there as well because with risk assessments that is part most of all these regulations legal needs to be involved in the risk assessment because that's a legal decision they claim.
So we need to shift legal left.
And the problem with that is that the legal department is very used to say no and not come up with solutions and say yes.
And the same goes for security.
You developed a service software as a service or something.
You develop a product and in the last minute before launch you have a security review.
You have a pen test and you have security people that act as police saying yes or no.
And if they say no you'll get additional cost and you have to go back and rebuild.
But they're not part of that process.
You come back after a while to another toll gate where they stand and check your product from their big shares.
This is a culture shame for a lot of people.
And the question is where are those people?
Companies today doesn't pay for training.
Companies are.
We're in a financial climate where we can't employ a lot of new people.
So how can we do this?
There big change both in the eastern sectors and all producers of products in.
08 for the producer software.
I think as much as I hate to use the phrase but I think AI is actually the savior here because the reality is that modern models we have today, like look at Opus, they will write better and more secure code than the average developer.
I would argue that Opus 4.6 probably writes better code than 98% of developers out there.
Right.
And more secure.
So I guess what I'm saying is in one way it's easier than ever to write more secure code in that way.
It is.
And also auditing that code is easier than ever was.
Right.
Because now you can have an LLM that's trained on security dimensions and it can do a full on audit on your code base in minutes or hours.
Right.
You someone needs to understand that audit.
Oh 100.
But that's why the role of the engineer is changing to becoming an architect.
From a code monkey.
Right.
That is a huge.
That architect needs to know.
Secure by design.
Yes, yes.
The mechanisms.
And at the same time as we do all this and have this mountain of stuff to do for these two and for CRA compliance we have the post quantum crypto thing coming and yeah, we haven't seen all that regulation but that will happen during the coming five to 10 years during your product's life cycle.
But this is interesting because that means we need to have crypto agility.
We need to be able to change for products that exist out there in runtime.
We need to change the whole crypto engine.
We need to switch trust anchors and most companies haven't even thought of doing that.
They're running PKIs with oh, we have 30 year certificates so we never have to bother.
At least not before I retire.
Low crypto RSA stuff and.
But I want to steer it back to open source again because I think it's really important because I want to throw.
I got you there.
Oh no.
I would love to talk PKI but I think it's been out of scope for the conversation.
We can do another episode of PKI because I would, I'd love to talk PKI with you because that's actually something I really enjoy.
But I want to turn this back to open source for a simple reason.
Because we started talking about the liability of open source in vendors and if we overlap that with the fact that these LLMs can write code very quickly.
So I saw a really interesting thought experiment the other day and someone was.
saying.
because these LLMs are so good these days and if we assume the rate of change is at the pace it has been for the last 612 months and they just could get better and better.
The argument someone was making, I forgot to credit it but it was basically like it makes it irrelevant for using open source in commercial products because it's more of a liability for the simple reason that if you're using open source then you need to do complete different supply chain management versus if your LLM is writing all that boiled code himself.
It changes the dimensions for security.
But what you're doing is.
I can see why someone say that because what you've got is you've got first party code, but you've got all of the code is first party code.
If you have some code that's open source, you've actually got a bigger development team because the open source community is looking after that bit of code for you as well.
Do you want to do.
And I can see both Sides if you want to be completely in control to the LLM, which is much the same way people like inner source, where they may think take all the open source and control it themselves, then periodically bring stuff from the outside.
Or do you use the open source community for what it's great at?
Unpaid, often no commitment, but some awesome development work and some awesome features who are actually far more responsive than maybe you can because you've got a thousand development teams in parallel rather than one development team.
This is not me shading open source.
I think it's fantastic.
I'm just saying the argument that this person was making was basically like when you're pulling in an open source library, you're going to use 1% of that code base.
Yeah, I can see that.
Yes.
The probability of vulnerability in that 1% of that code base is relatively small compared to you pulling an entire library.
So what I've been looking at is, and this is from some of the ideas that have been played around with Fosdem is I think SBOMs we need to go even lower than we currently do because we're at the component level, which it says I've got a library and I've got functions.
I'm not documenting which of those hundred functions I'm using now.
I've been looking at doing that for binaries and I've got somewhere with that.
It would be good to start getting that level of increased level of granularity such that allows you to say, well, if I am affected, am I really affected?
Because actually the S BOM or the transparency is going down to that level of detail and we don't have that.
And we don't have that with anything at the moment.
That, that's typical us because we're, we worked for quite some time now with bombs and we're looking at the next step while most of the people are not.
Haven't really begun the first step.
Right.
But I do agree we need to go to a component level at some time, but that's going to cost a lot more time and money.
But Victor, coming back to your way of thinking there, I'm an old network guy.
I, I built networks, which is Piper trained people in Ethernet and IP and LDAP and all that.
I worked for 10 years with the SIP protocol, so I'm a protocol geek.
And what we see today in the world of networking is that most people take it assumed that it's working and the knowledge is disappearing from organizations.
Yes.
So even basic misconfiguration and problems can't be solved because there's no one home.
What if your scenario with coding happens and we got a problem that the LLM can solve for you?
We need someone that goes in and analyze the code and fixes the problem or finds it and helps the LLM.
Well, I mean that person won't be there.
You're right, you're right.
However.
serious cost and problem 100 I, I just.
The future scenario that I envision in 5, 10, 15 years from now is these LLMs will write code that no human can understand.
They might help, they might even write assembly straight up.
Right.
And yeah, they don't need the abstraction layer we need.
Exactly, exactly.
So, so maybe that argument is kind of moot because, well, the pool of people on the planet today that could do assembly that well is very small,
but that comes, you know, I've worked in sort of what you'll call critical infrastructures and where safety and security and you know, we can argue safety and security where they are.
I want determinism, I want stability, I want guarantees.
You thought something into an LLM, you've no guarantee you're going to get the same thing the next day.
No, if you use a coder, a developer, a person with experience, you're going to get roughly the same.
Okay, they'll learn and they might get better, but you're going to see some relationship.
So I think we've got to be really careful about assuming everything doesn't need the human involvement.
In particular these regulations need the evidence.
And if you can ask the developer why he made a decision.
And currently I've got a student working for me and we're trying to emphasize the importance of writing those assumptions that you may implicitly writing those down, someone can pick them up six months later.
LL doesn't do that.
And if we need to do that when we can understand when an issue happens in a product and we can say, well, we made that design decision not to do, not to encrypt that data flow because it's a design decision, but it's captured, at least you've got some evidence to start with of why you've got, maybe you've got the consequences of not doing that.
We are going that direction.
I mean, look at the way we, I mean 15 years ago when we created a system, we had this UNIX guy, Linux guy that installed all the things.
He was magical and he installed everything and then installed the application, got it running.
Nowadays we have a lot of systems as Code, we have terraforms, we have docker files, we set up stuff.
But we seldom log into all of these.
Right.
We don't sit with Chop or anything.
We monitor.
And what you're saying is we're going to take the next step and say the input to the LMS is the code.
That's what we're going to manage and control.
But the code, well, we won't even understand it and we don't have to.
But I guess we need much better test systems.
The whole paradigm is changing.
But it's always been changing.
Yeah, but I mean this is what some of the smartest people in the AI world is working right now.
It's the guardrails around that.
Right.
How do you put up guardrails?
And without losing philosophy.
But picking up the bird testing, isn't that bringing everything back?
The reason they want the regulation is because people are releasing products that haven't been tested adequately.
objective.
Yeah.
And you know, we all know we can always test.
Testing is always time bound, you know, and actually, okay, AI could help do that.
But ultimately, how do you know you have tested every possibility?
Because if once you've tested every possibility, then your product will never be on the market.
Test every possibility.
Machines are really good at testing every possible possibility.
How do you do that?
Yeah, the testing has focused on the functionality the customer requires, the blinking lamps and all the cool stuff.
But they totally ignore the security aspects.
They haven't looked for security holes.
They haven't.
Yeah.
I mean they ignore the vast amounts of cyber security knowledge that's been out there for business reasons.
And I understand that if you operated a business with maximum profit as the goal, there was no reason because customers bought your.
There's no reason to invest in cyber security.
And by the way, the cyber security experts, they're weird people.
You don't want to hang out with them.
Right.
So.
No, no.
But this is the way back to where we started.
Legislation is needed to fix this.
Yeah.
Be a culture change.
And legislation won't fix the culture and how people act and think.
But people have got to think.
And this is where secure by design can come in as well.
Because a lot of people focus on the functionality, as you say, the use cases.
When I train people, I say you need to think differently, not like an engineer sometimes.
And you have to think about the abuse cases.
Yeah.
And that's that suddenly things.
Well, what's an abuse case?
Well, it's not written down.
Well, that's.
The hacker hasn't got a playbook of how to Hack your product.
He's got some playbook things of things that common failures but he's not going to, you know, he'll find things that are not written down.
So therefore how do you ensure that?
And that's the things that's where the testing is.
Maybe, you know, you can automate a lot of it, but maybe you do need to have a different thinking and you know, how much testing do you do?
There's a, you know.
Yeah, you know, I mean how much training do you need to do for a marathon?
Well, you've got time.
Yes, yes.
You know, you've got to do.
Be pragmatic sometimes.
Yeah, I'm just saying like training and data set on say OWASP top hundred is relatively trivial and running that against a code base is relatively trivial.
That's more than most companies out there are doing today.
Right.
And that's why I'm like I'm bullish on agents to do security audits because they can be very specific and they are read up on the latest vulnerabilities and whatnot, have that data set.
Whereas an old school security guy might go to like two conferences a day a year and pick up on new stuff.
Whereas.
So like it's a moving target.
Right?
Yeah, but, so let's steer this back to CRA which ultimately steers us to S BOMs because I think that's the common thread between all of us.
What am I. Oh, back to home turf, Victor.
Back to home turf indeed.
But one thing that worries me a little bit around the SBoM requirements in CRA is that people treat it as a checkbox exercise and they would just submit something and as we all know, garbage in, garbage out.
Right.
Because if there's no audit of that, how do we like or even.
Let me ask a question like how do we even prevent that from happening?
First, there's no obligation to submit anything until I mean if you're certified there may be other rules.
Right.
But if you're self certified until the market authority asks you.
But there's also a clause saying that market authorities may ask you to collect statistics from their spons.
But I think that there is a mistake.
When they wrote here, they specified clearly there's bomb the authorities will ask for, which is at least top level dependencies because they can find out the rest if they have the top levels.
Right.
And they're well known unless they're internal.
So you have Victor 1, Victor 2, Victor 3 as top level dependencies.
No one knows what that is, you probably need to go one layer down there.
But the rest of the text indicates clearly that the vendor is responsible for everything.
He sells all the components and he needs to have due diligence, he needs to have vulnerability checks, he needs to do pen testing.
So in order to comply with that, you need a database of all your components.
And you probably also want the licenses and the copyrights and the package URLs for checking it.
And you end up with a full S bond, not level dependency.
Right?
You can call it whatever you want, Excel, spreadsheet or database, but it isn't software bill of materials.
So the law.
Could I be more clear that.
Well, the thing you deliver to market authorities is one.
But in order to fulfill the process here, you certainly need a full SBoM.
But going back to what you said, how do you know whether it's complete or how do you know whether it's right?
And I think this is one of the big challenges we have as an SBoM community is we have no consistency.
If you own one tool and you've got five dependencies, direct or indirect, just matter, and you have another tool that tells you 10, how do you know which is right?
Because if you only take the five and you only monitor those five components, you can still have a vulnerability that could be exploited in a component you don't know about.
You will still be affected by the COA because you have a requirement to not deliver a product without exploitable vulnerabilities, whatever that might mean.
So we have a quality problem in terms of how do you ensure the things.
So I strongly recommend to people that they should never just use one tool.
They should use multiple tools and often try and aggregate those and try and say, well, if they are significantly different, well, maybe get a third tool to try and arbitrate.
But if they are radically different, that's a danger.
The danger I see is people were going to select one tool and assumes that's the right thing to do.
I've never been of that view.
When I used to compile code in C, I would always have two or three compilers and compile them and prove it worked.
different states.
Here, the tool.
I fully agree with Anthony here.
I've been in projects where management bought a fancy cool tool from a company and it didn't work for our code base at all.
But people believe that, well, we run it, we comply with the management and we're happy.
But they didn't have any S bomb.
I think that's critical.
But if you go back to CRA you need sboms for your development work, that's fine.
But the product you deliver may be something else.
There may be an installer, there may be hardware firmware like we discussed IPMAI earlier, and other things.
The market Authority will want SBOMs of the product, not your code, only the product you're placing on the market.
Yeah, and I think that's the critical difference that people are quite often missing, that the product you placing on the market can contain a lot of different things.
Let me tell you firsthand, if you're a PC manufacturer today or OEM selling PCs to the European market, you're not gonna find a vendor out there, to my knowledge, that can value S BOM of every single firmware.
They do not exist.
I've looked.
I am not aware of any that can buy your SBoM, except to some extreme niche players, perhaps.
But, but also check the agreements.
When you buy a board and you get firmware and you get drivers and other things, the agreements may be problematic if you want to reveal what's in there.
And yeah, as you said, they're not ready to provide you with S bombs, which means you may have to change board manufacturer.
And that means you have less than one and a half year to do that and rewrite your code for that.
Yeah, yeah.
And I think, you know, if people are, if, you know, if some manufacturers aren't prepared to deliver an S bom, then does the onus then become on the manufacturer to create an S bomb?
Well, good luck doing that with AMI bias or something like that.
Right, Correct.
So therefore is, you know, that's a challenge that people are going to have to do and it won't be, you know, do we want everybody to be doing that?
So, you know, choose your bios.
And the BIOS is in hundreds of products.
Does that mean you want hundreds of people trying to do the same job or not?
Where does that, where does that go?
We, we're now in a very technical, exact world, which is good for engineers.
We feel safe and comfortable.
Comfortable.
But we also have to realize the market authorities doesn't have the knowledge.
They don't.
They're staffing up in Sweden.
We haven't even made decision about which market authorities.
We have a proposal so that they haven't got the directives, they haven't got the funding, they haven't got the staff.
So this will be a market problem that, as Anthony indicated, will apply to many different companies.
And I think it's an issue we have to take later.
We have to start with baby steps.
And move ourselves upward the stack.
But it's going to be a problem at some point.
Absolutely.
Yeah.
I mean, piggyback on that narrative.
Like when I had Sarah on the show we talk about.
Because she was on attacking committee for CRA.
Right.
So she has a lot of insight into the reasoning of why things are written the way they are.
But she was basically saying to your point, it's about showing effort.
That's the thing like, and kind of like what I was.
My, my talk at Folstom was essentially about how you generate SBoM that's CRA compliant.
And it's about showing effort that you're moving in the direction.
You won't get fines if the market authority finds a component you haven't got in your S bom.
But if you ignore them and don't update your S bom, then you will be in trouble.
So it's a lot about cooperation and as you say, process here way is more about process than checklist business.
Yeah.
And people and I've always said, you.
know, models, which is the critical issue, it doesn't point to management, but it will end up in management because it's going to change the business model.
The cost of maintaining a product will be much higher than before and many companies doesn't have a revenue to match that cost.
I, I've always said, you know, when I used to, when I got started getting looking at open source licensing, you know, ignorance is no defense.
And I said, you know, when I tell the engineers, you know, this is what the challenges are, basically at least take it seriously and try and do the best you can.
You're not going to be perfect, but at least you'd have made an effort to try and capitalize, you know, to look at, you know, has that application got a license, a valid license or not against your policy.
And I think the SCRA is going to start with that and exactly as you say.
And Sarah would say would.
Let's, let's demonstrate commitment.
We're committed to try and do that.
We're never going to be perfect because perfect doesn't.
No one's defined what perfect exists.
Then when we start looking at all the different standards around the world in terms of what should we include in our SBoM?
Yeah, that will evolve over time, but I don't want us to get fixated is it JSON, is it XML, is it CycloneDx, SPDX?
I just want to make sure have we got that inventory of information that we can then start doing things to actually make society secure more Secure and more resilient.
Ultimately that's the goal we want to get to.
Yeah, I'd love to have a one hour discussion about XML or ABCDIC or Jason.
Well, the longest word is that if you hate yourself, go for xml.
If you don't hate yourself, go for JSON.
We're not even talking about XML schemas.
But anyway, I think Anthony's point is important here.
Yeah, it's about making society more secure.
Yes.
Racism about making society secure.
Yeah.
It's the process.
Yeah.
Ultimately critical.
That's one thing.
Right.
It's when we're looking at again, kind of throw back to my first time talk is basically people want an easy button.
That's the vast majority of the people that needs to adhere to CRA, they do not care of.
Between Cyclone spdx, Cyclone versions.
SPDX versions, build, run all these like neons that we kind of like in this little bubble spend the days talking about the vast bureau of customers who needs to be.
Or vendors that need to be compliant.
They couldn't care less.
They want that easy button design.
Do I have an S bomb?
Yes.
Cool.
Move on.
Not having an extra.
Not having an S bomb is the problem.
You know, I want people to start saying when you ask for an S bomb and that's what my Fosden talk.
Which one do you want?
I want people to be actually asking those sort of questions.
What flavor would you like?
Yes, that's step two, right?
That's not, that's not step one.
That's step two.
Okay.
Well, yes, and I think we're probably as you say, because we're in this bubble.
We're already two steps ahead.
The world is a step minus two.
We are step five.
Right.
So let's get to zero first, Right?
Yeah, I think, I think zero is, I think zero is achieved because I think people have been talking about S bonds for five years and there is now some experience.
Let's be real, Anthony.
We have been talking about S bombs for five plus years.
That is not the rest of the world where you speak to a lot of people.
Even in the tech world, they don't even know what S bombs are.
So let's just, let's rein it in a little bit.
Okay?
Yeah.
Obviously I've got the wrong nerdy friends.
Then.
Anthony and I in SBoM Europe we wrote something.
Was it a year ago called yes.
Is that S bomb?
Yeah.
And I think that's important to go back to now and then.
And I think one of the most important one is of the 10 rules there is any S bomb is better than no S bomb?
Yes.
Yes.
Then we can discuss the next step and the next step, but get an S bomb, get it working and try to take your first steps and then we can make better.
Yeah, I think that's a fantastic note to end at.
Thank you both for coming on the show.
We are at time.
Are there any last words?
Ola, I know you have a conference coming up.
You should do a shout out to that about that before we wrap up.
Absolutely.
Anthony and I, as I said, we've been running SBOM Europe for a while now with we've been participating in conferences and other things, but we try to notch put things up a notch now by starting our own conference called SBoM Focus.
Because we haven't found that on this side of the Atlantic and with all the legislations we've been talking about, I think it's time for the SBOM nerds to meet and work on the steps forward.
So SSBOM Focus is April 10, Friday, April 10, in Stockholm, Sweden.
We are planning to move this around Europe and also discussing how to create labs, much like the Espo Marama labs in us.
Yeah.
To test interoperability, to help the community and the industry to get tools that work together.
Because this is going to be a tool chain, not a single tool, and we need them to work together.
And in addition to that, in the labs, we're going to introduce labs and interoperability tests for the Transparency Exchange API, which will be very important.
And that goes hand in hand with Cyclone DX2O.
So we have a lot of cool stuff, but it all starts in Stockholm.
Go to SBOmFocus EU and you'll find more information and we'll see you in Stockholm in the spring.
Much better than today.
Good stuff.
Perfect.
Thank you both for coming on the show.
A lot of fun.
I really appreciate it.
And I will see you both at some ESPO event around the world sometime soon.
But until then, have a good one.
Thank you so much, guys.
Have a good one.
Take care.
Bye.
Found an error or typo? File PR against this file or the transcript.