►
From YouTube: Securing the Software Supply Chain with the in-toto & SPIRE projects - Cole Kennedy & Mikhail Swift
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. 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.
Securing the Software Supply Chain with the in-toto and SPIRE projects - Cole Kennedy & Mikhail Swift BoxBoat Technologies
A software supply chain is the set of steps required to test, build, deploy, and assure a software release. Verification of the build policy through a cryptographically attestable process is required to give software artifact consumers the confidence to install software releases on mission-critical systems. In this talk, we will discuss the current gaps in the open-source eco-systems and demonstrate a cryptographically attestable software pipeline with automated certificate issuance.
A
A
Let
me
start
by
introducing
my
myself
there.
I
am
right
there,
I'm
a
solutions
architect
at
box
boat
technology.
I
also
lead
a
lot
of
our
technical
initiatives,
are
at
box
boat,
dealing
with
the
federal
and
high
compliance
industries,
I'm
a
contributor
to
the
cncf
sig
security
supply
chain
working
group.
Right
now
we
are
working
on
a
supply
chain
security,
white
paper.
Hopefully.
A
A
A
Engineer
with
us
at
box
boat
as
well,
he
he
contributes
with
me
to
that
white
paper
I
talked
about
and
then
he
works
on
the
us
air
force
platform
one.
So
he
helps
bring
some
of
their
mission
partners
on
board.
So
if
you
think,
like
these
large
traditional
slow-moving
defense
integrators
right,
they
need
to
as
the
u.s
air
force
moves
into
a
devsec
ops
environment.
They
need.
B
A
Bring
these
large
so
mikhail's
working
on
a
team
that
is
really
helping
enable
one
of
those
large
integrators
to
to
work
in
that
u.s
air
force
platform.
I'm
really
proud
of
the
work
and
then
I'll
talk
about
a
little
bit
about
boxboat.
We
are
a
professional
services
company
I
like
to
call
say
cloud
native
integrators,
so
we
can
take
your
you
know
your
business
requirements
and
then
we
take
the
cloud
native
landscape
and
come
up
with
a
plan
to
really
accelerate
your
your
devops
journey
and
your
digital
monitor.
A
But
let's
get
to
the
problem
at
hand
right.
There
was
some
stuff
that
happened
this
past
winter
and
it
really
kind
of
shook
the
entire
industry
security
administrators
are
finally
trying
to
figure
out
that
they
have
no
way
to
assess
the
risk
level
of
software
running
on
their
systems.
Right.
It's
a
system
based
upon
trust
and
that's
a
problem
right,
because
a.
A
A
Key
material
and
certain
consistency
if
you've
ever
worked
in
a
large
corporation
and
have
tried
to
do
some
sort
of
request
for
certificates.
You
understand
that
the
process
is
different
everywhere
and
it's
generally
very
streamlined
right.
It's
something
that
that
takes.
You
know
multiple
levels
of
approval.
It
can
take
multiple
days
so.
B
A
A
A
Identity
is
not
just
workload:
identity
right,
most
of
us
understand
identity
as
a
user
identity.
So
we
need
to
have
strong
identity
systems
for
both
users
and
work.
The
next
part
is
policy
right.
So
traditionally,
when
we
talk
about
policy,
we're
talking
about
organizational
policy
right,
what
can
users
do?
What
can
administrators
do?
What
are
our
left
and
right
limbs
generally
in
a
traditional
architecture?
You
have
your
policy,
that's
managed
by
a
change
control
board,
so
you'll
bring
a
change
to
that
change,
control,
board
and
they'll
examine
the
policy
to
know
hey.
A
B
A
Is
we
take
that
policy
and
we
we
enable
it
as
policy
as
code
right,
so
we
have
our
left
and
right
limits
defined
as
some
piece
of
automation.
You
know
open
policy
agent
is
a
great
tool
to
do
this
and
then,
finally,
we
have
control
right.
What
is
actually
taking
these
identity
documents
and
policy
documents
to
make
decisions
in
the
system.
A
A
A
Extremely
important
to
a
testing
of
the
validity
of
of
that
software
that
it
was
built
on
the
machines
you
expected
it
to
be
built
on
it
was
built
by
the
compilers
you
expected
it
to
be
built
on.
There
was
no
man-in-the-middle
attacks
that
that
modified
the
code
in
between
these
different
processes.
A
A
An
this
is
a
piece
of
metadata
that
is
emitted
from
each
step
of
the
build.
So
if
we
take
those
s-bombs
assigned
s-bombs-
and
you
know
put
them
all
together-
we
and
use
it
and
deliver
them
to
the
execution
phase
right.
We
can
actually
use
a
controller
at
the
execution
phase
to
determine
whether
we
trust
that
software
and
that
allows
our
system
administrators
to
examine
that
software,
to
make
sure
that
it
does
meet
that
organizational
policy.
A
A
The
problem
is
that
miner
actually
didn't
release
an
implementation
or
any
implementation
guidance
on
so
at
box.
What
we
kind
of
took
it
upon
ourselves.
You
know
we
we've
been
working
in
supply
chain
and
supply
chain
security,
for
you
know
the
entire
history
of
our
company.
It's
what
we
do
traditionally.
A
Focused
on
delivering
software
faster,
but
as
we
move
into
these
high
compliance
environments,
they
have
new
requirements
right.
They
want
to
actually
be
able
to
trust
that
that
software,
so
we
started
looking
at
the
in
toto
project
and
toto,
is
a
great
project.
It
does
what
we
need
to
do
right.
It
emits
those
s-bombs
that
metadata
that
signed
metadata
for
each
stage
of
the
build.
A
It
allows
us
to
verify
that
by
an
out-of-band
policy
enforcement
they
call
that
a
layout
file
right
so
that,
when
you
put
these
together,
it
allows
you
to
cryptographically
verify
the
build
process.
Wherever
you
are
right.
So
we
can.
We
can
verify
that
build
process
at
the
execution
phase,
not
having
to
rely
on
trust
of
of
that
that
business
process
from
that
vendor
that
so.
A
A
A
B
A
Those
requirements,
each
functionary,
which
could
also
be
it
could
be
a
person
or
an
actual
build
step,
does
require
a
private
key
to
sign
that
metadata,
which
kind
of
causes
some
issues
when
we
bring
this
into
an
enterprise
environment
so
enter
spiffy
spire,
you
know
we're
not
gonna,
do
a
real
big,
deep
dive
into
what
spiffy
spire
is
and
how
it
works.
There's
a
lot
of
really
really
great
talks
on
that
and
a
great
active
community,
but
spiffy
is
the
spire
is
the
implementation
of
the
spiffy
apis.
It's
a
reference.
A
Implementation
is
what
we
used
in
this
project
here
and
spire
allows
us
to
issue
identities
in
the
form
of
x509
certificates,
to
workloads
based
upon
their
immutable,
attribute
container
hash.
What
user
there's
there's
a
lot
of
different
selectors
that
we
can
pick
on,
including
you
know
what
machine
that
they're
being
built
on
in
one
of
our
engagement,
we're
actually
able
to
tie
issuing
these
identities
down
to
a
the
public
hash
of
that
tpm
key
on
that
machine
right,
so
we
can
cryptographically
prove
that
builds
happen
on
a
specific
machine.
A
All
right-
and
so
this
allows
us
to
register
these
functionaries
through
the
spire
registration
and
once
we've
registered
these
these
functionaries
to
the
spire
registration
api.
Those
functionaries
are
issued,
the
keys
that
we
specify
and
then
they
can
sign
that
metadata
and
the
whole
process
becomes
automated.
A
It
allows
us
to
create
an
automated
architecture
that
that
implements
that
reference
design
that
that
we
talked
about
earlier
that
might
have
released
that
deliver.
Uncompromised
paper
allows
us
to
tell
allows
us
to
attest
for
the
workload
identity
right.
What
who
built
the
software
and
where
it
was
built
and
allows
us
to
pass
that
information
downstream
to
consumers
of
the
software.
So
they
can.
B
B
And
we
can
see
this
reflected
in
our
in
total
layout.
The
layout
is
what's
going
to
tell
in
toto
what
each
step
should
do
who's
allowed
to
do
that
step
as
a
functionary
and
then
what
materials
and
what
products
are
expected
for
each
step.
So
everything
here
has
to
match
what
happens
in
our
pipeline.
B
For
example,
if
our
command
doesn't
match
and
toto
will
throw
warnings,
it
won't
outright
fail
because
sometimes
commands
not
matching
as
expected.
There
are
some
things
you
may
your
variables.
That
may
vary
that
you
just
won't
know
ahead
of
time,
but
everything
else,
such
as
our
materials,
will
fail
and
cause
a
hard
failure
on
verification.
B
So,
for
example,
in
our
in
our
clone
stage,
we
are
saying
we
don't
need
any
materials.
We
should
not
have
any
materials
because
we're
cloning
we're
going
to
create
everything
in
our
folder
saying
that
we
basically
clear
it
created
the
world
when
we
clone,
then,
as
part
of
our
build
stage,
we're
going
to
say
our
build
command
should
be
go
build
and
then
our
expected
materials
must
match
our
products
from
our
clone
state.
B
And
then
the
final
part
of
the
in
total
stage
is
the
inspection
and
verification,
so
by
default
in
total,
we'll
look
at
every
single
metadata
prevented
by
each
of
these
steps
and
it'll
make
sure
that
the
materials
and
products
match
your
defined
rules.
You
can
also
define
this
inspection
stage,
which
may
do
extra
stuff
that
you
define
in
our
case.
In
our
previous
build
image
stage.
B
We
tarred
up
our
file,
our
docker
image
and
now
we're
going
to
say
that
this
docker
image
bar
that
we
have
now
must
match
the
one
that
was
created
from
the
build
image
stage.
So
if
someone
were
to
download
a
target
copy
of
our
image,
they'd
be
able
to
verify
with
the
signed
metadata
that
the
image
they
have
was
the
same
one
that
we
created
as
part
of
our
build
process.
B
The
final
part
that
we
added
is
this
root
case
by
d
are
currently
today.
Entoto
allows
you
to
sign
metadata
and
verify
functionaries
with
dpg
and
public
private
key
pairs
that
are
embedded
in
this
layout
with
our
integration
with
spiffy.
We
wanted
to
make
sure
that
we
could
sign
metadata
with
any
key
and
certificate
pair
belonging
to
a
trusted
root.
B
This
is
saying
that
certain
attributes
of
our
certificate
must
match
these
things.
So,
for
example,
the
clone
any
common
name
is
okay.
We
want
this
specific
uri
in
our
certificate,
and
this
is
a
spiffy
id
that
will
be
in
any
key
made
by
our
fifi
agent
and
provided
to
our
builders
the
show
how,
when
toto,
can
catch
unexpected
things
from
happening
in
your
build
process,
you
can
take
a
look
at
this
merge
request.
I've
opened,
and
here
I'm
just
adding
a
line
after
our
main
function.
B
B
If
I
take
a
look
at
our
build
property
volume
for
this
merge
request,
I
see
it's
failing
image
verification
if
we
take
a
look
as
to
why
it's
in
failing
the
inspection
step
for
artifact
verification
failed
for
step,
build
materials
may
not
go
were
disallowed
by
the
rule
disallow
star
as
part
of
our
rules
for
verification.
For
our
build
stage,
we
said
that
everything
used
as
materials
had
to
match
the
products
from
our
clone.
B
When
you
start
to
combine
in
toto
with
things
such
as
reproducible
builds
and
distributed
builds,
it
really
gives
you
a
strong
idea
of
maybe
when
a
build
environment
has
just
diverged
and
is
producing
different,
builds,
or
maybe
something
malicious
is
going
on
in
that
build
environment,
and
you
need
to
dig
in
deeper
if
you
want
to
play
with
our
code.
We've
published
it
here
on
github
on
the
box
vote
and
toto
golang
repo.