►
From YouTube: Securing JavaScript - Universe 2022
Description
Presented by: Myles Borins
The npm registry is the heart of the JavaScript ecosystem. Hear about the steps that GitHub has taken to secure this important part of the software supply chain from enforcing software solutions, such as automated malware scanning, to policy including enforcing two-factor authentication for high-impact packages. This talk will cover what GitHub has shipped to respond to an increase in threats to the company’s ecosystem and what GitHub is working on next.
As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub
Thanks!
Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github
About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com
A
A
Javascript,
my
name
is
Miles
Barnes
I'm,
a
director
of
product
management
here
at
GitHub
and
I
work
on
GitHub
packages
and
npm
npm
itself
is
a
critical
tool
in
the
open
source
software
supply
chain.
We
serve
over
140
billion
downloads
a
month
to
customers
all
around
the
world
and
are
Central
to
package
management
and
distribution
in
the
JavaScript
ecosystem,
and
there
are
various
threats
to
our
overall
software
supply
chain
across
open
source
as
a
whole
and
more
specifically,
to
npm
itself,
which
is
what
we
deal
with
day
to
day
here
at
GitHub.
A
One
of
the
threats
that
we
deal
with
at
MTM
is
what's
known
as
an
ATO
or
account
takeover
and
in
particular,
where
this
is
dangerous,
is
in
the
taking
over
of
high
impact
package.
Maintainer
accounts.
If
a
high
impact
manager's
account
is
taken
over,
it
can
be
used
to
publish
vulnerabilities
or
malware
in
highly
downloaded
code,
and
we've
seen
this
happen
before
in
particular
on
October
22nd
2021.
We
noticed
that
the
UA
parser.js
package
had
been
hijacked.
This
is
a
package
with
1200
plus
dependents.
A
This
put
us
on
a
high
alert
and
we
made
some
changes
to
the
way
in
which
we
were
scanning
malware
and
checking
for
vulnerabilities
on
the
registry
and
when,
a
couple
weeks
later,
the
KOA
package
was
hijacked
a
package
with
166
dependents,
nine
plus
million
weekly
downloads
in
malware
installed
via
a
post,
install
script.
We
were
able
to
get
that
package
removed
in
30
minutes
with
the
vulnerable
version,
and
when
later
that
day,
the
RC
package
was
hijacked.
A
package
was
over
1300
dependents
and
13
million
weekly
downloads.
A
Similarly,
with
malware
deployed
via
a
post
install
script,
we
were
able
to
take
that
down
from
the
registry
within
15
minutes,
and
so
you
may
be
asking
you
know.
What
did
we
do
right?
One
thing
that
we
did
is
have
malware
scanning
in
place.
This
was
an
experimental
scanning
service
that
identified
the
malware
in
all
three
instances.
A
We
had
been
working
on
this
for
a
number
of
months
prior
to
the
first
account
takeover
that
we
mentioned
with
UA
parser,
but
we
hadn't
deeply
integrated
into
our
process
because
it
had
a
lot
of
false
positives
after
the
UA
parser
incident.
When
we
went
through
and
did
our
debrief
and
we
realized
that
the
malware
scanning
had
noticed
it
super
early,
we
went
through
and
augmented
our
scanning
solution
to
notify
us
when
high
impact
packages
were
scanned
with
malware
and
that
allowed
us
to
have
a
much
faster
response
time
in
the
next
two
incidents.
A
Another
thing
that
allowed
us
to
work
quickly
and
solve
these
problems
after
the
UA
parser
JS
incident
was
clear
policies.
Malicious
code
is
against
our
acceptable
use
policy
and
we
went
through
and
updated
the
language
to
make
it
really
clear
and
updated
our
our
internal
processes
trained
staff
and
made
sure
that
we
were
ready
and
able
to
act
super
quickly.
If
this
were
to
happen
again,
not
having
clear
policies
is
a
really
easy
way
to
drag
your
feet,
and
you
can't
do
that
when
you're
in
the
midst
of
an
incident.
A
Another
thing
that
we
did
was
work
on
automated
tooling,
so
we
have
a
lot
of
chat
Ops
that
we
use
here
at
GitHub
for
doing
a
lot
of
different
things,
and
we
worked
on
very
specific
special
commands
for
doing
malware
takedowns
to
packages
that
automate
the
whole
process
of
everything
they
need
to
do
from
removing
a
version
to
wiring
everything
up
for
setting
up
a
advisory
in
The
Advisory
database
to
Banning
the
account
that
that
published
the
package.
All
of
this
we
now
have
that
can
be
run
by
an
agent
with
permissions
special
permissions.
A
Not
everyone
can
do
it,
but
for
someone
who
does
have
permissions,
they
can
do
it
with
a
single
command
and
chat
Ops.
And
finally,
we
have
all
hands
on
deck
ready
to
go
when
something
like
this
happens
through
support
engineering,
product
security,
trust
and
safety
incident
respond.
Communications.
We
have
a
lot
of
different
partners
that
need
to
be
able
to
come
together
in
short
notice,
to
handle
these
kinds
of
high
risk
incidents,
and
there
were
a
lot
of
things
that
we
learned
from
this
account.
Takeovers
was
a
pattern.
A
It
was
a
common
pattern
amongst
attackers
as
to
how
this
was
being
done
as
well.
The
accounts
had
had
their
password
stolen
attackers
were
using
those
stolen
passwords
to
access
the
account
after
accessing
the
account
they
were
then
publishing
malware
through
a
post
install
script.
Another
thing
that
was
really
clear
was
that
time
to
response
was
extremely
critical.
The
longer
that
the
malware
was
up
on
the
registry,
the
broader
the
impact
that
it
would
have.
A
We
also
determined
that
strong
2fa
may
have
stopped
this.
None
of
the
compromised
accounts
had
2fa
enabled
two-factored
authentication
would
have
made
it
that
if
hey
I
came
by
and
had
gotten
a
password
from
a
third
party
or
from
another
source,
maybe
password,
reuse
or
through
some
other
means
they
would
not
have
been
able
to
get
into
the
account
without
the
second
factor.
A
Every
single
time
that
there's
a
high
profile
security
incident
involving
open
source
people
lose
a
little
bit
of
trust.
These
are
dense
in
the
armor
of
the
overall
Trust
of
Open
Source,
something
that
has
been
you
know,
helping
industry
flourish
for
decades
and
it's
important
and
I
think
it's
important
for
us,
both
as
stewards
at
npm
and
stewards
of
the
GitHub
ecosystem
for
us
to
make
sure
that
we
do
everything
in
our
powers
to
ensure
that
folks
are
confident
and
secure
and
Trust
open
source
software.
A
So
we
made
this
Mission
and
the
mission
was
no
more
account
takeovers.
Now
we
can
never
totally
stop
all
takeovers,
but
what
we
can
do
is
significantly
raise
the
bar
introduce
various
defense
in
depth
and
make
it
extremely
hard
for
folks
to
take
over
Accounts
at
least
much
harder
than
it
was
in
the
past,
and
so
we
created
what
we
called
the
npm
security
roadmap
with
four
major
pillars
that
we
were
focused
on
for
making
sure
that
account
takeovers
would
be
significantly
harder
to
happen
in
the
future.
The
first
step
was
login
verification.
A
When
accounts
don't
have
2fa
on
it.
We
wanted
to
make
sure
that
there
was
something
in
place
to
protect,
and
we
did
this
through
an
emailed
OTP
which
we'll
talk
about
in
a
minute.
We
wanted
to
roll
out
mandatory
to
fa
specifically
for
high
impact
package.
Maintainers,
we'll
talk
a
little
bit
more
about
why
we
came
up
with
that,
what
the
definition
was
and
how
we
rolled
that
out.
We
needed
to
improve
the
2fa
experience.
A
So
if
we're
going
to
tell
people
hey,
you
have
to
have
2fa
or
bother
people
pretty
consistently
to
turn
it
on
their
account
better,
be
a
really
good
experience,
so
we
invested
in
making
2fa
delightful
and
trying
to
make
it
something
that
people
would
want
to
use.
And,
finally,
we
needed
to
invest
in
improving
account
recovery.
This
is
maybe
not
intuitive,
but
your
account
security
is
only
as
secure
as
your
account
recovery.
A
So
let's
dig
into
that
concept
of
login
verification
that
I
was
talking
about
when
you
log
in
to
your
account,
and
you
don't
have
2fa
enabled
on
your
account.
You
now
get.
This
screen
enter
a
one-time
password.
So
for
your
security,
when
you
try
to
log
in
and
if
you
don't
have
2fa,
we
now
send
you
an
OTP
via
email
that
you
need
to
put
in
to
be
really
clear.
This
isn't
2fa
and
by
the
Nast
standard.
Email
cannot
be
used
as
a
factor
for
two-factored
authentication.
A
You
can
go
in
and
recover
your
account
with
passwords
reset
via
the
email.
So
if
your
email
is
the
factor
at
which
you're
using
to
like
have
a
second
Factor,
it
isn't
2fa
by
like
the
pure
definition
of
it.
But
what
this
does
mean
is
that
if
someone
steals
your
password,
they
actually
can't
get
into
your
account
unless
they
also
have
access
to
your
email
address.
A
This
means
that
unless
the
email
address
was
also
compromised,
they're
not
able
to
get
in,
and
so
we
started
enrolling
on
December
7th
Publishers,
so
anyone
who
had
published
access
to
a
package
into
this
new
login
verification
process.
This
was
you
know
only
about
a
month
out
from
when
the
incident
first
started,
and
we
wanted
to
have
a
clear
solution
in
place
as
quickly
as
possible
to
significantly
raise
the
minimum
bar,
and
you
know
selfishly
to
make
sure
that
we
didn't
have
more
incidents
over
the
holidays,
which
would
be
coming
up
later
in
the
year.
A
A
A
Some
accounts
had
email
addresses
that
were
known
to
bounce,
so
we
rolled
this
out
in
cohorts
to
make
sure
that
a
we
could
test
with
a
smaller
group
to
make
sure
that
there
were
no
bugs
to
start
with
and
then
that
we
only
in
the
New
Year
enrolled
accounts
that
we
thought
would
actually
have
problems
so
that
we
didn't
end
up.
You
know
like
breaking
someone
else
over
the
holidays
as
well
and
by
March
1st.
We
actually
went
ahead
and
introduced
login
verification
for
all
accounts.
A
Once
we
saw
how
successful
it
was
with
the
publisher
group,
we
decided
this
needs
to
be
a
new
minimum
bar
for
all
npm
accounts
on
the
entire
registry,
and
it's
been
fairly
successful
now,
as
I
mentioned
before.
This
has
resulted
in
more
account
recoveries
and
that's
something
that
you
know
we'll
talk
about
afterwards.
Why
and
how
we've
invested
in
improving
it,
but
you
know
improving
security
always
tends
to
be
a
bit
of
a
trade-off
between
security
and
usability,
but
overall
we
found
that
this
was
a
really
great
balance.
Let's
talk
about
two-factored
authentication
enforcement.
A
I
think
that
it's
an
incredible
thing
that
we
as
an
industry
are
moving
in
this
way,
but
as
someone
who
comes
from
a
non-traditional
background,
I
started
programming
with
node.js
building
like
weirdo
art
installations
with
arduinos
and
stuff.
I
know
that
we
need
to
be
thoughtful
about
all
the
different
kinds
of
maintainers
that
we
have
and
not
everyone
is
going
to
be
super
intuitive
and
there's
accessibility,
concerns
that
can
come
up
with
this
as
well.
In
general,
we
can't
disrupt
our
most
important
maintainers
while
trying
to
enforce
2fa.
A
That
was
an
ethos
that
we
had
as
part
of
this,
but
we
also
need
to
protect
the
ecosystem
and
can't
drag
our
feet
on
rolling
this
out.
So
we
came
up
with
a
plan
for
two-factor
authentication.
First,
we
wanted
to
focus
on
ATL
and
what
this
means
is
that
the
enforcement
would
only
be
for
creating
new
sessions,
not
for
publishing
packages.
Well,
it
is
possible
that
account
credentials
can
be
stolen,
such
as
an
access
token,
and
that
access
token
could
be
used
for
rolling
out
malware.
A
That
wasn't
the
pattern
that
we
had
been
seeing
in
the
pattern
that
we
were
focused
on,
so
we
stayed
extremely
focused
on
what
and
why
we
were
rolling
this
out,
which
was
protecting
from
account
takeovers.
So
we
do
not
actually
enforce
folks
to
enable
2fa
for
publish
and
there's
still
a
way
to
opt
out
so
that
you
can
publish
with
2fa,
as
well
as
other
mechanisms
of
publishing
and
automation.
Without
2fa
such
as
automation,
tokens.
A
We
did
a
phased
rollout,
we
coordinated
product
improvements
and
expanded
enforcement.
We
shipped
to
learn
based
on
feedback,
so
our
first
group,
which
we'll
talk
about
in
a
second,
was
the
top
100
maintainers
and
we
didn't
even
roll
out
to
them
until
we
had
introduced
web
authen
and
each
one
of
the
phased
rollout
groups
aligned
with
more
product
launches
that
we
did
to
improve
both
the
2fa
and
Recovery
experience.
A
We
also
made
sure
that
the
entire
process,
when
was
maintainer
first,
we
didn't
want
to
disrupt
workflows,
so
existing
access
tokens
continued
to
work
even
after
the
2fa
deadline.
So
if
you
were
a
maintainer
who
has
2fa
enforced
on
your
account
after
the
deadline,
but
you
haven't
set
it
up
yet,
but
you've
already
minted
access
tokens
either
locally
on
your
machine
or
NCI.
Those
tokens
can
still
be
used
to
publish
packages
today
they
cannot
be
used
for
doing
any
account
Administration.
So
you
can't
add
new
maintainers
to
packages.
A
You
can't
create
new
tokens
or
new
sessions,
but
we
wanted
to
make
sure
that
if
a
group
of
maintainers
were
being
enforced,
that
we
wouldn't
be
breaking
their
automations
now.
This
is
something
that
we
may
and
probably
will
change
in
the
future.
We
haven't
decided
on
timelines
or
scope
yet,
but
we
wanted
to
make
sure,
at
least
for
this
rollout
that
we
were
doing
it
in
such
a
way
that
again
really
focused
on
account
takeovers
and
really
focused
on
making
sure
that
we
were
as
minimally
as
possible,
disrupting
our
overall
maintainers
workflows.
A
So
the
timeline
looked
like
this:
we
reinforced
for
the
top
100
maintainers
in
February
1st
and
this
aligned
with
our
public
beta
of
our
new
2fa
process,
so
that
allowed
us
to
have
web
authen
and
a
few
other
features
we'll
talk
in
a
bit.
May
31st
we
enforced
for
the
top
500
and
that
aligned
with
the
general
availability
of
our
new
2fa
process,
enhanced
experience
and
on
November
1st
we
enforced
for
high
impact
package
maintainers.
A
That's
all
maintainers
are
packaged
with
with
one
plus
million
weekly
downloads
for
500
plus
dependents
and
after
November
1st,
whenever
a
package
passes,
this
threshold
maintainers
are
dynamically
added
into
this
list
and
given
15
days
notice
to
enable
2fa
on
their
accounts,
as
of
September
27
2022,
which
is
when
I'm
recording
this
session,
because
I'm
actually
heading
out
on
paternity
leave.
Soon.
These
are
the
stats
of
what
adoption
looked
like
the
top
100
maintainers
had
90
adoption,
the
top
500
maintainers
said
87
adoption
and
the
high
impact
maintainers
have
74.5
adoption.
A
This
is
relatively
High
adoption
of
2fa,
and
it
shows
that
our
enforcement
is
working
and
moving
people
towards
this
right
now
getting
to
a
hundred
percent
adoption
is
not
a
goal
as
there
are.
You
know.
We
know
that
the
accounts
are
protected.
We
will
be
looking
into
ways
of
moving
those
numbers
higher,
but
what
is
most
important
right
now
is
that
the
vast
majority
of
accounts
are
protected.
So,
let's
talk
about
improving
the
overall
2fa
experience
and
making
adding
a
second
Factor
delightful.
A
The
first
thing
that
we
did
to
improve
our
overall
2fa
experience
was
introducing
web
authen.
Web
authen
is
a
standard
in
the
browser
that
supports
a
large
number
of
different
second
factors,
including
security
keys
and
biometric
devices
such
as
Touch,
ID
and
windows.
Hello.
Historically,
the
npm
registry
only
supported
using
a
second
factor
on
a
phone
with
a
mobile,
authenticator,
app
or
what's
also
known
as
time-based
one-time
tokens
totp,
and
we
only
supported
a
single
device.
Now,
with
web
authen,
you
can
use
all
sorts
of
different
devices
based
on
what
you're
interested
in
using.
A
We
also
went
through
and
significantly
improved
the
process
of
2fa
management,
making
2fa
better
to
use.
We
allow
people
to
manage
multiple
security,
Keys
We,
allow
folks
to
set
up
and
replace
in
line
their
authenticator
app.
Prior
to
this,
you
actually
have
to
disable
to
a
fan
on
your
account
in
order
to
change
your
authenticator
app,
which
doesn't
really
work
with
the
whole
concept
of
enforce
2fa.
A
Everyone
has
2fa
enabled
for
both
op
and
publish,
and
then
you
have
the
ability
to
opt
out
via
additional
options,
and
this
may
be
necessary
for
folks
who
are
transitioning
and
maybe
have
been
using
public
tokens
rather
than
authentication
automation,
tokens
in
CI,
and
they
don't
want
to
break
their
continuous
integration
or
they
enable
2fa
and
find
that
Integrations
were
broken.
This
allows
a
quick
opt
out
so
that
folks
can
get
things
working
properly.
We
also
significantly
invested
in
2fa
for
organizations.
A
So
while
we
have
a
plan
in
a
way
in
which
we're
rolling
out
2fa
to
support
folks
in
the
registry,
we
want
to
allow
organizations
and
organization
admins
to
enforce
2fa
for
their
organizations,
which
raises
the
bar
for
other
smaller
sections
of
the
registry.
We
also
wanted
to
make
it
easy
for
folks
to
audit
the
2fa
adoption
of
ORD
members
for
security
reasons.
We
don't
actually
show
on
a
profile
page,
whether
or
not
someone
has
2fa
enabled
showing
this
would
create
a
Target
on
the
backs
of
folks
who
don't
have
it
enabled
yet.
A
But
if
you
are
a
member
of
an
organization
and
through
that
organization
are
being
given
access
to
packages
and
Publishing,
it's
important
that
the
admins
of
that
organization
know
whether
or
not
you
have
2fa
enabled
so
this.
This
new
auditing
functionality
that
we
introduced
into
the
org
makes
it
easier
for
org
members
or
admins
to
make
sure
that
they're
aware
of
the
adoption
in
their
organizations.
So
one
thing
that
we
also
invested
in
is
streamlining
the
login
and
publish
experience
for
the
npm
CLI
and
for
that
I've
got
a
demo
for
you.
A
So
let's
look
at
the
new
login
and
publish
experience
that
we
have
with
npm9
that
significantly
improves
the
overall
publish
flow
with
web
authent.
This
experience
is
available
if
you're,
using
later
versions
of
npm
8
by
explicitly
saying
auth
type
equals
web,
but
for
now
we're
just
going
to
type
in
npm.
Login
you'll
see
that
I'm
no
longer
prompted
to
enter
a
username
or
password
or
anything
I'm
prompted
to
hit
enter
to
open
a
browser
and
when
I
do
that.
A
It's
going
to
send
me
to
this
page,
where
it
shows
me
who
I'm
authenticating
as
because
it's
using
my
existing
session
I'll
hit
use
security
key
scan,
my
fingerprint
on
my
computer,
and
we
can
see,
authentication
is
successful
and
I
can
go
back
to
the
terminal
and
we
can
see
that
I'm
now
authenticated
and
what's
the
first
thing
that
I
may
want
to
do
while
I'm
authenticated
well,
of
course,
I'm
going
to
want
to
go
ahead
and
publish
a
package.
I've
got
this
package
that
I
have
a
new
version.
A
I
need
to
publish
I'll
similarly
hit
enter.
It's
going
to
open
up
a
browser.
It's
going
to
challenge
me
for
my
security
key
and
you're,
going
to
notice
this
great
little
challenge,
which
allows
me
to
click
a
button
and
say
don't
challenge
me
again
for
my
IP
address,
which
I'm
sorry
it's
blurred
out.
I,
don't
want
to
show
you
my
IP,
but
for
the
combination
of
this
IP
address
and
my
token,
it's
not
going
to
challenge
me
to
publish
for
the
next
five
minutes
with
2fa.
This
is
really
important
if
you're
doing
many
operations.
A
So
the
next
big
thing
that
we
invested
in
was
improving
account
recovery
because
more
2fa
means
more
recovery
and,
as
I
mentioned,
we
raise
account
security
by
raising
the
bar
with
2fa.
But
if
account
recovery
can
happen
at
a
lower
security
bar
we're
only
as
secure
as
our
account
recovery
process,
so
we
had
three
different
pillars
for
our
improves
account
recovery
process.
Investment
first
was
process
improvements.
We
invested
in
new
playbooks
that
were
reviewed
by
various
account
Security
Experts,
in
collaboration
with
our
support
teams,
to
ensure
that
we
can
have
a
consistent
process.
A
That's
applied
to
all
accounts
that
has
an
extremely
high
security
bar.
We
were
very
inspired
by
the
DMV
by
having
a
point
system
that
we
use
internally
to
kind
of
think
about
how
many
factors
of
identity
people
have
and
then
using
those
to
determine
whether
or
not
there
are
enough
points
of
identity
to
have
a
same
or
similar
bar
to
the
amount
of
security
that
2fa
offers.
A
We
invested
in
streamlining
identity,
verification
through
both
email
verification
and
linking
GitHub
and
Twitter
prior
to
the
work
that
we
did
here.
The
Twitter
and
GitHub
accounts
on
your
profile.
Page
was
just
a
text
box
that
you
fill
out
now.
We
have
oauth
applications
directly
integrated
with
Twitter
and
GitHub
that
create
a
link
that
we
can
verify
and
in
fact
we
automate
all
of
that.
A
My
recovery
codes
so
I'm
going
to
go
ahead
and
click
to
recover
my
account
so
we're
going
to
go
ahead
and
we're
going
to
click
to
start
account.
Recovery.
That's
immediately
going
to
bring
me
to
this
thing
where
I'm
being
shown
my
email
address,
but
you
can't
see
it
right
now,
because
that's
actually
being
blurred
out
to
protect
my
privacy
but
I'm
being
emailed
a
one-time
password
which
I
would
enter
in,
but
we're
going
to
go
ahead
and
skip
that
verification.
A
Right
now,
because
somehow
I
didn't
get
that,
but
if
you
did
put
in
your
one-time
password
there,
the
agent
would
know
that
you'd
verified
your
email
address
no
I'm
in
here.
You
could
see
my
username.
You
could
see
my
email
address,
which
should
also
similarly
be
blurred
out
I'm,
going
to
say
that
I
need
to
reset
my
email
I'm
going
to
go
ahead
and
click
to
connect.
A
My
GitHub
account
and
you
can
now
see
that
I've
linked
to
my
GitHub
account
I'm,
going
to
click
to
link
my
Twitter
account,
which
is
going
to
bring
me
here
onto
Twitter,
to
verify
and
authorize
the
application
which
I've
gone
ahead
and
done,
and
now
you
can
see.
I
have
a
support
ticket
with
everything
linked
and
I,
say:
I
want
to
reset.
Actually,
my
two-factor
authentication,
not
my
email
and
I
click
to
submit
the
support
ticket
and
now
I've
submitted
to
our
support
team.
A
This
ticket
already
has
all
of
my
identity
verified
all
of
those
factors
and
the
support
team
has
everything
they
need
to
go
ahead
and
recover.
My
account.
This
is
great
because
formally
this
required
so
many
back
and
forth
with
the
agents.
It's
also
great,
because
we're
able
to
do
this
programmatically
and
and
verify
it
actually
not
just
kind
of
like
a
trust
us,
because
you
filled
in
some
text
it's
significantly
better
than
what
we
had
before
and
a
great
iteration
in
just
making
account
recovery
better
for
all
of
our
customers.
A
A
This
has
been
a
heavily
requested
feature
not
just
from
the
community,
but
by
myself,
of
wanting
tokens
that
are
generated
that
don't
have
access
to
every
single
package
that
your
account
has
access
to
granular
Acts
access
tokens
will
be
able
to
be
limited
to
specific
packages,
to
specific
Scopes
or
to
an
organization
for
doing
admin.
Work
if
you
wanted
to,
for
example,
automate,
adding
and
removing
people
to
an
organization
when
you
add
and
remove
them
from
your
from
your
company.
A
It
allows
you
to
set
expiration
dates
on
tokens
and,
in
fact,
has
an
enforced
expiration
date
of
no
longer
than
one
year
and
also
allows
you
to
to
use
a
cidr
list
to
limit
IP
address
ranges.
So,
for
example,
if
I'm
setting
automation
up
for
a
single
package,
I
maintain
a
package
called
node,
osc
and
I'm
doing
that
through
automations
on
GitHub
actions.
A
A
Instead
we're
going
to
be
creating
an
attestation
that
follows
the
Providence
of
a
package
from
the
commit
that
was
used
to
kick
off
the
build
through
the
whole
build
itself.
So
the
package
that
eventually
ends
up
on
the
public
registry
we're
going
to
be
integrating
with
a
tool
called
sigstore,
which
is
a
an
open
source
tool
for
creating
short-lived
certificates
and
creating
a
notary
to
keep
track
of
Open
Source
publishes.
A
I
think
that
this
is
one
of
the
most
important
things
that
we're
looking
at
building
right
now
for
software
supply
chain
security.
If
you're
interested,
we
have
an
open,
RFC
right
now
that
you
can
go
and
take
a
look
at
and
we'll
be
keeping
the
community
updated
as
we
make
developments
so
overall,
as
we
think
about
next
in
our
roadmap,
we've
got
three
major
things
that
we're
focused
on
we've
got
core
security
improvements,
so
this
is
investments
in
our
infrastructure
and
our
internal
processes
in
the
way
that
we
manage
the
registry.
A
Finally,
we're
focused
on
Innovation.
We
know
that
JavaScript
is
constantly
evolving
and
we
need
to
keep
our
finger
on
the
pulse
of
where
the
language
is
going
to
ensure
that
we
have
solutions
for
not
just
the
JavaScript
of
today,
but
the
JavaScript
of
tomorrow.
With
all
of
that
in
mind,
I
want
to
thank
you
for
taking
the
time
to
listen
today
and
to
hear
about
everything
we've
been
working
on.
You
know
it's
an
ongoing
journey
and
I
am
just
personally
so
excited
to
get
to
spend
my
days
on
this.
Thank
you
so
much.