Securing Software Supply Chains and CI/CD Platforms with Endor Labs’ Varun Badhwar

This is Textron tv. Hey guys, thanks for the throw. We're here with Varun Baris, who is the CEO for Indoor Labs, and they just picked up some additional funding from Citi Ventures, and they are provider of some tools that help us secure our software supply chains and our CICD platform specifically.

But we'll get into that in a minute. Varun, welcome to show. Thanks for having me, Mike.

Good to chat with you again. What does this investment mean for you guys? I mean, there's a, normally, I mean, there's a lot of venture capital floating around, but there hasn't been as much abl, so what should people interpret from this investment?

Yeah, Mike, as, as you might recall, we had talked when we had raised our 70 million series A, we are a very well capitalized early stage company. I think the most important thing that, that I take away from this, uh, is really an endorsement from, uh, city and city ventures around the importance of the problem that we're solving, uh, you know, around securing your software development lifecycle. Uh, so I think it is, you know, it continues to demonstrate that as a company that is already serving in our early stages, large institutions, financial companies, amazing technology companies, some of the world's leading AI companies, as our customers, we, we get tremendous insights into how much, you know, security and vulnerability noise is becoming a problem in terms of developer productivity.

And I think as, as Citi, uh, talked about in their, in their announcement with the press release as well, is our ability to help make engineering teams more productive while it's making them more secure. To say that there is tension in the system is probably an understatement. We've been talking about shifting, um, responsibility for more application security further left towards developers for a while, but a lot of them will complain that the cognitive load is too high.

And to your point, there are just too many alerts being generated and there's not enough context as to what goes with what, um, how did we get here and how do we get outta here? It's a very simple math problem. You probably add three to 4%, 5%, um, headcount a year in, in most companies, uh, at a mature state.

You know, vulnerabilities are increasing by probably 30 to 40% a year in terms of just the vulnerabilities being disclosed. Um, 90% of your application code today is code. Your developers don't even write, uh, it's code that they're borrowing from complete strangers on the internet that may or may not have the same levels of motivation and urgency as you to keep that code secure and while maintained and up to date, you kind of put all of those pieces together and the problems right in front of you.

Uh, and I think that the, the, the further challenge is, you know, we're talking about how AI will accelerate software development and well, great, now you're gonna have a hundred x more code being generated, but a relatively constant number of AppSec engineers. And unless we do something about revolutionizing our approach that these tools take, we're in big trouble. I kind of feel like we're in big trouble, but I don't always feel the same level of urgency out there when I talk to, uh, senior leaders or when I read any given survey, yeah, I mean, they're aware that there's an issue, but I guess they have competing priorities.

So how do we elevate this to become something that feels more like Jot one Mike is very simple, right? Like the, the, the CISOs are overworked, overwhelmed with tools, understaffed, you know, the, the first and foremost thing is how do we make these tools really simple to deploy? Because even the best CISO who wants to do the right thing, we'll look and say, if the technology you're offering me takes me six months to deploy, I just don't have time to do that.

I'm gonna go figure out something else to fix quickly. So one is, how do we make our technologies collectively as an industry really dead simple to deploy? For example, Android Labs, you click a button, it installs an app into your GitHub environment, and it starts scanning a code.

So that's the number one problem. The, the, the second piece is how do you justify the value for somebody to switch from an incumbent tool, right? Like most organizations have a software composition analysis tool, and we're huge proponents in not asking you for additive budget.

Most of our customers replace existing what call best of class SCA tools with indoor labs, and the, the business case is right in front of them. Once they deploy this technology in the proof of concept, they will see on average upwards of 90% reduction in vulnerability noise or integrated platform into the SDLC, you know, commenting and reviewing pull requests and doing it very natively like success. People ask me, what's your developer experience?

And I say, my developer experience is no developer experience. They never see or labs as a product. We meet them where they are in GitHub and GitLab and Jira.

So I think you take these things together, you made it really easy to test the value. You've made it very native for the developers to not have to learn a new tool. And by the way, you demonstrated to me that you can give me back thousands and thousands of hours a year of developer time to build features and drive innovation.

We have kind of, you know, it's a slam dunk value proposition at that point. I feel like we're still having an issue with determining who's in charge of something. And of course, if everybody's in charge, nobody's in charge.

But the developers seem to think that the security people are doing something about this, and the security people still think that developers are doing something about this. So how do we kinda get to the middle? Yeah, look, reality is everybody has different OKRs.

Developers are measured on productivity and feature velocity, and security teams are measured on risk management. And, and, and those things don't add up. Uh, look, at the end of the day, what we do is squarely the responsibility of product security and application security teams.

I think the question behind the question though here is where should product security teams and application security teams report into? Do they report into the ciso or should they report into the engineering and technology function? We're seeing that all over the place, honestly, right now, but we are starting to see more forward leading organizations where some of the AppSec teams actually report into engineering.

And we think that's a, that's a great, that's a great change, uh, because then it's not a finger pointing, but really the ownership comes in there where the CISO team will mandate what controls are required, what testing is required, but the actual implementation and execution of that will remain the product security team's, uh, kind of narrative within the engineering team. So I think that's a really good way to think about this, but it requires a very strong partnership between the CISO and the CTO, you know, to continue to make that, that influencer versus execution role all work. And let's not forget, there's a third angle here, which is compliance and audits, right?

So you got, you know, FedRAMP saying all critical vulnerabilities must be fixed in 30 days. Okay, well now we've gotta make sure that that loop is getting closed all the way from the product security teams and application security teams within engineering to the CISO or the GRC team that is responsible for it. Um, so I think there's a lot of moving parts and I, you know, one of the things, for example, Mike, we've worked on with our customers auditors is to basically demonstrate that indoor labs like technology can not only reduce the noise internally, but it can alleviate a ton of busy compliance work because you can prove that majority of these vulnerabilities are false positives.

So, you know, it's bonus on people like us to influence the industry to think differently and get better at it. And we're, we're doing that and it's working really well. Do you think we're gonna need more stringent regulations at some point?

Because, I mean, we're seeing some stuff around FedRAMP, but it seems like, um, a lot of organizations just don't move the needle till there's a compliance mandate staring them in the face. Yeah, you know, look, we could talk about this all day long. Um, a lot of times unfortunately, compliance doesn't equal security and, and the behavior that, you know, you run the risk of is everybody starts doing everything for compliance, but that doesn't help you prevent the next breach.

Um, and so I think we have to be pragmatic. I I think for example, the, the government's push on SOM has certainly made this topic of open source software governance more mainstream and much faster than it should. But I think like how prescriptive should the regulation be versus directional, uh, is, is always an age old debate.

Uh, I think what we have to make sure is that the regulation and the compliance standards are actually driving better security outcomes and not just creating busy work for organizations to prove certain spreadsheets are trapped. And, and, and it's not moving the needle on security. And unfortunately, you know, with every breach we see every single week these days, you know, I don't know, you gotta ask the question, are we, are we getting better as an industry despite all of the investment in security, or are we not?

And there's some foundational pro, uh, problems. We all have to really look at that, that are deep rooted in how security has been implemented and run. Do we need some sort of national movement then for, 'cause some people are calling for something equivalent to what the airline industry did in the sixties and seventies where they, you know, got together and said, we're gonna have better engineering full stop, and that became a, a, a mandate and do we need to do something similar?

Look, I think it's starting to happen organically, right? Like CS a, um, initiative around secure by design and several companies are now starting to sign up around that. I think that's great.

I think the government now putting mandates out there to say, if you're the software supplier, it is your responsibility. You can't transfer that ownership. This happens a lot, right?

Like if I use open source software and then my software that has this open source software is, you know, uh, uh, licensed by a large bank and there's a vulnerability in that piece of software that I was using or I made the choice to use, is it my responsibility? And I think the answer is through regulation. Now it is, right?

So I can't transfer the risk because my developers took a choice, uh, to use a particular library that turned out to be vulnerable. And so I think, um, we are starting to see more of that mandate. Unfortunately, like the reality when I started Indoor Labs three years ago was, you know, most folks were transferring the responsibility of, oh, just because I use open source software, it's not written by me, it's not my problem.

And you know, you saw this with Lock four J when it happened, thousands of organizations emailed the maintainers these long spreadsheets asking questions about their security practices. And they're looking at this and saying, we're just good Samaritans helping the industry. We don't owe you any responses.

And so I think organizations that rely on this critical pieces of software need to make sure that they're doing the right things in terms of governance and reviews and quality checks and security checks of this software. And I think the whole software bill of, uh, material initiative is making sure that our downstream customers, the final customer I sell my product to also has a way to hold me accountable to share and full disclosure, what components do I use as my software? How do I secure them?

And to come back and ask me tough questions if I'm not doing the right thing. Of course, these days you can't walk down the street without somebody leaping out to tell you about their great new AI thing. How might AI get applied in this space and, and what should we be looking for?

Look, there's, there's security for AI and then there's AI for security. Let's kind of break this down. Let's talk about, uh, securing all of the AI usage.

I think as I told you, the big problem we have in front of us is, you know, code is going to be written a hundred times faster. It may not be better code, it may probably be worse in many cases, right? And so are we prepared with the right automation and prioritization detection capabilities to review and not just review, but auto fix and remediate that code?

You know, Mike, I'll tell you one of the fundamental problems we see is, you know, there's the finding and prioritizing vulnerabilities. One part of the problem. There's some even further deeper rooted problem that we don't talk a lot about as an industry because we're so fixated on we have too many problems, is even when we find a shorter list of problems, the remediation is too slow.

So, you know, what are the opportunities to remediate using ai? I think that's a great way to think about how you now start applying AI for security. And in a few weeks time, Mike, you know, you'll be hearing more from us about some massive innovation in that space.

But I'll, I'll say broadly as an industry, AI is good for certain things around re around explainability of vulnerabilities and things like that. But finding zero days, I would say we've tried it, you know, we have published some research around it, it's not there yet. So you have to be very cautious on how you're applying AI to solving critical security challenges.

I think it's great for workflow automation like soc playbooks and SOC automation, but you know, just discovering zero day vulnerabilities, I I I, I wouldn't bet my money on it today, but six months from now, we could be looking at a very different world. Yeah, I was talking to some folks and they were candidly admitting that one of their issues is they keep fixing the same vulnerabilities over and over again. Because what happens is, um, they update a piece of software, then they apply a patch, and then somebody else comes along and throws in a different container with a different version of that thing, and then they got the same vulnerability over again.

And it might just being a vicious cycle, um, is there something we need to do that's more process or cultured center than just handing out new tools? Yeah, two, two problems. Thank you.

You bring up a a great point. I think one is, it is very difficult today for organizations to trace, you know, let's say Wiz is detecting an alert in your cloud runtime or Prisma cloud. You know, how do you trace it back to the source repository in GitHub and the date and time that that release was cut from your environment and where else it's applied.

We think this is a be of a traceability and providence problem in most organizations. Like nobody could really tell you this piece of release software is running in these 75 containers in these different AWS Azure and GCP environments. Very difficult to do traceability.

You know, Google has put out good concepts and frameworks like six store to do artifact signing and providence. But the reality is like most enterprises don't have the, the, the people and the time to go implement that. And in fact, we think, and we have delivered that as a just a core feature in our product, is you need to be able to trace your software from code to cloud because by doing so, you can then say, this application package has a vulnerability.

Currently that package is deployed in these 75 containers. So in order to fix this properly, I gotta fix this package and then I gotta redeploy these 75 containers. We need that level of visibility in the industry.

The other problem is, is a kind of a self-inflicted problem in the industry is, you know, we buy a different tool. You are alluding to this for a different part of the problem. Let's take for example, SC and container scanning.

Most organizations have two different tools doing that. You know, the software composition analysis tells you that this application package has vulnerabilities, then that application package is put into a container and that container scanner then tells you all the OS vulnerabilities and the application vulnerabilities and you end up with duplicates. Now you wanna go buy a third tool to de-duplicate stuff.

And I call this problem like, you have cancer and you're trying to take Tylenol to help yourself. Like you may get six hours of relief, but you really gotta go figure out the right cure for cancer with chemo and radiation. And that is actually fixing the sensors that are causing these problems.

So at indoor labs, for example, you know, we are integrating now and we have cohesive capabilities for SC and container scanning using the same engine that just never creates those duplicates in the first place for you and then reduces that noise for reachability analysis. So I fundamentally believe the onus is on us as an industry and vendors solving problems in the space to find the right grouped problems and not build feature after feature, but really understand that at, at the core, how do you build cohesive capabilities? For example, if you're doing security in the shift left, how do you kind of connect to all of that together?

So my customer doesn't have a problem that I am creating around duplication. And to that point, it seems like we've maybe given people the false impression that there's one way to solve all this and that's all they need to think about. 'cause it seems to me there are vulnerabilities that are gonna get introduced by developers, then there's gonna be vulnerabilities that might get introduced during the DevOps process and updates, and then there's gonna be vulnerabilities that exist in the target environment.

And all these things are issues that, you know, the cyber criminals don't really care where the vulnerability came and just wanna exploit it when they find it. So how do we get a more cohesive thought process going here? It's difficult.

Mikee on one side, like I, I think about this a lot. I built Prisma Cloud, you probably might recall before this, and we did nine acquisitions that put everything together into a beautiful platform to kind of create this category called synap. Um, there are things that make sense to be done together because they're complimentary.

There are others that are just completely different domains of problems, right? Like there's a reason why there are leaders in cloud security and different leaders in network security and different leaders in cloud, uh, in endpoint security. I think you just can't expect one company, even though some might tell you they can do it all to do it all and do it well.

The flip side though is there are complimentary things like we focus on everything your software depends on. That means open source software, AI generated code models, your CICD pipelines, your repositories, because there's all very related. We don't go out there and claim that we're gonna do cloud runtime security.

We think that's a different area of, of, of, uh, focus. But we think that vendors and tools need to talk to each other and communicate with each other because to deliver the customer outcome, these things all need to connect together. And you know, the, the example I was giving you my earlier of artifacts signing and providence and traceability, that's a great example where you can connect which repository generated which artifact and ultimately which runtime environment in which cloud and which data center is that running and what vulnerabilities are you finding there and how do you correlate them from here?

Can all be traced if you have this code signed and traced across the board and, and you can connect these through different vendor APIs. So I think that's reality is box in. Like to me, customers always ask me like, is there one code to cloud platform?

And I say, probably not. Your best outcome is to think about a platform on the left side, which is around your secure SDLC, something like Android Labs. And you then need a capp, like a prisma or a waste that then ties all of your entire journey from code to cloud together.

That's probably a better outcome than, you know, settling for less. All right folks, you heard in here. Hey, somebody real soon is gonna come knocking on the door and saying that you have to improve the security of your software supply chain by this certain date.

And once that happens, there'll be a lot of stress or you can get in front of it now and be proactive about it and not sweat it when it comes. Hey ver thanks for being on the show. Thank you for having me.

Great to be here again. All right, and back to you guys in the studio.