Securing Everything from 40-Year-Old C++ to GenAI Code with Varun Badhwar, CEO of Endor Labs

(Intro Narrator at 00:00:00) Today, we're talking to Varun Badhwar, CEO of Endor Labs, about how they're solving the developer productivity tax by making code more secure. You're listening to Joel Beasley, Modern CTO.

(Joel Beasley at 00:00:17) So I like to start at the beginning with what you're doing with Endor. Can you tell me why you decided to create this company?

(Varun Badhwar at 00:00:23) Back in 2021, I was running an engineering team of about 450 people building one of the fastest growing SaaS platforms for cybersecurity. And there's this little known incident called SolarWinds that happened that summer where many of us, thousands of companies, in fact, that were using it got affected by the software supply chain incident. That triggered our board of directors to ask lots of questions around, well, what are we doing about software supply chain security and doing a threat model of everything that could possibly go wrong. And in that process, the base realization for me was, you know, software development is a bit of a fallacy. We are really software assemblers.

(Varun Badhwar at 00:01:02) You know, 90%, 80%, 90% of the code comes from open source. Our developers are rapidly putting it together, writing all of the integrations around it. But reality is most of this code is unvetted. It's complete strangers on the internet, hobbyists, some good companies behind it. Some are unknown unknowns.

(Varun Badhwar at 00:01:20) You don't know where they live, what they do for a living, what their motivation in shipping software are. And nobody's really paying attention to those details. And when I looked at what our teams were doing to scan some of that software, we were using a popular tool at the time that I won't name for software composition analysis. That was spitting out 68,000 alerts in the backlog of our developers, and nobody ever did anything with it. And so as I dug in deeper, it turns out eight out of 10 things that are reported by these code scanning tools for security vulnerabilities are actually wrong.

(Varun Badhwar at 00:01:55) After developers spend several hours going through that process, that's what it turns out to be. And it's an odd situation because it essentially means that we're holding developers guilty until they can come back and prove their innocence to their security counterparts. And that is essentially what causes all of the friction in cybersecurity. That is what I call the developer productivity tax. And essentially, that tax was too high in my opinion, and we weren't really addressing any of the risks associated with the software, the true risk, because we could never figure out what was real, what was hypothetical, what was a false positive.

(Varun Badhwar at 00:02:34) And therein was just the moment to say, like, there's gotta be a better way to solve it. And, you know, lo and behold, actually, today is literally a four year anniversary of the company. We, you know, we set out to hire the smartest people on the planet to go crack the code on how we're gonna solve it.

(Joel Beasley at 00:02:52) That is amazing. I remember that SolarWinds incident. That was a topic on the show. Everyone was talking about it for quite a while. So you started this company. No other products were able to solve what you needed in the way that you needed. So what's different about your approach to the other ones? Why go build it? Why not use something else?

(Varun Badhwar at 00:03:12) Yeah. So as 90% of our code is now open source, the way, obviously, the audience here is very familiar, we all work with this as we bring in all of these libraries from open source. Those dependencies bring in more transitive dependencies, on average, 77 transitive dependencies with each direct dependency, and you have just this massive complex code graph that comes in. But the biggest realization is 88% of lines of code in your repositories go unused because developers bring these large libraries, they use a method or a function here or there, everything else is just dormant yet sitting in your code base.

(Varun Badhwar at 00:03:46) And all of these code scanning tools in the market had the same exact technical approach. They scan the manifest of your application. In the manifest, the developers have declared certain libraries that they're bringing in. Any and all vulnerabilities in those versions of libraries that are declared in the manifest are assumed to be affecting you. They call it a day.

(Varun Badhwar at 00:04:06) All of this goes into a backlog of developers. And so why is this broken? One, you really need to look at the source code as the ground truth, not the manifest, and you really need to understand what code is actually being used in the context of your application. And if I could crack that first problem, I would already be able to safely filter out the vulnerabilities being reported in 88% of the code that's dormant, not even called in your application. So that's problem number one.

(Varun Badhwar at 00:04:34) Problem number two was, how do I do this analysis fast enough where I could do it as the developers are writing the code, not running the scan eight, twelve, twenty four hours later when they moved on to other things? And problem number three was don't leave it up to the people at the altar with a list of problems and no proposed solutions. There's a reason in engineering we have this term called dependency hell because it's freaking complicated to figure out how you're gonna go upgrade complex foundational libraries in your application. It could take weeks, months, years sometimes to do it. And when security teams are just reporting, "Go fix this, go upgrade this library version here or there," nobody can actually appreciate if it's gonna work or not.

(Varun Badhwar at 00:05:16) So our goal was we've gotta give you the answer on how you're gonna fix it with the confidence that this will actually work in the context of your application, not just hypotheticals of just go bump to the latest version. Because latest isn't always the best for your application. So to answer your question, how do we go about fixing it? Why hadn't anybody cracked the code in the industry before? So my cofounder, CTO, and I went out and we hired the best in the business in program analysis across the world.

(Varun Badhwar at 00:05:47) We ended up with 13 PhDs, world renowned experts, all the way from Brazil to Netherlands, France, US, India. And the whole goal was, if we get the smartest people in the room, we put enough resources and compute and funding to hire the best people, we will go figure out how to crack this code. And there was a lot of this work being done internally at places like Meta and GitHub and Microsoft for internal developer productivity. And we harnessed the best of that knowledge, a lot of work that has been done in academia and research, and we built this mechanism called, how to build a call graph of your application. And where essentially we can trace with static analysis every path from your first party code into every dependency, not just what libraries are being called, but what methods, what lines of code are being used in those libraries.

(Varun Badhwar at 00:06:37) And how do you do it at scale? Because theoretically, in a lab, you could do that, but it would take twenty four, forty eight, seventy two hours. We had to do this within one, two, three minutes. And so we built a new technology called stitching where we could precompute a bunch of these call graphs. And then when we came into our client organization, our customers, say it's Robinhood or OpenAI or Snowflake, we could rapidly connect their first party code and our call graphs that are precomputed for open source and get the full visibility of their application.

(Varun Badhwar at 00:07:06) So that was the first problem we had to solve. The second problem was all of the vulnerability databases that exist in the public ethos. All they do is earmark which library was affected. You don't know what lines of code were affected. You don't know what lines of code fixed it.

(Varun Badhwar at 00:07:22) And so even if I had this beautiful call graph of your code knowing what methods are used, what methods are not, I now had to overlay the vulnerability data set on that. And essentially, we took a Herculean effort to go back to the past decade, look at every CVE, and build systems plus human engineering to go figure out how we could annotate every vulnerability down to the line of code that affected it and the lines of code that were actually implemented to go fix that security problem. And so we've just, over the years, built this tremendous knowledge graph that, you know, I'll pause here, but as we fast forward talking about AI and AI coding assistance, it's just remarkably valuable data.

(Joel Beasley at 00:08:03) You use an acronym. Whenever anyone uses an acronym on the show, we ask them what it is. What's CVE?

(Varun Badhwar at 00:08:09) Common Vulnerabilities and Exposures. It's the industry standard in how we communicate across vendors, across researchers what a vulnerability is. So every time somebody finds a problem in any piece of software, there's a process, there are certain organizations that you go report it to. They give it a distinct CVE ID. It goes through a full triage process to the reported vendor, then they decide how to fix it or if it's open source. It's like the Social Security number for vulnerabilities and software.

(Joel Beasley at 00:08:45) Awesome. And your LinkedIn bio, it says that there's huge amounts of malicious code in circulation. What's happening there?

(Varun Badhwar at 00:08:52) If you think about the world, the attackers, the hackers, like, their goal is to find the easiest entry point to have the maximum impact in whatever they do. Right? And with how much reliance the industry has on open source software. Like, there are packages out there on NPM that have half a billion downloads each year. Right?

(Varun Badhwar at 00:09:13) And literally, the whole Internet operates on some little library that is written by some stranger who lives in Russia, that nobody knows what their day job is, what they do, what motivates them, how they earn money, but that is the core of the software that we rely on the internet. And essentially what we have started finding more and more cases of is malicious code infiltrating into the open source ecosystem on NPM, on PyPI, and others because what people are saying is, look, this is a wild west. Developers go in, they look for utility, they find something, they grab it, they start using it. And so we have started seeing really, really popular open source projects get compromised. How does that happen?

(Varun Badhwar at 00:10:04) Well, maintainers not paying attention. They get a social engineering attack. They get a phishing email. They give their credentials. That spirals into all of a sudden, you have a new version of a library that has a 100,000,000 downloads that has malware. And most of the developers don't pin their dependencies, and so there's an auto upgrade cycle that keeps happening. It grabs the latest version, comes on the developer's laptop, you're popped. Your credentials, your secrets, everything's out of the gate. And so I think it's an emerging attack vector that software engineering teams really need to understand, which is, how do I trust this open source ethos? Verify everything I'm getting.

(Varun Badhwar at 00:10:43) Like, we have all been missing the verify layer. We just grab stuff off the internet. And I think the times are different. You can't do that. And so a big part of Endor Labs value prop, for example, is we're constantly scanning every package, every package version that's released on the internet, looking for 150 points of potential risk.

(Varun Badhwar at 00:11:01) Could be code quality issues, could be hidden maintainer change. Is that suspicious or not? A new release version, let's look at the code. It didn't have pre-install scripts, now it does. What are these scripts trying to do? Are they exfiltrating your credentials and such?

(Varun Badhwar at 00:11:16) And so just for your audience to be aware that, you know, using open source without guardrails is a bit dangerous. Harness the power of open source, but make sure you have controls in place that are scanning all of the software and giving you some confirmed data on, can this be trusted?

(Joel Beasley at 00:11:34) And so in an ideal world, my background is software engineering, ideal world, I run your tool. It tells me, you know, where the problem or the vulnerability. And then there's just a button. And like, I just click the button. Are you guys doing any of that automatically? Is there any of these situations that are so common that your machines can learn from them and then it's just a one click implementation?

(Varun Badhwar at 00:11:55) Yeah. So again, speaking of the state of the art that existed four years ago and what have we done, four years ago, what people would do is say, well, great. I see Jackson Databind, you know, version 1.3.1 has a CVE. Great. The remediation is upgrade to the latest.

(Varun Badhwar at 00:12:12) Now nobody could ever tell you if the latest had any breaking changes, any backwards compatibility issues, version conflicts. Was it gonna work in your code? So if you recall when engineers talk about dependency hell and you Google it and look at all the posts around it, it's about, oh, shit. I tried to upgrade. It broke my app.

(Varun Badhwar at 00:12:31) Then I went back. Then I tried another version. Then I went back. And it just is a complicated problem. And the reason it's a complicated problem is all of this open source software, they don't guarantee any backwards compatibility.

(Varun Badhwar at 00:12:43) They don't have to. It's open source. Use it at your own risk for the most part. And as a developer, somebody might have introduced this library seven years ago. I'm not the guy who brought it in, and I've gotta go fix it.

(Varun Badhwar at 00:12:55) So I lack context on my application. I lack context on if the upgrade is gonna work or not. And so part of that cracking of the code that Endor did, the secret sauce, is now that I have a call graph of your application, I actually know with my machine intelligence how you're using this library. What lines of code are you invoking? Where you might have version conflicts and such.

(Varun Badhwar at 00:13:17) So I have knowledge about your application. I am also tracking similar knowledge and insight about every version to version change in the open source. And so when I am about to tell you, a developer, that listen, you have a vulnerability and you've gotta fix it with this upgrade path, I can simulate in the context of your application and say if I took your existing call graph and I replaced it with this new version's call graph, would it actually cause any problems in your application? Would there be any breaking changes? Were any methods and functions replaced?

(Varun Badhwar at 00:13:49) And so with the intelligence that Endor has developed, we actually can now give you an easy button, not just with a pull request that is created with the action you need to take, but also with the confidence that when you actually approve that PR, it's gonna work and not tear up your application.

(Joel Beasley at 00:14:07) That's wild. That's, uh, what's the key way you sell this into companies? Is it time savings? Because to me as a business person and an engineer, it's like, great. I want my stuff to be secure.

(Joel Beasley at 00:14:19) Security is a big one, but just the time savings of implementing it.

(Varun Badhwar at 00:14:23) Yeah. Look, we call all of this everything in security. And there's been lots of debates in the world of do developers care about security? Do they not care about security? I call all of it a developer productivity tax. Security for the most part is a developer productivity tax. We are trying to move fast, ship applications.

(Varun Badhwar at 00:14:42) We keep getting these reports of things that are going wrong. Our OKRs typically measure us for development velocity and what we ship. Security has separate OKRs. They conflict. So what is a developer productivity tax?

(Varun Badhwar at 00:14:56) It is all the time you have to spend mostly proving your innocence to the security teams because as I told you, 90% of the things security teams often report to developers are false positives, yet you have to prove your innocence. All the manual triage, investigation, code review to go give the evidence to say, no, no, like get this off my plate. I'm not gonna fix it. Huge tax. The second thing is when I actually found a legitimate problem out of, like, the diamond in the rough, and I'm actually performing these upgrades, they are very time consuming.

(Varun Badhwar at 00:15:30) And I don't know with certainty how to even estimate to a product team or security team how long it might take me. Maybe I'll be done in an hour. Maybe it will take me six weeks. So Endor's value, when we go in and deploy a product or we typically, we replace an existing product or we augment a product like Dependabot that's just natively available in GitHub, there's really kind of a couple key metrics we track for our customers. One, how much of your backlog of reported issues did we just eliminate that you never even have to think about?

(Varun Badhwar at 00:16:01) And, you know, companies like Robinhood have given us public testimonials that we have typically eliminated 95% of the backlog of theoretical vulnerabilities that are not even real. So imagine for a moment, 95% of your backlog of security work just goes away, out of the window. So we measure how much time that saves you. The second thing we measure is how much faster with our insights are you able to upgrade your libraries and fix your code and refactor your code. And we're measuring that at about 400% increase in how fast you can remediate.

(Varun Badhwar at 00:16:33) And I'll tell you something. The reason this has become more important today than ever is the adversaries typically would take six, nine months to develop exploits for these vulnerabilities that were available. Today, with AI, spending $2.77 on these models, they can generate an exploit within minutes. So the time you had to go secure your application has gone from you probably have months to go figure this out to now you have days to actually defend yourself.

(Joel Beasley at 00:17:04) That's pretty interesting. So 400% increase in remediation speed. You're measuring the time of them not chasing vulnerability issues with code that's not called. And how do people buy this? Let's do a quick call to action for Endor. Do you charge by seat? Do they reach out to get a demo? How does that work?

(Varun Badhwar at 00:17:25) Yeah. Go check out endorlabs.com. There's actually a product walkthrough. You can actually interact and see how that works. And, also, I encourage everybody to go look at endorlabs.com/customers and just the incredible stories from Dropbox and Peloton, Robinhood, Fivенine, Cursor, and just incredible companies that are building the future of software of our time and how they actually value what Endor Labs offers them.

(Joel Beasley at 00:17:52) That is brilliant. Those are some big customers.

(Varun Badhwar at 00:17:55) We certainly have some amazing customers that we're very proud of, proud of that. Speaking of developer productivity, a great segue could be starting to talk about the emergence of AI coding agents because I think that ties right into the developer productivity.

(Joel Beasley at 00:18:10) That is perfect because that was exactly where my mind was going. Because there's a couple parts of the conversation. There's all the existing code library and dependencies, but then there's also what I'm doing right now with coding agents.

(Varun Badhwar at 00:18:22) Yeah.

(Joel Beasley at 00:18:23) So what do you do there?

(Varun Badhwar at 00:18:25) So now we've been talking about developer productivity. And if you look at any company on the planet, everything that they're boasting about today is how AI is going to drive developer productivity up. Behind all of that are these AI coding agents. And let's kind of go back behind the scenes. How are these AI coding agents trained to write software? They're trained on all of the code on the Internet, open source code. And so it's great, but it's also scary because they have learned the good practices, the high quality code patterns, but they have also learned all the different poor development patterns, non-scalable ways to write code, insecure ways to produce software. And statistically, there's a great academic research out there that said that looked at GitHub Copilot and a few of these agents and said, between 50 to 62% of the code generated by these AI coding agents is actually insecure by default. Now, one question can be, well, is that better or worse than human generated code? I don't know if there, I haven't seen much studies on what human generated code is, but hypothetically, it feels like a bigger number.

(Varun Badhwar at 00:19:39) It's also scarier because the velocity at which coding agents produce code and also the verbosity, they just write a lot of lines of code. And so who is now going to be responsible for actually addressing all of their sins from a security perspective or a tech debt perspective? Another question before that, before we get into how we solve that is, well, why can't they get it right? Well, Joel, they can't get it right because, ultimately, they do not have labeled information to unlearn the bad practices that they picked up from all their training data. There's no one out there selling label information to say, well, this code you learned on GitHub is secure. This other one avoid, and don't do that. Right? And so they're just replicating the patterns of what they're trained on, and they're producing a lot more code for the organizations, and a lot of it is insecure. Now, there are two ways to solve it. The old way you would do this is you would basically let it ship the code, you let it go into a pull request, but then some security scanners would kick in, identify some problems, and guess what? Put it into the backlog of the humans to go fix. We think the best way is actually to have a security pair programmer integrated into Cursor, into Copilot, into Augment, pick your favorite coding agent and IDE interaction. And essentially, what Endor does is it is observing the interaction between the human and the coding agent. It is seeing the output of the coding agent. It is giving real time feedback back to the coding agent to say, listen, you're making some mistakes here in terms of security. Here are the problems. And by the way, remember we just talked about remediation? Because we have all this unique insight of the code and how to fix it, we give it, and the AI agent is very effective without burning a lot of tokens to actually rewrite the code securely with our feedback. And so we think this kind of moves to a secure by default strategy where having security oversight baked into your coding agent, overseeing AI, essentially now you're playing AI with AI. Right? There's an AI agent purpose built for writing code. Our AI agents are purpose built for securing code and reviewing that code, and they work in cohesion to actually make sure the outputs are secure by default.

(Joel Beasley at 00:21:56) Are you guys publicly traded?

(Varun Badhwar at 00:21:58) Not yet. We will be someday.

(Joel Beasley at 00:22:00) Okay. Let me know. I feel like this is the future. So many people are going to pile on to this because it just makes sense. It's not a hard to calculate ROI. It's not like this amorphous, we'll just do it, and it'll get better. It's a very specific thing. And is it just one product or service like this or is it a whole suite? You have different products.

(Varun Badhwar at 00:22:26) We have a suite of capabilities you can license and aggregate as the entire platform where you can start with a certain set of components. Maybe you just want to start with scanning of the open source software and doing the remediation around that. But, also, you may want to extend that to doing agentic security code reviews of your code. So we allow the customers the flexibility of how they want to license these components, altogether or start in one of these places. And, essentially, though, our goal and objective as a company is to help customers ship secure code as quickly as they can, and eliminate that developer productivity tax that I keep coming back to out of the equation. Because today, it's a trade off. I either ship fast or I ship secure. And we think you should be able to ship fast and secure by having the right tools and frameworks in place in your SDLC that are just very natively built into the platform. And one of the core beliefs we have is engineers, the developers, should never even have to see and or go to an Endor UI or get out of their workflow. We come and meet the developers where they are in their pull request workflows, in their coding agents, wherever they live.

(Joel Beasley at 00:23:41) I love that because it's so frustrating getting a new UI, a new thing to do.

(Varun Badhwar at 00:23:47) Yeah. You know, I'll give you a good story here. Atlassian, obviously, I think all developers use some parts of Atlassian somewhere in their life, whether you love it or hate it. We obviously love them as a partner. But Atlassian rolled out Endor across 9,000 developers and 28,000 plus code repositories in three weeks. And that's just how we can scale and ramp this up across the enterprise.

(Joel Beasley at 00:24:11) Okay. But in all fairness, Atlassian has some of the greatest people on the planet working there. I've done some interviews with them. No kidding, Varun. Every person I've talked to, I think it's four or five different leaders at Atlassian over the years of doing this show was just mind blowing. I remember them by name.

(Varun Badhwar at 00:24:29) Yeah. They're incredible people over there for sure. And the engineering practices are great. But look, you know, we've done it there. We do it for small startups that are going to be the future of enterprise software builders. And then we have some of the, you know, forty, fifty year old code bases that are running Java seven, Java eight, C, C++ without package managers, and we support them as well. So, you know, the way we've designed our platform and architecture, I just want to be clear, is, you know, we call it from 40 year old C, C++ code to modern monorepos and Bazel architectures. We kind of cover the data.

(Joel Beasley at 00:25:03) Oh, I'm glad you brought that up because at first, I was just kind of thinking of things active projects that are newer projects, more modern stuff. But you can go all the way back to 40 year old C++.

(Varun Badhwar at 00:25:14) We do. And we have the best technology there because, you know, if you think about it with C, C++, the foundational problem is there's no real package manager adoption around C, C++. With JavaScript, you have NPM, you got Maven with Java. You got NuGet, but 90% of the world writing C, C++ code has no package manager. So how do people use all the code? They just copy paste stuff. Without packages, without package managers, how do I even identify that? And there's been really old, clunky ways of doing that, which are built on just matching hashes of, hey, if this symbol is a code component that is similar to this because it matches a hash, then great. I'll flag it. But if the developer slightly even modifies a variable name or adds a comment in that code, I can't even identify and attribute where did this code originate from. And, you know, we've solved that forty year old problem with a brand new approach using LLMs and embeddings to actually build embeddings of all that C, C++ code on the Internet. And now instead of relying on hashes, we can actually match the code even as the developers modified it and attribute it to the origins of where it came from. And so that's a huge problem that customers have had from a legal perspective. Think about embedded systems being shipped, not knowing what components of software it relies on. We've solved that problem, taken a modern approach to solving a 40 year old problem.

(Joel Beasley at 00:26:36) That's pretty cool. That's actually really interesting. Now whenever I do these types of episodes, I always get questions people ask after them about, you know, do you do this in health care or can you do this with banks offline? Do you have on prem type solutions? Do you have all that?

(Varun Badhwar at 00:26:54) Yeah. Look. Our customers span from 100 year old insurers, largest financials on the planet to the most modern companies. We have a very flexible architecture of how we scan your code, where we scan your code. If you're a modern enterprise, you just want to plug in a GitHub app or a GitHub action and let us go crawl and run across all your repos, great. We could do that. If you are much more sensitive to where your code is and where it lives, we can scan in your CI/CD pipelines as a step in your build process. All of this is very extensible, very flexible, and can be handled across the board.

(Joel Beasley at 00:27:33) Alright. Now I'm curious to know when you're going in and talking with these companies, do they already have a good idea of how much time they're spending on the security debt? Is it already a pain point, or is it something you're educating them on?

(Varun Badhwar at 00:27:48) We're educating that there's a better way. I think everybody is frustrated and given up. I feel like in most organizations, if you were to run a poll with your development teams of rate your relationship with security one to 10, it's pretty adversarial. And it's pretty adversarial because security teams feel like developers ignore what they send their way. Development teams feel like security doesn't understand how code is written. And the larger the enterprise or the longer the backlog. We have measured this at large banks. The backlog is 5,000,000 security issues to be fixed in your code base. You're probably not going to get to 5,000,000 things to fix in the next ten years, even if you invested that time. We've talked to some large insurers where they benchmark how much time developers spend on security problems. Upwards of 50% of developers' throughput is focus, is just trying to fix all these tech debt, security debt kind of stuff. And so, while your CEOs are coming to you and saying, well, we need coding assistance, we need to drive productivity out. Sometimes you just got to look at the basics and say, well, if the ask is to improve developer productivity, let me remove the bottlenecks that actually prevent them from building features and shipping software. And security tends to be a very big component of that. And, you know, the people have easier time measuring how many problems are being reported to them because they have some existing tool. You might be using Dependabot. And, you know, we have a customer that did a talk at GitHub Universe that said, you know, Endor came in and eliminated 1,000,000 Dependabot alerts from their backlog with our analysis. And so easily quantifiable, you know what your Dependabot backlog is showing, Endor comes in, runs our analysis in our way, completely changes the narrative. That number is more measurable. The fuzzier number that most customers have a harder time to measure is how long is it taking their development team to actually fix every security vulnerability that's been reported to them. That metric is a little fuzzy.

(Joel Beasley at 00:29:57) Earlier, when you were talking about the OKRs of security versus OKRs of developers being sort of at odds, has anyone found a good solution to that? Or is that just part of the problem? It's just how things are.

(Varun Badhwar at 00:30:11) Yeah. I think people are trying to solve that problem in about 20% of our customer base. Product security as a function reports not into the CISO but to the CTO. So traditionally, if you put them out there under different leaders, you know, you've got conflicting priorities. In companies that are figuring out that this isn't working, the product security, software security function is moving to the engineering platform CTO function. So then at least you have a single throat to choke to say, well, the CTO organization is responsible for the security of this software as well. So we're starting to see that evolution. I actually encourage in most of our customer engagements that if the security team is not bringing a representative from engineering into the evaluation process, I actually consider that a bit of a flag. And I usually encourage our customers that I talk to with security side to say, please bring your counterparts from engineering because, great, you can go select a product. But if they don't understand and appreciate the value they're getting because as I told you earlier, we're not just addressing the security problem, we're addressing the developer productivity problem.

(Varun Badhwar at 00:31:18) Upgrading software and libraries is a developer problem. And so the more you can bring those people on, the more value that people find in our product. And we try to break those adversarial boundaries to try to bring more cohesion into a function. But as an industry, I think there's still a long way to go. And the thing I always encourage board members and CEOs when I talk about this problem is, look, the CISO's OKR and security should not just be how many problems did they find and report, but how do they enable the business to do what the business needs to do.

(Varun Badhwar at 00:31:51) So revenue and revenue generation should be a part of the security leadership's OKR. And security should be a key part of the CTO organization's OKR. That's the only way this will work.

(Joel Beasley at 00:32:06) A lot of board members now are pushing the CEOs to get some sort of ROI with AI. Right? It's happening in a lot of different companies. This sounds like it would fit into that plan. If I'm a CTO and I implement Endor Labs, I can come back to my C-suite peers and say, hey, we actually leveraged AI to reduce our backlog of CVEs.

(Varun Badhwar at 00:32:29) Yeah. There's two parts to this. Right? You've got your legacy code base that's not going away, and then you're writing new software. And the legacy code base, the best way to measure this is how much of our backlog did Endor just rapidly eliminate.

(Varun Badhwar at 00:32:43) So these are things we don't even need to get distracted about. And usually the older the software, the less interest development teams have to touch it because it's fickle. They don't know what's gonna break. It's a house of cards. For the modern software, it's really more about how am I creating the paved roads as my developers are rapidly gonna start writing software. And by the way, we haven't even touched on vibe coders and citizen developers, but in companies, now your worry is not just the trained software engineers, but other departments, other functions that are gonna be contributing to your code base.

(Varun Badhwar at 00:33:15) How do I create the paved roads? Because if I don't create the paved roads and I have security embedded into my AI-powered software development lifecycle, if I had a backlog of 3 million security problems in the last three years, the next three years, my backlog will be 9 million because of the increase in code generation. And so, yes, I think the metrics and the way CTOs should really consider where Endor Labs fits is it's gonna help me run my business, my legacy code, and help me as I'm changing my business and changing my SDLC to just put in the paved roads so I never have this kind of security debt problem to look at again in the future.

(Joel Beasley at 00:33:55) Now I've heard of vibe coders, but what are citizen developers?

(Varun Badhwar at 00:34:00) A more polite way of saying vibe coder.

(Joel Beasley at 00:34:03) Vibe coder. Okay. That's what we're doing now. We're just like, oh, we'll soften it up a little bit.

(Varun Badhwar at 00:34:10) Yeah. I think it's the more enterprise kind of terminology to use is like, hey, inside of a company, there are more citizen developers. You know, my wife coding and my kids coding, that's more vibe coding, but inside of an organization you see more. But look, it's a real problem. Even in my company at Endor, marketing is now checking in some code.

(Varun Badhwar at 00:34:29) Sales and SEs are checking in some code. Customer success teams, support teams are producing things, and so it's great. Right? We wanna harness the ability for English to be the most popular programming language of the future. We wanna harness that.

(Varun Badhwar at 00:34:46) But we wanna provide the paved roads because the thing we have seen is with AI, especially coding agents, it's not just a problem of the known security vulnerabilities, the things we said that have a CVE ID and a CVSS score. It's about business logic things. It ends up doing silly things. So for example, if you don't prompt it, it's a fascinating experiment. I encourage everybody to do it.

(Varun Badhwar at 00:35:12) Prompt a coding agent, your favorite coding agent to write something in Python for you. Right? Build a web server, HTTP request to authenticate something. Same prompt, same logic, now ask it to build it with a secure prompt. So ask the AI coding agent to make sure it follows all of the security practices.

(Varun Badhwar at 00:35:30) Make sure it has proper authentication, authorization, and look at the difference of the outputs. In one case, it'll give you what you said with little to no security controls or basics even. Not even basic session validation might be missing. Basic business logic might be missing. If you ask it correctly, then it'll do things a little bit better.

(Varun Badhwar at 00:35:49) So my macro point there is if you're a company with 20,000 developers, you cannot expect that every one of those 20,000 developers will know exactly how to prompt it to write secure software. And so what you need again is guardrails to make sure that that business logic is covered properly and you don't have silly things in your code base that is just amateurish. But the problem is humans don't have enough time to code review all of this AI-generated software manually. So you are gonna need automation and AI to do that, and you're gonna need trained specialists that are security specialists to do that. And, you know, again, that's part and parcel of how are you gonna embrace vibe coding: putting the right paved roads in place to automate a lot of the review and diligence process.

(Joel Beasley at 00:36:35) It's interesting. Yeah. And it's not all or nothing either with the labels of the vibe coding and and whatnot. Because I've noticed myself, I've got a fairly basic website that I have that I use through Lovable just because I wanted to experiment with Lovable. And so that's one experience.

(Joel Beasley at 00:36:54) And then sometimes I'll use, you know, I've got Cursor. Yeah. And so I'm working on maybe some legacy applications, improving those or adding some features. And so I kind of skip around and use different things for different reasons. And so sometimes over here, I feel like Lovable is pure vibe coding.

(Joel Beasley at 00:37:14) That's actual vibe development.

(Varun Badhwar at 00:37:16) Yeah. It's building websites. Right? It's not building core backend kind of software.

(Joel Beasley at 00:37:20) Yeah. And I found it's really bad for that. It's not good for it. I don't, and I'll use as little words as possible, it's just not good for it.

(Joel Beasley at 00:37:29) But when you open up Cursor and you can actually, it can help you write the function. Like, alright, I need a function that does this, and then I need to test for it. And you can just go function by function. It's just generating one thing at a time. And that seems to be pretty reliable.

(Joel Beasley at 00:37:44) If I'm wrong, send me a message.

(Varun Badhwar at 00:37:47) Look, my two cents on this is Cursor supercharges developers. Lovable takes people that have never written a line of code and helps them become developers, vibe coders.

(Joel Beasley at 00:38:00) That is absolutely right. And did you see the new trend with vibe marketers now? They've kind of adopted that.

(Varun Badhwar at 00:38:07) There's a vibe everything. You know, we have a lot of jokes from vibe internal at Endor that I won't get into. Look, it's a fascinating thing because I study the data and academic research a ton around vibe coding. And look, a lot of this will get better. It's like, you know, when you had horse carriages, you don't have the infrastructure for cars, and then you had to build all the infrastructure and traffic lights and all the controls and rules and regulations for cars.

(Varun Badhwar at 00:38:36) You're gonna need that for AI running software. Right? You're gonna need paved roads. I keep coming back. You're gonna have to put all the controls that are just automated.

(Varun Badhwar at 00:38:43) Because today, if you talk to most trained developers, the feedback you'll get is they've gone from 80% of their time writing code, 20% reviewing code, to 20% writing code, 80% reviewing code. Because that code that comes out still needs several iterations to get it production ready, right, if you're building serious enterprise software. There's a lot of promise. It takes a lot of the grunt work away, writing test cases, auto-completing code, lots of benefit. But, again, you can't let it loose autonomously necessarily and expect it to have a production-ready application that is secure, scalable, and all of that.

(Varun Badhwar at 00:39:22) And so, you know, look, that'll change rapidly. I couldn't tell you. In six months, maybe it'll start doing that. Maybe it'll take five years. But I think our belief fundamentally at Endor is most companies, by the way, will also keep switching in and out of these tools because, like, one day, Cursor is hot. The other day, Copilot's hot. The third day, Windsurf is the best tool on the planet, and these things will keep changing. And so as a company that's worried about putting the paved roads, you almost need an independent layer of security and quality and other controls, where your developers can bring in whichever tool of their choice for writing software, but your harness for testing, verification, security is just consistent across these.

(Joel Beasley at 00:40:03) That's a good point. Josh, we need to clip that point. That's a really strong point. I do wanna talk about some leadership insights, though, because you are a founder. So I like to ask this question.

(Joel Beasley at 00:40:14) It's got some guardrails on it. So I wanna know the best leadership advice that you've ever received. But then, it's like you received it, you've implemented it, it worked, and you've kept it for a long period of time.

(Varun Badhwar at 00:40:28) Look. The best practical leadership advice I have received is specifically around building the right culture, especially as you think about hiring engineers in a startup. Right? You're two guys in a garage trying to build a company.

(Varun Badhwar at 00:40:49) People are coming to you leaving big stakes on the table, leaving nice comp packages, especially if you're trying to go for the best talent. You know, why do they come to you? And I think for me, the biggest learning over the years, and I made mistakes, but I think I've learned and corrected those, is uber transparency. You know, if you think about incidents that have happened of late where, you know, part of Windsurf got acquired and bunch, you know, small handful of founders and people made money, most of the engineers were left on the street. There's more skepticism of what is the upside of startups.

(Varun Badhwar at 00:41:22) And I believe the way you address that is just transparency in how you engage prospective candidates, engineers, employees. And so one of the things we do at Endor that is different, surprisingly, I don't know why it's different, is even when we're having offer negotiations and conversations, we're very transparent about our cap table. How do you even consider the value of equity? What could the upside be? What could the downside be?

(Varun Badhwar at 00:41:50) You know, how much is our total stock option pool? What was the value of the last round? What could be the value of the next round? What is the strike price? What is the upside?

(Varun Badhwar at 00:42:00) And I say this because you have a lot of technical audiences here, and a lot of engineers have lots of choices of where they go. They work for big tech, they go to FAANG, or they go to a startup. And I would say, if you are considering a startup to bet your career on, make sure the founders and the teams are very transparent with you about the compensation, the equity structure, the upside for you. And the second piece around that is when you are in a company, making sure that you're really understanding the big picture. Like, great, it's nice, you're going in there writing code. But a lot of focus for us at Endor is we share the dirty laundry with all employees. We'll talk about what's working well. We'll talk a lot about what's not working well.

(Varun Badhwar at 00:42:44) Because I feel like you're in a journey, and everybody knows a startup journey is not a straight up to the moon. You eventually might get to the moon. There's lots of ups and downs and bumps along the way. And you want these people committed and bought in because they understand that that's what a journey is.

(Varun Badhwar at 00:42:59) And so you treat them as adults in the room. You share a lot of that practical feedback. What's working? Is sales working? Is product working?

(Varun Badhwar at 00:43:07) What's broken? How's the leadership going? What changes are you thinking about? What do you need to make? You know, the kind of evaluation of the company and all of this.

(Varun Badhwar at 00:43:16) I think it really gets people committed and focused into the mission and to work with you on this.

(Joel Beasley at 00:43:23) That was good. What's a leadership mistake that you've made early on that you would never repeat?

(Varun Badhwar at 00:43:29) I'll come back to hiring because I feel like that is an important topic. Most companies, you either build a great, incredible product and you win the market, or you need the best engineers for the best product. Oftentimes, I've seen people take the easy route, like, hey, I worked for company X. I know 10 people in that company X that are my peers that I'm just gonna bring in, and we're gonna build a product with all 10 of us that understand.

(Varun Badhwar at 00:43:55) The fallacy in that is all 10 of you think alike. All 10 of you have had the same exact experience. Let's take an example. If all 10 of you worked at Google, you have no idea how the real world outside of the Silicon Valley works with real software engineering problems, the legacy architectures, all of the other ways that people operate. And so, you know, I've made that mistake before where I'll just go to the same pool of talent that I know and it's an easy answer and we'll go grab 10 people and get to work.

(Varun Badhwar at 00:44:22) And what I found is along the way, you just have a lot of blind spots as you're building software, building products, shipping software, things that are different. So with Endor as an example, when we started, we made a promise to ourselves as founders that no more than two engineers in the first 15 would be from the same company. So we actually worked extra hard and we ended up with two from Meta, two from Cisco, two from Palo Alto Networks, two from GitHub, and two from Uber. And we created a very diverse engineering organization, which to this date is probably one of the most credible foundations that we have in this company.

(Joel Beasley at 00:44:58) Oh, yeah. It makes sense because you're building tools for developer workflows. You need to know all the different types of workflows. That's awesome.

(Varun Badhwar at 00:45:05) Yeah.

(Joel Beasley at 00:45:06) So you did make that mistake at the beginning. You just grabbed a whole group of people and then it didn't work out well.

(Varun Badhwar at 00:45:11) So, you know, the benefit I have is I've been building startups the last 15 years. Endor is my third. So I wouldn't say I made that mistake at Endor, but I did certainly early in my life. Yeah.

(Joel Beasley at 00:45:23) Nice. Nice. Now, you've been doing startups for 15 years. How have you mixed that with your personal relationships? Do you have kids?

(Varun Badhwar at 00:45:34) Oh, it's a great topic. So I do have kids. I have twin boys that are five. I have an incredibly supportive wife that has been there from the point of time where I had nothing in my life to show, and I had no successful startup or exits at the time, all the way through the ups and downs of startup building, getting acquired, having an incredible run at the last startup, having twins born in the middle of the pandemic, and then when they were literally one year and two months, me telling her that I wanted to quit and start my next startup.

(Varun Badhwar at 00:46:14) And that was a tough subject of discussion. And to this date, I'd say there's still some bitterness of what if. And, you know, look, I had an incredible success at the last startup. My wife's perspective was take a break. Let's travel.

(Varun Badhwar at 00:46:29) You know, kids are young. This is time to do it. And, you know, my counterpoint was, look, I've stumbled upon this idea that we discussed a little bit, and how I ended up with the Endor idea. I have this idea. The time is now.

(Varun Badhwar at 00:46:43) Ideas, you know, don't wait for you six months, 12 months. You know? Somebody's gotta solve it. Somebody's gotta solve it now.

(Varun Badhwar at 00:46:51) So that's the story of where we ended up. And look, my goal right now is I am very focused on how I prioritize my time because I want to make sure I'm there for bedtime with kids. I want to, as much as possible, drop them off to school in the morning, spend Saturdays mostly undistracted. And so there's just a manic prioritization of how I spend my time and what I spend my time on.

(Joel Beasley at 00:47:19) That is awesome. I've got three little ones, eight, six, and three.

(Varun Badhwar at 00:47:24) I mean, similar. Yeah. So if you average it out, you're calling me the same.

(Joel Beasley at 00:47:28) Yeah. Not twins, though. Whenever I meet people with twins, I'm like, look, I will never say that I understand what that's like because we did it one at a time, and it was hard every time. So two at once? Congratulations, my friend.

(Varun Badhwar at 00:47:41) Thank you. Thank you.

(Joel Beasley at 00:47:43) Thank you so much for listening. And if you found this episode useful, please share it with a friend or colleague who you think would get value from it. And if you have topics that you'd like to hear discussed on the podcast, either add me on LinkedIn or send me an email, [email protected]. Every time I get an email or LinkedIn message, it absolutely makes my day and inspires me to keep going.