►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Source Attestations with Gitsign - Billy Lynch, Chainguard
Attestations are a useful tool for attaching supply chain metadata to artifacts and images, but how can we attach attestations to source code itself? In this talk, we'll go into some of the ways you can attach attestations to source code with Git. Learn how data can be stored verifiably alongside commits, how attestations can be modeled to describe SLSA source requirements, and how tools like Gitsign can make this easy to add to your CI/CD pipelines.
A
All
right,
thank
you
thanks
everyone
for
coming
so
yeah.
What
we're
going
to
be
talking
about
today,
lightning
talk,
so
super
fast,
is
source
attestations
with
a
project
called
get
sign.
So
a
little
bit
about
myself.
My
name
is
Billy
Lynch
I'm,
a
software
engineer
over
at
chingard
I'm,
a
maintainer
for
the
get
sign
project
as
well
as
some
other
supply
chain.
Security
projects,
tecton
chains
and
I
also
make
contributions
to
the
rest
of
six
store
and
tecton
as
well
so
Source
out
of
stations.
A
So
the
first
thing
we
starting
to
talk
about
is
what
is
an
attestation?
You
might
also
hear
another
word
called
Providence.
So
what's
the
difference,
so
the
two
terms
here,
Providence
we're
really
talking
about
sort
of
the
who.
What
where,
when
why?
So
these
are
metadata
about
the
artifact?
Where
did
it
come
from?
What's
in
it?
Why
is
it
here?
Why
do
we
care
about
it?
An
attestation
is
the
metadata
itself,
isn't
necessarily
enough,
because
that
could
be
populated
and
produced
by
anyone.
So
an
attestation
is
really
trying
to
say.
A
A
So
really
the
difference
between
the
two
is
provenance
plus
some
identity
is,
is
what
really
makes
up
an
attestation
and
when
we
talk
about
identity?
Usually
this
is
where
signatures
come
into
play
and
if
we're
talking
about
signatures,
then
we're
going
to
be.
You
know
one
of
the
things
we're
going
to
be
talking
about
is
sixstore.
So
six
store
is
a
project
under
the
open
ssf
it
its
goal
is
to
make
signing
software
artifacts
easy.
Whether
this
is
images
git
commits
anything
part
of
your
sort
of
software
supply
chain.
A
We
want
to
make
that
signing
easy
and
one
of
the
really
cool
things
about
sigstore.
Is
it
has
this
process
what
we
call
keyless
signing,
which
allows
you
to
basically
generate
ephemeral,
keys
to
sign
objects
and
artifacts,
using
a
certificate,
Authority
called
fulsio
and
to
produce
signatures
and
attestations
and
put
them
into
a
transparency
law
called
recore?
A
And
what
this
lets
you
do
is
sort
of
offload
the
complexity
of
managing
Keys
to
six
door
tooling,
so
that
you
know
all
you
need
to
worry
about
is
like
making
sure
that
those
things
are
signed
and
not
having
to
worry
about
managing
gpg,
keys
and
rotation
and
stuff,
like
that.
So
one
of
the
tools
that
people
are
sort
of
most
familiar
with,
just
because
it's
been
around
for
a
little
bit
longer
is
a
tool
called
cosine
and
cosine
is
really
focused
on
container
signing
so
making
signing
oci
images.
A
It
can
also
do
blobs
stuff,
like
that
very
easy.
So
cosine
has
a
really
Nifty
command
called
cosine
of
test,
where
you
can
actually
attach
provenance
data
to
an
image
and
sign
it
to
make
an
attestation
that
about
that
image
right,
so
you
can
attach
s-bombs.
You
can
attach
hey
like
hey.
We
ran
this
check
on
on
this
image
and
you
can
attach
it
in
and
upload
it
as
in
the
same
registry.
A
So
you
can
see
at
the
bottom
here
there's
this
dot
ATT
file
that
actually
has
the
same
sha
within
the
tag
that
references,
the
image
that
it's
attesting
to.
So
this
really
Nifty
trick
What
it
lets
you
do
is
store
the
attestations
in
the
same
location
right.
So
if
you
have
the
ability
to
go
fetch
this
image,
you
also
have
the
ability
to
go
fetch
this
attestation.
A
So
that's
a
really
really
useful
tool
really
really
powerful.
So
one
of
the
things
that
we
were
sort
of
thinking
about
for
git
sign
is
you
know
we
have
this
Behavior
with
cosine.
We
can
add
attestations
to
images,
but
oci
images
are
just
one
artifact.
One
part
of
your
software
supply
chain
git
commits
are
another
part
right,
the
source
that
goes
into
your
CI,
the
source
that
goes
into
the
images
that
you
build
are
another
artifact
that
you
might
want
to
add
attestations
to
right.
A
A
So,
as
I
mentioned
in
the
beginning,
one
of
the
projects
I
work
on
is
called
git
sign.
So
the
original
sort
of
goal
for
git
sign
was
to
make
git
commit
signing
easy.
So
traditionally,
you'd
use
a
gpg
key
or
an
SSH
key
to
sign
your
commits,
but
with
Git
sign
you
can
actually
use
the
full
six
store,
keyless
flow
and
we
were
thinking
hey.
Can
we
apply
the
same
sort
of
principle
of
cosine,
a
test
to
git
sign
and
that's
what
I
sort
of
want
to
show
off
today?
A
So
we
have
a
really
quick
demo
I'm
just
going
to
hop
over
to
the
GitHub
repo
here.
So
this
is
just
a
sample
repo
that
I
put
together.
So
within
the
get
sign
repository,
we
have
it's
right
now,
a
separate
binary,
we're
working
towards
Upstream
into
the
git
sign
binary
itself.
A
tool
called
git
sign
a
test
right,
so
it's
very
much
mirroring
what
cosine
a
test
does
and
as
an
example
here,
I
have
a
few
GitHub
actions
that
are
producing
attestations.
A
Some
some
things
that
you
might
want
to
attach
to
your
Source
commits
right,
so
this
could
be
an
s-bomb.
You
know
what
are
the
transitive
dependencies
that
are
part
of
this
repo
that
are
going
into
my
builds
I'm
going
to
hand
wave
a
little
bit
here:
salsa
source
satisstation,
so
I
was
talking
right
before
this
one
of
the
things
that
if
you
look
at
the
in
Todo
docks
the
salsa
docs
sort
of
the
concept
of
two-party
review
and
have
all
my
changes
been
reviewed
by
by
someone
I
trust.
A
Can
we
generate
attestations
for
that
and
add
that
to
the
repository
things
like
scorecard
static
analysis-
and
you
can
extend
this
even
further
right-
fuzzing
have
CI
tests
ran
against
this.
What
were
the
results
of
those
CI
tests?
These
are
all
things
that
you
might
want
to
attach
to
these
commits
and
put
in
a
discoverable
location,
so
that
other
tooling
knows
how
to
find
it
and
then
can
take
advantage
of
it.
A
So
as
an
example
here,
here's
the
the
s-bomb
tool
that
ran
so
we're
just
using
the
kubernetes
bomb
tool.
So
it's
pretty
simple,
pretty
straightforward!
We're
just
checking
out
the
code
installing
the
bomb
tool,
installing
git
sign
a
test,
we're
generating
the
s-bomb
and
then
all
we're
doing
here
is
adding
this
attestation
making
an
attestation
Associated
commit.
A
So
all
we're
doing
here
is
we're
running,
get
signed
a
test,
we're
giving
it
the
file,
we're
telling
hey
it's
type
spdx,
and
what
this
is
doing
is
it's
actually
storing
the
attestation
in
a
special
ref
space
within
the
repository
itself.
Right
so
just
like
branches
and
tags,
we
can
actually
push
and
pull
these
custom
refs
if
you're
familiar
with
Git
notes.
This
actually
works
in
a
very,
very
similar
mechanism,
but
this
is
sort
of
a
different
carved
out
space.
A
Where
you
know
our
goal
is
to
really
make
this
a
space
for
to
put
attestations
into
attestation
data,
and
so
what
we
can
do
with
this
is
just
push
the
Repository
and
if
we
cut
over
to
the
repo
here
we
just
have
you
know
simple
repo.
We
can
actually
go
fetch
the
attestations.
This
isn't
actually
going
to
do
anything
because
I
already
have
it
cloned
locally.
A
We
can
do
full
get
things
with
it,
so
we
can
actually
check
out
arrest,
attestation's
commits,
and
so
this
is
going
to
dump
us
into
a
folder
that
looks
pretty
gnarly,
but
it's
actually
just
structured
sort
of
format
for
hey
here
are
all
the
commit
Shaws
that
we
have
attestations
for.
So
if
we
do,
if
we
just
get
the
commit
Shaw
for
whatever's,
that
means
so
we
have
this
a4a.
A
So
if
he's
CD
into
a4a,
here's
where
we
see
all
the
prominence
data
and
all
the
attestations
right,
so
each
one
of
these
files-
they're
sort
of
up
here
here,
it's
it's
storing.
What
is
the
prominence
data
that
that
we
added
so
in
the
case
of
the
s-bomb,
this
is
just
an
spdx
s-bomb
and
then
the
corresponding
signature
is
the
signed
data
of
that
s-bomb
that
we
produced
using
this
extra
keyless
flow.
A
So
this
looks
pretty
gnarly
because
it's
a
b64
blob
of
the
the
provenance
data
that
we
had
before
and
we
can
do
this
for
for
the
other
things
as
well,
so
like
for
the
the
review
thing
here.
Let
me
just
pipe
this
into
JQ,
so
it's
a
little
nicer
to
see
so
for
this,
just
for
the
demo
I
just
sort
of
spat
out
the
pull
request
data.
A
So
for
this
pull
request,
you
know
I
I
reviewed
it
I
approved
it
and
we
can
actually
store
this
data
in
in
the
git
repository
itself
only
using
git
protocol.
So
you
don't
need
to
you
can
do
this
in
sort
of
a
git
repo
agnostic
way,
so
it
doesn't
really
matter
if
it's
GitHub
gitlab
anything
like
that
and
then
the
other
thing
is
so.
Here's
a
Nifty
UI
that
we
use
for
just
inspecting
recore
log
entries.
A
So
this
corresponds
to
the
S
bond
that
I
produced
before
so
you
can
see
it
was
issued
by
six
door.
It's
a
short-lived
cert
I
ran
this
three
days
ago
and
what's
really
cool
about
this
is
because
the
cert
was
issued
to
the
oidc
identity
of
my
CIA,
my
GitHub
action
CI.
You
know
we
can
use
the
certificate
in
in
this
attestation
to
say:
hey.
No,
this
came
from
ICI,
it
came
from
like
a
known
Runner.
It
wasn't
just
a
random
developer.
A
That
sort
of
produced
the
status
station
uploaded
it
to
the
repo
things
like
that,
so
that's
sort
of
the
value
that
like
Sig
store,
can
add
to
a
process
like
this.
So
this
is
a
lightning
talk,
so
we
unfortunately
don't
have
that
much
time
to
go
into
the
specifics,
but
yeah
so
I
just
wanted
to
show
this
off.
It's
things
that
we're
working
on.
It's
things
that
we're
actively
thinking
about
you
know
the
things
that
are
on
our
mind
is
Source
attestation
data
like
I,
mentioned
before
right.
A
It's
another
part,
it's
another
piece
of
the
software
supply
chain.
We
want
to
have
attestations
so
things
that
I
would
like
to
hear
from
everyone
from
everyone.
If
you
want
to
grab
me
during
lunch
or
something
is
like
what
kind
of
data
would
you
like
to
see
in
attestations,
you
know
obviously
I
think
there's
a
lot
of
value
in
having
this
data
present
next
to
the
commit
yeah.
So
we
want
to
see
how
we
can
grow.
A
This
I
am
definitely
interested
in
the
like
the
in
Toto
salsa
spec,
for
like
the
two-parter
review
stuff,
like
that,
but
yeah
I
think
it
would
be
really
interesting
to
see
how
we
can
apply
this
for
for
other
things,
yeah.
So
thank
you.
That's
all
I
have
a
really
short
talk
if
you're
interested
in
get
signed,
here's
the
link
for
the
GitHub
repo
and
if
you
want
to
come
and
chat
laughter
more
than
happy
to
so
thank
you.