►
From YouTube: GitLab at AWS re:Inforce 2023 - Using Human Habits to Accelerate DevSecOps Maturity and Increase Joy
Description
Recent research and writing strongly suggests "Habits Can Move Mountains... Efficiently". It appears habit changes can do so at a low marginal cost while also improving quality of life.
This sessions articulates and demonstrates how GitLab DevSecOps:
- Increases Developer Flow and Joy through low friction processes.
- Fundamentally aligns with positive human habit psychology research and why it matters.
- Precisely inserts process automation innovations in existing workflows.
- Gives critical "rich context" to tap into existing motivations for voluntarily remediation.
- Is a true “shift left” through empowerment and accommodation of Developers normal workflow.
- Facilitates the fundamental human need for low friction collaboration.
Table of Contents:
00:00 - Introduction
00:19 - Overview: Business as Usual Habits
02:27 - Platform-First Shifting Architecture Left
06:42 - The Power of Platform First Development
08:01 - The Power of Habits
08:35 - Stacking Vulnerability Remediation Habit
12:39 - Empowered Shift Left
16:58 - GitLab DevSecOps Workflow Automation
21:18 - Merge Request View
24:51 - Rich Context Guides Behavior
28:50 - DevSecOps Maturity Planning
34:18 - Rich GitOps Deployment Controls
35:27 - Summary Wrap up
A
Hello:
everyone,
my
name
is
Darwin
sonoy
I'm,
a
partner
Solutions
architect
at
get
lab
alliances.
Today,
I
want
to
talk
to
you
about
frictionless
devsecops.
How
gitlab's
authentic
empowered
shift
left
allows
us
to
accelerate
devsec
Ops
maturity
and
improve
developer
Joy
at
the
same
time.
So,
let's
Dive
Right
In
during
the
course
of
our
session,
we're
going
to
take
a
look
at
several
factors
that
build
up
into
business
as
usual,
habit
by
software
developers
as
they're
building
out
their
software.
They
consider
vulnerabilities
to
be
just
another
defect.
A
One
of
the
aspects
of
this
is
getting
inside
of
the
developer's
habit.
Loop
there's
some
very
powerful
writing
on
habit
loops
and
how
they
work.
It
turns
out
that
in
devsec
Ops
we
already
have
one
of
those
habit
loops
and
we
can
simply
stack
remediation
management
inside
of
that
context,
and
timing
are
also
crucial.
It
turns
out,
when
you
present
the
opportunity
to
fix
problems
of
software
at
the
right
time.
It's
very
easy
to
get
people
to
engage.
A
We
also
want
to
talk
a
little
bit
about
how
transparent
responsibility
really
motivates,
and
this
is
natural
to
the
place
in
the
cycle
where
git
lab
addresses
vulnerability.
Remediation
collaboration
in
real-time
learning
are
important
matters
that
gitlab
handles
in
process,
so
that
developers
can
keep
working
and
collaborating
about
challenging
situations.
They
might
need
to
resolve
with
security
problems
and
then
finally,
gitlabs
only
when
necessary.
Approvals
reduce
friction
and
noise
in
the
entire
process,
because
security
only
needs
to
get
involved
when
there's
truly
something
that
goes
out
of
thresholds.
A
So
in
many
devsecops
organizations
we
see
a
challenging
pattern.
Gitlab
has
established
that
devops
as
a
platform
is
a
great
way
to
ensure
that
your
devops
is
clean,
consistent
and
unified
across
the
organization,
but
for
some
reason
within
Dev
secops
many
organizations
still
start
from
scratch.
So
we
end
up
seeing
something
like
this,
where
a
lot
of
different
tooling
is
linked
together,
collaboration
is
manual
or
out
of
band,
so
it's
kind
of
an
organic
approach
to
the
SEC
part
of
devsecops.
Gitlab
really
feels
that
you
should
start
from
platform.
A
So,
instead
of
starting
from
scratch,
we
want
to
start
from
platform
and
gitlab's
platform
is
importantly,
an
extensible
platform
developers
really
demand
that
their
platforms
be
capable
of
extension
at
various
different
levels
to
make
sure
that
they
can
tailor
them
to
what
they
need
and
gitlab
as
a
platform
as
well
as
its
devsecop
solution
are
both
extensible.
In
this
way,
a
lot
of
things
in
our
industry
that
seem
to
be
new
are
also
old.
At
the
same
time,
so
we
have
something
called
undifferentiated
heavy
lifting.
A
When
we
talk
about
operations
in
reality,
developers
haven't
actually
been
doing
undifferentiated
coding
via
platforms
for
quite
some
time,
I'm
going
to
call
this
shifting
architecture
left,
because
what
it
does
is
bring
entire
architectural
patterns
further
to
the
left
of
the
process,
so
that
when
we
work
with
these
systems,
we're
able
to
look
at
them
as
entire
systems
instead
of
pieces
and
parts.
So
let's
take
an
example:
if
we
look
at
something
like
the
Ruby
programming
language,
it
is
a
very
rich
programming
language.
A
It
allows
us
to
do
a
lot
of
things,
but
anytime
we
have
a
Computing
language
developers
quickly
start
to
collaborate
because
they
notice
they're,
rewriting
the
same
code
as
people
in
other
organizations
or
in
their
same
organization
and
So
within
Ruby.
Like
many
languages,
we
have
a
dependency
manager
with
shared
code,
libraries
and
Ruby.
A
This
is
called
rubygems,
and
this
allows
us
to
consume
code
that
others
have
written
tested
and
continue
to
maintain
that
we
can
just
depend
on
so
that
we
don't
have
to
keep
writing
code
for
the
same
things
again
and
again
across
projects
and
across
organizations.
In
the
case
of
Ruby
2,
we
have
another
layer
of
platforming
or
frameworking,
which
is
Ruby
on
Rails,
an
application
framework.
This
takes
care
of
even
broader
base
concerns
about
how
to
do
an
application
or
in
a
given
part
of
it.
A
So
let's
say
that
we
have
an
application
and
we
realize
that
we
need
to
have
some
database
storage
to
persist.
Certain
attributes
of
the
information
developers
who
are
working
from
platform
go
to
the
top
or
most
abstract
level,
or
what
we
might
call
the
the
leftmost
level
in
order
to
understand.
Is
there
something
here
already
so
if
they
find
that
in
Rubio
and
rails
they
have
a
complete
database
management
set
of
libraries
and
code
that
manage
a
lot
of
extraneous
concerns
that
they
may
or
may
not
be
already
familiar
with
with
a
certain
database?
A
A
If
ruby
gems
aren't
satisfactory
well,
then
of
course
they're
going
to
have
to
code
something
up
in
the
Ruby
language,
similar
to
their
standard
application
code
and
if
they're
thinking
forward
toward
platforming,
they
might
actually
code
those
as
ruby
gems,
so
they're
immediately
reusable
versionable
and
have
all
the
benefits
of
dependency
management
that
any
other
gems
that
they
consume
have.
So
this
kind
of
approach
to
coming
from
the
top
down
the
most
abstract
level
to
find
functionality
that
might
work
is
something
developers
are
very
familiar
with
now.
A
A
Let's
take
a
bit
of
a
dive
into
why
extensible
platforms
give
a
lot
of
power,
so
it's
very
typical
for
developers
to
start
with
some
small
custom
Nuggets
of
code
and
then
over
time
build
a
large
custom
code
base
now
for
the
actual
application
that
you're
creating
this
customer
facing.
This
is
perfect.
We
really
want
to
start
small,
build
on
that
success
and
grow
it
into
something
that
the
customer
finds
valuable.
A
The
challenge
is
that
when
we
do
this
for
something
where
we
can
adopt
a
platform
first,
it
largely
ends
up
being
distracting
over
engineering
of
something
that
we
do
not
need
to
code
ourselves.
So
a
platform
first
approach
means
that
we
look
at
the
platforms
we
have
available
to
us
and
try
to
understand
if
it
has
the
capability
that
we
need-
and
we
use
that
if
it
does
then
over
time,
if
necessary
and
when
necessary,
we
make
minimal
custom
extensions
to
that
platform
in
order
to
facilitate
things
that
it
doesn't
currently
facilitate
directly.
A
So
this
is
sort
of
a
lean
engineering
approach
where
we
put
platforming
first
and
we
make
sure
that
we
take
advantage
of
the
platforms
that
we
have
available
to
us.
So
in
the
area
of
devops.
Gitlab
really
feels
that
this
is
the
way
that
you
want
to
approach.
This
is
to
do
Platform
first,
so
I
wanted
to
talk
a
little
bit
about
platform
first,
because
it's
such
a
large
part
of
how
gitlab
solves
the
devsecops
problem.
A
So
recently,
there's
been
a
lot
of
excitement
about
habits.
Some
really
good
books
have
been
written,
and
it's
very
evident
that
when
humans
make
small
tweaks
to
their
daily
routines,
it
can
make
very
big
effects
in
their
lives
over
time,
and
this
actual
effect
isn't
just
true
of
how
we
do
our
personal
habits.
A
We
want
to
talk
about
how
at
gitlab
we
do
an
empowered
shift
left.
This
means
that
we
shift
a
very
strategic
set
of
capabilities
left
to
ensure
that
the
people
who
are
involved
in
remedying
vulnerabilities
have
everything
they
need
at
the
right
time
within
gitlab.
The
idea
of
shift
left
includes
having
direct
and
clear
responsibility
for,
what's
going
on
when
a
developer
is
looking
at
their
merge
request,
that
is
only
for
code
that
they've
changed.
A
So
if
a
vulnerability
appears
it's
new
and
wasn't
there
before,
they
know
that
they
have
actually
introduced
that
vulnerability,
and
this
is
cleared
across
the
entire
system
because
it's
their
commit
their
merge
request
and
their
Branch
that's
being
worked
on.
So
responsibility
is
early,
clear
and
easy
to
identify
for
everyone,
including
the
developer.
Studies,
have
shown
that
developers
are
very
interested
in
generating
high
quality,
very
secure
code.
They
don't
want
to
be
that
person
that
causes
some
sort
of
vulnerability
in
the
system.
A
There's
also
the
factor
of
timing.
As
we
talk
here,
I'm
going
to
show
you
how
we
have
the
right
timing,
when
developers
can
consider
fairly
substantial
changes
to
software
without
a
lot
of
impact
to
their
process,
then
we're
having
the
right
tools
at
that
time
is
also
critical
and
gitlab
allows
a
lot
of
additional
tooling
it's
training
at
this
time.
So
gitlab
has
some
just
in
time
or
on-demand
training
for
given
vulnerabilities,
it's
very
specific
to
that
vulnerability.
A
So
if
developers
want
to
grow
their
capability
to
understand
that
vulnerability,
well,
then
they
can
Dive
Right
In
and
learn
about
it
and
there's
even
some
gamification
in
some
of
the
training
providers.
Collaboration
super
important.
We
all
know
that
collaboration
is
important,
but
when
we
start
trying
to
collaborate
in
two
three
four
five
different
systems,
it
starts
to
become
unmanageable.
If
you've
ever
had
vulnerabilities
being
shared
in
spreadsheets
and
emails
and
documents,
it
ends
up
being
quite
a
mess
just
getting
on
the
same
page.
A
So,
within
this
context,
gitlab
allows
its
full
collaborative
capabilities
to
be
extended
into
remediating
vulnerabilities
and
then
of
course,
approvals.
So
while
we
want
to
fully
empower
the
developer,
we
want
to
make
sure
that
the
right
approvals
are
in
place,
so
that
code
that
goes
out
meets
the
company's
quality
standards
and
approvals
and
security
standards.
All
of
the
things
that
need
to
be
met.
So
when
we
bring
all
of
these
things
left,
we
have
a
much
better
picture.
A
If
we
take
a
look
at
typically
how
this
happens,
we
haven't
assembled
ready
to
go
product
and
then
developers
are
told
about
the
problems
that
we
have.
Potentially,
from
a
security
perspective
at
this
point,
there's
many
presenting
problems
and
many
people
and
teams
involved
so
diffuse
responsibility.
Lots
of
challenges,
lots
of
Desire
not
to
take
this
apart,
swap
out
some
parts
and
then
redo
all
the
testing
to
see.
A
If
it's
going
to
work
again,
the
challenge
with
presenting
this
capability
of
the
security
scanning
at
this
time,
is
it
a
compounded
from
a
situation
that
was
not
only
natural
but
much
easier
to
address
this
problem?
So
if
you
think
about
the
time
when
a
developer
is
working
on
individual
functionality,
frequently,
this
is
done
by
an
individual
person,
who's
collaborating
with
their
peers.
A
If,
at
this
point,
we
point
out
that
something's
faulty
that
has
been
introduced
to
the
system-
well,
it's
not
too
big
of
a
deal
to
swap
it
out
because
we're
still
in
the
mix
of
trying
to
get
the
functionality
working.
So
if
making
something
more
tight
on
security
breaks,
something
functionally
what
we
have
time
in
order
to
dig
through
that
and
to
fix
it
up.
So,
on
the
right
side,
we
have
kind
of
what
I
call
a
big
ball
of
mud
context
and
on
the
left
side
we
have
a
very
pinpointed
responsibility
with
good
timing.
A
We
still
do
need
that
traditional
type
of
scanning
as
we'll
talk
about
in
a
minute,
but
if
it's
our
only
type
of
scanning,
then
we
run
into
this
late
problem.
This
also
affects
developers
literal
daily
happiness
at
work,
because
when
you
have
these
problems
discovered
late,
it's
very
stressful,
usually
the
deadlines
are
not
moved
and
if
something
has
to
change,
it
starts
to
eat
into
the
developer's
quality
of
life.
So
this
is
a
good
win-win
situation
for
everyone
all
around.
A
Let's
talk
a
little
bit
about
human
habit,
psychology
and
how
gitlab
is
taking
advantage
of
some
of
the
new
ideas
and
new
discoveries
in
human
habit.
Psychology.
Some
of
this
is
discussed
in
the
book
Atomic
Habits
by
James
Clear.
First
we're
going
to
just
go
through
kind
of
what
a
a
habit
destroying
situation
looks
like
turns
out
the
same
things
that
you
would
do
to
never
build
a
habit
are
exactly
the
same
things
you
do.
If
you
have
a
bad
habit,
you
want
to
destroy
or
tear
down.
A
When
there's
out
of
context
consoles
hard
communication
unclear
responsibility.
All
these
kind
of
things
that
happen
late,
all
cause
that
routine
of
you
know
engaging
in
vulnerability,
remediation
management
to
be
very
difficult
for
any
person,
then,
as
a
routine,
is
completed,
it's
important
with
habit
Loops
to
have
some
sort
of
reward,
and
it's
very
typical
for
these
kind
of
things
to
be
unsatisfying
in
the
case
of
traditional
remediation
management.
A
So
all
of
these
aspects
and
invisible,
cue,
difficult
engagement
and
an
unsatisfying
reward
all
cause
a
habit
to
never
form
and
in
fact,
can
be
used
to
dismantle
a
habit.
Let's
take
a
look
at
the
positive
Loop
and
then
how
gitlab
takes
advantage
of
this
existing
positive
Loop
within
developers,
everyday
work,
so
a
habit
or
context
queue
needs
to
be
obvious
and
within
the
normal
working
day
of
a
developer.
Pushing
code
is
an
obvious
cue.
A
When
they
push
that
code,
we
have
a
routine
and
generally
that
routine,
that
is
engaged
is
resolving
build
failures.
So
you
get
feedback
from
the
system
on
whether
everything's
passing.
If
there's
been
any
problems
created
by
the
most
recent
push
of
code-
and
you
resolve
those
build
failures,
all
happening
within
the
context
of
a
merge
request
in
gitlab,
then.
Finally,
we
have
that
reward
and
in
gitlab
that
satisfying
capability
of
seeing
those
clean,
build
check
boxes.
So
the
more
green
check
boxes.
We
see
the
more
satisfied.
A
A
Loop
now
within
Atomic
habits,
there's
something
called
habit
stacking,
which
means
that,
instead
of
having
to
establish
a
whole
new
Loop,
say
looking
in
a
different
place,
engaging
with
different
information
reports
and
consoles
and
then
having
to
understand
that,
once
you've
resolved
that
there
may
or
may
not
be
some
sort
of
celebration
of
that
in
git
lab.
We
simply
stack
vulnerability.
Remediation
management
right
into
the
merge
request,
so
essentially
we're
taking
an
important
process
or
routine
and
simply
taking
advantage
of
an
existing
habit
Loop.
A
So
this
is
a
very
powerful
way
to
motivate
people
to
get
into
that
vulnerability.
Remediation
habit,
Loop.
It
also
improves
the
joy
of
the
process,
because
now
not
only
does
this
become
more
internalized,
but
software
vulnerabilities
are
just
seen
as
another
defect
and
they're
rewarded.
With
that
clean
build
check
mark.
It
also
causes
things
to
be
addressed
early,
so
developers
don't
have
fire
drills
when
they're
coming
up
to
a
major
release
of
the
software.
A
So
many
of
us
are
familiar
with
the
developers
daily
habit,
Loop
of
pushing
code
getting
build
feedback
looking
at
what
needs
changed,
fixing
that
up
getting
that
satisfying
feedback
that
this
the
code
is
improving,
becoming
more
functional
and
also
is
quality
code.
But
let's
take
a
look
at
how
this
fits
into
the
overall
git
lab
process
and
some
important
aspects
of
how
that
works.
So
gitlab
has
multiple
stages
through
which
development
is
tracked.
These
equate
to
the
devops
infinity
loop
of
continuous
Improvement
and
within
gitlab.
A
We
have
the
capability
to
do
work
management
that
work
management
is
expressed
in
many
different,
agile
artifacts,
which
can
also
be
used
for
other
types
of
work
management.
But
one
of
the
key
points
is
when
we
come
down
to
the
point
in
which
a
developer
is
going
to
start
work
in
gitlab,
you
create
a
merge
request
and
a
branch
at
the
same
time
inside
of
gitlab,
so
that
all
work
is
visible.
A
When
you
do
that,
essentially,
you
are
pushing
code
to
that
Branch
right
away,
because
you're,
making
a
copy
of
the
main
branch
and
the
automated
test
and
build
capabilities
start
kicking
in
right
away.
One
of
the
important
parts
here
is
creating
a
environment
completely
transparently
without
anyone's
intervention
and
environments
created.
Gitlab
has
this
capability
out
of
the
box
for
any
kubernetes
distribution.
A
I
have
built
it
out
for
cloud
formation
and
I'm
working
on
building
it
out
for
serverless.
This
capability
is
really
important,
because
developers
no
longer
have
additional
friction
around
getting
environments
now.
The
reason
why
an
environment
is
important
is
if
we're
going
to
do
all
types
of
security
scanning,
so
dast
I
asked
fuzzing
all
the
types
that
require
an
active
copy
of
the
application.
Well,
then,
we
need
to
make
that
available
to
developers
at
this
point
in
their
their
cycle
of
development.
It's
important
to
note
too.
These
are
devops
environments.
A
Devops
environments
are
deployed
where
production
environments
are
deployed,
so
each
developer
can
have
a
production-like
environment
on
just
their
feature.
Branch
gitlab
also
supports
Dev
environments
and
these
kind
of
work
ahead
of
time
before
we
hit
a
devops
environment,
but
those
work
together
and
also
in
gitlab,
you
can
still
have
shared
branches
with
shared
pre-production
environments
as
well,
but
gitlab
is
unique
and
then
it
pushes
it
all
the
way
back
to
that
developer
feature
Branch
time
frame.
We
then
also
have
collaboration
over
all
aspects
of
code,
including
security,
and
then
developers
have
this
remediation
management.
A
That's
basically
a
single
pane
of
glass.
In
that
merge
request,
they
can
see
everything
that's
going
on
with
the
code
changes
they're,
proposing
making
as
a
get
feedback,
and
they
push
fixes.
This
environment
is
refreshed
and
it's
rescanned
so
that
they
can
get
those
green
check
boxes
on
a
vulnerability
they
might
have
just
introduced
minutes
ago
when
they
get
the
final
approvals
that
all
their
code
is
good
to
go
in
all
aspects,
including
security.
Then
they
merge
this
branch
and
delete
it
and
when
they
do
that,
merge
delete
the
environment's
automatically
cleaned
up.
A
So
a
lot
of
folks
are
like
hey:
yeah
developers
are
never
going
to.
Let
us
automatically
delete
their
environments,
but
usually
that's
because
it's
so
hard
for
a
developer
to
get
an
environment.
It's
simply
creating
a
branch
causes
a
new
environment
to
come
into
existence,
they're,
really,
okay,
with
deleting
them
as
soon
as
that
code
is
merged,
because
a
new
one
is
just
a
branch
away.
So
just
keep
in
mind
that
this
aspect
of
transparently
managing
devops
environments
in
the
background
is
really
fundamentally
important
to
how
gitlab
manages
vulnerabilities.
A
So
we
also
have
some
aspects
of
this
that
are
extensible.
Like
we
mentioned
about
this
being
an
extensible
platform,
you
can
bring
your
own
scanner
extension.
We
tell
you
in
our
documentation
how
to
make
one.
You
can
also
build
out
your
own
devops
environment
extension
as
I've
done
for
cloud
formation.
Another
aspect
of
git
lab
is
that,
while
all
of
what
we've
been
talking
about
right
now
is
all
about
developer
productivity
developer,
Joy
gitlab,
because
it
focuses
on
value
stream.
A
Metrics
is
really
customer
value
focused,
so
at
the
next
level
up
in
the
organization,
we
can
keep
everyone
focused
on
generating
customer
value,
even
while
also
managing
these
important
productivity
metrics.
So
that's
just
an
overview
of
how
gitlab
and
some
of
its
additional
capabilities
fit
into
making
vulnerability
remediation
management
just
another
defect
that
developers
can
work
on
here
we
have
the
venerable
gitlab
merge
request
view.
Now
this
view
is
what
I
call
the
single
pane
of
glass
for
developers.
A
It
tells
them
a
lot
of
information
about
what
is
going
on
with
their
software
as
they're
building.
Interestingly,
a
lot
of
this
is
interactive.
It's
not
simply
a
log
of
things
that
have
been
done
or
things
that
could
be
done
and
it
keeps
the
developer
in
this
context.
So
if
we
take
a
closer
look
at
what's
going
on
here,
we
have
down
here
the
vulnerabilities
and
they're
presented
right
here
in
the
interface.
A
These
are
interactive,
so
each
of
these
Blue
Links
can
be
interacted
with
and
you
can
open
up
the
vulnerability
object
on
their
developers
can
do
things
such
as
assert
information
like
I.
Don't
think
I
should
have
to
work
on
this
because
I
don't
know
it's
a
back
end
component
that
we
never
expose
to
the
web,
and
this
is
a
web
vulnerability
or
we
never
use
that
bit
of
code
that
is
vulnerable
in
this
particular
component.
A
A
When
you
open
up
a
vulnerability
object,
you
have
all
the
details
of
exactly
where
it
what
it
is
a
link
to
the
cve
and,
interestingly,
a
link
to
real-time
training,
so
that
you
can
dig
in
and
train
more
if
you
need
to
by
creating
a
gitlab
issue
from
one
of
these
vulnerabilities
you're
able
to
then
have
the
full
collaborative
capabilities
of
gitlab
available
to
you.
This
is
paired
together
with
threshold-based
approval
rules.
A
These
two
approval
rules
license
check
and
vulnerability
check
are
very
special
in
that
they
only
come
into
effect
if
a
certain
policy
is
violated.
So
in
this
case
the
vulnerability
check
rule
will
only
be
triggered
if
the
developer
is
trying
to
merge
a
high,
medium
or
unknown
level
vulnerability
into
the
next
branch,
which
is
usually
going
to
be
a
shared
branch,
and
so
this
allows
security
to
have
a
lightweight
approach
and
only
come
in
when
necessary.
A
A
If
we
take
a
little
bit
deeper
dive
into
these
threshold-based
rules
that
you
can
see
here
that
I'm
able
to
specify
specific
scanners,
including
custom
scanners,
I'm
able
to
specify
a
threshold
of
how
many
account
of
how
many
of
certain
vulnerability
levels
are
allowed,
so
we
can
also
identify
what
level
of
vulnerabilities
allowed
and
whether
they're
newly
detected
or
previously
in
the
code
so
generally
in
gitlab.
You
want
to
get
the
developer
focused
on
newly
detected
things
that
they've
accidentally
introduced
in
their
code,
and
then
we
can
Define
that
approval
rule.
A
So
this
is
a
really
cool
capability
in
gitlab
that
allows
you
to
really
narrow
down
on
the
lightest
possible
weight
governance,
but
make
sure
that
governance
is
indeed
there.
So
that
was
a
lot.
Let's
summarize,
what
is
going
on
here
in
the
book?
Atomic
habits,
James
Clear,
says
environment
is
the
Invisible
Hand
That
shapes
human
behavior
and
really,
when
you
think
of
an
environment,
it's
got
very
rich
context.
A
So
when
you're
in
an
environment,
there's
a
lot
of
cues
and
clues
about
what
exactly
situation
you
are
in,
and
so,
if
we
think
about
environment
that
way,
we
can
think
about
the
merge
request
as
an
environment.
What's
going
on
in
git
lab
when
a
developer
is
trying
to
manage
their
vulnerabilities
inside
of
a
merge
request.
Is
that
within
their
everyday
habit,
Loop
that
they're
always
working
in
for
code
changes
they
made
moments
ago.
So
this
is
for
recent
stuff
that
they've
changed.
Only
newly
introduced
vulnerabilities
are
immediately
visible
and
directly
Associated
to
that
individual.
A
So
they
know
that
oh
I
made
this
particular
vulnerability.
I
should
probably
address
it.
They
have
a
semi-private
remediation
opportunity,
so,
unlike
scanning
on
shared
branches,
where
every
vulnerability
that
comes
up
is
concerning
and
there's
a
lot
of
thought
and
exposure
when
we
have
vulnerabilities
in
feature
branches,
we're
not
really
that
concerned
about
them,
because
it's
not
code,
that's
going
anywhere.
A
They'll
know
whether
their
code
continues
to
work
so
that
remediation
opportunity
is
semi-private
and
allows
them
to
work
and
eliminate
vulnerabilities
at
their
normal
pace
of
fixing
code
defects.
They
also
have
potentially
Auto
remediations
and
on-demand
training
available
to
them.
In
that
context,
we
don't
have
Auto
remediations
for
everything,
but
it
is
an
aspect
of
how
gitlab
allows
developers
to
remediate
things
when
it's
a
simple
fix,
such
as
upgrading
an
open
source
component.
A
We
also
have
per
vulnerability
full
collaboration
capabilities,
so
the
ability
to
understand
and
have
the
entire
team
pitch
in,
if
necessary,
when
a
developer
is
struggling
with
some
sort
of
fix
or
a
security
problem
that
they're
not
familiar
with
notice
that
in
this
way,
remediation
management
defaults
to
the
developer.
Now
we
say
remediation
management
we
mean
who's
responsible
to
make
sure
vulnerabilities
get
resolved.
A
Developers
always
have
to
be
the
ones
who
actually
code
the
fixes,
because
there's
a
high
chance
that
they'll
cause
some
sort
of
issue
with
the
code,
and
so
developers
really
are
the
only
ones
who
can
apply
remediations
to
their
code
and
successfully
keep
the
code
working.
But
who
manages
that
process
and
make
sure
that
gets
done.
This
causes
that,
to
shift
to
the
developer
and
in
a
good
way,
developers
like
to
create
high
quality
code,
they
are
crafts,
people
who
love
high
quality,
craftsmanship
and
so
they're
more
than
happy
to
engage
at
this
time.
A
With
this
information
and
this
kind
of
empowering
tool
set
now
on
the
traditional
remediation
management,
almost
all
of
these
particular
things
are
opposite,
so
visibility
is
late
and
delayed.
Responsibility
might
be
diffuse,
alerting
is
Broad
and
panic
oriented.
So
all
of
this
causes
remediation
to
be
a
lot
harder.
A
The
collaboration
is
especially
challenging
with
emails
and
meetings
and
documents,
and
just
trying
to
figure
out
if
something's
already
been
fixed
in
this
case
for
mediation
management
generally
defaults
to
the
security
staff,
and
this
is
because
they're
the
ones
who
run
these
reports
and
also
then
take
responsibility
to
move
through
the
organization
to
make
sure
that
these
things
get
handled
to
be
quite
clear.
Gitlab
has
traditional
remediation
management
built
in,
and
you
do
need
that,
so
that
your
development
teams
also
get
interested
in
paying
down
Tech
debt.
A
In
the
case
of
security,
maybe
some
medium
vulnerabilities
they
can
get
rid
of
or
other
ways
that
they
can
improve.
The
software's
security
profile
secret
lab
still
has
traditional
remediation
management,
but
it's
pushing
remediation
management
all
the
way
to
an
empowered
shift
left
that
causes
gitlab
to
be
truly
different
in
this
area.
A
I
want
to
spend
just
a
little
bit
of
time
talking
about
how
gitlab's
approach
to
this
causes
you
to
be
able
to
accelerate
devsec
Ops
maturity
as
an
organization.
So
this
small
idea
of
making
sure
that
we
have
alignment
with
human
habits
bubbles
up
to
very
big
benefits
in
terms
of
devsecops
maturity
as
an
entire
organization.
We
encourage
you
to
have
devsecops
maturity,
be
something
that
you
plan
the
approach
of
kind
of
getting
started
on.
A
Something
is
really
helpful
for
a
lot
of
things,
but
in
the
case
of
devsecops
maturity,
it's
going
to
be
important
to
plan
it,
because
there's
literally
no
end
to
the
amount
of
investment
you
could
make
in
this
area,
because
it's
a
risk
versus
cost
trade-off.
So
when
you
need
to
make
those
Investments
it's
best
to
have
some
sort
of
idea,
what
you
believe
devsecops
maturity
is
an
organization
so
that
you
can
plan
when
you
hope
to
get
there
and
you
can
make
the
right
resource
Investments.
A
When
this
doesn't
happen,
customers
don't
start
to
run
into
a
lot
of
challenges
as
well
as
we'll
see
here
generally
for
most
organizations,
devsec
Ops
maturity
means
more
teams
doing
more
types
of
scanning,
more
often
from
more
lines
of
code
for
more
of
the
languages
in
their
growing
total
code
base.
So
it
generally
means
doing
all
of
these
things
more
and
earlier
in
order
to
ensure
that
we're
eliminating
things
as
soon
as
possible
or
really
eliminating
them
before
they
ever
get
into
the
code.
A
It
gives
you
a
broad
measure
of
really
how
complicated
is
our
process,
so
that
developer
learning
curve
is
an
important
aspect
of
friction
against
devsec
Ops
maturity,
then
having
to
manage
and
maintain
anything
that
you've
bought
or
even
if
it's
free,
if
you've
stood
up
subsystems
to
to
perform
parts
of
this
process.
The
long-term
management
of
the
Ops
of
that
is
also
potentially
substantial.
A
You
then
have
the
code
base
growths
code.
That's
generating
money
for
companies
is
generally
growing,
as
they
add
new
customer
valuable
features.
Usage-Based
pricing
is
another
thing
that
customers
sometimes
don't
see.
Coming
I
heard
of
one
organization
that
tried
out
a
security
product
in
a
proof
of
concept,
they
got
a
bill
for
30k
that
year,
but
then,
when
they
went
to
scale
it
to
all
of
the
scanning
that
they
would
need
in
a
year,
the
price
tag
was
north
of
a
million
dollars.
A
So
it's
important
to
watch
those
usage-based
schemes
that
charge
you
for
the
amount
of
code
you
scanned
in
a
way.
They
start
to
penalize
you
for
getting
better
and
Tighter
and
sooner
in
this
Loop
of
finding
vulnerabilities
and
then
anytime,
your
processes
aren't
automated.
It's
a
real
Challenge
and
the
way
you
can
tell
when
your
processes
aren't
automated
is
when
the
process
of
getting
something
done
is
very
belabored
external
to
the
system.
A
So,
whenever
we're
managing
remediation
of
vulnerabilities,
if
that
involves
a
lot
of
spreadsheets
emails
and
meetings
consoles
and
Concepts
and
reports,
that's
when
you
can
see
that
you
don't
have
an
automated
process
now.
All
of
these
are
stumbling
blocks
and
are
painful,
but
they
also
represent
a
total
cost
of
ownership
curve
that
is
hockey
sticking
many
organizations
with
they
don't
pre-plan
devsecops
maturity.
A
They
head
on
down
this
road
and,
at
certain
point
they're
told
they
must
stop
due
to
escalating
costs,
whether
it's
hires,
whether
it's
software
licenses
or
operations,
so
just
keep
in
mind
that
we
tend
to
see
that
this
concept
of
roadblocks
is
also
causing
a
lot
of
cost
in
the
system.
So
with
gitlab.
A
We
feel
that
doing
it
yourself,
devsecops
can
result
in
compounding
penalties
for
getting
better,
getting
more
mature,
so
make
sure
that
whatever
you're
doing
now,
you
kind
of
plot
it
out
and
understand
where
this
curve
is
going
before
you
get
too
far
down
the
road.
Now,
by
contrast,
gitlab's
curve
is
flat
and
the
reason
for
that
is
you're
charged
by
the
number
of
developers.
Usually,
your
developers
are
a
predictable
metric
back
to
the
value
generating
activities
of
your
organization.
A
If
you've
got
some
old
code
bases,
you
don't
change
much,
but
you
need
to
keep
them
secure
and
new
code
bases
that
you're
keeping
secure
well.
The
number
of
developers
working
on
that
is
a
reasonable
measure
of
productive
work.
That's
going
on
so
I
always
like
to
ask
customers.
You
know
when
you
look
at
the
big
shiny
Factory
that
is
gitlab,
devsecops
and
you're,
comparing
it
to
some
sort
of
you
know
new
MVPs
of
securing
your
software.
A
We've
been
talking
a
lot
about
the
development
process,
but
I
just
want
to
give
a
quick
head
nod
to
get
Ops.
So
gitlab
has
been
doing
git
Ops
for
traditional
infrastructure
for
a
long
time,
and
as
this
slide
is
building
out,
you
will
see
a
bunch
of
purple
boxes.
Each
of
these
purple
boxes
represents
ways
of
gaining
control
over
the
aspect
of
software
development
to
make
sure
that
it's
high
quality.
The
purple
boxes,
though,
apply
not
only
to
getting
your
code
ready
for
integration
and
review,
which
is
our
green
Branch
here
on
the
screen.
A
It
also
can
apply
to
one
or
more
devops
environments,
which
is
the
orange
Branch.
You
see
on
the
screen,
so
keep
in
mind
that
gitlab
has
a
lot
of
additional
protections,
both
those
that
exist
in
traditional
git
and
then
down
here
below
the
Orange
Line,
a
lot
of
additional
controls
that
allow
you
to
make
sure
that
deployments
are
going
to
the
right
places
when
you
want
them
and
with
the
right
approvals
and
right
controls.
A
A
So
what
we've
been
talking
about
today
is
transforming
secure
development
to
be
a
business
as
usual
habit.
We
talked
about
how
getting
inside
of
that
developer
habit.
Loop
is
really
important
and
we
took
a
little
segue
into
git
lab's
platform.
First
orientation,
you
want
an
extensible
platform
that
you
build
out
on.
Also
context
and
timing
is
crucial
doing
these
things
at
the
time
when
a
developer
is
expecting
to.
A
In
other
words,
when
all
the
parts
are
out
on
the
bench
is
super
important,
and
that
means
we've
got
to
have
Dynamic
security
scanning
very
early
in
the
process
before
the
developer
merges
to
a
shared
branch.
We
want
transparent
responsibility,
because
that
motivates
all
of
us
to
understand
that
hey.
If
we
want
Top
Value
craftsmanship,
we
need
to
make
sure
that
our
code
is
clean
not
only
in
terms
functionality
but
also
in
terms
of
security.
A
Vulnerabilities
just
wanted
to
do
a
call
out
that
if
you
need
help
with
gitlab
and
how
it
works
with
AWS
in
any
regard,
including
what
we've
talked
about
here
in
terms
of
security,
we
have
a
special
sales
Alias
for
that,
and
you
can
reach
me
at
any
of
these
social
handles
out
on
the
Internet.
Thanks
very
much
for
your
time
and
I
hope
that
you
understand
now
a
little
bit
better
about
how
gitlab
is
lining
up
to
be
your
devsecops
platform.