Daniel Thompson-Yvetot - Risk, Evidence and Conformity

This talk focuses on the Cyber Resilience Act (CRA), a piece of legislation enacted by the European Commission in 2024 that standardizes how products with digital elements can enter the European market. The speaker, an experienced professional in the field, introduces his new book titled 'Risk, Evidence, and Conformity' and discusses his work on standards for the CRA, including topics such as browser security and cryptography. He explains the importance of obtaining a CE mark and adhering to strict cybersecurity regulations, which require manufacturers to prove their products are secure and free of known vulnerabilities. The talk also emphasizes the need for compliance documentation, including the maintenance of evidence for cybersecurity assessments that must be kept for up to ten years. The speaker highlights the challenges of navigating these new regulations, especially for open-source projects and smaller companies, while offering insights into how to effectively mitigate cybersecurity risks.

Sure. Uh, hey everybody. Uh, it's good to see a bunch of you. I've seen before at this talk. Um, I've been speaking about the Cyber Resilience Act for three years now. This is my third time here at this event talking about the same topic. And that's a great level. Thank you. And what what we're going to talk about today is my new book. So, I'm launching a

book called Risk, Evidence, and Conformity here at this event. and I'm going to be doing a book signing this afternoon around 2:00 after lunch out in the the foyer. So, just a show of hands, who's who knows what the cyber resilience act is? Have you heard of it? That's a lot better than last year. Last year was almost nobody. So, we're doing something good. Um, so I'll

give a quick introduction to myself and then I'll talk about the CRA and and what it means to you. So I'm one of the creators of Tari, the framework for building uh software for desktop and mobile apps kind of like Electron but with Rust. So it's uh more secure, more performant etc. I run a couple companies and the software industry as well as in the compliance venue

and I'm currently working at the um at one of the European standardization organizations writing three of the standards for the CRA. So I'm working on writing the browser standard, the password manager standard and together with my colleague the boot manager standard and uh I'm also working on the various annexes. So there's NXK for cryptography, NXR for the um remote data processing solutions and NXX. This is probably

all wild news to you. You've never heard any of these things. Doesn't matter so much. I'll talk a little bit more about it later. Uh last year I was given an award for cyber security leader of the year and I have written two books before this one. Uh some of you might have gotten the first one manufacturing European software last year at this event. I gave out

free copies. So let's talk about the cyber resilience act. The cyber resilience act is a piece of legislation enacted by the European Commission in 20 24 that harmonizes how products with digital elements enter the European market. What does that mean? So on the market, you have various things like chairs and TV screens and cameras and phones. And every time one of these products enters the market, you

have to put a kind of certification on there that you've followed all the rules and regulations for it. It's called a CE mark. And what the C mark says is the manufacturer has done all of their due diligence to show that they conform with the law. And so what is the law here? The Cyber Resilience Act expects manufacturers to follow a set of uh rules for proving

that their products are cyber secure. Like [snorts] the commission wants you to make sure that logging is done appropriately. They want to make sure that um the the update system is secure. They want to make sure that you're not shipping products with known vulnerabilities that are exploitable. And so in their wisdom and I I mean I I work with the with colleagues at the commission. Uh what

they've done is they've created a framework for product verticals to emerge. And these product verticals I just mentioned three of them earlier. Uh serve to help manufacturers place their product on the market using a system called the presumption of conformity. You might not have heard of that before, but the presumption of conformity is a method by which you show that you are in conformity without having to

go to a third party. You don't have to go assessment body or an ITV. You can just prove it yourself because there's very strict guidelines on how to do it. There's uh requirements and then there's assessments that show you how to get the evidence that you need. And that's great if you're making a browser or you're making a uh a password manager, a VPN, all these things

with the the it's very clear how to how to secure these products. The problem is that like 90% of the products on the European market are default category, right? They're not in these important groups. So every every other one of us is like, well, okay, how do we now know what to do? get the C mark, right? Like the the the point is like at the end

of the day, if you do not have a CE mark on your product, which is a piece of software or a library, you cannot stay on the market. And and I think that there's a lot of misinformation out there that the European Commission wants to fine you for not doing it right. They'll just take you off the market. That's the easiest way to make sure that you

um you attain the the holy grail of the C marking. The thing is there's no real definition of default. It's kind of like everything else. So, I actually dug through all of the uh the text recently in the um guidance draft published by the commission. It said the term default is not actually defined in the CRA. So, what are we doing here anyway? It's like, well, it's

everything else. And and there's actually a reason for this. And the reason is that, you know, there's like several dozen standards being written right now, but the commission expects groups of manufacturers to get together and write up new standards. So that's why they're they're they're they're kind of leaving it alone, I guess, but we're all just a little confused. I was confused. I'm still recovering from being

confused. And so the the the thing that you have to understand is there's a checklist if if you're a manufacturer or not, right? you probably are websites maybe not. And I think the I'll give you some some some things that I've learned along the way to help you kind of figure out where where you sit in this mess. Um, if your product is listed in the uh

the annex, then you're absolutely a product. Like there's no way to avoid being a VPN. If your product is a VPN, if it's intended purpose and reasonably foreseeable use is to be a VPN, you're caught up in the uh important class of of this. So, you'll have the guidelines. But if you're making something like a smartwatch or software for a smartwatch or anything that gets installed from

an app store, you're probably a default manufacturer. The the it goes down as far as Flappy Birds. In fact, my friend Filipe from the commission used the term Flappy Birds to say, "Look, it it it's still a product on the market that has some risk. So, you have to mitigate that risk. You have to show how you mitigated that risk." And everyone's like, "What risk? What can

Flappy Birds do?" The challenge of putting products on the market now is that you have to you have to ask yourself a whole bunch of questions. Like the first one is what cyber security risks do I have to address like and and if you don't even if if if your team is never concerned about cyber security at all then that's the first problem you have to uh

identify and I' I've again in in my book there's a whole that's 500 pages it's it's a it's actually a manual on how to survive the um annex one goes through and it lists all of the things that you're expected to do and prove So, how do you prove it? How do you prove that you've mitigated a risk? Well, you identify the risk. You craft a requirement

that states what you are supposed to do to mitigate that risk. You draft an assessment that is like a test to show that you've mitigated it. And then you collect the evidence. Sounds like a lot, but I mean, I'm sure a lot of you also understand how testing in contemporary software works. Uh, you run a test, you get the result, pass, fail. But now instead of the

the green red, you actually have to collect evidence of when it passed, under what circumstances it passed, what parts of your um collection of evidence does it relate to? Sometimes a test might cover several things. Like for example, you're supposed to use state-of-the-art cryptography. Who here uses SHA 1 because it's easy? I know some of us do. Oh, because it's safe. technically the ACM which is the

acceptable cryptographic methodology from ANISA has sunset Shia 1. So you have there's there's very there's very real reasons to um update your systems because when you have the proof that you have done the all of the right things and you've done everything correctly, you have to keep the you have to keep this evidence available for 10 years. I'm I'm like I wish I was making this up.

I wish I was like telling wild stories, but it's actually true. You have to keep your product secure for 5 years and you have to keep all of your evidence for 10 years at least. Unless your product is something like a library that's been in use for 20 years that might be in use for another 20 years, you are expected to keep that evidence for the entire

duration of the life cycle of that product or 10 years, whichever is shorter. What's a product? Well, the the library that you install into your um or your your your upstream library that you bring into your product is also a product, right? So, we have like all of these layers of individual products that come together to make a final product. what happens when something changes? Like, okay,

who's who's made a pull request that changed the feature this month? Yeah, right. Everybody. Technically, features change risk levels, potentially introduce new risks the moment you change the threat model, you've created a new product, which means you have to create a new declaration of conformity. You have to collect all of the evidence all over again. And then you have a new product. You have to do that

for at least 5 years or the lifetime of your product. Every time your product changes and the the new product, you have to keep that evidence for 10 years or until the end of that life cycle. So suddenly like we're we're we're we're going to be facing a world of bookkeeping. And you might be asking yourself, well, why is this important? That's important because when something happens

to your system, when your your system is being uh attacked or uh a vulnerability is being exploited, you're expected to report this to the signal reporting platform of Ana. Uh, Anisa is, by the way, the European Cyber Security Agency uh, out of Greece, great people, underfunded, good projects, but they don't care. You have to submit that thing within 24 hours. When something bad happens to your system

within 24 hours, you have to inform them. You have to fix it within 72 or start fixing it and then do a final report later. You get fined if you don't, unless you're open source or microenterprise. Who's open source? A couple people. Okay. So, everybody else uh above microenterprise. So, microenterprise is just a couple people, not much turnover. They don't care. Like, you'll get a slap on

the wrist, but they're not going to find you if you don't do the reporting because, you know, time is never enough when you're a startup. And so, the law is changing, right? So, like as as as we've been going through this for two years, we've been getting pieces of legislation called delegated acts that tell us how to understand and read the legislation. There's like 10 more coming,

right? And uh the thing is they're they're not revising anything. They're explaining what they meant. So, as an example, it's not exactly a delegated act. It's a piece of guidance which has the legal value of a recital which is to say not much but enough to give uh national authorities a feeling. They've now said that open- source projects can sell attestations to security level downstream and it's

not considered a market activity. Let me repeat that. Everybody who's been using open source up until now if you do not get an attestation from the manu the maker the the creator of that open source it is your responsibility to show that it is safe to use. You can't just pass the buck in case something goes wrong with the the cyber security posture of your pad left

library or left pad or is number right like any any of these things that introduce a security vulnerability that is then exploited is your fault unless you have an attestation from the open source community or it's a stewarded project. The point is the commission is making you as a manufacturer responsible for the entirety of your product. If you ship a bad component, it's your fault for sourcing

it wrong. I mean, it kind of makes sense. So, in my book, I talk about the foundations of the Cyber Resilience Act, what it's about, why it's there, who it addresses, and it gives you an understanding of module A, which is what we're talking about. Module A is the approach to self uh certification or self assessment of your product and we I I I draw the boundary

between what is a product and what isn't a product like for example is your not picking anybody but I see ozero over there is your Ozero connection part of the product well they're a supplier so you have to collect due diligence on they did and they probably want to give you a CE marking because if Ozero gives you a CE mark for the integration that using with

them, it is as good as due diligence. Now, if something happens to your product because of Ozero, you're to blame, but you can take Ozero to court for supplying you with a an inappropriate The next part, and this is this is I think the most challenging one because there's no real way to do a a blanket statement on what risks different products face. Like Flappy Birds, well,

if Flappy Birds has advertising, then that means that there's a third party injecting content into the screen that that that might be damaging, that might have an attack value. So the the the methodology really takes the the stride approach to understanding what people can or could or want to do with your software and then builds out a framework for understanding the risks. How do you mitigate the

risks and then uh performing assessments to show that you have on the mitigation the and I have to tell you if you run out of evidence if you don't have the evidence if the evidence isn't self-explanatory the commission will or the market surveillance authority will take your product off the market. That's how it works. First they're like, "Hey, we're not sure we're going to take this off

the market because we have the ability to take you off the market. Now, show us what's going on here. Right? So, for a couple weeks, maybe months, maybe three months, your products can't be sold on the market. It's kind of a scary situation if you don't do it right. So, the bigger problem, and I think this is the one that no one really realized, is this this

life cycle of you make a change, now you're responsible for that change, and maybe it crafted a new product. There's workarounds to this. Um, and you know what what my advice is and actually the way you wrote the standards is you go to read annex one of the cyber resilience act the all of the categories are listed out and every time you see the word shall that's

law that means you must. I mean in standards we can't write the word must. I don't know why I never figured it out. We write the word shall. So you thou shalt I guess maybe from biblical times but when you see the word shall it means this is something you have to do. If you cannot prove that you have done this then you have literally broken the

law. You have not complied with the expectations of the regulation. Then for every component you run a stride assessment. You have to engage somebody who understands a little bit of cyber security to do a threat assessment. You score and prioritize and you trace every risk. And my advice is don't pass risk on to the user. This is something that's not clear in the in the cyber resilience

act, but the commission does not like it when you say, "Oh, well, the user can figure out this risk, right?" No, it's up to you as a manufacturer. And uh another challenge that people might not realize is that you have to deliver the product in a secure default state. Maybe some of your users who are using password managers in uh corporate environments don't want 2FA because it

just doesn't work for their topology, doesn't work for their organization. You 2FA when you came in the door with your key card, right? So, but as a manufacturer, you have to deliver it to them in that secure default state that they can then accept. If they choose to change it, that's on them. And this is where the the notion of user modification comes into play. and the

user manual that you have to write. H it's um I think I think the biggest one that I I'm worried about is no exploitable vulnerabilities. And that's because I think we do end up shipping a lot of code that has theoretical vulnerabilities at that time and then a week later when it finally gets downloaded to someone's software or to someone's laptop or phone an exploit might have

emerged especially in these days right so proving that you knew when you shipped it when you cut that release that you knew there are no exploitable vulnerabilities means you do your does npm audit still exist or do they shove it anyway you do your audit of all of the dependencies and then whatever is flagged you have to go in there and show it is not a part

of your uh either a functional tree or it doesn't affect you. You have to do that. You have to keep that evidence on hand for the moment you cut it and then if it starts if that changes you have to report it to Ana and then you have to fix it. So security fixes by the way are not new products but um they how do I say

this? They're like they're very relevant for the entire ecosystem. And let me give you like a an example of a library that gets hacked that's used or downloaded millions of times a day. Everyone who's affected, everyone who's impacted has to file a report. Everyone has to go to the Ana website and uh type buttons and uh make and file that report that uh this has happened. it

it's going to be kind of explosive and you as a manufacturer can't rely on someone else having reported it. If you are aware of it, your compliance team also has to report it. the again the process of what you've done is something that you have to document immutably. Um, here's here's an example for you. Does anybody push like artifacts to GitHub releases? You know that an admin

can come in and change that artifact? That's not that that's not going to be viable in this uh in this ecosystem in this this new Europe. Uh, does everyone have an SBOM? Do you know when you're going to actually need the Sbomb? September 11th, 2026. In case you have been affected by a assault on a vulnerable component in your product, you're going to have to report it

and Ana is going to say, "Show us your sbomb." It's it's one of those interesting parts about this whole thing like as a product manufacturer, you put your product on the market, you put your documentation on the market in all of the languages that the users are expected to speak in Europe where you're deploying your product. And then you have to have an a software bill of

materials that's private. You have to have an architectural design document. You have to have uh all of your evidence from the cyber security risk assessment. If the market surveillance authority asks you to provide this, you have to you have to comply. Non-compliance is immediate fine and removal from the market. Uh does everyone here have a European entity through which they run their software? That's the other way

around. Is your entity entirely non-European and you're placing products on the European market? Good. Tell your friends who are running companies outside of Europe placing products on the European market, for example, on the uh iOS app store. If they're, for example, in Venezuela, and they're shipping an app to the European App Store, they are going to have to get themselves either an importer or an authorized representative.

How how does the European Commission how how do the market surveillance authorities contact the Venezuelan company and compel it to do anything? It can't. So now now it's like the the sovereignty of of Europe's new regime is closing in on the politics of distribution. So um the distribution part of our software ecosystem is so rampant that I I mean the I I feel like they made a

mis a miscalculation when they were looking at how open- source is made and distributed because I mean my open source project there's people from China and Brazil and Egypt and uh Israel like from all over the world we come together we have a foundation in Europe so suddenly it's a European project when people consume our open source project now because we're going to become a steward we

are going to give them a uh an attestation that's this VSA voluntary security attestation which says well there's there's three levels that you can probably make get a as a donation to the to the foundation. There's the yeah, we have a security.mmd and a security at email that's monitored. Then the next one is this is the entire list of all of our products. This is how we

know who's been working on them. This is the last time we've checked everything. And the third one is a complete assessment of all of the risks that we've identified in the open source project that you can then use as your own uh evidence in order to attain either the presumption of conformity or your own C marking. And so when when you're when you're sourcing these third-party components,

I think the the the two risky ones are going to be unattested open source like uh some Apache 2 library that somebody wrote 5 years ago who doesn't care because if it's unattested that means you take absolute full responsibility and it's not certain that it's really like open source. course the author of that project has nothing to do with you. There's no relationship whatsoever. So it it

becomes one of these these risks that the entire community has to bear of users of this open source. And so I hope that you know in the next couple years projects do come together that support smaller open source projects that are very important to us but just don't have the ambition to participate in in our capitalist world. And then the other one is cloud SAS, right? So

when when you when you integrate thirdparty components into your product, what happens during the assessment period is that you're no longer capable of ultimately assessing exactly what it is that that component does. You have to take it on faith. And that taking it on faith can take a number of shapes. They can maybe give you some some due diligence documentation of their ISO 27,0001 or their sock

2, but that's not the product. Those are processes. Those are human processes. What you really want is you want your components to all have C markings because that kind of takes you out of the shooting line. Excuse me. Everybody's going to get hacked. Isn't that the old saying? Like you haven't been hacked. Either you've been hacked or you haven't been hacked yet. Something like that, right? [cough]

Here's a horror scenario for you. Um, your Flappy Birds app gets hacked the hacker starts deleting everybody's personal photos. You send a letter like, "Sorry folks, here's the update. Flappy Birds works again. Sorry about your photos." Unfortunately, there's a very big brother to the CRA. That's the product liability directive. Have Have you heard of the product liability directive? Almost nobody. Okay, a couple people. The product liability

directive is an act that or is a piece of European legislation that is being transposed across Europe right now. every country has to transpose it in their own way. Um, and transposition means they take the law and then they apply it to their national regulations because yeah, human rights, uh, identity, property, that kind of thing varies a little bit from country to country in Europe. That's just

the nature of history. And so a natural person is damaged by a product with digital elements, they can sue the manufacturer for damage to themselves, damage to to their property, not the app, damage to their mental health, damage to their data. Again, I am not So now think back to the Flappy Birds instance just now. You've done everything right, but a hacker still got in and ended

up wiping everybody's The reality is you're going to be facing a class action lawsuit from everyone who had their data damage destroyed because of a little simple game like Flappy Birds, right? because of some library that you didn't inspect. Like I'm not trying to be like the the like uh you know freak creep show guy here, but we've been saying this from cyber security corners for decades.

And now I I feel like the the first steps toward uh kind of harmonization of all of these requirements is is very helpful. And you on September 11th this year, I don't know, it's a that bad date, you know, it's one of those should have been the 10th I guess. Um, on that day, the first part of this legislation is in application. What that means is you

have to report actively exploited vulnerabilities on this day. If you do not, uh, you're uh, non-compliant. You have 24 hours once you discover it to report it. And they expect you to finish it, solve it immediately. I kind of find the 72 hours a little bit dramatic. So based on my book and everything that I've learned, I'm putting together a sort of training course that actually also

helps you get your product compliant. I've compiled [snorts] several thousand requirements and we use obviously AI to assess your product. We kind of sit in the code with you and then we help you collect the sbomb. We help you um create the evidence. we flag gaps when they're missing. Um, that's the link to this to the uh newsletter uh to get more information uh about that product

when it comes out. We expect it'll be out sometime this uh this summer. Um it's called Fleet and the idea isn't that we help you get compliant, it's more about finding that resilience in that that lock step. I was uh I was in Amsterdam last year and we were at the demonstration from Gaza and one of the speakers is a reporter from Palestine and she said something

that stuck with me. I think it's going to stick with you. I'm tired of being resilient. Right? Like that's the problem. It never stops. It doesn't [music] stop when you fix things. It just goes on and on and on. And we really need to develop processes and policies for you know staying healthy and keeping our development for people we want to anyway thank you again signing away

hope to see you there. Thank you. >> [applause]