►
From YouTube: Protect Stage Strategy APAC Friendly Q&A - May 2021
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hello,
welcome
to
our
apac
friendly
q,
a
session
for
a
protect
strategy
meeting
this
was
pre-recorded.
Hopefully
you
had
a
chance
to
see
the
pre-recording
ahead
of
time.
This
point
will
open
up
for
questions
and
comments.
Todd
you've
got
the
first
couple
here.
B
Yeah
sure
the
the
first
one
just
to
comment
itself,
and
that
is
to
say
thank
you
for
giving
a
shout
out
to
the
vr
team
and
in
the
video
I
I
think,
giving
them
that
that
sort
of
recognition
and
exposure
is
awesome.
B
The
second
one
had
to
do
with
with
slide
15,
where
in
the
container
scanning
you,
you
mentioned
vulnerability,
matching
as
well
as
deduping
of
findings,
and
I
was
curious
if
a
few
had
explored
using
the
the
tagger
feature
that
we
just
got
done
putting
into
sas
because
it
it
solves.
For
a
bit
of
this
as
well
and
like
I
said,
I
realized
we
owned
the.
How,
but
I
just
didn't
know
if
this
was
already
explored
or
not.
A
A
I
know
in
the
slides
it's
kind
of
a
high
level
representation,
so
I'm
happy
to
at
least
talk
to
the
problem
to
be
solved
in
a
little
bit
more
detail.
There
are
actually
a
few.
You
know
this
sort
of
a
lump
identifier
for
a
few
different
problems
that
we
need
to
solve.
A
One
of
the
problems
that
we're
seeing
is
that
by
default,
the
scanning
engines
tend
to
spit
out
vulnerabilities
that
are
unique,
based
off
of
the
cve
and
the
package
name,
so
you
get
a
lot
of
vulnerabilities
with
the
same
cv,
but
different
package
names
and
typically
you
know
that's
because
one
package
includes
another
package
which
includes
another
package
which
actually
has
a
vulnerability
in
it,
and
so
you
get
three
vulnerabilities
when
really
there's
just
one
fix
to
be
done,
and
so
you
know
one
of
the
problems
we
have
is
just
reducing
the
noise
consolidating
those
downs
that
we've
got.
A
You
know
one
vulnerability
per
fix
rather
than
three
separate
ones,
so
that
would
be
one
problem.
Another
problem
that
we
have
is
fixing
how
we
match
against
the
default
branch,
and
this
one
we
actually
have
done
at
least
an
initial
research
spike
into
we're,
not
planning
on
using
tagger
for
that,
but
that's
just
adjusting
how
we
resolve
like
when
someone
does
an
mr
against
the
default
branch
right
now,
we're
not
supportive
of
all
of
the
different
kinds
of
branching
strategies.
A
Our
deduplication
strategy
there
to
identify
which
vulnerabilities
are
new,
starts
to
break
down.
So
this
would
be,
you
know,
basically
letting
you
match
when
you
create
an
mr
against
a
different
branch,
you
know,
and
you
already
have
known
vulnerabilities
there
that
have
been
approved
or
accepted,
or
even
that
just
exist.
This
would
be
to
compare
against
that
and
identify
which
ones
are
new
versus
that
branch
instead
of
new
versus
the
default
branch.
A
So
that's
kind
of
the
second
problem
to
solve,
and
then
there
actually
are
a
couple
others.
So
in
the
longer
term,
we
want
to
continue
to
reduce
noise
by
identifying
vulnerabilities
that
may
exist
in
the
code,
but
you
don't
actually
use
that
line
of
code
or
you
don't
actually
use
that
package
within
the
package
so
to
speak,
and
so
it's
a
much
lower
priority
to
fix
and
then
the
fourth
area
would
be
identifying
vulnerabilities
that
exist,
but
they're
kind
of
they're
out
of
your
scope
of
control
to
fix
them.
A
So
maybe
you're
on
already
on
the
latest
version
of
a
certain
package
and
really
the
only
way
to
fix
that
would
be
to
go
and
contribute
upstream
to
that
particular
package.
So,
even
though
that's
a
valid
vulnerability,
you
might
want
to
identify
that
as
a
non-actionable
or
not
easily
actionable
vulnerability
so
that
you
can
focus
on
areas
that
you
can
actually
control.
A
So
yeah,
hopefully
that
helped
and
thanks
for
the
suggestion
there
I'll
be
sure
we
at
least
consider
tagger
and
look
into
it
as
we
start
to
explore
those
problems.
C
A
Sure
so
that
that's
a
that's
a
loaded
question.
Obviously
it
varies
per
customer,
but
I
think
gartner's
position
on
this
is
actually
fairly
decent.
I
I
don't
know
that
I
100
agree
with
it,
but
I
think
it's
a
good
starting
point.
A
They
have
a
diagram
that
basically
creates
a
pyramid
structure
of
different
capabilities
in
the
cloud
workload
platform
production
market
and
they
actually
rank
those
they
put
the
ones
at
the
bottom
as
foundational-
and
you
know
the
ones
higher
up
is-
is
a
little
bit
less
important.
So
that's
at
least
one
framework.
That's
been
put
out
there
by
gartner
that
you
know
we
can
reference
as
a
starting
point
when
we're
thinking
about
relative
importance,
cool.
C
And
I
have
one
more
question
and
I'm
sorry
I'm
not
right
now.
I
can
have
a
hard
time
writing
and
thinking.
At
the
same
time,
I
know
that's
sad
in
light
of
the
the
whole
security
of
the
supply
chain.
C
A
So
I'm
not
sure
what
type
of
policies
you
have
in
mind
there
I
mean
what
we're
doing
with
the
security
orchestration
team.
Around
security
policy
management
is
really
meant
to
be
the
central
place
in
gitlab
for
your
security
and
compliance
policies.
So
I
would
expect
that,
ultimately,
all
of
our
security
and
compliance
policies-
roll
up
there
in
that
ui.
But
I
don't
know
if
there's
a
specific
kind
of
policy
that
you're
alluding
to
there.
D
If
I
was
like
reword
your
questions
indeed
yeah,
I
I
think
what
you're
asking
is:
is
there
collaboration
across
the
two
stages,
where
there's
overlap
and
an
example
would
be
like
sam
you've
created
the
particular
registration,
as
your
policy
manager
policy
creator
can
remember
the
exact
name
you
gave
it,
but
like
could
that
be
also
used
as
a
way
to
tie
back
to
compliance
requirements,
and
then
you
would
have
a
single
point
to
kind
of
be
like,
oh
hey,
all
pipelines
must
have
this
run
on
it,
which
could
be
container
scanning
or
all
containers
deployed
must
have
like
our
container
host
security
enabled
for
them,
and
not
you
know
not.
A
A
That
might
be
one
to
take
a
look
at
and
and
see
how
we're
collaborating
there.
So
the
short
answer
would
be.
Yes,
I
mean
again,
we
review
this
security
policy
management
interface
as
the
ultimate
user
experience
for
any
type
of
secure
security
or
compliance
policy
in
gitlab,
so
that
includes
not
just
enforcing
when
scans
have
to
run,
but
also
enforcing
what
happens
after
scans
complete
if
they
find
vulnerabilities,
do
we
then
fail
the
pipeline
or
require
certain
approvals?
A
You
know
any
sort
of
compliance
task
that
you
might
want
to
enforce
as
part
of
a
pipeline
job
would
roll
up
into
those
policies,
as
well
as
things
outside
of
the
pipeline,
like
just
scheduled
tasks
or
even
your
container
network
security
or
container
host
security.
So
again,
that's
really
a
big
part
of
the
charter
for
that
security.
Orchestration
category
is
to
build
it's
an
overlay
category
across
protect
and
secure,
and
manage
really
all
of
gitlab
to
provide
that
functionality.
A
A
So,
as
far
as
configurations
like
what
kind
of
configurations
how
you
configure
your
ci
pipeline
or.
C
Well,
so
if
I'm
a
customer,
I'm
thinking
not
from
the
get
lab
perspective,
but
from
the
customer
perspective
I've
got
configurations
for
the
pipeline
and
get
lab.
I've
got
for
my
cloud
provider
for
my
kubernetes
for
my
containers,
I've
got
lots
of
different
levers
to
pull
it'd
be
really
nice.
If
I
had
one
place
to
go
that
in
english,
like
language
would
help
me
configure
all
of
that,
and
then
tell
me
when
something's
going
off
the
rails
against
those
policies.
A
A
You
know
whether
it's
ansible
or
terraform,
or
you
know,
whatever
other
technology
that
you're
using,
so
that
tends
to
fall
more
on
bridging
into
infrastructure
as
code,
you
know,
how
do
you
manage
and
protect
those
types
of
configurations
in
the
long
run,
I
would
view
that
as
actually
being
an
additional
sas
scan,
if
we're
talking
about
protecting
it
before
it
goes
into
production,
so
be
a
sas
job
that
inspects
that
configuration
reports
back.
You
know
anything
that's
out
of
bounds
after
it's
deployed
into
production.
A
You
also
want
to
make
sure
that
things
don't
drift
from
their
initial
configuration
right,
that
they
stayed
put
the
way
that
they
were
originally
and
I
think,
that's
an
area
that
falls
under
protect,
but
it's
not
a
funded
area.
Inside
of
git
lab
today,
so
we
don't
have
a
category
or
group
to
go
focus
on
that
they'll
be
in
that
new
capability
for
us
to
go,
explore.
D
At
least
the
configuration
part,
I
think,
is
complicated
in
that
that
could
maybe
be
also
enforceable
by
code
owners
as
part
of
create.
It
could
be
part
of
the
compliance
components
where
there's
a
shadow
compliance
project
that
is
enforcing
things
over
as
well.
So
I
think,
maybe,
if,
if
we
rewound,
if
we,
if
we
could
turn
back
time,
if
we
could
find
a
way
cindy
like
maybe
the
secure
orchestration
to
sam's
point
is
more
of
like
a
manage
category
and
that
it's
eventually
sticking
its
fingers
in
all
the
different
categories
and
stages
and
whatnot.
D
But
it
was
born
out
of
protect
and
it
was
to
deal
with
continued
network
security
host
security.
And
I
I
I
don't
think
it
was
ever
laugh
roles,
because
I
think
we
then
we
started.
We
were
done
with
laugh,
but
it
became
a
really
great
thing
that
sam
and
the
team
came
up
with,
because
now
it's
applying
to
secure
and
now
certain
apply
to
manage-
and
I
think
longer
term,
like
gabe,
also
wants
to
be
able
to
leverage
it
for
plan
right.
So
sam
might
find
that
he's
created
a
thing
that
is
solving
a
problem.
D
Whether
that's
enforcement
of
configuration
approvals
scan
execution,
scan
scheduling,
network
policies
at
all
of
it,
but
I
I
think
it's
a
it's
a
challenging
area,
because
when
you
talk
about
iac
and
the
things
that
go
with
it,
like
terraform
seems
right,
you
could
scan
with
sas.
D
C
You
know
interacted
engaged
by
the
customer
so
that
they're
not
having
to
go
in
lots
of
different
places
or
understand
all
the
different
places
to
go.
If
there's
anything
that
we
could
do
to
simplify
that,
I
would
just
keep
that
in
mind.
It
may
be
a
longer
term
thing,
but
I
think
that's
something
that
they're
really
wrestling
with
and
as
infrastructure
as
code
gets
even
more
prevalent.
A
Yeah
I
agree.
I
I
do
think
that
that
security
policy
management
ui
is
that
centralizing
place.
You
know,
even
if
we're
not
100
there,
yet
as
a
company.
I
think
that's
where
we
are
going
to
put
those
rules
when
we
do
get
there,
so
you
know
again
if
it's
just
another
sas
job
we're
adding
in
the
ability
to
enforce
scanning
jobs.
A
Today
in
our
rules,
editor
it'll
be
a
very
natural
extension
of
that
to
say
you
know
now,
let's
enforce
this
terraform
scan
or
this
ansible
scan
to
make
sure
that
you
know
we're
configuring
things
the
way
you
know
in
a
way
that's
in
line
with
our
security
compliance
policies
and
again
on
the
production
side.
A
You
know
winner
if
gitlab
does
decide
to
move
into
that
space
of
enforcing
configuration
in
production
again,
I
think
we
would
use
that
same
policy
editor.
So,
even
if
we're
not
directly
investing
in
those
areas
today
it
is
building
a
good
foundation.
That's
going
to,
let
us
have
a
central
place
to
manage
all
of
that.
If
we
move
that
direction
in
the
future,
that's
terrific.
A
Yeah
we
could
do
just
sort
of
a
quick
recap.
The
first
one
scott
was
interested
in
better
understanding
that
bridge
that
we're
building
towards
the
secops
team
and
tangibly.
You
know
how
do
we
see
ourselves
getting
there
in
terms
of
what's
on
our
roadmap
currently,
and
the
answer
to
that
would
be
that
you
know
over
the
last
three
to
six
months,
we've
been
building
a
lot
of
what
I
call
architectural
underpinnings,
just
getting
a
good
foundation
in
place.
A
We've
chosen
to
move
from
claire
and
clark
over
to
trevi
because
trivia
is
better
suited
to
scanning
containers
in
production,
so
we're
not
scanning
containers
in
production
yet,
but
we've
laid
a
foundation
to
be
able
to
do
that
in
the
next
few
months
same
thing
with
our
policy
management,
even
though
we
don't
have
a
clean
ui
that
we've
released.
Yet
there
actually
has
been
a
lot
of
under
the
scenes.
A
You
know
architectural
work
in
how
we
interact
with
the
ci
pipeline
to
make
sure
that
we're
able
to
actually
truly
enforce
things
so
that
it
happens
every
time,
no
matter
what
so,
we've
done
a
lot
of
that
over
the
last
three
three
to
six
months.
We're
really
reaching
a
tipping
point
here
where
we're
shifting
you
know
from
doing
these
architectural
underpinnings
to
actually
delivering
on
some
of
these
features.
A
So
we
just
kicked
off
our
research
spike
into
starboard
to
identify
how
to
start
scanning
containers
in
production,
and
you
know
we're
getting
close
to
releasing
that
policy
ui
both
of
those
tangibly
do
help
us
to
build
the
bridge
over
to
secops,
because
the
apsec
persona
primarily
cares
about
vulnerabilities
as
they
exist
in
code
and
the
secops
team.
Primarily
concerns
about
is
concerned
with
keeping
the
production
environment
secure
and
so
where
those
two
overlap
is
vulnerabilities
in
code
in
production
is
really
like
the
biggest
area
of
overlap.
A
So
if
we
can
start
scanning
containers
in
production,
that's
an
area,
that's
joint
of
joint
interest
to
both
teams,
and
if
we
can
layer
on
security
approvals
and
policy
management.
As
part
of
that,
that
again
is
only
going
to
further
facilitate
the
dialogue
where
somebody
on
the
app
section
side
says:
hey,
I'm
going
to
start
scanning
here
in
production
and
oh
by
the
way.
You
know
the
secops
team
might
be
really
interested
in
that,
because
they
very
well
may
have
a
tool,
a
separate
tool
doing
that
already.
A
The
second
point
that
we
talked
through
was
just
where
we're
headed
with
the
alerts
dashboard
right
now,
there's
only
one
type
of
alert
that
can
come
into
there,
which
is
the
network
policy
alerts.
So,
even
though
we've
built
out
a
good
ui,
it
practicality
is
used
as
somewhat
limited
at
the
moment,
but
again
to
the
point
of
building
that
underlying
architecture
and
expanding
on
it.
B
A
We
have
some
new
vulnerability
intelligence
where
we're
headed.
There
is
just
updating
the
ux
to
include
a
kanban
style
view
where
you've
got
some
swim
lanes
and
there's
a
link
there
in
the
docks
that
I
shared
this
morning,
but
that
just
streamlines
that
workflow
process
as
they're
going
through
to
triage
those.
So
they
can
easily
see
what's
new.
What's
currently
in
review,
what's
been
resolved
and
then
everything
else
that's
either
been
dismissed
or
fully
taken
care
of.
A
So
that
may
have
been
a
little
bit
longer
than
a
quick
recap,
but
that's
the
that's
the
summary
of
what
went
on
what
we
discussed
this
morning.
E
Cindy,
did
you
have
another
question
or
were
you
just
recapping
what
we
talked
through
earlier?
I
was
just
typing
and
I
realized
I
didn't
type
it
earlier.
So
putting
that
in
there.
A
Great
well
thanks
for
joining
today.
As
I
said
in
the
morning
session,
you
know
again.
I
appreciate
the
engagement
and
the
dialogue
here.
If
there
are
more
questions,
feel
free
to
reach
out
to
me
anytime,
or
you
know,
if
you
prefer,
to
discuss
one-on-one
for
any
reason,
I'm
happy
to
do
that
as
well.