►
From YouTube: SKO Paths to Ultimate - security focus recap
Description
Since the Paths to Ultimate breakout included on SA and TAMs, I've recorded the security part of the discussion for SALs and other sales roles. The tips here should help you position GitLab Secure capabilities. Slides can be found at https://docs.google.com/presentation/d/1Oq8znDkHrgGK5Xe5D23SdiRLt33OIJZ30OWCHNNDV14/edit?usp=sharing
A
A
But
if
they're
not
willing
to
get
on
to
get
lab
CI,
then
you
may
be
barking
down
the
wrong
at
the
wrong
tree.
If
you're
trying
to
to
jump
to
a
secure
conversation,
so
just
caveat
there
and
then
the
other
thing
is
they
need
to
be
pursuing
dev
SEC
ops
when
we
get
into
use
cases
you'll
see
that
you
know
this
really
secure
and
the
way
we
do.
Security
scanning
is
really
all
about
getting
security
into
the
dev,
ops,
workflow,
and
so
velocity
really
needs
to
be
one
of
their
driving
requirements.
A
A
Do,
though,
a
couple
of
of
contextual
pieces,
you
know
as
they're
moving
towards
cloud
native
architecture,
containers,
orchestrators
and
micro
services
become
a
real
key
part
of
their
development
effort,
and
each
of
these
represents
a
new
attack
surface
which
a
lot
of
times
the
security
department
hasn't
thought
through.
So
they
may
not
be
scanning
containers
because,
quite
honestly,
they
may
not
have
even
thought
about
it.
A
You
can
do
version
control,
so
it's
those
micro
services,
the
fact
that
they're
now
coding
smaller
pieces
and
so
I
can
code
a
bunch
of
small
pieces
and
then
test
them
all
at
the
end.
In
a
traditional
application,
security,
testing,
method
or
I
can
do
all
these
small
pieces
of
code
changes
and
test
them
as
I
go
and
and
that's
what
we
do.
So,
if
you
think
about
what
the
incongruencies
are,
this
might
help
you
have
a
conversation
with
your
customer
puts
you
in
more
in
their
shoes.
A
You
know
if
they've
been
moving
from
penetration
testing.
You
know
those
things
have
been
kind
of,
not
sporadic.
That's
not
the
right
word,
but
very
much
at
the
end
in
production
and
what
we're
talking
about
is
doing
scans
in
development
before
it
ever
leaves
that
individual
developers
hands
we're
talking
about
empowering
the
developer,
and
you
can
you
can
say
you
know,
the
security
team
will
always
be
outnumbered
by
the
developers
and
so
the
way
to
scale
your
application.
A
So
it's
all
about
shifting
left
moving
thing,
removing
things
early
by
the
person
that
can
actually
do
the
remediation,
which
is
the
developer,
not
the
security
person.
You
know
one
other
point:
I
wanted
to
bring
up
because
it
came
up
in
the
in
the
selling
ultimate
slack
channel
that
we
created
as
a
result
of
this
session.
A
You
know
some
companies
are
shifting
left
by
doing
and
having
a
scanning
in
the
web.
Ide
I
think
four
to
five
house.
That
verrico
has
that
there's
several,
but
those
are
really
kind
of
called
blight
static
scans.
They
can't
do
a
full
static
scan
in
that
web
IDE
and
it's
only
one
type
of
scan.
We
have
five,
we
have
static,
dynamic
container,
license
compliance
and
dependencies,
and
so
yeah
they're
shifting
further
left
with
those
sass
light
capabilities
in
the
web
IDE,
but
it's
just
a
sliver
of
what
they
really
need
to
be
doing
now.
A
This
is
what
I
call
our
secret
sauce
and
it
it's
enabled
by
the
fact
that
we
are
one
application
for
the
entire
software
development
lifecycle.
It's
enabled
by
the
fact
that
we
embed
security
into
CI,
and
that
is
that
we
do
this
at
the
security
testing
on
the
future
branch
and
the
power
that
this
enables
is
as
a
developer,
I
make
a
code
change
and
I
press
commit
it's
getting
scanned
in
my
pipeline
and
I
get
the
results,
and
it's
I
made
this
code
change.
I
made
the
vulnerability
that
resulted.
A
It's
not
that
Sally
down
the
hall
created
the
vulnerability
and
I'm
having
to
deal
with
it.
Now,
in
my
you
know
in
my
code,
or
that
it's
been
lingering
out
there
for
two
years
and
I'm
the
first
one
to
change
this
section
of
code.
So
BAM
it's
my
problem.
This
is
very
clear
cause
and
effect
where
I
made
this
change
and
as
a
result
of
my
change,
here's
the
vulnerability
that
I
created
that
is
so
powerful
in
the
current
situation
with
most
applications,
security
testing
and
the
workflows.
A
What
happens
is
the
testing
is
done
by
security
at
the
end
in
production,
environment
and
when
I
find
all
of
these
vulnerabilities
as
a
security
person,
now
I've
got
to
work
back
and
figure
out
who
can
fix
them
because
that
finding
them
is
only
part
of
the
problem?
Fixing
them
is
the
bigger
problem,
and
so
I
need
to
figure
out.
You
know
who
is
the
developer
that
can
fix
it.
I
gotta
prioritize
it
and
get
it
into
their
work
queue
and
then
because
I'm
responsible
for
a
risk
and
managing
risk
I
get
pressure
for
it.
A
Well
has
the
vulnerability
been
fixed
yet
well,
I,
don't
know.
Let
me
go
check
with
the
developer.
Let
me
go
look
back
in
another
system
so
that
friction
in
that
workflow
is
eliminated.
When
you
can
empower
the
developer
to
just
find
and
fix
the
vulnerabilities
right
there
before
it
ever
leaves
their
hands.
A
Now,
as
I
said,
we
run
all
of
these
security
scans
in
development
and
the
way
that
we
do
is
very
different
as
well,
so
we
use
that
review
app
as
dynamic
scanning
requires
a
fully
functioning
application
in
order
to
do
the
tests.
We
use
the
review
app
as
that
fully
functioning
application
and
we
run
DAST
against
that
and
that's
how
we're
able
to
do
it
so
early
in
the
game
and
I,
don't
know
of
anybody
else
that
is
able
to
do
dynamic
scanning
that
early.
A
In
fact,
that's
kind
of
the
reason
why
interactive
application
security
scanning
or
iOS
was
created
was
because
dynamic
scanning
was
so
late
in
the
game
they
wanted
to
shift
left,
so
what
they
did
was
they
created
I
asked
in
order
to
do
that
and
it
it's
a
combination
of
instrumentation
of
the
application
and
that
dynamic
pressure
against
the
code,
and
so
you
might
even
be
able
to
argue
that.
Maybe
we
don't
need
not
I
asked
I,
don't
know,
we've
got
it
on
our
roadmap
and
that
has
yet
to
be
determined.
A
But
the
fact
that
we
do
dast
so
early
is
very,
very
unique.
Now,
if
I
only
had
three
slides
to
use
by
the
way,
it
would
be
these
three.
It
would
be
the
fact
that
we
do
the
testing
on
the
feature
branch,
all
of
the
testing
that
we
do
in
the
development
and
this
iterative
cycle,
because
what
this
is
showing
is
as
the
developer
iterates
on
their
code.
Naturally
they're
looking
at
I
made
a
code
change.
Does
it
function
the
way
I
wanted?
It?
A
Is
my
user
happy
with
it
the
way,
the
way
it
was
designed,
and
so
as
I'm
iterating
on
those
code
changes
I'm
also
in
tithing
on
my
security,
vulnerabilities
and
findings
and
I
can
take
three
three:
a
choice
of
three
actions
there
as
a
developer.
If
I
can
fix
it,
I
know
what
you
know:
what
it,
how
to
fix
it
I
have
the
time
to
do
it.
I
can
fix
the
vulnerability.
That
would
be
the
preferred
route.
I
can
create
an
issue
and
so
that
we
make
sure
that
it
doesn't
fall
between
the
cracks.
A
Let
me
deal
with
it
or
I
can
dismiss
it
now.
If
you're
talking
to
a
security
person-
and
you
say
that
dev
can
dismiss
a
vulnerability
that
usually
raises
the
hackles
on
the
back
of
their
neck
and
they'll.
Oh,
my
gosh:
we
can't
have
developers
doing
that
because
they'll
just
dismiss
everything,
but
the
key
here
is
they.
They
can
write
a
reason
why?
So
there
are
some
legitimate
reasons
for
dismissing
it
could
be.
Maybe
it's
a
test
database.
A
A
So
why
we
win
and
why
this
helps
the
the
prospect
is
that
all
of
these
security
scanning
results
are
contextual
they're
within
the
workflow
and
the
workflow
works
with
the
DevOps
iterative
environment
and
it's
very
efficient.
So
you
can
compare
it
to
phone,
you
know
your
cell
phone
and
your
camera
you
might
want
to
use.
You
might
still
want
to
use
the
camera
because
it
really
is
the
best
tool
for
taking
pictures.
If
you're
you
know
doing
a
family
portrait
or
something
just
like
you
may
really
still
want
to
use.
A
You
know
fortify
or
ver
code
or
black
duck
or
write
source.
Take
your
pick,
your
pick
of
your
favorites,
but
when
you're
looking
at
shifting
left
and
finding
vulnerabilities
earlier,
you
don't
need
to
get
into
an
argument
over
how
many
vulnerabilities
do
we
find?
What
is
the
efficacy,
our
scanners,
if
you
talk
about
the
fact
that
it's
integrated
so
it's
there
and
it's
the
results
that
are
important
and
where
they
show
up
in
how
you
use
them.
A
You
know
on
your
cell
phone
when
you
take
a
picture,
it's
all
integrated
with
you
know
your
social
media
and
the
internet.
I
don't
have
to
find
something.
That'll
read
a
flash
drive
and
then
make
sure
that
that's
connected
to
the
Internet,
so
it
all
just
works-
and
you
know
tsa
scanning-
would
be
another
metaphor
for
this
scan
everything
lightly
and
then
those
things
that
are
anomalies
or
more
randomly
you
know,
from
a
random
QA
standpoint,
go
deeper
with
a
different
scanner.
That's
fine!
A
You
shouldn't
be
making
the
argument
that
we
are
a
you
know
case
for
case
replacement
of
these
other
scanners.
It's
really
about
shifting
left,
let's
scan
everything
early
and
if
you
want
to
do
the
more
in-depth
scanners
later
fine.
You
can
do
that
too,
but
we
can
still
save
you
money
if
you're
paying
by
the
scanner
or
by
the
button
by
the
scanner
by
the
developer.
A
Now,
compliance
in
retrospect
compliance
really
isn't
a
motivator
for
doing
dev,
SEC
ops
as
much
as
velocity,
but
I,
put
compliance
in
here,
because
CISOs
in
particular
are
beginning
to
understand
that
gitlab
is
kind
of
the
crown
jewels
that,
if
I,
if
my
development
organization
is
putting
all
of
their
software
in
get
lab,
did
man
I,
better,
make
sure
I'm
protecting
gitlab
and
and
that
it's
compliant
with
some
basic
controls.
And
so
you
can
talk
with
them
about
the
end-to-end.
A
Security
of
software
has
to
do
with
not
only
application
security
testing
that
we've
talked
about,
but
protecting
that
application
and
production,
which
is
where
we're
headed
with
defend
and
then
policy
compliance
and
auditability.
So
making
sure
that
you
know
only
legitimate
developers
have
access
to
the
code,
for
instance,
and
that
I
can
look
at
who
changed
what,
where,
when
that
becomes
harder
to
do,
if
I'm
piecing
together
tools
and
then
the
platform
security
so
get
labs
security
in
and
of
itself.
And
if
you
get
people
asking
about,
how
do
you
do
multi-factor
authentication?
A
How
do
you,
what
are
your
access
controls
for
to
get
lab
application?
That
really
has
to
do
with
our
security.
There's
a
page
if
you,
if
you
google,
get
lab
security,
that's
run
by
our
security
team.
So
that's
ours
to
see
so
team
more
or
less.
No,
we
don't
have
a
C
so
per
se,
but
that's
that's
our
security
team
and
if
you
get
those
kinds
of
questions
around
access
to
get
lab
itself
talk
with
this
in
the
security
channel,
not
secure,
but
security
slot
channel.
Ask
those
questions.
They're.
A
So
we
did
a
poll
here.
The
poll,
by
the
way
that
was
in
the
session,
was
what
it
came
back,
is
the
biggest
barrier.
Was
the
cost
jump
from
premium
to
ultimate?
We
get
that
we
understand
and
there's
two
sides
to
that.
What
is
the
cost
itself
and
the
other
is
demonstrating
the
value
and
on
the
cost
itself.
Scott
Williamson
has
hired
a
p.m.
for
pricing
and
they
have
engaged
a
third
party
to
do
a
pricing
analysis
for
us
and
in
fact,
in
the
selling
ultimate
channel
the
gal.
A
A
Now,
let's
talk
about
a
couple
tips
and
techniques.
I
went
over
some
of
these,
but
so
I'm
going
to
zip
through
some,
but
I
also
want
to
get
to
some
things
that
I
didn't
get
a
chance
to
talk
about
in
the
session
because
we
got
buried
in
QA.
So
I
mentioned
secret
sauce
here,
embedded
in
CI,
actionable
iterative
before
the
code
is
merged.
Okay
covered
that
it's
not
what
scanner
you
use,
but
how
timely
you
address
the
results.
A
So
if
they
ask,
how
do
you
compare
with
this
scanner
that
scanner
and
whatever
there's
million
different
scanners
out
there,
turn
that
conversation
to?
When
do
you
get
those
results?
What
do
you
do
with
them?
Who
gets
them?
How
do
you
reconcile
those
results
across
different
systems
across
security
system,
in
your
developer
system
and
so
forth?
A
So
these
are
questions
to
ask
the
developer.
You
know:
are
you
getting
security,
grenades
that
are
thrown
at
the
end
of
your
SCLC?
Well,
it's
sort
of
disruption.
Does
it
cause
what
would
happen
if
you
were
able
to
see
all
of
these
vulnerabilities
yourself
before
the
code
is
merged?
That's
really
key
before
the
code
is
merged.
If
you're
talking
with
a
security
team,
you
know
they
have
their
their
challenges,
taking
the
results
that
they
found
and
tracking
it
back
to
who
did
it?
How
do
they
prevent
it
from
happening
again?
A
If,
if
you're
going
up
against
Microsoft
Microsoft,
you
know
there's
there
recessions
at
schoo
at
the
cells
kick-off
that
talked
about
the
ELA
and
I
would
encourage
you
to
go
look
at
those
the
competitive
sessions,
but
it's
really
kind
of
some
assembly
required
on
verify
verifying
for
error
code
bare
code
and
fortify.
You
know
you'll
get
some
things
about.
Well,
we
have
fewer
false
positives.
A
There
are
even
companies
that
are
having
developers,
use,
fortify
I,
think
our
developer
I
wouldn't
want
to
do
that.
But
and
you
can
find
results
out
there
that
show
you
know
efficacy
comparisons.
I
will
tell
you,
though,
don't
go
down
that
path,
go
down
the
path
of
the
workflow,
because
we
don't
have
a
real
good
set
of
results
to
say,
here's
an
efficacy
comparison
so
focus
on
the
workflow.
Are
they
testing
for
the
obvious
use
cases?
A
Are
they
running
vert
code
and
fortify
on
a
subset
of
applications,
I
guarantee
they
are
not
running
those
security
scans
on
all
of
their
apps
they're,
usually
doing
it
for
mission-critical
apps,
which
is
a
problem.
I
mean
target,
was
a
prime
example.
They
were
hacked
through
their
HVAC
system
and
then
people
Traverse
laterally,
so
they
might
be
doing
infinite
security
scans
and
finding
lots
of
vulnerabilities
on
a
couple
of
applications.
A
But
if
they're
not
testing
everything,
it's
like
leaving
a
window
open
and
another
seed
you
can
plant
is
what
happens
when
they
find
10,000
vulnerabilities
and
it's
at
the
end
of
the
software
development
lifecycle.
Now
they've
got
this
technical
debt
to
deal
with,
and
you
could
argue
there
was.
There
was
a
case.
Boeing
I
think
recently
got
into
trouble
because
they
knew
about
some
safety
findings
with
one
of
their
jets,
but
they
didn't
do
anything
about
it.
Is
this
not
something
similar?
A
If
you
find
all
these
vulnerabilities
and
you're
not
able
to
fix
them
right
away,
I
did
there
hasn't
been
a
case
yet
yet,
but
my
I
predict
at
some
point.
Somebody
will
get
sued
because
you
knew
the
vulnerability
was
there
and
you
didn't
prioritize
it
high
enough
to
fix
it
so
again
make
the
case
for
dealing
with
the
the
point
at
which
the
vulnerabilities
introduce,
which
is
in
development
and
fixing
it
there
in
a
procedural
method,
methodological
way
systematic
way
as
part
of
the
sdlc.
A
Now,
what
are
we
good
at
and
what
are
we
not
good
at
we're
good
at
the
workflow,
we're
good
at
it.
We're
starting
some
integration,
so
white
source
has
done
an
integration
with
this
there's
a
few
others
snakes
on
a
type
they've
done
them.
They
haven't
necessarily
done
them
in
the
most
eloquent
way
that
we
would
want
and
we
are
working
towards
making
it
where
it's
more
clear
how
they
need
to
integrate
with
us
having
some
standards
there.
So
those
integrations
weisswurst
has
done
a
really
good
job.
A
The
right
way,
where
are
we
not
good
at
well
that
head-to-head
comparison
is
a
problem
and
mostly
because
it
gets
into
a
religious
argument,
because
if,
if
a
security
person
went
out
on
a
limb
and
told
their
CIO
or
their
C,
so
I
need
to
spend
a
million
dollars
to
buy
fortify
or
to
buy
very
code.
They've
bet
their
career
on
that
they're,
not
gonna,
go
back
and
say:
oh,
never,
mind,
we
don't
need
it
now.
We've
got
this
other
tool
that
you
know
so
they're
not
going
to
do
that.
A
There's
there's
some
emotional
ties
to
it.
So
don't
get
into
that
head-to-head
argument.
Ok
talk
about
the
workflow
and
how
we
can
supplement,
there's
a
perception
among
security
people
that
open-source
scanners
are
inferior.
That
study
I
showed
on
that
one
slide
kind
of
shows.
Maybe
maybe
not
you
know
there
might
be
better
in
some
areas
and
weaker
in
others
and
as
a
middle-of-the-road,
they're
great
approach,
but
I
can't
just
kind
of
avoid
that
head-to-head
comparison.
A
A
A
A
This
is
on
the
group
dashboard.
Is
this
a
through
F
academic
grading
scale?
So
if
they
were
they're
worried
about
managing
risk
go
to
the
F
projects?
Those
are
the
ones
that
have
the
poorest
grades
on
as
opposed.
You
know
for
risk
and
then
again
drill
down
into
that
in
our
widget
itself,
so
that
they
reinforce
the
point
that
it's
single
source
of
truth
everybody's.
Looking
at
the
same
information,
one
last
point
here
around
defend
we're
not
really
talking
about
defend
from
a
secure
DevOps
standpoint.
A
Just
yet,
but
know
that
it's
out
there
we
do
have
a
laugh
that
focuses
on
kubernetes
ingress.
At
the
moment
we
want
to
be
the
best
for
cloud
native
applications,
and
so
that's
where
we're
really
headed
first,
but
you
can
have
a
look
at
that.
There's
some
Salesforce
resources
I
want
to
make
sure
that
you're
aware
of
there's
a
sales
resource
page
you
should
be
familiar
with
and
on
that
page
is
not
only
the
pitch
deck
but
there's
a
security
overview
deck
as
well.
A
A
Even
though
we
we
are
shifting
down
SAS
and
some
other
scanners
into
the
lower
tiers,
the
PM's
are
putting
together
a
page
that
is
going
to
give
you
more
information
about,
what's
retaining
being
retained
in
ultimate,
so
that
you
have
a
better
sense
for
the
value
that
we
bring.
It's
again
goes
back
to
the
workflow.
It's
not
wrapped
up
in
the
scanners
themselves.
You
can
put
in
it
our
scanner,
somebody
else's
scanner.
It
doesn't
matter
it's
that
workflow.
That's
really
important!
A
There
is
a
slide
in
here.
What's
coming
in
ultimate
and
in
this
area
gets
into
these.
These
two
boxes
here
at
the
bottom,
what's
focused
on
secure
and
defend.
That's
that's!
Coming
that's
going
to
continue
to
bring
more
value
on
the
ultimate
side,
and
one
last
thing
is
Brian.
Wald
showed
he
has
put
together
a
flow
chart
more
like
a
root
cause
analysis
of
what
are
the
barriers
to
ultimate
and
you
put
that
in
the
slack
Channel
if
you
would
and
in
it
the
link
is
also
down
here
in
the
notes.
A
If
you
would
go
to
that
and
see
if
it's
complete,
if
there's
other
barriers
that
you
encounter,
please
let
Brian
know
add
it
to
the
issue
or
put
it
in
the
selling
ultimate
select
channel.
So
hopefully
you
found
this
useful
for
you,
and
certainly
you
can
reach
out
to
me
any
time
with
questions
or
to
David
de
Santo
who
leads
the
PM's.
You
know
we've
ramped,
that
team
I
used
to
have
1
p.m.
to
interface
with
and
now
there
are
I
think
six
plus
David.