►
Description
Fuzzing the CNCF Landscape - Adam Korczynski & David Korczynski, Ada Logics
This talk presents Adam’s and David’s experience with fuzzing more than ten projects in the CNCF landscape over the last year resulting in more than hundred bugs filed and fixed. For each of the projects, the goal was to integrate fuzzing such that the project would be continuously fuzzed by the free fuzzing service OSS-Fuzz. The projects which will be discussed in the talk include Kubernetes, Argo, Etcd, Containerd, Vitess, Linkerd2-proxy, runc, Flux and more. In this talk Adam and David will present a holistic view on this CNCF fuzzing experience and the focus will be on the technical challenges and results.
A
Okay,
good
morning,
everyone,
thank
you
very
much
for
coming
to
our
talk
on
fussing,
the
cncf's
landscape.
My
name
is
adam
and
I
work
with
david
at
adalogix
and
over
the
course
of
the
almost
la
of
the
last.
Almost
two
years
we
have
been
working
on
securing
and
we
have
been
working
on
improving
the
security
posture
of
cncf
projects
by
way
of
fosting.
A
B
And,
and
also
just
to
note
here,
we'll
present
a
lot
of
work
that
we
have
been
doing.
But
we
will
also
touch
upon
projects
and
data
where
we
are
just
like
tiny
pieces
of
of
the
whole
puzzle,
because
there
are
other
people,
fussing
various
uncf
projects,
and
they
deserve
a
huge
amount
of
credit
in
the
data
that
we
show
as
well.
B
Okay,
so
I'm
david
and
I'm
going
to
give
a
quick
intro
to
fussing
and
the
main
reason
for
this
is,
amongst
other
reasons,
to
kind
of
argue
why
it's
useful
to
people
who
might
be
interested
in
fussing,
but
not,
but
might
not
believe
it's
it's
really
working
and
how
many
here
are
familiar
with
fussing.
How
many
have
heard
about
it
before?
B
Okay,
so
around,
I
wanna,
say
40
or
something
how
many
have
never
heard
about
fossiling
before
okay.
So
certainly,
I
think
maybe
this
talk
is
jumping
a
little
bit
too
too
ahead,
then
so
so
fussing
from
a
high
point
of
view
is
like
automating
test
case
generation,
so
it's
very
similar
to
writing
test
unit
tests
or
integration
tests,
but
it's
a
way
to
kind
of
like
generalize
the
input
that
a
test
case
uses
so
on
the
left.
B
B
The
point
is
then
that
the
fossa
can
generate
all
sorts
of
inputs,
and
this
is
the
input
that
the
fossa
will
generate
is
often
considered
to
be
just
random
input,
but
in
fact,
it's
kind
of
input
that
has
been
constructed
by
way
of
a
very
complex
system,
underneath
that
is
the
fussing
engine
which
approximates,
in
a
sense,
a
very
useful
input
for
for
the
files
that,
if
one
can
argue,
but
how
this
will
look
in
actual
code
is
right
there.
B
So
here
we
have
the
simplest
case
of
flush
driver
in
the
go
language
where
you
just
have
a
function
called
fuss,
and
this
will
then
be
called
by
the
fussing
engine
which
is
kind
of
like
underlying
in
your
program
with
default
input.
And
then
you
just
called
my
api.
So
this
is
the
exact
way
that
you
would
write
a
fossa
for
my
api
in
golang.
B
So
I
said
before
there's
this
there's
this
myth
that
fussing
is
just
random
input.
It's
not
going
to
work
to
my
application
that
uses
highly
complex
data
data
types-
and
this
is
a
this-
is
kind
of
like
a
response.
We
often
hear
when
we
approach
cncf
projects,
especially
cncf
projects
that
are
not
that
are
written
in
memory,
safe
languages,
so
in
memory,
unsafe
languages,
cnc
plus
plus
fusing,
has
been
around
for
for
quite
a
number
of
years
now
years.
B
Now
I
think
fasting
was
first
started
around
30
years
ago,
but
it
has
really
had
this
evolution
or
resurgence
in
a
sense,
the
last
15
years
or
so
where
this
coverage
guided
fussing
came
to
be
so
we
often
get
this
response.
When
we
say
we
would
like
to
foster
a
project,
we
often
get
a
very
sort
of
critical
view
from
us.
It's
not
going
to
work
because
it's
just
random
testing
and
it's
just
a
false
notion.
B
In
a
sense,
there
are
hundreds
of
academic
papers
in
the
last
decade
exploring
how
to
improve
fussing,
and
it
did
start
30
years
ago
with
basically
just
cutting
from
random
and
using
that
as
input
to
your
program.
But
that's
not
how
it
is
anymore.
It's
a
highly
structured
tools
that
try
to
pick
the
right
inputs
to
your
code,
such
that
you
will
execute
essentially
as
much
of
the
underlying
code
as
possible
and
when
I
say
modern
day
fosters
here,
I
really
refer
to
coverage-guided
fossus,
so
like
underlying
principles
in
coverage.
B
Guided
fasting
is
that
you
have
a
given
corpus,
which
is
just
a
set
of
test
cases,
and
these
are
the
test
cases
that
you
work
from
when
you
want
to
generate
new
input
to
a
a
an
api
and
the
fuzzer
will
start
with
a
given
corpus.
It
could
be
just
a
random
element
and
then
it
will
start
to
exec,
and
then
you
will
have
to
compile
your
code.
So
your
target
project
that
you
want
to
analyze.
B
You
have
to
compile
that
in
a
certain
way,
such
that
essentially,
the
compiler
can
insert
extra
code
into
your
program
that
the
foster
will
use
to
essentially
trace
execution
in
the
target,
and
it's
then
going
to
use
this.
I
I
ability
to
track
execution
in
the
program
to
identify
whether
a
given
test
case
is
good
or
bad,
and
the
way
he's
going
to
do
this
is
it's
going
to
pick
c's
from
the
from
the
corpus.
B
It
will
execute
the
program
with
that
seed
and
then
it
will
track.
What
was
the
kind
like?
Let's
say:
let's
just
call
it
execution
path
of
that
program.
Okay,
then
it
will
save
the
execution
path
into
kind
of
like
a
set
of.
We
have
explored
this
already
then,
the
next
time
it
will
so
like
just
run
again
pick
a
new
seed
from
the
corbus
mutate
that
seed.
So
that
means
just
modified
randomly
in
a
sense
and
then
it
will
execute
the
program
again
and
again.
Trace
did.
Did
we
see
a
new
trace
in
the
program?
B
It's
not
really
traces,
but
I
think
it's
more
intuitive
to
think
of
it.
That
way,
and
if
there
is
a
new
coverage,
say
a
new
trace
with
this
new
input,
then
it
will
save
that
seed
into
the
core
bus.
But
if,
if
there
isn't
new
coverage,
they
will
just
kind
of
like
forget
about
that
seed.
And
the
main
point
is
that
you
build
up
this
corpus
iteratively,
where
each
seed
in
the
corpus
essentially
executes
the
target
program
in
a
unique
way.
B
B
And
if
you
were
to
guess
for
four
bytes
correctly
say
a
b
c
d,
just
four
characters,
you
would
have
a
a
a
an
input
space
of
2
to
32,
because
a
byte
is
8
bits
and
4.
Bytes
is
plus
32
bits
which
is
2
to
32.
B
But
because
we
have
this
notion
of
core
bus
and
coverage
guided,
we
have
to
guess
each
byte,
essentially
one
at
the
time
and
when
we
are
to
guess
one
byte,
there's
two
to
the
eighth
chances
of
getting
it
correctly.
Okay,
so
that's
one!
That's
you
have
a
chance
of
one
out
of
256
to
guess
the
first
bite
correctly.
So
let's
say
we
get
the
first
bite
correctly.
B
Then
we
save
that
seed
in
our
corbus
and
we
just
call
our
current
seed
so
like
at
data
buffer
with
a
and
then
we
have
to
guess
the
next
one
and
that's
again
to
guess
the
next
byte
we
again
have
a
chance
of
one
of
256
of
guessing
it
correctly
and
that
kind
of
keeps
going
until
we
have
guest
abcd
correctly
and
again.
The
reason
we
do
that
is
because
we
save
whenever
we
see
that
we
guessed
it
correctly.
We
save
that
and
we
move
on
to
guess
the
next
byte.
B
and
that's
kind
of
the
ideas
behind
coverage
guided
fusing
and
why
it
reduces
the
complexity
of
exploring
a
program
from
just
random.
Guessing-
and
this
is
this,
this
thing
is
called
coverage,
guided
fusing
and
that's
kind
of
like
one
of
the
breakthroughs
and
fussing
that
essentially
made
it
much
more
applicable
and
what
almost
everybody
uses
today.
B
B
So
the
things
that
you
find
at
the
moment
are
stuff,
such
as
encore,
encode,
exceptions
out
of
bounds,
nail
pointed
references
timeouts
in
some
sense,
deadlocks
and
other
memory
issues,
and
these
are
kind
of
the
things
you
can
expect
when
you
fast
when
you
fuss
a
a
a
golang
project,
you
can
also
do
various
things,
such
as
behavioral
testing,
but
I
don't
think
I
will
go
into
that
now,
but
point
being
you
can
expect
you
the
fastest
will
not
detect
an
issue
in
itself.
It's
actually.
B
Okay,
so
fusses
are
pretty
complex
to
to
to
manage.
As
I
said,
we
need
to
have
this
core
bus
and
we,
the
faster,
will
build
up
the
corpus
over
time
as
it
explores
the
code,
and
that
also
means
you
shouldn't
run
the
fuzzer
from
an
empty
corbus.
Whenever
you
run
it,
you
kind
of
have
to
incrementally
build
it
up
over
like
each
day
over
the
years
and
so
on,
and
there's
also
a
lot
of
other
issues
that
comes
with
managing
fuses,
such
as
you
know.
How
do
you
keep
track
of
all
the
bugs?
B
How
do
you
report
things
and
how
do
you
share
results
between
everybody,
and
this
is
what
we
have
oss
was
for
so
oss.
First
is
a
service
run
by
google,
which
is
oss?
I
think
it's
open
source
software
first
thing.
Thank
you
and
it's
essentially
a
git
repository
where
you
upload
a
docker
file.
You
upload
a
build
script
and
then
you
to
a
given
folder
in
this
github
repository
and
then
google
will
just
start
running
all
the
files
that
the
given
build
script
will
build.
B
So
this
is
where
the
vast
majority
of
open
source
projects
are
being
fussed
by
way
off
now,
and
I
think
that
ocs
first
has
around
600
open
source
projects,
so
essentially
all
the
the
very
security,
critical
ones
and
all
the
ones
that
we
will
be
talking
about
this
case
in
in
this
talk
is
also
on
those
sensors
and
yeah.
We
have
a
link
here
to
how
to
integrate
into
ocs.
First,
please
check
it
out.
B
The
same
developers
of
oss
first
has
developed
this
concept
called
clusterful
slide,
which
essentially
runs
and
manages
all
of
your
fusses
in
your
ci,
and
you
don't
have
to
to
like
do
the
whole
integration
into
ourselves.
First
and
clusterful
slide
is
also
straightforward
to
integrate
into
your
project,
so
if
you're
an
open
source,
maintainer
or
similar
check
it
out.
B
Okay,
so
I
think
I've
already
talked
about
this.
Let's
now
talk
about
the
cncf
landscape
being
fast.
A
So
yeah,
so
here
we
see
an
overview
of
the
cncf
projects
that
are
currently
integrated
in
towards
espos
and
a
quick
note.
Istio
will
also
fall
on
this
list
once
it
joins
ideologics.
We
have
written
a
lot
of
fossils
for
istio,
which
also
has
resulted
in
a
high
severity
finding
we
have
a
blog
post
about
that
on
our
blog.
It's
a
pretty
interesting
case.
If
you
are
a
go
developer,
so
I
encourage
you
to
check
that
out.
A
At
least
I
can
think
of
at
least
one
that
do
have
fosters
and
do
a
pretty
good
job
at
writing
forces
and
maintaining
them
and
making
sure
that
they
are
not
broken,
but
not
all
cncf
projects
that
do
maintain
a
fussing
suite
integrated
into
a
ss
first,
and
because
of
that,
it's
it's
it's
a
little
difficult
to
say
that
that
they
that
these
projects
are
running
their
fossils
correctly,
for
the
reasons
that
david
mentioned
because
running
the
phosphorous,
especially
once
you
get
start
having
10
20
30
fossa's
in
your
system
in
your
project,
it
becomes
a
very
complex
task
to
run
these
fossils.
A
A
Yeah,
that
is
our
practical
approach
to
pretty
much
all
cncf
projects
that
we
approach
that
have
done
no
prior
work.
With
forcing
david
mentioned,
we
have
worked
on
some
projects
that
have
worked
on
forcing
for
years
and
that
that
is
another
story,
so
so
this
is
more
in
terms
of
taking
a
project
from
zero
to
having
a
pretty
solid
fussing
setup.
A
So
we
start
with
an
initial
integration
and
to
us
that
means
we
start
by
writing
a
few
initial
forces
and
merge
them
into
the
cncf
fussing
repository
where
we
maintain
all
fossa's
that
we
write
for
for
the
cncf
projects.
A
We
are
we
open
for
contributions
there
and
please
check
it
out
if
you,
if
you,
if
you
wish
to
next,
we
integrate
the
project
into
oss
first,
so
the
fossils
run
continuously
and
on
in
the
oces
force
integration.
We
instruct
voices
first
to
put
the
latest
master
branch
or
release
branch
and
pull
the
faucets
from
the
cncf
fusion
repository,
so
that
so
that
we
can
work
on
the
forces
through
the
cncf
fusing
repository
and
oss
first
will
catch
those
updates
continuously.
A
The
next
step
is,
we
write
a
lot
of
us
to
to
get
coverage
up
and
yeah.
I
mean
at
this
point.
We
we
we
have
made
the
initial
integration
and
we,
the
next
step,
is
really
to
increase
coverage
of
the
whole
project,
starting
with
complex
parts
of
the
code
base.
A
Finally,
we
we
work
on
delivering
this
over
to
the
project,
maintainers
and
owners,
and
if
we,
the
goal
on
this
final
step,
is
to
make
the
owners
take
charge
of
the
the
process
the
project
owners
take
charge
of
the
fusing
from
here
we
want.
It
is
our
goal
that
it
is
the
project's.
It
is
the
projects
that
that
they
take
complete
ownership
and
they
can
do
whatever
they
want.
A
The
lead
fosters
modify
fosters
if
they,
if
they
see
it
fit
and-
and
in
this
step
here,
step
three,
we
work
with
the
projects
on
doing
that.
A
So
there
are
some
pros
and
cons
of
having
someone
like
ossa
data,
logics,
integrate
a
cncf
project,
integrate
fusing
into
our
cncf
project,
and
one
of
one
of
the
pros
is
that
we
have
a
lot
of
experience
with
fussing.
I
think
a
datalogics.
We
have
contributed
fosus
to
more
than
200
open
source
security
projects,
sorry
open
source
projects
so,
and
we
have
you
know,
gone
down,
rabbit
holes.
We
have
seen
what
you
know,
what
how
how
to
quickly
get
from
zero
to
one
and
effectively.
A
But
of
course
we
don't
have
the
year
months
and
years
of
experience
that
the
project
maintainers
do
and
yeah
naturally
on
the
third
one
as
well.
Maintainers,
don't
have
that
much
time
to
first,
you
know,
learn
about
fossiling
and
how
to
best
integrate
it
into
that
project.
They
have
plenty
to
do
already.
A
I
believe
we
had
a
project
where
they
had
had
had
a
github
issue
on
the
fact
that
they
should
integrate
fussing
into
that
project.
For
two
years
this
this
issue
had
been
open
and
at
data
logic
we
were
able
to
pretty
quickly
get
fusing
started
and
the
the
engagement
resulted
in
a
high
severity
cv.
A
A
Yeah,
I
think
that's
it
for
this
one
yeah,
so
so
in
in
terms
of
the
last
step
in
the
process
of
integrating
of
working
with
the
cncf
projects.
A
A
few
things
that
we
do
when
we,
when
we
wish
to
hand
over
the
fusing
suites
to
the
projects
themselves,
is
that
we
encourage
so
we
work
from
the
cnc
cncf
fusion,
repo
initially,
and
we
encourage
the
maintainers
to
move
the
forces
upstream
to
integrate
into
the
test.
Suite
ci
nightly,
builds,
etc
and
which
will
make
maintenance
easier
and
should
help
the
projects
avoid
downtime
in
their
in
their
forces.
A
There
will
often
be
a
a
list
of
bugs
found
in
in
this
engagement
and
osspos
has
capabilities
to
reproduce
these
very
easily,
and
this
this.
This
will
be
something
that
will
help
projects
with.
We
encourage
projects
to
write
fosus
specific
for
that
project
and
simply
simply
further
develop
the
whole
forcing
setup
how
how
the
project
see
fit
a
quick
note
on
if
on
our
gopher's
header
project,
if
you
are
a
project
that
is
that
is
implemented
in
go,
we
have
a
very
neat
little
library
here.
A
B
Okay,
so
hello,
hello,
all
right,
so
you
can
fast
a
lot
of
different
projects
written
in
a
lot
of
different
languages
and
essentially
oss
first
supports
all
supports
projects
within
golang,
cnc,
plus
rust,
python
and
java
java,
and
the
bugs
you
look
for
in
various
the
box.
You
look
for
in
a
project
kind
of
depends
on
the
language
that
you
are
fussing
and
threat.
Models
of
the
projects
that
you
are
fussing
may
not
always
be
present,
so
you
can
go
multiple
ways
when
you
are
to
say
foster
project.
B
Can
you
can
try
to
identify
the
whole,
and
the
result
of
that
is
that
you
will
find
most
likely
a
lot
of
bugs
but
may
not
be
securely
relevant
bucks
because
you
might
not
so
like
attack
the
threat
model
in
a
sense
and
ccf
projects
are
often
written
in
memory
saved
languages,
which
means
that
if
you
are
looking
to
fast
cncf
projects,
most
likely,
you
will
turn
into
go
or
say
mainly
go
to
be
honest,
but
at
the
same
time,
even
if
you
are
fussing
a
project
written
in
goal
line,
you
can
always
look
for
the
dependencies
of
a
given
project.
B
So,
for
example,
flux
it's
a
git
ups
tool
that
is
based
on
that
it's
written
in
go,
and
it's
a
so
like
a
bunch
of
custom.
Kubernetes
operators
controllers,
sorry
and
that
depends
flux
depends
on
the
other.
Go
project
called
get
to
go
and
get
to
go.
Itself
depends
on
the
library
called
libgit,
which
has
sixty
thousand
lines
of
c
of
c
or
super
splash
code.
B
I
can't
remember,
which
essentially
means,
even
if
you
are
just
interested
in
fussing
memory,
unsafe
projects,
you
can
still
go
for
a
lot
of,
say,
cncf
projects
that
may
not
be
written
in
memory
unsafe
languages,
because
they
will
have
dependencies
to
memory
unsafe
languages.
B
Okay.
So
what
are
the
results
here?
And
the
results
we
are
going
to
present
in
this
section
is
essentially
the
data
given
to
us
by
oss
first
on
this
url,
so
they
make
all
of
the
results
publicly
available
by
on
box.chromium.org,
and
you
can
use
the
following
query
to
essentially
get
the
results
that
that
we're
going
to
show-
and
I
want
to
just
give
a
note
here-
that
this
is
an
overapproximation
from
the
perspective
of
the
results-
are
the
results,
but
it
will
be.
B
The
fusses
will
like
not
necessarily
only
find
legit
bugs
the
forces
themselves
can
have
issues
which
will
be
reported
as
a
bug
in
this
manner.
The
engines
can
sometimes
have
an
issue
which
will
also
report
a
bug,
so
take
it
with
a
little
bit
of
grain
of
salt
and
don't
expect
that
all
these
numbers
constitute
exploitable
bucks.
B
So
these
are
the
results
on
from
from
oss,
first
reported
and
potentially,
what
we
can
see
here
is
that
there
are
two
projects
envoy
and
phonebit,
written
in
c
plus
and
c,
and
they
have
approximately
well
above
200
bucks,
each
reported
and
notice
again
that
this
is
this
does
include
security
box
and
also
non-security
box,
as
set
by
oss
first.
So,
if
you
look
at
the
query
you
can
see,
I
have
this.
It's
like
type
here
where
we
both
include
security
and
box
security
types.
B
So
it's
not
just
security
types,
and
this
includes
all
forms
of
well
all
forms
of
memory,
corruption,
issues
that
you
can
imagine
and
notice
here
that
envoy
has
been
fussing,
for.
I
think
they
first
integrated
into
ss
first
since
2016,
and
I
believe
that
the
team
has
done
like
a
tremendous
job
in
in
getting
fussing
all
over
their
project.
So
in
the
sense
that
there's
a
lot
of
box,
it's
a
good
sign
from
the
perspective
of
they
have
analyzed
a
lot
of
their
code
base.
B
We
didn't
have
all
of
the
the
golang
projects
here
and
you
can
see
that
the
numbers
are
quite
a
bit
lower,
but
this
is
also
a
reference
to.
They
are
not
as
like,
mature
in
their
fussing
approach
as
the
two
other
projects
that
I
mentioned
here.
B
But
these
are
the
numbers
that
you
can
expect
and
in
a
sense
it
also
goes
to
show.
There
is
some.
There
will
be
work
involved
here
because
imagine
sitting
at
the
receiving
end
of
envoy
and
you
have
to
analyze
860
bucks
to
verify
how
to
fix
them
or
et
cetera,
et
cetera.
A
lot
of
them
will
also
be
like
issues
from
the
oss
site
that
will
be
fixed
by
itself
in
a
sense,
but
there
will
be
a
lot
of
work
for
for
for
the
developers
to
to
deal
with
this
stuff.
B
So
if
we
are
to
plot
the
issues
that
are
reported
here,
we
can
plug
them
based
on
how
many
issues
are
closed
on
this
monorail.
So
the
database
that
I've
just
shown
or
and
also
how
many
are
open,
and
in
that
sense
we
can
see
how
often
bugs
so
like
get
introduced
or
like
get
found
by
the
fusses
and
how
often
they
are
so
like
fixed.
So
here
we
have
a
project
called
argo
and
the
red
graph
that
you
see
up
here
is
the
amount
of
box
closed
on
the
database.
B
That
means,
whenever
a
bug
is
fixed,
it
will
turn
from
open
to
closed.
So
close
is
just
going
to
go
upwards
depending
on
how
many
bucks
gets
found
and
fixed,
whereas
the
blue
one,
the
blue
is
like
line,
shows
how
many
issues
are
open.
So,
ideally,
it
will
go
a
little
bit
up
and
then
it
will
hopefully
go
down
depending
on
how
fast
the
bugs
are
fixed.
B
And
here
we
have
an
example
of
say:
when
fussing
was
introduced
quickly,
a
lot
of
bucks
was
found,
but
they
were
also
very
very
fast
to
fix
it,
and
we
can
also
see
that
it's
kind
of
a
like
a
rhythmic
curve,
the
red
one,
which
means
that
the
fossils
will
find
a
lot
of
bugs
in
the
beginning,
and
then
it
will
start
to
fade
out
as
they
kind
of
have
explored
all
of
their
potential
or
get
to
explore
all
of
their
potential.
B
We
have
another
project
here,
kubernetes
and
notice
that
the
the
so
the
x-axis
shows
the
date
and
the
y-axis
shows
the
the
amount
of
issues
closed
or
opened,
and
here
you
can
see
so
like
a
similar
graph.
It
looked
rhythmic
in
a
sense
and
there
are
a
few
bugs
still
open
in
the
kubernetes
bug
tracker.
B
B
It
really
well
the
legacy
team,
but
at
the
same
time
you
can
also
see
bugs
kind
of
stopped
being
found,
let's
say
six
months
ago,
and
you
can
ask
why
most
likely
that's
because
they
don't
contribute
new
fusses
to
their
code
base,
which
is
also
an
interesting,
a
thought.
B
So,
if
you
were
to,
for
example,
if
you
knew
how
to
fast
rush
projects
most
likely,
you
could
go
and
and
and
help
them
out
fluent
bit
another
example,
and
again
we
see
it,
it's
like
they,
the
blue
bar,
keeps
being
low,
whereas
the
box
keep
increasing,
and
that's
also
a
sign
of
whenever
so
like
whenever
a
bug
is
found
and
fixed.
B
That
one
gets
put
you
know
put
on
the
ripper,
but
the
blue
one
kind
of
stays
constant,
and
that
means
every
time
a
bug
is
fixed.
A
new
one
is
found
so
when,
when
your
first
find
finds
a
bug,
it
will
kind
of
like
run
into
that
bug
all
the
time,
so
it
will
kind
of
redetect
it
all
the
time
when
you
then
fix
it.
It
can
finally
progress
further
into
coverage
and
that's
why,
like
the
red,
will
continue
to
grow,
whereas
the
blue
line
stays
stable
and
here
is
the
envoy
project.
A
Yeah
yeah,
so
let's
talk
about
where
we'll
go
from
here:
let's
zoom
out
a
little
bit
in
terms
of
where
we
are
in
the
greater
scheme
of
things
here,
as
david
mentioned
over
the
last
10
15
years,
a
lot
of
work
has
been
done
in
making
fussing
generally
available
for
for
open
source
projects
for
the
open
source
community
that
that
has
included
writing
really
really
great
fussing
engines
sanitizers
and
bringing
these
this
technology
to
other
languages
to
all
sorts
of
languages,
as
david
already
mentioned.
A
So
next,
over
over
the
last
few
years,
we
have
worked
on
bringing
these
forcing
capabilities
to
the
cncf
projects
and
and
in
in
and
like
you
see
that
that
is
like
more
or
less
where
we
are
in
in
that
in
that
story.
So
let's
talk
about
the
next
steps.
What
what
will
happen
over
the
next
couple
of
years?
Like
we
mentioned,
we
want
to
see
main
maintainers
involved.
A
Next,
we
will
see
more
box
bug,
oracles
and
sanitizers
for
memory
save
languages.
There
are
a
bunch
of
of
vulnerabilities
that
fosters
don't
detect.
They
do
they
check
some,
but
there
are
a
lot
they
don't
detect
and
we
want
to
find
those
automatically
next
yeah,
again
mature,
forcing
even
more
based
on
what
has
been
done
now
and
that
involves
involving
involving
the
community
and
the
maintainers.
Could.
B
I
just
could
I
just
interrupt
here
so
with
regards
to
this.
Could
you
go
one
back
with
regards
to
this
bug,
oracle's
standard
sizes.
One
important
point
to
highlight
here
is
that
we
have
java
fussing
available,
but
it
didn't
detect
the
lock
for
j
issue.
B
Then
they,
the
developers
of
this
java
fussing
engine,
came
up
with
a
bug,
oracle
to
detect
command
injections
and
they
found
lock4j
in
a
matter
of
minutes
with
that,
it's
like
the
new
bug,
oracle
and
you'll
see
a
lot
more
of
that
where
people
will
try
to
identify
those
type
of
like
high
level
issues
that
may
not
be
just
detectable
by
the
program
crashing.
For
example,.
A
Yeah,
so
I
I
I
guess
we
have
already
gone
through
the
maintainer
involvement.
That
is
one
of
the
steps
that
we
will
cons
that
we
want
to
see
over
the
next
couple
of
years,
but
yeah
so
david
had
an
example
of
a
real
world
scenario
where
a
bug
detector
was
improved
to
to
detect
new
vulnerabilities,
and
let's
talk
about
like
some
possible
scenarios
where
that
will
occur
in
the
in
the
cloud
native
space
that
that
the
cnc
projects
can
benefit
from.
A
So
when
we
talk
about
bug,
oracles
or
sensors,
we
consider
it
from
an
from
a
perspective
of
it
being
integrated
like
into
fusing
where
the
the
developers
of
foss
harnesses
and
the
tests
itself
don't
have
to
tweak
or
change
settings
of
the
photos.
But
the
same
frost
test
can
be
used
to
detect
all
these
different
box
and
vulnerabilities.
A
A
A
I
believe
that
the
talk
after
hours
is
about
a
vulnerability
associated
to
to
file
handling.
So
I
encourage
you
to
check
that
out,
but
basically
can
we
read
arbitrary
files?
Can
we
write
arbitrary
files
on
the
system
that
we're
not
supposed
to
command
injections?
We
added
the
logics.
We
found
a
suv
in
a
high,
severe
severe
city,
I
believe
in
flocks
last
winter
and
that
that
could,
I
think,
believe
they
found
another
one
just
last
week
and
yeah.
A
It
continues
to
be
an
issue
in
in
the
in
the
memory
saved
languages,
and
we
it
would
be
it
is.
We
might
see
a
bug,
oracle
sanitizer
that
will
find
these
these
bugs.
So
the
main
point
here
is
that
when
we
get
these
sanitizers
into
the
the
fusing
itself
into
fuzzing
itself,
where
developers
don't
have
to
do
anything
extra
to
to
make
use
of
these
sanitizers,
because
we
have
coverage
of
all
these
cncf
projects,
they
they
will
benefit
from
from
these
new
developments
immediately
and
that
will
have
a
massive
impact.
A
So
a
single,
a
single
sanitizer
will
be
piped
out
to
to
all
these
cncf
projects
without
much
or
any
further
work.
B
I
think
I
think
that's
it
we'll
leave
this
conclusion
as
such,
but
in
short,
we
fussed
a
lot
of
projects
found
a
lot
of
bugs
it
works
really.
Well,
it's
not
fully
automated,
as
you
can
see
that
there's
a
lot
of
bugs
to
digest
it
takes
time
to
write
these
verses,
so
you
will
often
hear
fuzzing
as
security
automation,
but
it
automates
a
part.
You
still
have
to
do
a
lot
of
work
yourself.
B
I
think
that's
it.
Thank
you.