►
From YouTube: Protect PM/CS Sync - June 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
Dive
in
hello,
welcome
to
our
monthly
sync
up
with
product
management
and
cs.
So
just
a
few
things
to
highlight,
we
have
a
quarterly
strategy
review.
We
had
one
last
month,
there's
a
lot
of
good
content
in
there.
If
you
have
a
chance
to
review
it,
I
highly
recommend
it
if
you're
just
looking
for
a
good
overview
of
the
protect
stage
or
an
understanding
of
what
our
strategy
is
for
the
next.
You
know,
six
to
12
months
is
really
the
content
that's
covered
in
there
just
agenda
items.
A
I
wanted
to
highlight
a
few
big
things
that
are
coming
out
here
in
protect
in
140
we're
making
that
switch
from
claire
and
clar
over
to
trivi
for
our
container
scanning
engine.
That's
actually
already
live
in
gitlab.com
and
then
for
self-managed.
It
will
be
available
with
the
official
14.0
release.
We've
had
some
really
good
positive
feedback
from
nearly
all
of
our
customers
on
that,
and
it
fixes
a
lot
of
underlying
bugs
we
had.
I
think
we
closed
out
over
20
issues
by
making
that
switch.
A
It
gives
us
more
up-to-date
vulnerability,
data
and
support
for
more
distributions
and
the
it
also
lays
the
ground
for
us
to
be
able
to
start
scanning
containers
running
in
a
production
environment,
which
is
actually
one
of
the
big
reasons
why
we
made
that
switch
to
begin
with.
Trivia
is
a
open
source
project
by
aqua
secure
and
they
have
a
sister
company
or
not
company.
A
sister
project
called
starboard
that
lets.
A
You
grab
that
information
so
making
that
switch
had
a
lot
of
really
positive
benefits
for
us,
and
you
actually
see
that
it
says
14
2
in
the
agenda,
but
we
actually
probably
have
the
first
iteration
of
scanning
containers
in
production
out
in
14.1,
so
hot
on
the
heels
of
that
switch
and
then
the
other
upcoming
item,
also
in
14
1,
is
our
security
policies.
We've
been
releasing
that
over
the
past
several
iterations
here,
but
behind
a
feature
flag.
A
The
way
we
work
at
gitlab
is
iterative,
so
you
know
that's
really
where
only
a
starting
point,
but
we're
planning
to
turn
that
on
in
or
turn
the
feature
flag
on
by
default
in
14.1,
so
that'll
be
visible
to
customers
and
shortly
after
we're
going
to
start
expanding
that
to
support
things
like
secret
detection
and
sas
and
then
we'll
be
moving
that
up.
So
you
can
write
group
level
and
workspace
level
policies,
but
a
lot
of
big
releases
release
items
coming
out
here
in
the
near
term.
A
B
A
So
our
compliance
team
is
not
under
protect.
Our
compliance
team
is
actually
under
manage
in
the
manage
stage,
but
we
are
working
pretty
closely
together
and
there
is
some
degree
of
overlap
there,
like
you
know,
we're
actually
looking
internally
to
start
scanning
all
of
the
containers
running
in
production
to
meet
socks
requirements
right.
So
there
is
some
overlap
between
the
two
groups
same
thing:
if
you're
talking
about
like
requiring
sas
or
das,
to
run
as
part
of
a
pipeline,
there's
definitely
a
lot
of
people
out
there.
A
Protect
has
been
focused
on
protecting
things
running
in
production,
and
one
of
the
big
requirements
in
that
area
is
doing
vulnerability
scanning
for
what's
actually
in
production.
A
lot
of
customers
have
things
that
they've
deployed
an
embarrassing
amount
of
time.
A
You
know
in
the
past
and
haven't
updated
or
haven't
kept
up
to
date,
or
you
know
they're,
not
even
necessarily
aware
of
what
all
is
out
there.
You
know
I've
had
some
customers
hint
that
they
have
stuff
running
even
from
like
three
to
five
years
ago
that
was
deployed,
and
so,
if
you
have
like
a
customer,
that's
using
cd
and
they're
constantly
deploying
you
know
every
day
to
production
the
difference
between
what
you
scan
in
your
pipeline
and
what
you
scan
in
production
is
going
to
be
pretty
much
the
same.
A
What's
in
your
source,
code,
repository
and
so
container
scanning
is
really
the
first
place
to
start
when
we
think
of
production
scanning
just
getting
a
baseline
of
you
know
what
packages
are
out
there
and
what
known,
cdes
and
vulnerabilities
are
out.
There
is
really
again
it's
the
first
place
to
start
with.
All
of
that,
so
it
made
a
lot
of
sense
to
move
it
over
to
protect
so
that
we
didn't.
You
know,
rather
than
re-engineering
a
totally
new
solution
for
production
scanning.
A
B
Thanks,
that's
great
information.
You
know
really
to
to
be
able
to
tell
customers
that
we
can
use
this
in
production.
It's
going
to
be
awesome,
so
looking
forward
to
that.
B
B
A
Yeah,
so
if
I
had
a
customer,
ask
me
that
today
the
way
I
would
respond
is,
I
would
point
at
our
auto,
suggested
solutions
for
for
vulnerabilities.
So
we
do.
We
don't
want
to
just
auto
remediate
things,
because
that
has
the
potential
to
break
things
and
we
never
want
to
break
their
production
environment,
but
we
do
have
the
ability
in
gitlab
to
auto,
suggest,
fixes
and
and
even
auto,
create
an
mr
for
them
to
go
and
apply.
So
again.
A
If
I
had
to
sell
like
what
exists
today,
that's
kind
of
what
I
would
focus
on
is
we're
giving
you
some
guidance
around
how
to
fix
that
as
part
of
git
lab,
but
yeah
long
term,
I
mean
getting
into
like
a
managed
service
provider
model
where
we're,
actually,
you
know
handling
those
vulnerabilities
for
somebody.
I
don't.
I
don't
think
we
have
interest.
At
least
I
have
not
heard
any
discussions
in
gitlab
of
us
heading
into
that
area
ourselves.
A
So
that
might
be
a
good
if
they
really
want
that
full
kind
of
remediation
management,
then
they
might.
You
might
look
at
bringing
a
partner
in
to
the
deal
where
you
know
a
traditional
mssp
might
be.
That
kind
of
you
know
service
for
them
and
go
through
and
do
those
remediations.
B
Yep
because
that's
we
did
a
pov,
and
that
was
one
of
the
things
that
you
know
why
they're
leaning
towards
the
other
tools
is
because
they
had
those
services,
so
a
partner
might
be
the
way
to
go
I'll
talk
to
our
channels,
team
and
see
you
know
if
there's
if
we
have
partners
like
that
out,
there.
A
A
C
I
do
so
from
a
hot
issue
perspective
the
executive
order,
which
I
just
linked
over
in
the
dock.
Have
you
had
a
chance
to
review
the
order?
Do
you
know
what's
going
on
with
that.
A
Yeah,
I
know
one
of
the
big
elements
is
that
they're
pushing
well
requiring
any
vendor
to
provide
a
build,
an
s-bomb
like
a
software
built
with
materials.
I
am
familiar
with
it.
I've
not
read
the
whole
thing.
C
Yeah
I
mean
it's
essentially
the
backdrop
is
the
supply
chain
problem
with
solarwinds
and
then
subsequently
the
colonial
pipeline
problem,
which
really
wasn't
a
supply
chain
problem,
but
it
was
just
a
cyber
security
issue,
so
it's
really
around
how
to
find
and
fix
things
quickly
and
then
how
do
software
vendors
provide
a
software
bill
of
materials?
C
The
definition
of
s-bomb
actually
has
been
provided
by
the
federal
government.
So
let
me
find.
C
That
here
we
go
so
the
national
telecommunications
and
information
administration
has
defined
s-bomb.
C
C
So
this
is
the
definition
that
they
are
going
by.
It's
not
exactly,
and
I'm
not
sure
if
it
is
exactly
aligned
with
our
definition
or
the
industry
definition,
but
this
is
how
they
define
it.
This
is
going
to
sort
of
become
the
baseline
of
what
they
think
is
the
software
below
materials.
C
Now
there
are
multiple
components
to
this.
One
is
the
one
is
what
you
find
in
the
scan
while
the
product
is
being
developed,
which
is
a
static
bill
of
materials,
and
then
there
can
be
dynamic
ones,
particularly
case
in
point:
is
you
know
the
solarwinds
thing
was
a
dynamic
link
library.
C
The
fact
of
the
matter
was
the
component
was
actually
getting
called
in
real
time,
so
there
is
a
a
very
interesting
conversation
going
on
back
and
forth
around
where
and
when
does
the
s-bomb
become
complete,
so
kind
of
bringing
it
back
to
the
whole.
Protect
conversation
here
is
s-bomb,
isn't
necessarily,
in
my
opinion,
just
the
libraries
that
you're
putting
into
your
product
in
the
container
world.
C
It
can
be
the
container
you're,
inheriting
as
part
of
the
layers
that
you're
developing
right,
so
it
could
be
a
combination
of
the
two
and
then
there
are
many
others
you
know
which,
which
which
package
you
use
and
then
which
package
manager
you
use
and
then
how's
that
I
mean
there's
like
so
many
vectors
of
where
software
build
materials
comes
into
play.
C
You
know
just
something
that
I
think
we
need
to
be
actively
discussing.
I
know
jonathan
hunt
has
sort
of
taken
a
little
bit
of
a
front
runner
role
in
working
with
the
nist,
but
I
think
from
a
product
perspective.
We
need
to
have
a
little
bit
thought
on
our
definition
and
how
we
see
the
world
in
devops.
C
So
that's
just
something
I
would.
I
would
highly
recommend
if
you
want
me
to
create
an
issue
somewhere,
so
we
can
have
this
discussion
I'll
be
happy
to
do
that.
I
I
don't
know
where,
where
we
want
to
take
this
and
how
this
kind
of
affects
specifically
protect,
but
I
would
think
it
does.
C
Yes,
and
from
what
I
understand,
that's
just
what
is
scanned
in
the
pipeline
is
that
correct.
A
Yeah,
so
right
now
that
dependency
list
is
only
generated
from
our
dependency
scanning
job,
so
it
only
looks
at
software
dependencies
like
software
package
dependencies
specifically,
what's
not
included,
is
a
listing
of
all
of
the
packages
in
the
container.
So
you
know
what
we
really
need
to
make
a
full
s-bomb.
A
You
know
I
would
say
that
we
have
a
partial
s-bomb
today,
but
to
have
a
complete
s-bomb.
You
know
and
include
those
elements
that
you
were
referring
to
earlier.
Samir
of
you
know
the
things
that
are
in
the
container
and
in
the
various
image
layers.
What
we
really
need
to
do
is
include
the
operating
system
level
packages
in
that
list.
So
that
is
something
that
we
would
like
to
do,
that
that
is
at
least
notionally
on
our
roadmap.
A
A
You
know,
obviously
that's
a
workaround
and
not
an
ideal
solution,
but
we
do
want
to
eventually
bring
those
in
and
add
those
into
that
dependency
list
as
well,
so
that
they
don't
have
to
go.
Do
that
on
the
side
and
merge
those
together.
They've
just
got
it
all
in
one
place.
C
Yeah
now
that's
that's,
I
think
that's
excellent
advice
and
it
does
make
sense-
and
I
think,
where
we
are
grappling
a
little
bit-
is
trying
to
understand
how
to
approach
the
customer,
because
we
don't
want
to
we.
We
can't
do
everything
that
that's
that's
a
given,
but
where
we
can
do
something
and
how
we
differentiate
ourselves
against
competitors.
C
I
think
that's
sort
of
the
messaging
that
we
would
have
to
put
together
so,
but
but
this
is
I
thank
you
for
sharing
this,
because
this
is
I've.
Never
even
thought
of
something
simple
like
this
right
and
the
simplicity
is
the
beauty
of
it.
Is
it's
it's
you
don't
have
to
install
like
40
million
different
things
to
make
this
happen.
This
is
literally
a
simple
command
that
you
run
in
your
ci
job.
You
grab
the
artifact
and
you're
done.
That's
awesome.
A
Right
yeah
getting
the
listing
is
not
hard,
especially
for
operating
system
level
packages,
because
it's
just
one
command
right,
like
I
said
we're
actually
doing
all
of
the
hard
part
for
them,
which
is
getting
a
list
of
all
of
those
software
dependencies,
because
that
would
be
way
more
than
one
command
to
go
figure.
All
of
that
out.
So
you
know
we've
done
all
of
the
heavy
lifting.
Obviously
we
have
a
product
gap
that
we
need
to
close
to
you
know
so.
A
C
C
So
one
of
the
customers
asked
us
like
why
and
then
the
second
thing
they
asked
us
is:
what
do
I
have
to
do
so
you
know
if,
when
I
upgrade
to
14.0,
obviously
there
will
be
some
instructions,
but
is
there
anything
else
that
I
need
to
think
about
in
terms
of
the
result?
Sets
that
I
get.
Those
are
the
two
common
questions
that
come
up,
and
maybe
you
have
addressed
this
and
I
just
you
know
just
you
just
need
to
point
me
to
somewhere.
A
Yeah,
so
why
switch
to
trivia?
I
did
cover
this
at
the
beginning,
but
I'm
happy
to
go
through
it
again.
We
had
several
reasons,
one
so
probably
the
biggest
one,
that's
most
immediately
impactful
for
customers
is
that
the
claire
project
that
we
were
using-
and
this
is
more
technical
detail
than
you
would
share
with
a
customer,
but
we
were
actually
using
a
small
offshoot
of
the
main
claire
project
because
it
provided
it
made
it
a
whole
lot
easier
for
us
to
run
the
scans
in
a
cicd
pipeline.
A
That
offshoot
was
poorly
maintained
and
it
started
to
have
some
issues
with
its
upstream
vulnerability
data
sources,
and
so
we
tried
to
work
with
those
maintainers
and
it
was
largely
unsuccessful.
It
seems
like
that
particular
project
we
were
using
was
just
not
being
well
maintained,
so
we
were
left
with
a
few
options.
We
could
go
back
to
the
main.
A
You
know
underlying
core
claire
project
and
build
in
that
extra
functionality,
ourselves,
which
would
be
obviously
costly
and
time
consuming
or
we
could
switch
to
a
new
new
provider.
So
customers
on
claire
and
clark
right
now,
some
of
their
vulnerability
data
feeds,
are
not
up
to
date,
so
they're
not
getting
the
latest
vulnerabilities
right
now,
incidentally,
moving
to
trivia
allowed
us
to
close,
like
almost
20
bugs
and
and
issues
and
feature
requests
that
we
had
open.
A
It
also
allowed
us
to
support
an
additional
operating
system
in
addition
to
what
claire
had
so
it
had
better
operating
system
coverage.
It
supports
distro-less
and
then
probably
the
biggest
reason,
though
you
know,
on
top
of
all
of
that,
was
we
wanted
to
start
scanning
containers
running
in
production
and
doing
that
with
claire
was
going
to
be
fairly
difficult.
A
When
we
looked
at
the
options,
trivi
was
a
clear
winner
in
that
area.
Trevi
has
a
sister
project
called
starboard
that
lets
you
go
grab
all
of
the
images
running
you
know
from
a
production
environment
and
scan
those,
so
moving
to
trivia
is
what's
enabling
us
to
do
this
production
container
scanning.
A
So
it
was
a
combination
of
all
four
of
those,
but
in
the
end
we
did
a
fairly
detailed
analysis
of
claire
versus
trivi,
and
it
was
you
know
it's
not
like
trivia
was
a
clear
winner
all
the
way,
but
trivia
generally
was
better
than
claire.
You
know,
when
you
come
down
to
some
of
the
detailed
aspects.
They
have
more
data
sources
than
claire
they're,
just
better
maintained
in
our
opinion,
but
you
know
lots
of
reasons
going
into
that
decision.
A
For
your
second
question,
what
do
customers
need
to
do
to
switch
to
trivia?
The
answer
is,
it
depends
we
have
our
documentation
is
live.
It's
been
live
for
a
few
months
and
I
can
include
a
link
to
that.
But
the
short
answer
is:
if
they're
using
auto
devops,
they
shouldn't
need
to
change
anything.
A
A
Time
has
flown,
we
are
almost
at
time.
Thank
you
for
all
the
great
feedback.
Are
there
any
other
points
that
we
should
cover
on
the
call
today.
C
No,
I
think,
keep
doing
what
y'all
are
doing.
It's
awesome
work
and-
and
we
are
now
in
the
ast
as
a
challenger,
which
is
awesome
just
in
a
general
sense,
secure
plus
protect
just
keep
doing
more
of
what
you're
doing.
Thank
you.