►
From YouTube: GitLab 13 6 Release Kickoff - Fuzz Testing
Description
Sam Kerr discusses the upcoming Fuzz Testing capabilities GitLab is focusing on with 13.6.
Planning board Sam reviewed is at https://gitlab.com/groups/gitlab-org/-/boards/1655608?&label_name[]=group%3A%3Afuzz%20testing
Fuzz Testing Direction page is at https://about.gitlab.com/direction/secure/fuzz-testing/fuzz-testing/
A
So
one
thing
I
want
to
point
out
at
gitlab
we
plan
ambitiously,
which
means
that
some
of
the
items
I'm
going
to
go
through
with
you
today
will
not
be
completed
in
13.6,
but
this
is
our
list
of
priorities
and
things
we're
going
to
be
working
on.
So
I
want
to
highlight
each
of
them
to
you
and
so
with
that,
let's
jump
in
I'm
sharing
my
screen.
Our
public
issue
planning
boards.
So
you
can
go
and
view
this
yourself.
A
If
you
would
like
to
follow
along
at
home-
and
you
can
see,
we've
got
a
lot
of
stuff
in
this
release.
We've
got
12
issues,
and
so
I'm
not
going
to
go
into
each
individual
issue,
but
I
do
want
to
point
out
a
few
things
and
highlight
a
few
themes
that
we're
focused
on
and
one
of
those
themes
is
really.
We
want
to
give
you
as
a
fuzzing
user,
more
value
from
the
gitlab
fuzzing
and
value
out
of
using
gitlab.
A
As
the
platform
that
you're
doing
your
fuzz
testing
on
to
this
end,
the
first
two
issues
are
all
about
making
the
results
of
fuzz
testing
and
crash
results.
Human
readable,
depending
on
the
languages
that
you're
using
fuzz
testing
results,
will
now
be
annotated
with
the
file
name
and
the
line
number
that
a
crash
occurred
at
rather
than
just
a
hex
address.
A
Additionally,
we're
focused
on
what
we're
calling
continuous
fuzz
testing
and
doing
our
first
iteration
our
first
release
of
this
capability,
and
what
continuous
fuzz
testing
is.
Is
it's
a
different
way
of
running
your
coverage?
Guided
fuzz
testing?
You
might
be
familiar
with
gitlab's
current
approach
to
coverage
guide,
festus
and
where
it
runs
inside
of
your
pipeline
for
approximately
10
minutes
or
so,
which
is
great
because
it
means
you
get
fuzzy
on
every
single
commit.
But
what
if
you
wanted
to
test
your
code?
A
24
7.,
the
fuzz
testing
engines,
get
better
the
longer
that
you
run
them,
because
they're
able
to
try
more
things,
find
more
parts
of
your
app
and
currently
there's
a
bit
of
a
friction
point
between.
Do
you
want
the
developers
pipeline
to
complete
quickly,
which
is
that
10
minutes-
or
so
I
mentioned
before?
Or
do
you
want
to
run
the
fuzz
testing
forever,
so
they
can
find
as
many
bugs
as
possible.
A
For
example,
if
your
application
is
testing
say
an
audio
interface,
the
fuzzer
needs
to
be
generating
audio
files
designed
to
find
bugs
and
vulnerabilities.
The
corpus
is
what
is
used
to
inform
the
fuzzer.
That
says
this
is
an
example
of
a
known
good
audio
file.
Do
your
mutations
on
top
of
this,
because
otherwise,
if
the
buzzer
is
just
making
completely
random
files
from
scratch,
it's
going
to
take
a
long
time
until
it
starts
to
generate
something
that
looks
even
close
to
an
audio
file.
A
A
Okay,
great,
so
what
I'm
sharing
now?
This
is
the
prototype
for
the
fuzzing
corpus
management
that
we're
building
right
now,
and
you
can
see
I'm
on
a
security
configuration
screen
that
you
would
get
to
by
clicking
on
the
configuration
button
on
the
left
side
of
your
browser
in
gitlab.
So
you'll
start
to
see
a
new
coverage
guided
fuzz
testing
option
in
here
and
if
you
click
manage
one
of
the
options
that
you'll
get
is
what
we
call
corpus
management.
A
You'll,
take
one
of
these
corpus
objects
and
say
in
your
pipeline.
I
want
to
use
this
specific
corpus
object.
For
example,
maybe
the
the
first
entry
in
this
list
is
all
about
audio
files
like
we
talked
about.
Maybe
the
second
entry
is
all
about
pdf
files,
and
so
this
lets
you
really
configure,
whichever
type
of
corpus
that
you
need
for
your
application.
You
can
access
it
here.
A
This
is
great
because
this
means
that
you
don't
have
to
commit
those
corpus
files
directly
to
your
git
repository
anymore,
like
you
did
previously,
which
we
know
can
cause
the
size
of
your
repro
to
grow.
It
means
you
have
to
do
merge,
requests
and
commits
to
the
repo,
which
might
be
a
point
of
friction,
and
so
corpus
management
we
feel,
is
a
really
great
way
to
the
corpus.
Management
registry
is
a
great
way
to
get
around
some
of
those
pain
points.
A
Also
in
this
screen,
you
can
see
how
large
the
various
corpus
files
are.
So
this
helps
you
manage
your
storage
inside
of
git
lab.
You
can
download
them
locally
if
you'd
like
you
can
delete
them.
If
you
don't
want
those
files
anymore,
you
want
to
free
up
storage
or
you
could
add
a
new
corpus
and
our
first
approach
with
this,
we
think,
is
really
simple
and
it's
also
really
elegant.
A
And
what
we're
going
to
do
here
when
you
want
to
add
a
new
corpus.
You
just
upload
a
zip
file
with
all
of
the
relevant
files
that
need
to
go
inside
of
your
corpus
and
that's
it,
and
so
again
this
was
a
design
prototype
of
what
we're
working
on
building
right
now
and
we're
really
excited
to
be
bringing
this
to
you
in
a
few
iterations.
A
A
A
We
know
that
the
docker
and
docker
deployment
model
is
troublesome
for
some
use
cases,
so
we
want
to
be
able
to
provide
you
the
option
to
not
use
it
if
you
so
choose,
also
we're
going
to
be
adding
support
for
the
latest
version
of
the
open
api
specification
version
three,
so
that
whether
your
open
api
or
your
swagger
file
is
in
version
two
or
version
three.
You
can
easily
use
git
labs,
fuzz,
api,
fuzz
testing
out
of
the
box.
A
One
of
the
other
things
git
lab
is
all
about.
Is
dog
fooding
and
we're
really
looking
forward
to
working
on
dog
fooding
get
lab's
own
code
using
gitlab's
own
api,
fuzz
testing,
and
so
we're
going
to
be
working
on
applying
the
api
fuzz
testing
engines
directly
to
all
the
various
apis
that
our
git
lab
application
itself
exposes.
A
We
had
a
great
experience
when
we
did
this
with
coverage
guide,
fest
testing.
We
found
some
things
that
we
fixed
and
so
we're
looking
forward
to
finding
again
some
more
things
that
we
can
fix
after
we're
in
the
api,
fuzz
tester
and
then
a
couple
other
items
on
here,
I'll
skip
through
most
of
them,
but
one
thing
I
do
want
to
highlight
is
we're
also
starting
to
think
about.
A
If
there
is
not
a
language
that
you
write,
your
application
in
that
you'd
be
interested
in
fuzzing
we'd
love
to
hear
that
feedback,
because
that's
what
helps
us
prioritize
and
make
sure
we're
focusing
on
the
right
things,
and
so
with
that
that
is
our
high
level
plan
for
13.6
again
at
gitlab.
We
plan
ambitiously.
So
these
are
the
things
we're
focusing
on,
but
we're
not
positive.
All
of
them
are
going
to
be
delivered
in
this
coming
iteration
we
release
on
the
22nd
of
every
month.
A
So
if
you
come
back
on
november,
22nd
you'll
get
to
see
which
of
these
got
shipped
as
part
of
gitlab
13.6,
again
we'd
love
to
hear
your
feedback,
whether
it's
good,
bad
or
ugly,
about
fuzz
testing
it.
It's
great
starts
a
good
conversation
and
it
helps
make
sure
we're
building
the
right
things
for
you
as
the
the
user.