►
From YouTube: Protect Stage Strategy May 2021
Description
Joint Direction for Container Security and Compliance: https://www.youtube.com/watch?v=grg_M1MtiYw&list=PL05JrBw4t0Kq4O8RBlOKi_euwv8NyI8yt&index=3
High Level Direction for Security Approvals: https://www.youtube.com/watch?v=KEAieGVSjGo&list=PL05JrBw4t0Kq4O8RBlOKi_euwv8NyI8yt&index=10
A
A
As
well
as
you
can
see
on
the
category
direction
page
for
container
scanning
so
scanning
is,
is
run
here,
we're
also
having
an
auto
remediation
component
to
container
scanning,
which
would
help
with
mitigate,
of
course,
as
well
as
all
the
details
to
help
you
identify
and
resolve
the
vulnerability
and
finally,
in
the
protect
stage.
This
is
the
primary
focus
of
the
protect
stage
as
a
whole.
You
have
components
such
as
container
host
security
and
potato
network
security,
helping
protect
your
containerized
environment
and
long-term
your
cloud-native
environment
at
a
high
level.
A
I
wanted
to
highlight
some
of
the
accomplishments
over
the
last
three
months,
so
on
the
container
scanning-
and
this
is
part
of
the
pipeline-
the
team
has
finished
the
work
to
support
the
trivia
analyzer.
This
will
be
replacing
claire
and
clar
as
part
of
the
container
scanning
category.
This
cuts
over
in
14.0,
which
is
actually
next
month.
A
It
is
there
today
behind
a
feature
flag
if
you
want
to
use
that
ahead
of
time.
This
also
leads
into
our
openshift
support,
we're
very
excited
to
talk
about
how,
in
14.0
with
trivia,
we'll
be
able
to
support
openshift
for
container
scanning
and,
finally,
lots
of
documentation
updates.
We
want
to
make
sure
things
are
easy
to
use
easy
to
follow
and
he
wasn't
very
much
focused
on
improving
the
documentation
on
security
orchestration,
I'm
very
excited
announced
we
did
reach
minimal
maturity.
Since
last
time
we
had
a
strategy
review,
that's
very
exciting.
A
That
was
kicked
off
with
the
alert
dashboard
now
being
available.
We've
also
done
lots
of
follow-on
enhancements
to
the
alert
dashboard,
so
please
check
out
the
category
direction
for
secure
orchestration,
as
well
as
the
documentation
on
the
alert
dashboard
and
then.
Finally,
we
are
also
finished
up.
Our
first
initial
release,
the
security
policy
management
component
that
work
is
behind
a
future
flag.
Today,
however,
we
will
be
outside
that
feature
flag
here
shortly.
So
please
check
that
out.
It's
very
exciting.
A
It's
been
focused
on
support
with
the
container
security
team
working
with
the
das
team,
on
getting
das
scans,
to
be
part
of
that
policy
enforcement
and
then,
finally,
on
cloud
workload,
protection
we're
doing
the
work-
and
this
is
currently
in
spike
for
rolling
out
starboard
to
be
able
to
run
trivia
as
part
of
a
production
environment
again
very
exciting
work.
This
is
a
lot
of
progress
made
in
the
last
several
months
and,
of
course,
this
is
all
due
to
the
hard
work
of
the
container
security
team.
B
Secondly,
there's
the
security
orchestration
category
we're
putting
about
50
of
our
investment
here
plus
we
just
got
approval
for
one
dedicated
engineer
to
focus
on
security
approvals.
As
part
of
this,
this
is
really
an
overlay
category
that
provides
uplift
to
all
of
secure
and
protect
by
providing
some
joint
shared
functionality
to
help
across
the
board.
And
lastly,
we
have
the
cloud
workload
platform,
protection
market
and
that's
where
we
have
container
scanning
in
production,
as
well
as
our
container
host
and
network
security
categories,
just
to
provide
an
overview
of
the
personas
that
we're
dealing
with
here.
B
We've
got
the
security
operations,
persona,
the
application
security
persona
and
then
your
traditional
devops
or
even
development
type
personas,
and,
as
you
can
see,
I'm
mapping
these
to
the
different
areas
in
protect
that
address
those
those
personas.
What
we're
trying
to
do
is
build
a
bridge
over
that
security
operations.
Team,
so
get
lab,
is
traditionally
focused
on
the
devops
and
development
teams,
with
secure
and
in
the
secure
stage.
That
team
is
focusing
primarily
on
the
application
security
team
and
would
like
to
really
break
into
that
security
operations
market.
B
Another
way
of
looking
at
this
is
in
a
bit
of
a
venn
diagram
where
we've
got
those
two
personas
coupled
with
the
compliance
team.
They
have
a
lot
of
shared
jobs
to
be
done
here,
ultimately,
they're,
all
interested
in
keeping
the
company
safe
from
cyber
security
attacks,
making
sure
that
the
risk
for
the
company
is
kept
to
a
minimum
in
the
past,
with
defend
we're,
focused
very
heavily
on
that
security
operations
team
down
in
the
far
bottom
left.
B
What
we're
trying
to
do
at
this
point
in
time
is
build
a
bridge
over
to
that
area
by
focusing
on
some
of
those
shared
responsibilities
between
the
secops
and
appsec
teams,
and
that
includes
scanning
production
containers
for
vulnerabilities.
That's
a
shared
job
that
they
both
need
to
do,
as
well
as
coordinating
with
development
to
remediate
findings.
B
I
want
to
highlight
the
security
approvals
feature
that
recently
moved
over
to
the
protect
stage.
This
actually
was
a
feature
that
previously
was
owned
by
threat
insights,
our
board
approved
budget
to
hire
an
engineer
to
work
on
this
100
full-time
and,
as
you'll,
see
here
in
a
minute
as
part
of
that
vision,
we're
going
to
be
moving
that
feature
into
the
security
orchestration
team
and
having
an
engineer,
work
on
that
100
full-time,
entirely,
focused
on
just
that
area
and
just
to
provide
a
little
bit
more
context
about
our
vision.
Here.
B
Really
we
see
this
merging
in
with
the
work
that's
being
done
today
with
security
policy
management,
so
this
would
be
a
new
type
of
security
policy.
This
would
be
a
scan
results,
policy
that
takes
effect
after
the
scans
finish
running,
and
that
policy
will
then
examine
the
results
of
the
scans
and
based
off
of
the
findings
there.
It's
going
to
optionally
take
certain
action
depending
on
how
you've
configured
your
policy.
B
As
of
today,
the
security
approvals
functionality
in
gitlab
is
fairly
coarse
grain,
it's
more
of
an
all
or
nothing
approach,
and
by
moving
it
into
this
policy.
Editor,
it's
going
to
let
users
get
very
specific
to
say
exactly
what
types
of
scans
they're
interested
in
what
level
of
severity
vulnerabilities
that
they're
interested
in
and
whether
or
not
they
want
to
only
have
approvals
triggered
if
those
vulnerabilities
are
newly
detected
or
pre-existing
and
not
dismissed,
yet
they
can
really
customize
exactly
what
they're
looking
for.
B
So,
ultimately,
we
want
to
move
this
from
where
it's
at
today
into
that
security
policy
workflow
and
also
make
it
available
not
just
to
the
project
level,
but
at
the
group
and
workspace
level
as
well
as
we
start
into
that.
Our
first
step
will
be
a
research
spike
just
to
figure
out,
what's
required
to
achieve
this
vision
and
to
start
breaking
everything
into
iterative
milestone
steps
as
far
as
our
roadmap
priorities
go,
I've
actually
taken
out
a
lot
of
the
slides
that
I've
highlighted
in
the
past.
B
Here
I
did
update
them
they're
part
of
the
deck,
but
I
didn't
want
to
recap
them
to
be
too
repetitive.
I
did
want
to
highlight
this
slide,
though,
which
shows
where
we're
headed
with
our
policy
management
work.
This
is
sort
of
a
big
matrix
of
perhaps
not
entirely
everything,
but
almost
everything
that
we've
got
you
know
in
in
our
vision
and
in
our
roadmap
plans
over
the
next
year
or
so
right
now
we're
starting
work
for
just
das
policies
only
and
we're
working
just
at
the
project
level.
B
Finally,
I
just
wanted
to
highlight
our
12-month
roadmap.
Well,
all
of
this
is
subject
to
change.
Hopefully
this
gives
you
a
rough
idea
of
where
we're
headed
both
in
the
next
three
months
and
also
out
over
the
course
of
the
next
year.
Right
now
we're
looking
to
see
if
we
can
support
scheduled
scans
for
policies.
We
want
to
build
a
ui
around
that.
We
also
want
to
extend
the
alert
dashboard
to
support
a
easier
to
use,
kanban
style
working
view
container
scanning
we're
working
to
use
trivia
by
default.
B
Although
that's
been
released,
it
still
isn't
the
default,
but
we're
planning
to
make
that
happen
in
the
14.0
release
and,
finally,
we're
working
to
allow
you
to
scan
containers
running
in
production
and
improve
the
ability
to
match
vulnerabilities
there.
Any
feedback
on
this
roadmap
is
welcome.
It
changes
rather
frequently
based
off
of
input
from
customers,
so
please
feel
free
to
reach
out
or
comment
on
any
of
these
epics
or
issues
if
you
have
input
or
feedback.
B
A
you're
always
welcome
to
ask
these
again
or
ask
other
questions
that
you've
got,
but
to
start
off,
we
wanted
just
to
address
some
of
these
commonly
asked
ones.
So
actually,
my
first
question
is
for
you,
david.
Why
is
container
scanning
part
of
protect
when
it
really
is
part
of
the
pipeline?
It
runs
as
part
of
the
pipeline.
All
of
the
other
secure
scanners
run
as
the
pipeline
part
of
the
pipeline.
So
how
did
container
scanning
end
up
over
here
in
protect.
A
So
that's
a
great
question:
sam.
We
get
this
actually
quite
often,
so
we
made
the
strategic
decision
to
move
container
scanning
from
security
vertex,
so
we
could
have
all
of
our
container
security
features
together.
Initially,
it
didn't
seem
intuitive
to
everyone.
However,
as
we've
begun
to
deliver
on
the
plans
that
the
caterer
security
team
has
had
example,
being
standardizing
on
a
single
engine
that
can
not
only
just
do
the
scanning
of
the
pipeline
to
do
scanning
in
production
and
highlighted
by
you
with
leveraging
starboard,
which
is
our
current
spike.
That's
being
worked
on.
A
This
allows
to
have
a
holistic
view
of
the
container
security
market
and
puts
us
in
line
with
that
container
workload
platform
or
protection
platform
space.
We
want
to
address
so
hopefully,
if
it's
not
become
more
intuitive
to
everyone
over
the
next
couple
of
milestones,
as
we
shift
more
of
the
goals
that
have
been
defined,
we'll
begin
to
see
that
for
everyone,
that's,
it
was
a
very
intuitive
decision.
A
The
next
question
is
actually
something
I
think
you'd
be
great
at
answering
sam,
so
we
commonly
get
asked
like
how
does
the
secure
restriction
category
in
the
work
with
the
policies
for
enforcement
and
now
approvals?
How
does
that
work
with
what
the
compliance
team
is
doing
and
are
we
collaborating
with
them?
Is
there
a
lot
of
overlap.
B
So
I'll
include
a
link
to
that
in
the
description
of
this
video,
so
you
can
check
it
out
for
a
full,
detailed
answer,
but
just
to
answer
your
question
briefly,
we
see
that
merging,
together
with
security
with
our
security
policy
work,
we've
taken
two
different
approaches
that
each
have
their
own
pros
and
cons
and
in
the
end
we
want
to
take
the
pros
of
both
approaches
and
bring
those
together.
So
our
work
with
the
security
policy
management
piece
is
somewhat
restrictive.
A
B
It's
limited
only
to
get
lab
scanners,
and
but
on
the
positive
side,
it
has
a
very
clean
and
easy
to
use
user
interface.
The
security
com,
the
compliance
team's
work
is
very
much
the
opposite.
They
let
you
merge
any
yaml
file
into
the
pipeline
and
enforce
that
to
run
as
part
of
a
pipeline,
but
the
user
experience
is
not
great.
It
takes
a
lot
of
clicks
to
set
up
and
then
you
have
to
know
how
to
write
a
ci
file
in
order
to
use
it.
B
So
where
we
see
this
headed
is
basically
a
joint
vision
that
says
if
a
pipeline
is
run
for
a
given
branch,
you
can
then
just
execute
a
ci
script,
and
this
can
be
a
link
file.
You
can
also
just
put
a
yaml
block
here
in
line,
but
basically
we're
taking
the
flexibility
of
what
the
compliance
team
has
done
and
coupling
that,
with
the
usability
of
the
security
orchestration
team,
for
an
overall
great
experience.
A
That's
great,
I'm
very
excited
that
the
teams
are
working
together.
I
think
the
more
we
focus
on
usability
and
collaborate,
the
better
that
experience
is
going
to
be
for
all
of
our
users,
because
our
users,
own
css,
protect
container
scanning,
container
security
and
there's
a
compliance,
and
they
see
us
all
as
one
platform,
because
that's
what
we
are.
A
B
Yeah
great
question
david:
we
did
a
pretty
extensive
analysis
as
we
went
into
the
effort
looking
at
how
we
were
going
to
start
scanning
containers
running
in
production,
and
that
really
was.
The
initial
driver
was
that
roadmap
item
of
needing
to
get
that
production
scanning,
and
we
found
that
trivia
supported
that
really
well,
it
worked
very
cleanly
it
integrated
in
a
great
cloud-native
way.
At
the
same
time,
we
had
a
number
of
challenges
with
the
scanner
of
claire.
B
In
the
past
we
had
a
growing
backlog
of
customer
bugs
and
requests
that
just
were
not
answered
and
we
were
not
able
to
get
through
all
of
those
in
a
timely
manner,
and
we
noticed
that
a
large
number
of
those
could
be
resolved
by
moving
to
trippy.
So
we
actually
did
a
pretty
in-depth
comparison
of
claire
versus
trivia.
We
also
compared
trivia
to
some
of
the
other
popular
scanners
out
there,
such
as
gripe
and
a
few
of
the
others,
and
in
the
end
we
found
that
just
previous
results
were
very
good.
B
Their
language
support
is
excellent,
they're
extremely
responsive
in
working
with
us,
and
at
the
end
of
the
day
it
it
seemed
like
it
was
just.
Not
only
did
it
help
us
get
to
that
end
goal
of
building
things
and
being
able
to
scan
in
production,
but
it
also
basically
took
care
of,
like
20
customer
bugs
at
the
same
time,
and
provided
for
a
great
improvement
to
the
total
security
that
we
could
provide
for
our
users.
A
Yeah,
I
also
I'm
very
excited
about
the
fact
that
you
and
the
container
security
team
are
working
with
the
trivia
project
to
also
be
able
to
leverage
our
own
vulnerability
research,
because
a
lot
of
people
don't
realize
that
gitlab
has
a
vulnerability.
Research
team
dedicated
to
making
sure
our
scanners
are
as
good
as
they
possibly
can
be
because
we're
commonly
known
as
just
using
an
open
source
scanner,
and
so
the
fact
that
we're
gonna
be
able
to
take
that
intelligence
and
integrate
it
into
that
scanner.