►
From YouTube: What is the Protect Stage
Description
A brief overview of the goals and focus areas for GitLab's new Protect stage
A
A
So,
if
you're,
looking
at
the
home
page
for
gitlab.com
you'll
notice
that,
instead
of
having
our
defend
column
here,
we
now
have
protect
and
the
reason
for
that
is.
We
want
to
make
a
shift
to
focus
on
enterprise
readiness
and
the
cloud
workload
protection
platform
space
so
on
the
protect
direction,
page
you'll
see
under
competitive
landscape.
This
nice
pyramid,
this
pyramid
outlines
the
one
of
the
main
focuses
for
the
stage.
A
What
we
recently
launched
in
132
was
our
container
host
security
category
and
that
fits
directly
into
that,
and
you
can
see
that,
with
the
current
capabilities,
we're
providing
found
integrity,
monitoring,
application,
allow
listing
and
active
response
and
blocking
that's
giving
our
customers
as
they
move
containers
from
development
into
production,
a
way
to
secure
them
and
protect
them.
Thus,
the
name
protect
outside
of
that.
B
Yeah
thanks
david,
so
to
talk
about
security
orchestration
with
that
is
really
an
overlay
category
across
both
secure
and
protect,
aimed
at
bringing
more
enterprise
features
across
all
of
the
scanners.
So
there
really
are
two
kinds
of
policies
that
we
want
to
add
in
support
of
that
security.
Orchestration
area,
one
is
a
scan
schedule.
Policy
and
another
is
a
scan
results
policy
and
I
can
show
you
just
a
rough
conceptual
mock-up
that
I've
got
here
of
what
this
workflow
could
look
like
in
the
future.
B
Is
that
we're
hoping
to
build
a
new
policy
section
in
gitlab,
where
you
can
come
through
and
customize
your
rules
for
when
pipelines
are
run
or
perhaps
on
a
certain
schedule
to
have
either
your
branches
or
your
production
environment
scanned
on
a
regular
basis?
So
this
takes
what
otherwise
can
be
a
little
bit
of
a
more
technical
setup
in
yaml.
It
makes
it
more
of
a
user
intuitive
setup
with
english
language
sentences.
B
We
want
to
bring
this
up
to
both
the
group
and
instance
levels
as
well,
so
that
you
can
manage
these
policies
across
your
entire
gitlab
instance.
Similarly,
we
want
to
have
scan
results.
Policies
that
take
actions
once
the
scan
is
complete
so
that
you
can
write
rules.
That
say
you
know
if
a
scan
finds
one
or
more
critical
findings,
then,
for
example,
you
may
want
to
fail
the
pipeline
or
perhaps
even
take
other
actions
coming
out
of
that.
B
Overall,
we
feel
like
this
change
in
direction
is
going
to
help
us
to
focus
more
on
those
features
that
are
going
to
make
gitlab
easier
to
use
and
make
it
simpler
to
enforce
these
policies
across
your
entire
gitlab
instance.
Thanks
for
watching,
and
we
look
forward
to
any
feedback
that
you
may
have
to
provide.