►
From YouTube: Secure Stage Strategy Review: 2021-09
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/dynamic-analysis/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
and
welcome
to
the
fiscal
22
q3
secure
stage
strategy
review.
My
name
is
hillary
benson
and
I'm
director
of
product
management
for
secure
and
protect.
Today
the
team's
gonna
go
and
and
share
a
number
of
updates
and
accomplishments
from
the
last
quarter
and
we'll
provide
some
highlights
of
our
work
in
q3
and
beyond
as
well.
To
start
things
off.
I
want
to
quickly
refresh
your
memory
on
the
focus
of
our
one
year
plan
insecure
and
then
we'll
move
on
to
talking
about
all
the
updates
of
the
last
quarter.
A
So
we
have
three
primary
areas
of
focus.
Ast
leadership
is
first
among
them,
as
we
touched
on
in
our
last
quarterly
review.
Gitlab
was
named
a
challenger
in
the
2021
gartner
magic
magic
quadrant
for
application
security
testing,
which
was
a
huge
boon
for
us
being
so
young
in
the
security
game
here
at
gitlab.
A
So
that's
the
overall
focus
for
our
one
year
plan
for
secure.
However,
you
want
to
touch
on
a
set
of
specific
q3
initiatives
that
you've
no
doubt
heard
about
by
now
in
various
contexts
and
that
certainly
have
bearing
on
what's
in
progress
and
what's
coming
up
for
secure,
so
product
and
development
teams
across
all
of
gitlab
have
made
the
gitlab
hosted.
First,
fiscal
22
investment
theme,
our
top
priority
for
q3
and,
as
I'm
sure,
you've
heard
elsewhere.
A
It
warrants
serious
and
you
know
concerted
focus
right
now,
so
the
implication
of
that
focus
for
secure,
as
is
the
case
for
most
product
teams
across
the
company,
is
that
our
pm
team
has
largely
but
not
entirely
shifted,
priority
away
from
new
feature
development
and
dedicated
our
engineering
resources
to
address
primarily
reliability,
scalability
performance
and
security
issues
for
the
next
few
months.
So
the
secure
pmc
day
will
highlight
what
that
focus
translates
to
for
each
of
our
groups
and
we'll
also
speak
to
some
of
the
feature
functionality
that
we
still
plan
on
delivering.
A
You
know
during
this
time
frame
but
thought
it
was
just
worth
noting
up
front
that
the
company
wide
focus
on
this
theme
for
the
quarter
is,
you
know,
certainly
a
major
driver
for
our
priorities.
So
with
that
I
will
hand
it
over
to
matt
and
he
can
take
us
through.
What's
going
on
in
threat,
insights.
B
Hillary,
let
me
get
a
screen
share
going
here,
real
quick,
so
one
of
the
things
for
thread
insights,
following
on
what
hillary
just
mentioned,
is
for
the
last
few
milestones
and
continuing
forward
for
the
next
at
least
one
or
two
thread
insights
is
doing
a
lot
of
work
to
support
our
sas
reliability
and
focus
threat.
Insights
maintains
a
prioritization
issue,
so
you
can
follow
along
at
home
if
you'd,
like
the
difference,
if
you've
looked
at
this
in
the
past,
is
these
top
items
are
all
things
that
are
really
pieces
that
we
need
to
shore
up?
B
B
So
this
work
is
the
main
we're
really
the
only
focus
of
our
backend
engineers.
Right
now,
this
has
pushed
out
some
of
the
upcoming
and,
in
fact,
in
progress
feature
work
to
probably
q4,
but
the
upside
of
all
this
is.
We
should
expect
the
ability
to
scale
forward
with
future
growth.
In
terms
of
vulnerability,
management
and
scanning
inside
of
mrs
pipelines,
et
cetera,
so
as
a
refresher,
this
is
going
to
bring
us
back
down
into
the
regular
priorities
list
is
still
really
remains.
B
So
this
is
one
feature
which
we
may
actually
have
part
of
coming
out
in
the
next
milestone
or
two
we'll
have
the
backing
api
for
this,
so
you
can
manually
create
a
vulnerability
record
against
any
project
you
like
via
api.
This
will
be
great
for
integrating
in
results,
maybe
from
some
sort
of
an
external
scanning
source
or
something
like
a
vulnerability
disclosure
or
bug
bounding
program.
B
B
This
setting
will
take
that
manual
step
of
having
to
go
in
and
actually
select
it
and
then
select
resolve
by
a
person.
So
this
should
be
a
great
efficiency
gain
to
teams
that
are
kind
of
trying
to
automate
as
much
of
their
security
as
possible
and
then
finally,
integrating
developer
security
training.
B
C
C
So
this
is
a
great
incremental
improvement
that
the
team
made
in
the
last
three
months
and
more
to
come
as
we
continue
to
improve
on
this
and
move
it
into
the
security
policy
area.
Secondly,
I
wanted
to
highlight
on
our
security
orchestration
roadmap
this
week.
Actually,
we
just
defaulted
our
feature
flag
to
on
to
turn
on
our
security
policy
management
in
the
ui.
C
We
now
have
support
for
das
and
secret
detection
policies
with
support
for
sas
coming
shortly
thereafter,
as
well
as
after
that
we'll
be
working
to
bring
this
up
to
the
group
and
workspace
levels,
whereas
right
now,
it's
only
at
the
project
level.
All
in
all,
our
vision
for
this
area
is
really
broad.
C
Again,
we
plan
to
continue
to
improve
on
that
in
the
upcoming
months,
with
a
whole
lot
of
improvements
on
our
long-term
maps
such
as
including
the
operating
system
packages
in
our
dependency
list
and
even
moving
away
from
scans
being
executed
in
pipelines
towards
pipelineless
scans
that
are
really
fast.
So
we've
got
a
lot
of
exciting
things
planned
upcoming
there
on
the
container
side
scanning
side
as
well
with
that,
I
will
turn
it
over
to
taylor
and
sask.
D
Awesome
hi
everyone
I
don't
have
anything
to
share,
but
there
are
lots
of
links
in
the
meeting
notes
so
feel
free
to
click
into
any
of
those.
So
to
start
sas
and
static
analysis
is
focused
on
a
lot
of
performance,
reliability
and
scale
work
when
you
think
about
static
analysis
within
the
context
of
secure
we're,
one
of
the
largest
contributors
to
job
runs
given
the
number
of
analyzers
we
have
in
scale
at
which
we
run
so
this
work
is
really
important
to
us.
D
There's
a
lot
that
we
have
planned
here
feel
free
to
look
at
that
issue
and
how
we're
looking
to
reduce
the
load
on
the
entire
system
and
improve
efficiency
long
term
for
static
analysis.
With
that
said,
between
this
performance
work
and
our
product
work,
we
don't
have
enough
resources
to
go
around
so
currently,
secret
detection
and
code
quality
are
considered
to
be
on
ice.
I
do
not
expect
any
meaningful
progress
to
be
made
on
those
feature:
developments
until
probably
spring
of
2022
we'll
keep
reevaluating
this
and
try
to
pull
this
in
as
we
can.
D
But
our
focus
right
now
is
on
sassed.
We
as
part
of
that
are
in
the
process
of
some
major
migrations
with
static
analysis,
specifically
with
sas
we're
transitioning
to
simgrep,
which
is
an
open
source
security
scanner.
We
have
15
open
source
security
analyzers
today,
that's
a
lot
to
maintain
for
us
there's
a
lot
of
complexity,
scattered
across
all
of
those
analyzers
with
different
implementation
details
so
as
we're
transitioning
to
simrap.
This
gives
us
a
number
of
wins.
This
is
less
analyzers.
D
To
maintain
this
is
a
shared
query,
language
and
reduced
number
of
maintained
implementations.
This
gives
us
commonality
for
rule
sets
and
simplifies
a
lot
of
the
interface
with
all
of
the
different
sas
analyzers
there's
also
a
very
large
community
of
some
graph
rules
and
rule
riders
of
which
we
contribute
to
as
well.
D
Semgrep
is
also
a
very
flexible
engine.
That's
feature
aligned
with
our
roadmap,
so
there's
lots
of
benefits
to
why
we're
transitioning
to
semgrupp.
So
we
will
continue
that
transition.
This
is
part
of
that
focus
of
trying
to
reduce
the
number
of
jobs
that
we're
running
as
well
rather
than
different
analyzers
running
individual
jobs.
Semgrep
is
just
one
job
that
has
many
many
rules.
D
D
We
basically
want
to
have
more
control
over
our
detection
rules
and
how
we
interact
with
the
other
security
scanners.
We
want
to
have
more
depth
and
breadth
in
our
detection
capabilities
without
adding
more
analyzers,
and
that
is
really
the
focus
of
this
new
proprietary
analyzer,
which
internally,
you
may
hear
referred
to
as
vet.
D
So
in
the
near
term,
we're
focused
this
engine
on
reducing
false
positives,
so
in
14.3
you'll
see
a
release
that
will
introduce
a
user
experience
in
the
vulnerability
management
suite
and
merge
request
ui.
That
will
allow
you
to
see
when
we
detect
that
analyzer
results
are
potentially
false,
positives
we're,
starting
initially
with
that,
is
informational
context,
but
eventually
we'll
expand
that
to
allow
customers
to
just
not
see
false
positives
at
all
long
term.
We
want
to
change
this
from
just
a
post.
D
Analyzer,
that's
validating
results
into
actual
detection
rules,
so
we
will
be
writing
detection
logic
into
this
proprietary
analyzer
supporting
individual
languages.
The
engine
is
also
capable
of
detecting
more
sophisticated
vulnerabilities.
It
does
it
builds
an
abstract,
syntax
tree
and
allows
you
to
do
data
and
control
flow
analysis
so
long
term.
That
is
really
the
direction
of
where
we're
headed
with
our
static
analysis
tools.
D
This
eventually
will
replace
some
of
our
open
source
analyzers
and
complement
semgrupp,
but
we're
talking
a
year
plus
out
at
this
point.
The
last
piece
is
data
quality
and
accuracy
because
of
the
richness
of
that
proprietary
analyzer
we're
able
to
have
much
more
accurate
findings,
I
mean,
if
you
click
that
link
there,
you'll
see
how
we're
starting
to
look
at
the
coverage
of
cwes
across
all
of
our
supported
languages
and
trying
to
ensure
that
we
have
great
coverage
and
efficient
coverage.
D
D
I'll
also
mention
this
is
a
bit
of
a
strategic
play
for
us,
because
with
our
vs
code,
gitlab
plugin,
we
will
be
able
to
pull
in
some
of
that
context
into
ides
and
highlight
those
vulnerabilities
within
the
context
of
a
developer's
ide.
I
do
want
to
be
really
clear
here.
This
does
not
mean
live
scanning.
We
do
not
have
plans
to
do
live
scanning
in
the
developer
ide.
This
is
purely
displaying
previously
detected
vulnerabilities
in
an
ide
using
this
inline
annotations
feature.
A
Thanks
so,
as
you
heard
at
the
beginning
of
the
call,
I'm
one
of
the
groups
that
de-prioritized
all
my
future
work
so
that
we
could
create
space
for
the
gitlab,
hosted
first
initiatives
and
what
we've
proceeded
to
do
in
the
past
couple
months
was.
We
have
always
kept
our
s1
and
s2s
in
slo,
and
we
are
actually
at
this
point
helping
some
other
teams
with
their
s1
and
s2s,
so
we're
continuing
to
knock
all
of
those
out.
A
We
hope
that
this
is
a
lot
less
painful
process
to
verify
your
changes
into
composition,
analysis
and
we
did
create
a
bunch
of
backlog
items
so
we're
going
to
continue
iterating
and
slowly
improving
that
whole
way
that
we
structure
our
tests,
not
necessarily
what
we're
testing,
because
we
had
test
coverage
for
everything
which
is
the
way
that
it's
structured
so
that
it's
easier
to
run
locally,
which
doesn't
matter
to
you
unless
you're
contributing
to
the
code.
But
everybody
can
contribute
so
obviously
a
good
lab.
A
It
matters
to
everyone
now
coming
up
in
the
next
set
of
months,
which,
at
this
point,
I'm
going
to
say,
is
actually
the
next
calendar
year,
because
we're
probably
going
to
finish
with
the
transition
from
focusing
on
get
love,
sass
first
and
then
start
moving
over
into
jumping
to
focus
on
these.
But
it's
not
exactly
going
to
be
three
months.
It's
probably
going
to
be
closer
like
four
or
five.
A
I
want
to
work
on
getting
dependency
scanning
up
one
maturity
level,
which
indicates
that
we're
going
to
start
having
dependency
graphs.
We
also
want
to
start
having
s-bomb
in
at
least
one
or
two
of
the
main
supported
formats
like
spdx
and
cyclone
dx.
Those
are
the
two
most
popular
ones.
We've
been
asked
for
so
far
and
we'd
like
to
replace
license
finder.
It
unfortunately
has
fallen
out
of
update
within
the
community.
A
It's
an
open
source
project,
so
we're
either
going
to
be
writing
that
ourselves
into
gymnasium
or
we're
going
to
find
a
different
open
source
project.
So
if
anybody
has
any
recommendations,
feel
free
to
comment
in
the
issue
with
what
open
source
license,
scanner
that
you
would
recommend
if
there's
one
you
enjoy
with
that
I'll
turn
it
over
to
derek.
E
E
The
last
release,
especially
we
have
really
improved
the
vast
site,
validation.
We,
the
first
thing
we
did
was
we
moved
the
validation
to
the
gitlab
runner.
What
this
enables
is
for
especially
self-managed
customers
to
be
able
to
scan
internal
sites
that
don't
have
a
url
that
is
available
outside
of
their
network,
so
this
enables
a
whole
another
set
of
users
to
be
able
to
run
on-demand
scans
with
active
scans.
E
We
also
made
it
easier
to
do
the
site
validation
by
adding
in
a
third
option
for
that
validation
by
adding
a
meta
tag
to
an
html
web
page,
and
then
one
other
thing
that
we
did
that
I
don't
have
a
specific
issue
for,
because
it
encompasses
a
lot
of
different
issues.
Is
we
improved
the
crawler
for
the
browser-based
desk
scanner
quite
a
bit
over
the
last
milestone
through
working
with
our
customers,
to
be
able
to
scan
real
web
pages
and
applications?
E
We're
able
to
greatly
improve
the
coverage
for
that
and
the
functionality
for
the
authentication,
as
well
as
the
crawler.
So
looking
ahead,
one
thing
that
we
are
finishing
up
right
now
we
are
hoping
to
launch
here
quickly-
is
the
scan
scheduler
for
on-demand
desk
right
now.
You
can
only
do
it
with
manually,
starting
a
scan
with
this
scheduler
you'll
be
able
to
schedule
scans
for
the
future
as
well
as
schedule
reoccurring
scans.