►
From YouTube: GitLab 13.4 Kickoff - Secure & Defend Stage
Description
Stage Kickoff for 13.4!
Secure:Static Analysis
Secure:Dynamic Analysis
Secure:Composition Analysis
Secure:Fuzz Testing
Secure:Threat Insights
Secure:Vulnerability Research
Defend:Container Security
Direction Page: https://about.gitlab.com/direction/secure/ and https://about.gitlab.com/direction/defend/
Planning Issues:
Secure:Composition Analysis: https://gitlab.com/gitlab-org/secure/general/-/issues/98
Secure:Static Analysis: https://gitlab.com/gitlab-org/gitlab/-/issues/235103
A
Hello,
everyone
and
welcome
to
the
secure
and
defend
section
kickoff
we're
going
to
try
things
a
little
bit
differently
than
usual
and
we're
going
to
walk
you
through.
Just
our
high
level
themes,
you'll
get
a
chance
to
hear
from
all
the
pms
in
the
team
and
from
there
we
will
then
wrap
up
to
kind
of
get
us
started.
A
There
are
some
really
great
things
that
happen,
since
our
last
call
buzz
testing
has
moved
to
minimum
maturity,
and
you
can
now
see
that
up
in
the
list
of
items
coming
same
thing
with
our
container
host
security,
both
those
things
are
now
available.
Fuzzygun.Com
and
both
will
be
available
with
the
self-hosted.
A
A
The
stage
for
secure
we've
set
some
strategic
objectives,
those
include
supporting
offline
environments
and
we
shipped
our
minimal
mvc
of
that
back
in
1210,
and
that's
really
critical,
because
our
customers
predominantly
end
up
being
in
offline
environments
being
security-minded
people
and
with
that
gitlab
really
gets
into
a
position
where
we
can
support
them,
because
it's
not
common
across
the
entire
security
space.
That
products
like
ours
work
in
an
offline
environment.
A
We're
also
focused
on
providing
application
security
testing
leadership.
Our
goal
was
to
try
to
get
to
complete
maturity
and
on
categories
like
sas
fast
and
defensive
skating
by
the
end
of
the
year,
based
off
the
effort
and
the
feedback
we've
received
from
customers.
That's
looking
more
like
next
fall,
however,
we're
still
releasing
a
lot
of
really
great
things
along
the
way
and
you'll
hear
a
lot
about
that
coming
up
here
in
a
minute
and
finally,
dog
footing
is
very
important
at
get
lab.
A
If
we
can't
make
our
own
teams
happy,
we
don't
know
how
we
would
even
make
you
happy,
and
I
believe
that
it's
very
important
for
us
to
be
dog
fooding
the
secure
functionality-
and
I
can
let
you
know
that
that
started
with
our
security
team
and
they've,
been
rolling
out.
Support
for
container
scanning,
license
compliance
dependency
scanning
and
sas,
and
starting
next
month,
we're
beginning
to
roll
out
that
to
the
secure
and
defend
engineering
teams,
as
well
with
the
plan
of
rolling
out
to
the
remaining
stages
over
the
next
couple
of
quarters.
A
On
defend
again,
we've
been
able
to
ship
three
categories:
we're
making
really
great
progress
with
things
like
container
host
security
focus
on
helping
you
have
visibility,
but
also
block
attacks,
targeting
your
containers,
and
then
we
have
ueba
or
user
and
nc
behavior
analytics
coming
next
year,
and
with
that
the
strategic
themes
for
defend.
We
want
to
focus
on
usability
convention
over
configuration
and
we
actually
shipped
our
initial
policy
management
option
in
13-1.
We
have
some
really
great
things
coming
on
13-4.
A
The
second
part
of
that
is
having
visibility
first
and
protection.
Second
and
that's
what
we've
been
able
to
do
with
things
like
the
initial
shipment
of
our
container
network
security,
hostgator
is
actually
shipping
with
protection
as
an
option,
but
we
do
plan
on
giving
you
better
visibility
and
that's
gonna
come
in
the
form
of
our
alert
ui
and
then
today
you
can
see
those
logs
if
you
use
our
export
to
seam
option.
A
B
Thanks
david,
so
in
that
theme
of
emphasizing
usability
and
convention
over
configuration
first
for
thirteen,
four
we're
continuing
our
work
on
the
policy
editor,
which
will
allow
users
to
really
edit
their
their
network
policies
in
a
way
that
hasn't
been
able
to
be
done
before
so
right
now,
editing
network
policies
is
fairly
difficult.
Doing
that
in
kubernetes
gives
you
no
way
to
translate
the
gamma
configuration
into
an
english
language
sentence
describing
what
the
policy
does
and
when
you,
edit
these
network
policies,
it's
critical
to
make
sure
that
those
policies
are
configured
correctly.
B
Making
a
mistake
would
mean
either
that
attackers
could
then
potentially
have
an
access
point
into
your
cluster
or,
on
the
other
hand,
that
you
might
end
up
blocking
valid
network
traffic.
So
what
we're
attempting
to
do
here
is
create
a
new
policy
editor
ui
that
solves
these
problems,
making
it
both
easy
and
intuitive
to
edit
policies
in
this
concept,
you'll
still
be
able
to
edit
the
yaml
file
directly.
B
However,
you'll
see
that
we're
also
taking
that
one
step
further
by
giving
you
a
plain
english
sentence
that
describes
what
the
policy
does,
that
you
can
go
through
and
edit,
and
you
can
still
see
the
yaml
being
generated
automatically,
but
you
can
also
switch
it
over
into
this
rule
mode
and
again
get
a
very
clear
sentence
that
makes
it
obvious
exactly
what
that
policy
does
so
again.
Keeping
with
that
theme
working
towards
usability
and
convention
over
configuration
and
I'll
turn
it
over
to
derek
to
talk
about.
C
Dust
sorry,
my
computer
was
having
some
issues
switching
over
all
right
so
with
desks,
I'm
gonna
talk
about
a
little
bit
how
we
are
approaching
usability
and
trying
to
make
the
usability
of
configuration
for
das
scans
a
little
bit
easier
in
for
the
on-demand
scans
initially
and
then
switching
that
over
to
the
ci
cd
pipeline
scans
as
well.
So
the
first
thing
that
we
are
doing
is
to
make
the
scanner
profile
available
to
everyone.
C
So
we
are
introducing
this
in
thirteen
four
we're
going
to
be
starting
with
a
very
minimal
version
of
this
and
start
adding
fields
in
here
as
we
go
through
the
subsequent
milestones.
C
If
these
are
done
on
a
production
type
site,
they
could
actually
cause
either
data
issues
or
a
vulnerability
being
exploited
on
the
actual
production
site.
So
the
possibilities
here
would
be
meta
tag,
text,
file
or
header
validation,
and
all
of
these
will
allow
you
to
specifically
allow
a
dash
scan
on
that
site.
Otherwise
the
scan
will
actually
fail.
D
D
The
first
one
is
security
for
everyone,
and
let
me
just
share
my
screen
here:
we've
got
so
we
believe
that
security
works
best
when
it's
accessible
and
used
by
as
many
people
as
possible
directly
within
the
dev
ops
life
cycle.
As
part
of
our
commitment
to
this,
the
community
stewardship,
we
have
all
15
of
our
open
source
asset
analyzers
available
to
all
gitlab
users
on
all
editions.
This
allows
any
gitlab
user
developing
any
of
the
18
supported
languages
and
frameworks.
D
D
We
believe
that
security
is
a
team
effort,
and
this
configuration
experience
makes
it
easier
for
non-ci
experts
to
get
started
with
gitlab
sas.
This
tool
helps
create
a
merge
request
to
enable
sas
scanning,
while
leveraging
the
best
configuration
practices
like
using
gitlab,
managed
sas
ci
templates
and
properly
overriding
template
settings.
D
This
nvc
is
only
the
beginning
and
lays
the
foundation
for
us
to
introduce
new
configuration
options
like
custom
rule
sets,
which
will
be
the
focus
for
us
in
13.4.
We
also
intend
to
expand
this
guided
experience
for
our
other
security
scanning
tools
and
just
to
show
you
what
that
looks
like
here.
We've
now
got
an
easy,
enable
option
for
staffs.
D
You've
got
some
settings
to
be
able
to
control
some
of
the
individual
overrides
to
that
template,
and
then
you
can
create
a
merge
request
and
I'll
just
scroll
down
and
show
you
there's
links
to
documentation
here,
so
that
you've
got
easy
access
to
that.
And
if
I
look
at
my
changes,
you'll
see
that
we're
correctly,
including
the
templates
and
setting
the
variables
that
we
passed
through
there.
So
that's
a
quick
look
at
what
we're
working
on
and
now
I'll
hand
it
off
to
nicole
for
software
composition,
analysis.
E
Hey
so
technically,
sca
includes
your
container
scans,
your
license
compliance
as
well
as
your
dependency
scans,
but
we're
mostly
going
to
be
focusing
on
just
the
dependency
scanning
and
I'm
trying
to
share
the
correct
screen.
E
I
think
that
worked
anyway.
So
what
I'm
concentrating
on
is
that
we
have
completed
all
of
our
p1
s1,
bugs
which
I'm
super
stoked
about
and
we're
making
a
whole
bunch
of
ui
improvements,
because
since
security
is
everybody's
responsibility,
if
anybody
is
frustrated
or
thwarted
by
the
experience,
they're
not
going
to
want
to
incorporate
security
in.
E
So
what
I'm
concentrated
on
right
now
is
that
the
merge
request
approvals
right
now.
A
lot
of
people
are
having
problems,
understanding
exactly.
How
do
I
set
up
the
approver
groups
and
what
happens
so?
We've
got
a
new
flow
going
where
we're
actually
going
to
tell
you
what
branches
it
applies
to.
What
the
group
names
are
suggest
some
default
groups
and
then,
as
we
get
through
to
the
end
here,
you
can
actually
grab
some
more
information
about.
What
do
we
mean
by
this
approval
group,
and
so
it'll?
E
Explain
to
you
and
link
you
to
the
documentation
and,
of
course
we
are
improving
the
documentation
around
security
merge
request
approvals
that
workflow
how
to
enable
it.
What
happens
when
you
enable
it
if
you've
already
got
a
whole
bunch
of
branches
open
and
so
we're
hoping
that
everybody
is
just
much
more
understanding
of
how
they
can
leverage
this
to
help
protect
all
of
their
stuff
by
making
sure
that
when
you
introduce
a
vulnerability,
a
second
person
or
a
specific
group
of
people
need
to
sign
off
on
that.
F
Hi
everyone,
as
david
mentioned
earlier,
fuzz
testing,
is
one
of
gitlab's
newest
categories
that
we're
releasing
and
really
as
we're
bringing
this
out
as
part
of
gitlab.
One
of
our
key
focuses
is
making
sure
that
it's
not
only
effective
but
also
that
it's
usable.
We
feel
that
if
security
products
are
not
usable,
you
won't
get
all
the
value
out
of
them
that's
possible.
So
this
is
one
of
the
key
focuses
that
we're
really
keeping
in
mind.
F
F
We
already
support
multiple
languages
and
deployment
types
today
and
so
we're
adding
new
options
such
as
java,
as
part
of
our
upcoming
release,
to
make
sure
that
all
of
the
fuzz
testing
results
are
not
only
easy
to
add
to
your
app,
but
also
actionable.
We're
really
focused
on
making
sure
that
everything
that
fuzz
testing
finds
and
produces
is
visible
as
part
of
that
same
experience,
you're
used
to
at
gitlab
and
so
I'll
share
my
screen
and
I'll
walk
you
through
some
of
that
right
now.
F
So
what
I'm
sharing
on
my
screen
now?
This
is
a
gitlab
ci
yaml
file,
which
is
used
to
configure
your
pipelines
and
what
this
is
showing
is
fuzz
testing
is
just
like
adding
any
other
scanner
inside
of
gitlab
that
you're
already
familiar
with.
You
include
a
template
file.
You
provide
a
very
straightforward
job
definition
that
you
can
copy
out
of
our
product
documentation
and
that's
it.
That's
all.
You
need
to
do
to
add
fuzz
testing
your
project
after
that
has
been
added.
F
You'll
then
start
seeing
fuzz
testing
as
part
of
your
pipeline,
just
like
any
other
job.
If
the
fuzz
testing
finds
issues
or
bugs
or
vulnerabilities,
those
are
going
to
be
reported.
Just
like
any
other
security
vulnerability,
you
can
see
metadata.
You
can
see
a
stack
trace
and
more
information
about
the
bug,
and
you
can
also
promote
that
bug
into
an
issue
where
you
can
then
discuss
it
with
your
team,
create
merge,
request
to
close
it,
just
like
every
other
scanner
here
at
gitlab.
F
Additionally,
we're
also
going
to
be
bringing
api
or
behavioral
based
fuzz
testing
as
part
of
this
upcoming
release
and
in
a
similar
way
we're
going
to
be
surfacing
these
results
just
like
you
would
see.
Other
gitlab
test
results
as
part
of
your
pipeline.
You'll
see
a
test
tab
and
all
of
those
different
results
from
the
api
fuzzer
will
be
shown
there.
You
can
see
the
original
responses.
You
can
see
the
the
responses
where
mutation
has
happened
and
bugs
have
potentially
been
found.
G
G
G
Now
this
information
is
showing
you
what
is
in
the
default
branch
so
for
most
projects.
This
is
what
would
actually
be
in
production,
I'm
showing
you
the
staging
just
for
kind
of
an
example,
but
I
want
to
point
out
that
this
is
actually
live
on
gitlab.com
as
well.
So
if
you
remember
back
just
a
few
releases
ago,
a
lot
of
this
information
wasn't
here.
G
So
it
was
pretty
basic
and
it
made
it
harder
for
the
security
teams
to
know
what
they
needed
to
drill
into
and
when
we've
taken
a
lot
of
feedback
from
our
own
apptec
team,
which
is
actually
been
using
this
for
several
months
now
and
made
improvements
so
that
it's
easier
for
them
to
use
this
day
in
and
day
out.
So,
for
example,
it's
minor
little
things
like
the
defaults
are
now
just
the
detected
and
the
confirmed
state.
G
It's
also
telling
you
there's
more
information
available.
A
lot
of
our
scanners
produce
more
information
than
we
would
always
display
in
an
overview
like
this,
but
just
sort
of
knowing
what's
behind
it,
can
give
you
an
indication
of
hey.
I
want
to
look
at
this
a
little
bit
more
closely.
We've
also
added
other
information.
That's
a
little
bit
more
future
looking,
so
you
may
notice
that
gitlab
now
appears
for
all
these
scanners.
G
Where
did
the
scan
come
from
and
eventually
you'll
see
the
same
kind
of
thing
here,
we'll
actually
call
out
by
vendor,
as
well
as
the
scanning
technology
used,
so
you
can
drill
into
exactly
what
you
need
to
look
at
now.
This
is
a
project
level
security
dashboard.
We
also
have
something
very
similar
at
the
group
and
the
instance
level
now
for
the
group
in
the
instance
level.
There's
this
sort
of
combined
view
now
you
may
notice.
This
is
again
one
of
the
usability
questions.
G
There's
not
a
lot
of
real
estate
here
for
the
vulnerability
list
itself.
What
we're
working
on
doing
is
actually
separating
out
these
widgets,
these
metrics
components
into
a
dedicated,
an
actual
dashboard
area.
We've
taken
the
first
steps
again.
This
is
already
live
in
in
production
on
gitlab.com
before
there
was
no
left
menu
here,
so
we're
adding
a
new
left
menu
for
the
instance
level,
so
that
there's
this
is
more
of
kind
of
a
security
area.
G
If
you
will
I'll
go
ahead
and
show
some
screenshots
of
what
this
will
look
like,
but
there
will
be
a
separate
vulnerability
list,
so
you'll
notice.
These
are
the
same
two
components
for
now.
This
is
the
start
of
a
really
a
true,
dedicated
dashboard,
to
give
you
more
sort
of
fingertip
insights
about
overall
instance
and
project
health.
G
A
Thank
you,
matt
and
thanks
to
the
team
for
their
great
updates,
I
gotta
say
I'm
very
excited
about
the
things
we
have
going
on
towards
our
individual
themes
and
our
objectives.
So,
hopefully
you
enjoyed
this
video
as
we
wanted
to
try
a
new
format
as
we
wrap
up
here.
I
also
want
to
highlight
that
we
do
have
get
lab
commit
coming
up
in
a
couple
of
weeks.
If
you're
not
registered.
A
Please
do
we
had
some
really
great
updates
in
the
product
keynote
as
well
as
sampra,
and
I
are
presenting
fuzzing
and
we
actually
have
our
director
of
engineering
and
defend
our
distinguished
engineer
in
defend
and
a
customer
presenting
how
defend
fits
together
to
give
you
a
defense,
in-depth
approach.
So
again,
thank
you.
Everyone
for
attending
and
we'll
see
you
again
soon.