►
From YouTube: Protect PM/CS Sync - June 2022
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
I
think
I'll
actually
switch
these
I'll,
give
you
a
road
map
update
first,
and
let
you
I'll
give
you
give
you
a
little
more
time
to
think
about
if
you've
got
any
hot
issues
or
focus
areas
or
other
things
to
bring
up
so
the
biggest
one.
Today.
I
just
wanted
to
give
an
update
on
our
roadmap
at
the
moment.
A
So
I
thought
it
would
be
useful
for
you
just
to
be
aware
of
this
epic
we're
actually
deferring
a
lot
of
other
new
feature
work
in
favor
of
picking
this
up.
If
you're
familiar
with
the
back
end
details
of
how
dependency
scanning
works,
it
just
produces
an
artifact
file
with
all
of
the
dependencies
and
then
when
we
show
it
in
the
dependency
list
it
it's
actually
not
pulling
from
the
database.
It's
actually
parsing
through
that
artifact
file
that's
stored
and
displaying
that
information
directly
from
that
file
and
that
works
for
this
for
an
mvc.
A
A
You
know
parsing
all
of
those
artifact
files
for
thousands
of
projects
and
then
bubbling
those
up
to
the
group
level
and
then
searching
them
would
just
be
it's
just
not
scalable
at
all.
So
it's
really
limited
our
ability
to
surface
this
up
higher,
and
so
what
we're
actually
planning
to
do
is
have
container
and
dependency
scanning
output,
just
raw
cyclone
dx
formatted
artifacts.
A
But
it
also
comes
with
another
nice
side
effect
of
because
we're
storing
these
dependencies
in
the
database.
What
we
can
actually
do
is
bring
in
our
advisory
database
into
the
gitlab
database
as
well,
and
then
we
can
run
this
vulnerability
match
service
anytime
either
of
those
two
items
change,
and
so
this
actually
lets
us
move
the
scanning
itself
out
of
the
pipeline
and
into
the
back
end,
and
it
makes
it
continuous
so
again,
instead
of
a
pipeline
driven
approach,
it's
an
it's
driven
on
change!
So,
anytime.
A
You
know
your
dependencies
change,
you're,
going
to
run
a
pipeline,
that's
going
to
generate
a
new
s
bomb,
that's
going
to
be
pushed
into
the
database
and
that
will
trigger
the
vulnerability
match
service
and
then
also
anytime.
Our
advisory
database
gets
an
update.
We
can
rerun
that
service
so
again,
kind
of
a
side
effect
of
this
is
that
this
dependency
list,
and
then
the
list
of
vulnerabilities
in
your
vulnerability
report
have
the
potential
to
just
always
be
up
to
date
with
the
latest
the
latest
advisory
data
all
the
time,
even
without
running
an
additional
pipeline.
A
And
I
know
I'm
throwing
a
lot
of
stuff
out
here
in
a
really
short
period
of
time.
So
just
stop
me
if
I
need
to
go
through
any
of
this
in
more
detail
just.
B
A
quick
question
on
that,
so
I
can
link
the
epic
in
the
thing,
the
agenda.
Sorry,
it's
still
like
9am
here
and
I
apparently
don't
know
how
to
work
this
early
anymore,
but
as
one
of
the
eventual
goals
going
to
be
able
to
have
like
organization-wide
searches
for
customers
like
when
log4j
vulnerabilities
hit.
Instead
of
having
to
go
through
the
longer
process
and
using
our
api
to
find
those
potential
vulnerabilities
within
repos,
we
have
a
different
mechanism
for
customers.
A
A
And
then
you
know
once
we
have
that
done
and
we
have
those
continuous
vulnerability
scans.
Then
we
can
move
on
to
things
like
having
a
group
level
dependency
list
or
being
able
to
filter
and
search
it.
So
we've
got
both
of
those
on
our
future
roadmap,
but
they
are
both
blocked
by
getting
that
information
in
the
dependent
in
the
database.
First.
B
A
Yeah,
so
that's
a
big
reason
why
we're
prioritizing
this
another
big
reason
that
we're
prioritizing
this
is
currently
our
license.
Compliance
solution,
our
use
of
license
finder
is
just
it's
draining
the
team's
time,
because
the
upstream
project
is
not
well
maintained
and
so
we're
taking
on
that
maintenance
burden
and
the
end
result
is
that
the
team
has
really
been
underwater
for
the
last
year
and
has
not
really
been
able
to
focus
as
much
as
they
would
like
on
new
feature
development.
A
A
C
Sam,
I
have
a
quick
question
about
that.
So
traditionally
licensed
match
used
to
be
a
separate
policy
type
thing
where
you
could
really
block
up
the
merge
request.
If
a
license
was
on
the
deny
list,
if
that
moves
into
the
container
dependency
scanning,
how
does
so
will
that
sort
of
trigger
that
policy?
A
Correct
so
the
container
and
dependency
scanning
they
won't
even
be
doing
scanning
scanning,
will
kind
of
not
really
be
an
accurate
term
anymore.
To
be
honest,
it's
more
like
an
s
bomb
generator
right,
it's
your
container
s
bomb
generator
and
it's
your
dependency
s
bomb
generator,
and
so
that's
finding
the
list
of
components
and
then
the
components
get
matched
on
the
back
end
and
rails
to
determine
which
licenses
are
associated
with
those
components
and
which
vulnerabilities
are
associated
with
those
components.
A
So,
yes,
you
will
still
be
able
to
enforce
that
on
the
merge
request.
And
actually
you
know
this
is
another
item-
that's
in
our
backlog,
if
I
can
find
it,
but
adding
in
license
approval
policies
and
replacing
license
checks.
So,
just
like
we
went
through
this
whole
migration
away
from
vulnerability
check
and
we
move
that
into
a
security
approval
policy.
A
We
actually
want
to
do
the
same
thing
and
move
these
license
approval
policies
into
that
policy.
Editor.
You
know
we
have
sort
of
a
prototype
here
of
you
know.
If
the
license
scanner
finds
more
than
zero
of
these
licenses,
then
I
want
to
require
approval
from
these
individuals.
So
the
idea
is
to
consolidate
all
of
these
in
that
policy
editor
at
a
future
point
in
time.
C
A
So
I
know
I've
kind
of
deviated
and
I'm
presenting
a
lot
on
the
composition,
analysis,
roadmap
and
technically.
This
is
for
secure,
but
I
just
wanted
to
share
all
of
this
because
of
the
overlap
that
it
has
with
container
scanning,
which
is
owned
by
protect,
and
so
the
net
result
is
we're
actually
collaborating
between
the
two
teams.
A
C
Very
cool
sam,
I
do
have
a
couple
of
questions
with
regards
to
somewhat
protect
and
somewhat
around
what
you
just
presented
are
we
are
we
at
a
point
where
we
can
move
into
that,
or
do
you
have
anything
else
you
want
to
present
first
yeah,
absolutely
so
number
one
is
all
of
this
going
to
work
on
red
hat,
open
shift
or
not.
That's
the
first
question.
If
it
already
does,
how
are
we
making
sure
that
it
continues
to.
A
Yeah
it
already
does
container
scanning
supports
red
hat,
open
shift.
Dependency
scanning
supports
right
at
openshift,
I'm
actually
not
sure
about
license
finder.
I
think
that's
the
only
thing
that
might
not.
I
will
have
to
double
check
on
that,
but
obviously,
once
we
replace
it,
then
you'll
no
longer
have
that
license
compliance
image.
So
then
it
will
so
the
short
answer
is
yes.
This
will
continue
to
work
on
red
hat,
open
shift
and,
if
anything,
actually
we
might
be
expanding
our
support
by
adding
license
compliance.
Support
for
red
hat
openshift.
C
Okay,
specifically,
I'm
interested
in
the
concerns
that
a
lot
of
my
customers
have
around
the
the
rootless
containers
problem
that
we
seem
to
have
with
the
secure
containers
running
in
openshift.
A
I
thought
that
we
addressed
that
for
everything,
except
for
for
everything,
except
for
license
compliance.
C
Yeah
there
was
a
there
was
an
issue
and
I'd
have
to
go,
find
it
that
that
actually
had
details
on
what
is
not
operational.
Still.
A
C
Okay,
I'll
I'll
validate
that
and
get
back
to
you
I
just
want
to
I
mean
we
don't
need
to
get
into
whether
whether
it
is
there
or
not.
I
just
want
to
be
sure
that
we
continue
our
continue
to
keep
our
eyes
on
it
and
don't
forget
it
because
you
know
in
a
further
in
iteration
and
I'm
just
throwing
this
out
there,
it's
possible
that
the
the
product
team
might
say.
C
A
Yeah,
I'm
less
sure
about
dependency
scanning
because
I'm
newer
to
that
one
and
that
one
actually
does
have
to
build
the
application,
so
it
might
need
root
privileges,
but
regardless
we're
doing
a
lot
less
work
in
the
pipeline
than
we
were
before
right
right.
So
it's
only
going
to
make
open
shift
support
better,
not
worse
with
this
change,
because
we're
shifting
that
a
lot
of
that
logic
out
and
into
rails.
C
Cool
okay,
good.
The
second
thing
that
I
had
a
question
about
was
with
regards
to,
and
you
may
have
covered
this
in
the
past,
and
I
apologize
if
I've
forgotten
about
it.
The
customer
was
asking:
how
do
I
scan
for
vulnerabilities
in
running
containers
that
have
been
deployed
in
kuber?
Sorry
in
in
kubernetes,
via
get
labs,
kubernetes
agent
and
see
that
result
and
my
my
suggestion
to
them
was
yeah.
You
can
do
that
and
I
forget
the
name
of
the
tool
that
we
had
for
real
real-time
live
scanning.
A
We
have
we
were
using.
Starboard
is
probably
the
starboard
that
was
the
one
yeah.
We
actually
no
longer
require
you
to
install
starboard
to
do
that.
That
was
a
great
improvement
that
we
made
it's
actually
very
easy
to
to
scan
your
production
environment.
Now
all
you
have
to
do
is
install
the
gitlab
agent
and
then
you
just
set
up
this
cadence
for
who
you
want
it
to
run.
A
A
We
found
that
we
were
actually
only
using
a
few
lines
of
code
from
starboard,
and
so
we
ended
up
just
it's
an
open
source
project,
so
we
ended
up
just
taking
that
code
and
including
it
directly
in
the
gitlab
kubernetes
agent
to
save
users
from
needing
to
install
the
entire
starboard
project,
which
does
a
lot
more
than
just
this,
so
yeah
you
can
specify
which
namespaces
are
scanned.
You
can
specify
the
cadence
and
there
are
actually
going
to
be
two
ways
of
setting
this
up.
One
is,
let's
see
here.
A
A
Once
we
get
all
of
that
done,
it
is
still
in
alpha
at
the
moment,
but
we're
getting
very
close
to
going
straight
from
alpha
over
to
ga
here.
Currently
we're
projecting
like
15.2,
I
believe,
with
the
possibility
of
getting
it
at
15.1.
C
Awesome.
Thank
you.
Thank
you
for
clarifying
that
sam
because,
as
you
noticed
in
the
documentation,
it
does
talk
about
starboard
and
that
I
think
that's
what
I
mentioned
to
the
customer,
but
the
vulnerabilities
would
show
up
in
the
the
screenshot.
Where
is
that
from
I'm?
Not
placing
that
in
my
head
exactly
where
that
screenshot
is
going
things.
A
Go
up
on
the
vulnerability
report
and
they
show
up
in
operational
operation
that
was
it
okay
and
then
they
also
show
up
the
screenshot
you're.
Seeing
here
is
of
the
agent
itself,
so
this
is
showing
everything
for
the
entire
project.
A
On
this
page,
it's
going
to
show
everything
for
this
agent
and
then
on
the
vulnerability
report.
It's
going
to
show
it
for
the
project.
Actually,
it's
also
going
to
show
everything
for
that
agent
in
both
locations.
I
believe,
okay,
because
we
don't
have
a
way
to
map
it
back
to
the
project
right.
We
just
right
and
there's
no
way
to
make
that
linking
between
which
project
is
which.
C
A
We
do
have
things
coming,
though,
so
that
you
can
filter
we're,
adding
some
additional
filters
here
soon,
so
that
you
can
filter
by
by
agent.
You
know
by
your
cluster
and
then
you
can
also
filter
by
image,
potentially.
A
So
I'm
not,
I
know
matt
wilson,
so
matt
wilson
actually
owns
this
page,
so
we're
just
oh
yeah,
okay
to
add
in
like
better
search
and
filter.
I
don't
know
if
he's
including
cves
in
that,
but
whatever
they
do
here,
we
will
get
the
benefit
of
that
as
well.
C
Awesome
cool,
thank
you
for
clarifying
that
as
well
sam,
because
that
that
was
the
missing
piece
and,
and
the
agent
is
very
new
and
so
trying
to
kind
of
figure.
Some
of
this
stuff
out
is
a
little
bit
of
a
challenge,
but
thank
you
for
clarifying.
A
You
know,
because
that's
that's
why
we're
keeping
it
in
alpha
is
because
we
are
making
some
of
these
big
changes.
Like
you
know.
Oh,
you
know,
starboard
is
no
longer
required
and
you
know
it
is
very
much
still
under
development,
but
we're
hoping
that
once
we
get
it
and
officially
announce
it
as
ga
ready
here,
you
know
that's
when
we
really
expect
it
to
be
stable
and
you
know
ready
for
for
production.
A
D
C
Maybe
maybe
I
just
saw
an
issue
about
it,
but
I
I
know
there
was
some
conversation
about
that
francis
I
I
just
can't
recall
it
ever
making
it
on
that
summary
page.
I
thought
it
was
in
the
detail
page,
that's
how
I
recall
it
to
be.
A
I
know
this
one's
been
one
that
we've
been
working
on
for
quite
a
while,
and
a
lot
of
customers
have
requested
it.
Let's
see
if
I
can
find
it
here,
add
support
for
group
level
policies.
A
So
this
one's
getting
close,
it's
probably
not
going
to
be
turned
on
the
feature
flag,
probably
won't
be
turned
on
until
15.2
is
where
this
one's
in,
but
it's
getting
really
close.
So
there
is
enough
chance.
It
makes
it
into
15
one.
I
suppose
when
we
do
release
this,
it
actually
is
going
to
only
support
scan
execution
policies
for
the
first
iteration
and
then
we'll
be
adding
in
support
for
scan
result
policies
as
in
as
another
follow-on
step.
So
I
didn't
want
you
to
just
be
aware
of
that.
A
C
A
A
If
we
dive
into
the
technical
backend
details
which
will
allow
us
to
easily
take
advantage
of
workspace
as
soon
as
it's
available.
So
we
have
one
set
of
code
that
gets
reused
for
project
subgroup
group
and
yeah,
potentially
workspace
in
the
future.
Once
it's
available.
C
A
Not
maintainer,
so
only
owners
can
set
the
can
change
the
linked
security
policy
project
and
then
it's
up
to
them
to
determine
who
they
give
access
to
that
security
policy
project.
They
can
give
developer
and
maintainer
access
out.
Just
like
you
would
with
any
other
project,
and
so
they
can
make
those
decisions
on
their
own
very
cool.
C
A
Times
you
have
some
limits
that
you
should
be
aware
of
as
well,
so
I
believe
we
have
a
max.
I
forget
if
it's
five
or
seven
total
policies,
I
think
it's
five.
You
can
only
have
five
policies
of
each
type,
so
you
can
actually
end
up
having
more
because
of
that
snowball
effect,
but
the
additional
ones
will
get
ignored.
A
A
C
And
one
last
question,
and
I
I
promise
I
don't
want
to
take
over
this
call
and
keep
asking
questions.
I
won't
get
to
taylor
and
fences
another
chance,
but
with
regards
to
the
policies
themselves,
a
very
common
question
that
comes
up
is,
if
I
have
a
custom
scanner
that
I've
integrated
do
the
policies
work
with
that
and
I
haven't
kind
of
played
around
with
it
to
know
whether
it's
yes
or
no
do
you
know
the
answer.
A
Yeah,
so
it
depends
is
the
answer:
if
they're
feeding
in
their
vulnerabilities
the
way
they
should,
it
will
just
get
bucketed
under
sas
das
container
scanning
or
one
of
those
others,
and
so
it's
just
going
to
be
treated
the
same
as
one
of
our
scanners.
A
There
are
some
scanners
out
there.
I
believe
that
do
not
so
we
have
an
open
epic
to
add
better
support
for
external
scanners
right
now.
If
you
set
it
to
all,
it
will
catch
those
as
well.
So
you
can
always
just
say,
apply
your
policy
to
all
scanners,
but
we
are
looking
at
adding
an
another
like
external
option
if
they're
using
some
other
name
besides
our
standard
list
that
we'll
just
give
them
a
free
form
text
box
that
they
can
put
something
in
to
match
on.