►
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
Keynote: Securing JavaScript - Myles Borins, Product Manager, GitHub
Speakers: Myles Borins
The npm registry is the heart of the JavaScript ecosystem. Hear about the steps we've taken at GitHub to secure this important part of the software supply chain from enforcing software solutions such as automated malware scanning to policy such as enforcing two-factor authentication for high-impact packages. This talk will cover what we've shipped to respond to an increase in threats to our ecosystem and what we are working on next.
A
My
planes
were
delayed
constantly,
but
I'm
here
now,
which
is
great
before
I
start
I'd
love.
If
we
could
all
just
give
a
big
round
of
applause,
you
don't
see
it,
but
there's
a
bunch
of
people
behind
this
screen
working
tirelessly
to
make
today
awesome.
So
if
you
could
just
do
a
really
big
round
of
applause
for
all
of
them,.
A
A
I
do
this
for
a
while.
I
wait
for
people
to
laugh.
That
gives
me
a
sign
that,
like
it's
going
to
be
a
good
audience,
this
talk
actually
has
a
lot
less
jokes
than
usual,
but
let's
dive
right
into
it.
Npm
is
a
critical
tool
in
the
open
source
supply
chain
just
to
show
our
hands
how
many
people
use
npm
at
least
once
a
week.
A
So
that's
a
few
of
you
and
there's
various
threats
to
the
open
source
supply
chain
that
we
deal
with
npm
being
a
key
part
of
this,
where
we're
seeing
attacks
happen
and
one
of
these
kinds
of
attacks
that
I
want
to
talk
about
are
account
takeovers
or
as
I'll
call
it.
From
now
on,
atos
and
in
particular,
we've
seen
a
series
of
attacks
against
high
impact
packages
and
using
those
high
impact
packages
to
publish
malware.
A
A
One
of
the
authors
accounts
was
taken
over
they
injected
malware
into
the
package.
They
used.
The
post
install
script
to
deploy
that
malware
to
our
customers.
That
package
is
deployed
about
12.
It
has
about
1200.
Dependents
is
downloaded
about
7.5
million
times
a
week
and
it
took
us
about
9
hours
to
take
it
down.
A
couple
weeks
later,
the
packaged
co-op
was
hijacked
pretty
much
the
exact
same
story,
this
time,
less
dependence
only
166
dependents,
because
it's
a
little
deeper
in
the
tree,
but
over
nine
million
weekly
downloads.
A
Thankfully
we
had
a
response
time
of
30
minutes
and
I'll
talk
a
little
bit
in
a
second
about
how
we
were
able
to
go
faster
and
later
that
same
day
only
90
minutes
later
the
package
rc
was
also
hijacked.
This
one
has
13
million
weekly
downloads.
We
had
it
off
the
registry
within
15
minutes,
and
so
there's
a
couple
things
that
in
these
scenarios
we
did
right
for
the
mpm
registry.
We
have
malware
scanning
in
place.
A
A
There's
tons
of
packages
that
are
published
all
the
time
that
are
extremely
low
impact
net
new
packages
where
all
the
downloads
are
essentially
bots,
that
are
cloning.
The
registry,
when
we
have
so
much
noise
coming
through
it's
it's
hard
to
get
these
signals,
and
this
helped
us
come
up
with
this
concept
of
a
high
impact
package,
which
is
a
package
with
more
than
a
million
weekly
downloads
or
more
than
500
dependents,
and
we
introduced
between
the
first
incident
and
the
second
incident
a
couple
systems
in
place
to
notify
our
on-call
staff.
A
Whenever
high-impact
packages
have
malware
that
are
associated,
we
have
really
clear
policies.
A
lot
of
you
work
on
open
source,
so
you're,
probably
super
aware
of
when
you
know
things
happen,
and
you
need
to
make
a
decision.
If
you
don't
have
a
clear
policy,
you
can't
act
quickly.
We
had
extremely
clear
policies
which
made
it
really
easy
for
us
to
just
take
that
malware
down
and
not
have
to
mince
words
about
it.
A
We
have
automated
tooling
to
do
all
of
that
and
support
agents
who
are
powered
empowered
to
do
it,
and
our
product
teams
and
engineering
teams
also
have
the
ability
to
do
it.
So
we
use
chat
ops
for
a
lot
of
this.
So
taking
down
a
malware
package
is
a
single
command
in
a
chat
room,
that's
audited
and
maintained.
You
have
to
do
it
in
that
chat
room.
You
can't
just
do
it
in
any
chat
room,
but
it
made
it.
A
So
we
could
act
really
quickly
and
we
had
all
hands
on
deck
when
you
need
to
make
decisions
quickly
about
important
things
and
figuring
out
how
to
manage
it.
You
need
support
engineering
products,
security,
our
trust
and
safety
teams.
Our
incident
response
teams,
our
comms
teams,
all
of
them,
are
together
we're
all
in
sync
and
we're
able
that's
how
we
were
able
to
take
a
nine
hour
response
time,
make
it
a
15
minute
response
time
in
about
two
weeks,
and
we
learned
a
couple
things
right:
attack
account.
Takeovers
are
a
pattern.
A
This
isn't
going
to
change.
These
are
happening
a
lot
and
we
need
to
do
something
about
them.
That
time
to
response
is
critical.
Every
minute
that
those
things
are
on.
The
registry
is
a
minute
that
someone
is
potentially
downloading
it
and
having
their
system
compromised,
and
we
need
to
be
acting
as
quickly
as
we
can.
A
We
did
some
analysis
and
found
that
strong
two-factor
authentication
may
have
stopped
this.
If
we're
thinking
about
what
are
known
as
password
stuffing
attacks,
people
have
databases
of
usernames
and
passwords
and
they
just
try
them
all
and
see
if
one
of
them
hits
two-factor
authentication
other
similar
authentication
protections
make
it
much
harder.
They
raise
the
bar.
You
know
we'll
never
completely
protect
against
these
things,
but
it
makes
it
much
more
difficult
and,
and
finally
the
biggest
thing
we
learned
is-
we
need
to
stop
this.
A
It's
not
an
option,
we're
stewards
of
the
registry,
maintaining
this
extremely
important
part
of
the
software
supply
chain.
You
saw
how
many
hands
are
up
in
this
room.
It's
the
most
important
thing
that
we
can
do
not
just
as
like
employees
of
the
companies
that
pay
us,
but
as
like
stewards
and
members
of
this
community,
no
one
else
can
do
it.
It's
extremely
important,
and
so
we
came
up
with
this
goal.
A
A
We
are
in
the
process
of
introducing
and
implementing
mandatory
2fa
for
highest
impact
accounts,
but
you
can't
just
enforce
2fa
without
making
the
experience
great.
So
we
heavily
invested
and
made
our
entire
roadmap
about
improving
the
2fa
experience
and
improving
account
recovery,
because
the
more
2fa
you
have
in
force,
the
more
people
are
going
to
lose
their
second
factors,
the
more
people
who
are
going
to
need
to
recover
their
accounts.
There's
a
real
human
cost.
To
this,
too,
every
single
account
recovery
is
susceptible
to
social
engineering.
A
You
can,
you
can
put
everything
at
the
beginning
and
make
it
really
hard
to
log
into
an
account,
but
if
it's
extremely
easy
to
recover
that
account,
if
you
could
just
press
a
button
and
get
a
an
email
and
take
the
account
over,
the
two-face
is
not
useful
at
all.
So
we're
also
in
the
process
of
heavily
investing
in
improving
our
account
recovery
process.
A
I
mentioned
login
verification.
This
is
what
it
looks
like
you
go
to
log
into
an
account.
Now
that
doesn't
have
2fa
enabled
you
get
emailed
an
otp.
You
need
to
put
that
otp
in
there
for
those
of
you
who
work
on
accounts
at
all.
This
is
a
great
way
to
make
sure
that
everyone
has
a
verified
email
address,
a
little
life
hack,
but
every
single
account
on
npm
now
requires
this.
A
We
rolled
it
out
over
time
like
many
of
these
initiatives,
to
ensure
that
we're
not
locking
people
out
of
their
accounts
and
we're
minimizing
the
trend
to
our
ecosystem.
We
had
december
7th,
we
started
rolling
it
out
to
our
publishers,
so
these
were
the
accounts
that
are
actually
susceptible
to
account
takeover
and
have
it
be?
You
know
a
problem
between
december
7th
and
january
4th.
We
slowly
rolled
it
out
to
all
of
our
publishers.
A
We
didn't
initially
start
with
that
being
the
goal
at
github,
we
have
an
expression
called
ship
to
learn,
so
we
shipped
this
out
to
our
most
vulnerable
accounts
first
and
slowly
rolled
it
out
to
more
people
as
we
monitored
the
support
tickets
that
were
coming
in
monitored
for
bugs
and
problems,
and
when
we
saw
that
hey
this
isn't
really
causing
a
massive
issue
for
our
customers.
We
decided
to
roll
it
out
to
everyone
and
to
be
very
clear.
A
This
didn't
make
everyone
happy
and
you
can't
make
everyone
happy,
but
sometimes
you
have
to
do
things
that
make
people
unhappy
to
protect
the
greater
whole
2fa
enforcement.
Talking
about
doing
things
that
make
people
unhappy
to
protect
the
greater
whole,
we
needed
to
do
in
a
way
that
didn't
disrupt
our
important
maintainers.
So
saying
hey,
we
enforce
2fa,
that's
a
really
bold
statement
and
a
lot
of
the
subtlety
comes
out
of
the
details
of
what
it
means
to
implement
that
so
our
process
we
started
by
thinking
about
like.
Why
are
we
doing
this?
A
We
had
a
focus
on
account
takeovers,
so
we
worked
on
only
enforcing
2fa
for
creating
new
sessions,
but
we
made
it
so.
The
defaults
are
when
you
turn
on
2fa,
it's
enforced
for
both
creating
new
sessions
and
publishing
packages,
but
folks
can
opt
out
of
that
and
one
of
the
things
that's
most
important
about
that
is.
It
means
that
existing
access,
tokens
and
automations
that
are
in
place
by
our
customers
were
not
broken
by
this
enforcement.
A
We
did
a
phased
rollout
which
I'll
show
in
a
second.
We
didn't
do
it
to
everyone
all
at
once.
We
started
with
the
maintainers
of
our
top
100
packages.
We
expanded
to
the
maintainers
of
the
top
500
packages
and
before
the
end
of
the
year,
we'll
roll
it
out
to
all
of
the
maintainers
of
high
impact
packages
and
those
groups.
I
won't
share
the
exact
numbers,
but
you
know
there
was
a
bit
of
like
kind
of
an
order
of
magnitude
between
each
one
of
those
groups
which
allowed
us
to
do
a
phased
rollout
gather.
A
Customer
feedback
and
understand
you
know,
is
this
working?
Are
there
changes
that
we
need
to
make?
And
finally,
was
this
concept
of
maintainer
first,
which
is
closely
aligned
with
a
github
ideology.
We
have
of
you
know,
being
a
customer
obsessed,
we
needed
to
make
sure
that
what
we
were
doing
was
protecting
folks,
but
also
that
it
wasn't
heavily
disrupting
them.
As
I
mentioned,
we
didn't
invalidate
existing
access
tokens.
We
have
this
thing.
We
called
limbo
so
if
an
account
gets
put
into
a
2fa
enforcement,
but
they
haven't
enabled
2fa.
A
Yet
we
actually
don't
block
that
account
from
publishing,
because
again
we're
focused
on
atos.
What
we
do
is
we
put
them
in
limbo.
They
basically
can't
do
anything
but
publish
a
package.
They
can't
mint,
no
tokens,
they
can't
change
their
password.
They
can't
change
their
email
address,
they
can't
add
maintainers
to
packages.
Anything
aside
from
essentially
publishing
a
package
is
blocked
for
that
account
until
they
implement
2fa
and
you'll,
see
in
a
second
what
that
looks
like
from
the
implementation,
but
on
february
1st
we
implemented
this
for
the
top
100
maintainers
just
a
couple.
A
A
lot
of
folks,
including
executives
at
the
company
when
they
saw
this
slide,
were
like
well,
why?
Ninety
percent?
Not
a
hundred
and
it's
like?
Well,
you
know
we're
trying
to
protect
against
atos
here
we're
trying
to
protect
against
the
vulnerability
of
the
account
minting
new
sessions.
That's
protected.
A
A
A
So
I
talked
about
an
improved
2fa
experience.
It's
really
important
for
us
to
make
the
second
factor
delightful.
We
can't
like
go
and
tell
people
hey
like
turn
this
thing
on
and
make
the
experience
not
great
before
we
invested
in
this
2fa
on
npm
was
a
single
second
factor
which
was
mobile,
authenticator
apps
only
so
we
went
and
implemented
web
authent
webauthn
is
an
industry
standard.
Allows
you
to
introduce
support
for
a
large
number
of
different
second
factors,
including
biometrics,
face
scanning
push
to
phone,
whatever
the
browser
implements
as
a
second
factor
within
webauthn.
A
We
support
now,
and
we
also
improve
the
overall
2fa
management
experience.
So
we
have
a
whole
new
landing
page.
Just
for
managing
your
second
factors,
you
can't
just
have
a
single
second
factor
anymore.
You
can
add
many,
and
this
helps
against
that
account
lockout
problem,
so
you
can
manage
multiple
keys.
You
can
replace
your
authenticator
app
without
turning
off
2fa,
which
sounds
like
something
you
probably
would
want
to
do,
but
that's
historically
how
it
used
to
work.
You
can
view
and
regenerate
recovery
codes
and
we
got
rid
of
this
concept
of
modes
used
to.
A
A
We
introduced
some
new
experiences
also
for
managing
2fa
for
organizations.
So
specifically,
we
allow
organizations
to
now
enforce
2fa
which
allows
individual
organizations
to
roll
out
these
restrictions
to
their
own
users
at
a
different
timeline
than
we're
planning
to.
We
also
made
it
much
easier
to
audit
the
second
factors
of
the
members
of
your
organization
to
be
clear,
whether
or
not
an
account
has
2fa
enabled
is
not
something
we're
making
publicly
available
that
can
make
accounts
like
targets.
A
We
don't
want
to
make
it
really
obvious
for
folks
about
which
accounts
aren't
well
protected,
but
if
you're
giving
access
to
folks
through
an
organization,
we
believe
that
you
deserve
to
know
that
information
of
what
the
risk
and
make
decisions
based
on
your
risk,
tolerance
so
approved
account.
Recovery
was
the
next
thing.
A
As
I
mentioned,
the
more
people
who
adopt
2fa
the
more
people
who
are
going
to
lose
those
second
factors,
the
more
people
who
are
going
to
have
to
recover
their
accounts
and
account
recovery
tickets
for
us
is
already
one
of
the
most
intensive
forms
of
tickets
that
our
support
agents
need
to
go
through.
Every
single
account
recovery
ticket
could
potentially
be
someone
trying
to
socially
engineer
those
teams
to
take
over
accounts.
A
That
way,
so
we
are
working
on
process
improvements,
we've
already
implemented
new
playbooks
that
have
been
reviewed
by
various
account
security
experts,
consistent
processes
that
we
apply
every
time.
We've
got
identity,
verification
that
we're
working
on
and
I'll
show
a
quick
demo
in
a
second
and
automation
to
make
this
whole
process
not
require
as
much
human
intervention.
A
So
here's
the
demo.
This
is
something
that
okay
there
we
go.
This
is
what
we
want
account
recovery
to
look
like
and
what
we're
working
towards
you
would
log
into
your
account.
You
would
click
to
recover
your
account
you'd
get
a
code
over
email.
This
is
verifying
your
email
address,
knowing
that
we
know
that
an
account
owns
that
email
address
is
the
first
step.
People
can
then
say
what
they're
looking
to
recover.
You
get
a
text
message
very
clear.
This
is
not
2fa;
it
would
not
be
a
second
factor.
A
It's
only
for
identity,
verification
and
part
of
a
multi-phased
process
for
identity,
verification,
we're
looking
at
linking
directly
to
we're
working
on
linking
directly
to
github
and
twitter
through
an
oauth
application,
so
you'd
be
able
to
go
in
authenticate
with
both
your
github
and
twitter
and
submit
a
ticket.
At
this
point,
the
support
agent
already
has
for
this
ticket
three
different
ways
that
you've
verified
your
identity
programmatically
and
can
then
use
that
information
to
execute
the
rest
of
the
account
recovery.
A
What
happened
was
that
oauth
tokens
were
stolen
from
travis,
ci
and
heroku.
Those
tokens
were
used
to
authenticate
with
github
and
download
private
repositories,
including
the
private
repositories
of
npm.
Those
private
repositories
were
scanned
and
secrets
were
found.
Those
secrets
included
an
aws
access
key,
which
was
then
used
to
gain
access
to
our
aws
infrastructure
within
aws.
A
couple
things
were
then
exfiltrated,
one
was
a
backup
of
skim
db.
It
was
from
april
7
2021.
A
Thankfully,
based
on
login
event,
analysis
and
using
package
verification,
we're
confident
that
no
packages
were
modified
or
no
no
new
versions
were
published,
but
there
was
account
information
that
was
taken
and
we've
notified
everyone.
We've
tried
to
be
extremely
transparent
about
this
entire
incident.
We
notified
everyone
who
may
have
had
their
passwords
leaked.
We
notified
everyone
who
may
have
had
the
metadata
from
their
packages
leaked
and
we
notified
everyone
who
the
names
and
versions
of
their
packages
were
leaked.
A
But
this
is
the
thing
that
I
thought
was
pretty
cool.
We
were
able
to
validate
the
registry
itself
using
package
signatures,
so
the
every
package
when
it's
published
to
the
registry
is
signed
by
npm
at
the
time
of
publish
previously.
This
was
done
with
a
pgp
signature
and
we're
in
the
process
right
now
prior
to
this
event
of
actually
resigning
every
single
package
on
the
entire
registry,
using
a
new
key
using
the
ecdsa
algorithm.
A
That's
a
huge
obvious
thing
that
we
need
to
be
investing
in
quite
a
bit:
we're
also
continuing
to
invest
heavily
in
customer
facing
security
features.
All
of
that
work
that
I
was
showing
you
around
account.
Recovery
is
all
in
process
right
now
and
we're
still
iterating
on
other
places,
especially
around
tokens
and
improving
the
ability
to
securely
publish,
but
we
can't
stop
there.
We
need
to
continue
to
think
about
innovating,
and
this
is
one
of
the
biggest
challenges
that
we
have
at
npm.
Today.
A
It's
not
going
to
be
great,
but
if
we
spend
all
of
our
time
securing
the
registry
today
and
don't
think
about
the
way
that
people
want
to
consume
javascript
in
five
years,
then
we
might
be
securing
something
that
people
don't
care
about
using.
So
this
is
the
thing
that
we're
trying
to
really
find
the
balance
on
between
securing
the
registry
today
and
building
a
product
that
will
continue
to
be
useful
for
folks.