►
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.
Uncovering the History of Your Software Artifacts - Mikhail Swift, TestifySec
Discovering who, how, and where a software artifact was created is a daunting task. Archivist is an open source In-Toto attestation index and store, allowing you to uncover the history and establish trust of a software artifact. Archivist allows you to discover the attestations you need to satisfy your in-toto policies and ensure only trusted artifacts make it to production. In this talk we’ll use Witness (an In-Toto implementation) to create attestations about a build process of an attestation and store them in Archivist. Then we will create a Witness policy and enforce it while querying Archivist to discover relevant attestations to satisfy the policy.
A
Thank
you
so,
as
mentioned,
my
name
is
Michael
Swift
I'm,
going
to
talk
a
little
bit
about
supply
chain
security,
which
change
of
pace
of
the
past
few
talks.
It's
me,
I'm,
co-founder
and
CTO
of
testify.
Sec
I've
contributed
a
little
bit
to
the
cncf
software
supply
chain,
best
practice
paper
in
Toto
and
I
really
love
open
source
software.
So
a
lot
of
what
I'm
seeing
today
is,
you
know,
really
really
cool
and
speaks
to
me.
So
I
guess
talking
about
software
supply
chain
security
is
a
really
complex.
Many
problem,
many
faceted
issue
right.
A
We
have
a
lot
of
problems
to
solve
all
at
once
and
a
very
little
amount
of
time
to
do
it
and
kind
of
a
high
level
overview
of
some
of
the
problems
that
we
see,
obviously,
or
how
do
I
know
what
happened
with
this
build?
Where
was
it
built?
You
know
who
triggered
a
build
where
who
committed
to
it
and
how
do
I
prove
that
when
I'm
using
it
or
when
I
want
to
use
this
piece
of
software
next
problem,
big
problem
that
we
have
is,
how
do
I
know
if
I
can
trust
who's?
A
Giving
me
this
information,
so
the
signature
on
it,
where
did
it
come
from?
Who
is
it
and
and
how
do
I
know
that
signature
was
actually
from
them
and
the
problem
that
I'm
kind
of
going
to
really
focus
on
for
this
talk
is
how
do
I
discover
this
information?
How
do
I
actually
get
it
to
use
it
when
I'm
wanting
to
evaluate
policies.
A
So,
as
far
as
like,
actually
generating
this
data
and
annotations
go,
we
have
a
bunch
of
really
awesome
work
happening
in
the
open
source.
We
have
tecton
chains,
the
middle
one's,
a
new
logo,
it's
witness
it's
the
project
that
I
primarily
work
on.
We
have
salsa
providences,
and
this
also
gives
us
you
know
a
bunch
of
awesome
Frameworks
on
how
to
make
decisions
and
really
assess
the
risk
assessment
of
a
artifact.
A
Given
the
information
that
you
have,
but
the
one
thing
that
all
three
of
these
and
I'm
sure
many
more
projects
that
I
did
not
include
here
have
in
common,
is
they
speak
the
in
Toto
language
they
use
in
Toto
statements
they
create
in
Toto
subjects
and
kind
of
wrap
them
up
in
a
Toto
attestations
for
the
trust
problem.
We've
seen,
you
know,
six
door
come
out
with
keyless
signing
really
the
recore
transparency
log.
A
Does
it
give
kind
of
a
non-repudiation
about
the
the
stuff
being
signed,
spiffy
Spire
for
workload,
identities
establishing
trust
there,
but
what
I
feel
we
kind
of
have
a
gap
in
right.
Now
is
the
actual
Discovery
and
usage
of
this
information.
We
have
policy
engines.
We
have
all
this
to
actually
make
the
decisions,
but
we're
somewhat
lacking
a
way
really
to
find
it
and
kind
of
query
and
use
it
so
Ponder
a
situation
where
we
have
a
large
CI
pipeline.
A
A
lot
of
these
things
might
happen
prior
to
an
artifact's
creation
and
trying
to
link
that
back
to
the
things
that
have
happened
before
isn't
always
the
easiest
thing
to
do
so.
That's
kind
of
one
of
the
problems
I
keep
encountering
when
we're
working
on
witness
and
policy
enforcement
is
how
do
I
find
the
code
review
attestation
to
prove
that
you
know
Alice
approved
me
to
put
this
in
production.
A
So
if
we
can
find
the
attestation
from
when
the
product
was
created,
maybe
we
can
use
context
clues
from
those
attestations
to
find
the
other
more
relevant
ones,
and
when
we
start
looking
at
this,
it
kind
of
starts
resembling
a
graph
I
have
the
attestation
for
when
the
product
was
built.
That
gives
me
the
commit
it
was
built
from.
A
A
Maybe
that
attestation
might
contain
things
like
the
commit
ID
to
get
us
back
to
that
code.
Annassation
one
get
lab
project
ID
if
it
were
built
on
gitlab
to
get
us
to
maybe
some
deployment
info
that
didn't
show
up
for
us
at
first
or
maybe,
who
made
the
commit.
So
we
can
start
getting
back
to
the
provenance
of
the
developer
themselves.
A
A
It
exposes
a
graphql
API,
so
users
of
this
can
query
it
find
things
and
kind
of
refine
their
queries
over
time
to
find
more
and
more
relevant
attestations.
It
pulls
out
specific
things
like
what
attestations
were
in
that
in
Totowa
station.
The
signature
is
on
it,
so
we
can
look
at
the
signatures
before
pulling
the
attestation
and
what
other
subjects
existed
on
that
in
Toto
at
a
station.
A
So
we
can
then
use
those
to
kind
of
expand
our
Graph
Search,
so
it
uses
in
total
subjects
as
graph
edges
if
you're
familiar
within
Toto
attestations
what
they
all
have
a
statement.
Some
subjects
that
describe
what
the
statement
is
describing
and
then
the
statement
itself,
which
is
at
this
point
kind
of
a
arbitrary
amount
of
data
that
could
be
a
salsa
provenance.
It
could
be
anyone
else
who
takes
some
of
these
in
total
attestations
and
implements
them
so
I
have
a
few
demos.
A
So
I
have
a
simple
main
program:
all
it
does
is
print
hello,
security
con
to
the
console
and
I
have
some
commits
about
it
or
I.
Have
these
commits
here
and
what
I
do?
What
I'm
going
to
do
is
I'm,
going
to
create
a
witness
policy
which
is
describing
what
I
expect
should
have
happened
when
I
get
this
binary.
A
I
expect
a
step
name
build
to
happen.
That
should
have
some
materials
which
is
describe
all
the
files
that
were
used
during
the
build
process.
It
should
have
run
a
command
and
it
has
an
embedded
Rigo
policy
here
that
will
let
us
enforce
things
about
that
command.
I'll
show
that
here
in
just
a
second,
and
it
should
also
have
some
annotations
about
a
product
which
will
be
the
binary
that
was
created
during
that
build
and
the
functionaries
describe.
A
A
A
A
A
Okay,
so
now
we
use
that
policy
that
we
created
in
that
first
step
to
evaluate
this.
Just
this
binary
that
we
have
and
what
witness
did
in
this
case
was
go
to
archivist
with
the
hash
of
that
file,
that
binary
and
and
kind
of
interrogate
it
to
figure
out
what
evidence
do
we
have
about
this
build
process,
so
it
found
the
two
different
annotation
envelopes
we
had
generated
prior
and
said
this
is
what
I
use
as
evidence
to
say.
This
artifact
is
all
good
to
run,
and
so
it
kind
of
to
show.
A
What
this
looks
like,
maybe
a
little
bit
is:
we
have
just
a
playground
right
now
to
kind
of
query
into
and
show
what
the
data
in
archivist
looks
like.
So
we
have
this
hash,
which
is
a
hash
of
a
different
product.
I
had
created
earlier
I'm,
going
to
try
to
find
out
of
stations
about
it,
and
what
we
find
here
is
we
have
one
attestation,
this
getoid,
we
say
it
built.
It
has
a
few
different
things
in
it,
and
the
subjects
include.
A
A
And
it
kind
of
shows
the
relationships
between
these
attestations
and
what
we're
looking
at.
We
have.
You
know
some
information
about
three
different
builds
that
happened
on
this
commit.
Maybe
we
have
the
commit
attestation
itself,
so,
whoever
committed
that
would
have
recorded
some
attestations
about
themselves.
We
have
dependencies
which
records
the
obviously
the
dependencies
of
the
project
and
kind
of
will
allow
us
to
make
NSA
or
policy
decisions
about
that
later.
A
So
kind
of
where
we
want
archivists
to
go
and
what
we
really
Envision
for
is
we
want
to
Archive
more
data
right
now,
we're
really
focusing
on
a
total
attestation,
but
something
we
see
frequently
is
if
I
have
an
s-bomb
or
if
I
know
of
a
cve.
How
do
I
find
things
that
are
relevant
to
that
cve?
If
archivists
can
archive
index
these
s-bombs,
it
should
make
finding
those
things
later
trivial.
This
is
a
graphql
query.
A
We
can
run
on
the
database
and
we
can
find
everything
we
know
about
that's
affected
and
obviously
improving
the
user
experience
right
now.
It's
obviously
early
in
development,
where
we
just
have
playgrounds
and
demos,
but
it's
going
to
be
important
to
kind
of
get
this
right
for
us
going
forward
and
I
kind
of
ran
a
little
fast
but
I
had
if
there's
any
questions
otherwise
get
archivist
is
available
on
our
GitHub
publicly
and
anyone's
free
to
pull
it
down
play
with
it,
break
it
and
tell
us
about
it.
A
A
Yeah
so
link
right
now
we're
not
currently
recording
it.
I
mean
we
archivists
can
adjust
them,
but
it's
not
going
to
get
kind
of
the
more
Rich
data
around
it.
Yet
and
Toto
is
moving
toward
their
kind
of
generic
attestation
format
with
ite.
Was
it
five
or
six
I
think
so?
That's
where
we
chose
to
focus
on
for
right
now,
but
the
link
stuff
will
definitely
still
be
relevant
and
we'll
we'll
definitely
be
looking
at
bringing
that
into
archivists.