The AI Coding Arms Race is Transforming Software with Henrik Plate & Amod Gupta of Endor Labs

(Intro/Outro Narrator at 00:00:00) Today, we're talking to Henrik Plate and Amod Gupta from Endor Labs about their State of Dependency Management report and what it reveals about security flaws in AI coding. You're listening to Joel Beasley, Modern CTO.

(Joel Beasley at 00:00:18) I already got to learn a little bit about your company from your CEO, but can you just give me the high level overview of what the company is and what it does?

(Amod Gupta at 00:00:28) Yeah. Endor Labs is an application security platform. Our goal is to help our customers stay secure, ship secure code by securing their code, the dependencies that their code depends on, the tools that their code depends on, everything in the pipeline all the way from when developers start writing code to when it hits your runtime environment. That's what we are in a nutshell, and we've got a bunch of tools in that platform that help the developers in every stage of the software development life cycle, gives them insight, protects them from malware, tells them when they're using vulnerable dependencies, and so on and so forth.

(Joel Beasley at 00:01:04) Yeah. And when I saw this on my calendar, the topic being how the AI coding arms race is transforming software supply chains, I was like, that sounds cool. That sounds fun. And it looks like you guys have both been studying this quite a bit. Henrik, you conducted tons of research and published a paper with your team. Can you tell me about that?

(Henrik Plate at 00:01:23) Yeah. Of course. So, I mean, we all know this AI wave is here, right? A great deal of developers already use it on a daily basis in order to boost their productivity. I guess you have some anecdotal evidence when discussing with your peers and colleagues and friends, and it's basically the same for everybody I talk to. And so they are going to stay, of course, and evolve further from the current agents running in integrated developer environments to very soon, I guess, fully autonomous agents pulling and resolving tickets from Jira or GitHub issues and God knows what. So with this report, we wanted to basically look at some of the security aspects that come with this revolution. And I say some because this whole security space is pretty big, so we had to be somewhat selective. And the two important topics that we looked at was, first of all, the dependency and dependency version suggestions that are made by models when they do develop code, right? So they introduce new dependencies, new open source packages, and they also select which versions will be introduced in this application. So this is one aspect, particularly around the versioning, that to our knowledge has not been covered yet by existing works, academic research or so. So that's why we wanted to focus on this. Also, it's in the backyard of our company when it comes to vulnerable open source components, right? So that is our, let's say, basic bread and butter business, I would say. And the second topic is we wanted to look at MCP servers, which is yet another hype on top of this AI hype, if that is even possible to be more hyped than AI. And so since this announcement from Anthropic last November or so, there have been thousands and thousands of MCP servers being developed, released to the public. And so we wanted to look a bit at their security, whether they are enterprise ready. And yeah, and so these are the two main topics covered by the research report.

(Joel Beasley at 00:03:36) So this report you put together, it's the State of Dependency Management. Is that the correct name?

(Henrik Plate at 00:03:42) Exactly. It's the third in a series. So we already had comparable editions in the last few years, looking at other aspects of the software supply chain. And this year, we are looking more at this AI code assistance, AI code generation for obvious reasons. Also because in some way or another, they are yet another dependency that developers and development organizations introduce into their company, basically, in their software development life cycle.

(Joel Beasley at 00:04:15) What's the most surprising thing that you found after doing this year's report?

(Henrik Plate at 00:04:20) Well, I would say most surprising and interesting, I would say. So there are many takeaways, right? And I hope we are going to jump into those later on. But most surprising and maybe entertaining were maybe two things. The one is as part of this one experiment, I was really going in detail through those communication protocols. So I was able to observe the conversation going on between the model, the agent, and the different tools it would use. And that was really funny to see just how many times the tools were not invoked, even though I told them so explicitly in uppercase many times and still they didn't do it. Or they invoked it wrongly again and again, making the same mistakes. So that was very interesting to dive into the detailed conversation. I think there are a lot of learnings around how you design agentic systems, how to design those tools that you make available to the models, because this is very different in terms of developing programmatic APIs. The second surprising thing was that once more the open source community proved to be very innovative in terms of picking up new trends and developing stuff. So since the announcement of Anthropic in November, there were more than 10,000 or so MCP servers released on GitHub repositories. And in one week of March, there were 1,000 new GitHub repositories alone where the open source developers basically proposed those tools to be used and integrated in those agentic systems. So I find this once more noteworthy.

(Joel Beasley at 00:06:16) Amod, did you read this report, or did you just throw it through ChatGPT?

(Amod Gupta at 00:06:21) I read this report. It's actually very fascinating to see how the focus of the report has evolved over the years. When Henrik did it the first time in 2023, the report focused on how the code is assembled more than it's written. Meaning, 90% of the code is coming from open source dependencies. Fast forward 2024, fast forward 2025, and we find that AI is writing a lot of your code. But guess what? AI is trained on the open source code that was being used as components to your code that was being assembled. So, yes, the world has changed and the concerns are a little bit different, but some things remain the same. There is open source code out there in the world. In 2023, the predominant trend was you were just importing that in your source code. And Henrik was dealing with a lot of concerns around that. 2025, AI is learning from that code and writing and in some way recreating that code in your applications now. And now we are dealing with those concerns. So it's pretty fascinating to watch how the report has evolved over the last two, three years.

(Joel Beasley at 00:07:29) And what's your role there at the company?

(Amod Gupta at 00:07:32) Oh, I run the product and design organization at Endor Labs.

(Joel Beasley at 00:07:36) Excellent. So you work closely with Henrik to take the security findings and put them. How do you work together?

(Amod Gupta at 00:07:43) Yeah. So, I don't know, Henrik, if you want to share a little bit about your role. But in terms of how I work with Henrik together is, Henrik is the brains behind the organization.

(Joel Beasley at 00:07:55) I got that. He's mad research scientist. Yeah. I picked up on that pretty early in the interview.

(Amod Gupta at 00:08:00) Yes. Exactly. So my job is to go and find out what problems are customers facing. How can I make their lives easier? Then I take those problems, synthesize those problems, and take them to Henrik. And Henrik and his team then does research, deep research, and comes up with very innovative solutions around how to solve those problems. We work together on how to package the solutions, and they take it back to the customers.

(Joel Beasley at 00:08:26) Can you give me one example of the full life cycle of that?

(Amod Gupta at 00:08:30) Yeah. I think the most recent one that comes to mind is malware attacks. They've been on the rise, right? The Shilulu attack or whatever the original name was that morphed into so many other packages. So we worked very closely on that in order to detect that that was happening and then detect how it was percolating from one package to all the. I mean, the unique thing about that attack was that it wasn't limited to that one package. It moved from that package to another horizontally and then spread widely in the ecosystem. So we got the early signs that that was happening, and then Henrik's team was instrumental in figuring out how to identify that footprint, what safeguards to put in, what policies to put in, and so on. Henrik, I don't know if you want to add to that.

(Henrik Plate at 00:09:21) Yeah. I mean, I can maybe explain a bit. So in this particular case, indeed, this campaign that you mentioned and the others that occurred in the last couple of weeks are very much linked to this whole AI topic itself. And I hope maybe we can sometime spend some time later on one of these cases. So indeed there are new trends in malware development that we see. I mean, this whole problem space started really, I would say, in 2018, 2019 when the number of malicious packages published on public repositories really started to increase and now skyrocketed. And even though many of the attack vectors being used remain the same, we also see new flavors. And one which is linked to AI is, of course, that malware developers use AI to develop their malicious stuff faster. I mean, that is very obvious, right? That is something that every developer boosts productivity. And so do the attackers. No surprise here. What I found more interesting are those cases or is this other case that came up. I think it was also in August or so. It was an attack on the NX build system where something new was introduced. And that was that the malicious piece of code, once it was installed and running on a compromised developer system, it would try to reach out, identify whether there is one agent running. And if yes, it would actually try to collude with that local agent in order to do its job, right? So what we saw there in this malicious package is that basically it searched for three code agents, code assistance, Cursor being one, Claude, and I think one from Amazon. And it would basically then once when there was one, it would say, your agent, please help me in order to collect credentials on this developer system, search those in those directories, and then please compile me a list of files that I should then exfiltrate to the attacker controlled host. So I know and have no secrets. And so I found this was a new flavor or dimension of the supply chain attacks showing just how careful we need to be about all those very helpful assistants running on all our developer laptops, right? They need to be secured. Unauthorized access needs to be controlled or prevented and so forth. So that was an interesting case where we see the collaboration between the research team on my side, let's say, and the product team on Amod's side to bring new detection techniques and influence the way we build our products to cover such new threats and the changing attack surface.

(Amod Gupta at 00:12:31) Incidentally, another interesting fact about the attack that Henrik's referencing in August, when the NX packages were trojanized. That happened because of a vulnerable GitHub Actions workflow. And guess what? That GitHub Actions workflow was written by an AI agent. That wasn't a human written workflow. So we're on topic there, Henrik?

(Henrik Plate at 00:12:54) I mean, I see honestly, I see this so often. I look at a piece of malware, and then I sit in front of a lot of very well written comments. And I say, well, this is exactly like how AI generated code looks like.

(Joel Beasley at 00:13:08) That's wild. I never even thought of that as the attack vector, just getting into my system and then talking to my assistant. Because there's not a lot of protections around the assistant. We've let the assistant into the environment. We said, okay, you can run wild in this environment. And we haven't really thought about it, and then someone figures out to hijack that. That's actually kind of brilliant.

(Henrik Plate at 00:13:34) Indeed. Yeah. And the more MCP servers and the more tools you provide the agent access to, the more powerful this attack can become.

(Joel Beasley at 00:13:43) And can you give a quick just like 10 second overview of what an MCP server is for people that don't know?

(Henrik Plate at 00:13:50) The MCP server, I mean, it's basically, if you want, Model Context Protocol. Some people call it the Bluetooth of AI. The whole idea is to have a standardized way of providing more context information to agents so they can take up to date and better decisions, as opposed to just working with outdated old training data. So it's basically, in my mind, a nice visualization is, if you want, the hands and feet of the model in order to interact with the digital world, basically, to learn new information, but also to execute and perform tasks. Be it scheduling, be it to schedule a calendar event or be it to search for vulnerable code or manage your dependencies as you generate your application.

(Joel Beasley at 00:14:48) Okay. Maybe maybe I don't understand. Because my understanding of it, maybe we're saying the same thing with different words, but I thought it was more of like a way to expose like my API to agents. Like, if I had a consumer based API that you would normally hit and connect to, I'm limited to working with the human developers and their AI assistants that wanted to connect with that. And they have to provide all this context about connecting to it and everything. But I thought the MCP server was where I would basically define all of that so someone can plug into it.

(Henrik Plate at 00:15:20) But I think we are saying the same thing. Okay. Alright. Cool. As an MCP server, you can define tools and you can define resources and make them available to an agent in order to both let it execute tasks, but also to get more information.

(Joel Beasley at 00:15:38) Alright. You're opening my mind. See, this is one of the things I like to do is I get these general ideas from just talking to people. I haven't heavily researched MCPs on a very deep level. And then I find experts like you, and I kind of validate my basic high level conversational understanding with what reality is to see where I'm wrong.

(Amod Gupta at 00:15:59) Well, that's exactly right. I think that's the right way to think about it. I think Henrik would agree. They are basically, we use MCP servers to extend the capabilities of the model. The model has been trained on a fixed set of data. So the model knows everything about that data. For let's say, the training stopped sometime in August. So from August on to now, October, all the things that have happened in the world that you want the model to be able to access, you can give it a search tool that the model can go and retrieve that information using the search tool. Which, by the way, tool is another way of saying APIs like you're saying, Joel. So APIs, general APIs, they extend the capability of the model and let it perform tasks, update itself, add functionality that it wasn't previously able to do.

(Joel Beasley at 00:16:51) How do you guys identify all these potential issues. How do you keep it from like, I've used these type of tools previously. So my background, software engineer for 17 years. Once the podcast got more popular, I stopped coding every day. So it's been about five, six years since I've been coding every day. But my early experience was that they would just generate a ton of noise. Like, here's 83 million security issues. How do you figure out which ones to actually spend time on?

(Ahmad Gupta at 00:17:21) Sure. 83,000,000 security issues that we found. I mean, you're not too far from the reality. The number of issues that the tools have typically found are so much that no engineering team has the capability to fix them in any reasonable amount of time. And even if the numbers don't run up into millions, they certainly run up into tens of thousands in large companies.

(Ahmad Gupta at 00:17:47) And there's no way you can fix them in the next five years also. So then what becomes important is prioritization. How do we identify of those tens of thousands of security issues which ones are the most critical? Which ones are the most important to fix?

(Ahmad Gupta at 00:18:02) And criticality has to have context. What I mean by that is it's just not critical because somebody somewhere slapped a critical severity label on it. Are you really affected by it? So you might be using an open source dependency that has a very large surface area and has a lot of critical vulnerabilities. But are you using that particular functionality of the open source dependency that now exposes you or your application to any of the critical dependencies?

(Ahmad Gupta at 00:18:32) I mean, I go back to the comment that most of the code is now assembled as opposed to being written. When you assemble code by adding third party dependencies to it, you are adding the whole package to your application. But you might be using a very small surface area of that package. If in that small surface area there's a vulnerable dependency, then you need to fix it. You need to care about it and discover it and do all the right things.

(Ahmad Gupta at 00:18:56) But typically, what we find is 90%, sometimes even up to 95% vulnerabilities, at least in the open source ecosystem, are in parts of dependencies that the application isn't using. That one app some other application somewhere is using this component. Application A is using this part. Application C is using that other part. So what we find is if you focus on the surface area that's actually reachable from your application, meaning you can possibly make a function call, you can possibly use that part of the open source dependency. If you use dark to draw a boundary around the open source surface area that you're using and then look for security issues in that, that is the biggest bang for the buck that you can get in terms of prioritization. And those are the ones that you actually need to fix.

(Joel Beasley at 00:19:51) So you're not, like, trimming out unused code. You're just looking at the used code and using that to prioritize what you respond to.

(Ahmad Gupta at 00:19:59) Yes. Exactly. Exactly. We're not trimming out code. We are not changing code. We are not doing anything to your application or code without you knowing. We're just reading all of your code, and we're doing deep program analysis to figure out what parts of your code reach out to what components of third party dependencies that you've imported in your application. And once we have that boundary in the relationship between a function from your code calling a function from open source dependency, we then mark all the vulnerabilities or all the security issues in those areas as reachable. We still discover all of the vulnerabilities and all of the security issues in the entire code base that you have. But we let you prioritize by focusing on the ones that actually matter to you and that can actually affect your application code.

(Henrik Plate at 00:20:52) Maybe to say it in other words, imagine that today's applications comprise thousands and thousands of functions. Right? Both from the first party code application, but many more even are coming from open source components. But of those thousands and thousands of functions, just a small subset is used. And so if a vulnerability is found in a function that is not used, guess what? This doesn't matter much. Right? And so this is kind of the core of the idea how to prioritize. That is this, let's say, the core ideas that led to the creation of Endor Labs in the first place.

(Joel Beasley at 00:21:34) Yeah. That makes complete sense because, you know, the last languages I was programming in was React and then Ruby as well. And I would import entire gem sets for, like, one tiny little subsection of features, and I got all this bloat with me, but I just dealt with it, you know.

(Henrik Plate at 00:21:50) And that is basically in order to go. But all of what we were discussing now has little to do with AI, AI-generated code and so forth. Right? This is more, let's say, classical software and program analysis techniques that we use to this end, that we use to prioritize all those vulnerabilities. But coming a bit back to this AI topic, AI code generation, I think this is where there is one opportunity lies. In fact, for the single function that you have introduced in your React application, rather than using this, why not letting AI generate or regenerate those 10 lines of code and save you all the kind of transitive dependencies that you pull in with React? So there's one opportunity. So kind of better import a few lines of code. Sorry. Better to write yourself a few lines of code rather than importing tens and hundreds of dependencies. But of course, this is a double-edged sword. There are also disadvantages in certain cases where this is not a recommended thing to do.

(Joel Beasley at 00:23:00) Yeah. I knew I knew you were gonna go there, Henrik. I was like, the security guy, he's luring me into this trap. I was like, the AI is definitely a threat that you have to. How do you watch the AI-generated code and make sure that that's secure? Is that something you do, or is that beyond?

(Henrik Plate at 00:23:18) No. No. No. That is what we do. So one important piece to this puzzle is definitely the MCP server that we have developed at Endor Labs, which is basically leveraging all this information we have about known vulnerabilities and open source components. And what we do with this MCP server, we basically integrate it into the code generation process itself. If you want to look at it, you can say we shifted to the furthermost left part of the software development cycle, which is when the code is actually conceived and generated. And it's there where we basically check whether the package and the version that is proposed by the agent is in fact existing in the first place and whether it has known vulnerabilities. And if it hasn't known vulnerabilities, we basically suggest a better version to use. And that is really also magical to see in the IDE and your development environment. Right? Because you can really see how Cursor, for example, or Windsurf invokes our MCP server to check, is the version used vulnerable? And if it is, you basically see how the code changes live in the manifest file where you declare this dependency. So that is one way, one important step to kind of secure AI-generated code: move as many security tools as possible into this earlier stages when AI is creating code.

(Joel Beasley at 00:24:54) So where do we like, a company. I have a Cursor. I have Cursor open right now on my. Where would I integrate you? How does it look if I actually interface with your company?

(Ahmad Gupta at 00:25:05) So Endor Labs will provide tools for you to integrate with us at every step of your software development lifecycle starting from your IDE. So in Cursor, you can go and add MCP servers or tools that extend Cursor's capability. By default, if you ask Cursor to, you know, you found an open source library somewhere on the internet. But assume you program in Go and this library is written in Ruby. And all you want Cursor to do is translate this Ruby code into Go. As part of that translation, Cursor will look for open source code that it can pull in that has equivalent functionality to the code that Ruby is using and do a translation. In this world, if you haven't specified to Cursor that make sure that you're using secure open source dependencies, you don't need to always use the latest version, use a version that works. There's so many guardrails to put in. What Endor Labs does is as Cursor is thinking through and planning what to do to achieve a particular task, Endor's MCP server sits there as a watcher, as a security watcher. So when Cursor brings in an open source dependency that we know from before has a critical vulnerability, we will, in the background, prompt Cursor to look for an alternate that's more secure.

(Ahmad Gupta at 00:26:28) So all of this is possible because what Henrik's team has done over the past years is for every vulnerability that we get in any open source dependency, Henrik and their team goes and looks at the exact function that this vulnerability impacts in the open source dependency, decorates that dependency with that metadata, and stores that in the database. That's very different from what you find in the open source world out there. You'll see, you know, Jackson DataBind version X.Y.Z. is vulnerable to the CVE. But beyond that, you don't know what line of code in Jackson DataBind is vulnerable. What Henrik's team has done over the last four years progressively is created a database which is extremely valuable of every vulnerability and the function that it impacts in every open source dependency.

(Ahmad Gupta at 00:27:16) So now fast forward to Cursor. When we see Cursor importing a dependency that we know about and we think is gonna call that line of code that actually brings in a vulnerability, this MCP tool can nudge Cursor to look for an alternative. And that's extremely, extremely powerful because it causes less code churn, but at the same time, makes your application more secure.

(Joel Beasley at 00:27:41) How do I deploy this? Like, let's say I have a thousand engineers and I wanna deploy this across all of them. Is it, do I write a memo and tell them to go install? Like, how does that actually work?

(Henrik Plate at 00:27:52) Oh, that is a very good point. Amad, before you chime in, I think this is one of the biggest challenges that enterprises have these days. Because my observation, my feeling is that all of these advantages are primarily appreciated and observed on an individual developer level. Right? So each and every developer goes out and tries to make sense of this fast-paced AI topics, new models popping up, new agents and tools. And bringing this from this individual developer system to an integral enterprise-ready environment is something that is very hard. And I honestly, I don't think we have yet the tooling and the infrastructure and the management control plane to do this really. So I, this is one of the spaces I think we will see a lot of new technologies and many new basically vendors and companies also popping up in the next couple of months in order to, you know, enable enterprises use this beyond just individuals.

(Joel Beasley at 00:29:02) Yeah. Because a lot of people, I had talked with teams of all different sizes, and it seems like there is some benefits because everything's moving so fast. So the fact that everything's so decentralized with the developers having to set it all up, that might be a little safety, built-in safety function. But when we do get it to the point, there's also like the culture issue. Like, I'll talk with a lot of CTOs. They're trying to even just get their people to use, like, the Copilots or the, like, just to even get them to use it. But if you could just provision it somehow across everyone's device and they, that might be cool too. It might open up all sorts of issues, but I don't know. I don't work at a big company. So.

(Ahmad Gupta at 00:29:47) Yeah. No. I think this is an open problem. I was meeting with a customer of ours that's a large issue in size. Some of their developer workstations have up to 80 MCP servers installed. Eight zero. Wow. There is no distribution mechanism. This is an unsolved problem. There is no distribution mechanism right now that can help them with this. Some of these MCP servers are just downloaded from the internet. There's no provenance. Don't know who created it. Don't know who managed it. Some of them are well known. Endor's MCP server, GitHub's MCP server, Atlassian's MCP server. Some of them are imported as VS Code plugins. We are starting to see a trend where developers are wrapping their MCP servers in VS Code plugins. Some of them could be centrally hosted, meaning you don't need to install it locally, but you could just reference it and call it. So companies are trying to solve this problem in different ways, but there's no standard yet.

(Joel Beasley at 00:30:43) Oh, what do you think the most, Henrik, startup head on? What do you think the most likely end result is for how this will be solved?

(Henrik Plate at 00:30:53) That is a big call. I wanted to be. Before going into this or maybe, Amad, you have a few seconds to think about a proper answer. I wanted to share some additional details just to reinforce Amad's message here. So when one of the kind of the outcomes of the research report described in this document is that for some kind of technologies or tools or services, you have a plethora of alternatives. So how do you actually, so for, if you browse those MCP marketplaces and, you know, registries where you can find them, if you search for something like Shopify or so, you will find 10 or dozens or even more different MCP servers. How do you know which is the good one? And of course, whenever you have a new and thriving, fast-moving environment, that is also something inviting attackers to just, you know, why not develop and kind of deploy a malicious MCP server? There will be for sure a few people downloading those and installing those. Doesn't cost much, right? An MCP server can be wiped, coded in just a few days or a few hours, probably. Yeah. That is, this is kind of to reinforce this.

(Joel Beasley at 00:32:09) And you can clone the legitimate one and just add your nonsense on top.

(Henrik Plate at 00:32:12) Yeah. Exactly.

(Joel Beasley at 00:32:16) Oh, so validation of MCP servers is probably gonna become a thing.

(Henrik Plate at 00:32:20) Yeah. This whole vetting. Right? But this is, like, for every other supply chain component, you will need to do some vetting. Right? And so just like any other dependency you introduce, you know, just look at it closer, look at different health metrics, such as the ones that we also offer and show in our kind of in our platform. Right? So how well is a component maintained? Is this an individual contributor or maybe an organizational contributor? Are there any changes in ownership? What is the response times to issues and so forth? All these kind of quality activity metrics that you can think of. And so that will be important. And maybe another observation. What I see is going on with these MCP servers and what is in fact going on with just every, almost, I have the feeling every new technology. There will be quicker than you can think a new marketplace and a new registry allowing people to download stuff, but writing registries in a secure way is not an easy thing. And I have the feeling, so for example, to make, immutable packages. Right? So once you have deployed something on a registry, it should not change or to have proper signatures or to have proper publisher authentication and all these security measures around the registry. And I see over the course of the last few years, the same mistakes being done by one registry popping up like mushrooms after the other. Right. So that is a little bit of a sobering learning, I would say, that, you know, those registries keep on making similar mistakes. So there is this Visual, the one be it the one for Visual Studio Code extensions, the soon to be created registry for MCP servers, I guess, and others.

(Joel Beasley at 00:34:28) So let's say I have a company, software development company. There's one employee. We decide what our stack is. We're like, hey, we're gonna use Cursor. We're gonna use Endor Labs for security. We're gonna use this. And then I end up, what, making a document that describes how we do things here on the engineering team. Then we hire developer number two. He gets that document and goes configures the lab. Is that how it's currently happening?

(Ahmad Gupta at 00:34:56) Yeah. It's becoming the standard. Security guidelines are starting to incorporate AI tools as a first class citizen. You know, typically, these documents have had coding guidelines. How do you write your PRs? What type of linters do you use? What tools do you have access to? What kind of package management wrappers should you use? What policies, et cetera? And slowly but surely, guidance around using AI tools, MCP servers are finding their way in there.

(Amod Gupta at 00:35:29) So I think that's certainly what's going to happen. But more than the distribution, I think what's going to be more important to Henrik's point is the governance around these tools. You can have secure coding guidelines, but that's one part of the puzzle. Just like you have a lot of these package management wrappers and firewalls and proxies that look at any open source dependency that you're downloading, registries have some of these capabilities built into them.

(Amod Gupta at 00:36:01) I think similarly, MCP servers will evolve into registries and marketplaces, the distribution mechanism. And then there'll be governance around pulling from those registries, scoring of MCP servers on those registries, and policies around that.

(Joel Beasley at 00:36:15) So you think as a company, we might choose this registry and, like, basically like an app store, anything inside this is safe?

(Amod Gupta at 00:36:22) Correct. So, you know, some company like VS Code might come out with an opinionated marketplace. They have a marketplace of VS Code extensions. They might come out with a marketplace of MCP tool extensions. They might be an open source registry like NPM for node packages, which is public hosted for all the MCP servers. Less governance there, and the governance for that is left to the person that's downloading a package from that registry. So both of these models are possible.

(Henrik Plate at 00:36:59) I think on a higher level, it's important to distinguish all this kind of operational aspects. Right? How do you get those MCP servers to the organizations? Is it okay? Where do they run? On the developer systems or in some central systems by an organization? How do you make sure that all those are auditable and traceable? So these are kind of operational topics. And then the other big question is how do developers in fact use those tools? How do they prompt the tools? How do you make sure that all those other security best practices, organizational security requirements, maybe regulatory requirements, and also all the kind of the software architecture that you are working on right now—that all of that is properly ending up in the context of the model writing your code?

(Henrik Plate at 00:37:57) And so that, I think, there will be a lot of development around prompting techniques, how to provide the right level, the right content, and at the right level of detail in some automated way. So that the developer does not need to remember to write a long novel every time he wants to generate a function. Right. So there has to be a mechanism to automatically include all those guardrails in the conversations.

(Joel Beasley at 00:38:32) It's interesting. And then how do you create a strong prompt culture? You yell at people? You just be like, this is what we do?

(Henrik Plate at 00:38:40) I think here, the trick will be to—what is encoded now in very long, maybe, Word documents, however that is managed in the different organizations—to transform the guidance that you printed and put on the desk of the developers to now transform this into prompts that you can then include automatically. And I think this should not be seen as a burden, but more as a chance, because if you manage to include this automatically, you don't have any guarantees, but let's say higher chances or some chances that the model picks this up. Whereas in a similar way that you also hoped a developer would pick up all the paperwork that you gave him and threw on his desk. Right? And so this will be part of the solution, I think, encoding this in prompts and also making them part of—in fact, the making them version controlled. So this should be part of the Git repositories to make sure that they are automatically picked up through the tool configuration, through the agent configuration, whatever you use. And that is easily possible. If you look, you said you have Cursor open—there are some configuration files, and this is where you can put loads and loads of prompts to make sure to provide additional context, to provide those guardrails for code generation.

(Amod Gupta at 00:40:19) I think, just to add to what Henrik's saying, I'm noticing two interesting things with prompts. One of them is that people are conditioned to think of prompts as something you tell a chatbot. So when you're interacting with ChatGPT on the web and asking it a question about something, that's different from giving Cursor a prompt that's going to generate code. The latter should be looked at more as a spec, and the former is just one sentence in a conversation. So that's, I think, maybe due to the popularity of ChatGPT, subconsciously a lot of folks are just used to thinking of prompts as a piece of conversation.

(Amod Gupta at 00:40:58) The second thing that I'm noticing is it's not very clear still to people how much of an LLM's behavior they can change with the right prompting. So, given a loose prompt, "Go write an application that does this" versus given a very tight prompt, "Go write an application that does this. Make sure it has an authentication layer. Make sure it's mTLS. Make sure it's this library that's used. I want the output in this JSON format. This needs to be—" You can control a lot of the way an LLM behaves by being more descriptive in your prompt. But I think that's—culture is the right word. That's something that's going to take a while before it percolates down to every developer, everyone who's using LLMs to generate code.

(Joel Beasley at 00:41:46) Once we rip all the humans out and just replace them all with AIs, then we'll just tell the master AI what to do. Now I want to talk about the secure prompts because you actually have a fantastic resource on endorlabs.com. You have 40-plus AI prompts for secure code coding, and that's something people can download. It looks pretty cool. Did you guys make that or is that a different team?

(Henrik Plate at 00:42:07) It's not that we have a good number of employees, but it's not that we have one team not knowing at all what the other team is doing. We will eventually get into such a situation, but it's not yet. So yeah, we are very well aware of those problems and I kind of—maybe to add on to Amod's point. I also tend to say that the more specific you are, the better the results. And so, meaning in terms of the technologies you want to use, in terms of the security controls to implement, the more the better. However, the problem with this is that being very specific of course requires some seniority. Right? And so if that is not possible, you will go back to the second-best advice of more phrasing, more high-level requirements, which is still good, but gives more freedom to the model, to the agent actually implementing and meeting those requirements. And the second, I think, in terms of prompting, is to not let it go wide right away, but to follow a phased approach of planning something or asking it to plan. Review the proposal before implementing loads and loads of code. That would be my kind of high-level takeaways. But it's definitely worthwhile checking out this resource to have more detailed insights into single prompting techniques.

(Joel Beasley at 00:43:45) Let's give some people some very practical, tactical advice. Like, what should enterprises be doing right now when they're thinking about AI-generated code, untrusted input, and security?

(Henrik Plate at 00:43:58) So I think in terms of recommendations for AI-generated code, I think my first advice would be to actually check whether it works in your specific environment. So after reading through a good bunch of research papers, academic papers, you will really—once you do this, you will realize there's a wide range as to whether agents create secure or vulnerable code. So this goes from 25% of the code is vulnerable to 75% of the code is vulnerable. So there's a large spectrum. And of course this is constantly changing with new models and agents and technologies popping up all the time. And what is interesting though is the coverage of those academic papers is still limited. Right? They mostly look at certain programming languages. They mostly look at certain frameworks and technologies, only at certain kinds of vulnerabilities. And so just because something works in Python, code generation works in JavaScript, doesn't mean it works in the language that you're using.

(Henrik Plate at 00:45:10) So I think enterprises need to have an understanding whether it works in their specific context, language, technology, and also have a means to measure this over time. Because otherwise they cannot just rely on some anecdotal evidence of a single architect or developer liking the tool, but you need to have some ground truth to measure this as you're going to choose and pick models and tools and MCP servers and God knows what. So this is the first thing. Right? Check whether it works in your context. And then the other topics I would say are—we have touched upon a few—integrate security tooling into the whole code generation process. So this comes back to using those tools and MCP servers integrated into the code assistants to basically detect and fix and patch things as early as possible. The third one is this prompt culture, a prompt library. Make sure that you have a good one and that it is enforced by integrating this in version control systems. And maybe the fourth one that is something that we shortly touched upon in the very beginning—I feel there is a lot of shadow AI, shadow IT popping up on everybody's developer laptops. Make sure to identify this and secure it to prevent these malicious packages that I mentioned before exploiting and colluding with your helpful assistants.

(Henrik Plate at 00:46:41) So that would be my kind of four more concrete advices on how to use this. Amod, anything?

(Amod Gupta at 00:46:49) No. I think you touched on all the main ones, Henrik. I think the only thing I would say is just treat AI-generated code as untrusted input, which means if you get a piece of code from some third party that you're trying to incorporate in your stack, do all the things that you would do with that piece of code, meaning mandatory code reviews, meaning tests and security checks before merge using some sort of scanner to scan the code, using policies to make sure any third-party dependencies that that code is pulling are versioned. You have an allow list. In fact, at this point, as AI keeps getting better, but till it gets there, have an extra pair of eyes that goes and looks at the code that's generated by AI. Have provenance. Make sure everything is signed so you can trace. One of the issues that we ran into recently with a customer was they had an incident that was caught by some tool, but nobody could figure out who wrote this code, only for them to realize that this was part of a large PR that was AI generated. And so provenance becomes a question. Who wrote this code? Who understands this code? When some issue happens, which developer should I—I shouldn't say next, should I choke—but, you know, who's responsible for that?

(Joel Beasley at 00:48:10) We're choking necks. Yeah. We're doing it.

(Amod Gupta at 00:48:13) Who's the best person to look at this? Right? So provenance becomes important, which means any artifact that you produce—a binary, a container—should be signed, should be attested, so you can trace where it came from, which repository it ties to. So I think aside from what Henrik's saying, I think the guiding principle is treat it as untrusted input in your application stack and follow the same best practices that you've been doing.

(Joel Beasley at 00:48:40) Yeah. And it's not only that you just want to choke the neck. It's that you want to figure out what led to that actually being able to happen. Right? Because if you can see that AI-generated code brought in this maliciousness or this difficult situation, being able to talk to the engineer and understand why they—how they used this? How did this come to be? What prompt was used? How could that prompt be different? You can have all those conversations and learn more about the origin of the problem versus just not knowing how it happened at all.

(Amod Gupta at 00:49:10) Exactly.

(Joel Beasley at 00:49:11) Well, hey. We made a podcast. How do you feel?

(Henrik Plate at 00:49:14) Oh, it was a great discussion. I enjoyed it very, very much. Thank you.

(Joel Beasley at 00:49:18) You guys are super knowledgeable. You're very, very smart. You know, I met Varun, and he talked highly of his team and everything. But after meeting you guys, I'm like, you guys are world class over there.

(Intro/Outro Narrator at 00:49:29) Before you go, make sure to check out Endor's full State of Dependency Management report for a full breakdown of what we discussed today. Click the link in the show notes or find it at endorlabs.com.

(Joel Beasley at 00:49:41) Thank you so much for listening. And if you found this episode useful, please share it with a friend or a 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.