►
From YouTube: Protect Strategy August 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
Hi
everyone,
thanks
for
joining
our
pre-record
of
the
protect
strategy,
review,
take
a
look
at
the
video
here,
as
well
as
the
direction
pages
for
protect,
which
we
recently
updated
prior
to
the
q,
a
session
that's
coming
up
today,
sam
and
I
are
going
to
walk
through
some
updates
on
where
we've
been
and
where
we're
going
prior
to
the
live
q,
a
I'll,
provide
a
high
level
overview
of
the
protect
stage
and
where
it
sits
in
the
devsecops
lifecycle
and
then
walk
through
some
of
the
details
of
what
the
teams
delivered
for
protect
in
the
last
few
months
and
then
passed
off
to
sam.
A
A
Those
plans
could
change,
so
you
shouldn't
use
the
content
that
you
see
are
here
today
for
purchasing
or
planning
purposes,
so
we'll
get
started
here
with
the
overview
as
a
reminder
we're
talking
about
the
protect
stage.
So,
as
you
can
see,
there
are
four
categories
here
on
the
right
that
are
available
now
on
this
stage,
including
container
scanning
container
host
security,
container
network
security
and
security
orchestration.
A
A
Protect
is
now
in
the
analyze
step
with
container
scanning.
In
the
mitigate
step,
we
provide
guidance
on
which
vulnerabilities
are
the
most
critical
and
how
to
fix
them,
and
then,
of
course,
the
primary
focus
of
the
protect.
The
protection
stage
of
the
life
cycle
here
is
where
we
have
container
host
security
and
container
network
security,
and
we
actually
recently
introduced
some
capabilities
like
production
container
scanning
that
fit
in
this.
This
protect
portion.
A
I
want
to
highlight
some
accomplishments
from
the
last
three
months,
so
we've
delivered
multiple
features
in
the
container
scanning
category.
The
first
item
in
container
scouting
was
the
transitioning
to
trivia
as
our
default
scanner.
So
basically,
what
happened
here
is
we
swapped
out
the
underlying
technology
of
our
container
scanning
capabilities
and
moved
from
claire
to
trivi?
There
are
multiple
benefits
of
trivia
over
clear,
including
that
it
provides
more
accurate
results,
gives
support
for
additional
operating
systems
and
also
provides
more
timely
vulnerability.
Definition
updates
the
second
item
here
in
container
scanning.
A
Some
customers
require
the
use
of
ubi-based
images,
often
for
security
reasons,
and
this
is
a
feature
that's
of
particular
interest
to
many
public
sector
customers.
So
we
support
this
now.
Under
the
security
orchestration
category,
we've
been
working
to
introduce
a
couple
new
capabilities,
the
first
of
those
centers
on
enabling
more
granular
vulnerability
check
rules.
So
when
that's
delivered,
users
will
have
the
flexibility
to
customize
their
handling
of
vulnerabilities,
for
instance,
the
ability
to
require
a
security
or
approval
approval.
B
Great
thanks
hilary
and
to
kick
it
off,
I'm
just
going
to
be
sharing
a
high
level
overview
of
how
our
categories
that
we
have
within
this
group
mapped
to
the
different
markets
that
we
target
and
the
capabilities
that
we're
building
out.
So,
first
of
all,
we
have
the
container
scanning
category
and
in
this
diagram
I've
actually
split
that
into
two
pieces.
It's
one
category,
but
really
there
are
two
aspects
of
it.
The
first
aspect
is
pipeline
scanning
and
that
really
falls
into
the
software
composition,
analysis
market.
B
The
second
piece
of
that
is
container
scanning
and
production.
As
hillary
mentioned,
we
just
released
that
in
its
alpha
state
and
that,
together
with
container
host
and
container
network
security,
really
fall
under
the
umbrella
of
the
cloud
workload
platform
protection
market.
Additionally,
we
have
our
security
orchestration
category
and
that's
an
overlay
category.
It's
not
unique
to
just
protect
it
spans
across
all
of
gitlab,
and
it's
working
to
provide
uplift
uplift
to
accelerate
our
market
share
capture
for
the
asd
and
cwpp
markets.
B
B
So
with
that
being
said,
I'm
going
to
be
diving
into
each
of
these
three
market
segments
and
talking
about
what
we're
doing
in
each
of
those
so
starting
off
with
the
container
scanning
the
pipeline
piece,
as
I
mentioned
before,
that's
really
falls
under
the
sca
or
software
composition,
analysis,
analysis,
market,
that's
a
piece
of
the
broader
application,
security
testing
market
and
within
there
you
have
container
scanning.
So,
as
you
can
see
in
this
diagram,
I've
got
this
really
broad
ast
market
that
encompasses
all
of
the
different
scanning
types.
B
This
is
all
about
testing
application
security
before
it
goes
into
production
and
then,
when
you
break
that
down,
you've
got
your
software
composition
analysis
either
scanning.
As
a
piece
of
that
software
composition,
analysis
is
approximately
15
of
the
broader
market,
and
you
can
see
that
even
just
that
piece,
just
the
sca
market
is
really
large
and
is
projected
to
grow
into
the
future.
B
Some
of
the
key
market
requirements
that
are
in
this
space
are
outlined
here.
You
can
see.
We've
made
some
good
progress
in
checking
a
lot
of
these
boxes
and
we
either
have
roadmap
plans
or
work
in
progress
to
address
quite
a
few
more
in
our
near
term,
or
a
map
you're,
definitely
going
to
see
a
theme
coming
up
around
noise
reduction
in
the
near
future.
B
B
That
may
be
separate
vulnerabilities,
but
really
at
the
same
underlying
fix,
and
so
they
only
needed
to
be
treated
as
one
item:
vulnerability,
prioritization,
which
involves
taking
a
look
at
how
easily
the
vulnerabilities
can
be
fixed
by
the
development
team
or
whether
some
other
team
owns
the
code
and
so
that
fixed
may
be
a
lower
priority,
simply
because
it's
outside
of
the
control
of
that
group
and
then
false
positive
identification.
Where
we're
looking
at.
B
How
can
we
identify
whether
or
not
a
package
is
actually
used
in
production?
If
it's
something
like
a
bluetooth
package,
for
example?
That's
not
commonly
used
in
a
server
application,
then
that
vulnerability
that
vulnerable
code
may
be
present
in
the
container,
but
it
also
may
never
be
exercised,
and
so
that
would
be
a
false
positive
that
just
introduces
noise
into
the
system.
B
Lastly,
we
want
to
eventually
get
to
the
point
where
we're
able
to
generate
an
s
bomb
and
also
do
regular
scans
against
our
registry.
Some
of
that
is
going
to
involve
rethinking
how
we
structure
the
scanner
to
work
in
a
more
performant
way
and
to
start
storing
some
of
those
results
locally,
so
that
we
don't
have
to
rerun
the
scanner
every
time
if
the
image
hasn't
changed.
B
Moving
on
to
our
security
orchestration
category,
there
are
really
three
different
capabilities
that
fall
under
the
umbrella
of
security,
orchestration,
there's,
security
alerts,
security
approvals
and
security
policies.
We
did
a
lot
of
really
good
work
on
security
alerts
in
the
last
six
to
nine
months
and
so
that
that
capability
for
now
is
more
or
less
on
hold.
While
we
really
focus
on
the
security
approvals
and
security
policies
piece
eventually,
all
of
these
get
tied
together,
because
alerts
are
generated
from
a
policy
and
policies
govern
which
approvals
get
triggered.
B
So
all
three
of
these
are
very
closely
interrelated
for
the
security
policy
piece.
We
end
up
with
this
really
big
matrix
of
a
whole
lot
of
different
types
of
policies
that
we
want
to
include,
or
that
we
may
include
at
some
point
in
the
future
in
gitlab
right
now,
we're
actively
working
on
what
we
call
scan
execution
policies
and
those
policies
govern
when
a
scan
gets
run.
B
B
Then
there
are
scan
result
policies.
These
tie
in
with
the
security
approvals
that
I
talked
about
where
scan
result,
policies
take
effect
after
a
scan
is
completed
and
you're.
Looking
at
the
results
of
that
scan
and
trying
to
make
a
decision
about
what
are
the
next
actions
that
you
want
to
take,
maybe
you
want
to
require
approval.
You
may
want
to
do
something
as
assertive
as
failing
a
pipeline,
or
perhaps
you
actually
want
to
call
out
an
external
web
hook
to
take
some
external
action.
B
B
And
last
but
not
least,
it
includes
things
specific
to
git
lab
as
well,
such
as
insider
threat
or
even
privilege,
escalation
policies,
things
governing
when
users
are
allowed
to
use
admin,
privileges
in
the
gitlab
application
itself
and
even
looking
at
when
users
log
into
gitlab.
You
know
if
they
log
in
from
one
country
at
a
certain
time,
and
then
they
try
to
log
in
from
an
entirely
different
country.
Five
minutes
later,
that
would
be
suspicious
just
based
off
of
the
sheer
fact
that
it's
difficult
to
travel
that
distance
in
five
minutes
right.
B
So
you
may
want
to
look.
We
may
want
to
actually
alert
or
even
block
login
attempts
or
push
attempts
into
gitlab
if
we
see
suspicious
or
anomalous
behavior
occurring
right
now.
Our
initial
mvc
is
to
support
these
policies
at
the
project
level,
but
we've
got
a
near-term
roadmap
item
to
take
that
up
and
make
it
available
at
the
group
and
workspace
level
as
well.
So
we've
got
a
lot
planned
here.
B
A
B
In
the
ui,
under
the
security
and
compliance
section,
called
policies,
and
in
here
you'll
get
a
listing
of
your
policies,
as
you
can
see
here
in
this
mock
you'll
be
able
to
manage
these.
These
policies
are
managed
by
via
a
linked
policy,
a
linked
security
policy
project.
That's
a
separate
project
from
the
development
project
that
you're
operating
in,
and
that's
done
for
a
number
of
reasons
that
allows
for
full
separation
of
duties.
So
you
can
have
a
separate
set
of
maintainers
and
developers
on
that
security
policy
project.
B
You
also
can
have
full
history
and
change
audit
logging.
So
all
of
these
policies
get
translated
down
into
yaml.
They
get
stored
in
that
linked
security
policy
project
so
that
you
get
all
of
the
benefits
of
get
included
in
that,
including
a
full
full
version
control
in
history.
That's
available
there
and,
lastly,
because
it's
in
get
you
have
support
for
two-step
approvals,
including
the
use
of
our
mr
approval
workflow.
So
you
can
require
maintainers
to
approve
any
changes
that
are
proposed
for
policies.
B
Shifting
over
to
our
security
approvals
vision,
right
now
in
the
near
term,
as
hillary
mentioned,
we're
working
to
add
more
flexibility
with
the
existing
vulnerability
check
rules
in
the
longer
term.
We
see
this
moving
into
the
security
policy
editor
where
users
will
be
able
to
get
in
here
and
provide
very
specific
granular
rules
specifying
exactly
which
scans
might
trigger
a
vulnerability
check
which
branches
they
care
about.
The
number
and
severity
of
vulnerabilities
that
will
apply
and
they
can
chain
these
rules
together.
B
So
you
can
have
multiple
rules
that
apply
and
then
one
or
more
actions
that
come
out
the
other
end.
The
most
basic
of
these
actions
is
the
one
you
see
here
on
the
screen,
which
would
be
to
require
approval
from
a
certain
number
of
individuals
and
again,
as
you
can
see,
all
of
this
translates
down
into
yaml
which
gets
stored
in
that
linked
security
policy
project
for
the
first
iteration.
B
This
will
be
at
the
project
level
only,
but
just
as
we
move
the
security
policy
editor
as
a
whole
up
to
the
group
and
workspace
levels,
we
plan
to
also
move
these
vulnerability,
check
or
scan
result
policy
rules
up
to
the
group
and
workspace
levels
as
well,
just
to
make
it
easier
for
security
teams
that
have
a
really
large
number
of
projects
to
manage.
So
they
can
do
that
once
and
manage
it
centrally
for
their
entire
organization.
B
Again,
it's
a
very
large
market,
it's
growing
very
rapidly,
so
there's
a
lot
of
room
for
new
entrants
and
new
players
to
come
in
or
even
for
us
to
extend
and
add
our
capabilities
that
we've
already
got
here
in
gitlab
for
our
first
release,
we're
really
focusing
in
on
mid-size
companies
and
there's
a
couple
reasons
for
that.
Typically,
this
smb
market
lacks
budget
and
a
mature
security
team.
So
it's
rather
difficult
to
sell
these
capabilities
to
them,
especially
since
a
lot
of
these
technologies
are
new.
There's
a
lot.
B
That's
still
evolving
in
terms
of
mindset
among
companies
and
smb
tends
to
not
be
at
the
forefront
of
that
evolution.
Enterprise
customers,
on
the
other
hand,
tend
to
be
very
mature.
They
tend
to
require
a
very
steep
feature
set
and
where
gitlab
is
relatively
new
to
this
market,
we're
not
a
great
fit
for
that
segment.
Yet
we
eventually
want
to
play
there.
But
for
now
the
mid
market
is
our
sweet
spot.
B
Just
to
share
a
little
bit
more
about
our
vision
for
that
cluster
image
scanner
right
now,
those
results
are
just
being
brought
in,
together
with
all
of
the
other
vulnerabilities
in
gitlab.
We're
planning
to
separate
that
out
into
the
separate
tab
in
the
vulnerability
report.
So
there'll
be
a
development
vulnerabilities
tab
and
an
operational
vulnerabilities
tab
that
separate
operational
vulnerabilities.
Tab
is
initially
going
to
have
just
the
results
of
the
cluster
image
scanner,
but
we
plan
to
add
additional
types
of
scanning
in
the
future
that
we'll
feed
into
here.
B
You
can
imagine
the
usefulness
of
a
das
scan
or
a
fuzz
testing
scan
against
something
running
in
production.
Obviously,
you'd
want
to
run
like
a
dash
scan
in
more
of
a
passive
mode,
so
you
don't
actually
interrupt
your
production
workflow,
but
those
would
be
examples
of
near-term
next
steps
that
might
come
into
play
further
down
the
road
we
might
want
to
introduce
things
like
dependency
scanning
or
configuration
scanning
or
even
scanning
of
the
infrastructure
itself,
to
make
sure
that
the
infrastructure
is
hardened
and
secure.
B
This
cluster
image
scanner
is
one
of
the
key
capabilities
that
we
view
as
helping
us
build
this
bridge
to
addressing
production
security
in
our
customers.
As
we
take
a
look
at
the
target
personas
that
we
address
in
gitlab
today,
most
of
gitlab
deals
with
the
devops
or
development
persona.
That's
here
on
the
right.
B
The
overlap
between
those
teams
is
the
ability
to
scan
production
containers
for
vulnerabilities,
that's
really
where
the
appsec
team
gets
involved
because
they
deal
with
vulnerabilities
that
exist
back
in
code.
The
abstract
team
is
working
with
the
developers
to
help
make
sure
that
those
vulnerabilities
get
fixed.
Yet
at
the
same
time,
the
vulnerability
exists
in
a
production
environment,
and
so
that's
where
it
starts
to
concern
the
infrasect
team.
B
So
by
introducing
this,
our
hope
is
that
this
will
help
us
get
the
ear
and
eye
eyes
of
the
infrasect
teams
and
help
to
start
engage
them
in
gitlab,
get
them
involved
in
the
discussions
and
help
start
bringing
them
in
a
little
bit
more
into
the
loop
again.
That
was
another
one
of
the
big
reasons
why
we
moved
container
security
over
from
the
secure
stage
over
the
protect
stage
in
the
first
place
was
to
allow
us
to
build
out
these
production
capabilities.
C
C
B
B
So,
in
the
long
term,
we
have
the
vision
to
move
all
of
that
into
the
security
policy
editor,
but
for
the
short
term
to
keep
us
iterate
iterating
quickly.
We
are
just
adding
capability
to
be
more
flexible
with
those
approvals
in
line
where
it
exists
today.
So
if
you
come
into
vulnerability
check,
if
you
click
enable
you'll
see
already
here
in
production,
you
can
select
a
lot
of
things
that
you
could
not
select
before
you
can
pick
which
scanners
it
applies
to.
B
You
can
pick
which
severity
levels,
whereas
before
it
only
triggered
on
criticals,
highs
and
unknowns.
So
now
you
can
select
which
of
these
you
care
about,
and
you
can
also
specify
the
number
of
vulnerabilities
that
you
want
to
require
that
need
to
be
met
in
order
to
trigger
that
rule.
So
say
you
only
want
you
know
the
approval
rule
to
be
triggered
if
there
are
at
least
three
critical
vulnerabilities,
you
could
select
that
today
and
also
select
the
scanner,
so
it's
a
way
to
filter
things
down.
B
B
You
know
that
triggers
on
one
critical
or
it
triggers
on
three
highs,
and
that's
really
where
this
user
interface
reaches
the
limitation
of
what
it
can
do
so
again.
This
is
available
now
and
we're
going
to
be
adding
a
little
bit
more
to
this
ui,
but
then
we'll
be
shifting
our
focus
to
start
building
that
out
in
the
security
policy
area,
where
we
have
a
lot
more
flexibility
to
start
chaining.
These
things
together
to
create
a
little
bit
of
a
more
complex.
C
Does
that
help
david?
Oh,
it
does,
and
I
I
had
seen
some
of
that
already
in
production,
specifically
the
security
scanners
part,
but
it
should
probably
not
go
uncommented
that,
like
what's
already
been
done
here,
is
really
awesome.
C
I
I
I
it's
a
simple
change
as
you're
talking
about,
but
it
has
a
echoing
recurrent
has
an
impact.
I
can
think
of
the
right
word
right
now,
because
I'm
not
enough
caffeine,
but
customers
are
constantly
asking
for.
How
can
I
control
my
roles
better
and
that
right
there
is
showing
you
could
set
policies
on
feature
branches
versus
you
know,
maine.
You
can
also
specify,
then,
by
scanner
and
severity,
which
is
a
common
request.
B
B
C
Yes,
on
the
topic
of
like
approvals
and
just
general
road
map,
you
did
a
joint
video
with
sam,
the
other
sam
in
devon
sec.
It
feels
like
a
couple
weeks
ago
was
probably
two
months
ago
at
this
point,
but
you
talked
a
lot
in
the
video
about
some
overlapping
roadmap
goals.
C
He
was
talking
about
compliance
roles
and
other
things
like
that,
how's
that
ever
going
so
far,
you
two
began
to
see
some
clients,
not
the
right
word
like
I
guess
I
don't
use
a
buzzword
like
synergy,
but
overlapping
focus
where
you
both
can
help
each
other
accelerate
roadmaps.
B
Yeah,
so
there
definitely
is
a
lot
of
synergy
there.
I
don't
really
see
we're
not
going
to
see
that
happening
in
the
form
of
like
accelerating
each
other's
roadmaps,
but
the
features
that
we're
developing
are
complementary
to
each
other
and
when
we
do
bring
them
together
and
integrate
them
they're
going
to
get
better
together.
So
I
actually
created
I'm
still
working
on
this
slide,
so
bear
with
me:
it's
not
finalized
yet,
but
just
at
a
really
high
overlook
overview.
You
know,
scan
policies
has
certain
characteristics
and
attributes
to
it.
B
Compliance
pipelines
have
other
characteristics
and
attributes
these
tend
to
be
very
complementary,
and
so
what
we've
got
planned
is
still
it's
all
in
the
roadmap,
we're
not
actively
working
on
those
items.
Yet
we
have
some
other
groundwork
that
we
need
to
get
done
first
before
we
can
really
bring
these
together,
but
eventually,
when
we
do
bring
the
two
together,
it's
going
to
get
us
the
best
of
both
worlds
in
a
lot
of
senses.
So,
just
to
talk
specifically
to
some
of
those,
the
flexibility
scan
policies
is
limited
only
to
the
items
that
we
support.
B
So
we've
added
support
for
dast.
We're
adding
in
support
for
secret
detection,
we've
added
in
support
for
scanning
production
clusters
or
we're
working
on
that.
You
know
eventually,
we'll
add
in
support
for
these
scan
results.
Policies
that'll
be
kind
of
like
the
vulnerability
check
2.0
in
a
way,
but
all
of
those
require
individual
efforts,
whereas
compliance
pipelines
are
super
flexible.
Anything
that
you
can
do
in
a
ci
file
can
be
done.
B
That's
going
to
allow
it
to
be
chained
together
with
other
actions,
and
it's
going
to
bring
it
into
the
policy
the
scan
policy
ui.
So
again,
all
of
that
right
now
is
really
more
of
just
a
shared
product
vision.
B
And
just
to
put
a
visual
on
that,
what
that'll
look
like
in
practice
is
part
of
that
plumbing
that
I'm
talking
about
right
now.
Scan
policies
are
only
at
the
project
level.
We
need
to
bring
those
up
to
the
group
level
before
we
can
start
to
integrate
with
the
compliance
pipelines.
B
C
B
I'm
hoping
that
it
materializes
somewhere
around
the
12-month
time
frame,
but
it's
definitely
too
early
to
commit
to
anything.
It's
far
enough
out
that
you
know,
like
I
said,
we've
got
to
first
get
policies
up
at
the
group
and
work
space
levels.
C
So
I
I
have
the
next
question
too:
I'm
just
going
to
keep
on
asking
questions,
but
other
people
by
the
way,
there's
lots
of
you
on
the
call.
Anyone
can
ask
a
question.
It's
not.
This
is
not
just
for
my
amusement.
So,
like
you
have
a
lot
of
really
exciting
plans.
C
I
went
through
the
slides,
of
course,
the
video
like
what
right
now
do
you
see
is
your
biggest
risk
to
your
plans,
because
you
have
a
really
strong
strategy
about
where
protect
needs
to
go,
and
I'm
just
curious
like
what
roadblocks
could
I
be
helping
or
hillary
could
be
helping
remove.
B
Yeah,
I
think,
there's
a
lot
of
value
that
we
have
to
create.
I
think
the
biggest
risk
that
might
you
know
change
things
with
our
plans
is
just
the
overall
performance
and
stability
of
gitlab.
You
know
if
we
end
up
needing
to
re-prioritize
our
resources
in
a
significant
way
to
go
work
on
that.
You
know,
obviously,
that's
going
to
impact
where
we're
headed
in
our
time
frame
to
achieve
it.
If
we
do
make
that
decision,
I'm
sure
it's
going
to
be.
B
B
D
Hey
sam
chris,
garcia
and
new
kit
lever
joining
the
team.
That
was
a
really
cool
workflow
and
I'm
excited
to
kind
of
work
towards
that.
I'm
curious
if
you
talked
with
anyone
in
the
monitor
stage,
for
example,
because
we
just
hired
alana
bellucci
who's
coming
over
from
swim
lane
and
in
a
lot
of
ways,
she's
already
built
things
of
defining
thresholds
and
then
kind
of
creating
actions,
and
that
type
of
thing
I'm
curious.
You
know
that
kind
of
looks
exactly
like
incident
management
to
a
certain
degree.
B
It
is
in
a
lot
of
ways
we
have
talked
with
monitor
not
recently.
So
if
the
person
you
mentioned
is
a
new
hire,
then
we
have
not
talked
with
them,
but
that's
a
great
idea.
If
someone's
got
experience
there,
I'm
always
looking
for
feedback.
B
If
you
could
put
that
name,
I
didn't
quite
catch
the
name
of
that
person.
If
you
could
put
that
person's
name
in
the
notes,
I'll
reach
out
to
them
and
capture
their
input
as
as
well.
So
that's
going
to
have
a
lot
of
overlap
in
general
with
monitor
we're
using
their
alerts
and
their
incident
workflow
page.
So
a
lot
of
the
work
that
monitors
done,
we're
actually
using
all
of
their
back-end
code
and
some
of
their
front-end
code
as
well
for
our
security
alerts.
B
We
have
those
separated
out
just
because
they're
different
personas,
so
the
person
who's
monitoring,
like
cpu
performance,
doesn't
have
the
same
role
and
responsibility
of
reviewing
security
alerts,
but
the
workflows
are
fundamentally
the
same.
So
we
actually
do
have
quite
a
lot
of
collaboration
points
with
the
monitor
team.
B
C
B
Yes,
so
the
ability
to
scan
containers
in
production
has
gotten
a
lot
of
attention.
It's
actually
in
an
alpha
state,
so
we
have
not
been
pushing
it
from
a
marketing
perspective
and
from
what
I
hear
you
know
it's
kind
of
just
spreading
like
wildfire.
People
are
talking
about
it
with
their
customers
and
their
accounts.
B
We're
really
excited
to
get
that
out
of
an
alpha
state
to
finish
out
some
of
the
breaking
changes
that
we
have
to
make
and
get
that
to
a
point
where
it's
really
stable
and
ready
for
customers
to
use
just
because
I've
seen
a
lot
of
their
excitement
around
it.
So
if
I
were
to
pick
one
thing
you
know
for
the
next
three
to
six
months,
I
would
say
that
that's
it.
C
And
then
xavier,
how
are
you
doing
I've
been
talking
in
a
while?
I
think
it's
going.
C
C
You've
got
probably
one
of
the
hottest
topics
right
now
then,
because
it's
coming
up,
I
want
to
say,
like
on
every
customer
call.
How
can
we
add
more
flexibility,
so
the
work
you've
done
is
amazing.
So
far,
thank
you
very
much
yeah.
So
I
during
the
video
and
then
I
think,
you're
on
slide
13.
You
talked
about
detecting
anomalous,
behavior
and
alerting
or
blocking
that
activity.
C
So
I
was
curious
like
how
do
you
see
the
work
you're
doing
with
secure
orchestration,
and
I
think
you
were
talking
about
container
post
security
at
that
point,
overlapping
with
what
the
model
ops
stage
is
doing.
The
flight
ml
team
on
insider
threat,
I'm
assuming
they're,
probably
complimentary
and
you'll-
probably
work
together
with
them,
but
I
was
curious
if
you
could
go
over
that
a
little
bit.
B
Yeah,
so
we're
not
really
working
together
right
now
I
mean
we
are
just
getting
the
initial
release
of
you
know:
policies
security
policies
out
from
behind
a
feature
flag
right
now,
so
we're
not
that
far
along,
but
part
of
the
long-term
vision
for
the
security
policies
is
that
you
would
be
able
to
write
insider
thread
or
mlaps
of
insider
threat,
really
type
policies
in
that
policy
editor.
So
where
I
would
envision
that
going
is
you
know,
they're
working
to
develop
out
their
capabilities
there?
B
Eventually
the
configuration
or
the
policy
workflow
for
that
would
be
managed
in
our
policy
editor
at
least
that's
the
vision
that
I
have
for
it
again.
It's
pretty
far
out.
So
we're
not
we're
not
to
the
point
of
really
coordinating
those
efforts,
but
that's
where
I
would
envision
a
heading.
C
Yeah
I
mean
for
for
everyone,
who's
going
to
watch
the
recording
at
some
point
or
the
session
they're,
not
that
far
along
either
we've
got
alexander
still
on
boarding
from
underview,
as
you
are
aware,
and
job
is
where
the
hall
is
over
there,
helping
out
right
now
and
he's
going
to
decide
whether
he's.
C
Yeah
like
like
we're,
they
don't
have
a
pm
yet
or
an
engineering
manager
yet,
and
all
that,
so
it's
like
they've
got
a
ways
to
go
too.
It's
just
something
I
thought
I
would
ask
about,
because
I
saw
the
for
I
like
how
the
security
policy
editor
is
becoming
like
this
de
facto
standard
on
how
to
do
things
across
the
product,
not
just
in
protect
but
insecure
and
realization.
C
Okay,
so
our
cloud
workload
platform
protection
is
very
plans,
are
very
ambitious
by
the
way,
and
I
love
how
ambitious
they
are.
The
side
note
there's
currently
three
categories
that
make
it
up
and
you
talk
about
it
being
container
host
security,
container
network
security,
container
scanning
and
production.
C
How
would
you
rank
those
in
importance
for
us
and
does
your
ranking
also
map
to
where
we
could
get
the
capture
most
amount
of
market
that
you
highlight
on
slide
17,
because
that
may
not
be
the
case
like
our
best
thing
might
not
be
the
thing
that
has
the
biggest
market
share,
but
I'm
just
curious.
You
could
go
over
that.
B
The
challenge
that
we
had
when
we
went
head-on
at
this
in
2020
was
that
gitlab
doesn't
have
a
lot
of
those
infrastructure
security
personas
using
gitlab
as
of
today,
and
so
getting
a
lot
of
usability
getting
a
lot
of
traction
there.
It
was
a
hard
uphill
battle
for
us.
So
for
us
I
would
say
the
most
important
thing
is
the
container
scanning
and
production
feature
that
we're
working
on
right
now.
B
B
Folks
and
just
you
know
at
least
open
the
door
to
give
us
a
place
to
start
playing
container
network
security
is
something
that
a
lot
of
different
vendors
are
doing.
You
look
at
google
and
you
know
they
have
their
own.
You
know
they
offer
a
way
to
use
network
policies
as
part
of
gke.
B
You
know
there
are
a
lot
of
different
solutions
out
there
for
the
network
protection,
and
so
while
it
is
really
important,
it's
less
of
a
differentiator
for
us.
The
container
hosts
security,
which
really
we
should
probably
actually
renamed
more
of
like
intrusion,
detection
and
intrusion
prevention,
but
not
to
be
confused
with
like
the
endpoint
intrusion
detection
market.
B
E
Let
me
ask,
while
I
type
because
the
follow-up
question
so
when
you
say
that
the
container
hosts
securities
is
second
in
priority,
is
that
is
that
mostly
due
to
the
internal
feedback
we
already
had
like
in
falco
versus
what
was
the
other
one,
it's
falcon
psyllium
yeah
psyllium
is
a
little
bit
harder
because
it's
on
on
network
policies
and
there's
a
lot
more
going
on
there,
but
but
falco
was
deemed
the
more
easily
accessible.
I
guess
from
our
infrastructure
team.
B
I
mean
that's
part
of
it,
but
I
think
we
could
resolve
that
if
we
just
supported
generic
network
policies,
so
you
know
the
fact
that
you
know
there
are
some
support
challenges
with
psyllium
network
policies
in
and
of
itself
doesn't
move
it
down
to
priority
number
three.
I
think
what
moves
it
down
to
priority
number
three
is
the
fact
that
can
you
know,
network
policies
in
general
is
a
little
bit
more
of
a
commoditized
feature.
C
So
it
kind
of
follow
up
to
this
in
case
you're
wondering
if
there's
like
a
motivation
behind
the
question
or
the
first
question
so
on
today,
you're
talking
about
25
effort
being
on
container
host
security.
Does
it
make
sense
from
your
perspective
or
get
jerry's
perspective
to
say
like?
Maybe
we
just
definitely
not
touch
it
for
a
quarter
or
two
quarters
to
get
container
scanning
further,
along
and
on
the
production
side
and
then
come
back
to
it
or
is
by
midnature
that
zero
to
25
percent
means
that
it's
usually
at
zero
percent.
B
Yeah,
so
those
percentage
guidelines
are
what
was
established
when
we
switched
from
the
the
defend
to
the
protect
stage
and
so
far
up
to
this
point,
we
have
not
really
been
fully
staffed,
whether
it's
you
know
for
one
reason
or
another,
there's
been
a
variety
of
reasons
that
we
haven't
really
been
fully
staffed
on
our
our
back
end
team,
and
so
this
has
been
at
zero
percent.
We
haven't
really
touched
it
in
a
really
long
time.
B
At
this
point,
so
I'm
hoping
that
come
october,
we've
got
a
new
hire,
starting
I'm
hoping
at
that
point
we'll
be
able
to
actually
have
someone
start
looking
at
it,
but
we've
been
doing
just
that.
We've
been
accelerating
container
scanning
in
favor.
You
know,
rather
than
investing
in
container
host
security
for
several
months
now,.
C
Yeah
I
mean,
and
then
at
that
time
like
I
would,
I
would
be
biased
and
say
like
I
would
want
you
to
have
that
conversation
with
yourself
is:
does
it
make
sense
to
start
again
on
that
or
get
even
faster
return,
your
maturity
faster
on
the
container
host
security,
but
I'll?
Let
you
decide
that
as
the
dri
sam
and
make
the
right
call
on
it,
just
try
to
understand
where
you
can
get
the
best
bang
for
your
buck.
B
Yeah
at
some
point,
there's
going
to
be
a
tipping
point
right:
we're
going
to
have
done
enough
for
container
scanning
in
production
that
we've
kind
of
met
that
80
20
rule,
and
we
want
to
have
that
next.
You
know
that
next
breadcrumb
trail,
so
to
speak,
for
the
infrastructure
security
team
to
follow.
We
want
them
to
get
interested
in
container
scanning
and
we
want
to
say.
Oh
look,
we've
got
this
other
feature
set
over
here,
and
so
I
think
it
would
make
sense.
B
You
know
at
some
point-
and
I
don't
know
exactly
where
that
line
is,
but
in
some
point
we're
going
to
have
done
enough
on
container
scanning
in
production
that
we're
going
to
want
to
start
to
pick
up
at
least
a
little
bit
of
investment.
There
doesn't
mean
we
have
the
whole
team
on
it,
because
we've
got
a
lot
of
other
priorities
that
we're
juggling
here,
but
at
least
start
to
do
something
in
there.
B
I
think
would
be
useful
so
that
we
can
have
something
else
to
talk
about
and
to
continue
that
discussion
instead
of
just
ending
it
container
scanning.
Only.
C
And
the
last
question
I
threw
in
here
for
you
on
slide
10,
and
I
can
remember
somewhere
in
the
video
you
started
talking
about
how
you're
working
on
a
software
build
materials
and
the
efforts
around
what
that
could
look
like
and
rightfully
so,
not
mentioning
names.
There
are
people
who
play
in
that
same
space
who
that's
like
their
claim
to
fame
as
we
generate
software
built
materials.
C
Today,
the
composition,
analysis
team
has
a
dependencies
list
which
kind
of
serves
that
for
users
they
have
the
export
to
it.
So
you
can
actually
export
out
the
equivalent
of
that,
I
would
say
when
I
wrote
this
in
there
like
nicole,
would
obviously
admit
that
it's
nowhere
near
as
mature
as
it
should
be.
Just
for
the
sake
of
calling
that
out.
Do
you
see
what
you're
planning
on
doing
around
software
build
materials
to
be
complementary
to
what
they're
doing
augmenting
it?
Or
is
it
something
different
that
I'm
not
following.
B
Yeah,
so
I
would
see
that
as
just
feeding
into
that
existing
ui.
I
don't
think
we
need
two
separate
uis.
I
don't
see
any
reason
to
have
you
know
anything
separate
there.
It's
the
same
persona,
it's
the
same
problem
and
really
you
know
it's
only
our
internal
gitlab,
that's
separating
out
the
operating
system
packages
versus
the
language
specific
packages
for
a
lot
of
our
customers.
That's
just
all
one
and
the
same,
and
it's
part
of
that
s
bomb.
B
C
I
can
finish
having
my
question
after
I
said
it,
but
again
it's
like
maybe
a
follow-up
to
your
answer.
Then,
should
we
consider
at
some
point
that
software
bill
materials
or
digital
bill
materials
as
linux
foundations,
defining
it
as
its
own
category
that
multiple
teams
are
feeding
into
or
do
you
think
it's
fine
that
it
it's
not
a
category,
because
the
existing
category
is
particularly
included
as
a
feature.
B
I
think
it
could
go
either
way
depending
on
how
you
want
to
carve
it
up.
You
know,
I
think,
that's
more
about
our
own
internal
organization
of
things
rather
than
what
impacts
the
customer.
So
I
think
that's
just
more
of
an
organizational
question.
I
don't
have
a
strong
opinion
on
whether
it's
a
dedicated
category
or
a
feature
in
a
category
either
way
we're
going
to
be
contributing
into
the
work
that
they're
already
doing
and
just
adding
our
stuff
into
the
same
list.
B
C
Yeah
the
thought
process
is
more
the
visibility
to
the
customer
like
yes,
we
have
this
functionality,
because
the
question
that
I
get-
and
I
know
if
you've
run
into
this
in
your
customer-
calls,
but
occasionally
they
say
well,
do
you
support
software
composition
analysis?
Because,
instead
of
having
a
category
that
says
sca,
we
have
three
categories
that
support
it,
and
so
I'm
always
thinking
about
how
we
make
it
clear
for
the
for
the
customer
and
then
internally
we
can
figure
out
who's,
doing
which
part
of
what,
but
just
curiosity
on
what
you're
thinking.
B
E
E
C
Yeah,
I
know
this
is
not
related
to
this
meeting
per
se
or
this
q
a
for
protect,
but
there's
a
little
bit
of
bumblings
about
that
already
so,
nicole,
on
top
of
working
with
sam
on
s-bomb
d-bomb
type
related
stuff
she's
been
talking
with
the
verify
team,
because
they're
looking
at
doing
what
I've
been
calling
runner-less
runners
because
essentially
they're
looking
to
be
able
to
have
a
scanner,
be
kicked
off
without
the
need
of
a
pipeline,
and
if
they
can
do
that
to
your
point,
we
can
then
actually
pre-load
the
current
advisories
as
opposed
to
waiting
until
pipeline
starts
and
then,
as
soon
as
that
update
kicks
off,
she
would
be
able
to
then
kick
off
that
process
to
say:
hey.
C
These
are
the
35
new
advisors
that
came
in.
Does
it
impact
the
existing
known
for
materials
which
would
be
pretty
thick?
It
would
give
us
that
a
little
bit
of
an
edge
that
essentially
twice
a
week
you'd
be
getting
updates
as
opposed
to
waiting
for
another
pipeline
run
and
that
pipeline
may
or
may
not
pick
up
a
new
database.
If
there's
not
been
an
update
yeah,
we.
E
It
might
be
a
lovable
thing,
but
we
are
biased,
biased
in
that
in
developing
gitlab.
We
we
run
hundreds
of
pipelines
every
day,
so
we
don't
get
that
experience
from
from
customers
and
users
that
run
that
less
often,
and
the
second
thing
on
what
you
say
is
that
I,
I
think,
we're
victims
of
our
own
success
with
the
with
the
with
the
runners
and
everything
as
a
runner
and
and
slowly
we're
starting
to
look
at
okay,
maybe
maybe
the
they're
more
efficient
ways
of
doing
these
things.
Sorry,
sam.
This
is
sort
of
big.
B
Time,
tangent,
anyone
can
answer
this
conversation
so
yeah
I
mean
it
just
goes
to
that.
Second
and
third
bullet.
I
know
david
and
slack
today
were
talking
about
you
know
what
does
it
take
to
get
container
scanning
to
complete,
and
this
would
be
part
of
that.
That's
what
I
was
referencing
there
saying
you
know
we
need
to
adjust
our
architecture.
B
You
know
before
we
get
to
complete.
We
would
want
to
store
that
list
and
eventually
we
may
not
even
need
to
use
those
runners
at
all.
We
would
just
be
able
to
run
a
scan.
You
know
near
instantaneously
and
and.