Decipher Podcast: How Socket Is Modernizing Tools for Securing Open Source Software

Socket founder and CEO Feross Aboukhadijeh recently joined Dennis Fisher on the Decipher podcast, which is produced by an independent editorial team covering the practical applications of information security.

This episode discusses Feross’ journey as an open source maintainer, with more than a decade of widely-used contributions, and how he grew frustrated with the state of security.

Considering how much power a single maintainer has in the ecosystem, if they decided to go rogue or were compromised, the repercussions could potentially be catastrophic. This was the impetus for the founding of Socket. If we’re trusting a system where developers are building software using open source code from random strangers on the internet, the world needs better tools for securing these supply chains.

The episode covers how Socket addresses the unique challenges of our ecosystem by leveraging AI-powered threat detection whenever developers update and/or add a dependency. Socket goes beyond traditional vulnerability scans to flag suspicious packages based on more than 70+ criteria.

With the whole world depending on open source software, in many instances with thousands of dependencies per project, early threat detection and deep package inspection are critical for thwarting preventable open source supply chain attacks.

Check out the episode with Feross on the Decipher website, or read the transcript below.

Transcript:

Decipher Podcast
===

Dennis: [00:00:00] Welcome to the decipher podcast. My guest today is for us, Feross Aboukhadijeh, the founder and CEO of Socket. How are you, Feross?

Feross: Doing good, Dennis. Thanks. It's great to be here.

Dennis: Yeah. Thanks so much for doing it. I appreciate it. I've been looking forward to this one. I know we, we tried to do it earlier in the year and you guys got a little busy after you got a nice funding round.

Feross: Yeah. Yeah. It was really good news back in August. We did our a 20 million series a from Andreessen Horowitz. Super great news. Yeah, things are going well at the company. That

Dennis: must be a nice feeling. I've never like been in that position specifically. I've worked at startups, but not at the level where you are.

It must be just one of those milestones where you're just like, okay, we can, like, we've got some runway here.

Feross: Yeah. But I mean, the, the right way to look at these things is always that the work is really ahead of us. I mean, [00:01:00] funding is really just creating obligations and expectations more than a moment.

I mean, you should celebrate the wins, obviously, but yeah, we're looking ahead to what we have to do next for sure.

Dennis: All right, cool. So I wanted to talk, we have not met before, so we haven't had any like deep conversations about what socket is doing, but I know you guys are doing some really cool stuff with supply chain security and there's an AI component to it, which, um, we were talking off mic before we started recording about how much sort of noise there is around AI in the security world these days.

So if you want to just give sort of the short version of the problem that you guys are trying to solve and how you're, how you're going about it, I think that would be great.

Feross: Yeah, for sure. So Socket is a tool to help developers and security teams, ship faster and spend less time on security, busy work specifically around like managing their open source dependencies.

So we help avoid the [00:02:00] vulnerable and malicious dependencies. The way we do that is, is through, um, some pretty cool tech that I'm excited to, to chat through with you. The background on the company, like why I started it is that I actually was an open source maintainer for most of the last 10 years.

And I kind of got fed up with the state of security, kind of seeing the way that open source packages are created and maintained on the, on the maintainer side of things. I just felt like a single maintainer had way too much power in the system. Just thinking about kind of like my own code that I was responsible for.

It gets currently my open source code gets something like a billion downloads per month on the NPM package manager, and this is. Wild, right? Like it's just an insane number. And, so I saw how much power a single maintainer had. I mean, imagine if my account gets compromised or if I just decide to go rogue one day, which, of course, I'd never do.

But, just this is the system that we're, you know, everyone is [00:03:00] living in. And we're building our software on top of this, like, mountain of open source code written by random individuals on the internet. And so, you know, that's kind of the problem. And I just got, I just got fed up with like, you know, the tools that were out there, you know, claiming to really try to tackle this problem, but weren't really doing it right.

Dennis: Yeah. I mean, the thing you mentioned about people going rogue, that's, we've actually seen that happen a couple of times in the last few years, and it's always the weirdest thing. You're like, aren't there safeguards against this? And then if you dig into it a little bit, as you said, there kind of aren't.

Like you can just, if you've got a package that's super popular, you can make a change that, you know, causes, you know, all kinds of havoc for millions of people. If you just have a bad day.

Feross: Yep. Yeah, exactly. We've seen multiple examples of this. Um, there's a maintainer of a popular package called colors JS and also faker JS, um, extremely popular packages.

Colors was used literally by everybody. Um, and it does something super simple. It just colorizes text in the [00:04:00] terminal. So, um, kind of a really kind of trivial package, but everybody used it. And, um, one day the maintainer just woke up and decided that he wanted to sabotage the package, um, again, he's the maintainer of it.

Right. So think about like, you know, the typical things we hear about security, people like to talk about like signing, you know, okay, signing will solve all of our problems. Well, it turns out this is actually the legitimate author of the package who would have been able to sign it. Um, and then you have, um, you know, people talking about, um, you know, like more integrity throughout the supply chain.

Again, this is the legitimate author of the package publishing this. And so, yeah, what he did is he added a bunch of code in there that, you know, basically was a denial of service on everybody using the package. It added like an infinite loop, printed out a bunch of gibberish messages, conspiracy theories, just kind of like a really weird, modification to this package.

It affected everybody, including, Like Amazon's cloud development kit SDK that people were using. So [00:05:00] when people went to go and use that tool, um, it started printing out all this stuff, people thought Amazon was compromised. Um, it turns out, no, it was just one of their dependencies got updated by the person who works on it and it turns out everybody was using it.

And so, yeah, that's, that's the way our supply chains are today. If you have these individual maintainers and again, most of them are good. I'm not trying to. I'm not trying to be negative on open source. I'm an open source maintainer, but you just have with the scale of the ecosystem, even a single bad actor can really have like a really wide reaching effect on the whole ecosystem.

Dennis: So how does your tool address that problem? What's the basic approach that you guys are taking?

Feross: So, Socket is really easy to install. It's like a two click install. And most people put us into their, um, GitHub instance and we just sit there and we watch anytime a pull request is opened by a developer, and whenever they add a dependency or update a dependency, those are the two times where, you know, updating and adding are the [00:06:00] two times when you're introducing new third party code, uh, into your application and what's, um, What's what's so mind boggling to us at the socket is that most teams have a pretty rigorous, you know, some, some type of code review process where they have to review their teammates code before it's allowed to get merged into the app.

But when it comes to open source dependencies, typically, get hub and these other tools will just show you, like a one line diff that shows you, oh, hey, this dependency was added with no actual indication of what the code is that's coming in with that dependency. So it looks deceptively simple. It looks like it's a one line change.

But in fact, that one line change is actually bringing in thousands, tens of thousands, hundreds of thousands of lines of additional code. Um, and in NPM,the average package has 79 additional transitive dependencies that come in because it's this. kind of sprawling ecosystem where everything depends on everything.

And so just that one line change can be [00:07:00] masking 79 additional dependencies on average. And so, um, so what developers really need in that, in that pull request environment is they, they actually need some kind of tool ideally to come in and, and, and tell them whether the dependencies are safe. And, um, Again, it's not enough to rely on.

It's not enough. It's not fair to expect a developer to go and review all the code in the dependencies. It's obviously not practical, but it's also not okay to just So we can't just throw up our hands and do nothing and say, well, there's nothing we can do here. There's a middle ground, which is we can use automation.

We can use Socket to basically go in, um, look at what the behavior of those dependencies are and highlight risks and flag risks. And so Socket will come in, leave a comment on the pull request and let the developer know, for example, you know, Hey, it looks like this dependency you installed. Has, um, you know, some, some sketchy behavior in it.

Maybe it's, it's taking, um, your environment variables, your API tokens, and it's sending them off to a random server. Um, that's, that's pretty bad. Um, that's something that [00:08:00] we will, we would be able to catch. Another example would be, um, a typo squad attack where the developer has installed the wrong package by accident.

It's like maybe one letter off from the correct package. We would be able to catch that. Um, and hopefully you're seeing here, like. I'm really referring to kind of, you know, this sort of risk profile of packages that goes really beyond like typical vulnerability scanning tools that just tell you whether it has a CV or not, we're really talking about the holistic risk of the package.

Dennis: Yeah, for sure. And like, as you said, this, everything is sort of built. On top of each other. And there's this whole pyramid of trust that has to exist in order for, you know, me to get my, my open source software out the door. So how far downstream can you guys look? You know, if I pull in package ABC. Or dependency ABC and into my path into my project, how far downstream in that package can you see and be like, Okay, [00:09:00] that thing depends on this and that depends on this.

And we know that that package is broken and or malicious.

Feross: Yeah, yeah, we have to go all the way down. You have to if you don't if a tool doesn't do that, then it's really missing the whole picture. So Absolutely. We go all the way down to the, to the, to get the full set of dependencies that are installed.

And, you know, it's actually, it's really fascinating when you start digging into these different, language ecosystems to see how they, they actually do things so differently from each other. So when we started, um, initially we supported JavaScript and NPM, which is, you know, the largest ecosystem by far.

But then we added Python earlier this year as well as go and they're, they're all so different from each other. So. When we added Python, we learned that, um, for every single Python dependency, what the developer thinks of as, you know, I'm using ABC. Package ABC version one, let's say there's actually dozens of different artifacts that could be installed depending [00:10:00] on your developer system.

So depending on whether it's windows, depending on whether you're, you know, 32 bit or 64 bit processor on your machine. And so you actually have for every package, you actually have a set of, um. You know, 2030 files that might be downloaded and when you're looking at, um, you know, packages that could be compromised, it may be that only one of those artifacts is compromised.

So only one particular architecture, one particular, you know, environment is actually going to get the booby trapped, um, package. And so, you know, we have to scan not just all the way down the dependency tree, like you were saying, but even within a single dependency, there's potentially like. Dozens of, of additional artifacts we might have to look at.

So it's really a, when you start getting into the problem, it's actually, there's quite a lot to get right. To do this correctly. Yeah.

Dennis: That is just knots on top of knots. On top of knots. I mean, there's no, it's literally. A task that humans can't possibly perform, you know, given the size of, you know, say just the [00:11:00] javascript ecosystem.

There's no way on earth that could be done manually.

Feross: Yeah, yeah, it's, it's wild. Um, the, the, the, um, typical app has. I mean, just, just hello world. It's kind of gotten crazy. I don't know how much your listeners, I'm sure everybody, like a lot of people love to hate on JavaScript because of how wild and freewheeling the ecosystem is.

But, it's gotten to the point where if you follow the guide, the official guide from the, you know, the react project to set up like a basic hello world website, um, you follow their guide, you install the dependencies. They recommend you end up with over a thousand dependencies. Just to get that hello world to show up on the screen.

So that's like what, you know, that's the way people are building apps today. It's like, you can't even get started unless you've installed a thousand dependencies. So then imagine as you build that app out, as you add more features and functionality, you're going to end up easily in the tens of thousands of dependencies range.

And that's what we see. Um, like just as an example, discord, the popular messaging app has 30, 000 dependencies. Um, and those. Dependencies [00:12:00] are written by, um, 200, 000 plus, different contributors. If you take all the commits across those dependencies. So it's just, you know, the whole world is involved in building, in building these apps, basically, when you really think about it.

Right. So it's pretty crazy.

Dennis: It is one of those things where if you think too much about it, you get to the point where you're like, how does anything work? Like, how does any of this actually function? And like, we're able to talk to each other over the internet. How does any of this actually. Work on a daily basis.

Feross:

Yeah, I ask myself that all the time. Uh, it's I mean, it's in one way. It's amazing, right? It's like open source actually mostly works and most people are good and, you know, people want to work together and we, you know, over time things improve, you know, if you, if you, there's that famous quote from Linus Torvalds, the creator of Linux, where he says, um, with enough eyeballs.

All bugs are shallow, uh, meaning, you know, eventually, like, the community is going to find the bugs and, you know, this is why open source is better than [00:13:00] proprietary software in general. That is because you have the ability to make things better and people to contribute. Um, and that's all true. But, um, I think what's really changed in the last decade is.

There's more people that we have to depend on than before. Like I would say, 10 years ago, you might, uh, you might have, you know, a handful of dependencies that you could name. You know, you might say, alright, we use Linux, we use the Apache web server, we use WordPress, we use jQuery for our front end. You know, you could name these dependencies and you knew who was behind them.

There is some foundation, like the, The jQuery foundation runs jQuery and you can trust them and they have a bunch of processes. And what's changed is now, um, and mostly it started, I would say, with NPM. Um, they made it so that anybody can publish open source code, um, in a very permissionless way. It was, it's literally one command.

You, you type NPM publish, your code goes live. There's no vetting process. There's no, um, approvals. So it's really made it, you know, like [00:14:00] Easier for people to contribute, which is a good thing in some ways, but it also means that it's, you should really think of these, these ecosystems as like a wiki where anyone can edit anything and anyone could put, put up anything.

There's really no vetting going on. Um, and when you. And when you have an ecosystem like that, then, you know, like Linus's quote about how people are going to look at this code and eventually we're going to find all the bad stuff isn't necessarily true. I mean, if, if, if, um, you know, a developer on your team typos and install and brings in a package that has, you know, a hundred downloads, no one's really looked at that.

You really can't expect the security community. To find all the vulnerabilities in these packages that are really obscure that no one's looking at. Um, and so that's, that's another reason why all this existing tooling is really broken down. Is that it's designed, basically, when, when people, when people say open source security, what they really, mostly mean is vulnerability scanners.

And those don't really tell you what you need in this new world. They're, they're, they're just going to say, yep, looks good, no vulnerabilities. But what about like, The fact that this package hasn't been updated in 10 years. Or what [00:15:00] about the fact that this package has one maintainer who has no history and is a no name and who knows who they are.

Or what about the fact that the package only has 100 downloads and no one's actually vetted it. And so the tool telling you that there's no vulnerabilities is not actually that reassuring because no one's really looked for vulnerabilities. And so who knows what the heck is going on in that package, right?

So there's all these ways that it's breaking down in the new world. Not to mention the fact that when you have, you know, 30, 000 dependencies, Then the vulnerability alerts that you get are also going to be so numerous that you basically ignore them because, you know, if you have 10 dependencies and you can, you can act on it, but if you have 10, 000 dependencies, then you're just going to see the alerts as noise and you're going to tune it out, which is what a lot of teams do.

They're just overwhelmed. And so the tools have broken down in that way too. So that's why we need change and in the whole ecosystem.

Dennis: Yeah, that's a great point. The vulnerability scanning part of it is one thing, but. And as you said, even if you go through that process and you get back, you know, 40, 000 CVEs [00:16:00] or 400 CVEs, whatever, nobody can address that.

We've seen that over and over again. There's no way for people to actually act on that number. Um, and you know, if they're in some package that you're installing, you can't fix it anyway. You know, it's not your package. Um, so you're sort of at the mercy of the developers.

Feross: Yeah, totally. I mean, this is why we've been really focused on this holistic risk picture, because we think that if you, if you can stop, here's, here's one way to put it.

Right. Like a package that has a malicious. Change or package that's been hijacked. That's always going to be higher priority than a vulnerability because right. A malicious package is going to compromise you 100 percent of the time. I mean, it's just, you don't want to run that code. It's bad. You need to stop it before it gets into your.

Um, and socket helps do that. You know, we have a tool that can wrap the package manager so that when your developer is running the command to install a package, we can actually sit there in the middle and, um, and intercept that install and, and, [00:17:00] and either stop it or, or prompt the developer to confirm that they're sure they want to proceed if we, we find something that might be worth a second look.

Um, so like a typo, for example, we would. Stop at them and say, Are you really sure you wanted to install that thing that has, you know, 100 downloads. There's one that's one letter off that actually has 100 million downloads. It's probably what you want to do install. And so we can save them before they own themselves.

There's just a lot to do. Yeah.

Dennis: And that's another thing I wanted to ask you this. This always seems like an obvious question, um, for a founder, but this also seems like one of those problems where a bunch of people probably noticed it over the years and looked at it and were like, man, somebody should do something about that.

And eventually somebody like you is like, you know, The hell with it. We need to do something about this. Like, I'm annoyed. Um, so what was actually like, you sort of described it before, but were you [00:18:00] surprised that nobody had actually addressed this? Like, did you go out and look and think like, there's gotta be a tool for this?

Feross:

Yeah, yeah. No. So I'll give you the exact story. It's so funny you bring this up. We were, uh, myself and a, and a couple friends were building this, uh, app called Wormhole, which is an end-to-end encrypted file transfer application. Um, we were building it, uh, and this problem came up while we were building this.

The reason is that we had a pretty high security requirements for this app. We really wanted it to be this most secure way to send files. Um, think something like a Firefox send. If you remember that service before Mozilla shut it down, um, we were building the kind of the V2 of that product and you can actually access it.

It's still online. Um, it's, it's, we, we maintain it. It's called wormhole. app and, um, it's a really great way to send files quickly, um, and it has a lot of really cool features like streaming the files across the web and. Really great encryption. All that stuff. But anyway, um, yeah, while we were building it, we were, um, you know, we were trying to do everything right.

You know, we had code review. We had a strict content security [00:19:00] policy. We were super careful when choosing our dependencies. All the standard security tools. Despite all this, we still ended up with thousands of dependencies because we used react to build the app, which, um, you know, maybe that was maybe that was our mistake.

But we want to do. We do right by our users. And we had this nagging feeling that like, okay, we're doing all this other stuff to secure our, our, our app and to do the right thing. But at the end of the day, we just have this pile of code. I mean, and if you think about it, open source is like 90 percent of the lines of code in your app, the app, the code that you actually write that your team writes.

You know, that, that we were writing for our app. It's like this like thin layer that sits on top of this mountain of third party code. So, and it doesn't matter that that code is written by other people. It's actually our responsibility as developers and, uh, you know, security teams that are shipping this code out.

Because at the end of the day, all that code gets bundled together and it runs in one process. It doesn't matter. Like, Oh, I wrote that code or they wrote that code. Like it's all one process at the end of the day. So we're going to get owned if, if that, that code is a third party code is bad. So. [00:20:00] You know, um, we just felt like, okay, we need to review this code somehow, but we're like a three person team.

How are we going to do that? And so we started asking around and you know, who, what do other people do? You know, surely, surely like other people do something about this. So we asked like all the, you know, all the best companies, all the people we respected and everybody just said, you know, well, we run a vulnerability scanner and we hope for the best and.

So I was just shocked. I thought there's no way that like this is the state of the art. Um, now that said, we did find a couple teams. There were a few teams I was very impressed with that actually do review every line of code of their dependencies. Um, it's like the Googles of the world, these really, really big companies will actually just take that code and they'll check it into their own.

Source control system and treat it as their own code. But that's like so expensive and so costly. Uh, so, so really you can't expect everybody to do that. Yeah. That's

Dennis: impossible for basically all but about eight companies to do anything like that. Right. Yeah. So how does, how [00:21:00] exactly does the automation work?

Like in the background without, you know, giving away the. You know, the state secrets,

Feross: Yeah. So we use a bunch of signals. Um, it comes down to, um, static analysis is the first layer of defense. So we actually, unlike all the other vulnerability scanning tools, we actually download every open source package that we can get our hands on.

Certainly everything our customers are using. But beyond that, we literally follow the feeds of all the new packages getting published on all the major ecosystems and we download them within seconds of them being published. Um, then we actually look at the code. Um, and again, that's really unique in this space because most of these tools, they just look up whether the package has a CVE based on its name and its version.

So they're literally just doing like a quick little database lookup to see, like, is there a CVE published for this based on the name and the version? They don't know anything about the code or the contents of the package and what it's actually doing. So we do that. We download the code. We look at its behavior.

We figure out whether it does things like access the network, read your files, uh, read your environment [00:22:00] variables. Does it contain obfuscated code? Does it run an install script so that the, you know, there's code that runs automatically upon installation? That's actually, you know, used by 95 percent of, uh, of attackers out there.

They love the install script feature of, of NPM that lets them just run their payload right away. So we look at all these things and then, um, when we find like enough, I mean, first of all, If, if you want to, as a customer, um, flag any package that has any of those things we detect, you can certainly do it.

So you can say, all right, at our company, we're going to review every package that accesses the network. That's just going to be our policy. If you want to do that, you can, um, for some teams that's too much. And so what, what they really like is that the next layer that we do is, is that we, we put any package that has these suspicious signals through an LLM and we ask it to basically explain what the code is doing and why, and then to actually make a determination.

As to whether or not it's malicious and doing just that simple approach. We've been able to detect 10, 000, like literally 10, 000 pieces of malware [00:23:00] on, um, NPM, PyPy and Go in, uh, just the last six months. just with that simple approach of looking for capabilities and then basically getting an LLM involved to make a determination.

So it's been super effective and we've rolled this out and it's basically, it's, it's out there in the wild right now and it's protecting all of our customers. Um, it's really cool. That is really cool.

Dennis: I mean, As I said before, like I get so many pitches or, you know, pings from friends that are like, Hey, I'm working with this AI based company.

And I like my ears just start ringing at that point. And I'm just like, Oh yeah, I can't really hear the rest of what you're saying. Um, but what you just described is an actual practical use for an LLM and like something that, you know, puts it into, you know, into practice and. Benefits people without just sort of throwing the A.I. Label on there, which is a lot of what I've seen so far in the security world,

Feross: unfortunately. Yeah. I mean, I mean, for so long, I understand why people are skeptical of this stuff. And for so long, [00:24:00] AI has been snake oil in the security space. So I'm almost hesitant to even bring up the fact that we're using LLMs because you know, it does trigger people.

I have to say like, you know, it actually, I would say what it's useful for is like, you'll see basically, I think you'll basically see three ways that LLMs are used in products today. You'll see a chat bot interfaces, which I think are. Mostly a gimmick. Um, maybe I'm wrong, but I just haven't seen.

I just, I feel like it's one of the most obvious ways to add an LLM to your product. That way you get the whole, you know, sexy AI label on your, on your product. I'm not, I'm not a huge fan. Um, then there's a summarization. Which is actually useful, I think, um, taking a machine alert and summarizing it in English so that somebody who's not an expert can understand it.

This is actually going to be super powerful in like, you know, in a SOC when you have like an analyst who's maybe less experienced. But in our case, it's useful because we're trying to explain to a [00:25:00] developer who's not necessarily a security expert why they should care about a reverse shell that's been added to one of their dependencies.

So being able to say in English, like, well, this is going to give. This attacker, the ability to remotely connect to your machine and run commands on your machine and be able to just, instead of, instead of sending them like a, you know, a bit of code showing it happening, we actually can just tell them in English why it's happening and how it's happening is super powerful.

Dennis: And that's, go ahead. Yeah, sorry. No, I think, I think that's exactly right. The Socket thing is just something I was going to ask you about. It seems like a perfect use case.

Feross: Totally. Yeah. So summarization very obvious use case and security and it's I think it's great. And then I'd say that the final one is, um, is the third one that I see a little bit less of, uh, that we're doing at socket is, um, is kind of, uh, kind of sifting through like a pile of like a big set of alerts or the big set of noise and trying to filter it down.

And, it's not perfect at doing this but it's, yeah. [00:26:00] Like, for example, we're dealing with a scale of the entire open source ecosystem. So it's impossible to like actually have a human look at all this stuff. And so what we do is we just, we use the LLM to, um, do kind of a first pass and get rid of.

Packages that are clearly safe are clearly like the, the, the, um, usage of the network, the usage of the file system that we've detected is actually very benign. So it can actually do a good job of getting rid of all that. And then it gives us a much smaller set of packages to evaluate that we can then have humans look at.

So we, it's not replacing humans. It's actually just letting us do more and like put, get, get the human, put the human labor in the right area and like direct it to the right, to the right stuff. It's actually worth the human's time. Um, and S and so that's, that's another area that we've seen it. Uh, we've seen it be used.

So it's socket, you know, we're doing it for, for packages, but we've also, I have a, a good friend who runs material security and, uh, they're over there doing it for emails and for [00:27:00] phishing detection, because it turns out LLMs are pretty good at like. Even, you know, give them email subject headers and they'll be able to figure out like what, uh, what's fishing and what's not.

So there are these uses that are actually perfectly suited for LLMs. So I don't think that security people should just write off AI as completely, uh, uh, snake oil anymore, especially with the new stuff that's coming out. No, as long as there's like a legit use case and you can explain it to somebody.

Dennis:

Yeah. But as you said, a lot of it is just chatbots on a product or something like that, which. Allows you to throw the the word AI in front of your products and catch some more interest, you know, on the RSA show floor or whatever, you know, that's kind of what that amounts to, unfortunately. So, um, what's the typical, I don't know if there's such a thing, but what's the customer look like at this point?

Are you guys going after specific industries or is it sort of catch as catch can?

Feross: Yeah. So, you know, when we started, we were really focused on this malicious [00:28:00] Detection that we've been talking a lot about. And, um, and so we did really well with like forward thinking companies, uh, you know, companies like, Figma, like, Vercel, a company, a bunch of companies in cryptocurrency, because they actually understand supply chain attacks in a way that a lot of other people don't. But, but other organizations too, like Repli, RADA, um, bunch of open source projects. We have a really broad set of customers. Um, and then more recently we've, we've actually gotten, um, really cool AI unicorns on, on board. I'm not allowed to mention their names, unfortunately, but we have like three of the largest AI companies, probably the ones that you're you would think of when you hear the term AI company are using us, um, and, uh, And I mean, the thing about, the thing that's really great about the space we're in is everybody uses open source, right?

There's nobody out there that doesn't use open source. Uh, so, so [00:29:00] like it, it really is a very broad product. Um, everybody has a front end, everybody has a website that with a ton of, and they're probably using NPM, whether they want to or not, um, because the developers on the team insisted on it.

And so the security team got overridden and was. for kind of forced to allow, you know, uh, their developers to use, you know, quote unquote, modern, modern, uh, tools like NPM. And so they, they end up in this place with these thousands of dependencies. So the problem is just super widespread. Everybody has it.

Dennis: Yeah. And it's also, I'm guessing you don't have to explain the problem very deeply to people. They probably just get it, especially if there's one developer in the room. They're like, yeah. . Yeah, I completely understand what you're talking about.

Feross: Yeah, totally. Yeah. And I think, I think that the security teams get it too, and you know, they wish there's something they could do that that didn't slow down their developers.

And so that's one of the things they like about the fact that we're really there in the, in the developer workflow. Like I, I mentioned the PRSs already we're in the pull [00:30:00] requests. Um, we also are, are even earlier in the, at the moment when the developer's installing the package, we can, we can intervene, but we even have like probably the.

You know, shifted left. You can possibly get, which is we have a web extension that will literally advise the developer as they're browsing around the web, looking at stack overflow and Googling, it'll literally tell them if they're looking at a bad package, it'll say, Hey, don't install this. Like this is bad.

Yeah. Yeah. So it's, it's as early as you can get, right. It's, it's like before they've even made the decision to invest in like building some feature using this dependency, and then they're going to get slapped down by the security team later. Um, like before they get to that point, you can just tell them upfront, like, Hey, this thing actually kind of sucks.

Don't use it. It hasn't been updated in two years or whatever the problem may, may be. Um, uh, oh yeah, the other, the other place that's really useful is when there's, um, protestware. Which is, um, have you heard about this? Do you know, you know about, okay. Yeah. So this will be interesting. So, uh, [00:31:00] this, this, this trend really started at the beginning of like the Russia Ukraine conflict, uh, when, um, a lot of people were really upset about that, obviously, and, um, a bunch of maintainers wanted to use their, I guess their, their power over their, you know, their open source.

Code to, to make a statement and to protest, you know, and, and so a lot of them were, we're doing is putting in hidden code into their packages that would, that were not doc, it was not documented. It would do, would do, you know, different things depending on who, who is running it. So I'll give you a couple of examples.

Um, one person added code into their very popular project that would, uh, delete your entire hard drive if you appeared to have a Russian IP address. So this affected people who were using a VPN, or, you know, who, you know, had their IP address in their GeoIP incorrectly. It affected a bunch of people, as you can imagine.

Um, then there were more benign cases where people would, like, Include hidden code that would pop open a [00:32:00] pop, uh, uh, kind of a petition to sign, uh, you know, to make a statement about, you know, being against the war. Um, but it would do it, it would do it in the front end of anybody using their, their code. So that means if you're, if you're a bank and you're using this, this open source code that your visitors are going to get a pop up asking them to sign a petition.

It's like, I don't care what you think about, you know, what your political opinions are, the open source project should not, you know, it's not what open source. It's not what people expect when they're using open source, right? Exactly. Yeah. Yeah, and so, you know, it's really, it, it, it, uh, it was very eye opening to people.

The thing they did that was also particularly nefarious was they made it so that it only ran if your time zone was set to an Eastern European time zone. So if your, if your developer team is in like, you know, North America, Like, they wouldn't even see this. It would only happen once it got into production and the code triggered, it's, you know, triggered itself.

So, and the craziest part about this whole incident was that this code is still live today on GitHub and on NPM. And they've refused to take it down. And Really? Yeah, and I think it's a gray area because it's, it's a freedom of speech issue in some ways for the maintainer. I mean, you know, and so there's different people to have different thoughts on it.

It, should it be allowed? Should it not be allowed in that case? They've decided to keep it up. The code is still hosted on GitHub if you're unfortunate enough to be using one of these. booby trapped versions in your, in your app, like this is happening to your visitors today and it's, and you might not even know it.

And so this is where like, Socket can come in and when the developer is like considering using this package, we can tell them, Hey, even though this is on GitHub, even though it has 600, 000 weekly downloads, Um, you, you, you probably don't want to use this. Uh, and here's why, right? And, um, A anyway, if your listeners are interested, the the package is called, uh, EventSource Polyfill, and that's it's quite popular.

Like I said, 600, 000 weekly downloads, and this is this is still out there today. That's crazy.

Dennis: I had not heard of that. That's wild. Um, but [00:34:00] yeah, it does illustrate the thing that you mentioned earlier, where you're a maintainer and you have essentially complete power over the code that's in that package.

You can do whatever you want with it and cause, you know, downstream consequences for a whole lot of people. And, you know, there's not a great way of avoiding that. Uh, unfortunately.

Feross: Yeah. I mean, some people, you know, are, are careful about updating, but you have this, you have this unavoidable trade off where you have, you know, either you stay up to date really aggressively, which is really good at avoiding vulnerabilities means you're going to, you know, you're going to patch as soon as you can to, to fix CVEs, but you've now opened yourself up to supply chain attacks and, and, Installing code that has, has only been published a couple of days ago, in some cases, and hasn't really been vetted by the community yet.

And if you go too slow, then you have the other problem, which is, you know, that we've been trying to avoid for the last decade, which is getting people to patch. So if you go too slow, you're [00:35:00] going to just be vulnerable and, you know, you're going to be using code that's really old and has vulnerabilities.

So, we think the solution is patch fast, but, but use a tool like Socket to actually figure out what the code is doing and highlight when, um, for example, A package you've been using for the last two years, uh, suddenly decides it needs to, uh, access the network. Like, okay, why, why do you need to do that?

Right? Like, in the same way that an iPhone app, you, you know, if you're using an iPhone app and it suddenly decides it wants to use the camera, you know, it doesn't just get to decide that it has to ask you, it has to, you know, prompt you for that. Like, that's kind of where we want to get to with open source packages.

You know, the maintainer doesn't just get to decide that they want to do that. Now, um, you, you get notified as a user of it before that, before that is allowed to go forth.

Dennis: Well, it's a pretty fascinating problem if, if there is such a thing and you know, I'm glad that somebody is actually tackling it in.

It seems like a really cool approach that you guys are taking for us.

Feross: Cool. Yeah. Thanks, Dennis. [00:36:00] Appreciate it.

Dennis: Yeah. Thanks so much for coming on, man. I appreciate it and best of luck and. Hopefully I'll talk to you again soon once, uh, as, as things move along.

Feross: Yeah. Thanks for the opportunity. It's been super fun.

This is a great chat. Thanks for all the awesome questions too.

Dennis: All right. Good to talk to you, man. Take care.

Feross: Take. care.

​