►
From YouTube: Security pitch guidance with new deck August 2020
Description
Cindy Blake gives pointers for how to have a successful GitLab Ultimate security capability discussion with customers and prospects.
Find the deck at https://docs.google.com/presentation/d/1bA8rgcHjzXCqyO14blOI877qBOilWbvbqcwMmJFN0sM/edit#slide=id.g2823c3f9ca_0_9
A
If
you
will,
and
so
I'm
going
to
take
a
a
moment
to
show
you
a
draft
deck
that
I
have
I've
got
it
out
there
for
comments
and
show
you
how
I
would
pitch
it.
It's
a
little
bit
different
than
what
we've
been
using
for
security
overview.
So
love
your
feedback
and
I
think
doing
it
on
a
video-
might
be
helpful
to
show
you
what
I
had
in
mind.
A
I'm
also
going
to
show
you
with
the
notes
so
that
you
can
see
you
know
I
can
point
out
some
relevant
items
there.
So
this
deck
is
intended
for
a
security
audience.
You
can
use
it
with
a
devops
or
developer
audience,
but
it's
got
some
things
in
here
that
are
intended
for
the
security
audience
because
usually
they're
the
ones
that
can
be
a
roadblock
if
they
aren't
on
board
with
using
the
secure
features
and
they
may
be
funding
the
delta
for
ultimate.
A
The
first
thing
that
is
really
important-
and
you
may
not
want
to
show
this,
but
it's
important
for
qualifying
your
audience-
is
to
make
sure
that
you're
on
the
same
page,
for
what
you
all
want
to
talk
about.
So
there's
four
elements
to
security
when
it
comes
to
get
lab.
One
is
the
security
testing,
and
that
is
what
we
call
secure,
there's
also
defend,
which
is
protecting
your
applications
in
production.
A
Think
of
that
more
as
cloud
application,
security
and
then
there's
compliance
and
people
often
confuse
compliance
with
secure
compliance
is
how
the
it's
under
the
manage
stage
in
gitlab,
but
it's
how
we
ensure
that
the
right
people
have
access
to
the
code.
So
you
don't
have
random
people
making
changes
to
your
code,
so
it
has
access
control
things
like
multi-factor
authentication
things
like
the
same
person
that
writes
the
code
shouldn't
be
the
same
person
that
pushes
it
to
production.
A
All
of
those
kinds
of
things
are
compliance
and
you
need
to
ask
enough
questions
to
find
out
what
the
concern
is
and
what
their
primary
pain
is,
because
if
it's
compliance,
this
is
not
the
presentation
for
you.
Contact
matt
gonzalez
the
pm
or
samya.
She
is
the
pmm,
that's
that's
working
on
complaints
and
they
can
help
you
there.
A
The
last
piece
of
this
is
how
git
labs
secures
the
get
lab
application
and
there
you
can
go
to
security,
not
secure,
not
defend
but
get
lab
security,
and
that
page,
that's
jonathan,
hunt's
group
kind
of
our
cso
organization.
If
you
will
and
there's
like
questionnaires
and
things
there
so
just
want
to
make
sure
that
everybody's
on
the
same
page,
for
what
it
is
that
we're
talking
about
that
is
actually
a
way
that
a
lot
of
time
gets
lost
in
having
the
wrong
conversations.
A
Now,
I'm
going
to
go
through
this
a
little
bit,
how
I
would
talk
with
a
customer,
you
know
application
security
is
is
difficult
because
it
is
a
it
requires
people,
processes
and
tools.
It's
not
just
like
throwing
a
a
network
security
device
on
your
network
and
and
doing
a
little
tuning
and
you're
ready
to
go.
A
When
vulnerabilities
are
found,
usually
by
the
security
person,
they
can't
do
the
remediation,
so
they
have
to
work
with
the
developers
to
do
the
remediation
to
fix
those
flaws.
So
it
takes
a
village,
it
takes
a
collaboration
coordination
and
that's
what
makes
it
so
hard
add
to
that.
When
you
use
a
devops
methodology,
you've
got
smaller
code
changes
much
more
iterative.
A
It
really
doesn't
fit
with
doing
a
waterfall
security
process
where
you're
doing
the
scanning.
At
the
end,
there's
new
attack
surfaces
with
containers
and
kubernetes
and
many
more
apis
between
functions
and
api
security
is
kind
of
in
its
infancy.
So
there's
not
a
lot
of
good
solutions
out
there
for
that.
A
Now
all
of
this
results
in
unsatisfying
trade-offs.
You've
got,
you
know,
risk
of
introducing
new
vulnerabilities,
but
you
also
have
velocity
and
time
to
market
and
all
of
those
things
kind
of
come
together
with
bad
trade-offs.
So
how
do
you
balance
those
things
now
use
this
slide
to
ask
your
customer
or
your
prospect,
questions
which
of
these
things
are
the
most
painful
to
them
turn
this
around
get
some
information
from
them
see
where
their
head
is
in
terms
of
what
is
the
chief
complaint
chief
issue
of
building
security
into
their
devops?
A
Now
the
whole
shift
left
mantra
kind
of
comes
from
almost
urban
legend
right,
so
nist
did
a
study
back
in
20
2002
2005
long
time
ago.
That
showed
that
it's
30
times
more
costly
to
fix
flaws
security
flaws
in
production
than
it
is
to
fix
them
earlier
in
design,
and
so
this
is
what
the
genesis
is
for.
The
whole
shift
left
is
wanting
to
reduce
cost
by
finding
and
fixing
vulnerabilities
earlier,
but
how
you
do
it
is
not
an
easy
nut
to
crack.
A
That's
been
around
for
a
long
time
and
that's
why
we
still
don't
have
really
good
market
penetration
around
application
security.
Not
just
gitlab
the
market
in
general,
doesn't
always
do
application
security
like
they
should
so
ask
them
questions.
What
do
you
do
when,
if
they're
using
fortify
or
vera
code
or
one
of
the
tools,
that's
been
around
for
a
long
time?
What
do
you
do
when
you
find
10
000
vulnerabilities
late
in
your
software
development
life
cycle?
It
happens
all
the
time.
A
A
Are
they
trying
to
you
know,
do
this
for
compliance
reasons
and
audit
reasons,
so
you
can
do
scanning
for
compliance
purposes
and
scanning
is
a
requirement
often
times
of
compliance,
but
is
that
what's
driving
them
have
they
had
an
audit,
and
maybe
they
failed
an
audit,
and
they
know
they've
got
to
do
better,
could
be
efficiencies.
They
realize
that
they
need
to
shift
left
finding
things
late
in
the
game
doesn't
work
for
them.
A
A
In
fact,
I've
had
customers.
That
said
I'd
rather,
you
know
rather
not
surface
vulnerabilities
early
in
the
life
cycle,
because
I
don't
want
the
developers
dealing
with
that
as
a
security
person.
I
want
to
control
it
and
I
want
to
be
on
top
of
it
so
be
careful
here,
because
the
security
people
sometimes
have
a
little
bit
different
motivations.
A
Sometimes
it's
job
protection,
so
ask
them
questions
get
them
to
put
this.
In
their
words.
What
is
their
desirable
outcome?
Now
oftentimes?
We
see
that
one
of
the
chief
drivers
is
efficiency,
and
so
you
can
think
back
to
command
of
the
message
and
pull
some
things
from
that
efficiency
side
of
the
equation:
an
efficiency
value
driver.
A
If
you
put
that
through
a
security
lens,
there's
efficiencies
for
both
the
developer
and
the
security
person
for
the
developer,
it
means
dealing
with
things
in
their
workflow,
not
having
to
change
context
and
have
somebody
come
back.
You
know
a
week
later,
a
month
later,
what
have
you
and
say?
Gosh
you've
got
this
vulnerability
that
I
need
you
to
deal
with
for
the
security
person.
A
It
may
mean
a
combination
of
maybe
there's
fewer
vulnerabilities
for
them
to
deal
with,
because
the
security
person
was,
I
mean
the
developer
was
able
to
resolve
them
early
on,
but
it
could
also
mean
for
every
for
every
less
vulnerability
that
they
have
to
worry
about.
That
hasn't
been
resolved.
That's
less
time
going
through
a
whole
workflow
that
they
would
have
for
triaging
those
vulnerabilities.
A
You
know
validating
them,
triaging
them
back
to
the
development
team.
Finding
out
did
the
development
team
assign
somebody
has
it
been
fixed?
You
can
imagine
the
time
effort
there.
So
I
wouldn't
show
this,
and
this
is
an
mvc
slide.
I
promise
I'll
make
it
prettier,
but
I
wouldn't
show
this
to
everybody,
but
if
efficiency
is
important
to
them,
it's
certainly
worth
bringing
up
by
the
way
this
deck
is
meant
for
you
to
be
customized
cut
to
customize
it
for
the
customer
that
you're
talking
to
don't
feel
like
you've
got
to
use
every
slide.
A
A
A
That's
really
key,
because
we
do
that
better
than
anybody
other
you
know
traditional
appsec
vendors
are
trying
to
partner
with
us
because
they
know
the
importance
of
getting
their
scan
results
in
front
of
the
developer.
We
do
that
natively.
So
if
you
can
get
them
to
articulate
these
items,
these
required
capabilities.
A
A
A
lot
of
the
tools
grew
through
acquisition
so
and
and
there's
a
lot
of
point
solutions
out
there.
So,
if
they're,
using
sneak,
for
instance,
sneak,
does
software
composition,
analysis
and
license
compliance,
but
it
doesn't
do
sas
and
das
if
they're
using
vera
code
veracode
fortify
the
big
ones,
they
are
multifaceted,
but
they
grew
through
acquisition.
A
So
they're
going
to
try
to
sell
you
a
a
separate
dashboard
to
pull
all
of
their
scan
results
together
into
one
place
center
cube,
they
focus
more
on
quality
than
on
security,
but
they
do
a
little
bit
of
security
as
well.
So
you
know
we
can
provide
that
end
to
end
view,
end-to-end
scanning
and
in
the
security
space.
It's
often
referred
to
as
defense
in
depth.
You
want
to
do
multiple
kinds
of
scans,
because
each
scan
is
going
to
find
a
different
kind
of
vulnerability,
and
we
do
that
very,
very
well.
A
You
can
show
them.
I
recommend
that
you
show
them
that
we
embed
our
security
scanners
within
ci,
so
that's
really
key
there,
because
it
spares
them
from
having
to
do
that.
Integration
if
they're
using
gitlab
ci
by
the
way,
if
they're
using
jenkins
for
ci
a
fern,
does
have
a
video
out
there,
where
we've
done
kind
of
a
proof
of
concept
to
show
you
can
use
somebody
else's
ci
and
still
use
get
lab
for
security
scanning.
Just
like
you
can
use
somebody
else's
source
code
manager.
A
However,
my
caveat
would
be
it's
really
best
if
you're
using
something
from
git
lab,
if
you're
not
using
gitlab
for
scm
nor
for
ci,
it
probably
doesn't
make
any
sense
to
use
us
for
secure.
So
that
is
why
we
are
a
niche
player
by
the
way
in
the
gartner
magic
quadrant.
So
if
somebody
tries
to
say
it's
because
our
scanners
are
inferior,
that
is
not
the
not
the
reason.
A
A
Looking
at
the
same
thing,
so
you
don't
have
the
translation
between
a
security
system
back
to
the
developer
and
between
the
developer,
doing
their
thing
and
trying
to
convince
the
security
person
that
it's
been
dealt
with
everybody's
looking
at
the
same
thing
which,
by
the
way,
auditors
love
because
of
that
transparency
and
that
visibility
end
to
end
across
the
development
life
cycle
of
who
changed.
What?
Where
when
and
why,
including
dismissing
vulnerabilities
and
approving,
merge
requests
that
may
not
meet
policy.
A
Fuzzing
can
be
another
piece
of
the
conversation
it's
not
too
early.
We
did
we
closed
those
acquisitions
of
peach
and
pheasant
in
I
think
april
march.
They
have
been
integrated
and
they
will
help
you
find
vulnerabilities
that
you
didn't
know
existed.
You
didn't
it's
one.
It's
a
case
of.
I
don't
know
what
I
don't
know
to
ask
for.
A
A
It
means
clear
accountability
for
the
developer
that
made
a
change
of
code
on
that
feature
branch.
They
created
that
vulnerability.
It
wasn't
somebody
else,
so
you
get
very
clear
feedback
of.
I
created
this
vulnerability,
I'm
the
one
best
capable
of
fixing
it
and
while
I'm
right
here
working
on
it,
that
is
really
really
key.
It's
totally
different
than
the
other
traditional
application
security
vendors
do
where
they're
testing
maybe
a
whole
repository,
because
then,
when
you
find
vulnerabilities,
you
don't
know
who
they
belong
to.
This
is
also
really
important
for
somebody.
A
That's
interested
in
improving
the
skills
of
the
developer,
to
create
more
secure
code.
What
better
way
than
to
give
immediate
feedback
of
you
created
this
and
it
was
a
vulnerable-
has
a
vulnerability
in
it
which
also
by
the
way,
we're
going
to
get
to
when
we
talk
about
defend,
because
that's
going
to
provide
feedback
on
exploits
actual
exploits
of
their
code.
So
you,
a
lot
of
people,
are
interested
in
educating
the
developer
to
craft
more
secure
code,
and
this
is
how
we
help
oops
now.
A
A
So
this
is
all
just
a
conversation
about
workflow
and
getting
them
to
internalize
what
that
workflow
might
mean
to
them.
So
this
is
a
cyclical
cyclical
iterative
flow
where
the
developer
is
changing
code
trying
it
see
what
works
if
you've
made
any
changes
to
the
handbook.
You
know
exactly
what
I'm
talking
about.
If
you
commit
a
code
change,
you
look
at
the
review
app
and
you
see
you
know,
did
my
pipeline
run?
Did
it
come
out
like
I
like
I
intended
it
to,
or
is
my
formatting
off
right?
A
But
the
key
point
here
is
what
it
does
is
it
strikes
a
line
through
it,
so
they
don't
have
to
deal
with
it
again,
but
it
doesn't
go
away.
It
still
shows
up
for
the
security
person
on
the
dashboard
and
in
fact
they
can
filter
for
only
to
see
only
dismissed
items
and
lots
of
them
like
to
do
that.
So
that's
important
now,
if
you,
I
recommend
using
this
slide,
if
you're
talking
to
maybe
a
manager
level,
maybe
even
practitioner
level,
if
you're
talking
with
a
c
level
use
this
slide.
A
Instead,
it
just
says
that
you
know
we're
helping
through
the
entire
software
development
life
cycle.
They
may
get
lost
on
on
some
of
that
more
detailed
workflow,
but
either
way.
The
fact
that
security
is
integrated
is
really
what
sets
us
apart,
because
it's
contextual
it.
It's
part
of
the
dev
ops
workflow
that
iterative
process.
A
It
gets
the
information
to
the
developers
who
are
the
ones
that
can
do
the
remediation
and
fix
those
flaws.
A
couple
more
slides
here
that
you
could
go
through
this
shows
a
merge
request.
This
is
what
the
developer
is
going
to
focus
on
so
they're
going
to
see
these
results,
the
security
results
in
their
merge
request
pipeline.
A
So
this
a
through
f
risk
score
is
really
important
to
them.
You
will
get
a
lot
of
questions
on
how
can
what
sets
that?
What
determines
what's
an
a
and
what's
an
f,
and
it
has
to
do
with
the
severity
and
the
number
of
severities
in
a
particular
project,
but
the
idea
is
here's
the
projects
that
are
the
worst
off
that
you
need
to
focus
on
a
lot
of
them
are
going
to
want
to
customize
that
we
have
an
issue
open
for
that
happy
to
have
them
contribute
to
it.
A
I
don't
recommend
that
you
talk
about
the
web
application
firewall
just
yet
it's
it's
still
getting
some
of
the
kinks
worked
out
and
is
is
small
in
the
number
of
users,
but
definitely
talk
about
container
network
security
and
container
host
security.
It's
very
very
timely,
so
these
have
to
do
with
people
that
are
using
kubernetes
monitoring
the
security
of
those
environments.
So
I
mentioned
that.
There's
you
know
cloud
native
brings
a
whole
new
set.
This
was
like
the
second
slide
brings
a
whole
new
set
of
attack
surfaces
and
that's
where
this
comes
to
play.
A
So
containers
orchestrators
microservices,
those
are
the
things
that
are
driving
the
cloud
security
and
there's
not
a
lot
of
good
solutions
out
there.
So
we
still
have
a
really
good
time
to
get
to
this
market,
and
you
can
talk.
I
don't
recommend
going
into
a
lot
of
detail
here,
but
you,
the
the
to
me,
the
sweet
spot
is
the
cloud
network
security
because
it
it
monitors
the
east-west
traffic
or
the
traffic
between
clusters
within
between
kubernetes
clusters
containers.
A
So
if
you've
got
one
container
calling
another
container,
that
shouldn't
be,
that's
probably
an
exploit
and
it's
those
kinds
of
things
that
get
found
that
are
often
associated
with
a
lateral
attack.
So
somebody
finds
some
low-hanging
fruit
that
gets
them
in
the
door
into
your
kubernetes
environment
or
your
containers
or
your
your
cloud
service,
and
they
use
this
sort
of
attack
to
cross
into
areas
that
may
be
more
sensitive
data
that
you
normally
would
have
protected
better,
but
the
the
kubernetes
piece
could
be
a
gap.
A
So
why
is
this
important
from
a
devsecop
standpoint,
you're
getting
real
information
about
real
exploits
and
you
can
get
that
back
to
the
developer,
we'll
get
better
at
that
closed
loop
over
time,
but
you
know
rarely,
does
a
developer
ever
hear
that
their
application
had
vulnerabilities
that
were
exploited
unless
they
get
fired
because
it
was
so
bad.
So
you
know
something
something
really
good
here
and
then
have
your
essay
go
into
a
demo
and
you
know
make
those
key
points
that
that
I
covered
here
so
hope.