Allie Howe: Hey everyone. Welcome to today's episode of the Insecure Agents podcast. I'm your host, Allie Howe, and today we have Feross Aboukhadijeh, CEO of Socket, a developer first security platform that protects your code from both vulnerable and malicious dependencies. Would you like to introduce yourself and tell us more about Socket?

Feross Aboukhadijeh: Yeah, sure. Hey, it's good to be here Allie. And I'm Feross, founder of Socket. Socket is a company that I started in 2020 after spending about a decade before that as an open source maintainer. So I published open source software that today collectively gets over a billion downloads a month. So I learned a lot about the software supply chain during that time period. And, you know, especially seeing how companies were using my software as well as that of, you know, the broader open source ecosystem. And I saw a lot of challenges with like how you consume open source, how do you know the packages are safe?

Obviously, vulnerabilities is on everybody's mind. Everybody wants to get to 0 vulnerabilities. But the other part that I thought was not really addressed by the market at the time was software supply chain attacks, which we're now seeing a whole bunch more of than we've kind of ever seen before. And so I felt like the existing solutions didn't really even attempt to solve that problem. And so felt like, you know, that was the reason that was a real impetus to start the company.

Allie Howe: One thing I think differentiates Socket or one thing that I like about it is the fact that you all like rate on different criteria like supply and chain, security, vulnerability, quality, maintenance, license, local, to be able to go and see before you go and like download a package or it's nice to see what your options are, what you're kind of signing yourself up to in terms of like security risk. So yeah, definitely like very, very cool. How long ago did you start Socket?

Feross Aboukhadijeh: So we started it in 2020. So it's been about four or five years now since we've had a product in the market that you can use and it would continue to, you know, it's, it's really not just focused only on software supply chain attacks anymore. We now do reachability analysis and help people prioritize vulnerabilities. We do auto fixes and we even now just announced something called certified patches, which is a way to kind of actually fix the problems without having to do any work to update your dependencies. So there's a lot of stuff now that kind of makes it more of a comprehensive dependency management and supply chain management platform.

That's kind of the the kind of where we're at now.

Allie Howe: Yeah, I saw the announcement about certified patches and that was super interesting to me because I think a lot of people just kind of assume that the latest patch is safe and they go to update dependencies. But a lot of times that actually introduces like even more security risk, which is something I think a lot of people don't realize. How did you decide that like that was like a need in the market and that you were going to go after like a certified patches? And do most people today like use those instead of like going after like the latest upgrade for example?

Feross Aboukhadijeh: I mean, everybody who's tried to fix vulnerabilities in their dependencies knows the challenge, right? So you have a CVE that's announced and you go and look at it and it says we're using version one point O at our company, let's say. And the vulnerability exists in that version and a whole bunch of other versions. And the solution is to upgrade to let's say version 4 point O, right? And so that's where the challenge comes in because now you're, you're moving across like multiple major versions and there's almost always breaking changes or, you know, refactors that need to happen in your application code in order to actually successfully upgrade to that new version.

And so it creates this pain where you're just trying to fix the vulnerability. You might be doing this under like some time pressure because, you know, you want to like remediate it under some reasonable number of, you know, hours or days. But now you're stuck having to go refactor your application and like, you know, that new version 4 point O is bringing you a bunch of new features that you don't necessarily care about. You just want to fix the vulnerability. That's extra challenging when you have a security person who may not even be a developer or may not even be an expert in the application that they're patching.

And so, you know, we've had cases where people are, you know, there's these legacy applications that have no tests, no one even knows how the application works anymore. And then it's some poor security person's job to go and like patch the dependencies and then in some cases to rewrite the code in the application and they're just like basically screwed. You know, it's like not a fun situation to could be in. And so the solution we came up with is what we call socket certified patches. And a certified patch is basically a targeted fix that goes directly into the version of the package that you're using and just patches maybe one line of code that addresses the vulnerability requiring you to upgrade to the new version so you can remain on that old version.

One point O in our example and you just effectively take in a couple line diff that fixes that version. And so you remain on the old version, but you no longer have the vulnerability. And so that solves the immediate problem of addressing the CVE and remediating it. But it gives you time to go and update to that like latest version later on if you want to. So you can kind of decouple fixing the vuln from taking in all these new features that are going to require you to rewrite your application code. So you just decouple those two things and you can do them separately instead of having to do them together, which is what makes it so painful to to fix vulns today.

Allie Howe: And if you installed a certified patch from socket, would like an external vulnerability scanner like a dependent bot or something pick that up? Or would you like have to use socket to be able to like recognize that that was fixed?

Feross Aboukhadijeh: Yeah, that's a really good question. So the way it works today, we keep you on the old version that you're on, and then we go into the actual source code of the dependency and patch it. And so that means that Socket will be able to recognize that this has been patched, but today the other scanners still pick it up as the original version. We have a couple ways to mitigate that. One is there's this new standard called OpenVEX, and you can include information in your SBOM that explains why the vulnerability in this package has actually been remediated through some technical means, in this case a certified patch.

And the other kind of way we're going to address this is we're working on a different deployment model that's going to address this in a more fundamental way. So instead of keeping you on that old version, you'll basically point to a new socket hosted version, which then will make all the scanners see it as a completely different package and sort of solve that problem. So there's going to be a couple ways to address that because it's absolutely an important problem to solve. Especially we hear from our customers that like even if they've addressed something, if one of their customers puts, you know, the SBOM or you know, the app into a scanner and comes back with a bunch of findings, it doesn't matter if they're actually remediated and, and properly addressed.

Because the customer is going to still hassle them about it and it's going to waste their time and they're going to have to like have conversations that they don't want to have. So it's an important problem that we want to address for sure.

Allie Howe: Supply chain security has always been a big issue like you talked about, but I feel like today it's even, you know, more relevant. There's been so many different attacks like in the news, especially like around like NPM in the JavaScript ecosystem. One of those is Shai-Hulud, which is like named after like the Dune movie, I guess like the the worms in the movie. I've I've seen like maybe like 5 minutes of that movie, but pretty like absolutely name.

Feross Aboukhadijeh: So I've heard.

Allie Howe: But basically it's like this huge attack were created, one of like the largest NPM package compromises in history. It's basically just like a self replicating NPM worm that once installed will be able to like search for secrets such as like API keys, tokens, like using TruffleHog. And then we'll like publish anything it finds to a public GitHub repository. And then it will push new copies of itself to NPM to infect, like even more hosts. So it's definitely like, you know, a big problem and it's struck like, not once, but like twice Now. How does socket help protect teams from attacks like Shai-Hulud?

Feross Aboukhadijeh: Yeah. So fundamentally what you're doing when you install an open source package is you're pulling untrusted code written by somebody that you don't know, who doesn't work at your company, who put it online and you're downloading it and running it, and usually without even auditing the code. So if you just think about what we're doing when we use open source packages every day, it's kind of crazy. And we're not just doing it like once or twice, we're doing it, you know, literally 10s of thousands of times because of the amount of dependencies in modern applications. And so the fact that this doesn't happen more often is actually kind of a testament to how how amazing open source is and how well it works most of the time.

Basically what socket does to address the problems of like Shai-Hulud and just in general, how do you know you can trust the software is you need to have something that reviews the code before you bring it in and run it. And the gold standard for that is ideally you'd have a like security expert, like a human, you know, reviewing every line of code and like looking at exactly what the code is going to do before you bring it into your project. And I said that's kind of like the gold standard, not practical. Almost nobody can do this. I think there's, there's only been maybe two companies in my entire career in this space that I've seen actually have a process like that where they have human review of every line of code of all of their third party code.

And they basically treated as their first party code. And it's kind of makes sense, right? If this code is going to run in your application, it's part of your application. It kind of makes sense to treat it that way. It's just not practical for almost anyone except for like the very largest companies in the world or maybe, you know, companies with very, very particular intense security requirements. Like we see that sometimes with cryptocurrency companies. So what you need to do is you need to have some process to scan this code. And before socket, what we saw the norm in the industry was to use a CVE scanner or vuln scanner.

And we just tell you, you know, hey, these are your vulnerable packages, but that doesn't address supply chain attacks at all. It's like kind of a completely different problem. So it's really important to understand the difference between vulnerabilities and supply chain attacks. Vulnerabilities are accidents right there, bugs that that good guys, the maintainers accidentally put into their their projects. Whereas supply chain attack or a malicious package. It's what it sounds like it's an intentional malicious code added into a project that used to be good, but now continue. It's effectively A poisoned artifact that you don't want to use. And So what you really need is you need to know before you bring that package in, whether it's malicious or not.

The CVE system and the vuln scanners, the legacy stuff that people were doing before is too reactive. So you're basically waiting for some human to kind of stumble upon a malicious package, make a big stink about it, write some blog posts, get some news stories. And then these vuln scanner vendors would just go in and kind of add in these package names like to their list of bad packages, even though there's no CVE for them Because again, this is not a vulnerability. So you can't, it's sort of separate from the CVE system. If you look at CVEs, you're not even going to see supply chain attacks 99% of the time, right?

So basically that's kind of what socket does. So we go in, we, we download every open source package before any of our customers. We have a feed, we're kind of pulling in every latest package that's published within a couple seconds of it being published. You can kind of think of it like this really big web crawler that just goes around and finds all open source software and then we scan it with our own kind of proprietary scanner that we created and it looks for signs of capability creep. So a package that used to behave one way, but suddenly you see it making network calls, reading environment variables like opening up files that it never did before, obfuscated code.

Anything that like, you know, is a significant change in the way the package has behaved in the past is a really big red flag. New maintainers is a really big one. New people that are contributing that we've never seen before who don't have a reputation. And then the other really big one is install scripts. So these are pieces of code that automatically run whenever a package is installed. They do have some legitimate uses, but almost all malware uses install scripts because it allows the code to trigger immediately instead of later on. So as soon as a developer, an unlucky person, installed one of these packages, it would immediately run the payload and then kind of scan your whole system looking for more secrets that it could use to spread itself further.

And so when you see enough of these signals, or sometimes in some cases even 1 one of these signals that's really bad, it means it's really worth taking a close look at this code. And So what socket does is we kick it over to a human threat research team that we have, and they will take a look at the finding and make a definitive determination as to whether it's malicious or not. And that is really nice because it means you get really low false positives because our AI system, while it's awesome, still has, you know, 5% false positives or something like that. And we want to provide kind of like a really, really solid experience.

And so everything goes through this like human in the loop process where human signs off on all findings. And so it makes it really, really trustworthy for our users and, and all that data, by the way, is free. So we put all this on our website and people can kind of go and look and see if their packages are safe and, you know, check this before they bring in code.

Allie Howe: So the Shai-Hulud attack was one of the largest like NPM compromises in history. What specifically about that attack stood out to you?

Feross Aboukhadijeh: Yeah. So the Shai-Hulud attack was one of the largest scale software supply chain attacks we've seen. It was the second version of this attack. So we'd seen something similar just a couple months ago, 834 NPM packages were affected, 700 versions compromised. And then there was even a bunch of high profile targets. So companies like Zapier, AsyncAPI, Postman, PostHog and a bunch of others that had packages that were affected. It was a worms. That was the other interesting element of it. When it ran, it would pull your tokens and then publish itself to your packages. And so it had this like viral nature to it that was like really scary and it was now seen a couple of times.

So I think the most interesting part of the attack from my perspective was the way they initially got access to the PostHog package. The attacker opened a malicious pull request against a PostHog public repository and it abused in my opinion design flaw and GitHub Actions. So basically GitHub Actions has this way to trigger code that runs automatically when a pull request is opened. And there's a couple ways to do that in GitHub Actions. And the one that was recommended for a really long time that a lot of people used is called pull request target. And what that means is when someone opens a pull request against your repository, you want to run this GitHub Action in response.

And the problem with that is that it runs the code with a token in the environment that gives it right access to the repository. So that's really bad because it means that someone opening a PR can potentially like use that token and then, you know, make commits to the repo or do things like that. The other really unintuitive part about the way that that works is if you have a GitHub Action that you've worked on that you've kind of improved over time, and so maybe you had some flaw with the way that it worked, the vulnerability, and you fixed it. It turns out an attacker can often still trigger the old version of your GitHub Action.

If you have any branches at all in your repository that are pointing to an old commit that has the old version of the GitHub Action, then an attacker when they open their PR can point that PR at the, you know, old branch. And so it'll run the action from that old branch, which could be an action from 2345 years ago that that had flaws in the design that allowed it to, you know, like allowed an attacker to sort of steal the token. So it's sort of like, even if you fix the flaws, if you don't go and clean all your branches and make sure there's no and, and, and obviously, like a lot of people don't clean up their branches on GitHub.

Like there's thousands of old branches on a lot of repos, especially high profile repos that get a lot of PRS and stuff. So I think that was probably the most interesting part. So GitHub just has this, in my opinion, this design flawed. Actually, I saw a post a couple days ago that they've actually now finally fixed this flaw. And so pull request target now the behaviors changed to sort of address this exact issue. I think that's actually really good to see that that's being fixed because it's just such a common problem and this is the, you know, not the first time we've seen this lead to a initial access compromise in this way.

Allie Howe: Amazing. Yeah, that's such a good point. Yeah, I didn't realize that about like the old branches that are leftover that aren't cleaned up that might have an old action sitting around they're connected to. So wow. Yeah. I was going to ask how like socket has evolved over the last like four or five years when you since you started, since like agents have come out and if you're using agents to help with that process.

Feross Aboukhadijeh: The analysis doesn't necessarily use agents. Today we use agents actually for the patches. So to generate the patches, that's actually a very iterative process of bringing code back from the patched version and bringing it back to the version that the the customers using in their project. So that's where we've actually found the most value from agents today. But yeah, it's your question of like how things have evolved with agents. I think the biggest thing we see is agents, when they're running in, you know, kind of like Yolo mode, they're installing packages and you know, there's a lot of ways that can go wrong. There's obviously the supply chain attacks where you have compromised packages, the LLMs that power the agents were trained often times, you know, six months ago or 12 months ago.

And so they have no idea about the, you know, latest state of these packages. And So what you really need to do is kind of inject information about the latest security status of the packages that the agents want to bring in into the process so that they can get that like information and they can decide whether to continue using the package or not. And so that's what we've seen is kind of been the most useful way to kind of continue using agents, but ensure that they're not going to bring in a backdoor package or or something that violates your security policy at your company or your organization.

Allie Howe: Yeah, cuz I think coding agents have become so prolific. I just went to the AI Engineer Code Summit that was in New York City where like coding agents were the main topic and we did the MCP debate. And one of the learnings that came out of that was, you know, code execution with MCP is a lot more efficient and better way to make tool calls than using like MCP. The calls themselves. I think it like increase performance by like, I don't know, like 98% or something like that. Anthropic did a blog on it. Obviously, there's all these developers that are using coding agents to just improve their own productivity.

But I think developers that are writing agents, building them and connecting them to different tools, they're going to be using agents to write code, to call those tools. So I think we're going to see like even more usage of agents to write code because they're just so good at that. So solving this issue of like, hey, like can I just like go trust this agent to download whatever it needs to go and complete this task and do meaningful work? That means it's downloading whatever dependencies it needs. So agents for sure need something like socket and there's going to be way more agents out there than there are humans today.

I've heard people say it's like 10 to the power of n or whatever of like maybe like every human out there is going to have like 10, a hundred, a thousand different agents. All of them need something to help them make sure that they can solve the right dependencies. So it'll be really interesting to see like not just socket, but I just feel like security companies in general, like how much greater the need is for that. Where do you see, I guess, the future going with agents and what they're going to need to be able to make sure that they can run and execute code securely?

Feross Aboukhadijeh: Oh, isn't it crazy that we live in a world where there's that many agents per person? It's kind of like when, you know, they came up with IPv4 and they thought there's no way that, you know, we're going to need more IP addresses than humans, right? Obviously we're like, clearly run out of IP addresses now. And so we have to come up with IPv6, which is still not like fully really adopted. And so, yeah, the idea that, you know, every person's going to have thousands of agents is exciting, but also kind of like, I don't know, pretty mind blowing thought when you think about it.

Allie Howe: I guess just like what are your like future predictions for AI agents and like how do we secure coding agents really?

Feross Aboukhadijeh: You think about it, right? The fact that agents write in secure code, to me feels like it's a bug in the LLM, like it's trained on poor quality code, code with vulnerabilities, and so it just writes code with vulnerabilities. But like this is a bug in the LLMs and this is something that the model providers are going to fix. So I think that like in the short term, there's value in, you know, tools that assess the code that is coming out of the LLMs or like hook in with tools or even just things like SAST that scan the code afterwards or AI code review tools that check the code, even code written by other AIs, right?

So there's value and all this kind of stuff. But I mean, ultimately, if you look at the way things have been improving, like you just extrapolate it out, you can see how like eventually that that stuff will become less important, I think because the code that comes out the first time will, will just be better, right? And will be be more secure. And it's not that to say that there won't still be bugs and you still won't need some type of review process, but I think that's going to get better and better. You know, similar to like with self driving cars where, you know, Waymo just released a report about, you know, they've, I think they've driven like 100 was 100 million miles.

I think, don't quote me on that, but they've just they've done a bunch of miles on the road. And you know, I think it's like 90% fewer fatalities, 90% fewer accidents involve any kind of injury. So like LLMs are going to get to a point where they're writing way fewer vulnerabilities than humans. And so you'll still need some process, but it's going to get so much better. And so I think question then becomes for all the security vendors that are building things, you know today to help make you know, agents and LLMs and AI generated code more secure, It's like where do they fit in?

In that new world, right, I think with socket, you know, I see the value of our deep analysis of a third party code is that we can throw a ton of compute and a ton of AI resources and token spend on even a single dependency. Like in some cases we can spend 100 or $1000 analyzing just a single dependency. And that's because when we do that work, we can reuse that across all of our customers and a lot of a lot of packages are used by every organization, by many, many organizations. And so we can amortize that cost. Whereas if you think about, you know, first party code scanning, that's kind of not reusable, that's just, you know, you're analyzing your source code, you're analyzing that commit, that PR.

So I think like there's some kind of like limit to how much you want to spend on that, because tomorrow there's going to be another commit and there's going to be more work to do, whereas we can do this work once and kind of resell it. And so we can throw a ton of resources at it and there's value in kind of centralizing that. So that's not something that every company is spending on, you know, analyzing the same version of React or the same version of Next JS or whatever dependencies they're using. It is really interesting. No one really knows like where things are going to go.

It's just all evolving super fast. So I think the best advice is to just be humble and to be nimble and just be adaptable to kind of whatever happens and where everything's go.

Allie Howe: For sure. I think we're all like figuring this out together. And I think there's like a bunch of like new primitives like agent sandboxes. Do you think those will notably help improve the secure coding of agents? Like if you've got like, I don't know if you're in a sandbox and you're going to download certain dependencies to run a task if those packages contained malicious code in them, is the blast radius I guess smaller because it's in a sandbox?

Feross Aboukhadijeh: Oh yeah, for sure. I mean, the idea that you just run NPM install on your main computer and just like let it install whatever it wants to, you know, just as a human doing it right where you're explicitly choosing the packages is not a great idea in 2025. Then to think that you're going to let an agent do that where you're not supervising it, you know, that is not a very good idea. So I do think sandboxes have value there. The other thing you can do with the sandbox that's really nice as you can set up some security policies once and then you can ensure that, you know, whatever you do in the future, the agents are going to be following that.

So one thing we've seen some of our customers do is we have something called socket firewall, which is exactly what it sounds like. It's a network based kind of a proxy server that observes all the traffic going out to all open source package registries. So NPM, PyPI, Maven Central, RubyGems, cargo, like every different place where people publish open source code. And what it can do is if it sees you requesting known bad packages, known malicious packages or something in the Shai-Hulud attack, for example, you can make sure that it returns a 404 or some type of a forbidden code so that the package manager isn't able to install or even fetch that package.

And you can do this not just for malware, but for really anything that violates your rules of like how you want your development to happen. So you can say I don't want to use certain licenses which would be be illegal to use at the company or require you to open source all your code or things like that, that you definitely don't want to. You don't want an agent making those kinds of decisions for your company causing you to need to like open source your entire proprietary, you know, SaaS application because it holds in a dependency that it wasn't supposed to. So being able to have like one place where you define like what you want, you know, what components you want the agency even be able to get makes a lot of sense to me.

So sandbox can be a nice place to set up something like socket, firewall or whatever you use to sort of enforce that. And then just know, OK, no matter what the agents do, no matter how off the rails they go, no matter which like model we're using, whether there's bugs in it or not, like we're going to be fine. At least we'll have certain guardrails that can't be violated.

Allie Howe: I think another opportunity for change in terms of like what agents will do for the industry is help us gradually move away from different dashboards, which have been like how, you know, humans go and look to see what vulnerabilities exist, what we need to patch. I think maybe in the future, like an agent will be able to go and see that data and then go patch what it needs. I read in your recent blog the webhook events for alert changes. So something about how you can, you know, stop checking dashboards and start responding faster by using that. I just imagine like to me, that sounds like really perfect for an agent or an agent can be picked off once like a webhook event is triggered for different like alerts.

Maybe like that agent can go and like look and see if there's a certified patch that socket has released and like go do that update for the human without the human needing to go and like look at a manual dashboard. Is that sort of the future that you're seeing as well?

Feross Aboukhadijeh: Yeah, absolutely. I think that's perfect. So, you know, you have a specialized tool like socket that's going in kind of, you know, looking for specific events that are interesting and noteworthy. So in this case, a CVE was published or a new malware was discovered in one of your packages and then you can just kick off, you know, an immediate response to it. Obviously there's some risk in letting the agent like fully go autonomously, like, you know, deploy your application for you with, with our customers and the kind of people you know that are working with us today, there's certain limits to like what they want an agent to do.

So I know there's some products that are, you know, SREs, you know, dealing with alerts and incidents and automatically responding to them. We're still a little ways off from like at least me wanting to kind of let an agent redeploy prod on its own, like while the team is asleep. Like that's a little too far, at least for today. But for things like vulnerabilities where there's something like a certified patch available, it becomes something it's so simple to apply. It's just, you know, a version change or in some ways you're not letting an agent completely like run amok in your environment, doing things and deploying things.

You're really just saying, all right, it's allowed to do, you know, certain limited number of of things that are very, very high likely to to not go wrong with a patch. Our promises that will never break your application. So that's why they're called certified patches. So you should feel comfortable having an agent or even just some deterministic code applying those and not worry that it's going to break your application. So I think the more we can get to things like that where you're not just letting the, you know, for instance, an LLM generate a bunch of code and then deploy it like that. To me still, we're still a little early for that, especially like going out to prod without any human in the loop or for things that are more constrained.

I think we can actually do that today. So we can do things like apply a patch automatically to a vuln and secure prod without a human even being in the loop.

Allie Howe: OK, like 2025 was like dubbed like the year of agents. Really we're just super early. Like we just kind of touched on kind of entering the, you know, next decade of agents, not necessarily just like the next year. What did we learn from 2025 in your opinion about agents and where are we headed in 2026?

Feross Aboukhadijeh: I mean, I think with most new technology, I think security typically is an afterthought. And so, I mean, this was true with the cloud and it's, I think been true with AI and with agents as well. I think the promise of like what the tech can do is so exciting that people just push forward before they've figured out all the security of, you know, implications and effects. And and then we just kind of spend the next decade as an industry, like trying to clean up the the damage and the the poor design decisions and things. And that's just kind of like how it is. I mean, yeah, in an ideal world, you'd sit down and figure out all the security primitives that you need, you know, and the standards that you need to kind of do all this correctly and then ship the new stuff.

But that's just not, that's just not how it works. It's too exciting to kind of get stuff out today. The other thing too is there's an aspect of like humbleness of, you know, just you can't really predict all the things you're going to see from attackers and all the ways that things can go wrong. There is an iterative element of like making a system secure that happens over time, you know, because if you think about something like the web, right, the web is the most iterative system in terms of security. I mean, you know, the early web was incredibly insecure and we didn't even have like HTTPS.

We had all these horrible design decision, you know, cross site data leakages and, and privacy issues and tracking with cookies and all this kind of stuff. You sometimes see people today that like bemoan the state of the security of the web and they'll say, oh, we should burn it all down and build a new system. And, and, but the web is actually incredibly secure today. It's like the most attacked system, right? Yes, it has its kind of messiness. Like it doesn't look like it's a cohesively designed system because a lot of this stuff has been bolted on or like added later. And that's because obviously with the web, you can't break websites.

So like the old, you know, Space Jam website from like 1999 or whatever I like still loads perfectly on, you know, the latest version of Chrome today, which is really amazing. But so it creates this kind of like messy aesthetic because all this stuff has been evolved over years. In the end, it's like an incredibly secure and resilient system. And so I think it's beautiful that like that's how we do things that even though there is this cohort of people that would say we should just like design everything to be perfectly beautiful and nicely designed from the beginning, this is more like a biological system.

It just evolves and you kind of see what threats you face and then it adapts. And, and that's kind of also another reason why security is such an exciting field is that you have attackers that are not static. You know, they are always coming up with new attacks. And so you can't really sit down and think of all the attacks in advance. And in my opinion, I think you actually have to just be willing to evolve things and improve things over time based on what emerges. And This is why security is fun. And This is why we all have jobs for a very long time.

Allie Howe: Definitely agree with an echo. Your sentiment around like security is an ever evolving process. Our work is never finished. We're going to figure it out together as an industry and just keep moving forward. So super excited to continue to follow your work with Socket. Also glad to see like what happens in 2026. Is there anything else you'd like to add or anything that's coming up the with Socket in your future you'd like to share?

Feross Aboukhadijeh: I mean, the biggest thing is just, I think, you know, we haven't seen the end of these software supply chain attacks. I think. I mean, I've been beating my drum on this since the first big attack I saw in 2017 and with NPM, and it's still an issue now today in 2025. And so I think that having something in place to stop these attacks is going to be as important as having a vuln scanner. And it's actually kind of like the next evolution of like SCA and vuln scanning is kind of like this deeper package analysis that we and others are doing. So I think we're going to unfortunately see more software supply chain attacks, but we'll be ready to go to help protect the community and stop them.

Allie Howe: We can't secure and mitigate risks that we're not aware of. So like, that's definitely the first step. And yeah, the MPM attacks, supply chain attacks in general are not going away. So definitely worth keeping in mind. Thank you so much for coming on the podcast today, everyone. That was Feross Aboukhadijeh, CEO of Socket. Where can people connect with you if they want to join in on the conversation?

Feross Aboukhadijeh: Yeah, so you can check us out at socket dot dev and then on social media, we're just at Socket security and then I'm feross. So you can also message me at feross and my e-mail is just feross at Socket dot dev if you want to send me a note. And I love to talk about security, open source software, supply chain. So hit me up anytime if you have any questions about any of the things we discussed. I'm happy to to chat with people anytime.

Allie Howe: Awesome, amazing. Thank you.

Feross Aboukhadijeh: Yeah. Thank you, Allie. It's been really fun. Thanks for having me and with all the great questions.