Podcast Episode 36

Episode 036 54 min

Feross Aboukhadijeh, Founder and CEO of Socket.dev, a startup improving security and privacy on the web

with Feross Aboukhadijeh · Socket.dev

0:00 / 54:00

Also on Spotify, Apple Podcasts, YouTube, Podbean, Player FM

Episode 36 of The Security Podcast of Silicon Valley, published February 1, 2024. Host Jon McLachlan talks with Feross Aboukhadijeh, founder and CEO of Socket, about PeerCDN and WebRTC, selling PeerCDN to Yahoo, WebTorrent and the BitTorrent clients that adopted its protocol, bringing torrents into the Brave browser, Standard JS and its name, the CS 253 Web Security course at Stanford and its 24-hour final exam, a microwave child lock, the written rules and the unwritten rules, why most CVEs are noise, an app that changes 5% of its code every week through dependency updates, maintainer accounts with enormous reach, the event-stream backdoor, typosquatting, what a one-minute look at a malicious diff shows, heuristics and LLMs that block malware within minutes, the GitHub app and the command line tool, a browser extension and the iPhone permission prompt as a model for dependencies, bottom-up go-to-market and leadership, weekly planning with about 15 people, the Series A led by Zane Lackey, Wormhole, interviews with 40 application security leaders, The Matrix, Waking Life, and stay hungry, stay foolish.

Episode notes

In this episode of The Security Podcast of Silicon Valley, host Jon McLachlan of YSecurity.io invites Feross Aboukhadijeh, Founder and CEO of Socket.dev, a supply-chain cybersecurity company, to share his compelling journey as he tackles some of the most pressing challenges in software development security. Feross, a Stanford graduate and former intern at Intel, Facebook, and Quora, shares his journey from developing PeerCDN, a pioneering peer-to-peer content network, to his current venture, Socket.dev. Discover how Socket.dev is addressing critical software supply chain vulnerabilities by utilizing innovative technologies, including heuristic analysis and the latest LLMs. This episode offers valuable insights into the evolving cybersecurity landscape and Feross's unique approach to tackling some of the most pressing challenges in software development security. Join us for a captivating discussion that's a must-listen for anyone interested in the future of cybersecurity.

Hosted by Jon McLachlan — co-founder of YSecurity.

The deep dive

The unwritten rules

Feross Aboukhadijeh, founder and CEO of Socket, with Jon on peer-to-peer in the browser, WebTorrent, a style guide named as a joke, a final exam that was a 24-hour pen test, a microwave child lock, the written and the unwritten rules, why most CVEs are noise, an app that changes 5% of its code every week, the event-stream backdoor, typosquatting, heuristics and an LLM, two clicks to install, a permission prompt for dependencies, bottom-up go-to-market, Wormhole, 39 of 40 security leaders, and The Matrix.

Episode 36 of The Security Podcast of Silicon Valley aired on February 1, 2024, with Jon McLachlan hosting. The guest was Feross Aboukhadijeh. His LinkedIn lists him as founder and CEO of Socket since June 2020, and its headline reads “Created WebTorrent and StandardJS · Taught CS253 at Stanford” (Podbean, LinkedIn). Jon introduced Socket as “a cybersecurity platform that protects companies’ software supply chain against attacks.” The episode is called “Feross Aboukhadijeh, Founder and CEO of Socket.dev, a startup improving security and privacy on the web.” It has no video version.

The idea under all of it came up a quarter of the way in, when Jon asked how security came into Feross’s life.

“So the code is the actual source of truth”

Feross Aboukhadijeh, at 14:06

Listen · Feross Aboukhadijeh on episode 36, from 13:56
About 30 seconds: Feross on the written rules, the unwritten rules, and where a hack lives. The clip stops on its own. Read the full transcript.

This page follows the conversation in order: a section for each part of it, nineteen figures, fifteen clips from the tape, a video, the full transcript, and five tools: a quiz, a scorecard for who reads the code your dependencies ship, a calculator for how much code you merge without reading it, a timeline, and a to-do list. Where the decodes of the tape disagree on a word, the transcript puts its best guess in brackets, and the page doesn’t quote those words.

Peer to peer in the browser

Jon opened with the résumé: internships at Intel, Facebook and Quora, a bachelor’s in computer science from Stanford and graduate study there, work as a teaching assistant and section leader, and then a company of his own right away. That company was PeerCDN, a content distribution network built on WebRTC, the browser technology that lets two machines talk directly. Wikipedia describes WebRTC as “a free and open-source project providing web browsers and mobile applications with real-time communication” (Wikipedia). Jon asked whether 2013 was about when WebRTC came out. Feross said it was, and that the browser was what drew him.

“And I felt like each one of these things was going to lead to, like, some type of important new company.”

Feross Aboukhadijeh, at 1:43

He had shipped one browser project before. In September 2010, as a Stanford student and a Facebook intern, he launched YouTube Instant, which let people search YouTube’s videos as they typed, and YouTube’s chief executive, Chad Hurley, offered him a job (Wikipedia).

Yahoo bought PeerCDN. Wikipedia’s list of Yahoo’s acquisitions dates the deal December 17, 2013 (Wikipedia), and Feross’s LinkedIn has him at Yahoo from December 2013 to February 2015, where he “Built fast, mobile-first HTML5 video player and deployed to 1B+ users.” Jon assumed Yahoo had put the peer-to-peer network in front of its users. Feross said the deal went another way.

“it was less them integrating the technology and more us just helping with our skills, to be honest.”

Feross Aboukhadijeh, at 2:12

That, he said, is what led him to leave and work on open source. Yahoo owned PeerCDN’s code, so he started over.

A timeline. September 2010: YouTube Instant, search YouTube as you type, built as a Stanford student and Facebook intern. March 2013, filled: PeerCDN, founder and CEO of a CDN powered by WebRTC. October 22, 2013, filled: WebTorrent, the first release of a torrent client that runs in the browser. December 2013: Yahoo buys PeerCDN, and Feross works there until February 2015. 2015: Standard JS, a style guide, linter and formatter, named as a joke. December 2016: Brave, open source software consultant, bringing WebTorrent into the browser. September 2019: CS 253, visiting lecturer at Stanford, teaching Web Security. June 2020, filled: Socket, founder and CEO. February 1, 2024, filled: episode 36, Feross on this show.
From PeerCDN to Socket in seven years. Sources: Feross's LinkedIn, Wikipedia, TorrentFreak and the tape.

WebTorrent

Before WebRTC, Feross explained, the web was client and server. The browser could only ask, and the server answered with HTML.

“WebRTC gave us the ability to open a socket between my browser and your browser.”

Feross Aboukhadijeh, at 3:28

The idea he got into was BitTorrent over those connections: a swarm of peers, each sharing pieces of a file.

“It was a JavaScript implementation of BitTorrent that used WebRTC as the transport”

Feross Aboukhadijeh, at 3:51

The usual BitTorrent transports, TCP and UDP sockets, don’t work in the browser for security reasons, he said. Wikipedia calls WebTorrent a peer-to-peer “streaming torrent client written in JavaScript that enables BitTorrent functionality directly within web browsers,” and credits Feross as its creator (Wikipedia). His LinkedIn calls it “The first torrent client that works in the browser” and lists him as its author and maintainer from 2013 to 2022.

Two diagrams. Before, client and server: two browsers that can only ask, with arrows up to a filled server that sends back HTML. After, browser to browser: four browsers joined to each other, each sharing pieces of a file. Below: WebTorrent ran BitTorrent over these connections. TCP and UDP sockets, the usual BitTorrent transports, don't work in the browser for security reasons. Then: "WebRTC gave us the ability to open a socket between my browser and your browser." Feross, at 3:28
Client and server, then browser to browser. From Feross on the tape and Wikipedia's articles on WebRTC and WebTorrent.

Ten years on, the project has a community of its own, and the protocol change reached the desktop clients.

“we changed the protocol and they adopted it.”

Feross Aboukhadijeh, at 4:28

Listen · Feross Aboukhadijeh on episode 36, from 4:10
About 35 seconds: WebTorrent ten years on, and the desktop clients that adopted its protocol, uTorrent among them. The clip stops on its own. Read the full transcript.

When you torrent with one of the major clients, including uTorrent, he said, you share with people in browsers too. Jon called it a vision come to fruition: adoption changed how the underlying protocol works.

Torrents like PDFs

Next on Jon’s list: Feross was an open source software consultant for Brave, the browser. His LinkedIn dates the role from December 2016 to December 2021 and describes it in one line: “Integrated my WebTorrent open source project into Brave Browser.” Browsers open a PDF in place, without handing it to another program, Feross said.

“Their idea was, well, what if we did the same thing for torrents?”

Feross Aboukhadijeh, at 5:31

“So now all Brave users have WebTorrent built in to their browser out of the box.”

Feross Aboukhadijeh, at 5:51

TorrentFreak covered Brave’s torrent support on February 19, 2017. “Brave also supports torrent streaming,” it wrote, and it named Feross as the WebTorrent founder who helped build it (TorrentFreak).

Standard, as a joke

Then Standard JS. Feross built it because he was tired of giving style feedback on pull requests to WebTorrent. His own style was the odd one, he said:

“where you omit semicolons in JavaScript to make it look more like Python, and it actually works fine.”

Feross Aboukhadijeh, at 6:20

So he made a library to enforce it, a set of opinionated settings on top of ESLint, the static code analysis tool for JavaScript that Nicholas C. Zakas created in 2013 (Wikipedia). The name came from a script he wrote to see which relevant names were still free on npm. “Standard” was.

“I’ll call it JavaScript Standard Style, as if my style is the standard style that everybody should use, as a joke.”

Feross Aboukhadijeh, at 7:01

Listen · Feross Aboukhadijeh on episode 36, from 6:39
About 30 seconds: how Standard got its name. The clip stops on its own. Read the full transcript.

Two camps formed. His friends and fellow maintainers liked never having to argue style on a pull request again, and never having to configure anything.

“because the other linters require you to write, like, a 200-line config file to get it going, right?”

Feross Aboukhadijeh, at 7:30

The other camp objected to the name.

“You’re not the standards body to be able to say that it’s a standard.”

Feross Aboukhadijeh, at 7:57

That’s the critics’ line, as Feross told it. He answered with an LOL and admitted it was a bit of trolling.

He thinks it became the second most popular style in the JavaScript community, after Airbnb’s, at least when he last checked. His LinkedIn lists him as Standard’s author and maintainer from 2015 to 2022, at “7.5M downloads/month.” Jon’s rule on style is to keep whatever a project already uses. Feross added the teammate who slips a style change into an unrelated pull request, and Jon added the one whose editor restyles every file it opens.

“And you try to find, like, the actual semantic change, and it’s impossible.”

Jon McLachlan, at 9:07

Two cards. The other linters: write a config file of about 200 lines, choose every preference, and copy it into each project you work on. Standard, filled: install standard, its settings are fixed and opinionated, on top of ESLint, so there's nothing to configure and nothing to debate. Below: "I'll call it JavaScript Standard Style, as if my style is the standard style that everybody should use, as a joke." Feross, at 7:01
One install in place of a config file in every project. From Feross on the tape.

CS 253

Jon brought up the course Feross started at Stanford, CS 253, Web Security. Stanford used to teach it when Feross was an undergraduate, and it was his favorite course by far. When he went back for his master’s, it was gone, and he was heartbroken. The final exam is why: a VM running a vulnerable e-commerce website, and the job was a pen test of it.

“And we had 24 hours.”

Feross Aboukhadijeh, at 10:07

“And so I think I found like 13 or 14 vulnerabilities in it.”

Feross Aboukhadijeh, at 10:12

Extra credit went to a bug the instructors hadn’t planted, and he found one of those too.

Listen · Feross Aboukhadijeh on episode 36, from 9:50
About 40 seconds: the 24-hour final exam, and the bug nobody planted. The clip stops on its own. Read the full transcript.
Four cards. The target: a VM running a vulnerable e-commerce website. The time: 24 hours. The planted bugs: 13 or 14, and Feross found them. Extra credit, filled: a bug the instructors didn't plant, and he found one. Below: "And so I think I found like 13 or 14 vulnerabilities in it." Feross, at 10:12
The final exam as Feross describes it. From the tape.

Then Stanford asked him to teach it. He had to rewrite all of it, because the course hadn’t run in about 10 years.

“It’s shocking how much better it is”

Feross Aboukhadijeh, at 10:47

And how much more complicated, he added. Cookies are his example: it used to be enough to explain how they work and how they’re attacked. Now there are the attributes, the settings and the new restrictions for ads and tracking. The course page for Fall 2021 lists him as instructor and calls the course “a comprehensive overview of web security,” from the same-origin policy, cookies and sessions to cross-site scripting, HTTPS, WebAuthn and DNS rebinding (Stanford). His LinkedIn dates the visiting lecturer role from September 2019 to 2023.

The child lock

Jon said he could hear the passion in Feross’s voice, and asked how security came into his life. Feross didn’t know the moment, but he had a story.

“I do remember this one story from my childhood that my parents liked to tell, which maybe shows the security mindset.”

Feross Aboukhadijeh, at 11:28

His parents got a new microwave, and he read the manual, as people did before YouTube. That’s how he found the child lock. When he was mad at his parents, he locked the microwave, and they had to cook on the stove or in the oven. Jon offered another way out:

“and maybe just a bowl of cereal.”

Jon McLachlan, at 12:25

They never learned the code, Feross said. They told him to undo it.

Written and unwritten rules

Feross took the microwave as a start, and maybe a stretch.

“I think security is like a mindset, right?”

Feross Aboukhadijeh, at 12:56

A lot of security people, he said, want to figure out how to break things. He sees a set of rules and sees the exploits, without wanting to use them.

“And you just see them because your mind works that way.”

Feross Aboukhadijeh, at 13:15

Jon called them Easter eggs.

“Things that are there, and they exist, and they were meant to be there”

Jon McLachlan, at 13:22

And they violate the spirit of how the system should work, he said.

Jon said The Matrix captured that spirit. It was one of Feross’s favorite movies growing up, and it gave him the frame.

“But yeah, it’s like there’s the written rules and there’s the unwritten rules.”

Feross Aboukhadijeh, at 13:42

In the case of computers, he said, the specs are the written rules,

“and then the actual code is the unwritten rules.”

Feross Aboukhadijeh, at 14:03

Everyone works from how a system is supposed to work. The exploit sits in the gap:

“you go look at the code, and you find a difference between the written and the unwritten, then that’s an exploit, or that’s a hack.”

Feross Aboukhadijeh, at 14:17

Two cards. The written rules: the specs, what everybody thinks the rules of the system are, and how it's supposed to work. The unwritten rules, filled: the code, the actual source of truth for what you can do with the system. An arrow down to a dashed box: a difference between them, an exploit, or a hack. Below: "you go look at the code, and you find a difference between the written and the unwritten, then that's an exploit, or that's a hack." Feross, at 14:17
The written rules, the unwritten rules, and the gap between them. From Feross on the tape.

Jon agreed, 100%.

“That’s the difference between the expectation and the reality.”

Jon McLachlan, at 14:31

Finding those gaps, he said, is an art that rests on a science: you have to understand how computers work, and then you can still be surprised. The surprises can be security exploits. That was his way into Socket.

Most CVEs are noise

Feross started with what Socket is for.

“Socket is a tool that helps fight vulnerabilities and malware and supply chain attacks”

Feross Aboukhadijeh, at 15:14

The attacks come from your open source dependencies. They built Socket for visibility, defense in depth and proactive protection, he said, because they saw a gap in how people think about dependency security. Most people, and the security industry in general,

“is really obsessed with vulnerabilities”

Feross Aboukhadijeh, at 15:48

Fixing known vulnerabilities is a good baseline, he said. Then Jon raised how many there are, and Feross went further.

“Like, they’re not actually exploitable. The severities are overstated.”

Feross Aboukhadijeh, at 16:12

Vendors have an incentive to find as many as possible, he said, so they can point to thousands of vulnerabilities in their databases. A CVE is an entry in Common Vulnerabilities and Exposures, the reference list for publicly known security vulnerabilities (Wikipedia). His number is a guess, and he says so.

“probably 95% of CVEs are not worth even fixing.”

Feross Aboukhadijeh, at 16:33

Listen · Feross Aboukhadijeh on episode 36, from 16:08
About 40 seconds: why most known vulnerabilities aren't worth the fix, by his estimate. The clip stops on its own. Read the full transcript.

The teams fixing them, he said, are often doing busy work. Jon put a cost on it.

“chasing these CVEs that probably don’t even have any paths from the outside world to be executed or exploited.”

Jon McLachlan, at 16:54

A grid of 100 squares: 5 filled, 95 dashed. Filled: worth fixing, probably 5 in 100, by his estimate. Dashed: noise, not exploitable, severities overstated, or no path from the outside world. Below: "probably 95% of CVEs are not worth even fixing." Feross, at 16:33
Feross's estimate, not a measurement. From the tape.

Five percent a week

The problem Socket solves came from another project first: Wormhole, an end-to-end encrypted file transfer app Feross built with a friend. They didn’t want to see anything their users did, so the security bar was high, and they met it.

“We had really strict code review, a strict content security policy.”

Feross Aboukhadijeh, at 17:27

They chose dependencies with care and ran the standard security tools. A content security policy is a standard that helps prevent cross-site scripting, clickjacking and other code injection attacks (Wikipedia). And still,

“we still had a dependency tree with thousands of dependencies in it.”

Feross Aboukhadijeh, at 17:38

They kept those dependencies current with Dependabot, which opens pull requests to update them. By Feross’s count, something like 5% of the app’s total code changed every week that way, and the app was 90% open source.

“You’re actually churning, like, a huge percentage of your app code every week.”

Feross Aboukhadijeh, at 18:19

And almost everybody, he said,

“doesn’t look at the code that they’re merging.”

Feross Aboukhadijeh, at 18:28

Listen · Feross Aboukhadijeh on episode 36, from 18:15
About 20 seconds: merging dependency updates without reading them. The clip stops on its own. Read the full transcript.

The nagging feeling was that they weren’t doing right by their users. One comparison made it sharp:

“Like, I was reviewing my teammates’ code more closely than I was reviewing the code written by these random people on the internet that were making my dependencies.”

Feross Aboukhadijeh, at 18:45

A bar split in two: open source dependencies, about 90%, filled, and our own code, 10%. Below, a second bar: a filled sliver for about 5% of the total, changed each week by dependency updates. Below: "You're actually churning, like, a huge percentage of your app code every week." Feross, at 18:19, and "doesn't look at the code that they're merging." Feross, at 18:28
Wormhole's code by Feross's numbers on the tape: 90% open source, and about 5% of the whole changing each week.

A juicy target

Jon spelled out the attack this invites. A big company uses a JavaScript library, which depends on three others, one of them lesser known.

“Could you just contribute something into that lesser-known library and introduce a vulnerability or a hiccup”

Jon McLachlan, at 19:51

“for a very juicy target, when you have a lot at stake?”

Jon McLachlan, at 20:04

Five hundred million downloads a month

Feross had felt that from the other side, as a maintainer.

“So I was a maintainer for, like, full-time maintainer for, like, I don’t know, five or six years, full-time just doing this.”

Feross Aboukhadijeh, at 20:16

His code ended up in a great many supply chains.

“So my packages alone are downloaded something like 500 million times per month on npm.”

Feross Aboukhadijeh, at 20:40

“And that’s 100 packages that I have access over.”

Feross Aboukhadijeh, at 20:46

Some maintainers have created 500 or 1,000 packages, he said, and he knows one person whose single account reaches further:

“17% of all downloads on npm are controlled by his one account.”

Feross Aboukhadijeh, at 20:58

He didn’t name him, and called him an amazing maintainer. Jon finished the thought: such a person would never do anything malicious, but

“you lose your laptop or something like that, you can also have a security breach”

Jon McLachlan, at 21:10

Three numbers. 100: packages Feross had access to. 500 million: downloads a month of his packages alone, on npm. 17%: of all downloads on npm, controlled by one maintainer's account. Below: some maintainers have created 500 or 1,000 packages. Dashed: a lost laptop is enough for a breach, Jon points out.
The reach of a maintainer account, by Feross's numbers on the tape.

The event-stream backdoor

The second way in is the handover. New maintainers join projects all the time, Feross said.

“Maybe you get tired of maintaining something and you give it to somebody else to take over. That’s actually very normal and very healthy.”

Feross Aboukhadijeh, at 21:30

The case he remembers best is event-stream. Its maintainer, Dominic Tarr, had written 500-plus packages by Feross’s count, and no longer wanted to maintain this older one, which had millions of downloads a month. Someone offered to take it over, and he said yes, as maintainers normally do.

“They did good changes for about a month, and then they snuck in a backdoor.”

Feross Aboukhadijeh, at 22:22

It was aimed at one company. The attacker knew event-stream sat in a chain of dependencies that company used.

“It was designed to only execute in that particular environment that they wanted to target.”

Feross Aboukhadijeh, at 22:43

The code was heavily obfuscated and used the description of the top-level project as its key.

“use that as a decryption key to decrypt the malware.”

Feross Aboukhadijeh, at 22:58

Listen · Feross Aboukhadijeh on episode 36, from 22:33
About 35 seconds: how the event-stream backdoor stayed hidden from everyone but its target. The clip stops on its own. Read the full transcript.

Everywhere else, decryption failed and nothing happened. In the target’s build, it ran. The target was a crypto wallet app, and its users

“they had, like, all their crypto stolen.”

Feross Aboukhadijeh, at 23:26

On the tape, Feross says the problem first got on his radar in 2017. Wikipedia’s npm article dates the discovery to November 2018: a malicious package, flatmap-stream, had been added as a dependency of event-stream 3.3.6, and it “contained an encrypted payload that stole bitcoins from certain applications” (Wikipedia).

A timeline of six steps. Step 1: the maintainer moves on, Dominic Tarr no longer wants to maintain an older package with millions of downloads a month. Step 2: someone offers to take over, and handing a project on is normal and healthy in open source, Feross says. Step 3: a month of good changes, the new maintainer builds trust. Step 4, filled: a backdoor, per Wikipedia a malicious dependency, flatmap-stream, added to event-stream 3.3.6. Step 5, filled: aimed at one company, it decrypts only in the target's build, which ships a crypto wallet app. November 2018: discovered, as Wikipedia dates it, and Feross says the problem got on his radar in 2017. Below: "They did good changes for about a month, and then they snuck in a backdoor." Feross, at 22:22
The event-stream handover, step by step. From Feross on the tape and Wikipedia's npm article.
A filled box: one obfuscated, encrypted payload in every install of the package. It splits in two. Dashed, everywhere else: the key comes from this project's description, it's the wrong key, decryption fails, and nothing happens. Filled, the target's build: the description is the right key, the malware decrypts and runs, and the wallet app ships with a backdoor. Below: "use that as a decryption key to decrypt the malware." Feross, at 22:58
One payload, two outcomes. From Feross on the tape.

Raise the cost

Jon took the crypto wallet as the rule: money on the line makes you a target.

“You just need to raise the cost of the attack to make that payout not worth it from their perspective.”

Jon McLachlan, at 23:40

Attackers go after the lowest-hanging fruit, he said, and some run a business while others want street cred.

“But in some sense, their time is just as limited as ours”

Jon McLachlan, at 23:57

Every few minutes

People hadn’t seen the opening in open source until around then, Feross said. Socket has watched for it since.

“Socket monitors every new package that’s published to npm, PyPI, and the Go ecosystem.”

Feross Aboukhadijeh, at 24:26

Inside the company there’s a live threat feed of what they catch.

“And it’s like every few minutes there’s stuff we detect, and it’s outright malware.”

Feross Aboukhadijeh, at 24:43

Sometimes someone has compromised a package and added code to it. More often it’s a lookalike name.

“Or the most common attack is actually typosquatting, where they’ll register a name that’s similar to a popular package’s name and hope that people are going to typo the install.”

Feross Aboukhadijeh, at 24:51

Typosquatting began with web addresses: a form of cybersquatting that relies on people’s typos (Wikipedia). Feross has typoed installs himself, and raced to hit Control-C before they finished. Socket’s command line tool takes the race away. It intercepts npm install, and when the package you typed has 10 downloads and one a letter off has 10 million, it points you to the other one.

“And it’ll ask you if you’re sure before you proceed.”

Feross Aboukhadijeh, at 25:27

Two cards. The package you meant: 10 million downloads. One letter off, filled: 10 downloads, registered by an attacker who hopes you typo the install. An arrow down to a box: Socket's command line tool intercepts npm install and asks if you're sure before it goes on. Below: "Or the most common attack is actually typosquatting, where they'll register a name that's similar to a popular package's name and hope that people are going to typo the install." Feross, at 24:51
Two package names one letter apart, with Feross's example numbers from the tape.

One minute with the diff

Jon pictured a static analyzer that flags patterns for a person to check, and asked whether people look. They do.

“Definitely have humans looking at everything that we flag.”

Feross Aboukhadijeh, at 25:57

At this scale, automation comes first, and Feross’s insight came from reading attacks. From 2017 on, each time one happened, he looked at the attack code.

“if somebody just had, like, looked at, for one minute, at this diff, they would see right there in front of their eyes”

Feross Aboukhadijeh, at 26:26

An obvious attack, he said. A giant blob of obfuscated code added to a file.

“Or, oh, look, they’re running eval on a giant base64-encoded string”

Feross Aboukhadijeh, at 26:41

Or a network request that sends off every environment variable the package can read, from a package that never needed the network before. Patch and minor versions are supposed to be small changes. When a patch release asks for new capabilities, that’s the tell.

“suddenly they’re claiming in this patch version that they need all this new permission, right?”

Feross Aboukhadijeh, at 27:18

Listen · Feross Aboukhadijeh on episode 36, from 26:49
About 35 seconds: the red flag of a patch release that suddenly wants the network. The clip stops on its own. Read the full transcript.
Four cards. A giant blob: obfuscated code added to a file. eval at runtime: running a giant base64-encoded string. Secrets out the door: reading every environment variable and sending it to the network. New permissions in a patch, filled: a small release that suddenly needs the network or the environment. Below: "Or, oh, look, they're running eval on a giant base64-encoded string" Feross, at 26:41
What a one-minute look at a malicious diff shows, in Feross's examples from the tape.

Heuristics, then an LLM

Jon summed it up as Socket’s own heuristic for what risk looks like. Feross agreed, and said there’s more, with a caveat.

“and I hesitate to say AI, because everybody uses it as a buzzword in security.”

Feross Aboukhadijeh, at 27:45

For most of security, he said, AI has been a little bit of snake oil. The new large language models are his exception, and Socket started early.

“And we were playing around with GPT-3 back in, before ChatGPT had even come out”

Feross Aboukhadijeh, at 28:10

OpenAI released GPT-3 in 2020 (Wikipedia). Socket used it to explain package behavior. When a package makes a network call, the model is asked:

“what is the reason for this network call?”

Feross Aboukhadijeh, at 28:28

And what data it seems to send. Within a minute of a package being published, the static analysis heuristics run, then the model. If the model is confident enough that the package is malicious, Socket blocks it.

“So we have auto-blocks within minutes of publishing”

Feross Aboukhadijeh, at 29:04

Four boxes joined by arrows. Published, to npm, PyPI or Go. Heuristics, from static analysis. An LLM, which explains the behavior. Blocked, filled, if it's confident. An arrow down to a box: people review everything Socket flags. Below: "So we have auto-blocks within minutes of publishing" Feross, at 29:04
From publish to block, as Feross describes it on the tape.

Three months after this episode aired, Feross went deeper on models and defense on the a16z podcast, with a16z partner Joel de la Garza and Derrick Harris. Socket posted it to YouTube on May 6, 2024.

Feross on the AI + a16z podcast, 39 minutes, posted by Socket Security on May 6, 2024. Watch on YouTube.

Two clicks

Jon guessed Socket was a command line tool. It has one, Feross said, but that isn’t how most people use it.

“most users use our GitHub app.”

Feross Aboukhadijeh, at 29:45

It’s listed in the GitHub Marketplace.

“It’s literally two clicks to install it.”

Feross Aboukhadijeh, at 29:56

There’s no change to CI and no new GitHub Action in each repository. Socket looks at the two moments new third-party code arrives: a pull request that adds a dependency, and one that updates a dependency. And it holds to one rule.

“And we do it where we never want to bother a developer with risk that they didn’t cause themselves in that pull request.”

Feross Aboukhadijeh, at 30:36

Risk already in the codebase is ignored. A typo package or malware blocks the pull request, and a suspicious change gets a warning. Jon liked that. Security done correctly, he said, fits into our daily lives and the processes we already have, and is almost invisible, except when there’s something to flag and an action to take.

Two cards. Already in the codebase, dashed: risky or not, Socket leaves it out of this pull request's comment. Added or updated here, filled: a typo package or malware blocks the pull request, and a suspicious change gets a warning. Below: "And we do it where we never want to bother a developer with risk that they didn't cause themselves in that pull request." Feross, at 30:36
What a pull request comment covers, and what it leaves alone. From Feross on the tape.

As far left as we can

The command line tool still matters, Feross said, because intercepting installs protects the developer’s own laptop before any pull request exists.

“So we can shift left as far left as we can.”

Feross Aboukhadijeh, at 31:55

Further left is the browser. Socket’s Chrome extension works while a developer is still choosing a package. You land on a nice-looking npm package without knowing its transitive dependencies, its maintainer’s reputation, or whether one of them hides data exfiltration. Socket puts what it knows on that npm page,

“if there’s any red flags, right there at the top of the page.”

Feross Aboukhadijeh, at 32:59

The extension writes it plainly: this package uses the network, or this package steals your data. Jon compared it to a phone.

“It’s like those little warning signs that your iPhone will pop up, like, oh, this app wants your location.”

Jon McLachlan, at 33:08

Feross said that’s the analogy Socket uses itself.

“you should be able to know the permissions that your dependencies are using, just like you can on your iPhone.”

Feross Aboukhadijeh, at 33:23

Listen · Feross Aboukhadijeh and Jon McLachlan on episode 36, from 32:55
About 35 seconds: red flags on the npm page, and the iPhone permission prompt as the model. The clip stops on its own. Read the full transcript.
Three boxes joined by arrows: choosing, with the browser extension, filled. Installing, with the command line tool. Merging, with the GitHub app. Below: choosing, red flags at the top of the npm page, such as this package uses the network. Installing: npm install is intercepted, so the laptop is protected before any pull request. Merging: two clicks from the GitHub Marketplace, and every repository is covered. Then: "So we can shift left as far left as we can." Feross, at 31:55
Three places Socket checks a dependency, from the browser to the pull request. From Feross on the tape.

Sold to executives

Jon liked how it fits what developers already do. Feross wished more of the industry thought that way, and had a guess why it doesn’t.

“I think it’s because security software is typically sold to executives.”

Feross Aboukhadijeh, at 33:46

The executives don’t use it. Jon took it from there: close the sale at the top with a couple of demos, and the buyer never touches the pain points under the hood. That sets the company up for a huge inconvenience. In a bottom-up go-to-market, he said, the users, the adopters and the buyers are the same people, and the tool goes from engineers on up the chain. He made it a point about leadership. Dictating solutions violates people’s autonomy, he said, and a leader should ask for them. Having to say you’re the boss leaves a bad taste. If you can’t convince someone smart that it’s right for the company, maybe it isn’t.

“And you have to have the humility, I think, as a leader to understand and appreciate that perspective.”

Jon McLachlan, at 35:41

Listen · Jon McLachlan on episode 36, from 34:40
About 25 seconds: why he favors bottom-up over top-down. The clip stops on its own. Read the full transcript.
Two cards. Top-down: sold to executives with a couple of demos, they don't use the software, and the pain points stay under the hood. Bottom-up, filled: the users, the adopters and the buyers are the same people, and anyone can install it in two clicks, with no call to sales. Below: "I think it's because security software is typically sold to executives." Feross, at 33:46
Top-down and bottom-up, as Jon frames them on the tape.

No talk to sales

Feross said that’s what Socket is trying to do.

“So anyone can install Socket. You can try it out in two clicks”

Feross Aboukhadijeh, at 35:54

No call with sales is required, and Socket also works with CISOs, he said. The bottom-up part helps there: when a head of application security proposes Socket, developers who already use it raise their hands. No tool is perfect, he said, and then he made the case for looking past known vulnerabilities.

“Malware is way worse than the average vulnerability.”

Feross Aboukhadijeh, at 37:04

Most companies do nothing about it, he said, because checking a vulnerability database is easy, so everybody does that.

“The much harder problem is to say, what is this dependency going to do?”

Feross Aboukhadijeh, at 37:21

That, plus being in the developer’s workflow, is his recipe.

Fifteen people

Asked about a typical day, Feross said he spends a lot of it with customers: talking, demoing, helping, and bringing what he hears back to the team.

“And we actually do weekly planning cycles”

Feross Aboukhadijeh, at 38:08

There are monthly and quarterly goals too. Something a customer needs badly can be the next week’s work.

“We’re actually about 15 people right now.”

Feross Aboukhadijeh, at 38:37

“A lot of people think that we’re 50 or 100 people, just because of the rate that we ship stuff”

Feross Aboukhadijeh, at 38:44

The team is all senior people, he said. When TechCrunch covered the next round in October 2024, Socket had 32 employees and planned to reach 50 by the end of the year (TechCrunch).

The best day and the bad days

The best days, Feross said, are new large customers.

“we recently had a big customer switch over to Socket”

Feross Aboukhadijeh, at 39:20

It had used a tool that only does vulnerabilities. A careful company of that size saw a gap and chose Socket to fill it. That matters to a founder, he said,

“because so many startups don’t ever get to product market fit.”

Feross Aboukhadijeh, at 39:51

Jon congratulated him on the Series A.

“I saw on LinkedIn, a 20 million raise”

Jon McLachlan, at 40:06

Zane Lackey led it. Feross called him one of the founders of Signal Sciences, and said he had been an early angel in Socket.

“And then he joined Andreessen Horowitz and then led the investment in Socket.”

Feross Aboukhadijeh, at 40:27

Socket’s own announcement, on August 1, 2023, was “Announcing $20M Series A to Secure Open Source Software,” and it says Zane Lackey “was an early believer in Socket” (Socket). Zane’s post for a16z that day says, “We’re excited to lead Socket’s Series A” (a16z). Signal Sciences is the company Fastly announced it would buy for $775 million in August 2020 (Wikipedia).

Listen · Feross Aboukhadijeh on episode 36, from 40:11
About 30 seconds: the Series A, and the angel who led it. The clip stops on its own. Read the full transcript.

The hard days, Feross said, have been ordinary ones. Nothing dramatic has gone wrong. The bad days are the ones that get by you.

“and then at the end of the day, you feel like, what did I really do today?”

Feross Aboukhadijeh, at 41:08

He’s ready again the next morning, he said. Jon added a sense of compassion for yourself, and one rule:

“there’s no such thing as failure unless you actually, like, give up”

Jon McLachlan, at 41:47

Wormhole first

Jon asked about the founding story, and whether Feross had co-founders. He didn’t.

“I would love to have had a co-founder, I have to say”

Feross Aboukhadijeh, at 42:21

Wormhole, with the same friend, was the company at the start. The plan was a suite like Google Workspace,

“So docs, spreadsheets, notes, emails, all that stuff, that was all end-to-end encrypted.”

Feross Aboukhadijeh, at 42:42

Jon saw the hard part.

“especially because, like, key lifecycle management is extremely complex.”

Jon McLachlan, at 42:51

In a browser it’s harder, Feross said: you fetch only the segments of data you need from the server and decrypt them as you go. So they started with file transfer, and set a bar.

“We wanted it to be better in user experience and better in security”

Feross Aboukhadijeh, at 43:44

Both mattered equally, he said.

The comparison was services like WeTransfer and Firefox Send. Firefox Send was Mozilla’s free encrypted file transfer service, from 2017 to 2020 (Wikipedia). Wormhole is still live at wormhole.app. Its home page today offers end-to-end encryption, a link that expires on its own and up to 10 GB a send, and its footer reads “Protected by Socket.” The first difference on the tape:

“Even before the files are finished uploading to the service, you get this link that you can just go and paste and send to whoever you’re trying to send it to.”

Feross Aboukhadijeh, at 44:22

Jon tried it during the recording.

“It’s like there is a wormhole.”

Jon McLachlan, at 44:46

The second difference is on the receiving end.

“So you could be 1% uploaded, and they’re like, I want to load this file over here.”

Feross Aboukhadijeh, at 45:13

Wormhole reprioritizes the upload to send that file first. And when both people are online, WebRTC connects the two browsers directly.

Listen · Feross Aboukhadijeh on episode 36, from 45:00
About 40 seconds: how Wormhole lets a receiver open files before the upload is done. The clip stops on its own. Read the full transcript.
Three cards. The link comes first, filled: drop the files and get a link at once, and send it before the upload is done. The receiver goes first: at 1% uploaded, the receiver can open any file, and Wormhole sends that one next. Peer to peer: when both people are online, WebRTC connects the two browsers directly. Below: "We wanted it to be better in user experience and better in security" Feross, at 43:44
Two things Wormhole does differently, as Feross describes them on the tape.

Ninety percent of the code

Jon called Socket a pivot to make Wormhole more secure. Feross agreed. They had done everything in their control, he said, except one thing:

“our pile of Node dependencies that were sitting there taunting us.”

Feross Aboukhadijeh, at 46:33

That pile was about 90% of their code, none of it audited, and they had only looked at the other 10%.

“how can we say our app is safe”

Feross Aboukhadijeh, at 46:41

Developers know this, he said, but don’t think deeply about it.

“Like, at the end of the day, it’s going to get all bundled together, and it’s going to run in one process.”

Feross Aboukhadijeh, at 46:59

“No, like, if you’re using it and it’s getting run in your app and it’s all running in the same process, like, it’s your problem.”

Feross Aboukhadijeh, at 47:13

Listen · Feross Aboukhadijeh on episode 36, from 47:07
About 30 seconds: why third-party code in your process is your problem. The clip stops on its own. Read the full transcript.

They asked around, and nobody had a solution.

“They all said, why don’t you use this CVE scanner?”

Feross Aboukhadijeh, at 47:29

“Like, I know that we have zero CVEs.”

Feross Aboukhadijeh, at 47:37

His worry was malware, or a backdoor sending data. It doesn’t even have to be malicious, he said: some maintainers add analytics to learn who uses their package. Jon described opening a browser and watching JavaScript connect to random sites. Wormhole had a content security policy to stop data going anywhere, and they still wanted more layers. That’s defense in depth.

Two boxes join into one. Code you wrote, about 10%, reviewed. Dashed: code from the internet, about 90%, unaudited. Together: one bundle, one process. An arrow to a filled box: your app, your problem. Below: "No, like, if you're using it and it's getting run in your app and it's all running in the same process, like, it's your problem." Feross, at 47:13
One process, whoever wrote the code. From Feross on the tape.

Thirty-nine of forty

So Feross went and asked.

“And then I decided to go out and actually formally interview, like, 40 application security leaders”

Feross Aboukhadijeh, at 48:45

He asked what they thought of the problem, what they did about it today, and whether they cared.

“Actually, 39 out of the 40 told me that they thought this was a top three priority”

Feross Aboukhadijeh, at 49:05

They had no good solution, and it was one of the things that kept them up at night. That gave him the confidence: his team had the problem, the leaders had it, and his team had an idea how to solve it.

Listen · Feross Aboukhadijeh on episode 36, from 48:47
About 40 seconds: 39 of 40 security leaders, and the confidence it gave him. The clip stops on its own. Read the full transcript.

Jon asked about the 40th. Feross wouldn’t name the company, an app people have heard of. Its answer was that they didn’t care about securing dependencies and let developers do what they wanted. He said it has been breached more than once since.

“Well, props for not throwing each other under the bus.”

Jon McLachlan, at 49:57

Budgets constrain people, Jon said. Feross said he doesn’t want to blame people. It was that company’s mindset he was answering.

A grid of 40 squares: 39 filled, 1 dashed. Filled, 39: a top-three priority, with no good solution, and one of the things that kept them up at night. Dashed, 1: didn't care about securing dependencies, and Feross doesn't name the company. Below: "Actually, 39 out of the 40 told me that they thought this was a top three priority" Feross, at 49:05
Feross's interviews before Socket, by his account on the tape.

The Matrix and Waking Life

Jon asked for a book or movie that changed how Feross saw the world.

“The most influential movie for me was when I was a kid and I watched The Matrix”

Feross Aboukhadijeh, at 50:47

Jon said The Matrix was his answer too. The Matrix is the 1999 film written and directed by the Wachowskis (Wikipedia). It got Feross into philosophy.

“How do you know that you’re in reality?”

Feross Aboukhadijeh, at 51:17

It holds up, he said. Both agreed, as a joke, that the sequels don’t exist. His second pick:

“another one that folks might enjoy is a movie called Waking Life.”

Feross Aboukhadijeh, at 52:03

Jon had never heard of it. Feross described interviews with professors and others about existence and experience, drawn over frame by frame.

“And because each picture was drawn individually, it doesn’t line up exactly between the frames.”

Feross Aboukhadijeh, at 52:49

Waking Life is Richard Linklater’s 2001 film, released October 19, 2001, and made with rotoscoping (Wikipedia), an animation technique of tracing over film footage frame by frame (Wikipedia).

Listen · Feross Aboukhadijeh and Jon McLachlan on episode 36, from 52:26
About 30 seconds: Waking Life, drawn over frame by frame. The clip stops on its own. Read the full transcript.

Stay hungry, stay foolish

Jon closed by asking for words of wisdom.

“Stay hungry, stay foolish. There’s a lot of cool stuff out there in the world, and go forth and hack.”

Feross Aboukhadijeh, at 53:18

The first half is borrowed. Steve Jobs ended his June 2005 Stanford commencement speech with it, quoting the farewell message on the back cover of the last 1974 edition of the Whole Earth Catalog (Wikipedia).

What happened after the tape

A $40 million Series B. On October 22, 2024, Socket announced a $40 million round “led by Abstract Ventures, with participation from Elad Gil, Andreessen Horowitz (a16z)” and a group of angels (Socket). TechCrunch put the total raised at $65 million and wrote that Socket had “over 100 customers and protects more than 7,500 organizations” (TechCrunch).

Reachability. On April 23, 2025, Socket bought Coana to bring reachability analysis into the platform, aimed at “cutting false positives, accelerating triage” (Socket). Reachability asks whether your code can reach the vulnerable code at all, which is the question behind Feross’s 95% estimate in Most CVEs are noise.

A free firewall for installs. On September 30, 2025, Socket released Socket Firewall, “a free tool that blocks malicious packages at install time” (Socket). On the tape, the same job belonged to the command line tool that intercepts npm install.

A $60 million Series C. On May 20, 2026, Socket announced “$60 million Series C at a $1 billion valuation, led by Thrive Capital,” which brought its total funding to $125 million (Socket).

Code it never calls. On October 30, 2026, Feross wrote that Socket now protects five of the Magnificent Seven, and that the newest one bought it for precomputed reachability.

Many CVEs in an application's dependencies sit in code it never calls.

Feross Aboukhadijeh · October 30, 2026
Socket computes reachability once for each package version as it's published, he wrote, so a customer needs only an SBOM. View on LinkedIn.

Half the problem. On October 28, 2026, Feross wrote about a Trail of Bits test of 25 package managers against a compromised registry or mirror. Only Go and vcpkg verified the integrity of every package they downloaded.

Integrity is still only half the problem.

Feross Aboukhadijeh · October 28, 2026
The other half, he wrote, is to check what the bytes do when they run. View on LinkedIn.

Three ecosystems, then twenty. On the tape, Socket watched npm, PyPI and Go. A November 4, 2026 post announcing Socket Labs, a research group led by Alexandros Kapravelos, describes a live view across npm, PyPI, Maven, Go and Cargo, and an October 30 post counts 20 ecosystems (LinkedIn).

Twelve of the Fortune 100. In a November 5, 2026 post, Feross wrote that Socket’s protection runs at twelve of the Fortune 100, and that it “also protects the world’s largest company and twenty-two of the Fortune 500” (LinkedIn). On the tape, the team was about 15 people.

Teaching and investing. His LinkedIn dates the Stanford lecturer role from September 2019 to 2023, and lists him as an angel investor and a16z scout since 2022 (LinkedIn).

More on this show. Jack Cable named Feross among the angels in Corridor’s first round on episode 84. Jon told Georgianna Shea about this conversation, which he had just recorded, on episode 48. Neatsun Ziv of OX Security sampled a company’s five million issues and found most of them weren’t relevant, on episode 91. Simon Wijckmans of cside walked through the polyfill.io supply chain attack on episode 54, and Rejah Rehim explained what shifting left means on episode 82.

Did you catch it? A seven-question quiz

Seven questions from the episode. Each answer links the moment in the transcript.

Quiz · seven questions

Did you catch it?

Pick an answer to see whether you caught it.

  1. What does Feross call the specs and the code?

    a. "and then the actual code is the unwritten rules." The specs are the written rules. Transcript, 14:03.

  2. How long was the CS 253 final exam Feross took as an undergraduate?

    b. "And we had 24 hours." The exam was a pen test of a vulnerable e-commerce site. Transcript, 10:07.

  3. What share of CVEs does Feross estimate aren't worth fixing?

    c. "probably 95% of CVEs are not worth even fixing." He calls it a guess. Transcript, 16:33.

  4. How much of Wormhole's code changed each week through dependency updates, by Feross's count?

    a. "You're actually churning, like, a huge percentage of your app code every week." His count is something like 5% of the app's total code. Transcript, 18:19.

  5. How did the event-stream backdoor stay hidden from everyone but its target?

    b. "use that as a decryption key to decrypt the malware." The key came from the top-level project's description. Transcript, 22:58.

  6. Which analogy does Socket use for what a dependency is allowed to do?

    b. "you should be able to know the permissions that your dependencies are using, just like you can on your iPhone." Transcript, 33:23.

  7. Of the 40 application security leaders Feross interviewed, how many called the problem a top-three priority?

    c. "Actually, 39 out of the 40 told me that they thought this was a top three priority" Transcript, 49:05.

Who reads your dependencies?

Eight questions on whether anyone checks what the code you pull in does, from the episode. Each tip quotes the tape or paraphrases it, and links its section.

Scorecard · eight questions

Who reads your dependencies?

Answer for your main product and everything it installs. If two answers fit, pick the lower one.

  1. When a pull request adds or updates a dependency, does anyone check what the new code does?

    • No, we merge the update
    • Someone reads the changelog
    • A tool or a person checks the code's behavior

    Almost everybody, Feross says, "doesn't look at the code that they're merging." See Five percent a week.

  2. What happens when someone installs a lookalike of a popular package?

    • Nothing stops it
    • We would find it later
    • The install is checked before it runs

    Typosquatting is the most common attack Socket sees, Feross says. See Every few minutes.

  3. Would you notice a patch release that suddenly wants the network or your environment variables?

    • No
    • Only if a scanner has a signature for it
    • Yes, new capabilities in a release get flagged

    "suddenly they're claiming in this patch version that they need all this new permission, right?" See One minute with the diff.

  4. How do you decide which CVEs in your dependencies to fix?

    • We try to fix them all
    • By severity score
    • By whether our code can reach them

    Jon's cost: "chasing these CVEs that probably don't even have any paths from the outside world to be executed or exploited." See Most CVEs are noise.

  5. What do your pull request checks report?

    • We have none for dependencies
    • Everything, on every pull request
    • Only the risk this pull request adds

    Socket never wants to bother a developer with risk they didn't cause in that pull request. See Two clicks.

  6. Do you know who can publish the code you run?

    • No
    • For our direct dependencies
    • For the whole tree, and we watch for new maintainers

    "17% of all downloads on npm are controlled by his one account." See Five hundred million downloads a month.

  7. Does your web app limit where its pages can send data?

    • No content security policy
    • A loose one
    • A strict policy, with another layer behind it

    Wormhole had "a strict content security policy" and still wanted defense in depth. See Ninety percent of the code.

  8. What do developers check before they choose a new package?

    • Nothing
    • Downloads and stars
    • Its dependencies, its maintainers and what it does

    Socket's browser extension puts the red flags at the top of the npm page. See As far left as we can.

Merged unread

Code you don't read runs in your process. Start with installs: block lookalike names, and have someone or something read the next dependency update before it merges.

Spot checks

You catch some of it. Next, flag new capabilities in patch releases, triage CVEs by whether your code can reach them, and limit pull request checks to the risk each change adds.

Read before it runs

You know what your dependencies do and who publishes them. Keep the policy strict, and recheck it each time a maintainer changes.

How much code you merge unread

Feross’s number for Wormhole was something like 5% of the app’s total code changing every week through dependency updates. This calculator shows what that means for your app, and how long it would take to read.

Calculator

How much code you merge unread

Three numbers: your app's lines of code with its dependencies, the percent that changes each week, and how many lines a reviewer reads in an hour.

50,000lines of code changed each week
250hours to read them, every week
2,600,000lines changed in a year

With 1,000,000 lines and 5.0% changing each week, 50,000 lines change every week. At 200 lines an hour, reading them takes 250 hours a week, and 2,600,000 lines change in a year.

The 5% is Feross's number for Wormhole, from the tape. The 1,000,000 lines and the 200 lines an hour are placeholders: put in your own numbers.

From PeerCDN to Socket

Feross’s path, Socket’s growth, the supply chain attacks on this page, and the episodes on this site that pick up the thread. Filter by topic.

Timeline

From PeerCDN to Socket

  1. YouTube Instant

    Feross launches search as you type for YouTube (Wikipedia, on this page).

  2. PeerCDN

    Founder and CEO of a CDN powered by WebRTC (LinkedIn).

  3. ESLint

    Nicholas C. Zakas releases the linter Standard later builds on (Wikipedia, on this page).

  4. WebTorrent

    The first release (Wikipedia, on this page).

  5. Yahoo buys PeerCDN

    Feross works at Yahoo until February 2015 (Wikipedia, LinkedIn).

  6. Standard JS

    Feross starts the style guide, linter and formatter (LinkedIn, on this page).

  7. Torrents in Brave

    TorrentFreak reports Brave's torrent streaming, built with Feross's help (TorrentFreak, on this page).

  8. event-stream

    A malicious dependency, flatmap-stream, is found in event-stream 3.3.6 (Wikipedia, on this page).

  9. CS 253

    Feross starts teaching Web Security at Stanford (LinkedIn, on this page).

  10. Socket

    Feross founds the company (LinkedIn, on this page).

  11. Signal Sciences

    Fastly announces it will buy the company Zane Lackey co-founded, for $775 million (Wikipedia).

  12. Series A

    $20 million, led by Zane Lackey at Andreessen Horowitz (Socket, a16z, on this page).

  13. Episode 36

    Feross on the show (Podbean, transcript).

  14. AI + a16z

    Feross on models and supply chain attacks (YouTube, on this page).

  15. Episode 48

    Jon tells Georgianna Shea about this conversation (episode page).

  16. Episode 54

    Simon Wijckmans on the polyfill.io attack (episode page).

  17. Series B

    $40 million, led by Abstract Ventures (Socket).

  18. Coana

    Socket buys a reachability analysis company (Socket).

  19. Socket Firewall

    A free tool that blocks malicious packages at install time (Socket).

  20. Episode 84

    Jack Cable names Feross among Corridor's angels (episode page).

  21. Episode 91

    Neatsun Ziv on five million issues (episode page).

  22. Series C

    $60 million at a $1 billion valuation, led by Thrive Capital (Socket).

  23. Socket Labs

    A research group for supply chain and AI security (LinkedIn).

What to do this week

Five things, in the order of the episode.

  1. Read one dependency update. Open the next pull request that bumps a dependency and look at what changed, then take the scorecard with your team.
  2. Triage CVEs by reach. Ask which ones your code can reach before anyone spends a week on them, as in Most CVEs are noise.
  3. Check installs before they run. Lookalike names are the most common attack Feross sees, as in Every few minutes.
  4. Flag new capabilities in a release. A patch that suddenly wants the network or your environment variables deserves a look, as in One minute with the diff.
  5. Get help with the gates. Our Secure AI SDLC & Engineering work builds review gates and protected branches for the code that lands in your repos, and our AI-Accelerated Vulnerability Remediation Program triages the backlog by reachability. If you want to talk it through, book 15 minutes with us.

Key takeaways

  1. The code is the source of truth

    Feross's frame for security: the specs are the written rules and the code is the unwritten rules. An exploit lives in the difference, and spotting it is the security mindset.

  2. Most CVEs are noise, by his estimate

    Feross guesses that probably 95% of CVEs aren't worth fixing: not exploitable, overstated, or out of reach from the outside world. Teams that chase them all are doing busy work.

  3. You merge more code than you write

    At Wormhole, something like 5% of the app's total code changed every week through dependency updates, and the app was 90% open source. Almost nobody reads that code before merging it.

  4. A maintainer account is a big target

    Feross's packages get about 500 million downloads a month on npm, and one maintainer's account controls 17% of all npm downloads. A lost laptop is enough for a breach, Jon adds.

  5. A handover can be the attack

    The event-stream backdoor came from a new maintainer who made a month of good changes first. It decrypted only in one company's build, a crypto wallet app.

  6. A one-minute look would catch most attacks

    Obfuscated blobs, eval on base64 strings, environment variables sent to the network, and new permissions in a patch release are the tells Feross saw in attack code.

  7. Flag only the risk a change adds

    Socket's GitHub app comments only on risk a pull request introduces, blocks typo packages and malware, and leaves existing risk out of the developer's way.

  8. Know what a dependency can do

    Socket's analogy is the iPhone permission prompt: you should know the permissions your dependencies use. The harder question, Feross says, is what a dependency is going to do.

  9. It's your app, so it's your problem

    Code from the internet runs in the same process as your own. Feross asked 40 application security leaders about it before starting Socket, and 39 called it a top-three priority.

Chapters

Tap a chapter to play from there.

Pull quotes

“So the code is the actual source of truth”

Feross Aboukhadijeh ·

“But yeah, it's like there's the written rules and there's the unwritten rules.”

Feross Aboukhadijeh ·

“That's the difference between the expectation and the reality.”

Jon McLachlan ·

“And I felt like each one of these things was going to lead to, like, some type of important new company.”

Feross Aboukhadijeh ·

“WebRTC gave us the ability to open a socket between my browser and your browser.”

Feross Aboukhadijeh ·

“I'll call it JavaScript Standard Style, as if my style is the standard style that everybody should use, as a joke.”

Feross Aboukhadijeh ·

“And so I think I found like 13 or 14 vulnerabilities in it.”

Feross Aboukhadijeh ·

“I think security is like a mindset, right?”

Feross Aboukhadijeh ·

“Socket is a tool that helps fight vulnerabilities and malware and supply chain attacks”

Feross Aboukhadijeh ·

“Like, they're not actually exploitable. The severities are overstated.”

Feross Aboukhadijeh ·

“chasing these CVEs that probably don't even have any paths from the outside world to be executed or exploited.”

Jon McLachlan ·

“We had really strict code review, a strict content security policy.”

Feross Aboukhadijeh ·

“Like, I was reviewing my teammates' code more closely than I was reviewing the code written by these random people on the internet that were making my dependencies.”

Feross Aboukhadijeh ·

“So my packages alone are downloaded something like 500 million times per month on npm.”

Feross Aboukhadijeh ·

“They did good changes for about a month, and then they snuck in a backdoor.”

Feross Aboukhadijeh ·

“It was designed to only execute in that particular environment that they wanted to target.”

Feross Aboukhadijeh ·

“You just need to raise the cost of the attack to make that payout not worth it from their perspective.”

Jon McLachlan ·

“And it's like every few minutes there's stuff we detect, and it's outright malware.”

Feross Aboukhadijeh ·

“Or, oh, look, they're running eval on a giant base64-encoded string”

Feross Aboukhadijeh ·

“most users use our GitHub app.”

Feross Aboukhadijeh ·

“And we do it where we never want to bother a developer with risk that they didn't cause themselves in that pull request.”

Feross Aboukhadijeh ·

“So we can shift left as far left as we can.”

Feross Aboukhadijeh ·

“The much harder problem is to say, what is this dependency going to do?”

Feross Aboukhadijeh ·

“We wanted it to be better in user experience and better in security”

Feross Aboukhadijeh ·

“No, like, if you're using it and it's getting run in your app and it's all running in the same process, like, it's your problem.”

Feross Aboukhadijeh ·

“Stay hungry, stay foolish. There's a lot of cool stuff out there in the world, and go forth and hack.”

Feross Aboukhadijeh ·

About the guest

Feross Aboukhadijeh, Founder and CEO, Socket

Feross Aboukhadijeh founded Socket in June 2020 and is its CEO. Before Socket he founded PeerCDN, a CDN powered by WebRTC that Yahoo bought in December 2013, worked at Yahoo until February 2015, created WebTorrent, the first torrent client that works in the browser, and created Standard JS. He helped bring WebTorrent into the Brave browser as an open source software consultant from December 2016 to December 2021, and taught CS 253, Web Security, at Stanford as a visiting lecturer from September 2019 to 2023. He joined Jon McLachlan on episode 36, published February 1, 2024.

About the host

Jon McLachlan is co-founder of YSecurity, the on-demand cybersecurity team for startups, and of Cyberbase.ai. The Security Podcast of Silicon Valley is hosted by Jon McLachlan and Sasha Sinkevich. Jon McLachlan on LinkedIn ↗

Context and sources

  • Episode 36 on Podbean, February 1, 2024, with show notes on Feross's internships at Intel, Facebook and Quora, PeerCDN, and Socket's work on software supply chain vulnerabilities with heuristic analysis and LLMs. Source ↗
  • Feross Aboukhadijeh's LinkedIn experience: Socket from June 2020, a16z scout from 2022, Stanford from 2018, Standard JS from 2015, WebTorrent from 2013, Brave from December 2016, Yahoo from December 2013 and PeerCDN from March 2013. Source ↗
  • Socket, by Feross Aboukhadijeh, August 1, 2023: a $20 million Series A led by Andreessen Horowitz, with Zane Lackey leading the round. Source ↗
  • a16z, by Zane Lackey, Investing in Socket, August 1, 2023: a16z leads Socket's Series A, and Feross is the original author of WebTorrent and Standard JS. Source ↗
  • Socket, by Feross Aboukhadijeh, October 22, 2024: a $40 million Series B led by Abstract Ventures, with Elad Gil and Andreessen Horowitz. Source ↗
  • TechCrunch, by Kyle Wiggers, October 22, 2024: Socket had raised $65 million, had over 100 customers and protected more than 7,500 organizations, with 32 employees. Source ↗
  • Socket, by Feross Aboukhadijeh, April 23, 2025: Socket acquires Coana to bring reachability analysis into the platform. Source ↗
  • Socket, by Dale Bustad, September 30, 2025: Socket Firewall, a free tool that blocks malicious packages at install time. Source ↗
  • Socket, by Feross Aboukhadijeh, May 20, 2026: a $60 million Series C at a $1 billion valuation, led by Thrive Capital, for $125 million in total funding. Source ↗
  • Feross Aboukhadijeh on LinkedIn, October 30, 2026: Socket's precomputed reachability, and many CVEs in dependencies sit in code an application never calls. Source ↗
  • Feross Aboukhadijeh on LinkedIn, October 28, 2026: a Trail of Bits test of 25 package managers, and why integrity checks are only half the problem. Source ↗
  • Feross Aboukhadijeh on LinkedIn, November 4, 2026: Socket Labs, a research group led by Alexandros Kapravelos, with a live view of packages across npm, PyPI, Maven, Go and Cargo. Source ↗
  • Feross Aboukhadijeh on LinkedIn, November 5, 2026: Socket's protection runs at twelve of the Fortune 100 and twenty-two of the Fortune 500. Source ↗
  • Stanford, CS 253 Web Security, Fall 2021: a comprehensive overview of web security, with Feross Aboukhadijeh as instructor. Source ↗
  • TorrentFreak, by Ernesto Van der Sar, February 19, 2017: Brave supports torrent streaming, with support from WebTorrent founder Feross Aboukhadijeh. Source ↗
  • Wikipedia, npm: in November 2018 a malicious package, flatmap-stream, was found as a dependency of event-stream 3.3.6, with an encrypted payload that stole bitcoins from certain applications. Source ↗
  • Wikipedia, WebTorrent: a peer-to-peer streaming torrent client written in JavaScript, created by Feross Aboukhadijeh, first released October 22, 2013. Source ↗
  • Wikipedia, YouTube Instant: launched in September 2010 by Feross Aboukhadijeh, then a Stanford student and Facebook intern. Source ↗
  • Wikipedia, List of mergers and acquisitions by Yahoo: PeerCDN, December 17, 2013. Source ↗
  • Wikipedia, Fastly: in August 2020 Fastly announced it was acquiring Signal Sciences for $775 million. Source ↗
  • Wikipedia, ESLint: a static code analysis tool for JavaScript, created by Nicholas C. Zakas and released June 30, 2013. Source ↗
  • Wikipedia, Typosquatting: the definition. Source ↗
  • Wikipedia, Whole Earth Catalog: Steve Jobs ended his June 2005 Stanford commencement speech with its farewell message, Stay hungry. Stay foolish. Source ↗

Transcript

Automatic transcription. Jon McLachlan hosts this episode with Feross Aboukhadijeh, the founder and CEO of Socket. There is no diarization on the tape, so speaker labels were assigned from the content and checked against reference recordings of each voice from this episode and by pitch, and a few short lines may sit with the wrong speaker. Names and terms were normalized where the recognizer misheard them (Jon McLachlan, Feross Aboukhadijeh, Quora, PeerCDN, WebRTC, WebTorrent, BitTorrent, uTorrent, Brave, Standard JS, ESLint, npm, PyPI, CS253, typosquatting, Dependabot, protestware, GPT-3, ChatGPT, Zane Lackey, Signal Sciences, Andreessen Horowitz, Wormhole, WeTransfer, Firefox Send, Waking Life). Words in [brackets] are best guesses where the audio is unclear. Answers are transcribed as spoken, with most repeated words and false starts kept. Short backchannels such as "yeah" and "right" are left out where they overlap the other speaker.

Read the full transcript 10,331 words

Jon McLachlan

Hello, everyone, and welcome to another episode of the Security Podcast in Silicon Valley. I'm here today with Feross Aboukhadijeh. Did I get your name right?

Feross Aboukhadijeh

Yeah, you did.

Jon McLachlan

Perfect. Awesome. He's the founder and CEO of Socket, a cybersecurity platform that protects companies' software supply chain against attacks. Specifically, I think JavaScript, right?

Feross Aboukhadijeh

We actually do more than JavaScript now. We've added Python and Go, and we're on a roll continuing to add more. But yeah, we started in JavaScript because that's where most of the worst offending open source code tends to be.

Jon McLachlan

It looks like you are an intern at Intel, at Facebook, at Quora, all big-name companies I'm sure everyone is familiar with. You have a bachelor's of science in computer science from Stanford. And you also [did] some graduate studies there. Not to mention, looks like you really took a leadership role in Stanford, being a teaching assistant, section leader. And then you started to found your own companies, like, right away. You have PeerCDN, which is a next-generation content distribution network that's powered by WebRTC, that facilitates efficient peer-to-peer content delivery. That sounds awesome. You did that way back in 2013. That's right around the time, like, WebRTC, like, came out, wasn't it?

Feross Aboukhadijeh

Yeah. Yeah, I was fascinated with the web browser and all the new capabilities that were getting added into it. And WebRTC, WebGL, there was all this stuff that is so exciting. And I felt like each one of these things was going to lead to, like, some type of important new company. So I wanted to work on, work with WebRTC, because peer-to-peer is cool and distributed systems are cool. And yeah, so PeerCDN was what we built.

Jon McLachlan

And you ended up selling this company to Yahoo, and you went over to Yahoo for a while and helped integrate and build, I assume, like, your peer-to-peer WebRTC CDN into their ecosystem for a billion plus users?

Feross Aboukhadijeh

Yeah, it was less them integrating the technology and more us just helping with our skills, to be honest. So I was hoping they'd end up using the tech a bit more. And that's actually what led to me leaving and working on open source afterwards. I really wanted to take the, some of the insights from PeerCDN, and I really wanted them to see the light of day. And after Yahoo had acquired PeerCDN, it wasn't possible, it wouldn't have been possible to use that technology anymore. So I started from scratch on WebTorrent, which I think you were about to get to.

Jon McLachlan

Yeah. So you were an open source software developer on WebTorrent. What was that like?

Feross Aboukhadijeh

Yeah, WebTorrent is basically a way to share data directly from one browser to another. And WebRTC was the first, really made it so that for the first time you could do that. You could actually connect directly from my computer to your computer without going through a server. And before that, the web was very, like, clients, it was designed to be a client-server model, where you have a server, an HTTP server, and you have these browsers that are basically subservient clients that can only make requests to the servers, and then the servers send back HTML. And that's basically the model. But WebRTC gave us the ability to open a socket between my browser and your browser. And so there's all these ideas of what you can do with it. The idea that I got really into was being able to do BitTorrent over those connections. So building up, like, a network of peers that are swarming around a file and sharing bits of it, and the whole BitTorrent story that people might know about how that works. And so that was what WebTorrent was. It was a JavaScript implementation of BitTorrent that used WebRTC as the transport, instead of the traditional, like, TCP or UDP sockets that BitTorrent used before, because those don't work in the browser for security reasons.

Jon McLachlan

Yes.

Feross Aboukhadijeh

Yeah, it's been a great project. I worked on it for a really long time, but now, after, I don't know, it's been like, I guess, going on 10 years or so, yeah, since I started it, there's a whole bunch of other people working on it now. It's not just me, there's an awesome community. And now it's built into even the official BitTorrent clients. Like, they adopted the, we changed the protocol and they adopted it. And now, when you torrent stuff, you're actually, in any of the major clients, including uTorrent, the big one from the official company, you're actually sharing that content with browser peers. So people who are on websites that are trying to download that content will connect to your BitTorrent app. So it's really cool. It's, that was the vision, and now it's actually realized.

Jon McLachlan

So to see it come to fruition is, it sounds very special. Like, that success right there, like, adoption of the technology, and changed the ecosystem of how the underlying protocol works, right?

Feross Aboukhadijeh

Mm-hmm.

Jon McLachlan

And you also spent some time as an open source software consultant with Brave.

Feross Aboukhadijeh

The newer browser. I'm not going to say new anymore, because they've been around for a while, but Brave team is awesome. They've been trying to innovate in the browser space in a big way. And one of the things they wanted to do was make it so, just like how when you view a PDF file in your browser these days, most browsers will just show you the PDF. They won't kick you out to an external application to handle it. Their idea was, well, what if we did the same thing for torrents? So you click on a torrent link. Why is that kicked out to some external app? What if we just loaded it directly in the browser? And so they used WebTorrent to do that. And so I was helping them integrate it.

Jon McLachlan

Oh, nice. And so you're helping bring the WebTorrent stuff into the Brave browser ecosystem.

Feross Aboukhadijeh

Correct. Yeah. So now all Brave users have WebTorrent built in to their browser out of the box.

Jon McLachlan

And you've also spent time helping with Standard JS.

Feross Aboukhadijeh

Yeah. So Standard JS was a project to help with the code style of PRs that we were getting to the WebTorrent project. So I just got tired of giving style feedback to people, like, hey, this is a great change, but can you please change? I have a kind of weird coding style, or it was weirder in the past, but it's gotten more normal, where you omit semicolons in JavaScript to make it look more like Python, and it actually works fine. And so things like that, I got tired of giving that feedback in all of our pull requests. And so I just made a library to, to enforce that. It's built on ES, yeah, it's built on another linter underneath the hood called ESLint, but it basically is an opinionated set of settings. And the kind of funny story behind the name is that I was going to call it something like [Feross] style, or just some random name, some random package name. And then I wrote a little script to see, like, what names were available on npm that were relevant potentially to this type of a project. And the name standard came up as being available. And I thought that, I was like, oh, this will be funny. I'll call it JavaScript Standard Style, as if my style is the standard style that everybody should use, as a joke. And then people actually, so there were two reactions to this. First of all, all my friends, like a bunch of my friends and fellow open source maintainers, were like, oh, this is amazing. Like, now I never have to give feedback on PRs anymore. Like, I don't really care whether your style is, whether I agree with every decision. I just like that there's a tool that I don't have to configure, because the other linters require you to write, like, a 200-line config file to get it going, right? And to select what your preferences are. And then you have to copy that into every project you work on. And so I inadvertently solved that problem in an easy way for people, where they would just install standard and then...

Jon McLachlan

And you gave it a very descriptive name. It's just like, okay, here's where we're going to start. It's the standard.

Feross Aboukhadijeh

Yeah. Right. Exactly.

Jon McLachlan

Very [good].

Feross Aboukhadijeh

Yeah. And then a bunch of other people were like, hey, that's not cool. You're not the standards body to be able to say that it's a standard. And I'm like, yeah, well, like, LOL, like, that's what I'm doing. And then, you know, it's just, it was, it was a bit of trolling going on. But that people, yeah, a bunch of people liked it. And I think it's like the second most popular style now after Airbnb's style in the JavaScript community. At least it was last I checked. I don't know what it is now. But yeah. So it was pretty cool. And people really get a lot of value from not having to have those style debates on their teams anymore by using it.

Jon McLachlan

Yeah. That's the main kicker for me. Every time we have a discussion around style, it's like, well, what's already there? And let's just keep using whatever it is. And I'm not really going to be dogmatic about where I think things should go. I'm usually stepping into a project or code that already exists, and just [always maintain it].

Feross Aboukhadijeh

Yeah. Yeah, and there's always the teammates who want to go in and, like, tweak it to, like, they're like, they'll sneak [in] a change into the style in some other unrelated pull request.

Jon McLachlan

Oh, or they go into their IDE and they have a slightly different style configuration, and every file that they look at, like, automatically gets restylized. And then their pull requests are just massive, like, [off]. And you try to find, like, the actual semantic change, and it's impossible. So it's funny. And now you're not only the founder and CEO of Socket, but you're a visiting lecturer at Stanford University. Looks like you started the course Web Security, CS253.

Feross Aboukhadijeh

Yeah, so Stanford used to teach this course when I was an undergrad, and it was my favorite course, like, by far. Just, it was my introduction to web security, and I just loved it. And when I went back to do my master's, they had stopped teaching it. And so I was, I was heartbroken, because I was like, this was the best. This was like, this was so fun. This was, it was one of these classes that was so special. Like, literally, the final exam was, here is a VM running a vulnerable e-commerce website server on it. And you're, and we were supposed to basically run this thing and find every possible way to hack, basically to do a pen test of this e-commerce site. And we had 24 hours. It was so fun. Like, I've never had a final exam that was that cool and that fun. And so I think I found like 13 or 14 vulnerabilities in it. And I think one of them, you would get extra credit if you found something that wasn't, wasn't already known. What wasn't already known. Yeah. So they, because they had added those in. They added like those 13 or 14 in, and I found like one that wasn't inserted by them. And that was, that just felt really cool to be doing that in school. And so I loved it. And then they said, why don't you teach it? And so I had to redo all the content, because it's been, it had been like 10 years since it had been taught, and web security has moved on.

Jon McLachlan

It changes big time over the course of 10 years, doesn't it?

Feross Aboukhadijeh

Yeah. It's shocking how much better it is, like, and also how much more complicated it is. Just the number of, you can't just explain, oh, here's how cookies work, and here's all these, like, attacks you can do with them. It's like now you have to explain all the attributes and all the different settings that affect how they work, and all the, like, new restrictions for ads and tracking. And it's like insanely more complicated than it was back then, but more secure, hopefully, after all this work.

Jon McLachlan

How did [you] get into security? I really hear the passion in your voice when you're describing these things. And it must have, was, is there a story about how it crept into your life and became important to you?

Feross Aboukhadijeh

I mean, I don't know the moment it happened. I do remember this one story from my childhood that my parents liked to tell, which maybe shows the security mindset. I don't know if it's a stretch, maybe, but yeah, well, this is when I was, like, really young. Like, I think I was like five or six or something. And I learned, my parents had got this new microwave, and I took the manual for the microwave. And I used to love reading manuals back then, because there wasn't YouTube, there wasn't the internet. You weren't overloaded with content. So when you could learn about something, you got a new product or whatever, you'd read the manual. I don't know if people, like, remember those days, but you'd, like, you'd read it because you'd like, I want to know about this thing. And there's no Google searches or YouTube videos or podcasts or whatever where people are going to be talking about this stuff. You'd read it. So I read the manual and I learned that there's this child lock feature. And child lock lets you lock the microwave unless you put in, this, hit a special sequence of buttons. And so I would use that on my parents whenever I was mad at them. I'd lock the microwave, and then they couldn't cook or use it.

Jon McLachlan

Oh, they couldn't use the microwave. And instead, they had to cook, like, the old-fashioned way, in the stove and the oven, and maybe just a bowl of cereal.

Feross Aboukhadijeh

Yeah, exactly. So I definitely remember doing that a lot. And I don't know if that's a security...

Jon McLachlan

Did they figure it out? Like, did they, like, oh, it's locked again? All right, what's the code?

Feross Aboukhadijeh

They would just yell at me and say, like, unlock the microwave. And it's like, no, like, [I'm mad at you].

Jon McLachlan

No, it sounds like a healthy dynamics that I'm sure a lot of our listeners could share with, in terms of related to their parents as well.

Feross Aboukhadijeh

Yeah. So that was, I guess, like, like the start, but I don't know. I think security is like a mindset, right? I think you, it seems like a lot of security people have this devious mind, where they want to always, like, figure out how to break things in a way. I don't know if that's everybody, but I definitely see a set of rules and you think, oh, well, what, not that I necessarily want to go and exploit these, but like, what are the exploits there? And you just see them because your mind works that way.

Jon McLachlan

And yeah, yeah, they're like little Easter eggs, [maybe]. Things that are there, and they exist, and they were meant to be there, and they, like, violate, like, the spirit of how the system should be working.

Feross Aboukhadijeh

Yeah, exactly, exactly.

Jon McLachlan

Like the movie The Matrix or something, like, it's captured some of that spirit, like, pretty well.

Feross Aboukhadijeh

Yeah, exactly. And that was one of my favorite movies growing up. Like, probably a bunch of the listeners. But yeah, it's like there's the written rules and there's the unwritten rules. The written rules are what everybody thinks are the rules of the system. And everybody hopes that, like, that's the rules that are governing things. But there's usually a separate set of rules. And in the case of computers, you could think of it like the specs are the written rules, and then the actual code is the unwritten rules. So the code is the actual source of truth for, like, what you're going to be able to do with a system. But everybody's operating in this, like, realm of, like, well, here's, this is how it's supposed to work. But actually, if you just go look at the unwritten rules, you go look at the code, and you find a difference between the written and the unwritten, then that's an exploit, or that's a hack. And that's like, that, spotting that is like what it means to, like, have a security mindset, I think.

Jon McLachlan

I agree totally, 100%. That's the difference between the expectation and the reality. And there's little hiccups, I would say, like, between those two. And discovering those, like, there's an art to that, right? You have to understand, like, the mechanics, and there's a science to how, like, computers work. And we, to be good at that art, you have to understand the basics. But within that space, you can be surprised. And those little surprises, they can be little security exploits. So what are some of the surprises that Socket helps prevent or mitigate the risk around, speaking of security exploits? And so what does Socket do exactly, for just our community listeners?

Feross Aboukhadijeh

Yeah, yeah. Socket is a tool that helps fight vulnerabilities and malware and supply chain attacks that come from your open source dependencies. So we built it to provide visibility, defense in depth, and proactive protection from attacks that originate in your dependencies. So basically, the reason we started Socket was we saw a gap in the way that people were thinking about their dependency security. So they, you know, most people, and I would say actually the security industry in general, is really obsessed with vulnerabilities, and trying to get rid of vulnerability, known vulnerabilities. And that makes some sense, right? They're a good, they're a good baseline. Fixing vulnerabilities is a good thing, right? I'm not saying it's not, but...

Jon McLachlan

That's [overwhelming]. You have so many, maybe, sometimes.

Feross Aboukhadijeh

Yeah, exactly. There's so many. And a lot of the time, they're pretty low value. Like, they're not actually exploitable. The severities are overstated. And there's definitely an incentive in the industry to find a bunch of these, as many as possible, so that these vendors can say, oh, look, like, we have thousands and thousands of vulnerabilities that are in our database. But in terms of the security impact, I would guess or estimate that probably 95% of CVEs are not worth even fixing. Like, they're just noise. And the teams that are spending their time fixing these are just doing busy work a lot of the time.

Jon McLachlan

And you're just burning, like, the capital of whatever company you happen to be in, if you're spinning your wheels, like, running down these rabbit holes, chasing these CVEs that probably don't even have any paths from the outside world to be executed or exploited.

Feross Aboukhadijeh

Yeah, exactly. And so we, I was working on a project, another, and this is actually another website that I had built before Socket, which is called Wormhole. And my friend and I were building it. And the idea is it's an end-to-end encrypted file transfer application. So it had high security requirements. We didn't want to see anything about what our users were doing on the service. And we did everything right in terms of security. We had really strict code review, a strict content security policy. We were very careful when choosing our dependencies. We used all the standard security tools. We did all this stuff, but we, despite all this, we still had a dependency tree with thousands of dependencies in it. And probably a lot of the listeners are familiar with this problem. It's a particularly bad problem in JavaScript and npm, where you end up with just these huge dependency trees. And it was something like, we were using Dependabot, I think, to keep them up to date as well, and to help fix CVEs. And a lot of folks are probably familiar with that.

Jon McLachlan

Yeah, you're doing the right thing there, right? Or trying to.

Feross Aboukhadijeh

Yeah. Yeah. But something like 5% of our app's total code, lines of code, [were] churning every week by doing that. And so if you think about that, like, your app is 90% open source, and you're merging these PRs all the time that are changing the dependency versions, right? You're actually churning, like, a huge percentage of your app code every week. And most people, I would say almost everybody, like, probably literally everybody, doesn't look at the code that they're merging. They're just clicking merge on those PRs and letting those dependencies just change, and assuming that it's going to be better. And so we had this nagging feeling that we weren't doing right by our users by doing that. And so, and we also realized we were reviewing our own code. Like, I was reviewing my teammates' code more closely than I was reviewing the code written by these random people on the internet that were making my dependencies. And I felt like there was something off about that as well.

Jon McLachlan

Right. No, that, okay, so the problem makes sense. We have all of this code out there. We want to use all of the great work that has been laid down as a foundation that we can build on top of. Often that shows up as open source projects, and it doesn't even matter if you're using, like, JavaScript or Go or Java or whatever, Python, like, you're pulling in all of these dependencies from the open source community, which is great. But it also opens up the possibility of, like, well, what if something malicious ends up coming into your project? And a really scary piece is, like, okay, well, if you're at a big company, and someone knows that you're using a very particular, like, JavaScript library, and that library depends on three other libraries that are all open source as well, and one of them is, like, maybe lesser known. Could you just contribute something into that lesser-known library and introduce a vulnerability or a hiccup or, and really have, like, a targeted attack for something, for a very juicy target, when you have a lot at stake?

Feross Aboukhadijeh

I felt this effect myself, because I was a maintainer of WebTorrent and all these other libraries that I ended up writing while I was working on that project. So I was a maintainer for, like, full-time maintainer for, like, I don't know, five or six years, full-time just doing this. And I ended up being in, having my code in so many people's supply chains. And I was a random 20-something, and I cared about security and I was doing my best. But just thinking about how far that reach was that any random maintainer has into almost every company's supply chains, it's pretty massive. So my packages alone are downloaded something like 500 million times per month on npm. And that's 100 packages that I have access over. There are people who have access, who have created way more than that, like 500 or 1,000. And there's one person I know who actually has, 17% of all downloads on npm are controlled by his one account. He's an amazing maintainer, but...

Jon McLachlan

I'm sure he's an amazing individual too, and, like, would never do anything malicious. But, like, in the off case, like, you lose your laptop or something like that, you can also have a security breach, perhaps, that way.

Feross Aboukhadijeh

Right. So there's that aspect. And then there's also just dependencies getting compromised by their maintainers. So it's very normal in open source that over time, new maintainers are added to help contribute to the project. Maybe you get tired of maintaining something and you give it to somebody else to take over. That's actually very normal and very healthy. But there's been cases that, the most famous one that I remember, started, it was in 2017 when it first got on my radar that this was a problem, was a package called event-stream was compromised. And the story behind it was, this maintainer named Dominic Tarr was not interested in maintaining this library anymore. He was one of these really prolific folks. He had, I think, something like 500-plus packages that he had written. Very creative person. But this was one of his older ones, and it had been used by millions of downloads per month. And someone approached him and said, I'd love to take over maintenance of it. And he did what you normally do, which is you say, yeah, I'm not, yeah, I'm not taking, I'm not using it, I'm not taking care of it anymore. Sure, here's the person was nefarious. They waited a month. They did good changes for about a month, and then they snuck in a backdoor. And this was very hyper-targeted to one particular company.

Jon McLachlan

Right. Okay.

Feross Aboukhadijeh

They literally did. They did exactly what you described. They literally knew that this dependency was in a chain of dependencies that was used by the company they wanted to attack. And they put in a backdoor. And the way they did it was super sneaky. It was designed to only execute in that particular environment that they wanted to target. So nobody noticed it. It was heavily obfuscated, and it used, it basically used the name of the description of the top-level project. So it would pull that out and use that as a decryption key to decrypt the malware. And so what that meant was everybody else who was running it would fail to decrypt and nothing would happen. But in that one environment...

Jon McLachlan

Yeah, you had the wrong key.

Feross Aboukhadijeh

Yeah. And so it was very clever. And it led to, it basically caused this company's desktop app that they built to get backdoored, and they shipped it out to all their users, and then a bunch of users were affected. And in that case, it was a crypto wallet, and so they had, like, all their crypto stolen. Typical, right? Crypto stories.

Jon McLachlan

But when you have money on the line, like, you become a target, right? It's the theme. Hackers, they run a business too, and they go after the lowest-hanging fruit. And oftentimes, you don't need to have a perfect solution. You just need to raise the cost of the attack to make that payout not worth it from their perspective. It's maybe a, I don't know, that's one way to think about, like, folks that go after hacks and that hacker mindset. But in some sense, their time is just as limited as ours, and, you know, they're running a business. Some of them are running a business. Some of them are, they do it for, like, the street cred or the respect or whatever you want to call it.

Feross Aboukhadijeh

Yeah. Yeah. And in this case, I think people hadn't paid much attention to, like, in the past, they weren't really aware of the massive opportunity in open source, like, for their attacks. And so people started realizing it around that timeframe. And since then, we've, we now, Socket monitors every new package that's published to npm, PyPI, and the Go ecosystem. Those are the three [things] we do today. And we see, it's like every few minutes, we have a live threat feed in our kind of internal company dashboard that shows us, like, all the stuff we're catching and [blocking]. And it's like every few minutes there's stuff we detect, and it's outright malware. It's literally someone compromised a package and added something to it. Or the most common attack is actually typosquatting, where they'll register a name that's similar to a popular package's name and hope that people are going to typo the install.

Jon McLachlan

Just typo the install. Yeah.

Feross Aboukhadijeh

Yeah. And I've done that before. I've actually typoed installs before, but I've, I always rush as fast as I can to hit Control-C and cancel the install. And now, now that's one of the things Socket can help with, is you don't have to do that anymore. It'll actually intercept the npm install and tell you, hey, it looks like the thing you're installing has 10 downloads, and there's a package that's one letter off, that's one letter different, that has 10 million downloads. Like, maybe you meant that one instead. And it'll ask you if you're sure before you proceed.

Jon McLachlan

That's [unclear]. So, to Socket, so Socket, what it does is it takes all of the open source community contributions, and it runs it through a static analyzer. It looks for known, like, malware patterns. And then does it do any, like, dynamic analysis? Or how does it, how does it flag something as, like, interesting, or raise it for maybe a human to go look at? And do you guys look at them yourselves too, like, when they get flagged?

Feross Aboukhadijeh

Yeah, we do that. Definitely have humans looking at everything that we flag. But before that, we also have a lot of automation involved here. So we have to analyze every package in all these ecosystems in real time. And it's, the scale is so massive. So, like, what we want, what I can share, the insight here was, we looked at, I started seeing these supply chain attacks happening in the ecosystem starting in 2017. And every time one of these would happen, I'd look at the attack code, and I'd say, my goodness, if somebody just looked at this, if somebody just had, like, looked at, for one minute, at this diff, they would see right there in front of their eyes, like, a very obvious attack. Like, it's like there's a giant blob of obfuscated code added to this file. Like, it's obvious that something is weird about that. Or, oh, look, they're running eval on a giant base64-encoded string, like, to, at runtime, like, run this clearly obfuscated code. Or they're making a network request and reading the entire list of environment variables in the package and sending that off to the network. And before this version of the package, they never needed the network. They never needed to access the environment variables. It was a completely different, the package never needed those permissions, in some sense, right? It never needed those capabilities. And then now, all of a sudden, in this new patch version, [when] patches and minor versions are supposed to be pretty small changes and not significant changes, suddenly they're claiming in this patch version that they need all this new permission, right?

Jon McLachlan

Yeah. Okay, so it sounds like you wrote, or you have your own, like, heuristic of what risk looks like, and you can find that through a static analysis by encoding some of those patterns, maybe, into an initial first [pass], and then folks look at it.

Feross Aboukhadijeh

Correct. And, yeah, and when you say folks look at it, part of what we do is we have a bunch of heuristics, but also we have, and I hesitate to say AI, because everybody uses it as a buzzword in security.

Jon McLachlan

Trying not to jump on the AI bandwagon.

Feross Aboukhadijeh

But correct. Yeah. For most of, I would say for most of security, AI has been, like, this snake oil, fake, a little bit, maybe. Yeah. And I don't want to, I don't want to, like, I don't want to be in that realm by any means. But I have to say that with the new LLMs that have come out, like, we've been, so Socket's been paying really close attention to the LLM tech. And we were playing around with GPT-3 back in, before ChatGPT had even come out and had gotten everybody excited about it. And we were playing around with using GPT to explain package behavior. So when we see a network call, we can say, we can actually use the reasoning capabilities of the LLM to say, like, what is the reason for this network call? And, like, what data does it seem like it's sending out? And so being able to analyze the source code and figure out the purpose of each of the different permissions that are being used is actually pretty cool and pretty useful. And so it's not just, like, heuristic goes, and then we have a human look at it and do the analysis. We actually have, like, the ability to, within a minute of a package being published to one of these open source registries, we actually do our heuristics using static analysis, and then we also put it into this LLM. And if it's high confidence enough about this being malicious, we actually block it right away. So we have auto-blocks within minutes of publishing, and it's pretty cool. It's really, it means that it's like the fastest possible way to block this.

Jon McLachlan

Yeah. Yeah. And so to receive the benefit, all of that hard work that you guys have put in, the blood, sweat, and tears that you've poured into Socket, and figuring out, like, what are those heuristics? Could we use LLMs to accelerate our judgment calls, like, on obvious cases? It sounds like it's a command line tool that you install as a developer in your local development environment to help you manage and maintain your local installs of dependencies on the various projects that you have, for [languages supported].

Feross Aboukhadijeh

So we definitely have a CLI, but actually, most users use our GitHub app. And the reason is that it's because we're listed in the GitHub Marketplace. It's actually, like, a really easy install. It's literally two clicks to install it. And if you, so if you use JavaScript or Python or Go and you want to try out Socket, it's a two-click install, and then it'll add it to all your GitHub repositories, and you can start playing with it. There's no need to, like, go repository by repository and change the way that you do your CI, or add a new GitHub action to every single repo. It's like a two-click thing, and then boom, we're on, like, all the repos. And then what we do is, when we see any pull request that is adding a new dependency or updating a dependency, those are the two times when you're bringing in new third-party code. And so we will analyze those changes. And we do it where we never want to bother a developer with risk that they didn't cause themselves in that pull request. So anything that you already have that's risky, we're going to ignore, and only tell the developer in their pull request, here's what you are doing wrong, or, like, what you could improve in this pull request. So here is a package that looks like it's a typo, or here's a package that's malware. We're going to block this PR.

Jon McLachlan

[Or] here's a new one, like, here's a change that looks, like, suspicious. Like, careful.

Feross Aboukhadijeh

Yeah, I like that. Correct. So it's right there in line in their workflow, where they're spending all their time. They don't have to go out to a separate tool. They don't have to do anything complicated. It just slots in right there, and it just helps them do better.

Jon McLachlan

That sounds so easy. That sounds so easy. I think security done correctly fits into, like, our daily lives, fits into the processes that we already have, and is almost invisible, except when you need to flag something and there's an action required. Nice. So simple.

Feross Aboukhadijeh

Yeah. So that's the main, that's the main way people use us. But you're right, though, we do have that CLI. And I did mention kind of intercepting installs on the command line is actually really cool too. A lot of people like that, because it means that they're also protecting their local laptop and not waiting for the pull request to actually notice that they're using a malware dependency. So we can shift left as far left as we can. And even to the point where we have also, we've also launched a Chrome extension, where you can, as you're browsing the web, looking for packages...

Jon McLachlan

[We can also put] that insight directly into the, identify scripts that have not used Socket before and are trying to run maliciously identified, like, libraries or packages in your browser as you're looking at the page?

Feross Aboukhadijeh

Oh, no. So, yeah, no, so it's more like, I'm a developer and I'm doing research to figure out what dependency I want to use, because I'm trying to implement a feature. So I'm googling around and I land on a nice-looking npm package that seems like it's a good choice, right? But I don't know how many transitive dependencies this thing has. I don't know what all those dependencies are doing. I don't know if the maintainer is untrustworthy, or if they have no reputation, or I don't know if there's, you know, like, [protestware] or data exfiltration in one of these dependencies. So Socket will just, on that npm page, will just put that information, if there's any red flags, right there at the top of the page. And it'll say, this package uses the network, or this package steals all your data, or whatever.

Jon McLachlan

Oh, nice. It's like those little warning signs that your iPhone will pop up, like, oh, this app wants your location. You're like, no.

Feross Aboukhadijeh

Yeah, exactly.

Jon McLachlan

Exactly. For the supply chain, like, dependencies.

Feross Aboukhadijeh

I love that analogy. In fact, that's actually the analogy that we use. It's like, you should be able to know the permissions that your dependencies are using, just like you can on your iPhone.

Jon McLachlan

That's so easy and simple, and I love the, it just fits in with what we're doing already as developers, right? So seamless. Security done right is seamless. It just works and it fits.

Feross Aboukhadijeh

Yeah. And I wish more people thought about it that way. It just seems like the industry is very, I don't know. There's, I think it's because security software is typically sold to executives. That's the way that it's been done in the past. And so these executives, they don't have to use the software. And so the software is...

Jon McLachlan

So you can write an entire, like, bucket of crap. And if you can make that [sale] at the top level, like, with a couple of demos, and, like, the person on the receiving side never has to touch any of the pain points that are secretly, like, right underneath that hood, then you're setting up for a huge inconvenience, and you don't even know it. Like, in a bottom-up go-to-market strategy, which is like what you have, where you're targeting, like, the folks, the users and the adopters and the buyers are the same people. They're all the same. And we're going from engineers on up the chain, bottom-up instead of top-down, from CISOs and directors pushing stuff down. Like, I think that's the appropriate way. Like, as a leader, if you're not respecting people's autonomy, and you're not asking for solutions to hard problems, but instead you're dictating, like, what you expect solutions to be, you're really, like, violating people's autonomy, and you're not allowing them to bring their full self to the table. And that's where you lose out on all of the great benefit of the [talent] that you can surround yourself with. Right. So anytime there's a power asymmetry that's used by leadership to get something done, okay, I understand that's some people's leadership style, but it just, it feels like, because you're violating someone else's autonomy at that point. Because if you have to invoke a power asymmetry of, I'm the boss and here's what we're going to do, it's like, leaves a bad taste in my mouth. And I know that there's things, like, being left out, because if you can't convince someone who's smart that what you want to do is the right thing for the company, is it the right thing for the company? Like, maybe it's not. And you have to have the humility, I think, as a leader to understand and appreciate that perspective. Totally. I'm a huge fan of bottom-up go-to-market strategies.

Feross Aboukhadijeh

Yeah. Yeah, that makes, that's exactly what we're trying to do. So anyone can install Socket. You can try it out in two clicks, and there's no talk to sales required. And obviously, we do set, we do want to work with, we do work with CISOs and heads of [unclear].

Jon McLachlan

Of course, of course.

Feross Aboukhadijeh

Yeah. How awesome is it if the developers in the company have already used Socket to evaluate packages before? And then you come in as the head of application security, and you say, hey, we're thinking of using Socket. And then a bunch of people on the developer side raise their hand and say, oh, yeah, I love Socket.

Jon McLachlan

That's, it's a natural fit. It's just, it, like, works. Or even if you're a CISO, and you know that there's a huge list of, like, really difficult problems, and your principal engineer comes to you and is like, hey, this entire class of problem of supply chain, like, risk management, well, how about this? And it's basically mitigated as much as you're ever going to get [it mitigated].

Feross Aboukhadijeh

So no tool's perfect, but yeah, we definitely think, if you go beyond just focusing on known vulnerabilities, and you take a holistic look at the risk of packages, and realize that supply chain attacks are actually way worse than the average vulnerability. Malware is way worse than the average vulnerability. And most companies are doing nothing about that today, because the vulnerabilities, companies in that, tooling is just so prominent. It's so, it's so easy. It's actually been so easy to just check against this database, and everybody's just doing that because it's easy. The much harder problem is to say, what is this dependency going to do? And so if you do that, I think that, that plus being developer friendly and being right there in the developer workflow, that's, like, a really good recipe for success.

Jon McLachlan

Awesome. So now, with all of this, like, with you leading the charge there at Socket, and as founder and CEO of this growing, successful security company, what's your typical day look like?

Feross Aboukhadijeh

I do spend a large amount of time talking to customers and figuring out what we could be doing better, and demoing the product, helping people use the product. And that way, I can bring back those insights to the team and then help prioritize them. At Socket, we're a pretty small team, and so we move really fast. And we actually do weekly planning cycles, which means that we do have, obviously, we do have goals for the month, goals for the quarter, but we also can pivot within the span of a week. And so when we realize, we've talked to a customer and there's something that's very obvious, very important that they need, we can actually go in, and that could be something we work on that next, that very next week. That's really, we have a really tight loop between, like, customer feedback and then shipping things in the product.

Jon McLachlan

How big is the team?

Feross Aboukhadijeh

We're actually about 15 people right now.

Jon McLachlan

Wow. Wow. That is very small. Yeah. It must be super efficient.

Feross Aboukhadijeh

Yeah. Yeah. A lot of people think that we're 50 or 100 people, just because of the rate that we ship stuff, but our team is all very senior folks, and all just very, very good at what they do.

Jon McLachlan

Amazing. So what's the best day that you've had so far?

Feross Aboukhadijeh

The best day that we've had. That's interesting. I think that I definitely love when we get new customers, like new large customers, on board, because it just gets more and more evidence that people are liking our approach. So yeah, we recently had a big customer switch over to Socket from some other tool that just does vulnerabilities. Yeah. [Competitor], yeah. And it was just like a huge validation for us and for the whole team, that we're, wow, like, a company that, you know, is this large and this, I don't want to say conservative, but, like, this careful, realizes that they had a gap and that we're the solution to that gap. Like, how exciting is that? Like, we're actually really onto something here. So anytime we get more signs that we're building the right thing, it feels so good, as [the] founder of a company, because so many startups don't ever get to product market fit. And it's like, it's really just the reason that so many companies fail at this pre-Series A stage.

Jon McLachlan

Right. And congratulations, actually, on your Series A. I saw on LinkedIn, a 20 million raise you pulled through.

Feross Aboukhadijeh

Yeah, really excited by that. So we love the person who led the round. He's Zane Lackey, who is one of the founders of Signal Sciences. And he was actually an angel in Socket, because he was one of the earliest people to individually, like, like what we're doing and backing us. And then he joined Andreessen Horowitz and then led the investment in Socket. So yeah, it's wonderful. They're a great, like, I think they're the best, they're one of the best, with the best firm out there, and team's incredible. And yeah, it's really great validation.

Jon McLachlan

What's been the most challenging day that you've had so far?

Feross Aboukhadijeh

We haven't had anything, like, dramatically bad happen, the kind of, some of the kind of crazy stories you hear about, like, at maybe other startups. We were actually a pretty mature team, like, as you can imagine.

Jon McLachlan

I think a great group, yeah.

Feross Aboukhadijeh

Yeah, I think we have a great group. So I think the, probably the worst, like, the bad days are just days where I'm, where the day gets by you. You just, you start, like, a bunch of things come up, and you, and then at the end of the day, you feel like, what did I really do today? And where you just get pulled into too many different directions, and you lose focus a little bit. Those days are my worst days. But it's never a thing that gets you down, gets me down. I'm usually just, like, ready to go the next day, and just got to keep showing up and putting in the work.

Jon McLachlan

Consistency counts for a lot. And sometimes we can be our own, like, worst critic. We look back and we think about, like, how do we handle something. So I often find, like, a sense of compassion goes a long way. And remind yourself, like [you] mentioned, like, tomorrow's going to be another day. Have another go at it, right? So, and there's no such thing as failure unless you actually, like, give up, right? You give up, like, okay, it's done. But you just keep at it, persistent, keep showing up. It's good. It's good. You just, success is right over the horizon.

Feross Aboukhadijeh

Yeah, for sure.

Jon McLachlan

So what's the founding story? Did you actually start building this yourself? You are very technical, a strong technical background, you study computer science, and you noticed the problem. No co-founders?

Feross Aboukhadijeh

Yeah, no co-founders. I would love to have had a co-founder, I have to say, some days, when I'm like, wish that there was somebody else who could share some of that load. But no, so the story was, I was building that app I mentioned before, Wormhole, with a friend. And that was actually the company at the beginning. And we wanted to build a suite of productivity tools, similar to, like, the Google Workspace suite. So docs, spreadsheets, notes, emails, all that stuff, that was all end-to-end encrypted. So the service provider couldn't be able to...

Jon McLachlan

It's a really difficult challenge too, especially because, like, key lifecycle management is extremely complex.

Feross Aboukhadijeh

Yeah, there's a lot of challenges with that. And especially if you want to make it be a really good user experience in the web browser. So you want to be able to, you don't necessarily have all the data already offline and are able to decrypt it. You need to be able to fetch from the server just the data that you need, just the segments of the data that you need, and then to decrypt it as needed in the browser. So there was a lot of, and so we started, we wanted to start with something that was, like, just getting our foot in the door, and getting our, getting kind of something out that was, relatively speaking, easier. And so we started with file transfer as the use case. And so Wormhole was, we wanted it to, and our bar, our sort of goal, was not just, oh, it's the, it's like this other service, but encrypted, but end-to-end encrypted, and therefore, therefore worse in the terms of user experience. That was not acceptable to us. We wanted it to be better in user experience and better in security, and those were both equally important. So with Wormhole, we were able to have a user experience of something like Dropbox send or WeTransfer or Firefox Send, or these browser-based file transfer services, but better, better and better in both user experience and security. So we actually had, literally, I'm still super proud of it. It's still live today. If you, people want to check it out, it's at wormhole.app, to go visit and see. But it will actually, we let you drop your files on the browser, no account needed. Instantly, you get a link that you can share. Even before the files are finished uploading to the service, you get this link that you can just go and paste and send to whoever you're trying to send it to. And now you're done. You don't have to, like, because we, I really didn't like the way you wait after you drop the files on. You got to wait 15 minutes to upload this giant 10-gig set of files, and then you get the link, and then you send it. And that was a problem. So you get it right away. That's the first thing. The second thing...

Jon McLachlan

I'm trying it out right now. Whoa. It's like there is a wormhole.

Feross Aboukhadijeh

The user experience is definitely interesting. I think with the wormhole animation, we definitely got, some people love it, some people hate it. But the second thing we do that's really different is that the receiver of that link can actually start to access whatever files they want to within the set that you're sharing, even before you've finished uploading them to the server. So you could be 1% uploaded, and they're like, I want to load this file over here. And it could be one of the ones that hasn't even been uploaded at all yet, and we will dynamically reprioritize the files that are being sent. And it also uses peer to increase the speed. So using WebRTC, we would actually connect directly the two browsers together and avoid the cloud, and just go straight to your machine if you were both online at the same time. So it's like these niceties and these little tweaks that make the thing super fast. I was very proud of it. But yeah, you asked about how we got to Socket. So yeah, that was where we...

Jon McLachlan

So it was a pivot. It was a pivot to make Wormhole more secure. You built this thing, or you started to build this thing, and then you realize, like, wait a second, I'm not the only one with this problem.

Feross Aboukhadijeh

That's basically it. Yeah.

Jon McLachlan

What was that, well, how did you come to that realization that you just solved, like, a huge problem that the entire ecosystem and community faces?

Feross Aboukhadijeh

Well, there was a moment, yeah. I was asking around, like, what do people do? Like I mentioned, we did a lot of stuff to do security right with this. We wanted, we wanted to do the best job we could, and it felt like we had exhausted all the things we could do that were in our control. And the, like, last remaining piece that we didn't feel so good about was our pile of Node dependencies that were sitting there taunting us. And they're like 90% of our code that we haven't even audited or looked at. And we're like, how can we say our app is safe if, like, we've only looked at this 10%, and then 90% over here? And I think a lot of developers don't appreciate the, I know they know it, but they don't really think deeply about it and appreciate that it doesn't matter whether it's code you wrote, or whether it's code that somebody out there on the internet wrote. Like, at the end of the day, it's going to get all bundled together, and it's going to run in one process. And all of it is going to be, all of it is your app at the end of the day. Right. So it's not an excuse to be like, well, that's someone else's code, that's someone else's problem. No, like, if you're using it and it's getting run in your app and it's all running in the same process, like, it's your problem. And so we thought about it as our problem, that we wanted to understand the risk of and protect ourselves from that risk. And so we started asking around, and nobody had a solution. They all said, why don't you use this CVE scanner? And it was like, no, that's not really what we want. That's not really addressing the risk here. Like, I know that we have zero CVEs. Like, what I'm concerned about is there's malware or a backdoor sending data. It could even be, not even malware, it could be innocent. It could be the, there's some developers now that, like, maintainers that like to add analytics code so they can learn who's using their package. They want to collect some analytics or whatever, right?

Jon McLachlan

[Perfect]. Like, legit, like, use of, like, well, I don't know. You have to, like, you have to be very careful what you collect.

Feross Aboukhadijeh

Yeah, yeah. It, it's, it's sometimes [legit].

Jon McLachlan

[It's not malicious, let's just say.]

Feross Aboukhadijeh

Yeah, it's not malicious, but it's like, it could be potentially, for a lot of companies, it would be something they don't want.

Jon McLachlan

Very risky. Yes, exactly. Yeah. Like, and then you look at, like, your browser, you open it up, and if it's JavaScript, you can see it connecting to all these random sites, and you're like, what is going on here? Why does it need to pipe data to all of these random things? Frustrating.

Feross Aboukhadijeh

Yeah. Yeah. And for us, we didn't want to pipe data to anybody. So we had, obviously, a content security policy in place that would prevent that. But we still wanted to, with defense in depth, you want to have multiple layers...

Jon McLachlan

Layers of security. Yeah.

Feross Aboukhadijeh

Yeah. Exactly. Yeah. And so that was what we were like, okay, so really, there isn't a solution. And then I decided to go out and actually formally interview, like, 40 application security leaders, and ask them what they thought about this problem, like, what they're doing today to mitigate it, and whether they think it's a problem that they care about, that they're trying to solve, or what. And it was almost universal. Actually, 39 out of the 40 told me that they thought this was a top three priority, but they felt like there was nothing, there was really no good solution. And they were, they were just, it was one of those things that kept them up at night. And so that gave me the confidence that this was a big problem. And we had faced the problem. They were facing the problem. We had an idea for how to solve the problem.

Jon McLachlan

And so it was, so you gave it a shot. And then you would go back to that 40, or the 39. I don't know what the one person did, but...

Feross Aboukhadijeh

Actually, that was, I don't want to, I don't want to name who it was. It's an app that, it's definitely an app that folks have heard of. I'm not going to mention who it was, but they were like, yeah, we don't really, yeah, we don't really care about, like, securing our dependencies. Like, we just let people, developers can do whatever they want. Like, it's fine. And I don't want to say who it was, because they actually got, they've been breached multiple times since [then].

Jon McLachlan

Well, props for not throwing each other under the bus. And that's a complicated thing, too, because sometimes people are constrained by the budgets that the companies that they work for are operating under.

Feross Aboukhadijeh

For sure, yeah. And I don't want to blame people.

Jon McLachlan

I think you can't blame people.

Feross Aboukhadijeh

For sure, yeah. I know. I think it was more the mindset of this particular company or individual that was the problem. It wasn't like, oh, this is important, but we have three other more important things. It was more like, we don't really care. That was what I was responding to.

Jon McLachlan

That's difficult. Fair enough. Yeah. Yeah. But maybe you would like to share with our listeners a book or a movie that changed the way that you saw the world, or cued you into something that you thought was just interesting and intriguing.

Feross Aboukhadijeh

The most influential movie for me was when I was a kid and I watched The Matrix, but that's probably not an interesting recommendation for most of the listeners.

Jon McLachlan

Really? Why not? Like, okay, so I've met, so this is also the answer to my question, is, like, The Matrix. But why The Matrix?

Feross Aboukhadijeh

First of all, it's just cool.

Jon McLachlan

It's very cool. Yeah.

Feross Aboukhadijeh

No, but it's obviously, the philosophy of it is super interesting, especially when you're younger and you're just getting exposed to that for the first time. It got me really interested in, like, philosophy, and, like, what is reality? How do you know that you're in reality? There's just a whole bunch of really cool questions in there. You know, would you take the red pill, or would you take the blue pill? Yeah, I know. It's a bunch of, it sounds cliche now, as when you're older and you know about more stuff, but, like, I just remember at the time how mind-blowing and incredible it was, and still is, actually. I think it's actually held up, holds up really well, going back and watching it.

Jon McLachlan

I think so too. Like, the first one. Like, I don't know what happened with the other ones, but...

Feross Aboukhadijeh

Yeah, no, let's not talk about those.

Jon McLachlan

No, they don't exist.

Feross Aboukhadijeh

Let's definitely not, like, let's not bring those up. Like, confirm those don't exist.

Jon McLachlan

Yeah, no, I've met several young folks that are like, oh, yeah, I've heard about The Matrix, but I've never seen it. Really? Wow. Like, you're in for a treat if you ever sit down and...

Feross Aboukhadijeh

In that vein, another one that folks might enjoy is a movie called Waking Life.

Jon McLachlan

Oh, I've never heard of it.

Feross Aboukhadijeh

Yeah, Waking Life. It's just, it's, it's definitely a strange recommendation. So, like, strange. Yeah, it's basically, it's, this guy went around and interviewed a bunch of professors about, like, and different folks about, like, what is, what does it mean to, what is existence, and what does it mean to experience things? And then they did this really cool art style, where they took every frame of the movie, every frame of all the shots they took, and they drew, like, they drew on top of them, like, tracing the lines of the faces of the people they were interviewing. And they did that for every frame. So they drew a separate picture, and then they put it all together. And so there's no frames of, like, the, for the whole movie, you're basically watching these drawings. And because each picture was drawn individually, it doesn't line up exactly between the frames. And so it does this, like, wobbling thing.

Jon McLachlan

Wiggly, wobbly.

Feross Aboukhadijeh

Yeah. Everything is wobbling the whole time. And it's, it's, I don't know, it's just, it's a really unique, like, aesthetic.

Jon McLachlan

[Very artistic.] Yeah, very artistic. It's very particular aesthetic there.

Feross Aboukhadijeh

Yeah, it's pretty cool.

Jon McLachlan

Nice. Well, no, thank you so much for joining on the Security Podcast of Silicon Valley. Would you like to leave our listeners with any words of wisdom?

Feross Aboukhadijeh

Stay hungry, stay foolish. There's a lot of cool stuff out there in the world, and go forth and hack.

Jon McLachlan

I don't know. That sounds like great advice. Thank you again for joining, Feross, and thank you for all of our listeners for tuning in to another episode. I'm your host, Jon McLachlan, and stay tuned for the next episode.

Feross Aboukhadijeh

See you, Jon. Thanks for having me.

Jon McLachlan

No, thanks for joining. It's been awesome.

FAQ

Questions this episode answers

What does Socket do?
Socket helps fight vulnerabilities, malware and supply chain attacks that come in through open source dependencies. On the tape it watched every new package on npm, PyPI and Go.
What are the written and unwritten rules?
The specs are the written rules, how a system is supposed to work. The code is the unwritten rules, the source of truth. Feross says an exploit or a hack is a difference between the two.
How many CVEs are worth fixing, according to Feross?
His guess, and he calls it that, is that probably 95% of CVEs aren't worth fixing. Socket bought Coana in April 2025 for reachability analysis, which asks whether your code can reach a vulnerability at all.
How did the event-stream backdoor work?
A new maintainer took over event-stream, made about a month of good changes, then added a backdoor. It used the top-level project's description as a decryption key, so it ran only in one company's crypto wallet app. Wikipedia dates the discovery to November 2018.
What is typosquatting in npm?
Registering a package name close to a popular one and waiting for typos. Feross calls it the most common attack Socket sees. Socket's command line tool intercepts npm install and asks whether you meant the popular package.
How does Socket use LLMs?
Socket played with GPT-3 before ChatGPT came out, using it to explain package behavior, such as why a package makes a network call. Static analysis heuristics run first, then the model, and confident cases are blocked within minutes of publishing.
Why did Feross build Standard JS?
He was tired of giving style feedback on WebTorrent pull requests. Standard is a set of settings on top of ESLint, and he named it JavaScript Standard Style as a joke, after a script showed the name was free on npm.
What was the CS 253 final exam at Stanford?
As Feross took it, a 24-hour pen test of a VM running a vulnerable e-commerce site. He found 13 or 14 planted vulnerabilities and one the instructors hadn't planted. He later rebuilt the course and taught it.
How did Socket start?
Feross was building Wormhole, an end-to-end encrypted file transfer app, with a friend. About 90% of its code was unaudited dependencies, and the only advice he got was to run a CVE scanner. So he interviewed 40 application security leaders, and 39 called the problem a top-three priority.
How much has Socket raised since the episode?
The $20 million Series A, led by Zane Lackey at Andreessen Horowitz, was announced on August 1, 2023. A $40 million Series B followed in October 2024, and a $60 million Series C at a $1 billion valuation in May 2026, for $125 million in all.
Keep reading on the YSecurity blog
New episodes every other Tuesday

Got a story like this one?

We're always looking for practitioners who've been in the room when it mattered.