Guarding the JavaScript Supply Chain: Preventing NPM Attacks with Feross Aboukhadijeh - JSJ 695 - JavaScript Jabber

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:05):
Hello everybody, Welcome to another thrilling episode of JavaScript Jabber.
I am Steve Edwards, the host with the face for
radio and the voice for being a mine. But I'm
still your host, and sirih thinks I'm talking to her
for some reason. With me today we have a special
returning Yes, mister Farross, a book a DJ.

Speaker 2 (00:22):
How you doing, Fross?

Speaker 3 (00:24):
I'm doing good. Thanks for having me here.

Speaker 1 (00:26):
Yes, for those of you that wonder how to say
his name, it's think about like booking a DJ for
a show or something like that.

Speaker 2 (00:34):
That's what he told me, and it still works for me.

Speaker 4 (00:36):
I'm impressed you remember that, Steve, because yes, it is
pretty memorable ized pose.

Speaker 2 (00:42):
Yes, yes, so Fross.

Speaker 1 (00:45):
Before we get into our lovely dark world of internet
hacks and people trying to steal cryptocurrency, why don't you
give us a little background on who you are and
why you're famous, and your company and what it does
and all that good stuff.

Speaker 3 (00:58):
Cool.

Speaker 4 (00:58):
Yeah, I wouldn't say I'm famous, but I'm happy to
give you a background on.

Speaker 2 (01:02):
What I would.

Speaker 3 (01:03):
But that what I've done today. Yeah.

Speaker 4 (01:06):
So I started off kind of writing open source software.
That was kind of what I did for most of
my career. I found the early no JS community to
be like a really welcoming and awesome place. Kind of
found my way to the early node con conferences in
the one in in San Francisco that Michael Rodgers organized,

(01:26):
as well as the note Confee you and kind of
just got really addicted to publishing NPM packages. Published a
bunch of those over the years, some projects like webparrent.

Speaker 3 (01:38):
And standard js.

Speaker 4 (01:40):
Uh and uh, yeah, I just learned a lot about
the you know, the supply chain, the way that open
source software is used by companies, the way that you know,
open source development happens, and and I got really addicted
to it and it was really fun.

Speaker 3 (01:55):
It's an amazing community.

Speaker 4 (01:56):
Uh And ultimately that kind of to me starting Socket
in twenty twenty, after seeing a ton of attacks happening
against JavaScript packages, I got kind of obsessed with like
trying to fix the problem.

Speaker 3 (02:10):
I was like, why why do we accept that.

Speaker 4 (02:14):
Packages are just going to keep getting compromised and every
time that happens, we're just going to have to hope
that we were lucky and not affected by that in
some way or another, Like, can't we actually be proactive
about this?

Speaker 3 (02:24):
Scan for this prevent this, and so I.

Speaker 4 (02:28):
Started a company Socket to do that, and now we're like,
it's a big company now, I mean we're like seventy
five people. We have a ton of big customers, a
lot of companies you probably recognize, and just trying to
help people use open source safely.

Speaker 1 (02:42):
So just to clarify for us and I were talking
about this ahead of time, his website is socket dot dev,
not socket dot io, if you make that mistake. Socket
io is Girmo Rouscher's old library for doing web sockets.
Socket dot dev is Frost's entity that helps keep supply
chain stuff safe. So for us, that's quite the list

(03:07):
of recent compromises and attempts to compromise the NPM supply chain.

Speaker 2 (03:12):
I know that.

Speaker 1 (03:15):
The most recent one that comes to my mind that
we got hit with was the one, and we'll get
to this, the Chalk Library and all those libraries by
that same author that got compromised with a crypto trying
to steal cryptocurrency stuff. And fortunately for us, we weren't
using those libraries, so we were okay. But apparently that's just
one in a string of recent compromise attempts.

Speaker 2 (03:39):
So with further Ado.

Speaker 1 (03:40):
I'll let Frost take over and talk about what's been
going on lately.

Speaker 3 (03:44):
Yeah.

Speaker 4 (03:45):
Sure, So we've seen a bunch of attacks over the
last couple of months. I'll try to give you like
a high level summary and then we can dig into
the the different details if that's interesting to you.

Speaker 3 (03:56):
Yeah.

Speaker 4 (03:56):
So we saw a phishing campaign that started about two
months to go back in July where a lot of
kind of popular MPM maintainers got this phishing email that
was impersonating npm and asking them to like add to
FA to their account. And it turns out that that
email was actually sent from well, it appeared to be

(04:16):
sent from support at npmjs dot org, which is like
a real email that npm uses, but actually it wasn't
sent from there.

Speaker 3 (04:24):
It was just spoofed.

Speaker 4 (04:26):
And unfortunately the npm js dot org domain didn't have
the proper like email headers set up d mark and
SPF headers that would would have helped different email clients
to know that that that email, you know, wasn't legit
from from npmjs dot org. Turns out like they send
email from npmjs dot com, uh, and that had the

(04:49):
headers set up, but npmjs dot org is a real
domain that NPM uses, so it was still quite convincing
to get an email from that for people. So Lesson
learned there is like you need to set up these
email headers in these email these DNS records that help
you know, block spoofed emails even on domains that you're

(05:09):
not sending email from. As long as they're like a
domain that your users recognize that you use, you know,
you got.

Speaker 3 (05:14):
To protect them with those same with those same GNS records.

Speaker 4 (05:18):
So what happened is if people clicked on the link
in the email, it would take you to a website
that looked exactly like NPM, but it was a proxy,
so it sort of anything you clicked on would work,
and it would let you navigate through the whole site
just like you were on the real site, but the
domain was off by a letter, so it wasn't the
real site. And then of course if you logged in

(05:39):
it would it would steal your credentials. So that that
was something that was going around back in July, and
we kind of noticed it over at Socket because some
of the folks on our team got this got this
fishing email, and we were like, oh, this is interesting,
So we wrote about it, tried to warn people about it,
but nonetheless, a couple of days later there was kind

(05:59):
of the first prolific maintainers that were starting to get
affected by this, and that started with a Prettier project.

Speaker 3 (06:06):
So the Prettier package, a.

Speaker 4 (06:08):
Couple of Prettier packages were compromised, including yes lint can
fike Prettier, which is the reusable yes link configuration that
kind of has the the rules for es lint in
it that you can kind of apply to to to
yes lint, and so that was compromised with a with
a like a Windows specific DLL file. So for those

(06:31):
who don't know, that's basically just like a kind of
a compiled code file that that you know, you can
run on Windows machines, and that when that ran, it
would it would steal a bunch of system system information
like your environment variables. Uh, and then it would open
a web socket, speaking of web sockets, uh, It would
open a web socket to the attacker and it would

(06:55):
leave that connection open. And so then the attacker could
have base to be like an interactive shell, so they
would any text that they sent over that web socket
would be received on your your computer, your machine, or
your server and it would get run like in a shell,
and then the output would get sent back to the attacker.
So it's like they were almost acessation into your system,

(07:16):
but using a web socket to kind of run commands
on your computer or on your server. That's bad, right, Yeah,
it goes out saying that's bad. Yeah, yeah, they so,
so I think, you know it was it was cross
platform in that way, so there was the Windows piece
that the doll file, but then it was also like
it would also affect you on Mac and Linux because of.

Speaker 3 (07:38):
The web socket, and yeah, not good.

Speaker 4 (07:42):
They also kind of tried to hide their tracks through
through different like anti analysis techniques, so they would encrypt
the data going across the web socket, so if you
were like looking at the text, you wouldn't see, like,
you know, what was going.

Speaker 3 (07:55):
Across that that socket.

Speaker 4 (07:59):
So that was kind of the first first sort of
effect of this fishing campaign was it actually hit you know,
this popular library. Then it was kind of all quiet
for a little while for about a month there until
August when the popular NX build system was had one
of their packages compromised. And this this attack was interesting

(08:22):
for a couple of reasons. I'd say the first reason. Well,
for first of all, it just it was similar and
that it still just tried to steal credentials. So it
would like search your system for you know, s s
H keys, NPM tokens, basically any file that you might
have on your system that contains like a key or
a token in it. It was it would just hunt
through the file system looking for that and send it
off to the attacker. But what was interesting about how

(08:43):
they did it was it didn't just use like it
you know, just code to do that. It instead abused
AI tools like Claude and Gemini to scan your file
system for sensitive data, which is a technique that we
had never seen before. So this means that it would
look for or uh Claude or Gemini installed on your
system like this the cli tool that lets you interface

(09:05):
with these AI agents and these AI tools, and it
would use them to with a prompt asking the agent
to go and like search your file system for interesting files,
and then it listed out a whole bunch of file
extensions in the prompt like dot t x T, dot log,
dot n you know, uh, dot back, you know, just
different different kind of interesting extensions that could have keys

(09:28):
or data in it. That might be interesting to the attacker,
and then the agent would go and find all those
files and then collect them in one in one place
that could then be sent off to the attacker. So
I'd never seen like an LM being used in this
way kind of kind of you know, as a like
like effectively that the payload of the attack is not
like some malicious code, it's actually just a couple of

(09:49):
sentences in English. So that was that really blew my
mind when when I saw that.

Speaker 2 (09:57):
So why is that effective? Then you find it wor
inner or just that that was the attempt.

Speaker 3 (10:02):
Oh no, it was effective. Yeah.

Speaker 4 (10:03):
I mean if you had if you had to have
claud or Gemini on your system for it to work,
if you didn't, it wouldn't do anything. So that was
that was kind of the funny part was that it
wasn't you know, it wouldn't affect you if you didn't
have those CLI tools installed.

Speaker 3 (10:14):
So they kind of limited their reach a little bit.

Speaker 4 (10:16):
But I suspect they did it because it it was
an attempt to get past code scanning tools that look
for you know, suspicious code and if you know, if
it's just a string, then a lot of those scanners
will skip it, skip it.

Speaker 3 (10:29):
That's it.

Speaker 4 (10:29):
Socket socket wasn't wasn't tricked by this because we use ourselves.
We use l ll ms to look at the code,
which is a newer technique.

Speaker 3 (10:38):
Right.

Speaker 4 (10:38):
A lot of the sort of other security tools do
static analysis on the code alone. But if you actually
use an l M to look at the code, an
l N isn't going to be tricked by a sentence.
You know, you can ask the l M like what
is this code doing, and it'll look at the prompt
and it will tell you. So this, you know, with
with the right prompting that actually it's possible for like defenders,
for the good guys to also you know, use these

(10:59):
AI tools to catch the bad guys.

Speaker 3 (11:02):
Using a tools.

Speaker 4 (11:03):
So it's it's it is a cat and mouse game
some extent. But but I think you know, it didn't
get past us. But but I would say it was.
It was effective in that that if you actually ran
the code, it worked as it was intended to. Okay, yeah,
so that's uh, that's we're still not to the chalk
attack yet. But but I wanted to say one other

(11:23):
thing about this one. So NX, I don't know if
you're familiar with. It's this build system, so it's it's
kind of an open source it's an open source project.

Speaker 3 (11:30):
They have a GitHub repo that folks can contribute to.

Speaker 4 (11:33):
It's just a kind of a standard you know, NPM
open source project like people are familiar with, and so
they accept pull requests from the community.

Speaker 3 (11:41):
And one thing that was interesting about the uh.

Speaker 4 (11:44):
The way that this attack happened was it didn't use
the phishing email, so that's not how they got the
attack or got access. They used a different method, and
so I wanted to talk through that because I think
that the method was quite quite impressive. So they they
used a get of action workflow that the an X
project had, you know, added to their EPO, and it

(12:04):
had some vulnerabilities in it that the attacker was able
to use.

Speaker 3 (12:07):
And so I want to walk through that because I
want to.

Speaker 4 (12:09):
Make sure people are aware that get up actions are,
like they're very powerful, they're very useful. I use them
all the time, but they're also very dangerous if you
don't use them correctly. And there's a lot of foot guns,
like just ways that you can just think you're doing
something very innocent, very very very you know that looks
doesn't look dangerous, but it's actually like a like a trick,

(12:30):
like you're you're you're actually doing something very dangerous and
it's just it doesn't seem that way. So the thing
that they did, so they did a couple of things.
But the first one was they they were trying to
print out the PR title in the action. So they
had this echo command that just said like echo PR
title and then it put the variable you know, into
the command that that was that would print out the

(12:51):
PR title. The way they did that with echo, right,
and by putting the variable in there created a shell injection,
which is it's very similar to a SQL injection if
people are familiar with probably more familiar with SQL sql
injection attacks, and that just means that an attacker can
effectively insert their code into the command, so it's your

(13:15):
instead of the instead of something being treated as data,
it is inadvertently treated as code and executed. And so
the way you do that here is you as an attacker,
you'd just open a PR to this an x open
source project, and you'd put your attack code in the
title of the PR, but you'd start it with like
a double quote to sort of close off the quote

(13:36):
that they had in their command and then and then
the rest would be kind of run as runs as
a command, So you could get code effectively running in
the in the environment of the you know, of the project.
Now that is in and of itself not that like interesting,
because like there has to be some something in that
environment that you want to take or you want to
steal as an attacker. And uh so that this is

(14:00):
the kind of where you get to the second part
where get of actions support two ways of responding to
pull requests. So they have these triggers where you say, effectively,
when this thing happens, run my git of action right.
And so the thing that happens is the pull request
has been opened, right, And they have two ways to
react to pull requests that are being opened. One of

(14:21):
them is called pull requests and one of them is
called pull request target. And for many years, pull request
target was the one that was recommended in the getub
docs and was what a lot of tutorials and code
samples were using. So it's probably the one that a
lot of people chose to use. The problem with that
one is that, unlike the standard pull request trigger, the
poll request target one will will run the workflow with

(14:44):
elevated permissions, and it includes this get up token environment
variable that gives you full read and write access to
their pository.

Speaker 3 (14:54):
So that token is just sitting there in the environment.
And so if.

Speaker 4 (14:58):
You use pull request target in your project, it means
now anyone can open a PR on your project, and
if they can run code in that environment, you know
that can look at the environment vables. There's going to
be a really juicy environment vable there that lets them
effectively commit to your repository. So the combination of those
two things meant that an attacker could put code into

(15:18):
the title of a PR, send it to just just
open it on, you know, send a PR to the project,
and then that code would run. And they made that
code basically look for that environment variable and steal it
and send it off to them via an HTTP request.
So now they have the get up token, they can
commit to this, you know, important open source project, even
though they're not supposed.

Speaker 3 (15:38):
To be able to do that. So what do they
do with that, Well, they were trying to get onto NPM,
They're trying to compromise the NPM.

Speaker 4 (15:44):
Package, but they only have the get up token. So
this project like a lot of projects have a published workflow,
which is just another get of action that they've set
up that will published NPM, and they made sure that
the NPM published token was only available to.

Speaker 3 (16:03):
That publish workflow, so it was isolated over there, which
is great. They did a good job of that. But
now the attacker can write to the entire repository.

Speaker 4 (16:14):
So all they had to do was going and they
just they just edited the publish workflow file and just
added an extra step that would I think print out
or send the NPM token to them, because once you
can write to the repo, you know, then you can
just edit any of the workflows and just it doesn't
matter that the NPM token was only available to some
of the workflows. They can just edit the workflow and
print out the tokens and stuff. So that's how they

(16:36):
they basically stole the NPM token and then published the
malicious packages. So that was a lot of information, but
I just wanted to walk through it because I think
I don't know if you were following all of it
or it was interesting to you, but I think it's
fascinating because it's just like you're just using gid of actions,
you like don't think about like I'm going to like
my entire repo was going to get hacked and my
NPM package is going to get a compromise because I

(16:58):
just like you know, printed out a PR title like
in my in my get of action, Like that doesn't
seem like it should lead to that. So it's, uh,
it's pretty wild.

Speaker 2 (17:10):
So a couple of things.

Speaker 1 (17:11):
One, for those who want a good example of sequel
injection attacks, look up xk CD number three twenty seven,
otherwise titled Exploits of a mom and you're recognized Bobby Tables.

Speaker 2 (17:26):
Yeah, just leave that to you to look up.

Speaker 1 (17:28):
That's one of the few xkcds that I have memorized,
the number that and nerd sniping. But so a question
for you then regarding how you know, like you just said,
you wouldn't think that a GitHub action could expose you know,
you just somebody stealing your token?

Speaker 2 (17:48):
Is that on the is that on GitHub?

Speaker 1 (17:52):
Is that on the creator of the action they have
to know the finding security details of creating a GitHub
action or is it just the nature of you know
what it is that you can everybody's looking for vulnerability
somewhere and somebody happened to be created creative or how
do you look at that?

Speaker 4 (18:12):
I mean, as with security, all things in security, it's
it's a complicated answer. I think there's blame to be
shared on all sides. But I put probably more of
the blame on the design of get of actions because it,
you know, it's not fair. I don't think it's fair
to you know, have kind of a bad design or

(18:33):
bad defaults and then just say, oh, well I documented it.

Speaker 3 (18:36):
You know, go read the docks. The docks tell you
how how you know how not to use this.

Speaker 4 (18:40):
If it's if it's too if it's if you have
too many like booby traps or you know what sometimes
called foot guns in the design of of something, then
you know, you you definitely have some of the blame
on the creator of that design. So there were a
few things in the design here that we're just that
we're not obvious to people. I think, you know, the
fact that they were recommending pull request target for a
year instead of the safer pull request trigger is definitely

(19:03):
on GitHub. They've now documented that very well. So it
is all documented. But you know, there's a lot of
tutorials and guides and things that are going to still
have the old information, so, you know, and then I
think the other part of the design that is probably
not that obvious is so that the I mean the
NX the credit of the NX project. I was very

(19:25):
impressed they actually figured out that they had this shell
injection vulnerability and they fixed their get of action two
years before this attack happened. So from their perspective, they
fixed the problem, like they fixed the echo issue, you know,
and so how are they still affected?

Speaker 3 (19:42):
Right? That's kind of another interesting part of the story.

Speaker 4 (19:45):
It turns out that if you have an old branch
that still has the you know, still has an action
on that branch, then anyone can open a PR against
an old branch, right like when you open prs, you
can target any branch. You don't have to open the
PR on or on Maine. You can open the PR
on something from two years ago if if the branch
is still there. And so they had fixed this issue

(20:07):
two years before, but it was still lying around on
a whole branch, and so again to me, that's like,
I guess technically that's probably explained somewhere in the get
of Actions documentation, but I you know, I as security
person probably wouldn't have made that connection.

Speaker 3 (20:23):
Like I you know, I don't. I like to be kind.

Speaker 4 (20:25):
I like to sort of be try to have some
grace for people that are just trying to do their
best to like do things right. And I think there
was a lot of things that the NX team did
really well here and yet despite all that, like they
were still affected.

Speaker 3 (20:35):
So I definitely put some of the blame on the
design to get of actions here.

Speaker 1 (20:38):
Well. You know that's interesting because I can remember, I
don't remember when it was, I want to say, within
the past year somebody raising a question with GitHub regarding
the deletion of branches and whether or not they're truly deleted,
and you know, because they're thinking, Okay, I'm deleting a branch,
it's gone, and getthub saying no, that's a beat or

(20:59):
not a bove ug, you know, as they purposely keep
old branches around if you say you've deleted them. And
I was like, okay, and I can think of I
can think of a time where that has been useful,
you know, where I wanted to recuperate an old branch
for some reason and it's still and I know they
get up and deleted, but you know, at the same time,

(21:22):
that looks like a two edged sword in the case
that you're describing that someone thinks they deleted it, but
it's really not. And so now you got to worry
about old branch you supposedly deleted, which is still around.

Speaker 2 (21:32):
It can be used as an attack vector. Yeah, my
head spins just thinking about it. So anyway, this.

Speaker 4 (21:38):
Also matters a lot when you're trying to clean up
like an accidental commit that contains a secret or token
and you go intro you forced push to try to
get rid of it from the history, and but then
it's actually like still lying around on GitHub.

Speaker 3 (21:54):
So for those folks that don't know, if you know, to.

Speaker 4 (21:58):
Commit hash of the the commit that contains the the
secret or the you know, the one that you thought
you did, the commit that you thought you deleted, if
you put that commit hash into GitHub, it'll actually still
be there forever. It's just immutable, like it's just the
URL that just will exist forever with whatever you whatever
data you thought you deleted. So if you want to
actually fully delete it, you have to contact get up

(22:20):
support and basically ask them to going manually. Yeah yeah,
so yeah, even if you force pushed, the only only truly. Truly,
I think the clean way to fix it is to
completely delete their entire repo. But even then you might
have forks. If it's been a public repo and someone's
forked it, then my understanding is that that the fork

(22:40):
actually then kind of keeps a reference to all those
commits and then still won't get deleted. So yeah, you
should just assume if it's been ever in a commit
and it's been pushed to get hub like, it's public forever.
Even if you've force pushed over it like, it's basically
you can't bring you can't put the toothpaste back in
the tube.

Speaker 2 (23:02):
Interesting, Yeah, well it makes you nervous. So the only
so if you delete it.

Speaker 1 (23:06):
So what you're saying, and if I understand at least
forget up, I use getting lab in my day to
day work, we're using get labs, so I'm not sure
if all of this carries.

Speaker 2 (23:14):
Over there as well.

Speaker 1 (23:16):
But the so, if you delete the entire repo, then
you know, say it was private and nobody's forked, then
it should be gone. But individual branches are not truly
deleted within a repo that's still up.

Speaker 4 (23:32):
Yeah, the repo's up then then the commits, the then
specific commit hashes if you know, those hashes will allow
you to recover the data. So, uh, the question is
how do you find that hash. I'm not an expert
in this stuff, so I'm kind of uh talking mostly

(23:52):
based off of some research I read that was put
out by the truffle Hog team. You know, a truffle
hog is like a security tool that lets use for
tokens and secrets in things like get ub repos and
they've done a lot of research on this area. So
if if you search for their blog, you can kind
of find out find out some of this stuff that
Dylan Iri.

Speaker 3 (24:12):
Is the the.

Speaker 4 (24:13):
Founder and creator of that project over there, and it's
where I kind of learned most of the stuff from.
But yeah, I think so the short version is just
if it's if if you've ever pushed it up to
get hub, assume it's gone and you know, assume it's
out there, and then there is a there is a
way to kind of contact support and get those those
commit hashes removed.

Speaker 5 (24:31):
But you you know, you you should just you should
still obviously rotate the tokens and you know, revoke them
if you can, and try to try to assume all
that data is just gone even even if you do that.

Speaker 3 (24:45):
Right, Yeah, I don't know how it works get lab.
That's that's another that's another interesting question though.

Speaker 4 (24:52):
Yeah, so, uh, do you want to talk about the
uh the chalk one now?

Speaker 1 (24:56):
The ones that go to yeah, okay in regards to
another two f a email reset and being compromised.

Speaker 4 (25:04):
Yeah, that's right. That one was was a similar email.
This time the email originated from support at npm JS
dot help.

Speaker 3 (25:13):
So, uh, I don't know. I I kind of feel
like that.

Speaker 4 (25:15):
Email is obviously not not not legit, but that then
that said, you know, there are a lot of companies
these days.

Speaker 3 (25:23):
Using these these interesting new TLDs.

Speaker 2 (25:26):
And is help legit?

Speaker 3 (25:28):
Is that a?

Speaker 2 (25:29):
Is that a tl D?

Speaker 3 (25:30):
I suppose it is? Yeah, let me see uh Google
really quickly.

Speaker 1 (25:33):
Here, Yeah, Google looked. There's so many it's hard to
keep track from all.

Speaker 3 (25:37):
Yeah, it's like any word, you know. The one that
really the world only really.

Speaker 4 (25:40):
Still bothers me that they made it to a TLD
is dot zip because now you can Yeah, you can
have a file name that's like dot zip and you're
just typing it out the name of it and then
it'll get it'll automatically turn into a link in a
lot of programs now and it's like, yeah.

Speaker 3 (25:54):
I'm trying to do here.

Speaker 4 (25:56):
Yeah, but anyway, uh yeah, so so so it. But
I think, you know, again, like the phishing email stuff,
it's really effective, surprisingly effective. Even people that are security
experts fall for this stuff sometimes. So I don't want
to put any blame on the on the maintainer. The
only thing I'll say is, like, you know, phishing resistant
to FA would have would have solved these problems. And
so for those who don't know what is fishing resistant

(26:17):
t FA, I'm just going.

Speaker 3 (26:19):
To ask that. Yeah.

Speaker 4 (26:21):
So two FA is just you know, a second factor right,
second factor to two factor authentication. It's just the idea
that you provide, you know, some other evidence that you
are who you are besides your password. Typically you'll see
things like a time based code, or you'll see like
a text, like a two factor a text or by
another app or something like that. That's all great, it's

(26:41):
better than than just having a password alone. But the
gold standard what you really want to have is phishing
resistant TUFA. And what that is is it's basically a
two FA method that is resistant to phishing attacks.

Speaker 3 (26:55):
What does that mean?

Speaker 4 (26:55):
That means that there's no way to trick a person,
a human ofulnerable, you know, human to take that to
a fake token and to put it into the wrong website,
to put it onto a fake website. So how is
that enforced. Well, let's let's take a simple example of
one of those methods.

Speaker 3 (27:12):
It would be a UBI key.

Speaker 4 (27:13):
So for those who haven't seen them, they're the diesel
you know, hardware tokens that you can.

Speaker 3 (27:17):
You can buy it.

Speaker 4 (27:18):
I've used those, yeah, yeah, So what's what's one of
the best things about those is that they will refuse
to give up the you know, the key material to
the wrong domain. So if you're on a fake website,
you're on a fake NPM website and you you ask
that you know, you touch the key and you ask
it to provide key material, it won't provide the key
material to the wrong domain. It's going to provide different

(27:41):
key material to the to the attacker. So what that
means is that it can't be tricked. Right, it works
directly with the browser to enforce that it's you know,
providing material to the correct domain.

Speaker 3 (27:53):
And and so that's that's why it's awesome. The other
one you bought one of these.

Speaker 2 (27:57):
I've used these before.

Speaker 1 (27:58):
We had a fob, yeah, and they're there's another one
that I had and I can't find where it was.
I would plug it into a port on the laptop
and you had to touch it yep, like USBC type port.

Speaker 4 (28:10):
Yeah, So that the only kind it's it's all like
the real benefit of it is just that it it's
sort of the site get The site knows that, Okay,
I'm talking to the person who's in physical possession of
this device, so they know that, you know, someone some
attacker isn't unless they stole the device from you, right, Like,
what they're validating is that you have this physically in
your possession. But the other piece of it is the

(28:31):
fishing resistance. So the device is smart enough to not
give up the material to the wrong domain because it's
it's literally working with the browser to check the domain
and only provide it to the correct domain.

Speaker 3 (28:41):
So that's the kind of power of it.

Speaker 4 (28:42):
The other thing you've probably seen a lot more of
these days is past keys, and there's a lot of
sites that are prompting you now for past keys. And
for a while I was like another thing I have
to learn. But but past keys are also really cool.
Passkeys have the same property in that they uh, it's
it's working with either your you know, your your pastor

(29:04):
manager or your operating system to store this pass key.
And this pass key will only ever be given up
to the correct domain. So again it's fishing resistant. It
can't be tricked to you know, it won't get entered
into a into a fake site.

Speaker 1 (29:18):
So appractically if I'm wrong, But a pass key is
is specific to the device, right, So you can't have
one key passkey that you use in multiple places or
is that wrong?

Speaker 4 (29:28):
It does lock you to a device in theory, although
I can, like I have one password and I put
my pass key into my one password, and you.

Speaker 2 (29:35):
Can do that.

Speaker 3 (29:35):
Yeah, you can do that. Yeah, And in that way,
if you get a new device or you get a you.

Speaker 4 (29:40):
Know, like I can set up my pass key once
on my computer and then when I'm on my phone,
I have my one password there as well, and I
can just log into the same site. I don't have
to keep binding numerous pass keys on every device and
do it all over again when I get a new device.

Speaker 1 (29:54):
Yeah, because I have that same setup because we use
one password at work and I use it like for
a DP which is our you know, personal HR management stuff,
and I use it there all the time with you know,
with the fingerprint you know on my MacBook, which is
tied to one password which then gets me in.

Speaker 2 (30:09):
But I didn't realize I could use that across devices.
That's cool, Okay, yeah.

Speaker 3 (30:13):
I think you can. So I'm not sure that the
standard is very complicated.

Speaker 4 (30:16):
There might be a way that some sites can like
prevent you from putting your pass key into something that
has cloud sync, but don't quote me on that.

Speaker 3 (30:26):
I'm not I'm not, like, I just know there's.

Speaker 4 (30:27):
A lot of complicated options, and sites can demand certain
properties of the of the device, of the.

Speaker 3 (30:33):
Of where the pass key is being stored.

Speaker 1 (30:35):
But generally Mike had I already put it on Twitter
Frost said that pass key I'm kidding.

Speaker 4 (30:41):
No, it's a bit but but but in my experience,
I can basically put a pass key into one password
any any any any.

Speaker 3 (30:47):
Any time I've been prompted, So it's pretty cool.

Speaker 4 (30:50):
So anyway, the reason I bring all that up is
just to say that like like basically, like the the
maintainers wouldn't have been able to be tricked if if
NPM had mandated to f A with this fishing resistant property.
So it's somewhat disappointing that, you know, this was, you know,
somewhat preventable, you know, if NPM would have been willing
to kind of force this on maintainers, which is, you know,

(31:12):
I'm not saying it's costless.

Speaker 3 (31:14):
Obviously, there's there's some cost of kind of making everybody.

Speaker 4 (31:16):
Go through this, but but for prolific maintainers with access
to you know, billions and billions of downloads per week,
you know, I think it's it's probably a it's obviously,
in my opinion, a good trade off to make those
maintainers take this extra step. So what happened here was
this Kicks maintainer was compromised, he fell for the fishing attack,

(31:38):
and then he had access to a lot of Cinder
sources packages and cinder sources. An awesome, amazing prolific maintainer
who has some of the most useful and.

Speaker 3 (31:47):
Popular packages on NPM.

Speaker 4 (31:50):
Power is a huge, huge portion of the job script ecosystem,
and so that compromise was was able to get able
to allow the attacker to insert some code into those packages.
In this case, the code was a scrypto stealing code.
So it worked by hooking into the fetch API and

(32:10):
the xml httpeer quest API and various like wallet provider APIs.
And so what it did was it was if you
called those functions in your in your front end of
your site, it would be able to be able to
rewrite the transaction data and replace the legitimate addresses with
tackle control addresses. So they were just actively trying to

(32:30):
you know, insert themselves in the flow and like make
sure that you sent the money to them instead of
to your intended recipient.

Speaker 1 (32:38):
Yeah. I remember when that came out, there was a
bunch of them, and by the time we got notification
and looked, I know that.

Speaker 2 (32:46):
Uh was I talk.

Speaker 1 (32:48):
That's the one that comes to mind. I know there's
some other libraries that already had an updated version. I
think they'd rolled back to a previous commit or something
like that. I don't remember how they did it. And
so if you installed that then you were pretty good.

Speaker 3 (32:59):
Yeah, but this was a lot of popular packages.

Speaker 4 (33:01):
There was like chalk color packages, debug it's a big
one that people use.

Speaker 3 (33:08):
I use dbug.

Speaker 4 (33:10):
Yeah, so there's just a lot of these, a lot
of like low level, widely widely used packages.

Speaker 2 (33:16):
Sort of a left pad type thing again.

Speaker 4 (33:18):
Yeah, yeah, exactly. Yeah, So that was that was a
very big one. Fortunately it was only live for like
four hours, but if you were unlucky enough to install
during those four hours, you know, you were you were affected.
So this is kind of what why like we started
stock it to be totally honest with you, because it
seems like everybody is like reactive to these things. You know,
Oh I read about oh chalk was compromised. Oh let

(33:39):
me check my system. Did I install the vulnerable version
or the malicious version? And then you just kind of
hope that you were lucky enough to not have run
an NPM update during that window of time. And it
feels like, you know, we got we ought to be
able to do better than this as a community, you know,
as a as an industry, like we can you know,
I mean fundamentally, the problem is we're installing code that

(34:00):
we haven't evaluated. We haven't looked at the code that
we're running. That's really what it comes down to is
we're hitting install, we're pulling code.

Speaker 3 (34:06):
In on the internet. We're not looking at it and
then it's we're executing it.

Speaker 4 (34:11):
So that's where I think, you know, treat treating this
code differently, treating it as something that's part of your application,
that is your responsibility, is something that isn't just a
black box. It can can change, can help you know,
change change this sort of risk profile.

Speaker 3 (34:28):
Here, or you know, you can use a tool to
help you.

Speaker 4 (34:31):
And that's what we try to help is looking at
the at the code for you, using a bunch of automation,
a bunch of static analysis, and a bunch of l
ll M kind of like AI analysis to find these
attacks even before uh, you know, anyone else, anyone has
kind of discovered these, Like we're we're scanning of the
automated in an automated manner, all of NPM as well

(34:52):
as all of a bunch of the top ecosystems like
the Python, dot Net, Rust, Ruby, Goo, Scalah, et cetera.
So yeah, so then hopefully you know, we can we
can sort of be in the middle of that and
and and and and prevent those those packages from getting
on your system. Yeah, So that's that's that one, and

(35:18):
then there's there's a few more that came after that.

Speaker 3 (35:20):
If you're if you're interested to kind Oh, let's.

Speaker 2 (35:21):
Keep going, keep going.

Speaker 1 (35:23):
Okay, it sounds like I knew about that last one,
the one Chalk, that's all. But you were telling me
about the newer ones that I apparently haven't heard, so
I want to hear about them.

Speaker 4 (35:35):
So after the after the Chalk one, there was another
one that followed the following day, uh, compromised this project
called duck dB, which has three hundred thousand weekly downloads.

Speaker 3 (35:43):
And that one duck dB. Yeah, and you did hear
about it.

Speaker 2 (35:49):
Okay, well, no, not that, I mean just duck dB.

Speaker 4 (35:51):
It's a it's a the tool itself, right right, Okay, Yeah,
And this one was was the same attacker as the
day before, so this was exactly the same malware that
effect Chalk. So this one was clearly the same person.
And then the following week there was another set of attacks.
And this kind of brings us towards the end of
the story. So this one was interesting because it affected

(36:14):
another color library. I don't know why it's always a
color library, but it was a color library called tiny Color.
And on the Monday of September fifteenth, that hit about
forty packages and basically the thing that made this attack
interesting was that it searched your system for so the

(36:40):
malar searched your system for NPM tokens, and if it
found an NPM token, it wouldn't just steal it. It
would actually figure out what are the packages that that
token gives access to. It would download those packages the
tar ball, you know, the actual code of the package,
and it would insert like itself, it would replicate itself
the malware into that package and then publish it back

(37:03):
to NPM. So if your package as a as a
new version of the existing.

Speaker 2 (37:08):
Package, oh wow, okay, so.

Speaker 3 (37:11):
If you like, like if if you were affected, you
would you would.

Speaker 4 (37:14):
Not just have your NPM token stolen, but all your
NPM packages that you maintained that you have access to
would be infected with the same malware, so that it
sort of spreads like a virus, like a worm, through
through all of NPM. And so within like a day,
so by by Tuesday, September sixteenth, By the following day,
five hundred packages had been affected by this. It just
spread like a like a worm, completely through NPM, infecting,

(37:36):
infecting like even some some pretty uh like surprising packages
like crowdstrikes packages, which is a security company that like
a lot of people use, one of the.

Speaker 3 (37:47):
Largest security companies.

Speaker 4 (37:49):
So it's just interesting to see how wide, uh this
kind of spread before it was before it was.

Speaker 3 (37:54):
You know killed.

Speaker 1 (37:56):
So I'm looking at the blog post on your side
about this when I believe it is a shi hulud
or is that.

Speaker 2 (38:03):
The one you're talking about?

Speaker 3 (38:04):
That's right?

Speaker 4 (38:04):
Yeah, okay, yeah, so the malware they called it that
because of I think as a reference to the Dune.

Speaker 2 (38:14):
Oh that's right, Okay, I did hear that. I remember that.

Speaker 3 (38:18):
Yeah.

Speaker 4 (38:20):
Yeah, this was like the first line with that out
there before it got probably like two days or so.

Speaker 3 (38:25):
It was probably like a couple of days it was
out before it was caught. Report was fully shut.

Speaker 2 (38:29):
Down because it's a long time.

Speaker 3 (38:31):
Yeah, they kept.

Speaker 4 (38:33):
Changing the malware, like the actual payload, so that there
was like six or seven different versions that we were
able to identify across the different packages. So you know,
they kept evolving it to make it a little bit
better and fix different bugs in the worm. But the ultimately,
you know, was kind of petered out I think due

(38:53):
to kind of once NPM realized once you know, we
had we and others had reported at ten PM. I
think they have helped helped shred it down. So yeah,
I mean, it's it's it's it's funny because like this
concept of an NPM worm had been known about and
talked about for several years before this happened. Like there'd

(39:13):
been some some folks that had written posts about like, oh,
I could make a worm and it would take over
all of NPM and in a day. And you know,
they just just blog posts on this that you can
find find where people are you know, good, good, good
folks like good maintainers were sort of speculating about this
and writing about this, but we'd never actually seen it happen.
So it seems like the attackers finally like realized that
they should try to do that and and and you know,

(39:37):
and it worked to some extent. I think that the
issue with all these things though, is that they're so
noisy that they end up being caught by the community
or by security companies like Socket pretty quickly.

Speaker 2 (39:48):
Uh.

Speaker 4 (39:48):
And once once people are aware, then you know, we
can put blocks in place for all of our customers
to prevent them from bringing those in. And and then
you know, once the registries alerted in there and if
they're on top of things that can help shut these
things down. So the real kind of reason we've been
so lucky as a community that these things haven't been
more deadly or more dangerous is that the attackers have

(40:11):
been kind of noisy, i'd say, like loud and noisy,
maybe a little clumsy.

Speaker 3 (40:15):
In the way that they've done these attacks.

Speaker 4 (40:17):
If you were smarter, you would actually be sneakier, and
you would you know, try to last for several weeks
or months without detection and then you know, and during
that time kind of spread far and wide, whereas these
things keep getting shut and shut down in a few hours.

Speaker 3 (40:32):
And so, yes, it still affects a lot of people.

Speaker 4 (40:34):
I mean, if you have a package with billions of
downloads and it's live for four hours, that that's still.

Speaker 3 (40:38):
Going to hit a lot of people.

Speaker 4 (40:40):
But I think it would be much worse if it
had been live for weeks, right, And that's kind of
why I think they're failing to do right now today.

Speaker 1 (40:47):
Yeah, I can think of, you know, not necessarily the
same thing, but in terms of data hacks or intrusions,
you know that they find that have been around for
months or you know, Microsoft, I thinks had a couple,
and there's other ones that could to mine where they've
been in there for months, you know, like, oh, good lord,
they've had time to find everything.

Speaker 3 (41:04):
M yeah, totally.

Speaker 1 (41:08):
So I'm just thinking that sort of a you know,
back to your two edged sword. It's like, Okay, you
create a product of the great product.

Speaker 2 (41:16):
Everybody's using it.

Speaker 1 (41:17):
Now your responsibility increases with that too, to to you know,
to protect your users, because I think I think of
a lot of us assume oh MPM. Everybody's pushing packages
the MPM. It must be safe. They're not any problems, right.
But you were talking about the uh, the blog posts

(41:37):
that you know, people had written, say hey, I wonder
you know, I wanted to write a worm, I could
do this and this. So were those in retrospect that
you know, people noticed those blog posts that people had
been writing, or was that you know, people had been
somehow bad guy just read it, you know, saw those
and said hey, let's try it. But was it in
retrospect that people said, oh, yeah, somebody had been writing

(41:58):
about this for a while, we should have done something
about it.

Speaker 3 (42:03):
I think that likely the attackers probably just independently thought
of it. I mean, so many I don't know, I mean.

Speaker 4 (42:10):
Who knows, but I feel like I feel like this
is the kind of thing that if you have the
attacker mindset or the security mindset that you know, you
think of these things just for fun all the time,
like you.

Speaker 3 (42:21):
Know, I mean, like hackers are.

Speaker 4 (42:25):
You know, it's it's obviously that all the things we've
been talking about in this podcast are all bad in
the sense that they're all you know, stealing data and
it's all it's all crimes. But there's another angle by which,
you know, hacking more generally is is kind of this
creative endeavor, you know, where you're trying to find a

(42:46):
gap between the written rules of a system and the
actual rules of a system. So the written rules of
the system say, you know, like yeah, n PM's a
place you publish code, and you know it's you know,
you know, legitimate, only legitimate people can publish code there,
and you know therefore you can.

Speaker 3 (43:03):
Kind of rely on it.

Speaker 4 (43:04):
But the actual rules of the system are you know,
there's any ways to get access to packages that you
shouldn't have access to, and and kind of the attackers
and these hackers are good at seeing those gaps, and
that's that's really what hacking is is seeing these these
gaps or these differences between the way the way the
system is supposed to.

Speaker 3 (43:21):
Work, the way that works on paper, and the way
that it actually works.

Speaker 4 (43:25):
And so I think any kind of creative mind or
you know, good hacker mind could could have thought of
something like this, this worm, and it's just a matter
of you know, who's going to think of it and
who's going.

Speaker 3 (43:35):
To do it. So that's why there's als be more attacks.

Speaker 4 (43:37):
I mean, that's why security is interesting really, to be
honest with you, Like, I love it because it's always changing.
You have you have an adversary that's evolving and changing.
You know, if you learn like architecture or you learn
you know, pick your peak, your whatever field that you pick.

Speaker 3 (43:53):
Like, you know, the laws of gravity don't change.

Speaker 4 (43:57):
So if you know how to build a bridge today,
you know you know how to build a one hundred
years from now. Like, it's the same constraints, gravity is
the same physics, it's basically the same, right, Whereas in
security that's not true. You have this sort of intelligent
opponent who is adapting to what you do. And so
it's a dynamic system. So it's kind of exciting in
that way.

Speaker 1 (44:17):
Yeah, the term I've always used as a cat and
mouse game, right, yep, Yeah, you know you mentioned that
the old blog posted it brought to mind about I
think it was twelve years ago. I was working on
Drouple and maintaining some Drouple sites for a for an organization,
and there was a bug that came out that got

(44:39):
put in there and it was referred to as Drupal
gedding because it was so bad that if your site
got infected, you basically needed to start over with your
database and somehow, you know, import it from somewhere else.
And somebody went back in the in the issues history
for the particular module or a piece of code that

(45:02):
got it and found where somebody had filed the bug
report that said hey, and it all had to do
with an array that was passed in and how I
had handled reading values out of an array. It was
something super simple, just a couple of characters, and they
had said, Okay, this issue is here. If somebody figures
this out, we could be in some serious trouble. And
somebody figured it out and nobody fixed it and ended
up being just a huge, huge thudge thing. But you know,

(45:25):
I was just thinking in terms of bug happens, somebody
goes back, Oh yeah, somebody raised US flag a while ago. Right, yeah,
I mean that hindsight is twenty twenty right in anything in.

Speaker 4 (45:35):
That in that sense, I mean, I guess yeah, I
mean NPM has known about this risk for a while,
but it's it's difficult. I mean, I don't want to
keep all the blame on the on them.

Speaker 3 (45:44):
I do. I do think that there's definitely some blame.

Speaker 4 (45:46):
But like like with all things, there's blame to go
around in kind of every every points of different places, right,
you know, different people were at fault. But like, but
it's a hard problem because you know they're balancing like
usability of the package manager and you know, wanting to
make publish workflows flexible for people like I mean, you know,

(46:06):
it's useful to have to be able to have a
get a action that can publish new versions of your
package to ten PM, you know when without having to.

Speaker 3 (46:14):
Run that locally on your system.

Speaker 4 (46:15):
And if you try to do like a two FA there,
you know, now you can't have automation. You can't have
you know, uh, you know, you can't automatically do releases
when you know when certain you know, you know, when
when commits land and stuff like that. So a lot
of like the maintainer workflows would be affected by by
like a sort of a night you've change like that.
So that and then there actually already has been pushed

(46:36):
back to some So the NTEAM has actually done some
things in the in the last couple of weeks to
address these attacks. They made some security changes, but even
those modest changes that they're making have gotten like a
lot of pushback from maintainers who don't want to deal
with you know, deal with the extra steps.

Speaker 3 (46:51):
And I don't blame them, I mean, it's it's annoying.

Speaker 4 (46:53):
It's just this direct trade off of security and usability,
which we always see.

Speaker 1 (47:00):
All right, So we're getting close on times how we
got a couple more recent incidents.

Speaker 3 (47:05):
We made it through all of them, the ones that
we want it through all of them. Well, there's always more.

Speaker 4 (47:09):
I mean, I can tell you there's probably like there's
we find stuff every day, Like I could tell you
about something we found probably an hour ago, like we
were always blogging about this stuff on Soccer contpt on
our blog. So but just in terms of like the
the sort of really big ones. Over the last little while,
I think I think we covered all the main ones.
I don't want to get into like every little piece
of malware. But maybe that is itself interesting to you.

(47:31):
I don't know, cause, like you know, just the idea
that this stuff is actually not it's not just when
you see it in the news that it's happening.

Speaker 3 (47:37):
Like there is this constant.

Speaker 4 (47:39):
Low level burn of daily malware, like dozens and sometimes
hundreds of malware packages being pushed every day to these registries,
and we're always out there looking for this stuff, trying
to get it taken down, trying to protect people. So yeah,
shout out to the to the socket Threat team for
doing such a great job like looking for these hunting

(48:01):
for these things.

Speaker 1 (48:01):
And well, yeah, let's segue into that, since you've given
us all this information, we'll do some shameless plugging here.
So why don't to talk about socket dot dev not
io and look at tell us just about what you
do big picture, and then some of the products that
you offer to help with help.

Speaker 2 (48:24):
You avoid these issues that we just talked about.

Speaker 4 (48:26):
Yeah, so our whole mission is to help developers protect
themselves from exactly the kind of stuff that we've been
talking about. So we started in twenty twenty. We've been
working at this for a while. Today we find around
a thousand malicious open source packages every single week across NPM,
Python and about eight other ecosystems that we track. So

(48:49):
we're just trying to help developers stay safe. And there's
a couple of ways that developers can use socket to
stay safe. I'll mention actually the newest one, which is
I want to actually very excited about, called Socket Firewall,
and this is a free product that anyone can use.
It's really easy to get started with it. You just
NPM install SFW, which stands for Socket Firewall or stands

(49:13):
for Safer Work I guess depending on your.

Speaker 3 (49:18):
You're the way you look at it. But once you
install SFW, all you have to do is.

Speaker 4 (49:22):
Run your normal package manager commands, but you just prefix
it with SFW, So for instance, you'd run s FW
NPM install, FOU or SFW NPM update or SFW PNPM install.

Speaker 3 (49:37):
Or yarn ad.

Speaker 4 (49:38):
It works with everything, works with Rust and Python and
on all the jobscript package managers. And what will happen
is everything will install like normal, except for if you're
about to install something that's been compromised. So it's really
like a filter on the packages that come in. And
if we've identified that there's malware in any of those
packages or threats that you know could affect you, just

(50:00):
basically prevent them from coming in and we'll print a
message telling you this package was blocked for blah blah
blah reason.

Speaker 3 (50:06):
So it's very simple to use. It's totally free.

Speaker 4 (50:09):
People can just install it and start using it, and
we're just giving it away to the community to help
people stay protected.

Speaker 1 (50:14):
Oh okay, yeah, here, it's not listed on your products,
but I see the blurb at.

Speaker 2 (50:18):
The top of the page there.

Speaker 3 (50:20):
Yeah. We just announced it literally last week, so it's
it's exciting.

Speaker 4 (50:23):
I mean, we we are gonna we do have a
paid version of it for people that want to roll
it out at their companies. Like you can deploy it
in a in a server fashion, so instead of it
being a wrapper around the package manager command, you can
actually deploy it as like a server and then you
can point your your your different like package managers to

(50:44):
that server as a as your registry, so you can
kind of set the registry to be the socket.

Speaker 3 (50:50):
Firewall, and then it'll like work in that fashion.

Speaker 4 (50:53):
So so folks can look into that if they're interested
in like using another company. But the free version is
really powerful and like does everything that folks need to
do to protect themselves today. And I recommend that people
actually alias it so you can alias it in your
shell so that when you type NPM, it just runs
a s FWNPM behind the scenes and so you don't
have to remember anymore. You just put that in place

(51:14):
once and then you just protected forever.

Speaker 2 (51:18):
Awesome. Yeah, you can see the details on Socca dot dev.

Speaker 3 (51:24):
Yeah, and it's really it's really cool. Yeah, people should
definitely check it out. Sure feedback.

Speaker 4 (51:27):
We tried to make it work really really well, and
it works with NPM, YARN, PNPM, PIP, cargo.

Speaker 3 (51:39):
And UV.

Speaker 4 (51:40):
There's a bunch of different package managers that works with
so cool. Yeah, and then the other thing people can
do is our main product, Like this is the main
thing we've been doing for like you know, years now.
This is our bread and butter is we have a
GitHub app or a CLI tool that you can use
to scan your projects and protect your projects.

Speaker 3 (51:58):
So if you're on GitHub, it's really easy.

Speaker 4 (52:00):
You just go to socker dot dev, you hit install
socket and it'll give you like two clicks. You'll just
ask you if you want to install this on your
gi hub organization. And once you do that, then all
your pull requests will automatically be protected. So if we
see you about to upgrade to a bad package, we'll
be able.

Speaker 3 (52:18):
To put a comment on that poll request and.

Speaker 4 (52:21):
Tell you why this package is risky or why you
shouldn't use it, or what would be a better alternative
and all that kind of information. So, and it's all configurable,
so you can go in and sort of tell it
I really care about, you know, preventing deprecated packages from
getting into our project, and then it'll warn you if
you're bringing in a new package that's deprecated, or you

(52:41):
could say, I really want to prevent unmaintained packages from
being brought into our project. And then we'll be able
to tell you when someone on your team is bringing
in a package that hasn't had an update in five years.
You know, we'll be able to print a little comment
and say, hey, this package hasn't an update in five years.
Are you sure you want to use it? And it's
up to you. You can block in that case, or
you can just warn and let them, let them decide
how they want to handle it.

Speaker 3 (53:02):
It's really all up to you. So it's pretty.

Speaker 2 (53:04):
Powerful awesome all right.

Speaker 1 (53:09):
So before we get into picks, obviously we know about
soccer dot.

Speaker 2 (53:14):
Dev and your blog on there.

Speaker 1 (53:17):
Where else can people hear what you have to say
or give you money or anything like that?

Speaker 4 (53:24):
Uh yeah, just check out check out soccer dot dev.
I'm personally on x and the different social media platforms
masted on, loose Sky all that stuff. My name is
just Faross F E R O S. S. And then
socket socket is is on there too under socket security. Yeah,

(53:45):
and I mean also just shout out to or let
people know like that. If anyone is interested in this
stuff and wants to talk about security or you know,
uh how to how to stay safe while using open source,
just hit me up. I'm happy to like to talk
about this with people, even separate from like becoming a
soccer customer. I'm I also have been a lecturer and

(54:06):
like a teacher in the past, so I love talking
about this stuff. So if if anyone listening wants to
kind of learn more about like what they can do
to protect themselves from these types of attacks, or just
wants to like hear more about the latest stuff that
we're seeing that I'm seeing. Let me know, I'm happy

(54:27):
to kind of consider doing a talk at your company
to your developer team and just talk about these issues,
not like a product pitch or anything, but just talking
about supply chain security. I like to do that from
time to time. So if you think your your company
would be interested, let me know, I'm happy to help.

Speaker 1 (54:45):
All right, Well, I don't I wouldn't have any problem
with shamelessly plugging your company considering all the information you're
putting out there.

Speaker 2 (54:53):
So so thanks. Yeah, we're trying advertising, we're.

Speaker 3 (54:57):
Trying to do the right thing.

Speaker 4 (54:58):
And like you know, all of our data is public
to you know, you can you can go to a
socket and search for any package and just we'll give
all the data back to you, so you'll see all
of our scores and all the findings and whether it's
safe and different risks and quality issues and it's all open.

Speaker 3 (55:12):
So yeah, we're just trying to trying to be useful.

Speaker 2 (55:16):
All righty, So with that we will move into picks.

Speaker 1 (55:19):
Picks are part of the show where we get to
talk about whatever we want to within reason of course,
you know, books, movies, games, Chuck likes board games. Uh,
you know, tech could be non tech, could be whatever.

Speaker 2 (55:32):
I always like to say. I'm the high point of
these with my dad jokes of the week. So we'll
start with.

Speaker 1 (55:38):
That and then let for us save the best for last,
well almost the best for last. So anyway, a Roman
walks into a bar, holds up two fingers and says,
I'll have five beers, please.

Speaker 3 (55:56):
The numerals. If you're wondering, yes, actually thanks.

Speaker 2 (56:00):
A few people have said that to me an observation.

Speaker 1 (56:07):
Humans are the only species that will cut down trees,
make paper out of them, and then write save the
trees on it. And then the other night my wife said, honey,
why is there a strange baby in the crib? I said,
you told me to change the baby.

Speaker 2 (56:28):
Thank you. Those are the dad jokes of the week.
All right for us? What do you have for us?

Speaker 3 (56:35):
I have a few picks. One is a book.

Speaker 4 (56:39):
I read picked up last weekend called The Power of Now,
which is interesting.

Speaker 3 (56:45):
It's about kind.

Speaker 4 (56:46):
Of the idea of like living in the moment, being present,
and it's kind of like a spiritual kind of a book.
But I thought it was it was very interesting it's
it's it's really a simple idea that, like, you know,
your entire life is experienced in the moment, but yet
we spend so much time thinking of the past or

(57:08):
thinking of the future. And I'm someone who spends a
lot of time thinking more about the future than the past.
I don't tend to dwell on things, but I do.
I do worry a lot about, like, you know, what
I want to do, what I want to accomplish next,
Like what am I working on? I like to work
a lot, and and so I just thought it was
very eye opening kind of reminder that, you know, it's
not it's not a good idea to live your entire

(57:29):
life just thinking about you know what's to come, but
like actually take a breath and appreciate, you know, how
how awesome the current moment is. And and so anyway,
I recommend folks look at that if if they that
resonated at all.

Speaker 3 (57:44):
And my other pick will be just a.

Speaker 4 (57:46):
Classic book I always go back to you every few years,
which is the Enders game series. The Enders game series
is excellent, and even the prequels are are just amazing.

Speaker 1 (57:59):
So uh, I've heard about those, Yeah, and what kind
of book is that is that?

Speaker 2 (58:06):
Is it like sci fi?

Speaker 3 (58:06):
Is it? Yeah?

Speaker 2 (58:09):
What is it?

Speaker 3 (58:10):
It's sci fi? It's sci fi.

Speaker 4 (58:11):
Yeah, so it's it's uh, you know, it's about a
lot of people at bread enders game, I think, but
if they haven't. It's basically about a kid who has
to go into space and learn how to become like
an insanely competent commander of fleets so he can defend
Earth from an alien invasion that's coming. Uh. And the

(58:33):
series is like kind of it goes in the future,
it goes into like a really different direction, and it
goes like two thousand years into the future and follows
this this this is the kid as he kind of
travels through the Solar System and encounters like different new
alien species.

Speaker 3 (58:48):
Uh. And then the prequels are about kind of the.

Speaker 4 (58:51):
Earlier attacks that the aliens did on Earth and the
kind of the people, the humans that kind of fought them.
And it's just I just like the writing style a lot.
I think it's really media and really simple, clear, crisp,
like fast moving language. It's just a really a joy
to read it. It's like a really fun, fun read.

Speaker 2 (59:10):
Awesome is that it?

Speaker 3 (59:13):
Yeah? I'm supposed to more than two picks. No, no, nope.

Speaker 1 (59:16):
Some people just have one. Some people are like, I
don't have any, so I'll shut it out.

Speaker 4 (59:21):
I'll add a final one, which is just a reminder
for people to to NPM install s FW and check
out Socket Firewall, which we recently released. And please send
us your feedback if you run into any problems or
where you think it's awesome.

Speaker 3 (59:34):
Or you you you know.

Speaker 4 (59:36):
Use it at work or anything like that, let us know.
It would be awesome to get people's feedback on that.

Speaker 2 (59:41):
Cool.

Speaker 1 (59:42):
All righty well, thank you for coming back for us
and telling us about what's been going on in the
web safety world, or in some cases, the lack of
web safety. And thank you for listening to JavaScript Jabber
and we will talk to you next time.

All Episodes

Guarding the JavaScript Supply Chain: Preventing NPM Attacks with Feross Aboukhadijeh - JSJ 695

Episode Transcript

Popular Podcasts

Dateline NBC

Stuff You Should Know

The Breakfast Club

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}Guarding the JavaScript Supply Chain: Preventing NPM Attacks with Feross Aboukhadijeh - JSJ 695