Getting Ready for the EU CRA

0:00Chris RomeoNariman Agatagiev, an application security expert whose journey from competitive programming in Turkmenistan to leading enterprise security programs is both inspiring and instructive. With over 2 decades of software development experience across diverse technology stacks, including native cloud environments, Nariman brings a unique perspective that bridges the gap between development and security. Since 2016, Nariman has been at the forefront of application security, spearheading comprehensive application security programs and secure software development lifecycle initiatives at major international corporations. His deep expertise with industry-leading frameworks like BSM, OWASP SAM, and the NIST SSDF has made him a go-to authority for organizations looking to mature their security practices. As a Certified Secure Software Lifecycle Professional by ISC2, Nariman combines formal credentials with real-world experience, making him the perfect guest to discuss today's topic: Preparing for the EU CRA and What It Means for the Future of Application Security. We'll explore how this groundbreaking legislation is reshaping the security landscape and what organizations worldwide need to know to stay ahead of the curve. The Application Security Podcast is brought to you by Security Journey. Our training includes theory and immersive learning that teaches the skills and knowledge needed to create a security-first mindset across your organization.

1:20Robert HurlbutLearn more at securityjourney.com. Hey folks, welcome to another episode of the Application Security Podcast.

1:32Chris RomeoMy name is Chris Romeo. I am a general partner at Curve Ventures and also an application security superfan, I think, maybe a superfan at this point. I'm joined by my good friend Robert, who is fresh from the desert, so he has no money left at this point. He put all the money on red and I don't think that worked out. Is that what you did, Robert? Did you go red? I, well, neither one, but, but, but, but definitely fresh from Las Vegas, uh, where there were a lot of, uh, 2 great conferences there, uh, lots of great opportunities to meet people. So yeah, Robert Hurlbut, I'm a principal product security architect, as well as threat modeling trainer with Torion. And great to be here to talk about application security. Yeah. Did you, did you gamble even a quarter? No, not really, because I knew where that was ending. So.

2:31Robert HurlbutYeah.

2:32Chris RomeoYeah. The house always wins. People always forget that when they go to Vegas. Like, there's a reason they have all these giant buildings in the city and they can pay the power bill and everything for us. So they always win statistically. If you're good at math, they always win.

2:47Robert HurlbutIndeed.

2:48Chris RomeoEnough about Las Vegas. So we're joined by Neriman. I had a chance to meet Neriman at RSA. We sat down to talk about his New company and consulting endeavors, and said, "Ah, we gotta we gotta chat with Nerman on the AppSec podcast." So, Nerman, we always jump right in with our guests. We give you no time to warm up. We want to get right to your security origin story. So how'd you get into into security?

3:11Robert HurlbutAll right, and yes, indeed, we met and at RSA at a very important stage of my life where I had a turning point. I have been working for a corporate for last fifteen eighteen years. And I took a decision to move and try to do some entrepreneurship back then. And your feedbacks, your thoughts were like very critical and quite was inspiring for me when we were chatting back then at RSA. But coming to my security origin story, I grew up in a country far, far away from Las Vegas. It's called Turkmenistan. It sits somewhere between Europe and China, somewhere halfway. Central Asia. And we didn't have technology developed so much compared to, yes, back then when I was small, but I was lucky enough to have very good teachers in computers, you know, computer class. And he motivated me to start to put my candidacy to international Olympia team in computers. I was— started very early with programming when I was 12, 13 years old.

4:13Chris RomeoWow.

4:14Robert HurlbutHe was a very inspiring teacher back then. And the idea at that Olympiad is that you get a bunch of inputs and you have to solve a problem that maybe does some optimization work, calculation work based on input, and you have to get some output file. And when you solve this problem, it seems to be working, but when jury tries to assess you, how good you are at that Olympiad, they're trying to break your algorithm. They're trying to give you these files, like you think you're maybe planning like traveling salesman for like 10 points, 15 points, they give you a million points or they give you like input number of travel points minus 5 or 3.5. So they will try to break or give you corrupt inputs in all kinds of ways just to make sure you can't compete and you can measure who is a better programmer compared to other children. And it's embedded in my blood that I have to write my algorithm, my code bulletproof because always will be bad input because that's the way they, we compete. They try to break our code and I try to like make it work with any input possible, whatever way you try to abuse it. Fast forward, I knew I wanted to be a computer engineer, so I moved to Turkey and I started computer science there in a very beautiful city. It's called Izmir, a bit similar to Barcelona in Spain. So it's very fancy and very nice place.

5:40Chris RomeoYeah.

5:40Robert HurlbutUm, there at my first jobs, I already was a bit interested to like test my stuff properly. When I get a task just to make a data entry screen, and I would just use the frameworks available at that corporate to make that web interface, let's say, I would not just test that data entry screen is working. I would also try to play with the filters, with all kinds of Anything I can click around and I would only break and do, uh, SQL injection or like crash the backend because when I deliver my small data entry screen, I want to make sure it's bulletproof and nobody can break it. All their B2C customers cannot break it. Uh, and that's how it stuck to me. So I would like test very thoroughly everything. Again, 5, 10 years further in 2015, '16, basically 9 years ago, I was already living in the Netherlands. where I am at the moment. I was working for a big international corporate here, and the cybersecurity became more popular those years, and our customers started to ask us, hey, what are you doing for secure software development lifecycle? Do you have documentation describing your activities? We didn't have those. We were doing some things, but nothing was well documented. And people asked, who would like to volunteer? to improve our maturity, document it properly, implement activities, and do all this stuff. I stepped up to become a cybersecurity architect back then, and apparently I was the only one. So nobody else could see the future of cybersecurity except me. Luckily, I'm very happy that I chose this path. It took me 3, 4 years to assess May do lots of rounds of assessments, like see where are our gaps. Back then I was using BSIM. BSIM is a maturity framework with like 110, 115 different questions you ask to development teams and you try to find the gaps and what's missing and you plan some improvement. And I would start to introduce those things. We didn't have things like threat modeling. I would start to research, try to find my ways around. Implemented, documented. SCA implemented, documented. SAST, and I had to go through like all it by myself, and I didn't, I was not so aware about OWASP events. I was not aware of all this community around cybersecurity back then. I was a single person trying to do stuff. Only years later, when I started to go more actively in the Netherlands to Dutch OWASP chapters, I discovered OWASP SAM, proper way to do threat modeling, lots of new things, new frameworks, DISOM, and start to bring those to our organization, our corporate, and spread around new things, security champion program, threat modeling properly, and making, teaching the teachers so that they spread it further. And it was difficult path because if you want to introduce a maturity framework like SAM, OWASP SAM, that's a Software Assurance Maturity Model. They have 90 activities that you could do, and it gives you this way to measure yourself internally and plan properly the small steps. Plus, it has also these guidances from community, from people like me, you, Robert, and we probably all know this OWASP SAM. We we refer to different resources in the community to make those activities happen. And the SAM and OWASP participation was really a turning point for me and to bring lots of inspiration.

9:21Chris RomeoVery cool. And you mentioned OWASP several times, great things that they're doing. And so that's fantastic that you learned a lot by attending those groups and and helping you out in your own career. So fantastic to hear. So jumping in on our topic today, Nermin, what is the EU CRA?

9:49Robert HurlbutYeah. So, well, you know, in Europe, I live here for 12 years, we are very innovative with legislations, right? That's the best thing we do. In US, companies are much faster with introducing new technology, adapting those. EU is good with legislations and very often legislations are quite bureaucratic and not very useful, like cookie law, you know, European cookie law that you have to show that you're using cookies. That was introduced by one politician here in Netherlands. It's a, I wouldn't say the name of the party, just not to annoy people, but his idea was to inform European consumers that some websites can be consuming your resources, your RAM, and abusing the situation, but it was taken to a totally different direction and now he's ashamed that he proposed the EU cookie law. He told it himself. Then you have GDPR law, which had also good intentions. That's about protecting the privacy and the ownership that people own their data. You have rights to be forgotten. You have rights to get a copy of your data. good intentions, but it was not very clear how to comply. The checks are not done, controls are not done, and lots of companies are doing it just a checklist. Hey, yes, we have a PowerPoint with the steps, with some questions. Somebody sends it to you, you say, yes, I considered using as little as possible personal data, and you do it once for a huge cloud service, So I don't think it's really useful for most of the time. It's not done properly. But, and the problem there is that legislators, the commissioners, EU commissioners, they were doing their own stuff without having knowledge in technology and cybersecurity. CRA, it's a new act, it's a new law that was developed totally different. This time, It happened better. There was first version where that intention to make sure that all the software and the products with software components are safe for end users, that, that, that's safe from the data side. I mean, like for confidentiality and, uh, but when the first version came out, lots of foundations stepped up. So Linux Foundation, Oracle Foundation, uh, OWASP SAM team. Mm-hmm. And many more volunteers from all us in Europe, they volunteered to contribute to EU Commission. And we went a couple of times to Brussels. We sit and gave our feedback. We had a brainstorm how this new law will work in the practice. And after a couple of rounds, actually it ended up to be quite good legislation with new act, new document. But of course, I didn't say yet what is it. Actually, I just gave a pre-story. So the intention is that EU wants to make sure that the products with software components, it's almost everything, right? From your fridge to vacuum cleaners and almost anything you buy today has some software components, cars, everything, that they are developed with a security by design, that security is not afterthought, but while you're developing, that you're doing a proactive thinking of security. You do threat modeling, You do SCA, you scan your third-party components, you do static code analysis, you have proper plans for incident response. So when, when there's a problem, immediately within 24 hours, you have to report to certain national authorities, and they will coordinate with other companies. If they have the same problem, they will help each other. Then within the 7 days, you have to give an update, like exactly what happened and what did you do about it. And then you have to also follow up that, hey, after like 3, 4 weeks, what is the final decision? Are you releasing a hotfix or not? So this, all this lifecycle of incident response has to be very well documented. And after release lifecycle until end of life, that is also now well-defined. So you cannot just sell some products and forget about it. You have to support it at least for 5 years. Or until end of product lifecycle. So if it's clearly communicated that this product will be on the market for 3 years, that's fine. But normally it's 5 years you have to support hotfixes for cybersecurity because it's a new law. And everyone, even small manufacturer, everyone has obligation to comply. And also if you're outside of Europe, so you have some software, right, yourself, you have some startups you develop, right, DaVinci, the Threat Model Tool and other, now you have initiatives, Chris. If you want to sell it in Europe, but of course, if you want to sell it on-premise in Europe, not cloud solution, if you want to sell something on-premise, if it's a product that they can install locally, or if it's some hardware with a software in it, you have to have evidence that you did secure by design activities during development going forward. And there are some small details, like if you're just making a printer for home, or so that falls under this general default home compliances, at the moment you have to do self-assessment, but for example, German government already prepared a portal where you have to upload your self-assessment. So it's not just, yeah, I'm going to do something, you have to upload there and they recommend to use maturity frameworks like OWASP SAM, it's clear in their guidance is there. We have to do structured documentation of all the stages of your lifecycle from design, implementation, operation, governance, like it's described in SAM or BCI, whatever you use. You have to upload evidences. They're not gonna assess it, but for all these basic compliances, you do it. But if you make a modem or some firewall product or some more critical infrastructure-ish thing, Uh, then you fall under, uh, category 1 and 2, uh, classes, and, and then you have to be assessed. So you have to be certified. So every country will have certain authorities that, uh, that can do that for you.

16:15Chris RomeoAre they, do they, are they uniform though? If I certify in one country, do I have to, do I then get across the board?

16:23Robert HurlbutUh, looks like there will be like one organization that will be giving permissions to different companies in Europe to do the assessment. But in a timeline, the— there is this end of this year is only the moment where that will be defined finally. So that part is still being worked out, the rules, how to become one of these assessment companies. Looks like by end of 2025, that's the moment when that will be clear. But by end of 2026, like in 15 March, 18 March, That is the moment when the incident response obligations come into play. So you still have to start to report to these national authorities when you have any problem or compromise, end of 2026. And 2027, middle-ish, you have to have full evidence and documentation that you're doing secure-by-design activities. Got it.

17:17Chris RomeoHow complicated is this legislation? Like, how many pages? If I'm a small product company, and I make a Class 1 device for some reason, like how complicated is this thing that I have to comply with?

17:29Robert HurlbutSo it's, it's long and the language is difficult to track, but you can, especially if you do self-assessment, you have some easier way to start to do it, more practical way. And the easiest way in my opinion is to use OWASP SAM. Okay. So you can, so I can use OWASP SAM as my evidence. Yeah. So OWASP SAM core team members, we did assessment of EU Cyber Resilience Act based on SAM questions, and we have all the statistics. So on average, for example, you need to have 3 out of 3 in OWASP SAM language for operations column, because operations is one of the columns, one of the, like, business functions in OWASP SAM. It has like lots of activities because there is lots of attention for post-release activities. So there you have to do everything what is in SAM, plus you also need to report to national authorities. But that one is not in SAM because SAM is technology agnostic. It's not only for Europe, it's also for US. So we didn't write any OWASP SAM guidances. Here is the organization where you need to report. So that is missing in OWASP SAM, but most of stuff you need to do in Cortisa plus those reporting. Then for—

18:49Chris Romeois OWASP SAM mentioned in the, in the act itself? Like, is OWASP in, uh, this legislation?

18:56Robert HurlbutNo, the act says you need to be secure by design, but then each country published this, their own guidances where to report and how. Like, in Germany is today first one to do it, uh, they explicitly mentioned OWASP SAM and BCM and maturity, you know, things. Gotcha.

19:11Chris RomeoSo it's just Germany's the only one that's kind of is at the forefront of describing the implementation guidance of how you do this thing.

19:19Robert HurlbutYeah. Yeah. I expect that the rest of the countries will follow because today, uh, if you want to structurally document your development lifecycle, security lifecycle, focusing on security lifecycle, not broader, like R&D activities, you have only 2 options. You have OWASP SAM, you have BCM. In my opinion, because those, these 2 frameworks help you document and they not only, uh, helping you assess, but they also help you improve because you can plan the roadmap. You have guidances how to improve. You have this community, monthly community calls. You join, you ask questions to all us members, like how to do this, how to do that. They're helping. Uh, if you want to pay, you can hire BCIM and Synopsys and they will send experts that will help you to comply as well. So that's going— do it yourself compared to paying for that. But there are 2 options basically today. And other frameworks like cyber, NIST frameworks, for example, CSF, they're more control frameworks. They say you need to have third-party component security, but it doesn't say you how, or it doesn't say you how to measure. But in some, has criteria questions. It says, if you want to say yes, I'm doing third-party component security, here are 3 things you should be doing.

20:33Chris RomeoYeah.

20:33Robert HurlbutHe says, are you doing them? Do you have means to find the components you're using? Do you have means to find the problems you have there, like vulnerabilities? And do you have means to, like, fix it? So, the basic things, and then you are level 1. If you have automated, you're level 2. So, there's no way to—

20:49Chris RomeoThe hardest part is finding the things that are out there. But, Neriman, I'm curious though, why do we care? about this, like why? And I would say I'm a bit of a regulatory pundit to some degree. And it's a lot of it is because I grew up in the Common Criteria world. So like a previous iteration of trying to do this specifically at the product level and trying to have different company or different countries have different licensing and laboratories that did assessments. I kind of grew up in this. And so, I know all the struggles that come out of trying to do this. So, I guess, at the end of the day, why do we care about it, and who should care about it, I guess, as well? Like, is— if I'm just a general AppSec practitioner working inside of a big company, do I even care about this?

21:44Robert HurlbutWhy do I care? You have to answer that with 3 different hats, okay? As a citizen, let's say European citizen, why I would care is that when I buy a smart lamp or vacuum cleaner or any equipment for home, for example, I want to make sure that that part will be patched if there is vulnerability. I want to make sure that there are no hardcoded secrets, that default passwords are all like not in it, yeah, because having secret Scanning is one of the requirements in secure by design. So it is, when I see the CE sign, and you know, in Europe, whatever you sell, you have the CE signs that show that it's safe for consumers. CRA is part of the CE, it's extension to CE basically. So when I see that CE sign going forward, I will feel more confident that at least there is some basic security in place. So that's why do I care as a citizen? Okay? Why do I care as a software manufacturer located in Europe, for example? I'm here. I want to use it in my advantage, maybe to have a proper, when I'm selling in tenders, look, I'm compliant, I have proper documentation evidence. Now lots of customers care about it, so I can use for advantage. Why would I care when I'm a software manufacturer in US? or device manufacturer with software component in US. You don't want to be kicked out from European market. So you would care. You have to do it. And yeah, you have to do some evidence. You have to proper, have some structure there. And finally, as a cybersecurity expert, right? Not just manufacturer, like consultant, like we are, 3 of us, and lots of your listeners are cybersecurity experts or engineers in this, they work in this area. Why would you care? Well, it's a big wave of work. You should be aware of that and you should not miss this opportunity because awareness is coming in Europe at the moment. I know in the US there are also some laws coming, like you have a new rule that SCA and S-bonds need to be created and published. You can tell me more details of what the US is expecting from software companies, but some expectations are coming, obligations are coming for Europe. into US software companies. But as software engineers, security engineers, as security experts, for us, we need to be aware we have lots of work to do. We will need to help software manufacturers design and implement their software in a secure way. And we need to know how to do it structurally. You cannot just walk in and say, hey, I think you should do SCA. I think you should do SAST. I think you should do DAST. Just last month, I was consulting one company. They hired a big, one of these Big 4 consultancy companies before. They hired them and asked help to define their security roadmap. They got a report with 7 topics. Okay, you need to do SCA, you need to do SAST, you need to do DAST, you need to do this, this, this, and that's it. That's not how you should help software companies to be more mature. You should make broader assessment with all these activities, and you need to understand that the policies— each software company today has some sort of security policy, development policy. You need to understand that these in-house secure software development lifecycle policies, they are perfect world scenario. So if you have one that you share with customer, If you have a software company, you have this policy for security. That is your perfect world scenario. But if you actually go on the floor and talk with teams, perhaps you're halfway compliant in reality. Not every team actually doing all this stuff, which is written down in a corporate policy, what you're supposed to be doing.

25:39Chris RomeoMm-hmm.

25:40Robert HurlbutSo that's like perfect world scenario. So what you need to do is you are using survey like SAM, like vSim, go team by team, divide into scopes, ask questions, and then you compare how far are you from the target, the company policy or CRA or different legislations. They can be your targets. And then you can measure, okay, based on my self-assessment, I am 70% on the target for the operations. I'm like 40% on target for my implementation activity, design activities. And then you can define small improvement steps. for this quarter, for this year, only 3, 4 elements and you work on them, then you do reassessment again and you can do small iteration again. So that's how it works. So I mentioned your different hats, right? As engineer, as a citizen, that's why I wouldn't care.

26:31Chris RomeoNo, it makes sense. It's definitely, if you're building something and you want to sell in Europe, just like every other legislation that's ever been tied to product security. It's a barrier to sales. And so that will drive people going down the compliance route.

26:50Robert HurlbutAnd, you know, one rumor I heard, not official information, is that this law also will help to control the market. So if you produce something in US, in California, and If we don't like Californians anymore, and then European legislators can make all kind of, all kind of problems and say, look, we think you're not compliant, and then they kick you out of the European market. So this is also a political tool. So why do I care? As a politician, that's like another 6th hat. As a politician, it gives me another power tool to kick out Chinese brands, like, uh, that produce some networking equipment, uh, GSM equipment, I can say you're not compliant, prove it to me. Or, and it's not enough to be compliant at the release time to you. Let's say you delivered this tool to Europe, you, but one year later it's already sold out. But one year later, if you don't deliver on disclosing your problems, because there is also 5-year hotfix period afterwards, suddenly you're not CRA compliant afterwards. So it's a, it's a very strong tool.

28:01Chris RomeoIt's a political weapon as well. I'll go further. I'll describe it as a political weapon for sales and for controlling markets and stuff, which, that's a, it has this whole other dangerous side there to it.

28:16Robert HurlbutYeah, definitely.

28:20Chris RomeoSo how does, uh, EU CRA, uh, perhaps apply to open source library owners?

28:29Robert HurlbutOkay. Yeah. So statistics show, right, that every software sold has like 70-80% open source code in it, right? At least all new software. Um, when you go to a big old corporate that has lots of fortune code, maybe like 90% is actually in-house things.

28:49Chris RomeoSure.

28:50Robert HurlbutUh, but, uh, modern software, it's like 70-80% of lots of third-party packages. And behind the third-party packages, you might have some maintainers who like maintain that repository. You could have volunteers who are contributing as a hobby at night. Now, when you made a device with that 70% open-source components and suddenly your device is vulnerable because of that open-source library you're using, whose obligation it is to fix it? Who will lose the CE mark? Do you think it's open source maintainer?

29:26Chris RomeoYeah, it's going to be the commercial company that built the thing.

29:30Robert HurlbutSo the first person to make money on it is liable. So if I am using some third-party libraries that I'm paying for, if they're making money on that, then they're liable. I can say, hey, I'm using this, um, I don't know, uh, this modem inside my fridge, uh, and that modem is from that company. They're also CE certified. Uh, you, especially in a contract, you also probably will make it very clear. The first people to make money in that upper supply chain are liable there.

30:04Chris RomeoOh, interesting. So it is, it's the, it's the beginning of the supply chain then where, where it's the first time, first time somebody makes money with it.

30:13Robert HurlbutYes.

30:13Chris RomeoSo like if you, if I was to build a smart refrigerator, as long as I go and build and, and outsource all the components of it, including the software, I'm not, I'm not, and, and I'm not liable for it as a company.

30:28Robert HurlbutNormally not, but so that's how, what is used as a wording at the first to make money on it. But if you outsource it to China, that element, and you say, hey, you are liable, look, I'm getting fined, you need to make it, fix it. and they say, sorry, we are, we are bankrupt now. Good luck with that. So you need to make sure to have very good contract. You need to do very good due diligence on your supply chain. When you pick third-party components, you need to make sure that you pick the ones that are maintained. So that also helps the security of your own product. That forces you a little bit to think before you include it. And of course, the volunteers that are just doing it as a hobby, they're not liable. They don't have to do it. So if you're using, maybe you are contacted as a volunteer, as open source contributor, and corporate says, I depend on you and you have vulnerabilities I cannot sell anymore. Maybe you're nice, maybe you ask for money to fix it. So this actually contributes open source community because now they're not these volunteers that are just doing stuff for free and they're not important. Now they are important and companies will be interested to like recognize them and make sure. that they pick open source libraries that are responsive and are ready to do maintenance, et cetera. But of course, there is another side of it. CRA recognized concept called open source stewards. And stewards are foundations that collect under their umbrella big popular open source libraries like Eclipse Foundation, like Linux Foundation. And If you are, as a manufacturer, using one of that open source libraries from Oracle Foundation or Linux Foundation, it's not your liability anymore. The stewards, the foundation themselves, will be doing those obligations of incident response, reporting to the government when there's a problem, coordinating with their contributors, fixing, et cetera. So there is some, it helps a bit. using those foundation projects, because at least there you get rid of that liability. So you see the, uh, it's, it's not that clear how it'll all end up, but it's very clear that open source, um, community and the way it works will change in the future.

32:43Chris RomeoYeah. I mean, it sounds like it's gonna change for the better though. It's, it's adding some infrastructure, the seed. So an offshoot or an offset of the CRA. is that those foundations are gonna take on more responsibility amongst their products or their libraries and things that are, that are under their umbrella, and they're gonna do the incident response. They're gonna take care of the regulatory requirements for it. So no matter what happens with the CRA, that sounds like a positive move forward.

33:12Robert HurlbutYeah. Uh, finally, if you do your, if you have your own open source library, you're a maintainer, but you're making money out of it, let's say you actually offer paid services for that.

33:25Chris RomeoMm-hmm.

33:26Robert HurlbutUm, for example, you have it clearly stated on your website, if you need me to fix something, or here's a paid, uh, thing. So if you're making money on your open source library, you are also obliged to report and fix the problems as well.

33:42Chris RomeoMm-hmm.

33:43Robert HurlbutBecause then you're also making money out of that. But of course you can, If it's very obvious, you can be fined. But if it's not very obvious, if you just get a button, get me, like, sometimes I see this get me coffee button, you know, buy me beer button. So if they see that, probably you're not making money and they can ignore you. But if you're clearly making money, like, let's say you have a defect dodger, OWASP defect dodger, open source project, but there is a paid tier on top of that. They cannot say, we don't care, we're not going to fix it, because now they're also making money next to it. They offer some more services.

34:19Chris RomeoHow long do you think that this is going to take to shake out? So when I think about GDPR, and I'm actually a proponent of GDPR, as a privacy advocate, I like a lot of the things that GDPR mandates. It didn't shake out the way that I hoped as far as changing the scope of how privacy is protected. You know, it started to have an impact in the United States and then it kind of willowed away over time. But it took years to get there, right? Like there was the, there were 2 lawsuits. I think it was Facebook and somebody else. The EU sued them for €100 billion or something, some gigantic number. which then kind of started the movement of people starting to comply with GDPR and do the things that they at least try to do the things they were supposed to do. Do you think the EU CRA is going to have a similar timeline? Is it going to be years and then somebody's going to get sued? Somebody big is going to get sued and then that's going to start the people move, everybody moving in the right direction.

35:27Robert HurlbutI saw interesting research on this where they When one researcher, I forgot her name, I'm sorry, but she was comparing GDPR fines with expected CRA fines. And indeed, it took 2, 3 years until GDPR fines peaked. In the beginning, it was very little, it was not clear who is going to do that, et cetera. Only when somebody complains, they would look into that, in the problem. There was no proactive investigations. After 2, 3 years, the GDPR fines peaked. And they went down. With CRA, expectation is that once it's in place, end of 2026, it'll take 2 years until fines will peak. And do you know what fines are? They're huge. They're 2% of your global revenue. It's not profit. It's everything comes in before you make cost. 2% of global revenue is the fine up to. You can find that. So it, it can be very significant. Um, and yeah, expectation that the total amount of, uh, fines will be like double of GDPR compared to—

36:32Chris RomeoOh, wow.

36:32Robert HurlbutI saw the graph, they overlap GDPR with CRA and CRA was like double that.

36:37Chris RomeoWow. So we'll have a really big impact. So, okay. Well, Derman, this has been really good. Uh, for me as somebody who sits in the United States, and honestly, I haven't paid that much attention to CRA. Other than to know threat modeling is referenced in it, which I was cheering for. Like you know, anytime we move threat modeling forward, I guess what would be a key takeaway or a call to action for our audience? What can they do with this new knowledge of CRA? What should they do?

37:06Robert HurlbutNo, not because I'm OWASP SAM member, but I think key takeaway is to look into maturity frameworks like OWASP SAM. Because your main listeners are security engineers, security experts. You have knowledge in certain areas of cybersecurity, but framework like OWASP Summit will give you a big picture. It's more like on governance, a global level, high level. When you look at DSOM, DevSecOps maturity model, it focuses specifically on developers, DevOps people. It gives very concrete technical activities to those people that, but when you look at SAM, it's more like high level, more on the manager, the language that managers will understand what needs to be done. So looking into OWASP SAM, I think it's a key takeaway. If you never looked into that, you need to check it out, what the activities are. You can try to do assessment of your own teams. If you're working for some corporates, try to do a round of assessment of a pilot team. And you'll like it. You probably will propose it to do it continuously and see how far are you, um, from your corporate policy or from CRA. And one of the 2 subprojects of SAAM, one of them is benchmarks where you can compare yourself with the industry. You can see—

38:27Chris RomeoYeah.

38:27Robert HurlbutBy different industries, like how they, how mature are they? Uh, you know, some practitioners contributing data. And other, like, a big project of SAM is mappings. We map those SAM activities to different frameworks, like ISO, from NIST, from CRA, and you can download it as an Excel file with a, like, machine-readable format, and you can easily see which SAM activity maps to what CRA activity, or NIST Cybersecurity Framework activity, or ISO 27001, or whatever you're using. There are so many different mappings that you can find there. Of course, SAM doesn't cover 100% of all of those, but it's a starting point. It's the place where you start from. And then in every activity, in every guidance link, in that description of that activity, we have linked to OpenCRE project. And OpenCRE, it's a graph of all frameworks. So it's a mapping of mappings.

39:22Chris RomeoMm-hmm.

39:22Robert HurlbutSo once you jump to OpenCRE, It's like Pandora's box where it takes you to everywhere. Okay, for this activity, in ISO, it's that standard, in NIST, it's that activity. So basically, it's all interconnected. But starting point is sound. You do assessment, you see big picture, I need to do supply chain component security. Okay, once I do it, which controls I'm satisfying? Then you go to OpenCRE, through the link, and you find all the controls that you satisfied.

39:48Chris RomeoOkay, so—

39:49Robert HurlbutThat's my takeaway.

39:51Chris RomeoPeople should take a look at SAM. Hopefully all of our listeners, we've talked about SAM a lot over the years. Hopefully they've, they've taken a look at it, but if not, this could be a good jumping off point in preparation for dealing with CRA. Sounds like it's going to impact us over the next number of years if we're, if we're in, if we're working for companies that are building stuff. It doesn't matter where we are on earth, we all want to sell in Europe. So it's eventually, if it may not be this year or next year, but it'll be coming around and be something we have to experience. So.

40:20Robert HurlbutRight.

40:22Chris RomeoNeriman, thank you for sharing your knowledge about CRA. I learned a number of cool things. Didn't realize the SAM team was doing reviews of the CRA and providing feedback and going to their headquarters and stuff. So that's really cool. So thank you for sharing this expertise with us, and we look forward to seeing you at an event in the future.

40:40Robert HurlbutRight. Thank you, Chris. Thanks, Robert. It was nice to see you again, and see you in future events. Awesome.