Breaking Barriers in Application Security – Varun Badhwar, Endor Labs

This is Textron tv. Hey everyone. Welcome back here to Textron tv.

Happy to have I, it's first time I've interviewed him here on Textron tv. I don't know if he's been on here before, but let me introduce you to Varun Bois. Varun is the c e o and co-founder of Indoor Labs.

Varun, welcome to Textron tv. Thanks for having me, Alan. Excited to be here.

It's, uh, we're excited to have you on. So, Varun, before we jump into some news and, and, uh, discussion today, not everyone here is probably familiar yet with Indoor Labs. So if you don't mind, let's hear a little bit about you.

You, you're the co-founder and c e o. Let's hear a little bit about your story and, and indoor story, and we'll go from there. Sure, that sounds great.

Yeah, so my story is I've been in the cybersecurity space for, uh, about 17, 18 years. 13 of those years have been spent building companies and products in this space. com when there were 1500 employees back in the day, growing to about 6,000 while, while I was there.

And really, you know, in 2010 I realized that I knew more about cloud security than most people at the time. I was fortunate to be in that situation and really went down the entrepreneurial path. And, you know, thematically, if you look at all the three companies now, you know, they, they lay at an intersection where there's a massive technology transformation happening, which will require retooling and rethinking of security entirely.

So in 2010, the first company was in the CSB space called Cipher Cloud, which was when the whole enterprise SaaS movement started. 2015, I then started a company called Red Lock, uh, which now became one of the creators of cloud security posture management category. Three years later we got acquired by Palo Alto Networks.

And, uh, I went on to create for Palo Alto Networks, what is that now known as Prisma Cloud, which is what the largest cloud security, uh, posture management and c n a products in the market there. And really, honestly, three years into doing that, I was firsthand feeling a lot of pain around developer productivity being hampered by a lot of the security requirements, application security, code security, pipeline security. And, you know, looking at the 400 engineers I had the common conversation, um, my head of engineering and I would have is how much time or do we spend on building features versus going back and reviewing lots of different security reports.

And, uh, what would turn out unfortunately was 80% of the stuff coming in these security reports was useless, but it took hundreds of hours, thousands of hours of our developers' time to actually come to that conclusion and then debate and discuss that with security teams. So we said, there's gotta be a better way. And that was the genesis of Indoor Labs.

Now, you asked the question, what is Indoor Labs for the people that don't know us, us, um, that's our mission. Our mission is to improve developer productivity, eliminate what we call the developer productivity tax. Now, what is developer productivity tax?

It's when you're running application security tools that are generating tons of noise, most of the things being reported there don't actually reduce risk. You know, they might be good for compliance checkbox and other things, but they're not meaningful. And we think if we can give developers up to 50% of their time back to actually build features and drive innovation, that would be the nirvana that we all wanna strive for.

And that's what we're planning to do here at Indoor Labs. And I'll be happy to tell you kind of where we've started that journey. I love it.

I I love it. You know, look, the, the problem you're describing is not, quite frankly, it's not just an AppSec to developer issue. This has been a pro, I've been in security now 28 plus years.

There's always been, you know, we used to call it the desensitization issue, right? Back when I was selling snort based i d s and how many false positives. And then vulnerability management vulner back in those days, vulnerability management was job security for security people.

'cause they would only scan back then, we'd only scan once a year, if you're lucky. And, and we would deliver a, a phone book, you know, a a a one of them, you know, remember the old dot matrix printers, uh, a a phone book full of it, and then a guy would start it on January 1st, you know, checking off vulnerabilities. And around Christmas time, they'd finish, maybe take a week off, and then they'd get a new book, January one.

It was a great gig. They never get fired. They never finished all the vulnerabilities, but who cared, right?

It was, it was about job security. This has always been the problem. How do we separate the noise from the signal?

How do we, how do we prioritize, right? I had another company where we had a, a product called Van, where really what we used to do is put vulnerability in a workflow, prioritize it based on C V E and, and criticality. And even that doesn't work good.

Now that's dealing with security. People go deal with non-security people try to get them smart about security. Yeah.

That developer productivity tax, you know, I call it an idiot tax because idiots should pay it because we, you know, we need to, we, we need to do something to be more efficient here, Right? Yeah. So, you know, Alan, what we found was there's another kind of remarkable trend happening at the same time in software development, which is software engineering teams are really shaping up to be software assembly teams.

Meaning the first thing you do when you get a requirement is you don't start writing your software. Day one. You first go look at what are the different components I can bring from the open source ecosystem?

What can I reuse? And so five years ago, 80% of your code was probably written by you today, 80%, 90% of your code, and it'll probably get 95% with all the advances in AI is code that complete strangers on the internet have written. Now, that code falls into two buckets.

Yes, there are great companies like Meta and Google and Databricks and others providing open source, but the reality is that the heart of the internet runs on components written by single individuals, good Samaritans in most cases, that are doing this as a hobby. But it became a critical part of our internet infrastructure. Now, that's where we think, you know, when 80, 90% of the code is not written by you, you really gotta focus your attention on that.

And unfortunately, the market has existed to solve, this is called software composition analysis. And the SS c a market has been so focused on license scanning and vulnerability scanning with a, like, let me just hold you guilty by association. If I even get an inkling that you're using something, every vulnerability affects you.

That's not how it works. Because Alan, the cr the the craziest thing I uncovered in this journey is while you bring in 80, 90% of the this code, only 12% is actually used in your application, right? You bring the whole package, you call one or two methods in that package because that's what your application needs.

So that's all you're using. If only the tools were smart enough to uncover the code you use, not the code you import, you'd be a lot better in terms of noise reduction. So we said, let's start there.

Open source is big, open source governance is critical. We're seeing all of these supply chain attacks. Nobody wants to relive log four J again and ruin Christmas and New Year.

And so how do we build a much more effective way to help engineers and security teams select better open source software right from the very beginning? How do we then help them secure and maintain it such that the security noise goes away and we focus on the 10 or 20% of the issues that really matter. But the third thing was really important, which is how do we help them maintain and update and keep all of these dependencies really reasonably well curated and maintained in their environment?

We often are so fixated on security that we forget that the developer doesn't care just about that. Like what gives them value is if they build better applications, more sustainable applications, they don't get paged at three in the morning on a Saturday 'cause an a p I broke because some other person's code kind of impacted you. And so we think open source governance is really about select, secure, and maintain.

And that's why within AppSec, we decided to start with open source, given just this prolific explosion of usage. And now we're starting to take on more capability areas of that ABSEC space with the recent $70 million series A funding that we have just announced. So first of all, congratulations on the funding and $70 million in, in this environment current VC environment is, is, is is a sizable race.

So, so good for you, good on you. And congratulations to you and the team. com and Security Boulevard and Cloud native now, right?

Um, it's really what you're describing is the software supply chain security issue, right? And SBOs and everything that kind of goes with that today. Software's made in a factory.

It, you know, it used to software used to be a, a guild kind of thing where you had a, as you mentioned professional who cobbles together and writes actually codes. Today it's more of a very akin to a car factory where you have third party suppliers who, you know, their parts come into an assembly line and you have assemblers assembling cars and you have assemblers assembling applications today, right? From third party suppliers.

And what, what, what's, what's interesting about software is those third party suppliers, they have third party suppliers who have other third party suppliers and so on and so on, right? Especially you mentioned APIs. How the heck can you control, right?

That, that Saturday night call that an API's not working 'cause someone else's software that the a p I had a dependency on isn't working. This, this is, this is the reality of today's, you know, software manufacturing world, if you will. $70 million is a lot of money, but it's kind of a drop in the bucket when you look at the size of this problem.

How, how you, how are you, how's Endor helping here? Yeah, so Alan, first of all, you know, the US government now calls open source software, national security issues. So a lot of attention on this problem.

There's obviously, as you mentioned, the regulatory drive towards, you know, asbo. But in reality the conversation is transparency of what are the ingredients that go into your software. But ultimately, if you really think about SBOs being a means to an end, meaning at the end of the day, what is an sbo you're producing at the end an artifact that says, here's everything that when my application, in reality, you are not controlling at that point, what really went into your application, and you might look pretty bad if somebody was to look at your SBO and say, why on earth are you using these 17 things that are horrible?

And so we think you gotta really start all the way left at the point of the journey where developers are starting to think about what next open source package do I use? You know, in most companies I talk to, it's unbelievable. You know, we ask the question, my favorite question, well, what is your process to vet what open source software your developers are gonna bring in?

The answer varies on one extreme from a hope and pray strategy, meaning we don't, they can bring whatever they want to. The other extreme where, well, they log a ticket and wait, and I'm like, how long do you wait? Well, three to six weeks for a package to be approved.

And you know, we think either of those outcomes are really bad. So first and foremost, what we have built at, at Endor Labs is this massive internet scale infrastructure that is continuing to scan millions of packages dependencies as new updates, as new open source packages are coming out. And essentially following the car analogy, we build a Carfax report for every open source software out there such that when a developer wants to use something or is thinking about using something, we have already looked at hundreds of signals and are providing them a pre-vetted report that says, look, here's the risk with the humans behind this project.

Here's the issues with their code and quality, the community, here's any security issues that they might have. And you just get all of that information at your fingertips. And in reality, companies like Google and Microsoft have an army of people doing this for their internal selection process.

But 99% of organizations don't have the capacity to do this. So we're kind of democratizing this whole vetting and selection and governance process where people can now write with code saying, bring in any open source software you want as long as it has a b, c minimum criteria. So we enable that.

The second thing, Alan, we enable is we have completely shifted away from scanning your application manifest files to discover what open source packages you're bringing in. Because fundamentally that's what creates noise, because you don't know how I'm using it. I may have imported something, I'm no longer using it in my application.

So rather than looking at the phone book to say, okay, who should I call? We're looking at this real time within your application, completely statically without any agents, without any runtime kind of dreadful interactions as your software is getting deployed and code is getting checked in, we're scanning and saying, well, let me understand how you, the developer are actually bringing in and using these dependencies because I wanna look at the 12% of the code you're using. So I can dismiss 88% of the issues in parts of the code that you don't even care about using because it's not exploitable in your environment.

You talked about, you know, prioritizing with CVEs and criticality scores, that's great, but the fundamental way to prioritize is how am I using this code in my environment? And we empower that, we enable that. And then, you know, looking beyond that and kind of where we're headed now, Ellen, with the, with the kinda 70 million financing is we think code security, what we just talked about, and pipeline security in the C I C D are very intertwined.

Mm-hmm. I could have the best, most added code, but if I'm not monitoring the hygiene of my pipelines and I have overly permissioned access into my code repos or, you know, whatever other issues you might be because you're not enforcing branch protection rules and code reviews and M F A and your code repositories or people are putting in secrets and somebody can log right into your, uh, GitHub environment that has equal impact to your software supply chain. So we think a more cohesive set of capabilities, because we don't want customers going down the path of having 15 tools in C I C D doing slivers of security functionality.

We think that's just not a good outcome. So we're really focused on integrating and unifying many of the code and pipeline governance checks right into the single platform from Indoor labs. I love it.

Look, this is, this is real, right? And, and it's in there. Um, we're almost outta time, but Varun for people maybe who, what's the on-ramp for people who want to, you know, maybe try out indoor labs, check this out.

What, what's your advice for them to get started? com. We have, uh, demo videos recorded right there.

If what you see piques your interest, what you've heard piques your interest, just reach out to us for a website and we'll very quickly be able to spin up a evaluation and trial environment for you. Uh, it's as easy as connecting a GitHub app or a GitHub action right into your code repositories and seeing the magic. So we look forward to showing you what, uh, what we can do to really cut down 70, 80% of the noise.

That's typically, Alan, the stats our paying customers are seeing is, you know, they're using a current best of breed as ca tool in the market. They come use us. There's about a 70 to 80% reduction in noise and a far more context, which you can use to action, uh, your information.

I love it. com. Excellent.

Varun, Hey, thanks for coming on. Congratulations again on the raise. That's a, as I said, a really great number in, in today's market.

Um, but more importantly, you, you aren't, you know, no pun and no kidding, it's, this is a mission critical mission you're on here, right? And, and, uh, people need to, to jump in on it. I know you guys are, I think you mentioned you'll be a black hat, uh, for anyone watching this.

com Varun, come back on to keep us posted on this. Okay, man. Will do.

Thanks so much for having me. Have a great one. All Righty.

Varun Badis, C e o co-founder Indoor Labs here on Tech Drunk tv. We're gonna take a break and we'll be right back.