 Hi, this is your host Aplin Bhartiya and welcome to a brand new series, TFI are pioneers, where we showcase some of the moves disruptive and innovative startups in the space. And today we have with us, Yoad Fekete, co-founder and CEO of Mirror Security. Yoad, it's great to have you on the show. Great to be here. Excellent. And since we are kind of debuting you with this series, so talk a bit about the company, what problem that you saw in the space because security seems to be a solved problem. It's also a very crowded space. So what gaps you saw in the space which led to the creation of Mirror Security? First of all, thank you for having me. So a bit about why we started Mirror. So my background is technical, I've been DevOps engineer for the most of my career in my last role before starting Mirror. I led a group of DevOps engineers at Microsoft in the cloud application security team. And Microsoft was one of the companies that has been attacked by the SolarWinds attack. And my team was part of the incident response team. And so after the attack, we were looking for something that, you know, a solution that can kind of detect those kind of attacks next time. And we couldn't find anything, at least not anything that it's kind of easy to integrate and can help with both open source and your own software development lifecycle. That's where we decided to kind of start the company. I want to talk quickly about the evolution of security that you have seen over years, all the way from traditional IT to full cloud-centric, cloud-native. And this week, you know, AWS Reinvent is going on and I'm pretty sure they'll run a discussion on security. So let's talk about how you have seen security change over years. Yeah, good question. So, you know, at first days, when I started as a system administrator, right? So I was maintaining and building, you know, data centers and, you know, security for on-premise, networking, et cetera. And now over there, we were very focused on the infrastructure, on the perimeter, firewalls, you know, those kinds of things. And things have changed, right? The perimeter today, it's not that today you can kind of go to a web server slash admin and then put like the default credentials and you're in. It's not the case anymore. Today, the perimeter is very strong. You have zero trust. Everything evolved from on-premise that we as system administrator, we had to secure and today you get, you know, the AWS Azure, GCP kind of security baseline, which is amazing. So now it's shifted from the infrastructure level to the kind of configuration and application level. And I think that's the big evolvement because we kind of close the gates, close with closed the perimeter. And now we kind of shifted to application where developers can kind of bring anything they want into the organization. So you close your gates, right? But you still allow your residents to bring anybody they want in. So how do you tackle that? So that's how I see the shift in seeing the security from kind of the old days to now. And what are some of the security threats that you are seeing, which either you look at them are new or you see are becoming more sophisticated? If in the old days, people were very focused on, you know, kind of open ports or, you know, trying to map open servers and accessing those, it's not the case anymore. And even SQL injections were not kind of where we've been 10 years ago. It's much, much harder to access through those means. So, and since open source grew up so much like in usage, you see attackers trying to kind of attack the weak link in a change, right? So if I'll take an open source, like very used open source, but it's not as strong as in security as an enterprise company. And I attack that one by doing that, I'm able to get to a lot of other companies. So that's a big incentive. So we're seeing that a lot. And it can be by taking an open source by a phishing attack or by just, you know, trying to enumerate password if the person doesn't have a multi-factor enabled, all kind of ways. But the incentive is to get to an organization or an open source project with weak security and get to as many companies as possible. One more thing that I want to talk about, and this could be a sensitive topic, you're based in Israel, Tel Aviv, Middle East, Europe, big war is going on there. There was a point where we're also worried about the cyber security, cyber attacks will happen. What are you seeing from the perspective of cyber attacks because of these two big wars going on there? So this is very close to my heart. So we've seen increase in cyber attacks and today I'm on reserve duty these days. And my role is to enable security on some of the defense forces, you know, let's say products or stuff like that. Probably I can, this is the only thing I can say. We've seen attempts, but I can tell you that, I don't know if it's because of kind of Israel is known as a cyber nation or because it's just important as we see it as a very important capability to defend our perimeter and applications. So we do see a lot of attempts, but they are being stopped at the gate. And the other thing is that in terms of the resiliency of those companies, not specifically cyber, the whole economy. So I think at the first two weeks of the war, it was very hard to kind of work because this is a very small country. So everybody knows somebody that's been affected directly and in our company, we have somebody that survived the terrible Nova incident our head of DevOps and one of our other employees had a partner killed in the same kind of event. So we've been affected directly and those people, a lot of people know other people, but you know, we're almost 52 days after, I think. And it's amazing to see how people are recorded as citizens, not even in the army to kind of revive the economy because it's important for the resiliency of the nations, of our customers, of our products, of the cyber community and other products. You also mentioned open source. Talk about the importance of open source for mirror security. Not even for mirror security. You know, basically all companies, including us, we use like 80% of our code basis open source, right? And it makes sense because if I'm a developer and I need to write software that does one plus one, there's something out there that does that for me. So why waste the time? And this is to thank the open source maintainers out there, hopefully listening because that's a huge gratitude that we need to give them. And because it's 80% of the code base, that's why the risk factor is so big. So for mirror, we understood that we need to verify those open source for not only vulnerabilities but software integrity. How do we know that nobody injected or tempered with their process, with their CICD process? You know, enterprises protect their pipelines and their organizations with a lot of means and they put a lot of money. But how would you know that your open source uses the same means that or stands in the same security practices that you've kind of set as a policy for yourself and you know, kind of a spoiler alert, they don't and they shouldn't. As a consumer, we need to say thank you and we need to find a way to verify that integrity on our own and that's what we're doing here. Now let's talk about mirror securities rule in helping organizations with improving their security posture. Talk about what kind of offerings you folks have for them. So basically we do two things. So one is that we protect our organization from supply chain attacks originating from their open source and supply chain attacks that might happen in their own organization like happened with. SolarWinds or 3.6 and for open source it's what we've seen with PyTorch or UA Parser or CoIGS, those kind of attacks are not vulnerability. That's the main thing and we've built a unique binary to source technology that can actually verify the integrity of software without even need to be integrated with it. So that's what I was talking about. As a consumer, you need to verify that. That's our main uniqueness. Other than that, of course, we also detect vulnerabilities and we help prioritize those vulnerabilities by using reachability that means that basically we check if your code actually uses the vulnerable function because if it doesn't and I go back to my calculator example before, if you're using it to do one plus one and the vulnerable function is in the multiply function you don't need to fix that. And organizations today has a huge alert fatigue coming from traditional scanners. And that's something that has to be kind of fixed today to give better context about what you have in your organization, what needs to be fixed and give as much as concise information that you can give to the developers so they can remediate those vulnerabilities and attacks quickly. When we talk about security tools or their technologies are there, but I think equally important part is cultural aspect, right practices in place. So first of all, talk about the importance of cultural changes that you feel from the perspective of major security and how satisfied you are with the kind of culture because it's a big, you cannot paint every company the same as in a brush because different companies they have different kind of cultural but how happy or satisfied you are or you feel, no, we still need a lot of cultural changes within organizations. So yeah, let's start from the end. Unfortunately, and I've seen that in every organization I work for, okay. As an engineer myself, which is very security oriented when I need to run fast, when my boss expects me to ship software, I couldn't care less about security and he can care less because we're engineers by heart. So that's why you need processes in place. The security organization needs to define what they expect. So if they expect that no attacks, no temporary attacks should happen, no high or critical vulnerabilities should be deployed or they should be treated with an SLA of N days and no new dependency with critical vulnerabilities should enter the code base. You should be able to define it as policy and not like a document, right? Because nobody reads that. It's need to be set in a policy. It needs to be strictly integrated to the development ecosystem in an easy concise way and then it should enforce that and it should be an involvement because as a security practitioner, you care about security and you want to verify that application are being deployed safely and swiftly. As an engineer, you need to be aware of that but it's not something that I think that engineers care about on a daily basis, right? That's what I've been seeing in my career at least. These days we also talk about, a lot of students we are talking about culture, cultural changes that are happening. We started talking about platform meaning, of course, DevSecOps, it has been around for a while but we have also been talking about things like infrastructure is good, security is good, security, governance. So talk about it, what kind of paradigm shift you are either seeing and you want to break free from the old practices to get some of the benefits of things like, infrastructure is good, security is good or platform engineering. Let's shift away from security for a second as a DevOps engineer, infrastructure is code, is like it's gold. I think that should be no other way to create infrastructure. As far as security is code, it's important but it's not something that I expect developers to do still and in that case, if you have a good platform that allows you to set policies and integrate easily into your existing development systems, I mean, that's good. I mean, you can define it as code but you don't really need to define it as code because again, even if you have security champions within the teams, they should be the communication channel with the security team but they still need to be focused on business, right? As much as possible. So whether if security is called, helps with that, that's great but I still think that there are other ways to integrate and enforce and build security easily with just using a good platform and user interface. One more thing that I will talk about is and this is one of the hottest topic these days is Genitive AI. Talk about the impact of Genitive AI on security and security for Genitive AI. Okay, so let's start from I think the first one. We develop, even before Gen AI started, we develop our own proprietary model for detecting code tampering attacks and I see today how Genitive AI could have helped with that and we do use a lot of it in our product. It gives you context. It allows you to do feedback loops with incidents that you get in. It allows you to get insights to your users on the platforms but you need to be very aware of what you're using. I mean, don't use Genitive AI for everything because it's not a deterministic thing, right? You need to verify what should be used with Genitive AI and what should be used with proprietary models and if at all. That's one thing but it's made a huge impact and I think that companies that won't leverage that will stay behind every security company. I don't think there's a security company that didn't or won't kind of incorporate LLMs into their products and security wise in the models themselves we're using a lot of the dependencies. So let's talk about the PyTorch incident that we've seen that happened that a code and being injected to the Nike build and it's kind of we're using dependencies in other platforms which are not necessarily the traditional development system we're using because it can be used let's say in Jupyter Notebook for example. Those are other things that we need to be integrated in. We can check them probably in the same way because those are dependencies and it contains code, a lot of it is Python, that's great. We need to make sure that we're integrated in those integration points to make sure that the AI models we use which are basically packages are being verified as well. And I'm putting DLP, right? I'm not talking about chat GPT DLP and how to make sure we're not putting sensitive data in which is important but that's another kind of privacy or data privacy aspect which is totally important as well. Earlier you were also talking about known and unknown risks. Can you elaborate a bit on that? Yeah, so I think that most of the security professionals I'm speaking with today, especially the executives among them, they are very aware of the known risks, right? Because we have a vulnerability, it's documented in the National Vulnerability Database, somebody found that, you can go ahead, you can go there and see if it has a fix, if it's exploitable, but then there's the unknown risks. So let's take the jump cloud incident for a minute. It's a 600 people company, not a huge company, many customers, great product by the way, we're using it as well. I think that if I were to speak with their CISO before the incident and tell them, listen, North Korea is going to attack you and infiltrate your commandment control server inject malicious code that you will deliver to your customers, he would probably do either two things. He would say, I have security products, I have security scanning or either he will kick my face because that's a very weird story to just tell you that somebody from North Korea is going to attack you, but it happened, right? Why? Because first, if you're a software company, you're a target. That's one thing I can leverage you to access many other companies, which is an amazing incentive. And the second thing is that security, the executive and professionals are still not aware enough of unknown risks. So if you don't have a vulnerability, it doesn't mean that the open source you're using or the software you're using or your own CICD platform hasn't been breached. And no AST scanner will tell you that today. They will look and they will say, you have zero vulnerabilities and that you kind of get the false sense of security that you're a self. So if I could resonate one message from our conversation here today is to tell people treat both risks in the same importance. Now I will talk about the company and your own role in this ecosystem. There are a lot of security is a very crowded space. There are a lot of players who have been around, you can call them traditional security vendors. And then there are folks who are born in this post-cloud native era. Talk a bit about how you, I mean it's easy to say how you differentiate but I really want to see what place you see in this ecosystem where we look at those incumbents, traditional security players and also the modern security players. So we see a lot of evolvement these days with security companies that they understand the incumbents. They're doing a great job but I think it's kind of what happened with SNEAK and when they came around then they brought their innovation when check marks has been around and veracode has been around and white source, et cetera. But they said, okay, we have kind of a new economy that we see that we should be integrated as shift left as possible. And that kind of changed the whole application security world 10 years ago, even probably less, but something like that. And now we see other kind of evolvements because we're cloud native and application are being deployed every day, right? It's not every couple of weeks, not every month. And so application security testing is part of what should be part of like the process we do every day. So the new companies we see around are trying to help with the amount of friction and the amount of alert fatigue that we're seeing from existing even newer products. But, and those products kind of left at that state where that throw a lot of noise at you and the newer companies are trying to compensate for that and tell you, okay, let us help you. Let us upgrade your vulnerabilities. Let's see it in context because you mentioned cloud native, right? So we can now, when it's not on-prem, we can see what you're using in your code. Maybe connect that all the way to your AWS cloud or Azure or GCP cloud. And then we can correlate it back, right? Because if you have vulnerability, which is only exploitable if your server is open on port AD80 and it's not, why fix it? And that's an immediate and important impact on the business. And I think that's a lot of the companies you see today that trying to put context on top of issues that you get from existing product today. Can you talk a bit about the plans that you have for the company you folks just came out of stealth? Just, I don't want to talk about the next five year plan, but some immediate plans that you're looking at expanding the company or growing the company. First of all, we're looking to expand, of course, more in US and Europe, that's one thing that's go-to-market-wise, so we're doing a lot of work there. But I think the second thing is that now that we're working with our customers, I'm happy to hear that most of them have the same requirements. So what we're doing is we're kind of treating our customers as partners. And they see us in the same way and not as a vendor-customer relationship. So we work together to understand what is their currently DevSecOps plans or guidelines, work with them, improve that, learn what they do, what they need, what their customers expect them to do, and then build our roadmap according to that. So that's what we do today and that's what we're planning to kind of keep doing while we evolve and add more customers to the platform. It's getting harder, right? Because as you have more customer, you have more demands and it's harder to keep track. But that's kind of our motto that we kind of set in stone that we wanna keep as a culture for the company. Yoad, thank you so much for taking time out today. Talk about the company, congratulations. And since you folks just came out of South, I look forward to talk more to you folks because security is an important topic here at TFR as well. So I am looking forward to our next discussion but I really appreciate your time today, thank you. Thank you so much, I appreciate your time.