►
Description
Secure Stage Direction - https://about.gitlab.com/direction/secure/
* SAST Direction - https://about.gitlab.com/direction/secure/static-analysis/sast/
* Secret Detection Direction - https://about.gitlab.com/direction/secure/static-analysis/secret-detection/
* DAST Direction - https://about.gitlab.com/direction/secure/dynamic-analysis/dast/
* Dependency Scanning Direction - https://about.gitlab.com/direction/secure/composition-analysis/dependency-scanning/
* Fuzz Testing Direction - https://about.gitlab.com/direction/secure/fuzz-testing/fuzz-testing/
* Vulnerability Database Direction - https://about.gitlab.com/direction/secure/vulnerability-research/vulnerability-database/
* Vulnerability Management Direction - https://about.gitlab.com/direction/secure/vulnerability_management/
* Security Orchestration Direction - https://about.gitlab.com/direction/protect/security_orchestration/
A
Hello,
everyone
and
welcome
to
our
quarterly
secure
stage,
review
stage
strategy
review
to
be
specific.
I'm
dave
desanto,
most
of
you
know
me
already,
but
if
you're
not
with
the
company
you're
watching
our
video,
I'm
responsible
for
our
debt
section
and
our
sex
section
so
covering
our
development
focus
features
as
well
as
our
security
focus
features
at
a
high
level
for
the
stage.
A
We
continue
to
be
making
progress
towards
our
three-year
stage
themes
and
through
your
strategy,
a
couple
of
things
worth
highlighting
since
the
last
time
we
met
das
has
moved
to
being
able
to
run
within
production,
so
this
is
actually
being
able
to
run
a
dashed,
on-demand
scan.
I'm
sure
derrick
will
touch
on
that
in
more
detail,
but
that's
something
that
recently
was
completed.
A
The
primary
item
I
wanted
to
highlight
for
all
of
you
is
changes
in
our
target
audience.
So
today
we've
been
able
to
move
both
our
qa
support
and
our
security
consultant
support
forward.
We
believe
we're
now
a
strong
map
to
what
qa
teams
need
with
regard
to
security
testing,
as
well
as
we're
now
able
to
begin
to
support
our
customers,
who
are
security,
consultants
who
are
using
gitlab
as
a
way
to
manage
code,
they're
writing
for
their
customers
and
then
scanning
those
for
security
vulnerabilities
as
well.
A
We're
also
introducing
a
new
target
audience
being
compliance
specialists
and
managers,
and
with
that
today
we
see
that
on
our
plans
and
the
team
will
talk
about
those
but
they're.
Not
we're
not
strongly
mapped
to
that.
Yet,
however,
over
the
next
medium
terms
for
the
next
year
to
two
years,
we
definitely
see
us
getting
to
being
a
strong
map
for
secops,
as
well
as
getting
to
a
good
sport
level
for
compliance
related
customers
on
the
overall
strategy
for
the
stage
and
our
maturity.
A
A
B
All
right
so
I'll
start
off
with
a
couple
of
things
that
I'm
really
excited
about
that
recently
released.
So
the
first
is
creating
jira
issues
from
vulnerabilities,
so
this
is
something
we
added
in
13.9
and
was
actually,
I
think
for
me-
was
the
highest
customer
requested
feature
in
my
particular
area.
So
what's
really
exciting
about
this?
Is
it's
the
first
place
inside
of
git
lab
where
you
can
actually
create
a
jira
issue
directly
from
our
interface,
simply
enable
it
at
a
project
level
say
you
want
to
create
your
issues.
B
The
other
thing
that
I
am
really
excited
about
that
we
released
is
an
activity
filter,
so
the
activity
filter
lets
you
select
any
vulnerability
records
that,
let's
say,
have
had
an
issue
created
or
perhaps,
more
importantly,
are
no
longer
detected
in
subsequent
scans.
So
this
lets
you
drill
in
very
quickly
to
things
that
I
might
be
able
to-
let's
say,
bulk
dismiss
or,
as
of
a
few
days
ago,
bulk
change
status
to
resolve
for
issues
that
are
no
longer
detected
in
scan.
B
So
coming
up,
it
was
hard
to
narrow
this
list
down.
We
have
a
lot
of
exciting
things,
but
first
I'm
going
to
start
with
the
generic
security
report
schema.
This
has
been
in
flight
for
a
while,
but
really
the
goal
of
this
is
to
provide
a
single
way
to
integrate
virtually
any
scanning
tool
or
any
security
tool
into
the
pipeline
and
have
those
results
appear
in
the
vulnerability
management
workflow.
B
B
Now
this
is
going
to
be
a
long
process
and
we
have
four
steps
defined,
which
will
probably
take
us
through
the
rest
of
the
year,
but
the
first
is
adding
some
additional
messaging
inside,
mostly
around
error,
handling,
to
help
make
things
more
clear.
What
has
actually
occurred
during
a
particular
pipeline
run.
B
So
we're
going
to
look
to
add
more
visualization
capabilities
there.
One
of
the
things
that
we're
going
to
focus
on
first
is
something
to
help.
You
assess
how
am
I
doing
in
terms
of
my
timing,
my
remediations,
so
this
is
a
basic
sla
visualization,
which
shows
you
aging
of
vulnerabilities
over
time,
so
you
can
quickly
and
easily
through
these
two
changeable
views,
see,
for
instance,
let's
say
I
have
an
sla
of
15
days
on
criticals.
Do
I
have
anything
that's
aged
out
of
that,
so
this
is
going
to
be
a
big
benefit
for
anyone.
C
Thanks
matt,
so
for
the
security
orchestration
category,
this
one
actually
is
under
protect,
but
this
is
a
category
that
spans
across
gitlab,
so
we're
addressing
security,
alert
management
and
security
policy
management
again
across
all
of
gitlab,
not
just
protect.
We
just
barely
released
security
alert
management
in
13.9
and
we
have
policy
management
on
the
roadmap.
So
I'm
going
to
be
walking
us
through
what
we
just
came
out
with
and
what's
coming
in
the
next
three
to
six
months,
so
security
alert
management.
We
just
barely
released
a
new
alert
dashboard.
C
It's
here
under
security
and
compliance
threat,
monitoring,
and
you
can
set
this
up
with
your
policies
using
container
network
policies.
You
can
configure
the
rules
that
generate
an
alert.
Those
can
then
show
up
here
on
the
alert
dashboard.
You
can
change
the
status
and
you
can
click
into
these
to
get
all
of
the
details
for
what
actually
happened
on
the
roadmap,
we're
working
to
bring
policy
management
across
secure
and
protect,
and
this
involves
managing
when
scans
actually
get
run.
We're
addressing
this
in
true,
get
lab
style
and
a
very
iterative
approach.
So
we
have
outlined.
C
You
know
multi-step
plan
where
we
get
some
initial
value
out
to
users
and
improve
on
that
experience
over
time,
just
to
share
what
we
plan
this,
to
look
like
in
the
first
iteration
we're
planning
to
allow
you
to
link
to
a
separate
security
policy
project
which
will
contain
a
yaml
file
that
will
define
those
policies
soon
afterwards.
We
want
to
bring
a
ui
to
that
experience,
so
we're
going
to
let
you
view
a
list
of
your
policies
and
edit
those
policies
here
in
the
ui
and
to
do
that.
C
You'll
get
an
experience
that
looks
something
like
this,
where
you
can
go
in
and
actually
edit
the
yaml
here
in
the
ui
which,
without
having
to
worry
about
managing
that
separate
project
down
the
road.
Even
further,
we
plan
to
bring
a
nice
rule,
editor
option
to
that.
So
you
can
either
work
in
rule
mode
or
yaml
mode,
and
so
you
can
actually
schedule
those
scans
to
run
at
a
certain
interval
or
require
them
to
run
during
the
pipeline.
C
One
key
differentiator
of
this
versus
just
running
scans
through
the
current
gitlab
ci
dot
yaml
file
is
that
we're
providing
for
separation
of
duties
where
a
security
team
can
enforce
these
scans
and
require
them
to
be
run
in
a
way.
That's
not
editable
or
able
to
be
disabled
by
the
developers
on
the
project,
we're
actively
collecting
feedback
in
this
area.
So
if
you
have
users
with
ideas
or
input
in
this
area,
we
would
love
to
talk
to
them
and
with
that
I'll
turn
it
over
to
taylor.
D
So
the
first
thing
I
want
to
share
is
that
we
now
support
the
security
and
configuration
page
for
all
users,
allowing
any
gitlab
user
to
understand
what
security
tools
they
have
access
to
and
to
easily
be
able
to
enable
sas
to
via
a
button,
click
we'll
also
be
supporting
secret
detection
enablement
via
a
button
in
an
upcoming
release.
This
is
part
of
our
usability
theme
and
adds
to
our
mr
security
widget
improvements
for
core
users,
making
it
easy
for
core
users
to
access
the
json
security
reports
directly
from
the
mr
together.
D
These
features
make
it
easier
for
any
user
to
get
value
from
our
free
sas
and
secret
detection
tools.
Next,
I
want
to
touch
briefly
on
a
number
of
different
features
that
we've
recently
released.
We've
been
pushing
updates
to
many
of
our
sas
analyzers
to
support
more
types
of
project
configurations
like
multi-projects
and
mono
project
support
across
many
of
our
analyzers.
We
now
support
net
five:
we've
expanded
our
ruby
scanning,
we've
added
additional
severity
data
to
our
javascript,
ruby
and
c
and
c
plus
scanners,
as
well
as
node.js.
D
C
D
Open
up
a
consistent
method
for
writing
rules
across
analyzers.
This
will
also
provide
a
nice
option
for
languages
that
we
don't
support.
You'll,
be
able
to
write
custom
rules
within
semgrep
for
arbitrary
languages
as
well,
and
then,
finally,
with
git
lab
focused
on
ast
leadership,
we're
working
on
multiple
efforts
to
increase
our
accuracy
rates
in
false
positive
and
reduce
false
positives.
This
again
is
that
work
between
sas
and
vulnerability.
Research
that
I'm
really
excited
about.
D
E
Currently,
for
the
past
few
months,
we've
been
continuing
our
work
on
getting
to
the
complete
state
of
maturity,
which
involves
working
on
automatic
remediation
and
I'll.
Show
you
some
of
those
designs,
we're
working
to
add
paths,
information
into
our
dependencies
when
you're
looking
at
them
improving,
merge,
request
approval
setup
process
for
the
vulnerabilities,
as
well
as
the
license
rule
sets,
and
that
you
can
see
right
here.
The
things
that
are
coming
up
is
going
to
be
doing
dependency
scanning,
enabled
via
click
which
we're
borrowing
from
taylor.
E
6,
I'm
going
to
be
publishing
a
blog
post
about
this
that
we
have
consistent
behavior
between
all
the
ast
scanners,
about
what
does
a
failure
within
the
pipeline
mean,
and
we've
seen
some
user
confusion
over
this.
So
I'm
like
really
excited
to
bring
consistency
across
the
scanners
for
users
here.
So,
as
you
can
see,
most
of
our
stuff
has
just
been
around
adoption
through
usability
and
that's,
focusing
on
addressing
bugs
making
things
work
smoothly,
making
things
easier
to
understand
and
consistency
between
all
of
the
products
so
now
I'll
hand
it
over
to.
E
F
So
one
of
the
big
things
that
we
added
was
the
ability
to
validate
your
sites
so
that
you
can
run
active
scans
against
them.
So
you
can
see
whether
the
validation
has
failed
or
succeeded.
You
can
retry
validation
or
revoke
it,
and
that
works
in
a
concert
with
the
active
mode
so
that
when
you
go
into
your
scans,
you
can
see
that
the
scan
mode
is
active
and
the
target
url
it
won't.
Let
you
run
the
scan
if
you
have
not
validated
that
website.
F
This
also
shows
something
new
that
we
added
where
you're
able
to
save
the
on-demand
das
scans.
This
allows
you
to
create
your
configuration
once
rather
than
having
to
recreate
it
every
single
time.
So
when
you
go
into
manage
your
dash
scans,
all
you
have
to
do.
Is
click
run
scan
and
it
will
automatically
go
through.
All
of
the
steps
that
you've
already
configured
for
that
scan,
this
should
make
it
a
lot
more
quick
to
run
these
scans
and
to
to
get
the
results
that
you're,
looking
for
so
going
into
what
we
are
planning
on
doing.
F
One
of
the
big
things
that
I
am
excited
for
is
the
fact
that
we're
going
to
be
aggregating
some
of
these
incredibly
noisy
das
vulnerability
scans
into
a
single
vulnerability.
Previously
we
would
report
possibly
hundreds
or
even
thousands
of
these,
depending
on
how
many
pages
you
had
or
urls
you
had
on
your
website.
What
we're
going
to
be
doing
is
aggregating
all
of
these
into
a
single
vulnerability
and
show
you
how
many
places
on
your
site
that
vulnerability
was
found.
F
That's
going
to
help
a
lot
with
the
dashboard
and
vulnerability
reports,
then
we're
going
to
be
adding
the
remaining
options
that
are
missing
from
the
das
site
profile.
These
include
the
website
or
api
selection,
authentication,
request,
headers
and
excluded
urls
to
finish
off
the
on-demand
configuration
and
really
release
our
on-demand
scans
as
a
full.
Ga
all
right-
and
the
last
thing
that
I'm
very
excited
about-
is
we're
working
on
a
few
new
scanners
and
crawlers
for
dast.
So
the
big
two
that
we're
working
on
are
browser
and
peach.
G
So
right
now
I'm
sharing
the
category
direction
page
for
fuzz
testing.
We
have
a
lot
of
great
information
on
here.
Would
love
for
you
to
check
it
out,
provide
your
feedback,
but
really
I
want
to
jump
to
a
couple
sections
to
go
through
with
you,
starting
with
some
recent
highlights
of
things
that
we
are
excited
to
have
shipped
in
the
past
few
releases
and
the
first
one
of
those
is
that
we've
added
additional
language
support
for
coverage
guided
fuzz
testing.
G
We
know
that
our
users
develop
applications
in
many
different
languages
and
being
able
to
do
fuzz
testing
of
all
the
code
inside
of
the
application,
whether
it's
in
c
javascript,
python,
whatever
language,
is
really
important
to
help
finding
those
bugs
and
vulnerabilities
that
other
tools
are
going
to
miss
another
area.
We
recently
enhanced
our
api
fuzz
testing.
Is
we
integrated
the
results
directly
into
the
security
dashboard
if
you're
familiar
with
what
our
first
iteration
looked
like?
G
The
security
results
were
in
the
test
tab
inside
of
a
pipeline
using
our
junit
output,
and
this
was
great
as
a
first
iteration
to
show
you
those
security
results,
but
api
fuzz
testing
now
is
fully
integrated,
just
like
any
other
gitlab
scanner
would.
So,
if
you
look
in
the
pipeline
security
tab,
the
merge
request,
widget
or
the
security
dashboard
you'll
see
those
api.
Fuzz
testing
results
and
the
last
area
I'd
like
to
highlight
is
again
around
api
fuzz
testing
and
it
says
first
delivery
of
api
first
testing.
G
But
what
I
want
to
emphasize
here
is
that
we've
really
been
doing
a
lot
to
enhance
api
fuzz
testing
from
our
first
release.
We
released
this
in
13.4
and
we've
continued
to
iteratively,
improve
it
release
after
release
since
making
it
better
for
you.
One
of
the
main
areas
I'd
like
to
highlight
is
that
we
added
postman
collection
support.
So
if
you
had
an
open
api
file
or
a
har
file,
you
can
also
now
use
a
postman
file
to
fuzz
your
apis,
and
those
are
three
of
the
things
that
we
recently
released.
G
That
I
think
you'll
be
excited
to
check
out.
If
you
want
to
know
more
about
where
we're
headed,
we
have
a
lot
more
information
here
and
I'll
highlight
my
top
three
that
I
think
you'll
be
really
excited
to
see
and
the
first
one
of
those
is
allowing
our
coverage
guide.
Fuzzing
users
to
manage
corpus
objects
much
more
easily
than
they
can
today.
G
G
G
And
again
you
can
click
the
link
there
to
check
out
what
we're
doing,
but
we're
going
to
be
providing
a
graphical
user
interface
that
will
help
guide
you
through
that
initial
configuration
that
initial
setup
and
when
you're
done
entering
all
the
data
that
you
need
to
enter
you're
going
to
be
given
a
code
snippet
that
you
can
just
directly
copy
and
paste
into
your
gitlab
cimo
file.
This
means
you
won't
have
to
reference
the
documentation
as
much.
You
won't
have
to
do
debugging
of
a
yaml
file.
G
This
is
really
exciting,
not
just
for
gitlab,
not
just
for
you,
but
for
the
open
source
community
as
a
whole.
This
is
going
to
be
releasing
technology,
that's
not
been
available
in
the
open
source
world
really
ever
up
to
this
point,
it's
really
going
to
help
advance
the
state
of
the
industry
and
get
lab
is
really
excited
that
we're
going
to
be
able
to
do
this
and
work
with
you
in
the
open
source
community
on
it.
G
A
I
would
be
remiss
if
I
didn't
say,
like
you
know,
click
on
the
subscribe
video
if
you're
watching
this.
If
you
are
currently
not
following
all
of
our
videos,
the
secure
stage
produces
a
lot
of
videos
per
week.
So
please
do
that
and
just
a
last
final
call
out.
I
think
taylor
would
also
like
to
see
you
hit
the
like
button
if
you're
liking
the
video
as
well.
I've
never
pointed
so.