►
From YouTube: Understanding, maintaining and securing Envoy's supply chain - Michael Payne, Harvey Tuch
Description
Understanding, maintaining and securing Envoy's supply chain - Michael Payne, Harvey Tuch
Envoy depends on over 60 external dependencies for its data and control plane functionality, as well as for its build, test and features such as observability. This talk will provide an overview of the third party dependencies that constitute the Envoy software supply chain. We will enumerate, categorize and describe the key dependencies, with a focus on security and how they relate to the Envoy threat model. The talk will cover how Envoy’s dependencies have been maintained, versioned and tested, how the Envoy community plans to evolve and increase confidence in the supply chain, as well as how organizations can apply strategies to minimize unnecessary dependencies.
A
A
There
is
a
very
real
attacks
that
have
been
staged
in
open
source
against
the
software
supply
chain,
in
particular
in
the
managed
language
runtime,
such
as
python,
ruby
and
javascript,
but
there
have
also
been
attacks
such
as
xcode
ghost,
which
attack
developer
infrastructure
and
those
aspects
the
supply
chain.
These
are
very
real
attacks
which
exist,
and
it
helps
us
to
sort
of
understand
better.
What
is
onboard
exposure
to
these,
and
what
can
we
do
about
them
in
open
source
and
what
can
you,
as
an
organization,
do
to
limit
your
exposure
to
the
supply
chain?
A
As
a
starting
point,
we
can
look
at
envoy's
code
base
itself,
the
direct
code
that
you
depend
upon
from
envoy,
and
this
is
now
around
170
000
lines
of
mostly
c
plus
plus
code.
It's
grown
roughly
linearly
since
the
beginning
of
2018.
It's
actually
super
linear.
If
you
look
a
bit
further
back,
but
this
is
the
current
trends
and
we
can
actually
break
that
down
and
do
it
between
onwards,
core
and
blue
and
extensions
in
beige,
and
you
can
see
roughly
right
now.
A
It's
about
50,
50,
split
between
the
two
and
the
extension
mechanism,
which
was
introduced
back
at
the
beginning
of
2018,
is
actually
very
effective
at
helping
to
tamper.
The
growth
in
envoy's
code
base,
at
least
the
mandatory
code
that
you
must
include
in
your
binary,
but
it's
that
the
call
that
still
continues
to
grow.
A
Okay,
so
looking
at
the
same
time
period.
But
instead
of
looking
at
onboard
source
code,
we
look
at
the
number
of
dependencies
that
homeboy
directly
relies
upon
and
we're
just
looking
at
like
one
set
of
dependencies
here,
which
are
the
ones
that
are
linked
directly
into
the
binary
and
feature
in
the
data
and
control
plane.
They've
grown
from
roughly
around
20
or
so
dependencies
till
today,
where
it's
roughly
60
again
roughly
linear
growth.
A
And
if
we
slice
this
data
and
look
at
it
in
terms
of
extension
and
core
and
other
like
components
like
things,
extensions
that
are
dependencies
that
are
there
for
builds
and
tests,
and
apis,
it's
roughly
a
third
or
third
or
third.
A
third
for
call
envoy.
Third
for
extensions
in
envoy
for
the
actual
binary
and
a
third
sort
of
of
the
remainder
and
even
core
dependencies
in
envoy
have
grown
from
roughly
10
to
20.
A
Today
and
the
sheer
number
of
extensions
of
over
60
means
you're
in
a
situation
where
it's
very
hard
to
keep
in
your
head
exactly
what
envoys,
depending
upon
at
any
point
in
time
and
we've
introduced
some
metadata
to
help
with
this,
which
I'll
talk
about
later
well
for
the
next
few
slides
we're
going
to
look
at
envoy's
dependencies
through
a
different
visualization.
This
is
that
of
a
tree
map,
and
this
tree
map
depicts
the
square.
A
The
rectangles
are
sized,
based
on
the
number
of
lines
that
each
component
in
envoy
contributes
to
the
binary
as
determined
by
the
debug
lines
which
exist
in
the
onboard
binary.
So
it's
somewhat
of
an
over
approximation,
but
it's
the
actual,
the
most
direct
way
to
map
back
from
an
on
void,
binary
artifact
to
the
underlying
dependencies
in
home
voice
source
code.
So
we'll
we'll
go
with
that.
A
It's
it
provides
a
reasonable
first
approximation
of
the
relative
size
of
each
of
these
dependencies
amongst
themselves
and
between
them
and
envoy,
and
there's
some
interesting
things
to
note
from
this
visualization
to
begin
with
in
pink
envoys,
you
know
flagship
color.
We
have
all
the
envoy
directs
contributions
to
the
tcb,
which
is
about
20
to
25,
and
the
rest
is
actually
external
dependencies,
and
these
are
there
for
various
reasons.
We
have
boring
ssl
for
our
transport
security.
We
have
quiche
http,
ang,
http,
2
and
http
parser
for
our
codex.
A
We
can
look
at
this
data
through
a
different
lens
and
ask
which
are
essential
and
which
we
can
optionalize
and
compile
out
in
blue.
We
have
the
core
components
which
sort
of
dominates
the
the
the
view
and
we
have
embedded
the
optional
components.
The
extensions
and
you
can
you
know
by
removing
these
significantly
reduce
the
size
of
the
tcp
to
envoy
by
maybe
20
25,
but
most
of
these
dependencies
are
actually
there
to
stay.
A
A
A
We
can
now
look
at,
like
the
number
of
actual
version,
tagged
releases
on
github
for
these
different
dependencies,
and
this
breaks
a
very
different
picture,
because
many
of
our
dependencies
actually
have
no
version
releases,
which
is
kind
of
actually
scary
in
say
in
many
ways,
because
things
like
boring,
ssl
or
quiche,
or
something
like
tc
lab
or
this
kind
of
thing.
It's
kind
of
like
a
little.
A
Concerning
that,
we
don't
actually
have
a
way
to
know
when
we
should
be
updating
and
when
you
know
other
than
what
watching
for
cves
or
trying
to
you
know,
pay
attention
to
mailing
lists,
or
this
kind
of
thing.
So
this
isn't
that
we
actually
want
to
address
and
I'll
talk
about
that
in
a
few
slides
time
final
way
to
slice.
A
So
how
do
we
even
generalize
generalize
generate
these
visualizations
and
how
do
we
keep
track
of
them
today?
Well,
in
the
last,
this
is
actually
a
shifting
story
in
the
last
month
or
two
there's
been
a
number
of
improvements
to
this,
and
we
now
have
pretty
complete
metadata,
which
used
to
only
be
comments
or
not
at
all,
about
most
of
our
projects
that
we
depend
upon.
We
have
project
metadata,
versioning
information,
pinning
sharpening.
A
We
have
when
these
competitors
were
last
updated
and
then
information
on
the
use
category
and
extensions
and
cpe,
which
were
actually
very
useful
in
generating
the
visualizations
which
preceded
the
slide,
we're
actually
also
providing
a
dashboard
which
tracks
it
ahead.
The
current
version
and
externalizes
all
this
information
and
links
to
cve
search
and
that
kind
of
thing,
and
this
gets
included
now
in
the
onboard
documentation
in
each
release.
A
So
far,
we've
lastly
talked
about
things
which
are
informational,
they're,
not
necessarily
actionable
in
and
of
themselves
we're
trying
to
actually
take
this
information
use
this
to
improve
envoy's
security,
posture
and
the
way
we're
doing
this
is
to
start
with
is
by
formulating
a
policy,
and
this
policy
is
already
up,
but
we're
working
on
refining
this
and
making
it
enforceable.
But
this
will
say
things
like
well,
you
don't
get
to
add
a
repository
to
envoy
unless
it
has
peer
code,
peer
review,
peer
review
of
code.
A
It
has
version
releases,
release,
notes,
testing,
fuzzing,
all
this
kind
of
thing,
or
at
least
you
don't
get
added
to
make
a
dependency
of
the
core
or
things
like
robust
extensions,
because
having
a
policy
like
this
is
going
to
help
control
the
growth
in
extensions
and
it's
going
to
allow
us
to
have
greater
confidence
in
them.
We
probably
have
to,
like
you
know,
grandfather
in
certain
dependencies
which
don't
quite
match
up
to
this
standard,
but
where
possible,
this
will
also
use
this
drive
a
policy
around
replacing
these
older
dependencies.
B
Thanks
very
much
harvey
yeah,
so
so
dependency
maintenance
has
been
an
interesting
journey
for
me.
I
actually
went
to
one
of
the
first
envoy
meetups
that
matt
klein
gave
in
the
bay
area
sort
of
many
years
ago
and
became
very
intrigued
with
the
project
and
sort
of
tried
to
jump
in
straight
away.
I'm
not
like
a
strong
c
plus
plus
programmer,
but
also
I
sort
of
thought
you
know.
How
can
I
add
value
here
and
really
got
interested
in?
B
How
do
we
maintain
dependencies
maintain
their
currency
throughout
the
project,
and
so
I
sort
of
started
doing
some
of
this
work,
and-
and
I
was
thinking
about
you
know-
how
do
I
actually?
How
do
I
go
about
doing
this,
and
so
essentially,
what
I've
done
over
over
the
years
is
sort
of
build
up
a
process
around
maintaining
the
dependencies,
and
I'm
going
to
share
that
with
you
now
in
terms
of
some
of
the
dependencies
get
bumped
through
the
natural
course
of
development
on
invoice.
B
But
then
there's
just
the
regular
maintenance
and
that's
largely
what
I've
been
doing,
and
so
what
I've
done
is
built
like
a
large
rss
feed
that
tracks
most
of
the
dependencies
and
when
a
new
dependency
gets
added.
There
was
actually
another
one
added.
Today
I
actually
modify
my
my
rss
feed
and,
and
then
I
monitor
the
updates
from
releases
and
for
where
we
have
dependencies
without
releases
monster
the
commits
and
as
they
come
through.
B
I
can
open
those
look
at
those
determine
if
we
think
we
need
to
actually
make
a
change,
whether
it's
significant,
whether
we
can
skip
the
change
and
and
that's
sort
of
just
built
up
over
understanding
where
all
the
dependencies
sit
over
time.
And
there
is
a
link
down
the
bottom.
There
there's
a
a
github
guest
which
has
that
rss
opml
feed
for
those
that
are
interested
in
looking
at
these.
B
The
frequency
of
these
updates
and
then
we've
got
some
teams
also
that
use
that
use
bots,
that
look
at
github
release
emails
as
well,
and
they
can
actually
turn
those
release,
emails
that
come
out
of
releases
or
commits
and
modify
their
repos
based
on
those
watches.
Next
slide
are
we,
and
so
just
just
quickly?
Here's
like
a
table
that
lays
out
where
all
of
the
dependencies
in
the
invoice
envoy
codebase
are
there
used
to
be
more
than
this.
B
We've
actually
been
trying
to
consolidate
the
the
location
of
the
dependencies
it
used
to
be
quite
spread
out,
and
so
you
can
see
that
the
most
of
the
heavy
lifting
for
the
core
dependencies
is
in
the
bazel
repository
locations
file,
and
then
we've
got
some
api
dependencies
on
on
the
far
top
left
in
those
basal
files
and
then
down
below
bottom
right.
We
have
some
of
the
other
and
test
categories
and
they're
the
python
pip
installs
that
we
do
that.
B
Another
key
thing
here
is
that
I
I
don't
rely
on
on
docker
for
any
of
this.
I
I've
got
into
twitter
fights
with
people
about
this,
but
I
generally
find
that
when
you're,
adding
docker
it
either
slows
you
down
or
just
adds
another
layer
of
another
layer
of
abstraction,
if
you
like,
that,
can
make
this
sort
of
testing
more
difficult.
So
what
that
meant
up
until
recently,
bazel
3.5.0,
I
was
actually
compiling
basil
from
from
source
on
my
raspberry
pi
4.
B
And
so
what
are
some
of
the
tools
that
I
use
to
to
go
through
this
process?
So
mainly
this
refers
to.
How
do
we
generate
the
the
sha
shas
that
we
use
to
pin
against
in
the
build
process?
So
the
first
one
is
just
shas
256,
some,
it's
just
a
linux
tool,
that's
very
freely
available,
and
essentially
what
we're
doing
here
is
just
downloading
dependencies
out
of
github
or
wherever
the
source
of
the
of
the
dependency.
B
Is
you
just
run
that
against
the
tool
and
generate
the
shar,
then
that
goes
into
the
metadata
that
harvey
showed
before
that
is
used
to
verify
as
part
of
the
build
process,
we
just
added
the
same
requirements
for
the
for
the
pip
installs.
I
used
a
tool
there
called
hashen,
and
essentially
you
run
that
against
a
requirements.txt
file
passing
in
the
dependencies
and
it
generates
the
shares
there.
B
I
actually
think
that
this
is
actually
fairly
important,
so
the
integrity
of
our
docs
is
important
to
us
as
well.
So
we
don't
want
anything.
That's
has
the
ability
to
modify
or
interrupt
that
sort
of
quality
of
the
dockside
as
well.
So
we
think
that
these
additional
hashes
are
important
here
as
well,
then,
the
last
one
this
is
api.
B
Only
this
is
some
of
the
go
modules
and
I've
had
a
real,
really
hard
time
on
working
on
how
to
generate
these
sums
and
I've
tried
everything
from
custom
go.mod
files
to
play
around
with
the
go
command
line
tools
and
what
I've
resorted
to
now
is
I
find
the
version
bump
in
my
rss
file.
I
then
bump
the
version
number
then
run
a
test
and
have
it
fail,
which
generates
the
actual
correct
sum
that
I
can
then
put
into
into
my
testing.
B
So
what
I
wanted
to
talk
about
here
is
strategies
to
minimize
your
supply
chain.
So
what
that
is,
is
how
do
we
actually
minimize
the
the
dependency
lines
of
code
in
your
binary,
and
I
can
feel
very
confident
saying
that
there
are
many
extensions
that
harvey
you
showed
before,
that
you
don't
use
or
won't
need
to
use
as
part
of
your
invoice
deployment,
and
so
this,
the
current
images
are
currently
built
as
what's
called
a
kitchen
sink
image.
B
That
is
that
they
have
all
of
the
extensions
enabled
as
part
of
as
part
of
the
build
process,
and
so
why
kitchen
is
misspelt.
There
is
that
if
you
actually
look
at
that
issue,
matt
cline
actually
misspelled
the
word
kitchen
sink
and
whenever
I
would
try
and
go
back
and
find
reference
to
kitchen
sink,
I
remembered
it
by
knowing
it
was
misspelled
and
searching
for
kitchen
without
a
without
a
tea
and
so
the
way
to
there's
a
couple
of
strategies
here
on
how
to
minimize
your
envoy
binary
here.
B
The
first
one
is
a
custom
dot,
bazel
rc
file,
there's
a
link
there.
That
shows
a
link
to
the
documentation
on
how
to
do
this.
But
essentially
it
gives
you
a
way
of
disabling
certain
features
of
the
invoice
binary
as
you
build
it.
So
an
example
here
is
hot
restart,
there's
quite
a
few
scenarios
where
you
don't
need
or
require
hot
restart.
It's
a
fairly
sort
of
complicated
feature.
B
B
There's
a
very
large
list
here
so
you'll
find
that
you'll
be
able
to
significantly
reduce
your
exposure
to
the
extensions
by
this
method
and
then,
lastly,
for
the
teams
that
are
actually
importing
envoy
into
their
internal
repos,
you
can
actually
using
tools
like
copy
borrow,
actually
delete
the
extensions
out
of
the
source
tree,
rewrite
the
bazel
files
and
essentially
take
those
extensions
out
of
your
import.
So
you
end
up
with
a
much
slimmer
and
streamlined
invoice
source
code
base,
and
so
with
all
of
these,
all
of
these
methods
can
be
combined.
B
You
can
rely
on
your
local
package
management
systems,
yarn
mapped
and
there's
a
variety
of
other
ones
as
well,
or
you
can
actually
maintain
your
own
versions
and
override
the
the
dependencies
in
the
workspace
in
the
root
of
the
envoy
repo.
So
many
different
approaches
here,
depending
on
your
needs,
your
sophistication
and
your
requirements.
C
B
Yeah,
do
you
do
we
have
to
make
many
changes
to
dependencies?
Yes,
quite
often,
so
we
often
where
they're
at
what
we
try
and
minimize
is
carrying
patches.
So
if
you
look
at
the
actual
envoy
code
base,
you'll
see
that
there's
quite
a
few
dependencies
that
actually
have
patch
files
and
that's
where
harvey-
and
I
are
both
committed
to
try
and
reduce
or
eliminate
those
patches.
B
So
we
often
go
back
to
the
upstream
dependencies
and
ask
for
them
to
make
changes,
sometimes
that
that's
easy,
because
they're
controlled
by
friends
of
envoy,
in
particular
google
and
others,
sometimes
that's
more
difficult,
but
yeah.
We
often
have
to
make
changes
to
dependencies
as
we
bring
them
in.
C
A
A
So
python
node.js,
ruby,
even
rust,
but
unfortunately
there's
no
standardized,
csc
plus
plus
format
for
this,
and
so
we're
essentially
having
to
make
things
up
and
build
our
own
tooling,
as
we
go
because
c
and
c,
plus
plus,
are
sort
of
like
the
the
less
popular
languages
ones
which
folks
aren't
as
interested
in
building.
You
know
standardized
solutions
which
is
fun
really
hard
to
do
so,
yeah,
that's
kind
of
where
we're
at
right
now,
but
we
do
plan
on,
like
you
know,
sharing
what
we've
been
doing
in
norway
once
we're.
B
A
There
was
also
a
question
from
fabrizio
about.
There
are
some
documented
guy.
Is
there
any
documentation
on
how
to
actually
minimize
the
build,
and
I
don't
think
we
actually
have
a
good
guide
there.
So
I
think
opening
an
issue
around
that-
or
I
can
do
that
actually
or
country
and
pr
would
be
very
useful
because
I
don't
think
it's
obvious
other
than
reducing
number
of
extensions
you
have
compiled
in
and
most
folks
aren't
quite
clear
on
what
that
is.