From Coding Challenges to Cybersecurity Champion: Varun's Story of Innovation and Leadership

Embark on a transformative odyssey with Varun, a coding-challenged student turned technical tycoon, as he narrates his ascent from ethical hacking enthusiast to the founder of trailblazing enterprises. His tale is a beacon for anyone at the intersection of tech savvy and pioneering vision, emphasizing the crucial alignment between a founder and the market, as well as the delicate dance of transitioning from a specialist to a commanding leader. Varun's candid anecdotes and insights, gleaned from his times at Deloitte, KPMG, and Salesforce, evolve into a study on the meticulous craft of constructing a company from the ground up, hiring a team that embodies trust and diversity, and the pivotal role these elements play in the success and scaling of a startup.

With a spotlight on the dynamically shifting cybersecurity landscape, we navigate through the trials and triumphs of an industry grappling with cloud vulnerabilities and software supply chain threats. Varun's critique is unflinching as he discusses the balancing act between development speed and robust security practices. He peels back the layers on the opaque nature of vendor relations, advocating for transparency and education as cornerstones for better informed security decisions. Further enriching the dialogue, Varun unveils the ethos behind Endor Labs, his venture that aims to revolutionize software supply chain security and catalyze community engagement.

As we surge forward, the conversation turns to the future—where AI's role in cybersecurity promises enhancement, not replacement, of human ingenuity. Varun's forward-thinking perspective underscores the impending rise of software supply chain security and the enduring challenge of identity security. He casts a critical eye towards the interplay of regulations like S-BOMs in setting new standards, and concludes with an invitation to explore the community and resources at Endor Labs, positioning them as a nexus of technical excellence and educational outreach. You're about to tune into an episode that's not just a treasure trove of wisdom but a call to arms for the cybersecurity guardians of tomorrow.

Transcript

Speaker 1: 0:00

Hey, varun, how's it going? It's really good to get you on the podcast. I know we've been planning this thing for a while now and I'm really excited for our conversation.

Speaker 2: 0:10

Yeah, likewise, joe, excited to be here.

Speaker 1: 0:13

Yeah, absolutely. It's definitely a crazy time of the year for, I think, everyone just trying to get schedules to line up and everything. Yesterday, I remember that I had to go and take an AWS cert this morning. I was like, oh okay, that's great, I have to go do that now. But Varun, I start everyone off with telling their background right how you got into IT, how you got into security, even what interested you in the fields or what got you interested to make you want to go down this path.

Speaker 2: 0:53

Yeah, it's a fascinating question because I was doing my undergrad in computer science at the University of Southern California and I was just a horrific coder and nor was I good at it, but also I just wasn't excited and passionate about it and being South Asian Indian, by the sand, it's like you either become a doctor or an engineer. So I had to go finish my degree. But the one thing that was very clear to me by junior year was I couldn't see myself being a software engineer. And so you scramble and say, well, what else would be good and relevant? And what I enjoyed truly doing was being on the business side of technology. And it so happened that I ended up taking an elective course in ethical hacking and I absolutely loved what I did. You could break into people's networks without going to jail and it was like cool stuff, cool, geeky, cool stuff.

Speaker 2: 1:47

But then kind of the next challenge began, which is back I'm talking 17 years ago. Nobody really hired information security professionals out of college. You had to be a systems engineer, it professional, and then you kind of a few years in, made your way into InfoSag and so, scrambling through all of the career fairs and interview processes, I was trying to find my wedge in and it so happened that I got two offers, one from Deloitte and one from KPMG, to be an IT consultant and I kind of played them both against each other to say who would allow me to get into the security track faster and ended up joining KPMG through the university recruiting process. It's been a couple years there, just great experience. Salesforce happened to be one of my clients and this is back in 2006,. They had their first security breach, a first cloud company security breach kind of a big deal and they brought me in full time to join them and run the platform and kind of app exchange ecosystem security team. There was only five, six of us in security at Salesforce. The whole company was 1500 employees and it was just an amazing four years learning about cloud security before most people could spell cloud security.

Speaker 2: 3:04

And then, starting in 2010, I just was starting to get bored in that job and ended up was about to go to business school but realized a more real world MBA would be a better option for me and so I ended up starting a company in the cloud security space and just since then I haven't looked back 13 years of company building.

Speaker 2: 3:23

The first company was in the SaaS security space. The second was as we were migrating from data centers to platforms like AWS, what would the security architectures look like in the cloud? It started BroadLock in 2015, which is a cloud security posture management company, and really got the privilege and honor of defining what we know of today as CNAP, both before the acquisition by Palo Alto Networks, but also after, when I created a product called Prisma Cloud, which is one of the market leaders today in cloud security, and I'd say, just being a student of the business, how it all ties together to today is when solar winds happen. My board was asking me a lot of questions around software supply chain security and I just kind of dove in to understand more about it and what I recognized was the way we build software is changing rapidly and I'm sure we'll get into that. I don't want to steal the thunder, but that led to the creation of my third startup, which I'm working on now, called Endor Labs, in the software supply chain space.

Speaker 1: 4:26

Hmm, it's really. It's fascinating when, when I talk to people that go from a technical, you know role right, or a technical background, you know hands in the weeds right to founding something, to actually starting something, and then you know there's like that one one percent or one percent of one percent that are they're actually successful right, that you actually know, you know the names of the products, you've worked with them and things like that. You know what does it take for someone with a technical background to make that jump? Do you think what are maybe some key skills that you may have developed?

Speaker 2: 5:13

Yeah, you know it's a great question and oftentimes in startups you hear about this term product market fit, product market fit, but we'll get to that. But really it starts with founder market fit. So if I look back and say in my career, like what is made, what is being kind of the criteria, that's helped me be successful, it's a few things right. One is, again, I took advantage of the fact that I knew more about cloud security than 95% of the world back between 2006 through 2010. And so it was a learning. It was a first-hand understanding that thousands of enterprise customers really wanted to use Salesforcecom but were concerned about data residency and privacy. And oh my gosh, you're going to have my customer data outside of my firewall and I don't control anything. I don't know if you're encrypting it where the world is stored. And just hearing those challenges over and over again helped me get customer empathy and ultimately create the first company which defined the whole CASB category, like 2010,. When we started CypherCloud, there was no CASB and our first product was encryption data protection for Salesforce, which eventually involved into this reverse proxy architecture.

Speaker 2: 6:26

And so I believe this founder market fit like understanding the problem firsthand is super important, I think if you're technical enough to be dangerous, it's always helpful, and there's two tracks of technical. You can be technical in understanding the what but maybe not the how, which takes you down a very good product management path. If you're technical where you're the person who's building stuff, it's really good because you can actually go build the software. But I think at some point you have to realize and understand your strengths and weaknesses and say who do I need to round myself up with in starting a company that can address the weaknesses or shortcomings or lack of experience I have in certain areas. So if you're a deeply technical engineering background person but fundraising is something you don't understand as well, or market validation, engaging customers, selling and marketing and messaging aspects, then you better find somebody who can help you round those skills up because, to your point, the odds are against you. In order to turn the odds in your favor, you got a round of the best team. The best team will eventually build great products, which will hopefully get you to great set of customers, which will then eventually get you to a great outcome.

Speaker 2: 7:44

So I think it's going to take me everything in sequence, but the number one problem that I often see people stumble upon is either not believing in themselves and having the confidence to take the leap of faith, as I call it. A lot of times it's just you need the financial certainty right. You're in a place in your life with family, kids in school you just can't take the risk. And so, making sure you're a place in your life where you can give yourself fair and square, a two to three year window to really try out to see if it'll work, because chances are you will fail before you succeed. Also, bake that into your life plan and make sure you have enough runway, because if you try something for six months it's not going to work. I can already tell you just stay in your day job and then just, yeah, look, recognize your weaknesses and build around it.

Speaker 1: 8:33

Yeah, you have a couple of really good points there. I've had on a lot of CEOs and founders and they have all said very, very roughly, at least the same thing of you have to build in some runway. Right, if you're going to give yourself six months for this thing to work before you make a change or whatever, it's not going to work after six months. This podcast, right. It's obviously nothing close to running a large company or anything like that, but I actually gave myself all right, let's give it a year. If I still like it at the end of the year, let's do another year. And I do it every year. So now it's like December timeframe and I'm like, well, I enjoyed the last year, let's go another year.

Speaker 1: 9:27

But if you're giving yourself that short runway, you have to really go through the hurdles. You have to fail. You have to do a really bad job at something and learn. Okay, I need someone on my team that does X to help me in this area. How do you? Is there any like tried and true methods of building out your team in terms of actually finding the people? I'm sure now it's a whole lot easier for you to do it because you have the network. You have been in the industry for a decade or two, right, but if you were starting over today, what would you do to build that network?

Speaker 2: 10:11

Build that network, A network, right, Just be out there. I think, unfortunately, a lot of us with technical backgrounds are just by nature interpreted and it's very unnatural for us to be out there talking to strangers, showing about meetups, events. I think, first and foremost, you just got to be vulnerable, right, it's okay. Remember, everybody else around you is human too and they're kind of feeling the same, A little bit of stranger anxiety. There's a little bit of like, what am I doing here? What am I going to say? How am I going to introduce myself? But you got to do it because, I'll tell you, being as founder, you're almost always in very uncomfortable situations, so you better start getting used to that and warming up to that. The other piece is a lot of people that listen in here, I imagine, are practitioners. You work with great people around you in your company. Identify and ask yourself like, hey, if I ever build something of my own, who are the one or two people, domain aside, who have the work, ethic, technical chops that I would just blindly go call upon to come join me in this journey, Because I think if you can find one or two people from your closed network, that at least gets the process going. If finding a first hire is going to be hard, it's just always going to be hard. Not that it gets easier, but having tried and tested people where you have a level of trust, level of comfort to begin the company is good.

Speaker 2: 11:37

If you look at my three companies, the first company that I started with a gentleman who was a co-founder CEO was somebody who I had known and worked with actually I was on the advisory board of his prior company as a customer. I knew him over the years, trusted him, got into business with him. For RedLock, my co-founder CTO was somebody who had been an engineer for me at Cypher Cloud. At Endor Labs, my CTO is somebody who was my CTO at Prisma Cloud. Having that trusted relationship helps. But beyond that you got to put yourself out there and you got to ask yourself first principle questions. For example, at Endor Labs, when we built the company and the engineering team over the last two years, I could have taken a very easy path. I could have called 15 engineers from RedLock and Prisma Cloud. They would have joined me in a heartbeat and we got to work the next day. Yet the path we chose was to say we promised ourselves that no more than two engineers in the first 15 hires would be from the same company. Why was that important to us? Because we were building a product. That's the heart of cybersecurity and software engineering. Every company builds software differently. You look at Google, you look at GitHub versus Cisco and Splunk and Palo Alto Networks very different maturity levels in software development and the tooling and the architectures. We put ourselves through hell in the first year, year and a half, to hire those engineers to make sure we got diversity of experiences, diversity of backgrounds, not just gender and racial diversity, but actual true work product diversity.

Speaker 2: 13:19

I think you have to look back and see what's important to me. If I'm building a long-term company, I can certainly take some shortcuts, but is it better that I take the pain now and build a kind of organization and the talent pool that I need? And it's going to take work, it's going to be hard. The one thing I will tell people who are first-time entrepreneurs is finding the right seed investors and if you are getting some seed or early pre-seed money, a lot of investors can help you with some of that initial network and hiring of your key talent initially. But that's critical.

Speaker 2: 13:55

The last piece I'll say on hiring and talent is. A lot of times you feel like you know what? I don't have a lot of money. I maybe raised just a million, maybe $2 million. Do I hire experienced people? Do I take some shortcuts on hiring? Get some interns to build code? Look, you can go down multiple paths and not to say interns are not smart. But if you're building a B2B SaaS platform, it'll fall over pretty quickly if it's not built well from scratch and you might be able to build a prototype. The thing is, if your prototype is successful, you're going to have to continue building forward and going back to address tech that we think about. Oh, we'll rebuild it. Gosh, you never get time to rebuild it because once you get hit by it with success and adoption, you're kind of scrambling to go build the next thousand things that your customers are asking for, not going back to address your foundation. So make sure you build a strong enough product foundation is critical.

Speaker 1: 14:52

Yeah, that's very true. I can't even count the amount of times that I've heard oh, we'll go back and fix it later. And it never happens. And this is from an internal perspective where I'm already in there working with the development teams and they're saying oh yeah, we just got to get it out the door, it'll be all right. And then six, eight months later it's still there. It's still kind of just barely chugging along with some new patches of duct tape on it. Yes, starting any company I would assume pretty much in any industry it takes a lot of time. It takes a lot of effort. What was the time commitment like starting your first company compared to this company? Is there any difference? And do you ever regret any of the time that you put in Because you're essentially putting off other things? There's probably other things that you could be doing. Do you ever regret it? Or do you look at what you're getting from it and you're saying, okay, it's worth it?

Speaker 2: 16:04

Look, let's face the elephant in the room. The other thing, the biggest compromise you're making is on your personal and family life. There is no start time. There is no end time. There is you've heard this from people like Bezos it's work life integration, it's not balance, once you go down a startup path. So I think, first and foremost, you have to assess your family situation, figure out what kind of support you're going to get from your near and dear ones and that they're equally committed as you are into the journey you're about to take. The other piece you have to figure out is where do you draw the line? You could work 24, 7, 365. But, for example, I have twins. They're three and a half years old.

Speaker 2: 16:45

I don't want to look back five years later and say I missed the formidable years of their life, not knowing when their first words came out, when they did their first activity, and things like that. And so for me, the time between like 5.30 to 8.30 is super important every evening and I do my best to be with them. But then I'm back online at night, right, catching up on work. You know, weekends the same thing, compartmentalizing family time versus work time, but it's look it sacrifices you and your family will have to collectively make and you have to go in eyes wide open with that. Do I regret any of that? No, like I'm blessed to have a wife that understands this. She's been with by my side. We were dating when I started CypherCloud 13 years ago 14 years ago so she's kind of seen the journey through me and I think you know the other question I often ask myself and people ask me like, why are you doing it again? You don't need to write your financial in a place where you don't need to work. But I say you know, the thing that drives me is solving problems.

Speaker 2: 17:51

The security industry is so broken in so many different ways that we can talk about all day long. But the thing that drives me is if I look back and said what is Prisma Cloud? What did Prisma Cloud do? And what Prisma Cloud and RedLock have done have provided the opportunity in the industry for people to not have 100 tools for cloud security right For on-premise security. We had a fragmentation of 100 plus security products in an enterprise In cloud.

Speaker 2: 18:18

The whole CNAP idea is you invest in a single platform that solves many, many, many problems, and so we really helped the industry move forward. We created the constructs of shift left, right. There are so many things that we did as far as Prisma that I'm just so proud of, and I believe the same problems need to be solved now. Or, similarly, a different set of problems need to be solved and a platform is needed for the whole SDLC, like securing your software development lifecycle From the point where your developers are touching the first open source package and dependency, to all the pipelines to provenance and attestation, and it's that right. This ability to solve and make a difference in the community is what drives me.

Speaker 1: 19:04

Yeah, that's a really good point. What are? How have the problems in cybersecurity evolved since you first got into cybersecurity compared to now? And I asked that question because, even as myself, as a security engineer, security practitioner, I'm dealing with a lot of issues in the code, like you mentioned, and these insecure software packages that we now have to monitor that the SolarWinds hack brought a lot of light to Right. Yeah, what are some of the issues that you have seen that have evolved into where we are today?

Speaker 2: 19:52

Yeah, and Joe, let's not forget, we're speaking in December, just before the holidays. This is two years ago. This is when log 4J was going down, ruined Christmas and New Year's for many people. Yeah, look, everything is changing, but let's kind of break it down into a few key areas. Back when I started building companies 2010, everything was behind your four walls. Today, everything lives outside of your four walls. Perimeters are gone.

Speaker 2: 20:20

The areas that we were most vulnerable to 13 years ago were networks and endpoints. Today, I would say, we reasonably fortified those. Over the last few years, it's been cloud. I'd say today it's your software supply chain which is probably most vulnerable as we matured in certain areas. The attackers are smart. They want to find the laziest route in. They started finding cloud. Now they're starting to find software supply chain. They're relying some software you don't write, and the inherent trust in the open source ecosystem is the next place to point to.

Speaker 2: 20:59

The cat and mouse game continues. Look, the thing that we have to be cautious about is then we decided shift left was important. Okay, great. But then what happened? 5,000 companies started developing products and shift left. Now we're like, oh shit, we need 100 tools for shift left security. Now it's becoming a. What am I doing? Am I just shifting the responsibility to developers? Let's not forget, the thing that hasn't changed is developers are still incentivized and measured on feature to velocity, feature development and security. People are still measured on risk management. These things are orthogonal.

Speaker 2: 21:39

Until, as an industry, we don't collectively put everybody on the same OKRs, I just don't see how we solve this problem. On one side, the security teams feel helpless because they're finding things that are not getting fixed necessarily by engineers. On the other side, the engineers feel like security teams don't understand our modern development practices or modern development tools. They're still using these old ways of giving us spreadsheet of 1,000 issues when, in reality, when I dig in, 90% of them don't affect me. So we have major trust issues between security and engineering that needs to be resolved.

Speaker 2: 22:15

We have tooling that we need to quote, unquote, upgrade for the modern software development processes and stack, and then you've got the attack vectors that are rapidly evolving, right Like look, let's think about software composition analysis for a minute. This whole world started with license risks, then we added CVE based checks, but if you look at where the real attacks are coming in from today, it's not just people compromising well intentioned people's packages and vulnerabilities. It's actually uploading malicious code into NPM and PIE-PIE. Okay well, are your SCA tools like sneak doing anything about it? Not really, so you got a retool quickly.

Speaker 2: 23:00

So, anyway, that's my rant on the cybersecurity landscape, and I think the piece I feel most sorry about for people like you who are the practitioners is there's 5,000 companies out there hammering you with emails and calls and information, and a lot of me too, and copycats and snake oil, and how do you separate weed from the chef? And I think the things that blow my mind is 90% of cybersecurity products don't tell or give you pricing on their website. 90% of security products don't give you on demand access to the product. They won't even show you a demo on their website until you talk to somebody in sales. We think that's fundamentally got to change. The only way practitioners will absorb this information is if you give them the ability to kind of take an on demand journey of understanding and uncovering the best products for themselves and really being more educational than salesy driven with snake oil.

Speaker 1: 23:55

Yeah, it's a great point. You know, one of the biggest issues that I have encountered as a security practitioner is that typically I'm the stopgap in between a vendor and my CISO, right, so I'm the guy that is there to say does this product actually fit in our environment? Does it do what it claims that it's supposed to be doing? Are they reliable? Can I actually put my name behind this thing and say, yeah, this is something that goes on to the next step and it's extremely difficult because they're giving you such limited access, limited experience with it, and you have to really drill down into the minute details of these solutions over a 30 minute, 45 minute call and that's really difficult If you don't know the right questions to ask. You know you're going to run the risk of buying something that you shouldn't have been buying and spending, you know, several million dollars on a product that can't do 50% of what it claimed to be doing when you were, you know, in the discovery phase, right, I've actually had people reach out to me. I actually have a group text that you know when someone's going to be presented by a new vendor, right, we go through as a group the different questions that we should be asking for X vendor you know to be able to like really piece it out and figure out what's going on. And this is a great example. You know I was.

Speaker 1: 25:29

I was leading a POC for a CSPM solution a year or two ago at this point, and a part of you know bringing in this solution is that it had to make my life easier. It had to very specifically make my life easier because there was only two of us on this cloud security team. It was me and one other guy, and we're managing three clouds, right? So we obviously need a piece of technology to be there to assist us. And one of my, you know, tell tale questions was how many people does it take to actually run your solution? You know what's the headcount, right? Can I do it with what I have existing or do I have to add on headcount?

Speaker 1: 26:14

And one vendor I won't name them in particular was trying to dodge this question, no matter what, and I just had to be very blunt with them and I said we're not going on to the next phase until you answer this question, because if you don't answer it, it tells me that either one you don't know or two it's too many for you to ask, and so both of those are red flags to me. And then I got the answer and, of course, you know we would have to increase our team size by 200%. You know, basically immediately with purchasing this technology that we wanted to purchase in 30 days. It's just, it's a different mentality when, when you talk about you know how you present your product, like you were just talking about you know, having a demo on the website giving people you know access to the solution to be able to actually test out and whatnot. Did you come up with that just with years of experience in the field?

Speaker 2: 27:16

Joe, it's a very interesting question, a deep, rooted question. I've posted about this publicly on LinkedIn too. I feel like when you're building a startup, it needs to be a transparency. Let's start with the first milestone. Let's talk about when we're hiring people. It blows my mind that majority of startup entrepreneurs, founders when they're hiring engineers, they will not tell them okay, I'll offer you an offer and I'll say, okay, we get 5,000 stock options. Okay, it could be 5,000 off a million, a 10 million, 100 million total shares. You have no idea and I always tell people if the company is not even going to tell you what the total outstanding shares are or what the strike price of it is or any details that would effectively help you measure and quantify, what are you getting yourself into? Because inherently, you're taking a big risk and leap of faith coming here to work for me and if I'm not transparent with you, how can I expect anybody smart to make that jump? But that's how most of the industry operates. People do it and I published about this online that this should be just a no-no. This is a big red flag if you're looking to join a company and they won't share basic details. Similarly, I think as buyers. If you look at the Endor website, you can watch demos on the site and in fact next month we're going to have a free on-demand trial. You don't have to speak to anybody, you can set up, get going moving with the product.

Speaker 2: 28:44

We started this whole community because of what we learned. We actually call this practitioner community lean app sec Because I find, to your point, there are 5,000 vendors calling the CISO. The CISO is like a quarterback. The CISO is going to take something and eventually send it to you. You've got to do all the work and, by the way, you are one person in the app sec that's kind of ratio-wise supporting 500 developers. It's a thankless job and while everybody wants to take the CISO out to dinner, who's going and appreciating what the app sec engineers do? Who's bringing them into a community? Who's giving them a forum to exchange ideas with? So we launched by sure accident.

Speaker 2: 29:27

We did a virtual event in the summer called Lean App Sec. We had speakers from Peloton Docker, great companies come. It's really a practitioner, a practitioner community and learning. We're just facilitators and it was a great success. We had almost 500 people sign up for it within a month and from there we had a second edition of Lean App Sec and now we have one more coming up early part of 2024. The interest has been tremendous and, along the way, that community of attendees we just pulled randomly and said would you like a Slack community where you can all meet and exchange ideas and talk? And everybody was a resounding yes. So we've done that. We have launched an academy for Lean App Sec where we're giving people training on software supply chain dependency management, this whole regulatory movement for S-bonds.

Speaker 2: 30:13

The thing is we're expecting these engineers to take on more work, especially in this economy where you're not getting more headcount and vendors want to sell, sell, sell more product to you. But who's spending the time looking at the long game and educating you, adding value to you to be able to do your job better? And I'm a big believer in this, like transparency, education, community building and yeah, I mean I think I've learned this right Battlescars doing this for the last 13, 14 years. But these are long relationships, right?

Speaker 2: 30:41

That's the reason why if I send an email or a call to a C-Sword engineer who I may have talked to eight years ago, the nice thing is the chances are they'll respond to me, because I didn't sell them snake oil. I wasn't transactional and I was actually focused on providing them value before I asked for something, and I think that's how you build long-term relationships in this community, which is large yet so small and so intimately connected to your point. You have a group right. A vendor ticks you all off. It'll be pretty quick that you'll make sure your peers will hear about it. On the inverse, if I give you value, I'm sure your peers will hear good things about Endor Labs and it'd be a company that they may want to take a call with eventually, when you know the day-end time arises.

Speaker 1: 31:25

Yeah, absolutely you know. Before we go much further, why don't we talk about what Endor Labs is, what the problem is that you guys are actually solving in the marketplace and how you're doing it?

Speaker 2: 31:39

Yeah, you know, when I was building Prisma Cloud, my team grew rapidly. We had 400 engineers using a very popular quote-on-quote at the time modern SCA tool that generated 68,000 alerts for my 400 engineers. And after SolarWinds happened, you know, every board wanted to know about your software supply chain posture and I asked my VP of engineering how are we burning these down? He's like we're not. We are running the report. But you know, every time we get our engineers to look at these alerts, eight out of 10 of them are wrong. And so it kind of peaked it up with my curiosity.

Speaker 2: 32:13

Look into what's happening in this space. Look, software development has fundamentally changed. Five years ago we wrote most of our code ourselves. Today, 90% of your code is code your developers didn't write and is borrowed from complete strangers on the internet. Then we have no idea who they are, what their motivations are, how good the code quality is, yet it's foundational to our applications. Logically, forget anything else, logically as a human being, when on one side you're putting your third-party commercial vendors through a ringer to attest their applications field spreadsheets all of this versus the side door to your house where your developers bring in our random pieces of code Like there's something's not right here in the mix, and so we said look in order to solve software supply chain security.

Speaker 2: 32:58

Well, what are some of the problems? One is we still haven't figured out how to get wrap our arms around fostering innovation, empowering developers to use all of this, reusable components, on the internet especially. It's getting more exciting with AI. Right, people say the winner in AI is going to be open source. Great, I can't block my developers or say log a ticket and wait to use a package that doesn't work. If they need something, they need it now. And how do I make sure that I empower them to use the power of open source, but do it responsibly? What does responsibly mean? Now I want to make sure I understand who's written this code. Is the code quality good? Is it healthy? Is it well maintained? Are there any known vulnerabilities? Are there any risky use of APIs that can be easily exploited in the future? Is there any known signs of malware Like? The things I need to look at go far beyond vulnerabilities like CDs and license risk, and we don't have a good mechanism to do this in an instantaneous, automated fashion where it's integrated to the developer workflow. So that was one gap.

Speaker 2: 34:01

Then we said okay, people are using great popular tools BlackDoc, sneak, other things but everybody's frustrated with the sheer volume of alerts these tools generate. And if you look at why that is, joe, it's because they are basically running scans on your manifest files. And when they scan your manifest file, they're just getting an approximate estimation of what packages are being imported, with zero understanding of how your developers are using those packages. And they assume your developers are guilty for every vulnerability and every package that is called out there, whereas the true reality is only 10% of that code is actually used by your application. If I could understand what that 10% of code is.

Speaker 2: 34:45

I start looking at prioritization, far beyond just CVSS. I look at things like reachability. I look at fixability. I look at is it in test or production? What is the maturity of exploit? And by using these factors I can take that 68,000 list down to 68, maybe 100, maybe 200, and really give things to my developers to fix that have a meaningful return on investment. And, moreover, I'm not breaking the trust to say it's your problem. Here's a spreadsheet of like 30,000 criticals and highs. Go figure out what to fix and how to fix.

Speaker 2: 35:21

So, enddoor Labs the net it out is all about how to enhance developer productivity while keeping your software supply chain secure and ultimately regaining that trust between engineers and application security professionals cloud security professionals, to kind of get all of that right. So typically a customer of ours will switch over from a check mark, a severe code, a sneak, a black duck, to Enddoor Labs and usually find a 70 to 80% reduction in alert fatigue and, more importantly, they're able to turn their vulnerability programs into being a evidence driven. So if I'm telling a developer to fix it, I'm showing them where in a code it is, how it's getting called in their application, what is the best path to fix it in their code. But also I'm looking at software supply chain risk beyond vulnerabilities. So that was a starting point of Enddoor Labs.

Speaker 2: 36:13

Then we heard and realized from customers it's not just a code visibility and governance problem, it's also a pipeline problem. I have 2000 repos in GitHub. People are kind of managing it on their own in the development team. I don't know how I enforce branch protection rules. I'm getting 10,000 alerts for secrets. I don't know which ones are valid, which one is an incident versus which one is a hygiene problem. And so we've expanded our scope to really look at code governance, but also pipeline governance, much more holistically and do it in a way which is enhancing developer productivity, not slowing them down.

Speaker 1: 36:50

Hmm, I mean, you said a lot there that we should definitely unpack, but I feel like a lot of it centers around customer obsession.

Speaker 1: 37:02

You know, like Amazon has these leadership principles and one of them is customer obsession. And whenever I look at those leadership principles, I immediately think of myself in the times that I've bent over backwards for customers, someone that I've only talked to over the phone, probably never even seen them on camera or whatever, but they're a customer, you know, and to me that holds a special place, to me, even though it's not my own company technically or anything like that, but I took ownership over it. Do you also see it that way? Because you know it sounds like from an outsider right, it sounds like you're approaching this problem from how can I best serve someone, rather than how can I best make money? Right, and as an engineer, as someone who is buying solutions, whenever I see that you know it's automatically like, okay, I'm getting the best solution out there, like for sure, you know, and this person, if I have an issue at 2am, you know they're going to get up and help me. You know, like that means a lot to me.

Speaker 2: 38:10

Yeah, look, it's funny. If you ever come into our Palo Alto office, it literally customer obsession is big on all walls, and so I think everybody wakes up and thinks about that. But here's the thing, joe, I think about it from a CISOS perspective. The best CISOS think of their engineering organizations as customers. Right, the best security teams think of their engineers as customers. And that mindset is important because you want to service your customers, you want to come in their way, you want to figure out how to help them do their jobs better. And then, if I look at that chain of command like for security teams, if engineers are your customers, product teams are your customers. You want them to be able to ship code faster, put it in the clouds, be more transformative, be more innovative, then my job is to help you service your customer, and what that collectively means is that you and I should be able to look in the eyes of your technology leaders and engineering leaders and not just talk about risk reduction, but talk about how did you help them enable their business priorities and accelerate their business priorities. How did you help them save time?

Speaker 2: 39:19

We've probably seen these stats in large enterprise especially regulated Upwards of 40% of an engineering team's time is getting spent today on chasing vulnerabilities and security issues. Think about it in a macroeconomic situation where we're not all adding 20% in our engineering headcount year over year, you still got to do more. You will less, which means we have to drive collective efficiency, and Microsoft's a great example. Microsoft just made a CISO leadership change this past week and look at the background of Igor, who just came on as a new CISO. He's never been a CISO, he's been a technology person. He's built technology for hedge funds like Bridgewater, and so the future of cybersecurity is empowerment of engineering, understanding modern engineering practices, integrating into those. And to me, I think every CISO and security organization needs to be customer obsessed, meaning they're internal customers. And the way I win long term is that if I'm obsessing with you, alongside you, about your customers and driving efficiencies in your business, and not just unilaterally looking at this as a risk management problem but as an efficiency problem.

Speaker 1: 40:37

Yeah, it's very true and I've personally experienced it. When you get a CISO that has actually done the work, they've done the technical work, they have the technical job, so to speak, and when you're talking to them, nothing's going over their head, they understand, they can follow along and everything. And that always translates into a better relationship between security and the rest of the business, because security should always be seen at least in my view, it should always be seen as a business enabler. I want you to be able to understand that. I want you to be able to have access to every single piece of technology that you need to make this company as successful as possible. It's my job to make sure that it's all secured, but it's your job to make sure that you can do what you need to do to make us more successful.

Speaker 1: 41:36

And I'm running into that exact issue that you described right now, actually, where our developers are completely overwhelmed with the amount of findings and security vulnerabilities and prioritization is a very real problem. And I feel like the market is slowly starting to pick up on this trend, because it's not just happening at one company, it's happening throughout the entire market. Almost every company that I've been at the past five years, have all experienced this problem, and then the difficulty that security teams have is actually well, how do I prioritize this? I don't know if that application is using this vulnerable piece of code, and I don't know if that vulnerable piece of code makes my application less secure just because it's there.

Speaker 2: 42:36

Yeah, I'm sorry, didn't mean to cut you off, but this is where you need to hold your vendors to a higher bar. I mean, I think just don't tell me every problem on Earth Like, explain to me, explain to me, give me evidence on why it matters. Where does it matter? Because not only does it help you be more credible with your engineers remember, most likely the ticket that is ending up in a developer's plate wasn't the developer that originally created this problem three years ago, four years ago, five years ago? So somebody in engineering is also trying to figure out the context of shoot.

Speaker 2: 43:09

You asked me to change this dependency. How did it come in? Maybe it's transitive three levels down? That's a complex problem, and can you show me the path? How does my application call it? And so the nice thing about SaaS and subscriptions is, if your vendor is not keeping honest to the promises that they've made you, it's time for a change. It's time to look elsewhere. And, yes, switching costs are a thing between products, but I think most vendors are starting to figure out how to get better at that. But yeah, I think it gives enterprises and organizations like yours a much better opportunity to hold their vendors accountable for much higher standard of products and prioritization.

Speaker 1: 44:05

Yeah, it's interesting to see where the field is going and you know the new areas of focus that are popping up. Where do you see the field evolving in the next five years? You know, because I don't want to say that this is relatively a newer or a new issue. Right, it's probably been around for a long time, but people are finally just now identifying it and actually trying to solve it. You know, where do you see everything going in the next five years? And I'll tell you. The reason why I asked this question is because, with my audience, I always tell them to think more towards the future. Right, start to prepare your career for you know what's coming five, 10 years down the road, so that when that change happens, when that evolution happens of the field, you know you're more prepared, you're more well suited to make that change, to make that jump. So where do you see, you know, everything going the next couple of years?

Speaker 2: 45:11

Yeah, gosh, you know, given what we've seen in the last nine, 10 months, with the advances in AI by the week, it's hard and I'll probably be wrong in everything I predict right now. But I give you a few of my friends that I'm following closely. You know what is. I think AI will certainly be an enabler. It's not going to take our jobs away in security, but it will help us be more efficient, right, Things like prioritization, explainability, right, there are certain things it's pretty good at. But it's going to also create a whole new set of challenges for us, right? Like, okay, so far your problem was developers writing bad code. Now, when machines write bad code, how do you kind of put machine versus machine to fix the poorly written code? You've got a whole set of kind of challenges there. Right, that data privacy issues will kind of reemerge and be at the forefront again. I'd say, from an organizational perspective, I think it goes back to what I just gave you an example of. I think most organizations will have to, from a security perspective, think of engineering counterparts as their customers, not their foes. I think you will see a number of companies where product security will become really part of an engineering function, not a security function. I think it will be deeply embedded there. I think there will be a role of security teams defining policy, defining the what and the engineering teams with embedded DevSecOps. People will be deciding on the how you meet these objectives. So I think you know you should be prepared for pretty large organizational changes.

Speaker 2: 46:49

The other trend I've started seeing pretty closely is several CIO a CISO. So it's funny, if you remember, for many, many years and even to this day today, a lot of CISOs report to the CIO, right, Although now you're starting to see CISOs take the CIO job. So we're starting to see a career ladder where CISOs are becoming CIOs. Because, look, if you're going to find all these problems, you better take ownership to A, do things the right way from the onset, but also have risk management embedded into your entire framework. So obviously you're going to see that and I do strongly believe the next frontier right, we saw cloud and we saw endpointing networks becoming cloud as the next frontier of tech. And you know we've seen identity continues to be a challenge. I think identity kind of remains vastly unsolved. But I think software supply chain security is where the next frontier is going to be for the next five years, and it's one of those unique situations where actually the government is taking a leading role, not a lagging role, in driving the standards of operations much higher.

Speaker 2: 47:57

Now you may not agree with S-POMs and the value of S-POMs, Regardless, the conversation is happening. That's the most important part and that's driving people to think about better controls, you know, better capabilities around software supply chain security, because, look, two things One, every company is becoming a software company. Two, the fact that you can use software to be weaponized against your users, your employees. It's kind of a big deal and the impact this can have is pretty significant, as we've already seen. So, yeah, I'd say those are a handful of my predictions. Like I said, I'll mostly be wrong. A few of them might be right, but I'm looking forward to catching up with you in five years and doing a little checking on these.

Speaker 1: 48:45

Yeah, absolutely. I think it'll be a lot of fun. You know, unfortunately we're at the top of our time here, but before I let you go, how about you tell my audience? You know where they could find you if they want to reach out, where they could find Endor Labs to learn more if they wanted?

Speaker 2: 49:02

Yeah, thanks for asking, Joe. So I'm very active. I love engaging with the community on LinkedIn, so please follow me or connect with me on LinkedIn. You can look up by my name. Endor Labs is pretty straightforward EndorLabscom is a website. We believe in having a lot of information there. You know, our engineering organization is very uniquely technical. Like a third of our engineering team is PhDs and computer science deep researchers, and a lot of our content and our blogs mostly, I would say is written by engineers, not by marketeers. So if you'd like to learn about new techniques, technologies, do check it out. But also, like I said, a heavy focus at Endor is learning. So if you go on our website on the Learn track, there's Academy, there's peer to peer conversations and then, of course, if you want to join our Slack community, then do reach out to me and I'll be able to kind of get you an invite.

Speaker 1: 49:54

Awesome. Well, you know this has been a fantastic conversation and I'm looking forward to future conversations. You know when maybe you release new products or features, whatnot? I think it'd be really interesting to have you back on and even talk about, you know, the space evolving, you know, as we go.

Speaker 2: 50:14

Yeah, awesome Joe, thanks for having me. I really enjoy the conversation. Before to being in touch, take care Absolutely Well.

Speaker 1: 50:21

Thanks everyone. I hope you enjoyed this episode.