Chinchilla Squeaks Podcast: Modern Solutions for Securing Software Supply Chains

Socket CEO Feross Aboukhadijeh recently joined Chris Chinchilla on his Chinchilla Squeaks podcast to discuss modern solutions for securing software supply chains.

This episode extends into broader themes of open source maintenance, the evolution of dependency management, and the risks of selecting packages simply based on whether they have no known vulnerabilities.

Feross noted the irony in how much scrutiny developers apply to the direct code contributions of their teammates, versus the cursory approval of external dependencies, which can carry significantly higher risks, including potential supply chain attacks:

In a weird way, the teams actually tend to review the source code of their teammates more thoroughly, because when you open a pull request, you get to see the code that they wrote and you get to review it and leave comments on it. But when they bring in like five dependencies that themselves ended up bringing in 150 additional transitive dependencies, everyone just says, "Yeah, it looks good to me." And no one even opens the code up and looks at it. And some of these supply chain attacks - the bar is so low that if you just open up the file, you can often just see, there was no attempt made really to hide this.

This critical gap — where developers install any packages they want to use but don’t thoroughly vet them, is what Socket was designed to secure. Many of these packages contain obvious security threats that would be easily identified with minimal examination, but the reality is nobody is reading all the code in their transitive dependencies.

Feross explained how Socket uses static analysis and LLMs to provide real-time detection of supply chain attacks across hundreds of thousands of packages by downloading and reading the source code. By automating this crucial aspect of securing open source code, Socket enables developers to build secure software with confidence, focusing their code review efforts where they matter most.

Listen to the episode on the Chinchilla Squeaks website, and check out the transcript below.

TRANSCRIPT:

Chris: I'm Christian Chinchilla. Welcome to my podcast, an enthusiastic ramble through whatever has taken my interest the past week or so. Expect technology, games, history, travel, geekery, and as always, much, much more.

Hello everybody, welcome to another chinchilla squeeze with me, Chris Chinchilla. This is an episode of interview show and my interview this episode is one back from last year i think i have one more from last year after this one and it was with Feross from Socket.dev, one of the many companies involved in software supply chain security. They have an interesting product that deals with vulnerabilities, but also provides visibility, reporting, policy enforcement, and all of that. All these various different aspects of software supply chain security, not just looking at vulnerabilities and helping you identify and potentially fix those, but kind of the full gamut and with an interesting chat, an interesting product, one that I will probably look into a video of soon.

Chris: You actually have quite an interesting story, but I think we should probably start a little bit with Socket first, and then, and then come back to you, maybe.

So Socket is in this fairly active, at the moment, space of software supply chain security. Where do you fit into that wider landscape, which is growing, so it's always interesting to know which part the companies in it think they fit into the most.

Feross: It's a great question because so many people use the word software supply chain.

You know, that phrase has become a bit of a marketing buzzword. So it's important to really dig in and say, okay, what do you actually do? Yeah. What would, what would you say you do here?Socket is a developer first security tool focused around dependencies and basically helping developers to pick dependencies that are safe and secure.

And then on the other hand, once dependencies have already been included in an application, we help the security team to understand the risk of those dependencies, both in terms of vulnerabilities, which is traditionally been what tools in the space focus on, but beyond vulnerabilities Socket also helps detect malicious dependencies and other types of risky dependencies.

And there's a whole bunch of different angles when it comes to risk that we look at that go really far beyond what a traditional CVE scanning tools.

Chris: And you're right because I think a lot of other tools will look for just known vulnerabilities in dependencies, but I'm getting the impression that you go further than that.

Is that the case?

Feross:

Correct. Yeah. Perfect example of the limitations of the known vulnerability approach would be, say you have a developer on your team that makes a typo when they're installing a package and they get one letter wrong. It turns out that a lot of these package managers like npm and pypi, they let anybody publish packages under any name with really no vetting process at all.

And so a simple mistake like a typo doing during an install command can bring in untrusted code from a random publisher. And a lot of the times, I mean, I've done this myself and I'm a very security conscious developer and what will happen is, you know, that code in many cases may run, you know, the attacker's code immediately using something called an install script.

That's a huge risk. Just getting a typo there, but then say that package actually ends up getting merged and it, you know, maybe it's just something that isn't very popular. You know, maybe it has a hundred downloads a week or something like that. That's going to be something that almost certainly has no known vulnerabilities, but that doesn't mean it's because the package is safe.

It's because nobody's really bothered to look at it. You know, it's really relying on human researchers to actually care about. Doing the work to go and look at that package. And so that's one really big problem with the known vulnerability approach is just, you know, it'll tell you, Hey, there's no known vulnerabilities, but that doesn't mean it's safe.

Chris: That's actually, that's actually a good point. Yeah. And, you know, much like people squat on website domains that sound a little bit like other website domains that people might mistype. I would imagine there's a few people who probably less of a less lucrative, but, well, I suppose it depends, but squatting on.

I don't react with a K. Or And all sorts of strange things like that. But I also noticed because you're So you've got these kind of five tabs of the features you cover. And we've mentioned the sort of vulnerability side, but you also cover things like licensing, which is often kind of a secondary secondary tool in the kind of policy tool chain for many companies, I think fitting into what you said about the no known vulnerabilities because no one's using it.

You've also mentioned strange things that I wouldn't even think about here with licensing, like changing licensing, uh, mixed licensing, um, even maintenance, uh, deprecated, no bug tracker, again, that fits into the, you know, if no one's using it. Okay. It's safe, but that's because no one's touched it in five years.

Like that doesn't make it any more safe. Yeah. So there's lots of little more subtleties to some of the things that you're doing that I haven't seen so much in, in some of the others. Yeah. That wasn't really a question. That was more of astatement.

Feross: No, I mean, I think what we're doing is pretty unique.

It's, it's something that, you know, we got really interested in doing because our whole team is open source maintainers. And so we've really seen the producer side of this equation. More than the consumer side. And so, you know, I've seen my fair share of supply chain attacks that, you know, involve packages getting compromised, hijacked in various ways.

And one of the things that always disappointed me about the way that the community the security community handled it, is it, it always felt like it was very reactive. Waiting around for a happy accident for somebody to find that bad code was added to one of these packages in one case, you know, the malicious code wasn't caught except for the fact that a new version of the node JS runtime had come out and it happened to deprecate.

One of the functions that the attacker used in their attack code. And then that started producing a deprecation warning. And then the developers traced it, you know, community traced it back to, to the attack in, you know, in this package. So this package was actually, you know, was, was a compromise with the supply chain attack.

But, you know, it was like if five, six days until it was found and it was a total accident that, that allowed the community to find it. And so it just, it just seemed like, you know, we could write rules to detect these types of things. And, you know, we had seen enough of these attacks that, you know, it felt like we could.

Really produce a pretty comprehensive set of, you know, what do attackers do once they get their hands on a package? And so because of that, we ended up building something that, you know, it really is a, it's pretty different in the, in the space of software composition analysis tools or SCA tools, which is typically what this area is called.

And, and yeah, so we do vulnerabilities of course, but because everybody does that and it's a, it's, you know, it's worth tracking that stuff, it's important. But we also, we also do. Do a whole bunch of other things, but

Chris: actually something, another thing on the front page of your website, I'd like to ask more about is, so you've mentioned that a lot of the time, a lot of other companies in this space do sort of lean off of fairly large databases of, of known vulnerabilities and then adds maybe some, some things on top of those.

But one thing you're saying here is real time, how, without giving too much away, how are you managing to do. Real time across, you know, the hundreds of thousands of potential sources of that real time information.

Feross: Great question, and I'm happy to share it. We've been pretty open about how we do this. So the first step is we, you know, we need to have a copy of all the source code of, of all the, all the dependencies that you might possibly use.

Um, this is something that all those known vulnerability vendors don't do. They really just have a database of these known issues, uh, that says, Hey, this version is bad. Here's the version you got to update to, but they, you know, that's basically a human curated database that's maintained by the federal government, actually in the U S uh, the national vulnerability database is what it's called and basically, every vendor just downloads that and resells it in various ways.

What we do is we start from the source of truth, which is what is the code going to do when you, when you run it, you know, and, and we download all that open source code. And then we, we start by running a static analysis over it using our own in house static analysis engine. And we look for a bunch of things, things like what is this package's capabilities?

Does it read files? Does it access the network? Does it create child processes? Does it contain. High entropy blobs of code indicating that there might be obfuscated code or or minified code added that is trying to hide what it's doing by being, you know, by obfuscating itself like that, you know, that type of thing.

And And so if you see a package that has been around in the community for five years, and suddenly now there's a new patch release that's come out that needs to access the network and open up, you know, run some shell commands and download an exe file, then like probably it's worth having a human take a look at that.

And so the product will, will tell companies that, and if they'd like to just be told anytime a package, you know, has the use of use of certain capabilities, we can do that. We can send them an alert and say. Hey, you know, this is a new package that's using the network and, and they can, they can then, you know, review it themselves if they'd like.

And that's very easy to do in a real time sense, because we have all this code. And when, whenever we see a new package get published, we immediately scan it. So we just have a whole bunch of worker servers that are sitting around doing this. And if there does happen to be, for example, some package that we haven't scanned and a customer asks us about it through our API or through an integration, we can actually just.

And now analyze it on demand for them and give, give them the results. So, so we're, we're, we're always scanning stuff and looking for these, for these types of risks. But then the next step we do for, for a lot of teams, they don't want to have, they don't want to waste the time of their developers to actually review these, these potentially potential risks, malicious changes or these potentially risky changes. They just want us to tell them when we find something that's bad in their dependencies and to stop it from getting in the first place. And so to do that, we, we actually introduced and apologies. It's going to sound like I'm using buzzwords and stuff here because I'm going to say AI, and I'm going to say LLMs, but we actually found a pretty cool use for LLMs here, which is that rather than just, you know, throwing a chat bot interface onto our existing product like, like a lot of people are doing and calling it AI or even, you know, introducing some summarization or something like that into the product. We, we actually use the LLM in a way as a security researcher intern. So how I like to think about it, like we have this, this LLM that can look at code, it can describe what it's going to do, even if it's obfuscated and it can say, this is the data source.

This is the data sync. This is what the code seems to be doing. And then we can kind of get it to say, like, does it seem like it's malicious potentially. And if it does, if it does determine that it does have a, it does have a notion of maliciousness and it's not perfect and there are a ton of false positives, but if it does think that something is malicious, we can actually look into it further.

And that's actually allowed us to cut down on, on, you know, instead of having our human team reviewing, You know, the 7 million NPM package versions that have been published. We can have our team focusing on, on, on stuff that just seems very, very high risk and do that approach. We've actually been able to find around 400 malicious packages that are published every week that we take, we get taken down from NPM and PyPI and we protect all of our customers.

And while we're in parallel, trying to get those taken down. Yeah. So. So yeah, there's a human in the loop and, and, you know, and so it's not, you know, it's not going to be like instant instant if you, if you do want that human in a loop, but for, for some teams, they they're paranoid enough that they're willing to say, you know, what, like any package that the AI thinks is suspicious, like just.

Just block it until we've had a chance to look at it. And then even more paranoid people will go in and say, look, anything that's touching the network, anything that's using the file system, any of these capabilities that are sensitive also, you know, put those into a, you know, into a review before letting them in.

So just really what risk level you want to accept. And so some of those are more instant than others. Obviously the. human in the loop on our end is gonna, it takes a little bit of time, but we're pretty fast. So yeah, does that make sense?

Chris: You know, for sure. I just wondered, though, I think this is leading a little bit towards your, your background and how you got here, which we'll come to next.

But so you, as far as I can see, you are currently And I think this is possibly relating to a lot of the kind of extras you're adding on top. You support NPM, Go, Maven, PyPi packages. Whereas a lot of other vendors might also have things like containers and I don't know, any, I honestly can't think of many other, I suppose, crates or something, you know, you know, there's a lot of other things that they also support, but I guess that slightly more.

You're going for a slightly more curated experience, but are there, are there things that are next on the list to, to add to those four sources?

Feross: Yeah, for sure. The number one request we have right now is more language support. And so it's, our main priority is getting more languages so that when we come into a company, we can protect all their repos.

But I will say that one of the things that I'm proud of is that we're very focused on doing this. One thing and doing it really well. And since it is something that no one elseis really doing in the way we are. I think it's been received pretty well by the market because they, they see that, Oh, you know what, this is a gap that we have, you know, we're letting our developers install whatever packages they want.

And we're not even, you know, in a weird way, the teams actually tend to review the source code of their teammates, you know, more, more thoroughly, because when you, when you open a pull request, you get to see the code that they wrote and you get to review it and leave comments on it. But when they bring in like five dependencies that themselves ended up bringing in.

You know, 150 additional transitive dependencies. Everyone just says, yeah, it looks good to me. And no one even opens the code up and look, looks at it. And some of these supply chain attacks are so like the bar is so low that if you just open up the file, you can often just see, there was no attempt made really to hide this.

They'll just drop a giant blob of high entropy, you know, encrypted code that gets evaluated at runtime right into the bottom of some file. And it's like, if you just looked at that, you would have seen it, but no one's doing that. And, and I mean, and so. To answer to answer your question, I think, I mean, at some point we, you know, we, we will expand further into, into different areas, but one of the things that.

I'd like to be careful of is you see a lot of security companies do this where they'll basically go for breadth and then, and they'll do this through acquiring startups and kind of poorly integrating everything together just so they can say that they have this coverage, but in reality it doesn't really work that well.

And, and so our approach, I mean, Our whole team is open source maintainers. We, we really pride ourselves on our craft. I don't think we want to go down the route of, of building, you know, low quality enterprise software and just selling it to executives. And then the executives forced the developers to use it, even though it's terrible to use.

And it makes everybody upset. You know, that's definitely, that would be so against our, the way we would want to do things that, you know, we're going to, we're probably going to take a more, Careful approach than that.

Chris: And for the most part, it seems like your main interface is a, is a GitHub app. So I guess it sits on those aforementioned pull requests and, and digs a little deeper.

Feross: Yeah, yeah, exactly. I mean, we do have an API and, uh, and other, but, but, but yeah, the GitHub app is definitely the quickest way to get going. It's a two click install. You just, you Click it. It comes from the GitHub marketplace and then you pick the repos you want to protect and then that's it. And then we start, we start scanning all the repos, no changes needed, needed to CI or CD, no tech, you know, developers to go and do a bunch of work to add it to every repo and that type of thing.

Chris: And I, I wonder if this is a little bit, you know, you, you have NPM, Go, Maven, PyPy, but PyPy, I can never remember what it is. And especially with Go and Maven, that's sort of a lot of backend code, but you are sort of pushing the JavaScript first, uh, quite a bit. And when I look at, and this comes to your background a little bit, but I also see some of your clients like Figma, Versal, Next. js, sort of same people, Brave, Metamask, Storybook, a lot of very much front end JavaScript people. So it sort of feels like that's definitely the world that you've, you've captivated first anyway. And of course, whenever we think of packages, we tend to think of JavaScript first, even though it's not an original concept, of course.

But that tends to be the stereotype of where we think so is, is a lot of that just because that's the world that you've come from and we can talk about some of your projects in a minute, but is it, was it sort of JavaScript first and then the others came later or.

Feross: Yeah, we started with JavaScript first for a couple of reasons.

One, that's the community that a lot of us came from, so it was easier to get adoption there to begin with. But the other big reason, and honestly, even if we came from another community, We would have started with JavaScript first because it's the largest ecosystem. And it's also had the most, you know, high profile incidents and the most supply chain attacks, frankly, because it has a very, what's the word permissive and welcoming culture where there's very few barriers to entry.

I would say, you know, npm was one of the first package managers to create like a one line, kind of a one command publish. You just type npm publish. There's no signing step. There's no keys to set up. There's nobody to approve your packages. You just, it's just, you can register whatever name you want with one line with a one line command in your terminal.

And for that reason, I think they, they were super successful at getting people to publish to npm. And that's why it's one of the reasons why it's the largest, you know, package manager by far. I'll say the other, the other reason that npm, uh, both became one of the largest and also has sort of the most attacks that we hear about all the time is because of this culture of small packages.

And I would say this came about for, I think it's a kind of interesting reason, which is that it's funny, the phrase dependency, hell, It used to mean one thing. And now people think of it as they think of npm as dependency hell, because it's like, you know, you have a thousand dependencies when you just get hello world working on your website.

And, but the dependency hell used to mean something else. And npm was actually the solution to dependency hell, believe it or not. The dependency hell used to mean, used to mean a specific thing. It was when you had, if I have package A in my project and it depends on package C. And let's say at version 1.0, I need package C at version 1. 0. And then I add package B to my project. And B also happens to have a dependency on C, but it's version two of C. Now I have a problem where I have a, and I have B and they both need C, but they need different versions of C. And it turns out that like almost every package manager that came before NPM, maybe all, I don't know, but every single one that I've, I've ever used before NPM would just, the package manager would throw up its hands and say, Sorry, you know, I can't we can't install this because you need two versions of C pick one and and the problem is it's not like it's even in your control.

You're not even using C. You don't even know what C is. C is a dependency of your dependencies. So now you're just in a situation where you're screwed and there's nothing you can do. And so NPM said, Hey, this is really dumb. Let's just install both versions of C. We'll install version one and we'll install version two.

Yeah, and then it says we'll just give version one to A and we'll give version two to B and now everybody gets the version that they want. Now it's not a perfect solution because in some cases you might end up with objects. Duplication of code. You might end up with an object that you create in, you know, create.

If A returns the raw, like, Object that C produces and it's a version one of that object that might not be compatible with a version two of that object That's coming from the other library, but in in general it kind of just works to do this um And so it solved dependency hell, which was getting yourself into an incompatible situation where you can't proceed but the flip the the effect of that was that now suddenly There's no downside as a maintainer For adding additional dependencies.

It used to be that you'd have to worry that you were going to create dependency health for your users by adding dependencies, but now you can just add like a hundred dependencies and you'll never create a situation where your users won't be able to install your package.

Chris: So including now when we get to NPM trying to install Python and C dependencies, which is where it gets really weird.

Anyway, that's a separate, definitely a separate conversation. And I feel like I've had that conversation with someone on the show before, but let's just, I would really like to, to know. How you got to where you are, because you've been around open source for a little while. I can see some of the things that intrigued me.

You've got this MIDI player. I've been experimenting a lot with MIDI and music XML again recently. So I've been going back down the MIDI path for the first time in ages, but that's probably not your best known ones. You have a WebTorrent client and standard JS, which definitely does ring some bells. And that's Starguide. and Linting. I am actually super into Starguides and Linting. Mostly, actually, with English language, I help maintain Some tools in, in that department. And I can start to see how that might have led you towards something like Socket. But I don't see a complete path through some of these projects into something like Socket.

So how did you, how did you get there and why? What, what, what, what was the epiphany, the nightmare that you had that made you want to go down this path?

Feross: Yeah, you know, it's hard to connect the dots sometimes for how I arrived at this place. But I will say that. You know, I got obsessed with a web torrent and this idea of building a torrent client that works in the browser and that project really Was my main thing from, from, you know, most of my twenties, honestly, like, and, and one of the things that you learn with peer to peer projects is that security is actually really important because you're dealing with peers on the network that you don't trust.

So you always have to think about security from the very beginning. It's not something you can, you can add on later. Um, and so that's always been kind of there. And then also that project is what got me into being an open source maintainer. So while building that, I ended up making standard JS to mostly just to prevent people from sending me PRs, which were mostly good, but then had a bunch of problems stylistically or didn't handle errors and things like that, that I could catch with a linter.

And, and so before I knew it, I found myself maintaining about a hundred packages on NPM and it's one of these things where you start off and you're like, Hooray. Like, you know, I have these users using my code. It's so cool. Like, I, I feel like, you know, I'm doing useful work for the world, but eventually you end up, you end up overburdened with, with, when you get enough users of, of your, of your project and you're just a single maintainer.

And so you end up adding other people to help you end up really just having more issues than you can fix and, and, and, and, and so a lot of, a lot of questions start to come up when, when, when, when you are maintaining stuff, which is like, how do I trust this additional person to, should I give them access to the package or not?

I mean, I, I have a, I have history of maintaining this in a certain way. And if I add this additional person, they could just take it in a completely different direction. They could be a bad actor, especially if I've never met them in person before. I don't know who they are. And so we, you know, I had a friend who this happened to and, and in 2017, it was, it was very, pretty big incident in the NPM community where the event stream package was hacked.

You might've remembered this basically happened that, And a maintainer was added to a package and he pretended to be good for about a month and made really good changes and then eventually put in a backdoor that targeted a specific company. And so, you know, seeing kind of the way that, you know, the way that maintainers do things, but then also just seeing that, that all these companies, these fortune 500 companies were using my code when I was like a 20 something year old, you know, that was also very, very humbling.

And it made me realize that these companies don't really know what's in their supply chains. They're just pulling in this code. Their developers specifically are pulling in this code and hoping For the best. And so it got me interested in kind of supply chains and security and how do we trust the code that we're using?

And, and yeah, and then the final kind of nail in the coffin that made, that pushed me over the edge to want to work on, on this company socket was my, myself and two other people were building this product called the wormhole. Wormhole. app is the URL. Oh

Chris: yeah. It sounds like a, it's like an ngrok type.

Feross: No.

It's a file transfer tool for like sending files across the web to other folks. Yeah. Was it IPFS based or no? He uses WebTorrent under the hood.

Chris: Oh, WebTorrent. Okay. I might have come across it when I was messing around more with the decentralized crypto world.

Yeah. Oh, or maybe we used it. Oh, I can't remember. It definitely rings a bell, but anyway. Yep. Yep.

Feross: Yeah. So it's, it's basically a way to, it's like Firefox send. If anybody remembers that, that tool, you drop your files on the browser, you get a link, you send it to somebody, they can download the files, but it has a couple of really important attributes.

One is it's end to end encrypted. The, the link automatically expires and the, the files are streamable, meaning that, uh, even before they finished uploading. So like within a second of you dropping the files on the page. You get a URL that you can send. And that means that the recipients can actually start streaming the files from you, meaning like the encryption is streaming.

And if they were to say, click on a video that you're trying to send them, they could seek the video to halfway through the video. And even if you've only uploaded like 0. 1%, it smartly reprioritizes the part of the file that you're uploading to. Yeah. So it's pretty, it basically gives them the video that they need and uses it's peer to peer too.

So it can, it can literally. Directly send this to them without going through the server. But then, you know, if, if they, you know, if, if you, if you finish the upload, then of course, you know, you can then shut your browser down and then they'll be able to use the link even after you've, you've gone for up to 24 hours.

So it's kind of a hybrid between a traditional, like file hosting thing where you'd upload the files and a peer to peer system where they can, you know, get the performance benefits. It's kind of sad.

Chris: Cause it sort of feels like there was a lot. More call for these sorts of very clever peer to peer sharing applications a few years ago, and now people don't really use them as much anymore because internet is better or whatever the reason may be.

And I don't know, I feel like we used to be clever about file sharing in the past.

Feross: I feel the same way, although I still have to say, it's, it's funny how much Dropbox and Google drive still actually haven't, haven't innovated in this area. I mean, If you're trying to send somebody like, you know, a 10 gig file, you do, you do really have to wait for like a while to upload in the meantime, you can't get a link to send.

Chris: That is true, actually. Yeah. No, anyway, I feel like, so just out of interest, because we're running a little bit out of time, but for anyone who found this interesting, you do come from open source background. You do have an open source. Yes. Which is pretty generous. I think the only thing that's missing that could be useful on the free open source tier is license enforcement, but I'm not sure how much open source developers would really need that more beyond just being, you know, very strict open source license people.

So there's definitely a lot people can play with. If we were to speak in six to 12 months, what have you got on the roadmap next?

Feross: Way more programming languages supported. You mentioned that. Yeah. Yeah. And we'll have a lot more. Analyses, different things we're going to be looking for, hopefully better coverage of different types of threats that we're seeing, so that's going to keep improving.

Overall, we want to make the website we have today is pretty useful for a developer just to go and search packages and see like what the risks there are and just kind of what, what they need to know about a package before they install it. And one of the things we want to do is keep improving that so that it's really the best place to start when you're looking for open source packages.

Chris: Well, it's, it's also, you'll be pleased to hear. I see that they're one of your customers, but have also supported you a lot through some of your projects. I have been using Brave the whole time. So it's just, it's during this, during this call, which is also sort of nice to see that people have come with you on your journey as well.

Feross: So the Brave team is great. They're just really good people and, and it's a, it's an important product, I think. It's a really interesting browser. It has so many things in it. It does. It does a lotof experiments.

Chris: I will mostly use Safari, but if I have to use a Chromium browser, I will only use Brave.

I won't use Chrome, that's for sure. But anyway.

Feross: Brave has WebTorrentbuilt in, by the way.

Chris: Yes, it does. You're right, actually. I've never really had a need to use it, but I have seen the setting. Yes.

Feross: Yeah, if you click on a torrent link, it'll suggest that you enable WebTorrent and then You can, uh, torrent directly in the browser without needing a third party app.

Chris: I was wondering what project they'd supported you with and now that makes sense then. Okay. Yes.

Feross: Yes.

Chris: Well, thank you very much for joining me and I don't normally tell people this in the recording, but seeing as it's very appropriate, I'm going to hit stop and stay on the line because we need to let the stream finish.

And that was my interview with Feross from Socket. Anyone involved in the whole software supply chain should check it out.

See you next time. I hope you enjoyed the show. Find out more about me at chrischinchilla. com, where you can find show notes, sign up for my newsletter, and find all of my writing, games, work, and video links. There's also details on how to get in touch with me. And if you want to get even closer to what I do, you Join my discord server for behind the scenes discussions and helping me produce my shows and work.