►
From YouTube: Completely Securing the Software Supply Chain using Grafeas + in-toto - Lukas Puehringer
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18)
Completely Securing the Software Supply Chain using Grafeas + in-toto - Lukas Puehringer, NYU & Wendy Dembowski, Google (Any Skill Level)
Continuous delivery, a prevalent concept in the cloud-native ecosystem, has drastically simplified and accelerated development and deployment of software from its inception to the end-user. Unfortunately, the continuous delivery supply chain has become an attractive target for attacks. An attacker that compromises any of the steps of the supply chain, or alters the product in transit, can target all users at once. In this talk Wendy Dembowski and Lukas Puehringer will introduce in-toto and grafeas(grafeas.io), a software supply chain security ecosystem to verify the supply chain integrity, authenticity, and compliance of any application. The talk will feature real-life examples, such as the target deployments for various popular projects, including Debian, Arch Linux, reproducible builds, and Docker.
About Wendy
Wendy is a Staff Software Engineer at Google. She is a co-founder and the Khaleesi of Grafeas.
About Lukas
Lukas Puehringer is a research scholar and developer at NYU's Center for Cyber Security (CCS), where he leads, the development of in-toto and has been co-maintaining several of Prof. Justin Cappos' software projects, such as the Seattle and Sensibility Network Testbeds and The Update Framework (TUF). Lukas presented in-toto and TUF at DebConf2017.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 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.
Join us for KubeCon + CloudNativeCon in San Diego November 18 - 21. Learn more at https://bit.ly/2XTN3ho. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
My
name
is
Wendy
I'm
from
Google,
and
this
is
Lukas
from
NYU
and
we're
going
to
be
talking
to
you
about
securing
your
software
supply
chain
using
graphics
and
in
toto
so
graph
is,
is
a
artifact
meditated
storage
system
and
it
also
stores
signatures
for
your
Cloud
artifacts
and
in
todo
provides
a
framework.
I'm
sorry
is
a
framework
that
provides
integrity
and
authenticity
of
steps
performed
to
make
software
so
start
us
out.
Lucas
is
going
to
give
us
an
overview
of
in
todo
and
a
little
bit
more
detail
than
this.
B
Hello,
everyone
so
before
I'm
gonna
talk
about
in
todo,
I'm
gonna
talk
about
how
software
is
actually
made.
So
typically,
you
have
a
series
of
steps
start
by
writing
code
and
check
your
checking
in
checking
it
into
your
version
control
system,
something
like
it
and
then
you
take
the
sources
and
build
them.
There
are
various
build
tools
depending
on
what
code
you
are
developing.
Ideally,
you
have
some
quality
assurance.
You
use
the
CI
CD
system
and
run
tests
there
and
eventually,
before
you
ship
it
to
your
user
or
you
deploy
it
in
your
container
cluster.
B
You
have
to
package
it
in
a
write
format
or
containerize
it.
So
what
can
go
wrong
in
there?
There
are
a
lot
of
things
that
can
go
wrong.
Each
of
those
steps
in
their
software
supply
chain
can
be
compromised
and
also
the
software
in
transit
can
be
compromised
and
in
the
software
supply
chain
is
a
very
attractive
target
for
attackers,
because
by
compromising
asila,
a
single
developers,
machine
or
building
machine
attackers
can
target
millions
of
end-users.
They
can
introduce
Melissa
malicious
code,
such
as
backdoors,
etc,
and
these
things
have
happened
repeatedly.
B
You've,
probably
all
have
seen
high-profile
in
disclosures
of
text
in
the
software
supply
chain.
So
how
can
we
fix
this?
There
is
already
a
bunch
of.
We
are
very
good
point
solutions.
For
instance,
in
the
version
control
step,
where
you
develop
your
code,
you
can
sign
all
of
your
commits
using
git
commit
signing.
He
can
take
you
to
step
further
and
use
something.
That's
called
the
reference
state
log.
B
That's
a
system,
that's
also,
or
an
extension
of
git,
that's
also
developed
by
the
in
toto
team
and
adds
additional
security
guarantees
about
authenticity
of
git
commits
on
your.
Oh
sorry,
on
your
build
machine.
You
can
use
Trust
trusted
platform
module,
he
can
use
HSN.
You
can
also
use.
Reproducible
builds
something
that's
coming
more
and
more
to
make
sure
that
your
binary
is
the
same
on
every
machine
and
therefore
have
guarantees
that
can
add
additional
guarantees
to
your
your
build
software,
and
when
you
ship
out
your
software,
you
can
use
transport
transport
layer
security.
B
You
can
also
use
GPT
to
sign
your
binaries.
Are
your
final
software
product
and
in
the
container
world
there
are
things
like
content,
trust
or
in
in
docker?
There
is
notary,
I
think
we're
gonna
hear
about
that
later
and
this
week.
So
it's
the
software
secures
the
software
supply
chain
fixed
well,
partially,
there
are
still
the
gaps
between
the
steps.
So,
even
if
you
sign
all
your
commits,
you
don't
really
have
a
an
overarching
definition
of
who's
authorized.
You
need
something
like
a
PGI.
B
If
you
have
reproducible
builds,
you
trust
on
the
fact
that
the
code
that
goes
into
your
build
machines
is
saying,
and
so
there
are
still
several
problems,
even
if
you
use
all
of
those
point
solutions
and
that's
why
we
have
developed
in
toto-
and
these
are
the
things
that
we
want
to
accomplish.
We
want
to
make
sure
that
or
we
want
to
be
able
to
verifiably
define
all
the
steps
in
the
software
supply
chain.
B
We
want
to
verify.
We
define
who's
authorized
to
perform
each
of
the
individual
steps
and
we
want
to
guarantee
that
everything
happened
according
to
that
project
definition
and
nothing
else
in
toto
provides
two
types
of
metadata:
the
most
crucial
order.
The
first
part
of
metadata
that
you're
gonna
define
is
something
that
we
call
a
layout.
It's
the
project
definition.
B
You
put
all
of
those
into
the
layout
and
then
you
say
who's
allowed
to
perform
those
steps
we
use
cryptographic
keys,
so
you
define
the
public
portion
of
the
key
of
a
developer
or
a
builder,
or
it
also
can
be
a
machine,
and
you
add
it
to
the
step
in
the
layout,
and
then
you
define
the
artifacts
of
each
step.
You
say
what
should
come
out
of
a
given
step.
We
call
that
product
and
what
should
go
in
into
probably
a
subsequent
step,
which
we
call
material.
B
And
finally,
we
have
a
little
rule
language
where
we
say:
okay,
this
product,
that
came
out
of
this-
let's
say
the
versioning
step-
should
be
the
material
for
the
building
step
and
in
order
to
be
able
to
okay,
one
thing
that
I
forgot,
you
have
a
root
of
trust.
You
sign
this
piece
of
layout
piece
of
metadata
by
your
master
key.
B
The
project
owners
key
can
also
be
several
keys
to
have
a
threshold
and
that's
shipped
out
alongside
your
software
and
in
order
to
have
evidence
that
all
of
those
steps
were
carried
out
according
to
the
definition
you
have
all
of
your
developers,
your
builders,
we
call
those
people,
functionaries
or
those
entities.
You
have
them,
provide
a
or
create
also
a
piece
of
metadata,
which
we
call
link
metadata.
That
lists
all
the
artifacts
that
were
used
or
created
by
a
given
step,
and
this
piece
of
metadata
is
signed
by
the
private
page.
B
A
portion
of
the
of
the
cryptographic
key
of
the
functionary
and
the
links
together
with
the
layout
are
shipped
out
with
the
final
product,
and
then
we
have
in
total
verification
routine.
That
verifies
all
of
the
links
against
layout
using
the
final,
the
final
software
product
that
you
want
to
deploy
or
ship
out.
A
Now
we've
just
talked
about
a
lot
of
metadata.
A
secure
software
supply
chain
produces
a
lot
of
metadata,
and
so
what
do
we
do
with
that
metadata?
This
is
the
motivation
behind
graffia
swear
at
each
step.
We
have
at
each
step
of
your
CI
CD
process.
You
can
push
stuff
into
a
structured
API
that
is
common
across
wherever
you're
getting
the
metadata
from.
A
So,
if
you
have
multiple
builders,
your
build
provenance
would
look
the
same
for
both
of
them
and
you
can
use
that
data,
then
in
a
reliable
way,
without
worrying
about
translating
from
one
format
to
another,
and
so
we
have
build
tests,
you
see
in
the
middle,
we
have
scanners,
so
you
can
have
a
license
scanner,
a
vulnerability
scanner,
putting
metadata
into
graph.
Yes,
and
this
will
help
you
decide
whether
the
thing
that
you're
building
is
safe
to
deploy.
A
So,
to
give
a
little
more
context
in
the
graphics
API
we
have
to
resource
types,
one
is
called
notes
and
these
are
sort
of
the
thing
that
exists
in
a
content
context
insensitive
way.
So
if
you
think
in
the
case
of
vulnerabilities,
this
might
be
a
CBE
that
just
exists
and
information
about
where,
where
could
be
found
which
packages
are
affected,
and
then
we
have
occurrences
that
are
actually
referencing
places
in
your
artifact.
A
So
in
your
container,
which
package
contains
this
vulnerability
and
the
occurrences
always
reference
a
note
so
to
have
an
occurrence,
you
must
have
a
note
and
the
we
do
a
bit
of
name
spacing
for
these,
so
you
can
have
your
notes
and
occurrences
live
in
different
projects.
So
you
can
see
on
the
on
your
right.
A
A
Discovery?
Let's,
if
you
have
someone
doing
some
sort
of
scanning
for
you,
it
gives
them
a
new
way
to
indicate
whether
your
artifact
has
been
scanned,
because
you
might
have
a
difficult
time
telling
the
difference
between
no
vulnerabilities
in
this
thing
or
not
yet
scanned
builds.
You
can
learn
what
your
what
source
your
project
was
built
from
who
built
it.
What
was
the
version
of
the
Builder
and
really
makes
sure
that
people
aren't
just
pushing
stuff
from
their
dev
boxes?
A
That
you're
following
your
build
process,
and
then
image
is
specific
to
containers
and
it
gives
information
about
what
the
base
image
for
this
container
was
along
with
what
layers
got
built
on
top
of
that
attestations
are
sort
of
a
very
strong
piece
of
the
graph
use
API.
This
allows
you
to
sign
off
on
things.
So,
even
if
we
don't
have
a
schema
for
a
specific
type
of
metadata
like
QA
to
sign
off
your
QA
team
can
create
an
attestation
saying.
A
Yes,
we
think
this
is
good
to
go
and
verify
it,
and
you
can
do
the
same
thing
with
your
build
information.
If
the
build,
if
this
thing
was
built
in
a
way
that
you
were
okay
with
deploying,
then
you
create
the
attestation,
you
can
create
a
vulnerability
policy
and
say
yes,
this
thing
is
clear
of
the
vulnerabilities
that
I
don't
want
to
deploy
so
create
an
attestation
saying
that
and
then
finally
deployment
lets
you
track
what
was
deployed
where
it
was
deployed
and
by
whom-
and
the
helpful
thing
here
is.
A
So
the
way
we,
the
the
collaboration
between
graffia
stand
in
toto
has
the
expectation
that
we
would
query
the
data
from
graffia
s--.
That
would
and
translate
it
to
the
in
toto
metadata
layout,
which
is
a
little
bit
more
generic
than
graph
face
and
then
run
in
toto
verification
using
graffiti
metadata
and
then
having
Toto
push
an
attestation
into
the
graph
phase.
Server.
B
Thanks
yeah,
so,
as
Wendy
has
pointed
out,
it
seems
natural
to
kind
of
marry.
These
two
projects
courteous
provides
a
very
well-defined
API
where
you
can
storm
or
push
metadata
to
incur
it
from,
and
it
is
well
integrated
in
the
cloud
ecosystem
and
in
toto
really
works
the
individual
steps
of
the
supply
chain
and
it's
economic
to
the
step.
So
it
can
be
used
for
anything
that
you
have
in
your
supply
chain.
So
we
have
a
little
diagram
here
that
basically
explains
what
Wendy
already
said
or
visualize
it.
What
visualizes?
What
Wendy
just
said?
B
B
Yeah
I'd
also
like
to
mention
Santiago
Torres
who's,
the
brain
behind
in
toto
and
unfortunate,
and
fortunately
couldn't
make
it
here,
and
also
just
in
kappas,
professor
at
NYU
and
supervisor
of
the
in
total
project
he's
here
in
the
room.
So
if
you
see
him
his
that
guy,
you
can
should
questions
at
him.
I'll
be
around
if
you're
interested
in
toto.
There
is
a
bunch
of
demos
available
also
about
the
littles
of
supply
chain
that
I
showed,
or
we
showed
in
our
slides
for
kasam
github.
Send
us
emails,
contribute
yeah.
B
A
Also
have
if
you're
interested
in
getting
involved
in
the
graphics
community
we
have
every
other
week.
A
community
call
you'll
see
all
these
happy
faces
there.
These
are
the
Google
team
members
and
then
you
can
join
our
mailing
list
and
Kelsey
Hightower
wrote
a
demo
last
fall
using
the
admission
controller
to
Block
deployments
based
on
attestations.
So
if
you
want
to
take
a
look
at
that,
how
that
would
work,
you
can
look
there
and
I'll
also
give
a
plug
that
we're
holding
a
gracias
meetup
this
afternoon.
A
B
A
A
C
Proving
our
supply
chain,
so
we
were
actually
looking
at
building
something
like
graph,
yes
for
ourselves,
but
then
last
fall.
It
was
crappy
as
was
announced,
so
we
have
contributed
some
some
of
the
stuff
that
is
needed
to
make
this
work
in
production
like
Postgres
database
back-end,
for
example.
So
we
are
in
a
like
a
prototype
phase,
but
we
are
running
graph,
yes
in
our
organization,
but
also
you
use
graph,
yes
in
Google.
So
that's.
A
B
Yeah,
okay,
so
I
think
you
also
asked
about
in
toto
or
yeah.
Well,
we
have
the
reference
implementation,
which
is
fully
functional
and
tested
and
released
as
open
source
code,
and
we
are
working
together
with
operating
system
communities.
We
were
working
with
Debian
we're
trying
to
make
their
or
we're
in
the
process
of
making
their
rep
reducers
produce
or
generate
link
metadata.
B
We
are
having
in
toto
right
now
integrated
in
a
company.
That's
also
somewhere
out.
There
I
think
we
are
talking
with
Arch
Linux,
open,
Susie
yeah.
We
are
trying
to
have
their
package
managers
their
system
package.
Many
managers
perform
in
total
verification
on
system
packages
that
are
installed,
so
we
yeah
we're
going
in
various
directions
where
we're
trying
to
tell
people
that
is.
This
is
something
that
can
be
used
and
should
be
used
and
we're
excited
about
having
more
people
on
board
to
to
use.
It
I
think
there
was
a
question
over
there.
A
Developed
internally,
so
there's
no
code
that
has
been
created
yet.
However,
the
a
lot
of
what
criticized
is
the
work
in
the
admission
controller,
and
so
this
is
stuff,
that's
very
easy
to
do.
Following
following
Kelsey's
example,
I
think
the
more
difficult
part
comes
around
the
policy
language
and
like
how
to
ask
for
those
attestation.
So
there's
there's
work
going
on
on
that,
just
not
open
yet,
unfortunately,.
C
C
B
B
The
the
root
of
trust
is
basically
a
a
key.
That's
used
to
sign
one
lay
out
it's
a
root
of
trust
within
the
in
toto
verification,
so
this
key
that
signs
layout
is
used
to
trust
all
the
keys
that
provide
or
that
sign,
link
metadata
for
individual
steps.
It
doesn't
have
to
be
so
that
means
that
there,
that
in
in
toto,
is
a
sort
of
public
key
infrastructure.
B
So
all
the
keys
that
are
trusted
for
a
given
step
of
the
supply
chain
are
shipped
out
with
the
layout,
so
you
don't
have
to
handle
anything
extra
with
GPG
key
rings
on
your
system
or
whatever
what
happen
was
also,
what
happens
if
the
those
keys
need
to
be
rotated?
That's
something
that
is
not
really
handled
by
in
toto.
B
B
So
Cheston
was
saying
that
in
total
makes
it
possible
to
rotate
the
keys
for
like
not
the
root
keys,
but
the
keys
that
are
in
the
layout.
But
if
you
want
to
rotate
the
root
of
trust
which
signs
the
layout,
you
would
need
something
like
the
update
framework
that
integrates
well
with
in
todo
more
questions.