►
From YouTube: Oh The Places You'll Sign
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hi
everyone,
my
name
is
john
osborne.
I'm
a
supply
chain
architect
at
chain
guard
tonight,
I'm
going
to
be
talking
a
little
bit
about
sigstor,
which
is
a
free
signing
service
under
the
linux
foundation.
But
specifically
I'm
going
to
be
talking
about
it
in
the
context
of
salsa,
which
is
a
supply
chain
framework.
That's
been
out
for
a
little
while
and
the
reason
why
I'm
going
to
put
that
little
bit
of
a
spin
on
it.
A
If
you've
heard
six
store
talks
before
this
isn't
just
about
the
tech,
but
how
it
fits
into
the
framework
is
because
all
these
are
merging,
there's
kind
of
three
emerging
frameworks
right
now,
one
is
salsa
another
one
is
the
cis
benchmarks
for
supply
chain
that
came
out
another
one
from
nist
called
nist
ssdf
and
in
all
these
different
supply
chain
frameworks.
You
end
up
signing
a
lot
of
things,
and
so
it
ends
up
needing
to
be
automated
you're
constantly
not
only
just
signing
your
artifacts
but
you're.
A
Making
these
things
called
attestations,
which
could
be
include
things
like
an
s-bomb
or
other
just
statements
that
you
want
to
make
about
your
build
systems
about
your
dependencies,
but
your
source
code
and
so
on,
and
so
sigstor
ends
up
playing
a
big
role,
because
it's
kind
of
constantly
signing
things,
artifacts
and
and
documentation
attestations
about
the
process
as
it
goes
along
and
so
there's
a
big
role
there
for
six
store.
A
I
didn't
spend
a
lot
of
time
putting
together
content
on
the
supply
chain
framework
in
general,
but
I
did
want
to
start
off
this
talk
with
talking
a
little
bit
about
how
a
chain
guard
views
this
this
this
problem
space
specifically
so
I'll
share.
My
screen
right
here.
A
A
Is
people
immediately
tend
to
look
at
dependencies,
and
that
is
a
big
role
inside
of
software
supply
chain,
all
your
dependencies
that
you
bring
in
and
then
their
dependencies
and
all
the
layers
below
that
your
dependency,
trees
or
graphs
whatever
it
may
look
like,
there's
been
lots
of
studies
out
there
on
different
languages
and
how
many
levels
they
go.
Typically
in
some
languages
are
better
than
others,
but
software
supply
chain
isn't
just
about
your
dependencies
and
it
kind
of
breaks
down.
I
like
to
think
of
it
as
two
parts.
A
One
is
your
dependencies
and
then
the
other
pieces
is
all
the
systems
that
would
interact
with
an
artifact
from
development
out
to
production.
So
it
could
include
things
like
your
ide,
for
instance,
in
the
case
of
the
solarwinds,
or
it
could
include
things
like
locking
down
your
git
repos
and
not
just
other
testing
and
attestations
and
those
things
tend
to
run.
A
You
know
as
privileged
users
and
and
those
types
of
things,
so
limiting
access
to
those
removing
different
ways
that
your
system
could
be
compromised,
as
it
goes
all
the
way
from
development
out
to
production,
and
so
we
at
chain
guard
really
view
the
software
supply
chain
problem
as
a
lack
of
transparency
and
the
reason.
Why
is
because,
if
you
look
at
historically
how
we've
done
security,
it's
really
based
around
doing
putting
better
fences
around
our
systems,
implementing
better
security
practices
for
what
is
running
in
production.
A
But
it
hasn't
necessarily
been
around
all
those
type
of
things
that
now
we're
trying
to
adjust
in
the
supply
chain
framework.
And
the
reason
for
that
is
we
really
just
didn't.
Have
the
information
so
historically,
there's
been
no
way
to
tell
whether
you
know
who
wrote
in
apache
commons
library
or
even
if
you
know
something
came
from
a
certain
person.
There's
really
no
proof.
There's.
Definitely
no
cryptographic
evidence
that
something
came
from
a
person
that
it
says
it
is
or
what
methods
and
that
they
used
to
build
their
systems.
A
I
mean
for
me
personally,
I
use
fedora
on
my
desktop
and,
if
anything,
that's
almost
user
facing
you
know
video
audio
those
types
of
things.
Those
projects
typically
are
maintained
by
one
person
that
I've
never
met
or
heard
of
right.
So
it's
it's
there's
a
lot
that
goes
into
supply
chain.
Now.
This
query
here
is,
is
one
that
I
run
in
bigquery.
A
If
you
go
to
depths.dev,
which
is
a
project
essentially
from
google,
where
they
and
where
they
just
ingested
all
this
data
about
dependencies
out
there
they
went
to
github,
they
went
to
all
the
main
repos
that
are
out
there
and
they
just
ingested
all
this
data
and
they
really
tried
to
track
what
projects
are
dependent
on
each
other
and
then
what
is
the
state
of
those
projects?
Are
they
maintained?
When
is
the
last
commit?
A
Are
there
dependencies
out
there
and
there's
a
really
good
blog
out
there
on
devs.dev,
but
they
also
made
the
data
set
publicly
available
on
bigquery,
which
is
pretty
cool,
so
I
went-
and
I
ran
this
query
and
what
it
does
is.
These
were
projects
at
the
time
that
I
ran
it
that
had
critical
cdes
but
then
also
had
majored.
A
They
were
major
dependents
for
other
projects,
so
this
could
have
been
junit
all
these
you've
heard
of
a
lot
of
node.js
projects
out
there.
These
could
be
really
low
in
the
stack,
which
means,
for
instance,
the
junit
right,
there's
63
projects
that
are
depending
on
that,
but
there's
probably
60,
there's
probably
each
one
of
those
63
projects
probably
has
other
projects
above
it
right,
usually
j
units
pretty
low
in
the
stack,
so
the
sprawl
there.
That's
now,
inheriting
this
cve
at
least
the
time
that
I
ran.
A
A
The
second
aspect
to
it
is
all
the
systems
that's
going
to
interact
with
your
artifact
as
it
goes
out
there
and
one
of
the
things
I
look
at
is
you
know
historically,
if
you
look
at
let's
say
historically,
but
in
the
last
few
years,
devsecops
right
a
lot
of
let's
take
the
people
and
process
part
of
it
out
there,
because
that's
a
whole
separate
conversation,
but
the
devsec
ops,
a
lot
of
it
in
terms
of
technology,
has
been
about
shifting
left
right,
so
taking
all
the
out-of-band
stuff
that
we
used
to
do
at
the
end
of
the
software
life
cycle
and
shifting
it
left
right.
A
So
that's
important.
Of
course
we
should
do
that.
That
gets
us
feedback
and
up
gets
our
systems
up
the
door
faster.
But
what
about
all
those
systems
that
were
already
left
right?
So
those
could
be
your
get
management
repos
or
your
security
scans.
All
those
things
right,
those
have
to
be
locked
down
as
well,
and
I
think
part
of
it
was.
We
took
those
for
granted
right,
and
so
a
couple
questions
I
put
here
is:
there's
really
no
way
for
most
systems.
A
Most
pipelines
to
just
do
simple
verifications
like
can
the
source
code
actually
be
verified
in
the
sense
that
can
you
actually
tie
back
what's
running
into
production
to
get
commits
right?
Do
you
have
actually
cryptographic
evidence
that
can
do
that?
Can
the
build
system
can
you?
Can
you
trace
it
back
to
the
build
system
once
it's
running
in
production?
Do
you
actually
know
where
it
came
from?
A
A
So
when
you
really
look
at
it
from
the
the
salsa
perspective,
there
are
things
that
are
lacking
there
and
that's
really
what
salsa
is
intended
to
kind
of
fill
in
some
of
those
gaps,
and
there
was
a
big
announcement
this
week
from
github
around
node
node.js
and
in
six
store,
and
one
of
the
quotes
was
from
github,
which
I
liked
was.
A
A
Problem
there
was
next
executive
order
last
year,
and
I
thought
that
was.
It
was
interesting
because
it
was
the
first
executive
order.
I've
ever
seen
that
actually
called
out
specific
technologies.
They
actually
called
out
things
like
s-bombs,
which
is
which
I'll
talk
about.
A
If
you
don't
know
that
it
is
that's
fine
I'll
address
that
shortly,
but
I
grabbed
this
quote,
because
I
I
liked
it-
and
so
I
highlighted
it
and
and
what
it
said
was
basically
the
trust
we
placed
in
our
infrastructure
is
basically
proportional
to
how
transparent
it
is
right
and
when
we
look
at
software
supply
chain
historically,
it
hasn't
been
very
transparent
right.
So
we
want
to
increase
transparency.
A
So
for
us
we're
looking
at
the
software
supply
chain
and
we
want
to
create
transparency
so
the
way
we're
going
to
do
that
is
essentially
building
a
massive
data
layer
around
software
supply
chain,
artifacts
or
software
supply
chain
metadata,
and,
to
me
the
three
main
components
to
that
there
are
others,
but
the
three
main
components
of
that
are
is
one
digital
signing.
So
in
the
in
this
context,
I'll
talk
about
six
store,
but
it
could
potentially
be
other
projects
as
well.
A
So
those
are
digital
signatures,
you're,
assigning,
artifacts,
you're
signing
all
sorts
of
other
metadata,
as
your
project
goes
from
development
to
production.
The
second
piece
is
our
s-bombs,
so
s-bombs
is
now
mandated
in
a
lot
of
cases,
so
it's
mandated
for
instance.
If
anyone
wants
to
sell
software
to
the
government,
they
actually
legally
have
to
provide
an
s-bomb
now
and
what
is
inside.
An
s-bom
is
essentially
a
list
of
essentially
a
list
of
software
dependencies.
A
It
could
be
external
systems,
anything
that
it
depends
on
also
licensing
there's
more
to
it
than
that.
But
the
main
components
are
your
dependencies
and
your
licensing.
Those
are
important
and
then
the
third
piece
which
I
think
a
lot
of
people
are
probably
new
to
is
called
attestations
and
ad
stations.
A
It's
not
that
complicated
they're,
essentially
json
documents
and
they're
json
documents
that
say
specific
things,
so
they
might
say
something
like.
I
did
a
two
peer
review
or
I
did
a
static
code
analysis
or
I
did
follow
this
method
of
salsa
or
you
know
I
did
a
security
scan
and
we're
actually
created
I'll
actually
create
an
annotation
for
you
during
this
webinar
and
we
can
sign
it,
and
so
then,
we'll
have
cryptographic
evidence
of
that.
I
created
it.
A
So
sick
store,
so
there
have
been
signing
methods
before
six
store.
Really.
What
it's
trying
to
address
is
a
couple
key
pieces
is
one
I
think,
having
a
great
ux
right.
Anyone
that's
worked
in
software
knows
for
a
long
time.
If,
if
something's
really
hard,
it's
really
going
to
be
have
low
adoption
right,
I
came
from
red
hat
and
you
know
it
was
pretty
common.
It
was
almost
a
joke
that
people
would
disable
se
linux
right.
Se,
linux
is
an
incredibly
powerful
technology.
A
It
had
stopped
at
least
all
the
main
container
breakouts
if
it
was
configured
correctly
that
I've
been
tracking
right.
So,
but
you
know
it's
not
necessarily
easy
to
use
unless
it's
automated
for
you
right,
and
so
we
know
at
six
store
and
there's
a
long,
long
record
of
other
projects
that
have
suffered
from
kind
of
similar,
similar
states
right.
So
we
know
that
one
it
has
to
be
easy
to
use,
and
so
the
idea
of
six
store
is
you
don't
have
to
necessarily
know
or
manage
keys.
A
It's
all
done
for
you,
but
then
also
it
has
something
called
keyless
mode.
So
keyless
mode
is,
you
know
you
get
a
short
term
certificate
and
it's
in
it
lives
in
memory.
So
in
most
cases
it
doesn't
touch
disk,
so
no
one
has
to
manage
it.
No
one
has
to
worry
about
their
public
key
or
their
private
key,
and
also
since
it
has
this
mode,
it
can
plug
into
automation
systems.
A
So
if
you're
a
person,
it
can
just
tie
into
your
oidc
login,
whether
it
be
google
or
github
or
any
number
of
odc
logins
or,
if
you're,
an
actual
machine
that
can
tie
into
your
workload
like
identity,
there
are
integrations
with
spiffy
or
anything
else
really
can
tie
into
key
management
systems,
for
instance
aws.
It
can
tie
into
their
kms
system
same
google
azure
anything
I
think,
with
a
pkcs
11
interface
it
can.
It
can
tie
into.
A
So
there's
a
couple
key
pieces
to
sig
store,
one
is
cosine,
that's
the
piece,
that's
actually
making
the
signatures,
and
that's
that's.
What's
actually
signing
things.
Falcio
is
a
certificate
authority.
All
falcio
really
does
is
essentially
exchanges,
your
oidc
login
for
a
certificate.
So
you
log
in
with
google
as
an
example,
and
you
go
to
sign
something,
and
then
it's
going
to
create
you
a
short
term
certificate
that
lives
in
memory
that
it'll
just
be
a
standard
x,
509
certificate
except
the
the
email.
A
That's
in
there
will
be
your
gmail
login
that
you
logged
in
with
and
it'll
be
just
for
key
signing
and
it
lasts
about.
I
think
the
default
is
20
minutes.
So
it's
very
short
term,
and
then
the
third
piece
is
recore.
Recore
is
essentially
the
the
transparency
log.
On
the
back
end
that
you
can
use
for
audits,
you
can
use
to
verify
that
things
were
signed
by
individuals.
A
Of
course
you
need
some
method
to
do
that,
since
the
certificate's
going
to
be
gone
after
20
minutes
right,
and
so
the
whole
point
of
this
is
that
you
can
cryptographically
create
all
these
these
pieces.
You
can
verify
them
in
a
very
easy
way.
It's
all
community
operated.
So
there
was
a
very
cool
ceremony
last
year.
It's
on
it's
on
youtube.
You
can
find
it.
They
did
a
essentially
a
tough
ceremony.
A
So
there's
five
five
people
walking
around
with
eb
keys
that
created
this,
the
root
ca
for
for
six
store
and
they're
all
working
for
you
know
other
corporations
or
or
universities
and
there's
also
a
free
public
instance
out
there.
So
in
the
free
public
instance,
we've
hit
almost
over
three
million
entries
so
far
in
the
community.
In
the
public
record
log.
A
So
really
why
we
care
about
all
this
is
simply
around
key
automation,
so
this
was
just
something
I
did
on
my
laptop.
You
can
sign
anything
not
just
container
images,
not
just
attestations
and
s
bombs.
You
can
actually
sign
out
as
anything
so.
We've
talked
to
customers
that
want
to
sign
assembly
code.
We've
talked
to
customers
that
want
to
assign
sign.
You
know
all
these
binaries
are
legacy
systems,
and
that
makes
sense
right
cause.
A
If
you
think
about
a
legacy
system
say
it's
at
you
know
just
say
it's
a
an
edge
type
system
right.
You
built
it
you're,
deploying
it
in
a
lot
of
cases,
especially
in
the
enterprise.
Those
things
aren't
necessarily
getting
updated
very
often
right.
So
if
it's
been
running
for
a
couple
years,
you
actually
have
no
method
of
tying
back
that
it's
actually
the
same
binary
that
you
shipped
two
years
ago,
right
and
so
signatures
help
with
that,
because
you'll
know
that
it
actually
is
the
same
binary
and
you
have
evidence
that
it
is.
A
A
The
usage
is
very
easy,
simply
cosine
sine
cosine
a
test
if
you're
signing
it
at
a
station
and
then
verify
cosine
verify
so
all
very
straightforward
there.
If
you're
signing
an
s
bomb,
one
nuance
there
is
s-bombs
are
actually
considered
an
attestation
now.
So,
if
you
go
to
sign
something,
an
s-bomb
you'll
actually
just
be
signing
an
attestation
that
the
s-bomb
is
what
you
say
it
is.
A
We
also
have
a
project
called
get
sign,
which
was
really
what
the
which
is
really
what
the
github
announcement
was
this
week
and
I'll
do
a
demo
and
talk
a
little
bit
about
that
more
also.
A
This
is
the
google
container
registry,
and
I
just
want
to
show
you
this
because
it's
important
and
it
has
to
do
with
signing,
because
it's
the
way
that
they,
these
things
actually
these
artifacts
get
stored.
So
this
is
a
pretty
basic
busybox
image
that
I
copied
over
about
a
half
hour
ago
into
this
registry.
So
this
is
just
the
plain
busybox
latest
I
copied
it
over
and
I
just
want
to
point
out.
The
hash
here
ends
in
693,
because
that's
important
and
you'll
see
why
in
a
second.
A
A
A
So
it
scanned
clean
scan
because
this
was
the
busy
box
latest.
So
that's
very
nice.
We
want
to
have
clean
scans,
of
course,
so
what
I
can
do
now
is.
I
can
actually
create
an
attestation
around
that
and
I'll
just
set
some
environment
variables
which
aren't
necessary
per
se,
but
it'll
just
help
populate
the
attestation
component
to
it
and
I'll
make
a
very
short
default
station.
Sometimes
these
can
get
long,
but
in
this
case
I'll
actually
embed
the
scanning
results.
A
Inside
of,
if
you
see
here,
the
trivia
scan
I'll,
actually
embed
the
or
this
the
scanning
results
inside
manifestation,
and
I'm
going
to
do
that
because
that
way
I'll
be
able
to
prove
later
that
this
had
a
clean
scan
when
it
went
out
the
door
right
and
so
what
I'll
do
I'll
sign
the
image
first,
so
you
can
see
that
cosign
sign.
A
Google,
so
I'll
go
back
to
the
signature
here
and
it's
going
to
say
it's
just
telling
me
right
now
that
this
is
in
a
private
container
registry.
So
it
just
wants
to
make
sure
that
I
want
it.
I
want
to
go
ahead
because
it
is
private,
I'm
going
to
say
yes
and
it
pushed
the
signature
to
busy
box
our
to
the
google
container
registry.
So
and
that's
why
I
wanted
to
show
you
what
this
looks
like.
So
if
I
come
back
here,
remember
to
descended
in
693.
A
A
And
this
had,
this
is
the
same.
Hash
ends
in
693,
but
dot
sig,
and
so
that's
just
kind
of
one
interesting
nuance
of
cosine
in
general
is
when
you
sign
something
it
can
actually
store
these
things
inside
the
container
registry.
It
stores
them
in
what's
called
an
oci
artifact,
and
it
can
do
that
for
signatures.
So
anything
you
create
a
signature.
It'll
be
dot
sig.
A
If
you
create
an
out
of
station
usb
att
and
if
you
can
create,
you
can
create
s-bombs
too
and
they'll
be
dot
s-bom,
and
if
I
look
in
here,
I
can
actually
go
see
the
manifest.
So
I
can
actually
see
some
of
these
annotations
inside
the
manifest
here.
So
I
can
see
that
there
is
a
certificate
I
can
see
the
chain,
that's
the
that's.
The
sig
store
public
chain
there
inside
that
manifest
file,
and
so
that's
all
very
cool.
A
So
you
can
see
the
attestation
that
I've
created.
It's
got
some
information
in
it.
I
populated
that
it's
using
trivia
and
that
version
and
then
it
actually
populated
the
the
trivia
results
embedded
them
inside
the
scan.
Now
this
was
a
clean
scan,
so
this
was
very,
very
short
and
sweet,
but
now
we
can
go
ahead
and
sign
that
so
remember
remember.
I
said
it's
all
very
easy,
so
it's
cosine
a
test
as
well
right
here.
A
And
it
should
be
pushed
there,
so
now
it's
inside
the
transparency
log
also.
So,
if
I
come
in
here
back
to
busy
box,
I
can
see
there
should
be
a
new
annotation
in
here
again,
it's
693
dot
att.
So
this
was
the
same.
This
is
the
same
one.
If
I
look
at
this
manifest
file,
we
can
see
it's
got.
The
cosine
signature
and
the
cosine
certificate
bundle
all
those
things
again.
This
is
an
oci
artifact
that
it
put
it
put
it
inside
and
that
way
it
can
store
it
in
the
registry.
A
No
cosine
can
sign
any
anything
else
also,
but
if
it
signs
something
else
other
than
a
container
registry,
then
you'll
need
our
container
image.
Then
you
just
need
to
keep
track
of
the
signatures.
You
could
put
them
in
an
s3
bucket.
You
could
put
them.
You
could
use
the
same
naming
convention
with
sig
or
the
dot
att.
That's
all
something
that
you
have
the
option
to
do.
A
A
And
this
is
important,
so
it'll
verify
that
it's
signed,
but
also
by
who
it's
been
signed
by.
So
in
this
case
I
signed
it.
I
used
my
my
work.
Email
and
the
other
stuff
is
just
a
certificate
type
of
information,
nothing
important,
but
that
was
cool
and
then
I
can
verify
the
attestation
also.
So
I
can
make
sure
the
attestation
was
signed
like
we
said
it
was.
A
And
yes,
so
this
was
the
this
is
kind
of
the
information
that
similar
to
what
you
saw,
but
it's
using
in
toto.
So
this
is
the
the
basically
the
structured
way
that
we're
creating
these
attestations
and
it's
got
the
signature
and
at
the
end
it's
got
a
signature
field
down
here.
A
So
there's
also
a
record
log.
So
I
can
use
the
record
log
and
let
me
scroll
up:
do
we
have
the
id
that
was
created?
Let's
scroll
up
here,
you
scroll
all
the
way
up
to
sorry,
I
forgot
to
grab
this
id,
so
this
was
the
entry
in
the
log.
So
this
was
the
three
millionth
166
785th
entry
in
the
log,
so
we
can
check
that
from
the
command
line.
If
you
wanted
to.
A
And
also
there's
a
web
interface.
Also
so
I'll
show
you
what
that
looks
like
this.
Was
the
entry
in
a
log,
3
millionth
same
attestation,
information
and
it's
all
encoded,
so
you're
not
going
to
see
any
of
the
the
specifics
for
that
it's
all
encoded,
but
if
we
go
out
to
the
web
also,
we
can
put
that
same
id
inside
of
there's
a
public
interface
here.
So
if
I
type
that-
and
I
can
take
a
look
so
it's
proves
that
it
was
signed
by
sigstor-
it's
my
email
again.
A
This
is
the
x5
of
9
certificate
that
I
created
so
it
all
it
did
was
since
I
logged
in
with
google,
it
took
my
google
email
address
and
put
it
inside
of
chainguard.
Of
course,
I
can
see
that
there
if
I
log
down
this,
is
all
informations
encoded,
but
that's
the
attestation,
and
if
I
want
to
do
some
verification,
you
can
actually
verify
that
things
were
it's.
The
back
end
is
a
merkle
tree.
A
A
Okay,
so
that's
a
demo
cosign!
You
understand
how
it
works
now.
So
really
it's
it's
important
to
level
set
on
what
that
means,
so
signatures
by
themselves,
actually
don't
do
too
much
they
essentially
what
do
they
guarantee?
So
they
guarantee
that
one.
It's
exactly
the
same
as
when
you
signed
it
and
the
guarantee
that
you
signed
it
or
the
workload
signed
it
right.
So
the
signatures
by
itself.
A
They
can,
if
you
just
sign
us
up
for
artifact,
you
can
prove
that
it
was
exactly
that
way
and
that
you
signed
it
the
day
you
signed
it
right.
So
that's
good
for
making
sure
that
things
don't
necessarily
have
changed,
but
we
want
to
do
a
lot
more
than
that
right.
So
we
want
to
actually
start
signing
all
these
other
artifacts.
We
want
to
start
creating
attestations
around
how
it
was
built.
The
you'll
start
hearing
this
term
called
providence.
A
That's
really
based
around
the
build
process,
so
all
the
build
systems
that
were
interacted
with
it
as
it
went
out
the
door
most,
notably
typically,
what
people
are
signing.
The
kind
of
three
main
things
now
is
they're
signing
their
git
commits
they're,
signing
s-bombs,
they're
signing
attestations
and
their
artifacts.
A
So
s-bomb
there's
two
emerging
standards
out
there
right
right
now,
I
shouldn't
say
emerging,
but
a
lot
of
they've
actually
been
around
for
10
years,
but
they're
emerging
in
terms
of
popularity.
I
guess
you
could
say
so
one
is
spdx.
The
other
one
is
cyclone
at
chain
guard
we're
not
too
opinionated
on
it.
I
think
both
formats
will
probably
be
here.
A
One
interesting
nuance
here
at
wrinkle
is:
there's
actually
an
effort
to
put
some
companion
documents
out
there
with
that,
so
one
is
called
vex
or
the
vulnerability
exploitability
exchange.
What
vex
is
is
vex
is
something
that
would
come
from
a
vendor.
So
it's
a
standardized
way
to
make
attestations,
essentially
around
vulnerabilities.
So
a
lot
of
companies
have
been
doing
this
already.
So,
for
instance,
I
came
from
red
hat,
they
had
they
used
an
open
thing
called
oval,
and
that
was
a
standard
to
say
whether
something
was
vulnerable
or
not.
Vex
is
very
similar.
A
It's
just
a
companion
piece
to
the
s-bomb
and
it's
an
open
way
right.
So
if
you
look
at
a
lot
of
sca,
tooling
and
things
they've
been
creating
these
big
databases
that
they've
had
for
forever
right,
s-bombs
is
an
open
way
to
do
that,
because
you
know
we're
all
using
the
same
software
right
in
the
back
end.
It
doesn't
matter
if
you're
in
telco
or
startup
or
if
you're
a
bank
you're
everyone's
kind
of
using
the
same
components
right.
So
let's
have
our
standardized
way
to
do
that.
A
Invex
is
a
standardized
way
for
the
vendors
to
make
attestations
about.
You
know,
there's
say
that,
for
instance,
say:
there's
a
cbe.
They
can
say
if
actually
what
they're
shipping
is
affected
by
that,
and
it
might
not
right
for
a
number
of
reasons.
It
might
just
be
mitigated
in
the
context
of
the
environment
or
a
number
of
other
factors
right.
A
Attestations
this
is
new
for
a
lot
of
people,
so
I
think
sometimes
it
can
be
a
little
confusing,
but
all
it
really
is
is
a
json
document
and
the
reason
why
it's
important
is,
you
can
say
things
in
a
structured
or
unstructured
way
about
how
about
your
software
right.
So
you
could
say
things
like
the
build
system
that
it
created
and
I'm
going
to
create.
I'm
going
to
show
you
some
specific
edit
real
live
data
stations
in
a
second,
in
addition
to
the
trivia
one,
but
you
can
also
create
unstructured
ones.
A
If
you
want
to
or
create
your
own
structure,
so
you
might
have,
for
instance,
your
your
organization
might
do
things
on
top
of
certain
frameworks
or
have
their
own
checks.
They
might
have
their
own
review
boards.
You
can
make
attestations
that
those
things
were
followed
and
they
can
be
signed.
A
Commonly
I
would
say
that
the
number
one
thing
that
we
see
for
other
stations
right
now
is
how
it
was
built
and
you'll
hear
that
term
providence
a
lot
province
just
means
how
it
was
built.
So,
for
instance,
you'll
find
these
slides
I'll
put
them
in
like
on
my
github
repo.
But
you
know
you
might
see
something
like
there
might
be
an
adaptation
that
says
okay.
This
was
actually
built
from
a
very
specific
git
commit
right,
because
that
has
to
do
with
the
providence
and
how
it's
created.
A
You
might
have
other
ones
around
how
it
was
tested,
and
then
you
have
a
lot
around
security
scans,
which
is
what
I
just
showed
you
another
interesting
thing.
There
is
they're,
actually
standardizing
the
security
stand
format
now
also.
So,
if
you
noticed,
when
I
scanned
with
trivia,
it
actually
outputted
to
something
called
serif,
which
is,
I
think,
it's
an
oasis
standard
for
how
that
looks
like
too-
and
this
is
all
really
important,
because
everything
is
no
longer
going
to
be
a
one
off
right.
A
So
now
we
have
standardized
way
to
say:
what's
what
we're
shipping
with
s-bombs,
if
they're
affected
by
vulnerabilities
with
vex,
we
have
standardized
way
to
sign
things.
We
have
standardized
way
to
make
common
attestations
and
we
have
standardized
way
to
do
these
security
scans
and
other
things.
So
now
that
everything
is
standardized,
we're
going
to
be
using
all
the
same
software
and
we
don't
have
to
all
do
one-off
efforts
to
validate
and
vet
that
software
and
sigstor
is
really
critical
to
all
this,
because
it's
constantly
just
signing
and
verifying
all
these
things
right.
A
So
all
the
attestations.
Think
of
anything
that,
as
you
get
more
advanced
a
lot
of
customers
now
they
might
just
be
signing
they.
They
might
just
be
signing
their
documents
right
as
a
way
to
start
or
they
might
just
be
signing
their
s-bombs
right
or
just
signing
their
container
images
right,
but
as
they
get
further
along
in
the
salsa
path,
they're
constantly
signing
things,
they're
constantly
verifying
them
as
they
go
out
the
door.
A
So
I
wanted
to
that
was
all
great,
but
I
wanted
to
walk
through
some
specifics
on
what
that
would
look
like.
So
just
a
few
slides
specific
to
salsa,
so
salsa
covers
a
lot
of
areas
around
your
source
code
and
your
builds
and
your
dependencies
and
all
those
things.
But
for
this
case
I'm
just
going
to
talk
I'm
going
to
walk
you
through
level,
one
through
four,
so
you
can
see
what
it
might
look
like
right,
so
salsa
level.
One
is
a
lot
of
basics
around
documentation,
a
salsa
level.
A
One
build
would
say
that
you
have
a
scripts
to
do
it
right,
we're
not
doing
artesian
handcrafted
builds.
You
at
least
have
a
script.
It
could
run
in
your
laptop,
hopefully
there's
some
providence
available
some
information
around
how
that
was
built
right
and
there's
a
script
to
do
that.
This
is
a
real
life
example.
A
That's
in
the
recore
log
on
on
how
to
do
that,
and
you
can
click
back
on
that
as
well,
but
this
was
specific
around
maven,
so
this
person
was
creating
using
a
docker
file
and
had
some
maven
and
they've
some
packages,
and
this
one
came
from
red
hat
and
red
hat's
been
an
early,
adopter
and
contributor
to
six
store
as
well
and
they've
done
a
great
job.
Here
so
in
this
case
they
have
created
ada
stations
using
the
entoto
framework
and
the
use
in
the
salsa
prominence
format
around
that.
A
So,
as
you
get
a
little
more
mature
past,
just
scripting
your
builds,
you
might
want
to
say
that
you
actually
have
a
build
service
right.
So
in
this
case
and
they're
using
this
was
equinix
and
they're,
using
making
attestations
around
their
specific,
build.
I
think
they're
using
github
actions
and
they're
making
out
of
stations
around
that.
So
that's
important,
so
not
only
you're,
adding
on
right.
So
you're
not
saying
not
only
was
it
scripted,
but
I
actually
had
a
build
service
to
do
that
right.
A
So
it
wasn't
just
a
one-off
running
on
someone's
laptop
I'm
actually
managing
that
from
a
central
place.
I
can
start
doing
lockdowns
around
that
and
now
I'm
I
have
to
do
providence
on
that
too
right.
So
I
have
to
assign
it
to
say
that
it
was
created
with
that
build
service,
and
I
can
verify
that
using
cosine
to
verify
the
attestation.
A
You
can
see
how
you
get
more
mature
as
you
go
up
to
levels,
and
one
of
the
reasons
why
I
like
salsa
specifically
is
it
gives
people
an
incremental
path
instead
of
you
know
just
an
entire
list.
It's
like
hey.
Here's,
a
here's,
the
crawl
walk,
run
path
to
get.
You
know
to
secure
your
software
supply
chain.
A
Level
three
so
you're
building
on
that
again,
not
only
do
you
have
a
central
build
service,
but
now
you're
building
as
code
right,
so
it's
more
locked
down
it's
becoming
a
little
bit
more
closer
to
hermetically
sealed
and
you
have
non-falsifiable
provenance.
So
you
know
exactly
how
cryptographic
evidence
is
now
mandated
at
level
three
for
your
build
system
and
for
your
build
as
code
right.
So
you're
not
there's
no
way
really
to
interact
with
the
system
and
and
there's
limited
paths
to
interrupt
that
process
right.
A
So
you
don't
have
secret
keys
also
in
that
system
you're
using
an
external
kms
to
automate
it
automatically
pull
that
so
this
doesn't
this
very
fits
very
well
into
git
ops,
but
get
ops
isn't
mandated
here.
It
just
mandates
that
you
have
a
build
system
and
that
you
can.
You
have
cryptographic
evidence
that
it
came
from
that
build
system.
A
This
was
another
real
life
example
using
the
salsa
framework.
They
were
using
ko
and
github
actions
around
that
and
they've
created
created
attestations
that
they
did
come
from
that
and
they
had
builders
code.
If
you
scroll,
if
you
click
on
the
example,
you
can
scroll
down
and
actually
see
all
the
materials
that
were
used
also
for
level
three.
A
Level
four,
so
this
is
the
the
highest
level.
This
is
really
where
you
start
to
get
more
in
depth
around
some
of
the
harder
parts
of
software
supply
chain.
So
you're
doing
things
like
reproducible
builds,
which
is
a
very
big
challenge.
Not
all
build
tools
are
reproducible.
So
if
I
go
to
build
something
with
docker,
for
instance-
and
I
can
build
it,
multiple
times
actually
have
different
binaries.
So
it's
it's
hard
to
reproduce
that,
and
this
was
really
critical.
A
You
know
solarwinds
gets
brought
up
in
terms
of
the
hack
and
stuff
that
happened,
but
they
actually
they've
been
addressing
it
really
aggressively.
So
if
you
looked
at
their
talk,
I
think
at
kubecon
last
year
it
was
really
cool
and
one
of
the
things
that
they
did
was
they
actually
created.
Reproducible
builds,
so
they
actually
have
two
pipelines
now
that
should
produce
the
same
binary,
and
so
even
if
you
know
breaking
into
an
ide
is
really
complex,
as
we
saw
in
that
attack.
A
But
now
someone
broke
into
their
ide
for
whatever
reason
again,
they
would
actually
be
able
to.
You
know,
even
if
they
started
signing
stuff
stuff
that
had
been
compromised
at
level.
Four
you
have.
Reproducible
builds
and
parallel
pipelines,
so
you
know,
for
instance,
even
if
somebody
did
get
in
and
was
able
to
circumvent
almost
everything.
Well,
you
know
the
binary
didn't
match,
so
you
can
go
investigate
that
and
that's
really,
you
know
salsa
level.
4
is
really
designed
to
be
kind
of
foolproof
there.
A
One
of
the
other
things
about
salsa
level,
four
is
that
it
includes
code
reviews,
so
this
one
was
one
that
I
made
up.
This
was
a
there's
this
in
a
a
standard
to
do
code
reviews
it's
not
approved
yet,
but
this
has
been
submitted
by
someone
at
chainguard
to
up
streams
as
a
standardized
way
to
create
code
reviews-
and
it
just
looks
like
this.
So
again,
it's
just
a
json
or
yaml
document.
That's
all
it
is,
and
you
can
sign
things
so
you
did
a
code
review.
A
A
Now
that's
specific
to
salsa.
Again,
though
it
it's
no
matter
which
framework
you're
adopting
it
is
very
similar.
So
I
just
highlighted
some
things
from
the
software
supply
chain:
security
guide
from
the
cis
benchmarks,
you're
signing
and
verifying
commits
you're
assigning
verifying
releases,
the
s-bomb,
the
build
pipeline,
the
versioning.
It's
all
signatures,
validation,
signatures,
verify
signatures,
verifies
things
verify,
so
you
can
see
the
pattern.
It's
not
going
to
be
any
different.
A
If
you
adopt
a
separate
framework,
it's
going
to
be
kind
of
a
very
similar
story,
again
secure
software
development
framework
from
nist
very
similar,
constantly
signing
things
you
want
to
be
able
to
create
an
immutable
log
voting
signs.
You
know,
that's
recore,
it's
the
immutable
log
for
audibility
reasons
you
want
to
be
doing
signing
commits
you
want
cryptographic,
evidence
and
hashes.
You
want
to
be
able
to
verify
how
things
were
built
again.
Sign
verifies
time,
verify
sign,
verify,
sign,
verify
and
all
that
needs
to
be
automated
and
that's
really
where
six
store
comes
in.
A
I
got
two
slides
left,
I
think
git
sign
is
something
else
we've
been
working
on,
and
this
is
really
what
the
github
big
announcement
was
about
with
npm.
A
The
reason
why
git
sign
is
so
important
is
because
it's
really
just
so
easy
to
use
and
I'll
I'll
show
you
a
demo
here
and
we'll
actually
stand
everything
up
from
scratch
in
a
repo
that
hasn't
been
touched
yet,
but
you
can
do
keyless
signing
so
you
can
do
git
commits
with
signing
six
store
either
in
a
couple
ways
you
can
set
it
up
where
every
time
you
do
a
git
commit.
A
All
you
have
to
do
is
just
add
a
flag
to
do
the
signing
or
you
can
actually
set
up
so
you're
just
doing
signing
by
default
every
time,
and
this
is
important
for
a
lot
of
reasons.
So,
if
you
saw
the
frameworks
you
said
there
was
a
lot
of
information
about
you
actually
had
to
do
sign
commits
this
is
a
great
way
to
do
it,
but
it
also
can
be
critical
to
doing
things
like
two
peer
reviews.
A
So
if
you
use
git
lab
or
github
there's
ways,
if
you
have
the
enterprise
version,
where
you
can
do
those
things
and
then
you
can
easily
integrate
it
into
that
and
one
of
the
key
things
from
github.
If
you
read
their
blogs
or
on
the
announcement
that
they
thought
was
that
I
thought
was
really
interesting.
A
Was
you
know
they
were
very
committed
to
having
they're
very
they're
very
committed
to
increasing
software
supply
chain
security,
but
they
are
also
very
committed
to
having
the
developers
not
for
it
to
be
very
easy
to
use
for
developers
right
and
that's
really
where
y6
store
was
was
so
important
and
what
they
chose
to
help.
Do
that.
So
when
you
do
sign
something,
you'll
see
this
little
certificate.
That'll
say
it
was
created
with
six
story.dev
and
this
was
a
tweet.
A
I
saw
this
week
from
derek
sheppard,
where
he,
you
know
someone
actually
tweeted
at
him,
that
somebody
had
faked
his
email,
which
is
something
you
can
do
with
github.
I
can
go
in
and
I
can
change
my
git
configs
to
any
email
and
it'll
show
up
that
way
in
the
log.
A
So
he's
saying:
oh,
I
better
sign
this
now,
so
actually,
there's
cryptographic
evidence
that
it
was
me
that
signed
it
and
really
stick
store
is
becoming
very
important
behind
the
get
signed
project
there.
So
I'll
do
a
quick
demo
for
you
with
good
sign
and.
A
There-
and
this
is
a
new
repository
and
I've
actually
put
my
demo
scripts
in
there
also.
So
if
you
want
to
see
what
those
look
like
you're
all
going
to
go,
do
that
nothing
really
in
here,
yet
there's
no
even
get
on
elks.
There
should
be
just
the
basic
files
in
here.
So
there's
just
a
get
folder
in
there,
and
this
is,
I'm
gonna
run
a
couple
commands.
This
is
all
I
have
to
do
just
one
time.
A
A
A
A
And
yes,
there's
my
commit
message:
it
says
that
use
get
sign.
You
can
see
the
six
store
pieces
here
and
that'll
be
in
the
recore
log.
Also,
if
we
want
to
go
look
at
that-
and
I
can
also
use
six
store
to
verify
this,
so
I'm
just
gonna
run
a
couple
commands
here,
so
I
can
pull
out
some
of
the
information
out
of
record.
A
A
Check
that
out-
and
this
is
what
we
just
signed
again-
it
came
from
me
jay
osborne
at
chinguard,
actually
zoom
in
here.
I
realized
I
forgot
to
zoom
in
the
last
time
I
was
here.
Another
key
thing
here
is
the
key
usage,
so
this
can
only
be
used
for
artifacts.
These
aren't
signatures,
you
can
use
for
a
website
or
anything
like
that.
The
usage
is
just
code
signing
and
there
shouldn't
be
too
much
else
out
here,
other
than
the
verification.
Again,
that's
the
inclusion
proof.
A
A
There
we
go
and
there
we
go
sign
it.
You
can
see
the
commit.
If
I
come
back
here,
it'll
be
now,
it
says
unverified,
because
github
hasn't
added
the
six
door
public,
the
six
store
certificate
into
its
into
its
trust
store.
I
think
that
is
something
that's
gonna
happen,
especially
now.
A
The
announcements
so
at
some
point,
that'll
stay
verified,
but
you
can't
see
that
it
was
signed
and
then
it
was
signed
by
six
door
and
getting
to
the
end
a
couple
other
key
things
why
we
do
all
this
eventually,
if
we
want
to
make
risk
management
based
decisions.
A
This
is
an
upstream
project,
I'm
talking
about
six
store,
but
this
is
a
chain
guard
and
we
work
kind
of
half
and
half.
So
we
work
upstream
a
lot
with
a
lot
of
different
projects,
quite
a
number
of
them
actually
in
standards
also,
but
on
the
product
side.
This
is
the
other
half
of
it,
so
we're
basically
building
products
that
are
going
to
take
all
those
artifacts
and
allow
you
to
do
risk
management
based
around
software
supply
chains,
so
policies,
continuous
verification,
eventing
alerts,
those
types
of
things
last
thing
I'll
mention
last
slide.
A
This
is
very
important.
We
did
work
with
the
linux
foundation
and
the
the
open
ssf
around
around
a
free
six
door,
training
course
so
that's
been
launched
and
you
can
check
out
our
blog
it's
on
edx.
You
can
google,
it
also
there's
an
approach
to
get
there,
but
our
team
got
a
couple:
people
john,
at
least
on
our
team.
It's
an
amazing
job
on
it.
I've
taken
it
and
I
think
it's
really
great
and
if
you
get
a
chance,
go
to
it,
it's
free!
It's
not
too
long,
and
it's
great.
A
I
appreciate
you
sticking
with
me
on
this
whenever
I'm
recording
at
night,
but
whenever
you're
whenever
you're
watching
it,
I
hope
you
enjoy
it
and
again
my
name
is
john
osborne.
You
can
reach
out
to
me
on
twitter
or
email
me,
j,
houseborn
at
chainguard.dev
and
happy
to
talk.
If
you
have
any
questions.