►
From YouTube: Fuzz Testing Group meeting - 2020-06-16
Description
Weekly Fuzz Testing group meeting
A
All
right
welcome
everyone,
so
I
had
the
first
agenda
and
I
just
wanted
to.
This
was
kind
of
an
idea
that
I
was
thinking
about
a
little
bit
after
our
group
conversation
and
some
of
the
traffic
that
we're
getting
for
people
interested
in
fuzzing
for
their
customers
and
is
whether
we
should
produce
like
a
fuzzy
for
dummies
brown
bag
for
lack
of
a
better
term.
A
We
should
come
up
with
a
better
name
for
that,
but
basically
a
really
in
trouble
in
discussion
of
what
fuzzing
is
why
customers
might
be
interested
in
it
that
might
give
our
salespeople
and
some
of
our
technical
account
managers
some
information
on
how
to
to
learn
more
and
how
to
pitch
us
to
some
of
our
customers.
So
I
just
want
to
throw
that
out
there
as
an
idea.
B
Think
I
was
just
discussing
with
someone
this
this
week
about
how
you
know
the
the
term
for
fuzzing
has
been
overloaded
a
lot,
and
so
it
probably
really
great
to
produce
some
content
to
educate
that
mean.
We
can
then
further
turn
into
stuff.
That's
customer
facing
as
we
move
forward
since
I
think
we're
gonna
have
to
explain.
You
know
the
intent
of
our
tools,
and
you
know
the
types
of
fuzzing
that
we're
gonna
do
and
how
we're
communicating
that
and
so
on.
A
Cool,
so
what
I'll
do
is
I'll
open
up
a
brown
bag
issue
for
this,
and
then
on
that
issue
we
can
just
discuss
what
we
want
to
cover
in
this
this
fuzzing
for
dummies,
because
it
sounds
like
there
could
be
a
whole
series
of
content
we
produce
and
we'll
just
need
to
figure
out
what
our
audience
for
each
one
is
so
that
we
can
try
to
make
these.
You
know
short
and
pithy
and
educational
and
not
try
to
cover
everything
in
one
session.
D
I
haven't
work
on
inner
vision
yet,
but
I
did
a
pretty
dog
with
some
and
run
it
over
with
some
other
designers
that
there
are
some
technical
assumptions
and
some
ideas
at
the
end.
It's
just
really
an
idea
written
level.
So,
for
example,
like
we
can
change
the
maybe
severity
of
the
fighting
without
from
unknown
to
add
on
things
or
cooperate
with
like
mad
to
see,
there's
something
we
can
work
with
with
highlight
unknown
result
or
something
like
that.
D
So
if
you
have
anything,
just
go
to
the
ideas
at
the
bottom
and
if
you
think,
like
everything
on
the
top,
are
some
assumptions
we
have.
You
have
different
ideas
and
just
comment
on
it.
Then
I
know
that
you
want
to
change
something
so
ideas
you
can
directly
put
there
and
for
that
some
friends.
Please
comment
on
it.
C
E
D
A
A
A
It's
a
it's
a
project,
but
it's
also
a
repository
which
is
get
lab,
COV
fuzz
source,
and
that
is
private,
so
only
get
lab
team
members
can
see
that
and
update
source
code
or
contribute
source
code
into
that
repository,
because
it's
a
private
project,
people
outside
of
get
lab
are
not
able
to
access
the
container,
reg,
Street
or
anything
inside
that
project.
So
that
created
a
problem
for
us
when
we
want
to
publish
images
to
our
docker
container
registry
or
publish
binaries.
A
So
the
solution
to
that
is,
we
created
gitlab,
COV
fuzz,
which
is
like
below
it,
which
will
be
available
for
our
docker
images
and
for
the
binaries.
So
we'll
use
that
as
our
publishing
there
won't
necessarily
at
this
point,
be
any
repository
in
there
other
than
perhaps
a
readme
and
where
we're
storing
binaries,
so
there's
no
source
code.
A
In
that
second
link,
and
then
the
third
is
within
security
products,
slash
demos,
that's
where
we
can
put
sample
projects
and
that's
you
know,
projects
that
customers
can
download
play
around
with
tweak
and
try
to
use
that
as
a
sample
for
how
they
want
to
set
up
their
own
work.
So
that's
the
structure
that
we
set
up
for
this
tool.
I
want
to
make
sure
everyone's
aware
of
that,
because
I
would
imagine
we'll
do
something
very
similar
for
the
API
fuzzing
in
terms
of
the
structure.
C
Let's
see
so
after,
let's
see
I
created
this
issue
at
the
end
of
the
day
yesterday
and
I
reread
it
this
morning,
I
think
I
may
have
come
across
a
little
strong,
but
long
story
short.
The
issue
is
about
us
using
the
term
coverage
to
describe
a
category
of
fuzzing
when
that
is
just
one
aspect
of
fuzzing.
It's
like
a
one
feature
of
fuzzing
right,
so
API
fuzzing
can
use
coverage
the
using
lip,
buzzer
or
FL
or
go
fuzz.
They
can
use
coverage
coverage
is
just
one
technique.
C
The
real
reason
for
me
creating
the
ticket
is
that
I
personally
was
getting
starting
to
get
confused
about
what
Gouri
things
were
falling
into
and
if
I
was
going
to
get
confused
about
it,
the
users
might,
if
they
knew
about
some
of
the
technology
being
used
or
if
they
knew
API
fuzzing
was
using
code
coverage
to
improve
its
fuzzing
performance.
Then
they
might
think
it
is
the
coverage
base
fuzzing
instead
of
just
API
fuzzing
right,
so
yeah,
it's
a
that's
the
gist
of
it.
I
don't
mm-hmm.
C
I
haven't
had
time
to
update
the
ticket
some
more
so
there
are
the
different
pieces
of
the
buzzing
technology
that
we
could
use
to
categorize
it
and
so
like
it
does
it's
a
mutation
based
buzzing
or
a
jennette
uses
genetic
fuzzing,
algorithms
or
or
you
could
talk
about
what
it's
fuzzing.
The
other
aspect
is
so
API
fuzzing
you
that
one's
kind
of
talking
about
two
different
things,
it's
talking
about
what
you're
fuzzing,
but
also
the
specific
fuzzer
that
you're
using
we
are
using
an
API
fuzzer
right,
and
so
it's
a
for
the.
C
What
we're
calling
the
coverage
based
ones.
We
are
using
Lib
buzzard,
go
fuzz
or
wrapping
a
FL
there's
yeah
anyway.
So
these
are
all
the
things
swimming
through
my
mind
when
I
made
the
ticket
and
I
I'll
admit.
I
should
have
probably
waited
another
day
to
try
and
solidify
my
thoughts
and
have
a
better
proposal,
but
the
term
coverage
is
applies
to
all
of
the
different
types
of
fuzzing
and
it
was
becoming
confusing
to
me
so
I
I
will
update
the
ticket
talking
about
a
few
of
more
things,
but
that
was
the
gist
of
it.
B
Yeah,
thanks
for
creating
that
I
think
that
was
a
that's
a
great
thing
to
point
out
and
I
kind
of
agreed,
I.
Think
in
the
future.
You
know
we're
likely
to
use
a
lot
of
these
techniques
across
all
the
different
fuzzers
we
have
and
so
kind
of
figuring
out
a
reasonable
naming
system.
That's
gonna,
you
know
not
end
up
confuse
people
in
the
futures,
I
think
a
good
idea.
B
I
think
you
know
when
I
read
it.
My
first
thought
also
is
like
I
think,
one
of
the
reasons
that
it's
convenient
to
call
things
like
coverage
and
and
behavioral
is
that's
a
lot
of
times
how
customers
talk
to
us
about
stuff.
You
know
a
lot
of
the
conversations
I
tend
to
have
is
like,
though,
will
be
the
things
like
I
hear.
Afl
is
good.
Do
you
fuzz,
like
AFL,
does
type
of
thing
right,
but
I
like
to
your
suggestion
that
you
know
we
don't
have
to
necessarily
name
the
project
like
that.
B
C
And
it's
there
is
kind
of
a
third
way
to
look
at
it.
It
doesn't
play
very
well
into
marketing
in
general,
it's
all
fuzzy
and
then
you
configure
the
fuzzer
to
fuzz
the
specific
target
right,
but
for
marketing
I
would
not
recommend
we
go
that
route
it.
That
would
assume
a
lot
of
knowledge
in
the
user
about
what
all
of
that
means,
and
so
okay
choose
your
type
of
buzzer
and
say:
I'm
gonna
choose
an
API
fuzzer,
and
then
you
configure
it
in
the
yamo
or
whatever
UX
we
provide
the
user
for
that.
C
I
think
that
would
be
too
much
in
the
past
when
I've
made
tools.
That
is
the
approach
I've
taken
where
it's
just
all
fuzzing,
and
then
you
choose
the
fuzzer,
the
debugger,
the
mutation
aspects,
and
you
can
figure
all
of
it,
but
that's
not
what
we're
going
for.
So
there
is
a
distinction
there
between
the
marketing
and
the
user,
facing
terms,
or
at
least
some
type
of
distinction,
and
specifically
how
we
talk
about
it.
B
F
My
biggest
question
I
had
when
reading
the
issue
was:
where
are
we
talking
about
specifically
in
which
names
cuz
yeah
to
your
point,
things
they're
gonna,
be
super
high
level,
marketing
market
extra
documents
versus
low
level,
technical
documentation
and
everywhere
in
between
I
think
we
can
take
different
levels
of
granularity
depending
on
the
depth.
But
I
wasn't
quite
clear
about
what
this
issue
was
talking
about.
Specifically
gotcha.
C
I
100%
seat
you're,
saying
on
that.
I
will
rephrase
the
description
and
make
it
concrete
about
what
I'm
talking
about.
I
could
say
it
right
now.
The
the
concrete
aspect
that
really
got
me
thinking
about
it
is
so
been
working
with
if
jenia
on
the
schema
and
everything
but
I've
talked
to
Mike
about
also
using
coverage
based
features
and
API
fuzzing
and
potentially
in
the
future
for
doing
unit
test
drive
stuff.
It
also
uses
coverage
base
stuff.
E
Here
so
when
you
go
to
their
like
home
page,
they
call
it
support
for
coverage
guide
in
fuzzing
and
I
use.
I
use
the
same
term,
so
I
can't
I
mean
I
can
say
this
is
an
industry
standard,
because
there
is
only
one
example
of
it
and
fuzz
it
right,
but
like
that,
this
is
a
like.
I
saw
people,
people
you
use
it
for,
for,
like
clip
buzzer
a
fellow
fuzz
like
coverage,
guys
are
fuzzing
and
other
one
API,
fuzzing
or
behavior
fuzzing.
It
I
think
it
makes
sense.
C
F
When
I
think
also
what
we
can
do
here
since
we're
just
getting
started,
we
can
see
if
the
naming
does
introduce
confusion
or
users
understand
it,
picking
a
name.
You
know
if
there's
a
famous
Shakespeare
quote
about
it.
So
if
we
find
it's
introducing
confusion,
maybe
we
should
investigate
changing
it,
but
we
also
I
think
whatever
we
pick,
there's
going
to
be
uncertainty,
whether
we
change
it
or
continue
to
use
the
same
sorts
of
terms.
E
Yeah
and
anyway,
I
think
we'll
have
to
do
a
lot
of
Education.
Just
like
Mike
said
you
know,
people
are
not
aware,
like
just
asking
yeah.
Is
this
a
fellow
here
I
heard
about
AFL
like
it
will
have
to
make
education
about
like
what?
What
fuzzing
is?
What
tools
are
available
when
to
use
which
tool
anyway,
so
we'll
have
to
make
a
policy
education
about
what
terms.
A
Think
where
the
technical
accuracy
is
really
important
is
things
like
our
CLI.
If
we're
calling
it
CoV
Phi's
and
we
start
using
other
fuzzing
technologies
in
there,
I
think
that's
where
we
really
need
to
make
sure
that
the
adjectives
we're
using
are
correct,
I
think
at
a
marketing.
Sometimes
we
can
have
higher-level
buckets
that
you
know
there's
a
little
bit
crossover
and
they
don't
quite
clearly
line
up
with
a
technical,
but
definitely
when
we
start
getting
into
the
implementation
I
think
we've
got
to
make
sure
that
it's
it's
accurate
there
I.
F
F
It
is
a
good
point,
though,
about
if
there
are
terms
like
continuous
fuzzing
or
similar,
that
we
should
investigate
happy
to
discuss
that
with
marketing
if
they're
or
if
there's
any
other
terms,
you
all
think
we
should
be
think
we
should
be
tracking
and
honing.
You
know,
let's
talk
about
those
two
yeah.
E
E
Of
marketing
it
might,
it
might
be
well,
it
might
be
useful
to
consider
continuous
fuzzing
as
asset
Erin,
at
least
from
like
s
SEO
perspective,
so
like
when
you
write
continuous
pausing
on
Google
I.
Think
the
first
one
is
a
strange
blog.
The
second
one
is
OSS
funds
and
the
third
one
is
positive,
so
cause
it
has
a
good
like
rating
there
and
can
make
it
also
get
one
with
the
other.
A
A
Alright,
the
next
item
I
had
was
just
a
JSON
fuzzing
report.
So
there's
an
M
R,
that's
opened
up
on
the
schema
and
there's
been
some
discussion,
I
think
on
this
issue
and
I
think
there
may
be,
or
this
M,
R
and
I
think
there's
another
M,
R
or
issue
that's
associated
with
this
type
of
topic,
which
is
what
is
the
results
going
to
look
like
coming
out
of
the
coverage
guided
tool
right
now
and
then
what
are
the
results
going
to
look
like
coming
out
of
the
API
fuzzing
tool?
A
So
my
plan
was
to
try
to
set
up
sometime
later
this
week
so
that
we
can
talk
about
this
and
brainstorm
as
to
what
our
first
MVC
version
of
this
JSON
game.
It
should
look
like
and
I'll,
also
see
if
we
can
align
the
direction
that
we
want
to
go.
Whether
we
want
to
tend
to
have
make
that
look
very
similar
to
our
other
vulnerability
schema,
whether
it
should
look
completely
different,
whether
the
API
and
the
coverage
guided
are
going
to
look
the
same
and
use
the
same.
E
Yeah,
just
just
just
an
update,
so
I'm
working
on
the
I'm,
also
working
on
the
verge
request
of
adding
support
for
like
for
this
new
type
of
report
and
get
love
CIE
llamo,
which
is
the
coverage
fuzzing
report,
as
well
as
the
parsers.
The
coverage
funding
parsers,
which
essentially
is
a
inheriting
from
a
common
security
parser
in
the
rails.
E
So
this
is
this
is
a
week
report
we
can
feel
free
to
to
comment
on
it,
but
it's
still
not
ready,
I'm,
still
playing
with
it
and
trying
to
make
it
work
with
with
the
club
car
files,
so
get
locked
up.
Files
will
output
the
correct
report
and
then
I'll
check
that
the
backend
parses
this
report
correctly
so.
A
Perfect
and
I
think
in
one
of
these
issues,
I
added
a
link
to
I
think
it
was
a
secret
detection,
I
just
added
a
new
report,
type
I,
don't
know
if
you
saw
that
merge
request
from
secret
detection.
It
should
be
very
similar
in
terms
of
good
that
needs
to
get
rid
of
that's
yeah,
I,
think
I,
think
I
thought:
okay,
perfect,
excellent.
F
So
I
will
finish
typing
this
after
coat
closet,
I
put
it
on
slack
yesterday,
but
I
wanted
to
share
with
the
broader
group.
We
have
the
customer
advisory
board
coming
up
on
the
1st
of
July,
and
so
this
is
really
our
to
interface
directly
with
a
handful
of
customers,
there's
usually
about
a
dozen
or
so
of
our
our
larger
ultimate
and
premium
customers
there.
F
What
I
would
like
us
to
do
for
that
is
actually
to
put
a
small
demo
of
what
we
can
for
fuzz
testing
together,
to
be
able
to
show
that
so
it
would
be
something
that
wouldn't
have
to
necessarily
be
polished,
and
it
would
be
run
by
someone
from
gitlab,
most
likely
David.
So
we
wouldn't
have
to
you
know,
be
worried
about
users
doing
anything
wonky
with
it,
but
yeah
I
just
wanted
to
talk
about
that.
I.
Think.
If
set
the
link
you
put
there
for
the
demo
project.
F
E
So
the
damage
I
sure
so
that
more
than
I
showed
I
think
it
can
be
run
by
essentially
by
anyone
like
by
day
by
David
or
anyone
and
so
I
didn't
know,
if
maybe
yeah,
but
maybe
by
July.
Also
we'll
have
like
a
next
version
of
the
demo
with
the
support
of
the
new
coverage
report
which
I'm
working
on
now,
but
it
will
be
only
available
on
local
versions
either.
I'll
have
to
run
this
or
like
David
will
have
to
set
up
like
local
version
and
check.
B
E
A
Yeah
I
mean
certainly
for
our
13
release,
we'll
have
it
I'd
like
to
get
a
demo
of
all
the
functionality
that
goes
to
the
documentation,
shows
the
setup
so
that'll
certainly
be
there.
I,
don't
know
whether
for
July
1
we'll
have
that
ready
to
go
we'll
have
to
kind
of
see
how
things
go
the
next
week
or
two
yeah.
F
A
E
F
A
little
both
so
generally,
the
way
that
it's
approached
is
there's
an
overall
company
update
in
terms
of
general
product
strategy.
Then
there's
a
specific
area
that
gets
highlighted
each
time.
The
group
meets
this
time,
its
security
and
so
we'll
go
through
the
presentations
go
through
a
demo
of
what
we're
working
on
and
then
it's
open
for
feedback,
but
that
feedback
can
be
about
anything.
So
it's
either
on
the
demos
or
on
any
of
the
general
company
stuff
as
well.
C
It's
related
to
our
work
on
fuzzy
I
am
putting
together
two
different
brown
bags.
I
didn't
finish
typing
up
the
second
one
on
copy
paste,
this
one
of
them
on
dogfooding
fuzzing
with
get
lab
the
product,
and
so
the
get
lab
run
or
one
should.
It
goes
to
set
things
up
so
that
when
the
NB
c--
that
you've
Jenny
is
working
on
is
ready,
we
should
be
able
to
use
that
directly
with
Gala
Brunner,
so
doing
research
and
getting
that
going
and
then
fuzzy
and
get
lab
CID
animal.
C
It's
a
different
use
case,
but
working
through
the
specifics
of
fuzzing
things
within
a
major
project
would
be
good
to
show
people.
I
may
add
a
third
item
of
dog
fooding,
but
I
don't
know
if
I'll
get
to
it
and
this
other
one
is
about
wolf
unit
test
drives
coverage
base.
Fuzzing
was
Python
Ruby
and
go
that's
an
extension
of
the
PI
test.
C
Auto
Explorer
work
that
I
did
about
cleaning
things
up
and
making
it
work
on
Python
Ruby
and
go
I,
haven't
scheduled
them
yet
the
first
one
I
I'm
thinking
I'll
schedule
it
for
next
week
and
this
one
either
end
of
next
week
or
the
week
after
that,
yeah
anyways
figured
I'd.
Let
you
guys
know:
yeah
I
will
definitely
drop
a
message
in
the
channel
of
once
they're
scheduled,
oh
and
they
are
recorded
too
so
yeah.