The Security Champions Podcast

Nariman Aga-Tagiyev - Understanding the EU Cyber Resiliency Act: What You Need to Know

• Mike Burch • Season 4 • Episode 3

Share episode

Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.

0:00 | 1:03:09

Nariman Aga-Tagiyev is an application security expert with over two decades of experience in software development across diverse technology stacks, including cloud-native environments. Since 2016, he has been in charge of the Application Security program and the Secure Software Development Lifecycle, with deep expertise in frameworks such as BSIMM, OWASP SAMM, and NIST SSDF. 

In this episode, Nariman breaks down the EU Cyber Resilience Act (CRA) and why it’s far more than a regional regulation. It’s a global shift in how software security is expected to be built and maintained. He explains what the CRA requires, how it impacts software vendors and open source, and what “secure by design” really looks like in practice. The conversation also covers practical steps teams can take today to prepare, without overcomplicating their approach.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Podcast sponsored by Security Journey, Secure Coding Training for Developers and Everyone in the SDLC. Learn more at securityjourney.com. 

FOLLOW US to stay up-to-date with new content!

Get your free VIBE Coding Field Guide: https://hubs.ly/Q043-zdS0

SPEAKER_00

The Security Champions Podcast is brought to you by Security Journey. We help enterprises reduce vulnerabilities through application security education for developers and everyone in the SDLC. Learn more at Securityjourney.com.

SPEAKER_01

Welcome back to the Security Champion Podcast. My name is Michael Birch. I'm your host, and today I am joined with Nari Man. And I'm going to try to pronounce your last name right. Agategev as close.

SPEAKER_02

Yeah, yeah. It sounds good.

SPEAKER_01

So we are here. We're going to be talking about the Cyber Resiliency Act that is impacting the world, right? Everyone's been talking about, I've been hearing about is this Europe thing. It's not a Europe thing. It's a Europe thing, but it's a Europe thing that's attacking the entire world. And so we're going to be digging into that today. But before we get into that, like I always start, um I would like to start by hearing what's your security journey? How did you get started out? Where has led you to what you're doing now? And kind of tell me what you're up to. Thank you, Michael, for having me.

SPEAKER_02

Uh it's great to talk about CRA. I hear a lot from my colleagues in US that they're not aware of it. They don't know much about EU CRA. When they see this EU in front of it, they thought, ah, that's just something for Europeans. It doesn't apply to us. It's it does. It will completely change the way uh AppSec is happening as of next year. So it's great that we can reach the audience in the US with your help. Yes, I'm Nariman Agata Giev. You pronounce it super nice, it's very difficult surname indeed. And I've been in software development for maybe like 23-24 years since I was a child. I started uh I was a national team of uh sportive programming of Turkmenistan, where I grew up, let's say. And last uh 13 years, 14 years I live in the Netherlands. That's where I'm based at the moment. And I've been doing application security for the last 9-10 years, and I started first because some of our customers were wondering what we do we do for application security at the organization I used to work, and I volunteered to document all our practices, but as documenting I started to implement different stuff like threat modeling, SCA, SAST, DAST, Secure Design Reviews. And slowly that became my thing. And I enjoy explaining difficult things with easy language to the stakeholders, and I enjoy talking with very technical people at their level, technical level as well. So usually I act as a bridge between all stakeholders in organization and engineering department, and I enjoy it. I I like working with people, I like to build communities in the companies. Um as as of last year, I stopped my career at uh enterprises. I started my own uh consultancy company on cybersecurity, teamed up with a couple of very talented freelancers, uh, the best in their areas. And together we want to catch this wave of new legislations in Europe. We have CRA, we have NIST2, and we want to help as many companies as possible around the world to adapt and to implement it properly without too much overhead, with exactly being on the point, be strategically doing correct things, not wasting time, not wasting money. And that's not my goal. So I'm building a company. I'm saying a small startup now in the Netherlands, and this year for the first time I even will be at uh OVAS Vienna event as uh one of the booth sponsors, if all goes well. I'm really excited and scared. And uh yeah, but it's it sounds very nice to finally be on that side uh trying to present our team there.

SPEAKER_01

Yeah, that's so awesome. You know what? That that that reminds me of when we first met. So we actually met. Um, I'm trying to think, it might have been a bar, but it was an RSA thing, right? So we were uh I think uh a good friend of both of ours, Chris Romeo, was doing a thing. And I remember meeting you as about that time you were you just started transitioning and kind of doing this branching out and doing that that new venture. Um that's exciting. Like that's that takes that takes a lot to kind of like leave industry and kind of start your own thing. How's I'm gonna pick on that stream for a minute? How's that been? Like, how's that ride going from like the industry to uh the solo like build-it-yourself world?

SPEAKER_02

So it's uh it's not easy. I think I was extremely lucky so far, and I operate on luck. Um I I was like very lucky to find a few customers right after my resignation and was working with them, doing my self-free lancing work, actually implementing AppSec programs rolling out at very big companies a couple of days a week while building actual company more than a freelancer. But it's hard. I I have to work a lot, much more than you work for a salary, a daytime job. Sometimes your evening don't finish at 6 p.m. And I work in evenings because in Europe, evening is a morning in US. But I I jump on every opportunity I can find because I I took this bet and it just pleasure, so it does not feel like it's exhausting or tiring. I guess that's a feeling for most startup uh people, right? Entrepreneurs, and that's what I see in the US. When I talk with the different entrepreneurs that I meet at the events, like uh in the sponsor booth, when I used to hear from them that they start their days at 7 a.m. and work till like 8 p.m., I thought, how can I do that? That's too much. But now when I'm in this myself, I said, yeah, that's fine, that's okay. And because every moment you spent, you feel like you put very you are very efficient and you do something for your future, and you do something for your customers, you feel like um um they're that they're thankful to you, and and it's it's great.

SPEAKER_01

Yeah, that that's that's a different experience and viewpoint. Um especially around the fact that I think when we're we're in these kind of business worlds, it's uh there's a lot of abstraction between the work we do and the impact we have, right? Or the people we're reaching. Um going to that whole other world, I mean you you you have to be directly interacting with everybody you're impacting, and everything you do is an absolute investment into something you're passionate about. That's uh that's a really cool space to be. Uh, I guess oh, it's true that um if you love the work you're doing, it ain't work, right? So those long days become a little more acceptable. That's really cool. Yep. Yep. So as and I do and I'm gonna pull on a couple more strings before we transition and go to the CRA. I uh I one of the other things they like I'd like to pull into, my favorite topic, and some of the people I think that I I've seen in this space that do so well coming from the engineering before you go to be that app sec person, right? Um, so what what kind of I know you said you kind of you volunteered, you started taking on and started like building that out. What was the what was the formal? When did you like, all right, this is what I'm gonna do? I'm gonna be AppSec. Like, like what was that light bulb moment for you?

SPEAKER_02

I think I did this job for three, four years and next to engineering job. I was doing cloud architecture, DevOps automations, still some things actually outside of security and next to security activities. And in the beginning, we didn't have so much demand from customers. Like nine years ago, and we used to sell to huge customers and very serious customers that today absolutely will demand that you have a good secure soft developed lifecycle. But back then, a few of them asked, Oh, what do you do? Can you uh do a BCM assessment for us? Let's say BCM is a maturity model for application security. And we just wanted to satisfy the customer. But the more I went into it and the more demands started to come, I ended up spending almost whole time implementing AppSec programs and start to replicate the things in other departments. And I enjoyed it because actually I enjoy connecting to people. I enjoy asking questions, learn stuff and figure out like what people are doing and how they do that. And this uh new role in AppSec it opened lots of new doors for me and gave me opportunity to still do technical stuff, but meet new people all the time. Like talk with different departments and uh even like you you one day you work with DevOps person, another day you work with salesperson, helping him to convince some police department of some country that we are secure because they're gonna use our planning software to plan their secret assignments, for example. And and then in that call you say, Yeah, uh I I care for security as much as you do as our customer, and I put my own, let's say, um I I'm I take full responsibility own this as well. I'm not trying to convince you that we're secure, I really care that you you don't expose our private information. And uh it was great. It's a great experience as an engineer to be able to do the soft skills a little bit, get now there, a bit here. Um and after four or five years of doing these things, I decided to transition completely. So I asked our uh global security team and offered myself to rollout security champion program, to do threat modeling program. Uh I did in the SCA program, and the more I got into it, you discover more things, you meet with great people at uh OWASP events, right, that are really all into culture. And every time I come back from OWASP events, uh I have so much inspiration, so much new information, and start to just ask for um to have a coffee with some stakeholders. I say, look, I learned this, I want to do this. Um and I I think it's it's not for everyone. You say that sometimes when people from the engineering background, when they transition for AppSec, they become great AppSec people. True. But it's also not for everyone. Um not everyone can be community enabler or facilitate calls and because if you want to be a good community enabler, it's not about you. It's if you only make it about you, people will not follow you and will not be part of that. People want to be make it a bit about them or be about their network, about their friendships. So I enjoy just creating communities and staying a bit on the background, but uh enable people and make different departments talk with each other. When we make an objective for different departments to roll out an SA program, I would bring them in a call and it will not be a top-down call. I would say, uh guys, so what are your challenges? What are your successes? Share with each other, talk with each other, who wants to present next time. Um and it's pleasure, and and people like it. They start to make new friendships, cross departments, cross uh um business units. And it's pleasure to see them. And I I feel like I'm their friend as well for all these um departments.

SPEAKER_01

Yeah, that's one of my favorite parts is the community part. And it's interesting because um if you look at the market, right, if you look at people that are hiring these type of roles, um, you ended seeing like for the most part, that's pretty downplayed. Where most of the stuff that people are looking for and the hiring roles in the larger, I would say at least the US market around where I've been looking and seeing other stuff, it's heavy focus on you have to know every scanning tool under the sun, and that's all we care about. Like that's that's the number one priority. Um but I I I have to say, I think the the highly valuable people in those roles are those culture billionaires, those people that are passionate about community. Cause yeah, you can I could teach anybody to run a scanning tool, right? There's the results, go do something with it. Okay. But the person that's gonna build the relationship with the development team that's gonna make that actionable, that's gonna help actually like build that community and have them help and support in that process, that that takes a serious app sec person. Like what I consider someone to be a real app sec person, um, way beyond, like I said, the tools about that community.

SPEAKER_02

Well, you're absolutely right. I'm in software development like since childhood. I know lots of stuff. I started with Pascal C, I know Bitfortrance, I know how to break the memory stuff, but I I almost barely use my technical skills these days, and I do a lot of security work. Because as AppSec, if you want to grow into AppSec, you need to know some techniques, like how to structure a good threat modeling section, what questions to ask a threat modeling session, um, what technologies exist, what is what, what is SCA, like what's possible in the pipelines. So if you know a bit generally a bit of everything, and you just ask right questions, you learn how to ask right questions, almost 99% of the time um engineers know their problems. You just uh give them the floor and say, look, um, so let me draw what you're saying and in a nice data flow diagram. So you mean you have a service here, and do you have any ports open here? Okay, so let's draw that. And then you show it to them, they see it visually, and I ask them, okay, do you see any problem? Uh and almost all threads that I discover, it comes from those people, those engineers. And I'm just asking them different topics. Okay, let's think about spoofing, let's think about authentication a bit. And yeah, it's uh indeed when you see when you try to pass job interviews, it's all about what you know. They ask very difficult questions, but in reality, it's uh it's about your soft skills and asking right questions.

SPEAKER_01

Yeah, I I I definitely see us more as we're the facilitators, right? We're there to enable those engineered teams um because you're right, they have the knowledge, they have the skills, right? It's bringing those those things together and helping them uh giving them giving them the right tools, the access and the space to be able to action that in a meaningful way that actually helps us improve security. That's that's the goal of a good app sec person.

SPEAKER_02

But but Michael, also, I don't want to underplay the skills of some of our colleagues. I think if you want to build a good AppSec program and being a lead app sec program, you need to focus a lot on soft skills and ask the right question. But of course, there are lots of arrays where you can shine if you're very technical, if you're a secure architecture architect, uh, if you're a pen tester, um devse ops person, it will be able to automate everything and do all the magic. Uh, there are lots of niche topics where you need to use lots of skills. But what I'm saying, that I'm using barely technical skills, is because I'm driving the strategy of AppSec programs, trying to structurally assess them, like what we're doing, what we're not doing, and help companies to spend as little time as possible and get as much done as possible and have a proper AppSec program. And that's why here I need to use my facilitation coordination skills more in communication than technical skills these days. But definitely there are lots of topics that uh where people also need technical things as well.

SPEAKER_01

Nah absolutely. And that's a good call out. I think I get so my world's kind of like yours. I live in that culture world so much that like like I call pen testers pen tests and I don't even think about it as the app sec bubble. That's its own thing to me, right? Because I the because of the world that I live in, right? So stuff like that I kind of I can definitely lose sight of. So it's a really good call-out. Um, all right. I think we're at a good spot. I think uh I'm I'm super happy to have you here, but we're here to talk about CRA. So let's take a quick break. Let's uh gonna have a quick word from our sponsor. Let's jump on in and let's kind of dig it and understand how C what CRA is, how it's gonna impact us.

SPEAKER_00

The Security Champions podcast is brought to you by Security Journey. We provide diverse training content and easy to digest lessons to meet individual learner needs. In fact, learners report improving their knowledge as much as 85% on appsec topics. Learn more at securityjourney.com.

SPEAKER_01

All right, welcome back to the Security Champion Podcast. We are here to talk about the CRA. So let's start digging into this. What is the CRA? Why is it such an important topic for us to be digging into?

SPEAKER_02

So if you buy anything in Europe today, any electronics, a toy, a physical product, you would find a small sign, somewhere on the bottom of the box with a CE, usually it's here, and you would find a small paper inside, like in a medicine, that describes how to use it, what are the risks, other health concerns. It will say you don't lick it, it's a bad plastic for you, or don't eat it. So uh that CE sign demonstrates that whatever is sold in Europe is safe for the end user, for consumer. And it's not only about electronics, anything. And if you are importing any product to Europe, you need to certify and you need to have this label on it, and you need to have a paper that describes what risks are there in the product, what risk you took care of, etc. Now, with uh so many electronics and so many devices that we are buying as a consumers, like if you walk in an electronic shop, everything you see is there. Um consumers are also under risk and have lots of security risks, right? You buy a smart lamp or smart camera for a baby or a vacuum cleaner, and sometimes you use it for a year or two, and suddenly the app on mobile app to use it is not updated anymore, there is a vulnerability, and you you don't have any guarantees of protection. So European Union decided to extend this CE mark that you saw on this box on the bottom to digital products going forward. From now on, as of next year, if you buy any digital product or any physical product with digital components, like with some logic in it, with some software in it, they want to have evidence that it is developed with security by design and security by default. That you follow the proper uh application security uh processes, that you did your SEA while developing, that you thread modeling, that you have the diagrams, and that you thought about all the risks. You try to eliminate as many as much as possible. But also uh what you couldn't eliminate, you document in a paper which you need to host with your software next to it. Wherever you deliver the installer, if it's on-premise software. And by the way, uh I say products with digital components, but it also applies to any on-premise software. So if I install a mobile app or a desktop app to make some 3D drawings or planning app, anything. Anything that runs as a that I run as a consumer locally, maybe on some product physical or on my own phone or my desktop, or as a corporate, maybe in my data center even. So if I'm buying some on-premise installation of certain app, um, it has to be now serious compliant. It has to be developed with security by design, security by default, and they need to guarantee that they will support for five years all security uh fixes afterwards. So if there is a publicly um um disclosed vulnerability that is known to be exploited, they have to deliver hotfix for five years at least. And they have to make all the documentation available for ten years after placing that product on the market, once the product is imported to Europe. And as of this year, by the December 2026, the first part of the obligation starts, so incident um notifying the authorities that there is a exploit in your product. And that applies to not only newly placed products but everything you did so far. So what I sold already five, ten years ago, if I realize and learn that it's being ac actually exploited, I have to inform authorities now within 24 hours. And then within 72 hours, then give them an update. So this is what I'm gonna do, and within a month, afterwards give them final report, lessons learned, like how we're gonna fix it. And you have to do it continuously as a company that places any product in Europe. In US, well uh lots of products actually designed in you in US, right? Even if it's manufactured somewhere in Asia, uh and I think Europe is a big market for US companies today. If that US company is selling any mobile app or on-premise app, they need to worry and start to prepare for that and have proper evidence that they have a proper methodology. It's not only about having SCA. So you also need to demonstrate that I have a whole life cycle of that control. That I I designed the control, I defined, I I discussed with my teams what our risks based on these risks. We identified what security controls we need to implement, and then we need to have evidence that those controls are actually being done. So it's not only, oh, here are my controls, I have them. No. How do you come up with this control? That is also important. You need to demonstrate that I have this control. Also, I have SCA because my product is using these third party components, and I think I need to monitor SCA. And that evidence you also must demonstrate, because that is secure by design. It's not having an SCA tool. It's also how did you come up with those requirements? It's very interesting. And what is all even more is that all the backend services must be compliant to. So if I have a smart camera that is monitoring my garage or my house, and that camera sends some data to the backend and I I connect online via a browser to watch it, so all that backend also must be compliant. So if you have a time tracker app, for example, that is runs in the browser. That part, you think, oh well, it's not a product with digital components. So that all web apps normally are not in scope. But because that system is the backend of a mobile app, that is the data processing side of a mobile app that you actually deliver to the end user, suddenly that web service also must be compliant. So it's what everything.

SPEAKER_01

It's everything. Like this is a this is a huge scope. It's basically it it broadens a requirement, I think, um, to people that basically, I mean, in the past, I think I started thinking about embedded systems and stuff that like the the throwaway technologies that most people are like, hey, once it's out my door, I never have to worry about it again. And that that brings a whole new dynamic to that technology in group, too. And that's even a hard I would almost consider almost probably a harder one to solve when thinking about this stuff.

SPEAKER_02

Do you know what will happen if you don't do that? Let's say you sell a smart camera, and then somehow you're hacked and it's disclosed that people could see through your camera or something, and you don't do anything about it. And or you got into audit and they discovered that you didn't have any security practices implemented, or maybe you said you did them, but so for example, in your uh documentation you say that you changed uh default passwords and there are no hard-coded secrets. Maybe that's part of your evidence. But it turned out that you lied about it. You actually have hard-coded secrets. The fines are 2% of your global revenue, global revenue, not only in Europe. Uh so that's money that comes in before you do all the expenses. So as a US company, you are selling to Europe and you will get fined based on your everywhere, like global money you're earning. And in the worst case scenario, you just lose CE mark and you're not allowed to sell anymore. Then of course they have to coordinate between different countries that uh distributors need to pull the product back. It's a mess. And you have to have the declaration of conformity, this is a CE paper or SPDF somewhere on your website, in uh in uh every language to make it possible for all consumers to understand in Europe. So if you're selling in Italy, you have to have paper in Italian or in the Netherlands for Dutch and German. So it's um lots of paperwork and lots of preparation. So it's like actually selling physical product today.

SPEAKER_01

Yeah, that that's a huge scope uh over. Um, but it seems like here's the biggest thing I've heard in security all the time, right? Um the stuff I've done in the past, people have put out general regulations or guidances and stuff, but there's never been a uh I've never seen as big of a stick as this, right? I I I've never seen where they're like where secure by design has become a mandatory regulated thing that if you don't follow, that you could have this type of reaction. I mean, we see some stuff that you see like PCI DSS or some of these other types of things that if you want to be in this space, you have to kind of fall under, but nothing that's hit the every product everywhere. I got a question on this though, too. It's not the same for everybody, though, right? Like depending on what industry or what you're doing, like you have to follow CRA, but I think there's like different levels and different types of requirements depending on what you actually do, right?

SPEAKER_02

Well, if you are selling a product with digital components or on-prem software to Europe, regardless of your size, you must comply. So even if you are like a one-man company, you have to be compliant with this. But between companies that must be compliant, there are different categories. There are like four categories. So you have default category, any consumer product, mostly like devices for home, office software, like your planning software, uh, office apps that you're using, like uh like um Microsoft Office and stuff like that. Um they all fall under default category. And they will need to do self-assessment, have some evidence, and probably you will not be outdated unless there is some active exploit, and it turned out you were lying, etc. And I also saw research that there's expectation first couple of years nobody's going to find you or audit you proactively. But you must at least have that see it, the paper, right? You need to have this uh document published, so it's you still need to do stuff. You cannot just ignore it. You have to prepare. That's the default category. It's like 90% of all the products are there. And then you have like important products, uh critical products, a couple of more categories that are covering more critical infrastructure. The most critical category covers the water meters, um, the automation systems for uh energy sector and stuff like that. That if that is compromised, you're really in tr the whole nation is in trouble. Then you have more like important products where we're talking about network switches, modems, uh operating systems, um stuff like that. If you are in those categories, you will get more, you will get a uh external audit, and you will have to first get certified before you even sell. And there are some standards coming with certain guidance documents that will give you exact uh list of requirements, like control framework, what you need to comply with, what you need to do exactly. So for those companies, I don't worry. I worry about this 90% of companies that probably never did secure software development lifecycle so far and didn't think about it, and now have to structure it documented in some ways. And they will start to Google around, like, or let's say ask ChatGPT or other AIs what to do. Um and that's a bit difficult and it can be a bit confusing. But luckily for us at OWASP, we have some tools for that, and I want to bring up a couple of projects here. But maybe before telling of a solution, um I want to put a side note, small side note here. Europe is sometimes my US colleague laugh at Europe that you have so much bureaucracy and um so many rules, you have the GDPR and this and that, that you're so innovative with uh creating new laws and rules. And very often these rules just stop the innovation, right? They slow us down, they're not as competitive as the US companies. And yes, and very often those rules are not very logical and difficult to implement in practice. CRA is a bit different this time, that's my opinion. Because when European Commission implemented it, they actually invited the Linux Foundation, Eclipse Foundation, OWASP organization, and we went to Brussels. I went also. For example, we uh we have this OWASP SAM project, SAMM, Software Maturity Model Project. So this project is about how to build application security program structurally. So it has like 90 different activities, and you can assess yourself like a survey, see where you stand, you can use it as a baseline for your SSDLC security of life cycle policy. So SAM is the AWAS project for security product maturity assessment. So we, as some members, a few of us went there, we gave feedback. Um open source software community gave feedback, they told their concern that they're worried what it means for them, because if if I'm delivering an on-premise software but it's open source, I don't want to be fined for my pet project I'm doing at night, right? And all these feedbacks have been taken into account, and today's CRA is actually reasonable. I think it has reasonable expectations. It say it doesn't tell you what to do, it says you need to understand the risk focusing on the consumer, not on you. Like what are the security risks for the consumer, and try to mitigate them, try to define your controls, your requirements. And if you cannot inform them like what they need to do, maybe change their default password, like when they buy this device, for example. So the law is nice. Um now talking of SAM, uh today there are only two frameworks that help you to measure how good is your AppSec program, and one is uh um for profit BSIM, and one is OVASP SAM. That's very similar, they actually have come from the same roots in the past. Um but some focuses on securing your soft developer lifecycle. CRA focuses on the product security, right? So product but covering also physical products, I mean more. SAM can be used in practice theoretically, let's say to secure also your product, but it's using a bit technology agnostic language, you could extend it, and if you also think of physical threats, some is a perfect tool to use it as a baseline for your CRA preparation today. And a few things are not there, like for example, I just mentioned that you need to uh response to incidents for the first five years, you need to inform the authorities about it. The SAM maturity model does not have those requirements in it. It's a Europe-specific requirement that you need to inform any cell, this organization within 24 hours. It's it's a very law-specific thing. So SAM doesn't have that. But if you take SAM as an input, uh it gives you nice domains, all the activities, and then you document also what's your instant response, and you focus a bit okay what other threats I have because of this product being a physical, not just a software. It's good. It's good enough to structurally start as use it as a starting point for the CRA compliance. And I even heard from like my German colleagues here that their government explicitly recommends using some to measure, assess, and use it as evidence to show that you are ready for CRA, that you're having secure by design activities all in place. One maybe extra thing is when I because I mentioned that it's all risk-based. So CRA says you need to define your own threats and requirements. Some gives you everything possible. It has 90 activities, you don't need to do all of them. But one of the activities there says you need to do risk assessment and threat modeling. So those two activities actually describe diff helps you to define what other some activities you need to do. So like when you start to build the AppSec program, uh you need to do very detailed threat modeling, let us say, of your product. You need to document architecture, like what I'm using there, what components, maybe document a data flow diagram, uh if it's if it's a physical product, what comes in, what comes out, how the user is supposed to be interacting, um, what kind of data is processed with this product. And that must be a starting point. And based on that, you can define your security requirements. Okay, okay, then I have uh this back-end data processing service, so probably I need to protect that one and it's an API or web application. So I should probably do Dust, and then I have a source code, so I probably should do SAS, static code analysis. I'm using third-party components, I should have a CA. Threat modeling should be continuous. So you come on, come up with all these requirements, and then you keep repeating some assessments, and some assessments gives you the gaps. It shows you exactly what you're doing in a nice visual way. Uh we have a tool, so we have an Excel toolbox, we have a SAMI tool that helps you to do the interview and then shows you where are your gaps based on everything you can do. You then you can look at your gaps, some results, you can look at your security requirements that came out of risk, and you can define your SAM target based on the requirements you defined during the risk. Right? So that's the whole picture now, how it's all connects together. So to be ready for CRA, you need some, you need to do risk assessment. Based on risk assessment, define the targets for your gaps or priorities, let's say, for your roadmap.

SPEAKER_01

I love I love how they leverage the community for this and how it all marries really well. I think that's extremely powerful. And also it kind of ties everything we're talking about, right? Because we talked about like a the majority of software you're gonna end up here, right? And then and these criteria, as long as you're doing this, it sounds like everybody's gonna be reasonable, right? Like start working, proof work, get things rolling. We're not gonna come witch hunting you down and trying to make sure that like like um come after you, but like like you need to take this seriously because the impact, the impact is very, very serious, right? Um and it's all I think in the right direction, right? Like the stuff we're talking about here isn't busy work. It's not stuff that's like, hey, go do a threat model because it's on a checklist when we told you to. It's the way you framed it. We're gonna do a threat model because it's gonna inform everything else we're gonna do here. So there's a reason behind it. It's a driver that's taking us to everything else. I think that's I think that's really, really important for us to kind of realize that this the this seems seems reasonable, right? As we're kind of coming through. I did want to I did want to pull on one thing you brought up a bit earlier, right? Because you you talked about open source projects a little bit, right? Um that's a really good point that I'd love to kind of understand a little bit better, is as these open source projects, what are their obligations? And and I I I mean, it's interesting because we talk about the ideas that like in open source projects, they they want at the table probably have like, hey, we have some concerns about how this impacts us. But there's also probably the the there's some big open source projects that I want to make sure are probably doing this because they're pretty integral to the way that they're being used across the rest of our products, right? So um, I don't know. Do you have any other insights around that kind of relationship with the kind of the open source um software world?

SPEAKER_02

Yeah. Lots of people were concerned from open source community with this, because they don't want to get fined. And it's nice when you do it voluntarily, you enjoy it, but when somebody tells you, no, you must fix this box within the next five years, yeah, they wouldn't want to be told what to do in their pet projects, even in hobby projects. Um they're fine. Um Sierra describes um has like three um roles related to open source. So you have a contribute contributor, somebody that contributes in their free time to open source project, and they don't make money out of it. Maybe they can have a donate for a beer, buy me a beer button or something, but it's not enough to make a living out of it, and it's not enough, it's not for making a profit. So this will be tolerated and they are not making profit, they are not liable for anything at all, and they're not asked to fix at all the problem, security problems. Then you have maintainers, so these are the owners of those open source libraries, and if they are not making profit, they're also not liable at all. But then you have some maintainers who do make profit. So some companies make an open source product, but they also have a uh service for the same thing. You see it very often. So they say, okay, we sell this, it's our business, but you can see our code, it's open source. Uh those companies must be compliant, they're liable. So the the first company in supply chain that makes money of it is liable. So then you have, of course, the manufacturers, actually the companies that make the product or the software that rely on these open source libraries, they are making money first in the supply chain. It's their responsibility to make sure this product is compliant, and their responsibility is to make sure that those open source libraries are fixed. So you're going to pick the one that you trust that it will be fixed, because otherwise it suddenly becomes your headache, because it's your obligation to protect your customers and do whatever is possible for that. And it will transform the open source community, in my opinion. Because today sometimes they don't get that recognition, they don't get any compensation for what they do. But now the companies will care for you. They'll say, Well, we rely on your software. Can we help you with anything? Can we sponsor your trip to a WASP event or somewhere? Because if me as a manufacturer making money and I rely on this that freelancer or that open source contributor, I want to make sure that they actually still continue doing this. Um yeah, and there's also another player in this full open source uh picture, it's a foundation, like Eclipse Foundation, Linux Foundation. Uh they have also some uh responsibilities. They're obliged to have collaboration with authorities and facilitate and coordinate delivery hotfixes wherever it is possible. So as a manufacturer, if you pick an open source library that is hosted by Linux Foundation, Eclipse Foundation, or such organization that stand that um hosts this tool, then uh you you are fine because they can say it's their responsibility to fix, it's not mine, so you don't have to that worry about it. And if you are using a third-party library which you pay for, not open not for free, then when you buy it, you also need to have proper contract in place that that company that is making profit on their part, they are responsible to deliver hot fix within the next five years if if needed. So the whole that supply chain collaboration, everything becomes very different going forward. And one of some activities says, Do you have requirements for your supply chain? So do you have a checklist that you use when you buy software? And most of the time that's ignored. And now you cannot ignore it because if you're buying software, you must write in your contract, look, now I I can be fined for 2% of my global revenue. And I don't if it's because of you, I want to make sure that you act and do something about it. And uh and I want to transfer my responsibility to you on those things. Um so it will change totally the landscape.

SPEAKER_01

Yeah, I I could see that being a big one because you do have such a there's such a large amount of this open source community that are those nonprofit practitioners, right? That are they're donating their time. It's interesting as these larger organizations are now becoming, they're holding the responsibility of the third, like these open source projects they're using. The question will come does it make more sense for them to own that responsibility and fix it and be liable? Or would it make more sense to better support financially or otherwise these other maintainers to push that liability back down away from them, right? Because at some point it has to be kind of a cost decision. Like at this point, you know what? I might just it might make more sense to convert some of these people that we weren't paying for their software before to we just pay them now, because it's actually gonna reduce my liability burden rather than me having to own the liability of patching, maintaining, and fixing that. And if I don't, I'm the one that gets in trouble. So it's kind of an interesting dynamic. I definitely think that this can impact kind of the way the whole OS open source kind of world kind of works going a little bit in the future.

SPEAKER_02

Yeah. And the way that SCA program is done now with shifting, changing a bit. Because before, if you want to be compliant with SCA and you want to tell your customers, yes, I do SCA, it's enough to just have an SA tool. A pipeline that creates SBOM and maybe monitors your vulnerabilities for whatever you have. And that's the best companies do, most of the lots of companies, let's say. But now what is also being added is they they're shifting it a bit earlier. So before the component is being used or referenced, they also already want to have some check there. And some of SCA providers today, they allow you to create some rules that it gives you a score, the quality of that sort of component, right? That is it maintained, how many contributors are there? And when is last time uh was updated this open source library? So that kind of insights in SCA too becomes also very important going forward because you want to only use what is actively maintained going forward.

SPEAKER_01

Yeah, it kind of turns because before SCA was about a lot of it was like, hey, I have an S-bomb, I'm doing SCA. If something comes out, I can react to it quickly. That's really what the idea was there. Um or I can reduce threat by maybe, oh man, this one has too much known vulnerabilities. Maybe I'll go with a different package. But really, at most there is really threat mitigation, right? Um, versus this one now becomes like it's it's it's a liability, right? Like that's what it goes back to. This becomes where we're converting just threat into pure, oh man, if I take an unpacked unmaintained package, I'm probably accepting liability here that I'm gonna have to do a whole bunch of work to maintain myself, otherwise I'll be an at risk beyond just the threat of exploit, but like governance, right? Um, so that's that's interesting, is the way even the even the purpose of those tools and some of the way that we look at those are gonna kind of change over time. And that that goes back to so I'm I remember when S-bombs were first kind of becoming a thing. Um, I I do remember when that when people first started talking about there was this big hype of people that were going, uh it doesn't do anything, it doesn't change anything, it's not real security. Like that there, I heard that quite often. They're like, so what? It's an inventory list. Um over time, I think that's slowly being oh like, yeah, but let's talk about log 4j. Let's talk about the man hours people spent trying to figure out if they were actually affected or not. Well, the people that had S-Bombs and did this right knew immediately if they were affected, and if the people that didn't it had a whole lot of work to go do, right? So that was one of those first visions of why that was such an effective approach. But now we're now we're like doubling down on it. We're adding to that as part of that kind of thought process.

SPEAKER_02

And by the way, on the S-Bomb side, uh the law, the CRA, doesn't require you to disclose it to customers, but it says that the authorities are allowed to request it from you because they might decide to um have a database and get some statistics, what is actually being used. So like which libraries are being used in Europe in these products the most, and to understand a bit their own risks and do statistics and uh intelligence there. So you and SBOM is one of the requirements that explicitly mentioned, so regardless of your risk, you must do SBOM always. So like every company that sells to Europe now has must have an SCA tool or something. You have in you don't have to buy even one. Well, that's another topic maybe we can discuss with you because uh you you might think now you're forced to spend lots of money and get all these tools. Uh yeah, if you go to sponsor floor, everybody will try to convince you you must buy tools, of course. But at OWASP, we have 350 different projects, right? And you have a project for everything there. And we have dependency check tool, that is a console app you can put in a pipeline and it will scan and create your SBOM if needed. Um and fail your build if you have like vulnerability. You have dependency track that is a more tool with UI, like web application, that can manage your portfolio of your S-BOMs. You can upload it at your build time when you release. For every version that is actively being used by your customers, you keep that S-BOM in OVAS dependency track tool. And that one will notify you, you can create notifications. When there is a problem, uh the product owner will be will hear about it with an email from that. You have a Zap tool, right, for DAST scanning, for the dynamic rescue scanning. Uh SAST tools. Everything is there. So you don't need to buy anything, but you need to check out what is available and use it. Of course, if you if you don't know what you're doing, it's always easier to get a consultancy company and get to the help to figure it out. You can buy a big corporate product or small consultant company like us, advertising, uh, that will help you to put out the cheapest options possible. Uh everything is uh yeah. Everything is there. Knowledge is there. If you go to any event like OWASP conference, uh and other conferences in the US, there are so many today these days. Everybody is willing to share knowledge for free and teach each other. Like we are growing all together. Um and it only will benefit your product, your reputation. I don't see a big problem in this, except it creates lots of work, uh, and then you have to have finally forced to think about security of your product that you're selling. And it's they expect bare minimum. You need to do bare minimum to make sure that you don't leave default passwords in the things you sell. That should yeah, that's obvious things.

SPEAKER_01

So it's uh it's interesting, and and you got me thinking here too. Um so, first of all, like the open source stuff, man, and I I can't emphasize that enough. Even if so you're gonna you're gonna you have to do it and you're gonna spend it one way, right? You need to spend man hours and you're gonna figure out how to use the open source tools, or you're gonna throw money at the problem. You just gotta pick which one you're you're willing to give to make sure you do it right, right? Um, but I can't emphasize this how amazing the open source tools are. I and and I'm gonna I'm gonna pull on like we're talking supply chain stuff and some other stuff here too. Um, one that I've learned of just this year that it really wasn't savvy of until recently, um, salsa, another another thing. I don't know, have you ever heard of salsa as kind of a framework around supply chain security? Um I gotta I gotta reference that more. Um so I'm doing stuff at NC State here. Um there's uh they have a huge emphasis on supply chain security at the local college here, right? So a lot of the professors up there are working on a really a lot of cool projects and other things around that supply chain stuff. The way I explain salsa, and if anybody hasn't heard about that, it's from kind of bringing it up, you should check it out. Where S bombs are the ingredient list of what you do. Um, salsa is like everything else in the supply chain that isn't components. Um, so a good example, I would consider it like like if I were to, I like to bring it to the food thing, right? So if the S-bombs, the ingredients, salsa is like making sure you wash your hands before you touch the food. Like that's the that's that's the other side of it, right? Because you might have all the right ingredients, but you can still contaminate it, right? Like that's kind of the that thought process there. So just want to pull, do a little plug for another um awesome open source project, learn a lot about, go, go, go apply that into your kind of communities and stuff. But it goes back to there's so much stuff around the community, the people that can support you this. There's a lot of stuff the CRA is asking for you, but you're right. It's not it's not a shopping list. There's a lot of free products that help you do it. And even if if you have, if you're a smaller shop, go try one of these products. Like, like most of them, but like I will say this go back 10 years, and some of these projects might have been um a little less on the UX side, a little harder to use, a little harder to understand. But in the last 10 years, I will say most of the open source projects I've seen, whether it's Zap, um Um Threat Dragon, like all these other tools, they've had a huge uplift on their usability, their design. Like that's one of the biggest things I've seen shift in these last, like, like I would say decade is the quality of the user experience for these open source projects have become amazing.

SPEAKER_02

And quality is amazing. Some tools are better than commercial tools, and some standards. Like, look at Cyclone DX project. Over Cyclone DX project, it's a standard, the let's say the way that you define the S-BOM file, the date structure, the specification. And it's so well defined and so broad. It covers, of course, software-built materials, but you also use it for other things like what services you rely on, what hardware you have. Like it's it's lots of flavors, S-Bombs are part of the Cyclone DX project. They have hundreds of tools that you can use for free in your pipeline to generate S-BOM on the fly. Um and they are collaborating with authorities, with the European Commission, with some standard bodies. We are working. I member, I'm a liaison of OWASP at ISO organization these days. And they are working on the new updating new standard 2734. It defines application security, how to build application security program. And we're tightly working between OWASP, Sam team, and a few other volunteers from other projects with this ISO organization. Cycon DX organization, they got their standard approved and the one that is referenced by the CRA. Uh, like as, okay, this is the standard that you're gonna use to create S-bombs. And as OWASP, even though we are mostly volunteers and it's like self like somehow it works, we I I heard that OAS only has seven, eight people on a payroll, and we have like hundreds of thousands of members. It's like self-living organism. I'm I'm amazed how we are self-organizing ourselves without like really like central leadership telling us what to do. Of course, we have a board that helps us to do events and stuff like that, but we are doing a great job there. And lots of the standards indeed they are becoming industry standards. They use, they're referenced by uh lawmakers, and yeah, it's they're there for usage.

SPEAKER_01

I I I love so OWASP is such a great community. But my other thing too when I think about that, the the OWASP stuff too, it's so diverse. Um, I actually, interestingly enough, even for my own organization, right? We have a handful of people that are kind of involved. We have somebody that's kind of silently involved in some upcoming projects, and we have I have a person that's a non-security, non-engineer, like it's it's in a different role, account management, stuff like that. That's uh they're OWASP chapter lead now because they're just part of our community. They love the the space and the the the way they got into it is actually we would run tournaments. Um we have our education platform, right? So one of the things gamification, run tournaments. So we go we go to OWASP and we run free tournaments all the time. It's our kind of way of giving back to the community. So the person we put in charge of this ended up becoming a leader at the Vegas OWASP chapter because they got so involved in the community. And it was a non-def non-developer, non-security person that just started to become part of that community. So such a yeah, such a great place to be a part of.

SPEAKER_02

And Michael, because we uh we covered so many different topics and probably we scared now our listeners a bit, right? Like, oh, now I need to worry about this new thing. Uh just to give some head start to people, I want to give like concrete uh things. First, if you don't have any documentation of your architecture of your product, you must absolutely do that. And you will need it anyway for new hires to show like what architecture you have, what components you have. So it's very good to make architecture diagrams, the C4 diagram, for example, at different levels, like have a high-level architecture review, like a more detailed on module level. That's starting point. Data flow diagrams, because you need to track like what's come in, what goes out, and that's the easiest way to find the problems, like DFT diagrams. Once you do that, next absolute necessary step, threat modeling. Because if you do threat modeling of that product, and if you focus on the consumer, not your organization, on the threats that are applicable to consumer, that gives you the threats and you can get requirements out of that. And then you need to check over some to do assessment and lots of paperwork, documentation, writing down like uh what's um like how you do that. And that will put you in a very good position. So we told talked about many things, right? And I I I I hope we informed our friends about CRA now so they know where to start and talk what to do and what it expected from them. Uh but I want to give concrete couple of steps, like what to do, where what's next for them to make it easier. I would say starting point, document the architecture of your product. Document what you have. Maybe check out C4 diagram, you can document your product on different layers, like what you're using, when you're big hires context, what are the modules inside it, and this will be useful in any case, even for the new hires, etc. So step one document the architecture and add data flow diagram because that shows what comes in, what data goes out of your product, how it reaches the backend for the processing, etc. So the architecture diagram, data flow diagram, that's absolutely the starting point. Threat modeling, yeah, that's uh the the brainstorming about what can go wrong in your product, that is absolutely important next step. That you make a bit of time with a developer, with architect, with product owner who understands how the product is actually used in practice, that you brainstorm together do threat modeling activity, you look at your data flow diagram, at your architecture, and you discuss what can go wrong, and you need to focus on the end user at the consumer. Not what can go wrong for me as organization, as manufacturer in my back-end processing facility, what can go wrong for the end user, because the target here is to protect the end user, the consumer. So you're doing threat modeling, focusing on end user. Then you write down just everything that comes in your mind, right? And typically that what you do in threat modeling. Maybe some things are realistic, some not, doesn't matter. Every idea is great, just write everything. And then you're going to assess it and you you see what is actually unacceptable. So you want to identify which risks are unacceptable. And to cover these risks, you will make a list of requirements that you need to implement. Maybe you think there is a risk of a third-party component, or you make uh a program tool to identify it earlier. Maybe you see a risk that there is somebody can breed force at port. Maybe you have two-factor authentication, etc. And once you have these requirements, next very important step is to understand what actually is being done. Because very often companies have a policy, okay, this is our standard, this is what we are doing, but reality is very different. So OWASP SAM assessment, software assurance maturity model, is a tool to uh assess your current situation with every product you have, with different you can do it for every scope separately. And it gives you this kind of survey that will help you to see visually like what are your gaps are. And then you take your gaps. I mentioned that, you took it your requirements, and uh that way you define your roadmap. And next step is all the paperwork. So now, because you need to provide the evidence, right, of all the things. So you need to document what was your methodology so far. So you did it, you did architecture documentation, you did uh threat modeling, you defined requirements, you did uh some assessment, and you document all the controls. But you need to describe, okay, this is my life cycle of this control, this is how I came up with these requirements, and this is how what uh I decided to do. And these risks we covered, this risk did not. So the all the paperwork, that's uh for some people it's pleasure, some people find it's boring, but you need to have evidence documentation that you actually did this whole flow, full process. And afterwards, once you have these controls, you need to continuously validate and verify them. So validation is checking that the controls actually meet the requirements, and verification is that those controls are actually being done, what you described in the policy. Uh so you need to have verification steps for sure. Uh so when you have an audit, you can always demonstrate, well, I told in my documents that I'm doing threat modeling, here's my threat model. I'm actually doing this. I told I have a CA, here's my S bond. Uh, and I do it check in for instance regularly. And if you have that, and I think this absolute bare minimum and it's a good practice, whatever I've done told so far, uh, you are in a good shape for CRA. So maybe you just need to document a little bit and summarize what you're doing uh to have it as as evidence. Um and you're fine. So later next year when everybody starts to get ready for CRA and then start you maybe find some templates of that uh document that you need to share. You you take it and you just create yours, host it on your distribution uh server of your binaries, and you're good to go.

SPEAKER_01

Yeah, and and that's great. That's that's such a great wrap it up. It seems intimidating, but we have time. And as long as you start working on it, it's manageable. And to be honest, it's things we should all be doing anyways. It's not busy work, right? It's gonna only make you more competitive, it's gonna make your product better, it's gonna make your processes better. Um, so that it's something to embrace, not not be afraid of, I would say.

SPEAKER_02

Yes, for sure. It's a great for your reputation and for your product security. And there is nothing bureaucratic or unnecessary in this process. It's actually it's for your own benefit and for the benefit for your consumers.

SPEAKER_01

All right, I wanna I want to thank you so much for giving me your time today, jumping in, having this deep dive conversation. Um, I know and guarantee our guests, um, our listeners got a ton of information out of that. I'm still learning a whole bunch about the CRA. It's huge and packful. People need to, this is the time to learn about it. This is the time to do it. So I really appreciate you taking your time and kind of kind of sharing this with us.

SPEAKER_02

Thank you, Michael, for making this podcast available for your listeners. I think it's a very, very important job you're doing. Thank you so much for inviting me.

SPEAKER_00

The Security Champions Podcast is brought to you by Security Journey. Security Journey is an enterprise class secure coding training platform with lessons that are built on learning science principles to deliver long term, measurable results. Learn more at Securityjourney.com.