►
From YouTube: Bringing Provenance to All of Open Source: Lessons from Npm’s... - Trevor Rosen & Zach Steindler
Description
Bringing Provenance to All of Open Source: Lessons from Npm’s Sigstore Integration - Trevor Rosen & Zach Steindler, GitHub / npm
npm is the largest package registry on the internet, serving over 70 billion packages per month and acting as the de facto standard package system for Javascript, the world’s largest OSS ecosystem by lines of code. It suffers from the basic problem all registries have: there’s no verifiable link from a package back to its source code and build process. To solve this problem, npm is integrating with Sigstore’s open source libraries and public good servers, to securely communicate npm package provenance from your build system to the registry and make it available for verification with npm CLI. During this work, a bunch of interesting questions came up: What does it mean for a build process to be secure? Can we trust packages without verifying every developer’s identity? Does our approach work for other package ecosystems? This talk will take you inside arguably the most ambitious and impactful effort happening in software supply chain security today and offer some fundamental (and maybe controversial!) opinions about what’s needed for package provenance across all of open source.
A
I,
don't
think
we
could
fit
the
dozens
or
maybe
hundreds
of
people
who
participated
in
this
release
on
this
stage.
So
unfortunately,
it's
just
me
here
today,
but
I
wanted
to
start
out
just
by
saying
that
this
work
would
not
have
been
possible
without
the
six
door
open
source
project.
It's
key
to
the
npn
Providence
feature
as
we'll
describe
later
in
the
presentation.
A
This
particular
implementation
that
we've
launched
so
far
is
for
the
npm
packed
registry
and
works
on
GitHub
actions.
We
are
working
with
other
partners
to
expand
this
across
the
open
source
ecosystem
and
then,
of
course,
this
work
would
not
have
been
possible
without
the
work
that
happened
beforehand
with
the
intodo
project
and
also
the
salsa
specification
which
really
inspired
this
concept
of
build
profit
and
it's
build
integrity
and
supply
chain
security.
A
Okay,
this
is
what
it
looks
like
it's.
A
very
short
talk.
No
so
npm
build
provenance
ties
an
npm
package
back
to
the
exact
source
code,
exact
commits
in
the
exact
build
instructions
that
make
up
that
package.
So
here
this
is
the
example
for
the
six
door
JavaScript
package,
and
this
is
what
it
looks
like
if
you
go
to
the
npm
registry
and
look
on
the
website.
A
A
So
we're
going
to
talk
a
little
bit
about
what
is
provenance,
what
we
built
and
then
what
we
learned
along
the
way,
starting,
of
course
with
what
is
provenance.
So
the
somewhat
visceral
analogy
that
we
like
to
use
is
you're
walking
down
the
street
and
it's
a
hamburger
lying
on
the
ground.
Are
you
going
to
eat
it?
A
Maybe
you
would
maybe
you
wouldn't,
but
the
first
question
you're
going
to
ask
is:
where
did
it
come
from
right?
You
want
to
know
the
provenance
of
the
hamburger,
so
that's
exactly
the
case
for
open
source
projects
as
well.
We
already
have
this
concept
of
maybe
looking
for
social
proof.
How
many
stars
does
a
project
have?
Are
there
other
companies
we
respect
that
use
it?
Maybe
we're
looking
for
a
privacy
policy
or
a
security
policy
we're
trying
to
determine
the
trustworthiness
of
Open
Source
component
today
in
open
source.
A
There
really
isn't
a
connection
between
what
a
package
claims
it
contains
and
what
it
actually
contains.
So
sure
someone
can
put
in
the
readme
here's
a
link
to
the
source
code.
Here's
how
I'm
building
this,
but
they
can't
prove
it,
and
so
the
reason
we
undertook
this
work
is
to
have
these
verifiable
links
again
back
to
the
source
code
and
the
build
instructions.
A
A
You
can
see
it
for
yourself
if
you
go
to
salsa.dev,
but
these
are
the
different
levels
for
build
security,
and
so,
if
you're
unfamiliar,
the
salsa
framework
is
attempt
to
take
the
problems
of
supply
chain
security,
distill
it
down
to
a
framework
describing
the
sort
of
concerns
that
you
might
have
and
giving
you
sort
of
a
capability
model
to
say,
crawl,
walk
run.
How
would
you
increase
the
security
of
these
different
elements
so
for
builds
L1?
Is
that
any
sort
of
Providence
exists
again?
A
This
could
be
a
link
in
a
readme.
It's
just
you
know.
Someone
says
this
is
the
source
code.
It's
better
than
nothing.
L2
is
that
it
runs
in
some
sort
of
trusted
environment.
This
is
something
we're
going
to
dive
much
deeper
into
in
a
little
bit
here
and
then
L3
is
where
it
really
starts
to
get
interesting.
We're
saying
that
not
only
does
the
province
exist,
but
it's
verifiable.
A
A
I,
like
this
slide
for
a
couple
of
reasons,
so
this
is
just
a
different
view
of
provenance.
So
of
course,
there's
the
nice
shiny
box
on
the
npm
website.
That's
great,
but
if
you
look
on
the
transparency
log,
this
is
what
you
will
see
in
terms
of
Providence.
All
the
same
information.
Is
there
the
package,
the
hash,
a
link
to
the
URI
to
the
source
code?
A
The
entry
point
is
the
build
instructions,
but
it's
just
you
know
this
is
the
programmatically
what
you
would
interact
with
to
receive
this
information
and
then
the
reason
I
like
to
show
the
slide
is
because
it's
showing
here
again
how
we're
building
up
on
existing
standards
that
have
been
developed
in
the
community.
This
is
in
total
documents
we're
using
the
0.2
version
of
salsa.
We
will
update
to
1.0.
A
We
just
haven't
had
enough
time
to
undertake
that
work
yet,
but
we're
not
we're
not
trying
to
you
know,
come
up
with
this
on
our
own.
We're
really
trying
to
leverage
the
standards
that
are
part
of
the
Linux
Foundation
part
of
the
open,
ssf
and
bringing
together
this
this
concept
of
of
provenance
to
be
a
industry-wide
capability.
A
A
My
role
in
all
this
was
as
a
part-time
program
manager,
even
though
I'm
in
engineering
by
training,
so
I'm
going
to
do
my
best
to
to
walk
through
the
description
of
what
this
looks
like
going
back
in
time,
a
little
bit
before
we
undertook
this
work,
a
lot
of
cloud.
Cicd
providers
were
adding,
in
a
oidc
token,
to
uniquely
identify
a
workflow,
a
build
that
was
happening
on
their
platform.
The
reason
they
did
this
wasn't
for
provenance.
A
It
was
so
that
when
your
build
was
finished,
you
could
assume
into
a
cloud
provider
and
do
a
deploy,
but
what
we,
the
ecosystem
noticed,
is
that
a
lot
of
the
information
contained
in
that
oidc
token
is
exactly
what
we
would
want
for
build
provenance.
So
we
with
a
few
exceptions,
and
so
we
worked
with
the
GitHub
actions
team
to
add
in
that
additional
information,
and
then
the
other
thing
that
we
wanted
to
be
careful
about
was
ensuring
that
this
was
as
easy
as
possible
for
people
to
adopt.
A
A
A
A
The
registry
validates
the
the
Providence
attestations
and
then
it
makes
it
available
to
end
users,
and
so
you
know,
admittedly,
it's
a
little
bit
complicated,
there's
a
lot
of
different
moving
Parts
here,
but
the
real
value
of
the
six-door
project
is
that
it's
creating
this
distributed
source
of
trust,
that's
independent
of
a
specific
Cloud
CAC
provider,
that's
independent
of
a
specific
programming
language
package
manager,
and
it's
allowing
this.
This
architecture
is
going
to
allow
the
concept
of
Providence
to
propagate
through
the
open
source
industry.
Where
that's
that's
our
hope
and
dream.
A
So
the
often
we
get
questions
about
this
approach
again,
it
is
a
little
bit
complicated
like
are
we
getting
anything
for
that
complexity?
Yes,
we're
getting
quite
a
few
things.
So
a
couple
other
programming
language
package
managers
tried
to
delivered
this
concept
of
provenance
in
a
different
way
and
instead
of
looking
at
the
workload
identity
of
the
build
script,
they
were
focused
more
on
human
identity.
A
I,
don't
want
to
say
that
approach
is
wrong
in
every
case,
but
it
becomes
very
difficult.
So
first
you
have
to
strongly
authenticate
humans.
Maybe
you
want
like
government
issued
IDs
and
then
how
are
you
validating
those
then
you'd
ensure
that
humans
are
securing
their
account?
Maybe
you
have
to
enforce
multi-factor
authentication,
maybe
now
you
have
them
require
that
they
use
pass
keys.
If
your
platform
supports
that,
and
then
you
have
to
determine
the
human
was
a
member
of
the
project
that
they
had.
A
A
We
do
care,
you
know
they
still
have
to
authenticate
into
npm
and
have
the
permissions
available
to
publish,
but
the
the
provenance
access
stations
themselves,
don't
really
care
about
which
individual
human
is
is
running
this
workflow
and
that
simplified
the
process
considerably
for
us,
as
I
mentioned
earlier,
we're
no
longer
maintaining
durable,
Keys
long
term,
so
you're
generating
a
short-lived
key
pair
you're,
assigning
the
build
and
then
you're
throwing
away
the
private
key.
This
is
in
contrast
to
people.
You
know
provisioning
long
lived,
API
token
for
their
project.
A
If
someone
leaves
the
project,
they
have
to
rotate
it.
It's
just
much
easier
for
us
to
have
the
entire
key
life
cycle
live
within
a
single
build.
Instead
of
trying
to
worry
about
how
long
should
this
key
exist?
Was
it
still
valid?
What
if
someone
leaves
the
project
that
sort
of
thing
and
then
third
and
very
important,
we're
Distributing
Trust?
The
npm
registry
already
was
signing
packages
that
were
uploaded
to
it.
However,
in
the
event
of
a
compromise,
if
someone
compromised
the
npm
registry
sufficiently,
they
could
gain
access
to
the
signing
service.
A
A
Even
if
you
compromise
one
of
those
systems,
you
can't
forge
the
Providence,
so
you
could
Forge
Providence
certificates
if
you
compromised
fulsio,
but
then
you
wouldn't
have
an
authenticated,
npm
user
to
be
able
to
submit
them,
or
you
could
break
into
npm
and
put
your
malicious
package
in
there,
but
you
wouldn't
have
any
of
the
provenance
certificates
from
Sig
store
so
by
by
making
use
of
these
two
separate
systems.
We've
made
it
much
more
difficult
for
someone
to
sneak
malicious
code
into
these
public
good
instances.
A
Okay,
what
do
we
learn
along
the
way
I
already
touched
on
some
of
these
a
little
bit,
but
we
needed
to
figure
out
sort
of
what
our
first
toehold
was
in
this
problem
space.
So
we
narrowed
it
down
to
the
specific
cloud:
cicd
provider,
GitHub
actions
in
the
specific
package
registry
npm.
That
is
not
the
long-term
goal.
The
long-term
goal
is
that
this
works
for
many
Cloud
CSD
providers
and
it
works
for
many
programming
language
package
managers.
A
A
A
So
again,
you
know
some
of
the
pushback
that
we've
received.
People
are
like
well,
okay,
but
why
do
I
have
to
use
the
cloud
CISD
system
I've
always
built
on
my
laptop?
Well,
it's
complicated.
So
my
first
answer
is
you
can
build
on
your
laptop,
but
you
can't
do
that
with
Providence
right.
No,
if
you
are
just
getting
started
in
open
source,
if
you're
just
starting
a
new
open
source
project,
you
don't
have
to
publish
provenance
on
day
one
we
are
not
requiring
Providence
on
the
npm
registry.
A
However,
as
you
grow
as
your
project
grows,
as
more
people
come
to
rely
on
it,
you
should
really
strongly
consider
having
higher
trust
signals.
Just
like
you
would
go
and
update
the
readme,
ensure
your
project
has
a
license.
You
know,
as
you
get
larger
and
larger,
ensure
that
you
have
a
security
policy.
Maybe
you
want
to
have
a
vulnerability
reporting
system.
A
Adding
provenance
to
your
project
is
a
is
a
step
of
maturity
as
you
grow
ends.
You
know
it's
not
that
I,
don't
trust
any
of
your
individual
laptops,
sure
you're,
all
fine
people,
but
in
aggregate
we
have
thousands
tens
of
thousands.
Hundreds
of
thousands
millions
of
laptops
that
are
participating
in
build
systems
for
open
source
long
term.
This
isn't
a
sustainable
way
to
have
trust
in
our
ecosystem.
A
Oh
no,
okay,
the
Emojis
didn't
come
across,
but
the
second
thing
we
learned
is
that
machine
identity
is
greater
than
human
identity,
so
imagine
a
robot
with
two
heart
eyes
and
then
there's
a
human
below
it
crossing
their
arms.
Saying
no
I
touched
on
this
before,
but
it
gets
really
messy
when
you
start
trying
to
figure
out
how
to
strongly
authenticate
a
human
and
determine
their
trustworthiness
over
time.
People
join
projects.
A
People
leave
projects,
their
accounts
are
compromised
if
they're
improperly
secured
an
important
fact
about
build
provenance
is
that
we
aren't
saying
that
a
package
doesn't
contain
any
malicious
code.
We're
saying
that
we
know
exactly
what
the
package
contains
like
it's.
It's
still
up
to
you
to
go
and
audit
that
source
code
to
audit
those
build
instructions
to
ensure
that
they
don't
include
malicious
instructions.
A
However,
you
know
now
that
we
have
this
link.
We
can
do
that
and
then
we
no
longer
need
to
worry
about.
How
do
we
strong
authenticate
users?
What,
if
they're
in
a
different
geopolitical
jurisdiction,
we
don't
care?
The
source
code
is
what
matters.
The
build
instructions
are
what
matters
and
having
a
link
to
that
is
giving
this
us
this
new
security
capability
that
didn't
exist
before.
A
A
Really,
though,
if
you
think
back
to
that
in
total
documents,
probably
probably
you're
going
to
want
to
write
some
sort
of
like
stronger
policy
right
as
an
ecosystem,
we
haven't
really
defined
what
this
looks
like.
But
maybe
you
want
to
ensure
that
your
dependencies
are
coming
from
certain
organizations.
A
So
today,
our
story
on
how
we
verify
provenance
is
a
little
weak,
but
this
is
an
area
that
we're
looking
to
to
further
work
in,
so
that
we're
not
just
publishing
additional
information,
but
we're
actually
validating
it
before
the
deploy
which
is
which
is
you
know.
The
goal
here
is
to
ensure
that
our
the
code
that
we're
deploying
is
more
secure.
A
Okay,
I
snuck.
In
a
fourth
question:
how
can
you
get
involved?
I'm
so
glad
you
asked,
you
might
remember
this
slide.
So
again,
there's
a
lot
going
on
here.
If
you
own
a
cloud
CI
CD
system,
we
would
love
to
talk
to
you
I
believe
that
I
can
say
publicly,
because
the
full
CEO
repo
is
public,
that
our
friends
at
gitlab
just
landed.
Some
support
in
fulsio
I
think
one
four.
C
A
A
But,
oh
speaking,
of
bugged,
slides
the
open
ssf
was
supposed
to
be
in
the
middle
of
this.
So
another
way
to
participate,
of
course,
is
to
participate
in
these
conversations
that
are
happening
out
in
the
open.
The
openssf
has
a
working
group.
Securing
software
repos
I
find
the
name
a
bit
confusing,
but
there
by
repos
they
mean
programming,
language
package
managers
and
again
these
specifications
are
happening
in
the
salsa
organization
in
the
in
Toto
organization.
A
These
groups,
have
you
know
public
Community
meetings
and
then
last,
but
absolutely
not
least,
is
the
six
door
project.
Of
course,
so
we
reached
our
1.0
release
a
few
months
ago.
So
we're
done
no
we're
not
we're
nowhere
near
done,
there's
quite
a
bit
that
we
want
to
do
to
extend
this
as
the
salsa
specification
evolves.
They're
very
interested
in
not
just
build
properties,
but
also
Source
control
properties.
Think
about
where
all
your
commits
reviewed,
where
all
your
commits
signed.
A
You
know
we
would
love
to
figure
out
how
to
get
that
into
the
in
Toto
specification
as
well
support
those
sort
of
properties
as
well.
There's
a
ton
of
work
to
do
here,
and
we
would
love
your
help
and
just
a
final
thanks
to
all
these
projects
for
all
their
support
in
helping
us
launch
this
feature,
foreign.
A
C
All
right,
so
you
mentioned
that
all
that
it's
not
about
the
Providence,
isn't
validating
the
contents,
and
you
had
your
slide
about
saying
like
why
can't
I
build
on
my
laptop
so
currently,
I
can
because
npm
publish
is
just
uploading.
A
tarball,
so
I
can
build
on
my
laptop
upload,
the
tarball
from
anywhere
and
then
publish
with
provenance,
and
it
works
just
fine.
So
that
tells
me
that
the
only
thing
Providence
is
determining
is
where
I
published
from
and
so
I'm
curious.
A
A
The
the
providers
for
build
provenance
are
not
those,
though
it's
only
Cloud
CI
CD
systems,
and
the
reason
for
this
is
because
we
don't
have
a
way
today
to
attest
to
the
security
of
your
laptop,
but
we
do
have
the
ability
to
say.
Okay,
this
Cloud
CIT
CD
system
exists.
It
has
these
security
properties.
We
know
it's
using
a
fresh
VM
per
build.
We
know
that
these
build
instructions
are
are
what's
executing
we're
on
a
laptop.
We
don't
have
those
guarantees.
C
C
A
C
A
C
A
In
your
software
repo
right,
so
it's
a
it's
a
file
that
you
commit
yeah
in
terms
of
incidents
that
this
would
have
prevented.
I
do
not
work
on
the
npm
team
full-time
and
even
if
I
did
I,
don't
think
we
talk
publicly
much
about
our
instance.
We
did
recently
publish
a
threats
and
mitigation
page
and
I
was
going
to
include
a
slide
to
that
effect.
D
You
had
you
had
to
slide
up
with.
Do
you
want
to
go
back
to
the
the
flow
yeah,
and
so
you
know
I
I'm
familiar
with
the
the
full
CL
recore
flow
in
other
attestation
situations,
I
see
the
Providence
at
this
attestation,
Getting
Gone,
getting
uploaded
to
recore
and
also
added
to
the
registry.
Is
there
a
reason
for
the
duplication
of
that
that
attestation.
A
A
Yes,
so
so
I
think
I
think
there's.
Actually
this
is
kind
of
glossing
over
the
fact
that
there's
two
separate
artifacts
here
there's
the
signing
certificate
from
Full
co,
which
has
the
properties
burned
into
it
and
is
an
x509
certificate
you
can
validate
and
then
there's
the
attestation
documents,
which
also
has
the
the
properties
in
it.
A
But
offhand
I,
don't
know
the
way
that
that's
validated
so
I
believe
what's
happening
is
that
it's
crops
referencing
the
properties
in
the
signing
certificate
with
the
attestation
document
to
ensure
that
they
are
valid
and
that
that
so
you,
you
kind
of
need
to
keep
the
signing
certificate
around
in
order
to
ensure
that
the
province
attestations
are
valid.
But
then,
when
you're,
when
you're
interacting
with
it,
you
know
not.
Everyone
wants
to
process
the
x509
certificate.
So
it's
a
little
bit
easier
to
to
interact
with
the
in
Toto
document.
B
A
Yes,
so
we
do,
we
do
have
the
ability
to
invalidate
provenance
for
a
specific
package
if
there
was
some
some
known
security
issue
in
that
period
of
time.
So
we
don't.
We
don't
have
the
ability
to
add
Providence
if
it
doesn't
exist,
but
we
do
have
the
ability
to
take
it
away.
That's
that's
certainly
ability
we
wouldn't
use.
We
would
not
use
lightly
because
it
has
the
potential
to
impact.
You
know
everyone's
sort
of
like
supply
chain
security.