►
Description
Software Supply Chain Integrity with Sigstore - Marina Moore & Priya Wadhwa, Google
A
B
C
So
hi
everyone,
I'm
marina,
I'm
a
phd
student
at
nyu,
researching,
secure
software
updates
and
supply
chain
security.
More
generally,
I'm
a
maintainer
of
the
tuft
project,
the
update
framework,
tough,
as
well
as
octane,
which
is
the
automotive
variant
of
tough,
and
I
do
work
in
various
other
open
source
supply
chain
projects,
including
soup
store
and
notably,
and
various
other
projects.
B
And
I'm
priya,
I'm
a
software
engineer
on
the
google
open
source
security
team.
I
work
on
open
source
projects
like
six
store
and
tecton.
In
the
past,
I've
worked
on
open
source,
kubernetes
developer
tools
like
mini
cube
and
scaffold
fun.
Fact
I
like
to
play
the
drums,
but
it's
probably
not
so
fun
for
the
people.
I
live
with.
C
All
right,
so
why
do
we
need
six
star
so,
as
everyone
who's
here,
probably
is
aware
that
we
have
we,
as
a
community,
have
a
problem
with
supply
chain
security,
and
so
the?
What
sixth
is
looking
to
do
is
looking
to
find
a
way
to
securely,
distribute
all
the
pieces
involved
in
that
which
includes
the
software
itself,
as
well
as
things
like
s-fonts
and
other
information
that
we
need
securely
distributed
to
people.
B
So
we
started
cosine
a
few
months
ago
because
there
wasn't
a
really
easy
way
to
sign
container
images
and
that's
kind
of
how
cosign
started
as
a
project
to
automate
signing
containers
from
beginning
to
end.
So
you
can
kind
of
see
in
the
terminal
screen
grab
on
the
slide
that
you
can
use
cosign
to
generate
a
public
private
key
pair.
You
can
use
it
to
sign
your
image
without
private
key
pair,
and
you
can
verify
your
image
with
the
associated
public
key
as
well,
and
cosign
actually
has
support
for
signing
with
different
methods.
B
B
So
in
the
example
on
the
slide,
we're
actually
just
signing
a
regular
file
with
cosine.
You
can
upload
that
file
to
an
oci
registry
and
then
sign
it,
just
as
you
would
a
container
image
that
lives
in
your
oci
registry
as
well,
and
that
signature
is
stored
alongside
the
image
in
the
registry
as
well.
B
C
So
the
next
tool
in
the
six
store
ecosystem
is
called
record,
which
is
the
public
transparency
log.
It's
you
know
it's
a
transparency
log.
So
it's
an
immutable
and
tamper
resistant
log
in
which
users
can
sign
can
store,
assigned
metadata,
sorry
and
there's
a
tool.
The
record
cli,
which
makes
it
easy
to
query
anything.
That's
been
uploaded
to
the
log
as
well
as
append
new
metadata
entries
to
this
vlog.
C
One
of
the
cool
features
about
vcore
is
that
it
also
provides
by
default
a
timestamping
service
which
uses
the
rfc
3161
time,
stamping
service
standard
and
to
to
automatically
timestamp
anything
that's
uploaded
to
the
log.
So
you
can
make
sure
not
only
that
the
thing
that's
uploaded
that
you're,
you
know
verifying
is
the
thing
that
was
uploaded
to
the
log.
You
can
ensure
some
timeliness
properties
about
the
things
that
are
included
in
the
log.
C
And
the
final,
like
kind
of
core
sig
store
tool,
is
fulcio,
which
is
a
free
root.
Ca
that
uses
osu
email,
address,
verification
to
kind
of
simplify
developer
key
management,
so
instead
of
individual
developers
or
anyone,
who's,
signing
metadata
or
images
having
to
store
and
manage
private
keys
and
make
sure
that
they
stay
safe
forever.
What
fosio
does
is
it
allows
users
to
use
their
existing
oecd
supported,
email
addresses
to
to
verify
their
identity
and
then
pulsio
issues
them
a
short-lived
certificate
which
they
can
use
right
away
to
sign
that
that
metadata
or
information?
B
B
Okay,
where
is
that
there?
It
is
okay,
so
the
first
thing
I
need
is
just
a
piece
of
software
that
I
want
to
sign,
so
I
already
built
just
like
a
really
simple
docker
image
and
pushed
it
to
my
own
registry,
and
so
I
want
to
sign
it
and
I'm
going
to
use
cosine
and
it's
pretty
easy.
It's
just
a
cosine
sine
command
and
then
the
name
of
the
image.
B
Okay,
cool
redirected
to
this
oidc
flow,
so
this
is
how
I'm
going
to
authenticate
my
identity
and
prove
that
I
am
myself
so
I'm
going
to
log
in
with
my
own
personal
email
account
and
that's
pretty
much
all
I
have
to
do.
If
we
go
back
to
the
terminal,
we
should
see
that
cosine
was
able
to
sign
this
image
for
me.
So
the
way
that
it
did
it
was
it
generated
an
ephemeral,
public,
private
key
pair,
which
is
just
stored
in
memory
and
will
eventually
be
thrown
away
and
requested
a
certificate
from
fosio.
B
So
this
certificate
is
a
short-lived
certificate.
Like
marina
mentioned,
it's
only
valid
for
about
20
minutes
and
it'll
include
information
like
the
email
address
I
use
to
authenticate
and
the
public
key
that
we'll
use
for
verification
later
so
who's.
I
also
added
an
entry
into
the
record
transparency
log
to
keep
keep
track
of
the
signature
and
finally
push
the
entire
signature
to
my
registry,
where
it
will
live
alongside
my
image.
B
B
B
The
next
thing
it
does
is
make
sure
that
an
entry
was
put
into
the
transparency
log
when
the
signature
was
signed
and
that
it
was
during
the
window
of
validity
for
the
certificate
and
finally
make
sure
that
the
certificate
came
from
a
trusted
root,
ca
which
in
this
case
is
the
full
ceo
root
ca
and
then
there's
a
little
bit
more
information
like
who's
signed
damage.
It
was
me
and
the
actual
payload
that
the
signature
covers,
so
you
have
the
name
of
the
image
in
there
and
the
digest
of
the
image
itself.
B
B
And
in
here
we
have
the
base64
encoded
signature.
We
have
the
certificate
that
was
issued,
the
dia,
the
shawty
56
digest
over
the
payload
and
if,
for
some
reason,
I've
lost
this
log
index,
I
can
also
search
the
entire
transparency
log
by
email,
and
I
can
find
everything
that
I've
ever
signed
into
the
log,
which
is
a
bunch
of
stuff.
But
the
image
that
we
just
signed
is
somewhere
in
there.
B
B
On
the
other
side,
we
have
end
users
who
are
trying
to
verify
that
assigned
artifact
came
is
valid,
and
so
they
can
look
at
the
signature
in
the
record.
Transparency
log
also
find
the
certificate
and
make
sure
it's
valid,
and
they
can
also
ensure
that
the
certificate
came
from
a
trusted
root
certificate
authority
which
again
in
this
case,
would
be
the
full
seo
certificate
authority.
C
All
right
so
now
we're
going
to
talk
about
a
few
integrations
of
the
system
ecosystem
with
some
other
projects
in
the
supply
chain,
security
space.
So,
first
I'm
going
to
talk
for
a
minute
about
the
update
framework
or
taf,
which
is
a
framework
for
secure
software
updates
that
uses
metadata
about
artifacts,
to
assign
metadata
about
artifacts
to
prevent
node
attacks
on
a
software
update
system.
It's
based
on
this
principle
of
being
compromised
resilient,
which
means
so
that
if
any
single
developer,
key
or
repository
is
compromised,
I'm
not
sorry
or
repository.
C
So
the
way
this
works
is
we
held
this
offline
ceremony
where
we
generated
some
offline
keys
and
we
use
them
to
sign
metadata.
That
includes
the
public
keys
for
various
parts
of
the
system
ecosystem,
and
this
includes
the
fosura
root
cas
boots
certificate,
as
well
as
the
the
keys
used
to
sign
things
in
the
record
log,
and
so
this
allows
for
both
revocation
of
any
of
those
pieces
of
the
six
or
ecosystem.
C
C
The
next
thing
I
want
to
talk
about
is
in
toto,
which
is
a
framework
for
software
supply
chain
security.
More
generally,
it's
based
on
this
idea,
where
you
verify
every
single
step
in
the
supply
chain,
and
you
ensure
that
the
correct
person
did
that
step.
It
was
done
in
the
correct
order
and
all
the
steps
you
expected
to
happen
were
all
done
before
the
the
software
was
was
delivered.
So
here
we
have
an
example
of
an
intel
attestation
for
a
github
project.
A
C
B
Bit
about
how
we've
been
integrating
sligster
with
the
tekton
project,
so
for
those
of
you
who
may
not
know
techtron
is
an
open
source,
ci
cd
platform
on
kubernetes,
and
it
basically
just
lets.
You
run
your
build
pipelines
on
kubernetes
itself,
doing
things
like
building
images,
storing
them
somewhere
anything
you
normally
do
with
the
cicd
platform,
and
I've
been
working
on
tecton
chains
recently,
which
is
the
supply
chain
security
manager
for
tecton.
So
the
idea
behind
chains
is
that
it
runs
alongside
your
tachton
pipeline.
B
It
basically
observes
your
pipelines
and
provides
any
sort
of
supply
chain
security.
You
might
need
for
them.
So
this
includes
signing
artifacts
that
are
built
in
your
pipeline
with
cosign
and
also
includes
adding
entries
for
these
signatures
to
the
record
transparency
log.
It
can
request
certificates
from
pulsio
and
it
can
also
create
comprehensive,
build
provenance
for
your
pipeline
within
total
attestations
and
store
those
attestations
in
record
as
well.
B
B
B
B
So
if
we
go
to
the
next
slide,
you
can
actually
query
the
transparency
log
formula
provenance
with
the
digest
of
the
image
itself.
So
you
can
run
a
recourse,
cli
search
and
then
the
digest
and
it'll
spit
out
all
of
the
matching
entries
in
the
log,
and
you
can
get
some
more
information
from
that
entry
specifically
and
it'll
print
out
the
entire
entoto
out
of
build
provenance
for
the
build
of
that
image
itself.
B
So
I
had
to
cut
out
a
lot
of
information
from
this
providence
so
that
it
would
fit
on
the
slide,
but
it
includes
things
like
the
name
of
the
image.
The
digest
the
parameters
would
be
any
environment
variables
that
were
set
during
the
build
and
the
recipe
is
a
list
of
steps
and
each
step
corresponds
to
a
container
that
was
run
in
the
build.
So
in
the
recipe
you
can
see
the
list
of
containers
that
were
run
the
order
they
were
run
in
and
what
command
or
script
and
was
passed
into
each
container.
C
All
right,
so
some
future
steps
for
six
store,
so
cosign,
one
of
the
six
store
tools
already
had
its
1.0
release,
but
recall
and
felsio.
Those
are
still
upcoming,
they're
coming
up
pretty
soon.
Some
other
upcoming
projects
are
using
our
issue
inserts
to
other
nested
posterior
instances,
so
that
you
can
have
kind
of
a
local
instance
of
folsio
based
on
that
same
root
of
trust,
as
well
as
integrations
with
more
tooling
with
any
any
other
tooling
in
this
secure
software
supply
chain
system.
C
C
C
I
think
similar
for
the
next
question
of
how
you
trust
the
cosign
ecosystem.
I
think,
knowing
who
exactly
to
trust
to
sign.
It
is,
in
some
ways
an
individual
question
of
like
the
policy
of
the
consumer
of
the
software,
but
you
can
get
information
about
it
from
from
the
ecosystem.
To
then
make
that
decision.
B
See
I
understand
the
build
containers
are
sine
by
cosine
yeah.
You
can
use
cosine
to
sign
containers
that
you've
built
and
already
pushed
to
a
registry.
What
infrastructure
is
this
running
on?
I
think
right
now,
like
the
production
recorder
full
seo
we're
running
as
deployments
on
kubernetes,
always
the
last
time
I
checked,
they
were.
C
Okay,
here's
one
what
os
and
software
platforms
trust
the
filter
boot?
Is
it
arted
against
the
same
standards
as
other
cas
like
like?
We
said
in
the
previous
slide,
it's
still
just
before.
It's
still
like
waiting
for
the
1.0
release,
so
I
don't
think
it's
currently
put
into
any
oso
software
platforms.
That
would
be
kind
of
a
definitely
a
next
step
for
the
project
as
it
is
in
a
1.0
release
and
is
ready
for
large-scale
use
in
this
yeah.
B
C
They
kind
of
approach
the
problem
from
different
angles
and
different
pieces.
I
think
notary
does
a
lot
of
the
registry
storage
pieces
which
are
super
important
and
then
sixteen
does
the
kind
of
the
transparency
log
pieces
a
little
bit
differently,
so
they
just
kind
of
approach
it
in
slightly
different
ways.