The DTC Enterprise Tech Podcast

Varun Badhwar (00:01):
If a product cannot be spun up, set up in a trial, and a customer left behind with value in a 60-minute call, then you're going to be in this indefinite backlog of tools. People may, with good intentions, want to try, but they're never going to get to.

Ronda Scott (00:18):
Welcome to the DTC

Ronda Scott (00:19):
Podcast, a series of conversations between the investors and operators at Dell Technologies Capital and the people who are building what's next in enterprise technologies.

Ronda Scott (00:29):
In this exit interview, DTC managing director Deepak Jeevankumar talks with Varun Badhwar, co-founder and former CEO of Red Lock and Co-founder and current CEO of Endor Labs. They cover creating new categories in cybersecurity, how to build a customer-centric company, and what happens when you join forces with a company like Palo Alto Networks Spoiler. Sometimes things break when you scale faster than you ever thought possible.

Deepak Jeevankumar (00:56):
Hey, Varun, welcome to the DTC podcast series, the title exit interview. Hope you're having a good day. Thank you for joining us today,

Varun Badhwar (01:05):
Deepak. Thanks for having me. It's always a fun dialogue chatting with you. So looking forward to this.

Deepak Jeevankumar (01:09):
Varun needs no introduction, but I will still make the introduction. Varun is the third-time founder. He's currently the CEO of Vendor Labs, and prior to this was a GM of Prisma Cloud. He came to Palo Alto through the acquisition of Red Lock, where he was CEO and Co-founder. And before that he was a co-founder at CipherCloud. So third-time founder. Now we hope we can all learn from your experiences. So let's start with the fun part of your last company, red Lock. Both of us know that there was no category called cloud security. There was nothing called CSPM in the initial days of Red Lock. So how was it creating a new category then? Can you shed light on when you felt the market was catching up to you and how did you feel that

Varun Badhwar (02:00):
Deepak? It's a great question, and going back rewinding to 2015, I don't think I sat there saying, let me go figure out a thing I'm going to do and some market where I can create a category. I think it started with a clear problem that was in front of my eyes from even my prior experience having built CipherCloud where 2010 to 2015 was all the era about moving enterprise apps to SaaS. And for me, wireless building CipherCloud, what was becoming very evident was nobody wanted to run data centers anymore, and everybody's next move was to do the new things in the cloud when cloud at that point really mean meant AWS. There wasn't a lot of choices for cloud, and I think for me was just the way I have found myself to be most successful in building companies is to just have lots and lots of open-ended conversations to understand priorities.
(02:55):
What's keeping security teams up at night? What is that next big blind spot? Because if you think about any industry before you get into advanced threat detection and other aspects, it all starts with a visibility problem. You start sensing a visibility gap as now, in 2024, most CSOs are sensing the discomfort of visibility around AI and LLM use 2015 that was cloud. And I think for me that was the first principle argument to get into cloud security was to say, okay, there's going to be this whole next frontier of technology adoption that security teams will be completely blindsided to and how do we go solve that problem? And I think digging into that further and further and as we'll get into this conversation, I'm sure we'll peel the layers of the onion was what eventually became, I'm stumbling upon a problem. Wait a minute, this problem is large enough where it's going to award creating its own category. And obviously, now, if you look at it, billions and tens of billions of dollars are being spent securing the cloud.

Deepak Jeevankumar (03:59):
Yeah, yeah, no, that was a great fund that we had together in building Red Lock. So you talked about first principles understanding of a problem because I think you had a significant advantage because you were a customer of security products before you were in the practitioner's viewpoint. How did that influence your thinking about building a product as you were the head of security of post.com at Salesforce? Did that give you a leg up, and did it help you inform your decision-making on product features? What kind of customers to chase? It looks like that was one of your key first principles.

Varun Badhwar (04:44):
Yeah, look, I did have an advantage, I will admit, having worked at salesforce.com way back in 2006, 2007 when most people couldn't spell cloud security, I was kind of immersed in cloud security. So that was an inherent advantage. I think from a vantage point. What became clear is the companies that resist cloud adoption would lose the battle, and eventually, you would have to embrace it because the business pressure to adopt the cloud would supersede any other restrictions around security and compliance and other pieces. And the third thing was understanding the core principles of cloud architectures, multi-tenants, and the other aspects of what I would call what Marc Beo would call the real cloud, not the fake cloud when he would make his things at Oracle, were core principles. That gave me an early-mover advantage. And I think seeing that and seeing what happened with SaaS adoption in the early 2010s, it was just very clear that business would win this battle.
(05:46):
People would start deploying cloud applications in AWS and other clouds eventually much faster than most organizations anticipated. And it would fundamentally start with a visibility challenge. I always have this saying, you can't secure what you can't see. We didn't boil the ocean. Look, when we started Red Lock in 2015, there were companies, I won't name them, that were starting in cloud security around the same time but taking a fundamentally different approach. They were all about advanced threat detection, and my thesis was simple, start with the simple problem, which is a visibility gap. And if you think about it, 10 years, almost 10 years later, nine years later, CSPM and cloud security still starts with the number one challenge being visibility or lack thereof. So it was a foundational problem in 2015. It's still a foundation problem in 2024, obviously, maturity has evolved and for us with Red Lock, that's what we started with is the visibility gaps and the lack of perceived control because now security teams didn't have the separation of the developer wants a service, so they write software, then they request a firewall rule from the network team. All of those boundaries were gone. So all of a sudden you had the developer who could spin up a workload, write the application, set the firewall rule, set the security parameters, and off you go. And there are more security problems due to all of this removal of separation and segregation of duties where people were clicking buttons and making high-impact changes that you just didn't understand.

Deepak Jeevankumar (07:26):
I think you said something very insightful there. Start with the simple problems. While it is easy to conceptualize, but it's harder to productize, how do you productize simplicity? Did you look for any specific KPIs or requirements on how do you productize simplicity?

Varun Badhwar (07:47):
Yeah, I've had this KPI, and I've followed this along even at Endor labs, which is my directive to the team is if a product cannot be spun up, set up in a trial, and a customer left behind with value in a 60 minute call, then you're going to be in this indefinite backlog of tools. People may, with good intentions, want to try, but they're never going to get to or not going to get too fast enough. So yeah, the single biggest KPI for me is if I have an hour with a prospect, what can I showcase within an hour? In fact, at Endor Labs too, I have another philosophy, which is, and I personally certify every salesperson, every go-to-market person that comes into this company is within 30 minutes. I want you to be able to give your slight deck pitch and overview and a product demo within 30 minutes and leave 10 minutes for questions. So 10 minutes slides, 10 minutes product demo to showcase value, 10 minutes Q&A and next steps. Because frankly security teams, whether it's a CISO or a practitioner, are way overworked and are getting hounded by 3000, 4,000, 5,000 security startups. They don't have more than 30 minutes to make a determination of whether they're going to spend more time with you or not. So one

Deepak Jeevankumar (09:00):
Of the key things that you came up with at Red was the cloud security intelligence team. And what do you think was the contribution of that team to your success?

Varun Badhwar (09:15):
Yeah, Deepak, it's a great question, right? And this kind of goes into a bigger question if I zoom out, which is going back to the thousands of startups out there vying for attention for security teams, how do I make it to the top three, top four priorities of the year for you? And how do I do it with not ambulance chasing but actually value creation for something as new as cloud? How do I make sure people understand the gravity of the situation? And so the idea behind the cloud security intelligence team was to publish research around our learnings around the emerging threats in the cloud, the emerging exploits that are actually out there in the wild. People had social security numbers there, accountant numbers there, credit card numbers there, incredible amounts of data. One check of a button could make that entire set public.
(10:13):
And what we would find is we would just simple things, we would just scan the internet for open interfaces in the cloud and we would find all kinds of just crown jewels of organizations information sitting out there. And so what we started doing is we never charged people for this service, but oftentimes we would stumble upon a large enterprise, I'm not going to name names except maybe a couple that we made public, but we would stumble upon their information, we would report it to them as good Samaritans, we would help them understand that. But a lot of that data went into the resource that we anonymized and shared with the world of where these different attacks and risks are for you. One of the ones that actually was made public through responsible disclosure was when we found Tesla had crypto mining going on within their cloud environment.
(11:06):
They had no idea until we reported it. And again, that was just a great understanding of like, look, people aren't just after your data in the cloud. One of the most valuable things is if I can use hundreds of thousands of dollars of your computer on your dime, that is an expense and attack vector for me as an organization I have to defend myself against. So we use the opportunity of the CSI team to not just be good Samaritans and report issues back to organizations where we would find them, but aggregate that information and use that as research and educational material to help organizations understand why they need to do something about cloud security now and not wait for a year, two years, three years to prioritize these initiatives. That education, combined with the simplicity of the product and time to value, really was part of the secret sauce of how we were able to get tremendous traction within a short amount of time before we got acquired.

Deepak Jeevankumar (12:00):
I remember distinctly that within probably a year or so after racing series where we got involved in leading the round, you were getting pinged by many potential acquirers and that was a surprise for all of us. And of course we all said no for a few times before eventually taking the offer from Palo Alto Networks. Why were there so many acquirers interested in you?

Varun Badhwar (12:28):
Yeah, it's a great question. There's a lot to unpack here. Let me start with a disclaimer. I offered Dr. Founders, who asked me, Hey, I want to get acquired in the next year; how should I do it? And my answer always is don't start a company with the premise of I'm building this to be acquired. You want to build a great company, and you don't want to sell; you want to be bought. So that's fundamental philosophy number one. If you take the principle of I want to get acquired in one year, so what should I build? A, you don't control timing and a lot of other things, external factors, and B, you will probably take shortcuts that will prevent you from being a good acquisition or a good integration in the long term because we'll get to what happens after a successful acquisition momentarily. Now with that said, I think it goes back to the fundamentals debug, like we talked about CSI with CSI, we were punching above our weight class as a brand, like a Red Lock was a well-known brand two years since inception, people knew what Red Lock was and they knew that Red Lock was a perceived early market leader in cloud security.
(13:33):
That's one. They generally also knew that there was a high integrity team behind this company, strong engineering teams, strong go-to-market teams, strong partner ecosystem that was supportive of the movement, if you will. And the third was we had metrics to show we didn't need to get acquired, we had money, we had raised per series B, we were going to continue to grow and expand because we had such amazing metrics and growth to show.

Deepak Jeevankumar (14:01):
Of course, choosing an acquirer is as complicated as choosing or quoting an investor. Why did we ultimately end up choosing Palo Alto Networks and why did they choose you?

Varun Badhwar (14:13):
I think there's a number of things that go into this. So if you remember the Dynamics Deepak of 2018 springtime, Palo Alto Networks was in the market to buy a cloud security product. They had looked at Red Lock before deciding to move forward with Evident io. And I think for them at the time, evidence was kind of bigger from the perspective of customers, and that's the decision they made. We respected. So as far as I was concerned, when Palo Alto Networks made a phone call to us in the summer of 2018 after Nikesh just become the CEO for me, my first reaction was, you're my biggest competitor now is this kind of a joke. And I think in the matter of the next week or so, I think they demonstrated their commitment that this was a directive from the top. In fact, the first conversation I had after that was not with Corp Dev, but with really Nick and I sitting down one-on-one and having the conversation.
(15:15):
And I would say frankly, it was a meeting of the minds. He had come from Google; he had a mindset of the best products when he also understood how large of an opportunity the cloud security market was going to present to Palo Alto Networks to shift from a firewall and hardware company to a subscription-based revenue. And I'd say over the course of the next couple of weeks, it happened pretty quick. The third thing that was really important to align on was how were we going to make this acquisition successful. It was high stakes for Nikesh, it was his first acquisition. It was high stakes for us because we wanted to keep building, and we agreed on this model where, for the first time, Palo Alto Networks created a separate business unit, product unit model, what they call speedboats, and Red Lock became the first underpinnings of Prisma Cloud.
(16:12):
And he provided us the oxygen to really continue to expand. In fact, I thought it was ludicrous when we talked about the metrics to say, okay, this company was single-digit million a RR going to get to a hundred million an r was goalposts he set for us in the first 12 months after acquisition. And I'm like, how is this going to happen? But we had the right oxygen; we had the right support, and the right resources, and we ran it as a separate business. I had a lot of autonomy to continue to scale, but fundamentally, if the product foundation wasn't there, we would never have been able to achieve those wild metrics at the time that we thought were just unachievable. But having the right DNA of the organization, the right support from Palo Alto Networks where it was just enough involvement, not stepping on the toes on understanding and trusting us to know how to sell cloud security, which was a different motion than firewall security and the product holding its core foundation and enabling the scale that allowed us to go from dozens of customers to hundreds and then thousands of customers in very short order.
(17:28):
And that goes back to tying into my comment, if you started with thinking about building for an acquisition, you would've taken a lot of shortcuts in the foundations of the product, in which case maybe you would've had a successful exit, but you wouldn't have created a legacy for yourself after that because post exit, there would've been a lot of problems uncovered in the foundations of the company in product.

Deepak Jeevankumar (17:54):
Yeah, I think the best founders want not only to have a successful acquisition but also a successful post-acquisition experience and the product to grow, as you said, the business to grow a hundred times inside a bigger platform. And I think you were able to achieve this, and this probably might go down as one of the best acquisitions in cyber as Red Lock created the underpinnings of Palo Alto Prisma cloud, which has been like an industry winner. So you mentioned some of the key things that made you successful, speedboat executive support from Nikesh, or anything else that created the conditions of this massive success?

Varun Badhwar (18:39):
Deepak where most acquisitions, the reason most acquisitions fail in cybersecurity is because the acquirer wants to run the company their way. And that means, okay, I acquired a hundred-person company, 30 engineers go into my core 5,000-person engineering company, 10 salespeople go into my thousands of sales army company. And what happens is they all get lost within these organizations. They lose direction, they lose momentum. And trying to take a company that hasn't sold in that market or at least not successfully, which is probably the reason they're acquiring you, adds a lot of inertia in that process. So I would say if you look back, not just at Red Lock but also at the acquisitions we did after Prisma Cloud for Palo Alto Networks, the philosophy remained the same. Keep these organizations as tightly coupled units. Let the founders of these companies run the show and give it space and time before you try to make changes.
(19:59):
And I think that's the most, that's simple to say, very hard to execute in reality navigating large organizations. But it's just that that was the reason for success. And of course, having a very strong product and foundation and brand to build on where it's not just, I built it, I bought a mediocre company, and then I put it in a large ethos of selling with skews that can be sold within a platform, but truly buying best of breed products that have early proof of being market leaders, kind of evaluating the ability to scale those technologies and platforms up quickly. Getting the commitment of the leadership team of the acquirer of the company being acquired to focus on certain goals and objectives that are agreed upon pre-acquisition and then executing is what I think makes these things very successful for Palo Alto Networks.

Deepak Jeevankumar (20:57):
That's great to know. So

Varun Badhwar (20:59):
You

Deepak Jeevankumar (21:00):
Have set the bar really high as the founder of Red Lock and the GM of Prisma Cloud. How are you going to beat the bar again with being a founder for the third time? So why start another company and why taking on this burden?

Varun Badhwar (21:19):
It's a great question, and I had to spend a lot of time convincing my wife why I wanted to do that, but well, listen, one, it makes me happy. I enjoy building Second, I don't go around and say, this is my time here. In three months I want to start a company. So let me go figure out what I should work on. The way all three companies have happened is, I guess, call it coincidence, call it luck. I've stumbled upon problems that helped me see through earlier than others might, some large technology shifts and the impact they're going to have on security and productivity and so on and so forth. So, to answer your question here, if you remember the summer of 2021, SolarWinds happened, that was a big shakeup of the industry to say, while you're focused on network and endpoint and cloud, now there's this thing called software supply chain security.
(22:15):
And that's going to wreck havoc if you don't pay attention to your software development process, right? Think prior to that, Deepak security team said, I worry about production. Where's my production data? Where's my customer data? Those are my environments I want to focus on. Securing software development was considered a non-production environment. And hey, frankly, what developers do there is what developers do; who cares? And I think that was the moment in time where we all, firsthand as an industry, got to realize this was going to be the next frontier of cybersecurity attacks. That's one. Second was the technology shift. All of these security paradigms are caused by technology shifts. At the end of the day, software development is more like software assembly. Today, developers write less of their own code. They bring in components. It's like building a car. You don't build every component. Your engineers, the first thing they want to do is look at every reusable component out on the internet.
(23:16):
Okay? There's react framework for the table. There's an LLM from Hugging Face that can do this. There's this other component that's open source. I take these seven pieces, I assemble them with some first-party code around it, and that becomes my tool, my application that's fundamentally different than how we've traditionally written 80% of our code. But this was shifting. And the last piece around all of this is coming out of SolarWinds and I had quit Palo Alto Networks to start Endor labs before log four J happened. But once log four J happened, the cat was out of the bag, debug the government, the White House decided to publish the executive order on kind of software supply chain, open source security, and has continued to follow through with regulation as OM mandates other things, which is basically saying the world reality is pay attention to your software supply chain.
(24:16):
Understand the components that go into your software assembly line. Understand what tools your developers use in your CICD pipelines. Get visibility. Give us confidence that you can attest to the software you ship that you understand any potential risks and you have ways to mitigate it. Okay, easier set than done. Now you need to build a technology around all of that. And really that's where we fit in. And fundamentally we think AppSec is going to have the same moment it has that cloud security has for the last several years. If you look at most analyst reports now, AppSec is growing nearly as fast as cloud security, and traditionally, it's lacked. And we think AppSec is going to be all about not putting gates in the developer workflow, but rather empowering developers to build secure software from the onset. And that's where if software supply chain security is done right, it will enhance and boost the productivity of developers not done right, and it will add more tax to developers.
(25:20):
And we think most of the tools in the market right now, unquote, the leading tools in the space, whether software composition or whatever else categories, they add tremendous tax to developers. They cause distrust between engineers and security professionals. And we think it's tied that the next generation of tooling comes in that actually improves your software supply chain while encouraging developers to use more open source, encouraging developers to use more productivity tools in their pipeline, but do it with confidence and guardrails so you don't make the same mistakes you did with cloud five 10 years ago.

Deepak Jeevankumar (25:57):
That makes sense. I'm both afraid and hopeful for the future, I'm afraid because of the increasing threat surface and attack surface with the software supply chain, but I'm very hopeful because you're there to solve the issues that any other new first principles you've added to your list of first principles that you are following now with Endor labs and company building or understanding the market or going to customers.

Varun Badhwar (26:25):
Yeah, funny enough, Deepak for a large part, red Lock was creating a new category. Endor Labs is disrupting an existing category, but I think those first principles remain unchanged. The couple that we haven't talked about that I want to make sure we get to is there is no product, there is no customer if you don't invest in the right team and culture. So behind all of this, it all starts with a dream. It all starts with some fuzzy vision and the people that bring it to reality is your initial team. And I can't emphasize enough just how important it is to bring the right diverse mindset. I'll give you a follow-up piece we did here. The very easy answer to build engineering, the first 20 engineers would've been to say, okay, hey, X, Red Lock engineers, Palo Alto, Prisma Cloud 20, a few, let's go.
(27:22):
We're starting this company. The problem Diva would've been, look, it's a different domain, right? Endor Labs is all around software development, software productivity, engineering, and productivity. The easy thing would've been call people that have all great people who've worked with me in the past. The harder thing would be to say, you know what? We're going to make sure and make a commitment to ourselves as founders that no more than two people would be from the same company in the first 20 hires. So we actually made that pact, and we went, worked our asses off to go hire 20 people from at least 10 different companies. We ended up with people from meta, from GitHub, from Uber, Cisco, Splunk, Palo Alto, Prisma, and it was a diverse set of skills, diverse set of experiences, and it helped influence our product. That's on the RD hiring. Similarly, I'm a believer in giving chances to folks that are chomping at the bits for that opportunity have proven themselves to be scrappy, to be hungry, to have grit, disrupt markets, but maybe they haven't had that choice and opportunity yet to be a VP of worldwide sales or VP of marketing first bet on the people around you.
(28:35):
Empower them, enable them to be successful, give them the space, give them the coaching, the mentorship. And this is what's worked really well for me in Red Lock and continues to Endor labs. So I'm big on giving chances to the people that have the right attitude and aptitude.

Deepak Jeevankumar (28:53):
That is the holy grail of firing. Find the rising stars and the future is made by rising stars. And any patterns you've seen so far in spotting rising stars, you have been really good at it.

Varun Badhwar (29:10):
Specifically, to answer your question, what do I look for? It's energy, it's passion, it's relevance to the space that we're in. It's obviously what have you done, but really more, do you internalize your strengths, your weaknesses? Are you humble? Are you willing to learn? Are you willing to say, well, I don't know this, but I'm willing to put in the effort to learn? It's about those soft elements. And I spend a ton of time, especially on critical hires on the backchannel because of wireless; it's nice that you are giving me your preferred references. I feel like there's a lot more value I get out of conversations and people I may reach out to confidentially at the right time.

Deepak Jeevankumar (30:03):
And we talked about the key conditions of success. So finding those rising stars, I'll add that to the key conditions of success. And of course, in addition to that, you need to find the right design customers and the right investors to help you. So, any takeaways or learnings for first-time founders, but more importantly, any takeaways for second-time founders in choosing the right design partners and the right investors?

Varun Badhwar (30:32):
So let's maybe talk through those two things. Compartmentalize, I'm a huge believer in optimizing for the human, the investor, not the firm and the brand of the investment firm. Look, it could be a long slog, it could be a quick exit. Who knows? At the end of the day, you're looking for a partner who is willing to go through the journey with you. And the question is not only do I want this person in the boardroom and their money, but would I actually enjoy hanging out with them after? Would I call them when I actually have bad news that I need help? I almost look at my level of comfort in the human and working with the human beyond the brand. Because yes, certain brands will give you great recruiting assistants, and they'll give you an amazing network of customers. But the hell, yeah, that might help you at a point in time, but that's not forever. The person you're working with is forever on your side. So, I am a huge believer in gauging the individual, not the firm and the brand and optimizing for that.
(31:47):
As it relates to design partners, I think look, before I even design partners, I have a philosophical belief of building the open. A lot of people ask me, Hey, when should I go out of stealth? And my answer is usually yesterday, building in a cave means the likelihood of you getting it grossly wrong. Launching something and being like, oops, I just wasted 18 months is a lot higher than building in the open. My belief, Deepak, is if somebody can just hear you in a 30-minute call, take your idea, build something better than you, then shame on you, and good for them. Because building a company is not just idea. Idea is a diamond dozen, it's execution, it's team, it's the whole package. And so I would rather build in the open despite the risk of, oh, somebody's going to copy my idea because I have to have confidence that I can execute, or I would execute everybody else.
(32:37):
And in building in the open, you are able to iterate on your messaging much earlier. You're able to learn things much earlier in the process and get candid feedback much earlier in the process. When you're looking at design partners and design customers, cast a white net. Don't fall into the trap of, well, I talked to seven Bay area technology companies; I know what I'm doing because the world in Central America and the world on the East Coast are vastly different, right? The technology stack, the processes for the acquisition of technology, the people, and the skill sets are vastly different. If you're going to build a big company, you better understand the breadth of verticals and customers and maturity of customers that you can target.

Deepak Jeevankumar (33:21):
This is very, very insightful and I think a lot of Bay Area startups do fall into that trap of this building for Bay Area customers. So I'm going to ask you a very mandatory generative AI question. Has generative AI changed anything about how we are building a startup this time compared to the last time in terms of recruiting, in terms of finding customers, in terms of engineering, product building,

Varun Badhwar (33:47):
The foundational learnings we've discussed remain unchanged: build a solid brand, educate the market with data and research, and hire the best talent; what kind of caliber to look for? I think those things don't change because of ai. That's it. I think it'd be full errand to not think about how every function in your company can become more productive or will get impacted long term with ai. So I'll give you examples. I've told my team, one of the directives is to make sure all of our documentation is not a documentation where you search with keywords, but let's go feed that into an alum so customers can ask their business questions and we can feed them very targeted responses on how to use the product or when somebody is deploying our product, if they run into errors, don't give abstract error codes, translated in simple English terms what the problem is.
(34:44):
Again, generally, the AI is great at customer support, customer engagement, and AI is great at that. Do we think AI is at a point where we can replace our engineers with that? No, I think that the simple way we have concluded is that co-pilots of the world are amazing interns, but they're not principal engineers. So where you have certain work that's mundane, I think it can help offset a lot of that, but also don't imagine it to go replace your engineers in the company anytime soon. And the last piece of all of this is, look, we are in the crux of building capabilities and software supply chain security. I talked about how the software supply chain landscape has evolved. We're doing software assembly. Well, guess what? Today, 80% of your code is open source. In the next two years, it's going to be 95, 90 8% open source. Even the code that's generated by the copilots of the world is trained on open-source data. Is it trained on publicly available code? So just embrace what your software supply chain is going to look like. It's going to be a lot more convoluted. And for us, we're constantly building products and capabilities to help simplify the software supply chain landscape. A lot of it will be influenced by AI, and there are going to be new avenues for AI-generated code models and other things that you embed into your applications that will need discoverability, security, and compliance.

Deepak Jeevankumar (36:13):
Completely agree with you. We got to embrace any change before the change overwhelms us. So Varun, you have been very gracious with your time, so I want to really thank you for your time. So it has been great partnering with you and Red Lock and I'm sure it'll be even greater partnering with MDO Labs. So thank you for partnering with Dell Technologies Capital in both of these startups.

Varun Badhwar (36:38):
Thanks Deepak. And I just want to give a shout out to you as an individual, but also Dell Technologies Capital. You've been tremendous partners to us and friends to me personally and looking forward to a lot more success. Thank you.

Deepak Jeevankumar (36:51):
Great, thank you, Rad.

Ronda Scott (36:53):
Thanks for listening to the DTC podcast. If you like what you heard, you know what to do, like, share, and subscribe wherever you get your podcasts.