►
From YouTube: Protect PM/CS Sync - February 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
Judging
by
the
lack
of
comments
in
the
agenda,
I'm
guessing
no,
but
just
wanted
to
make
sure
everyone's
aware
of
that,
even
though
we're
deprecating
and
removing
it
I'll
just
add
a
little
additional
note
here
verbally,
is
that
customers
can
still
manage
their
production
rules
through
gitlab
and
really
one
of
the
best
benefits
of
all
of
those
features
was
the
ability
to
store
your
code,
your
policies
as
code
in
gitlab,
and
get
the
benefits
of
a
source
code
repository.
So
you
had
full
version
history.
A
You
could
do
two-step
approvals
and
that
sort
of
a
thing
that
still
will
be
possible
using
gitlab.
We
just
won't
support
a
native
integration
like
an
out
of
the
box
integration
with
any
of
these
vendors,
but
if
a
customer
or
user
wants
to
add
their
own
home
charts
into
their
copy
of
the
cluster
management
project
template,
they
can
actually
deploy
those
home
charts
in
production
with
the
new
kubernetes
agent,
secure,
ci
cd
pipeline,
and
so
you
know
they
would
have
to
kind
of
instrument
those
steps
themselves.
A
But
it
still
is
entirely
possible
to
do
on
top
of
gitlab
to
manage
your
network
policies
and
your
other
things
inside
of
gitlab
as
code
and
have
those
pushed
into
production
automatically
all
right.
So
then,
the
big
one
we've
got
coming
out
in
14
8
is
we're:
releasing
security
approval
policies
and,
at
the
same
time,
we're
deprecating
vulnerability
check
so
yeah.
I
expect
this
is
a
rather
large
deprecation
and
a
rather
large
new
feature.
A
I
know
we
talked
a
lot
through
a
lot
of
this
async,
so
you
know
taylor
unless
you
want
to
verbalize
any
of
those,
I'm
happy
to
just
kind
of
skip
down
to
the
updates.
I
have.
B
A
So
I
do
want
to
just
provide
a
couple
of
updates.
There
are
two
modes
for
editing:
the
new
security
approval
policies,
there's
the
rule
mode
and
the
yaml
mode.
The
yaml
mode
is
available
for
14.8
the
rule
mode.
Just
barely
is
I
mean
there
still
is
a
slim
chance
that
makes
it
in
14
8,
but
as
of
right
now,
it's
looking
like
it's
going
to
just
barely
miss
it.
A
So
if
you
have
got
a
customer
who's
on
gitlab
sas,
then
they're
gonna
see
it
here
really
soon,
because
it's
gonna
be
in
production
almost
any
day,
but
it's
probably
gonna
miss
the
build
cut
off.
So
if
they're
self-managed
customer
and
they
want
to
use
the
rule
mode,
it
will
have
to
be
14.9
for
them.
A
So
that's
unfortunate,
but
I
don't
think
that's
going
to
be
a
huge
deal
again
if
they're
comfortable
with
yaml,
they
can
start
using
it
in
14.8
and
if
not,
hopefully,
that's
not
a
big
deal
for
them
to
wait.
One
extra
release.
C
Question
about
that
same
if
they
did
go
with
the
yama
route
and
then
later
on
in
149,
let's
say
it
does
get
released
to
be
in
the
the
other
way.
Are
they
compatible
with
each
other
or
is
there
a
migration
that
needs
to
happen
at
that
point
again,.
A
Great
question:
no,
no
migration
is
needed.
It's
the
difference
between
rule
mode
and
ammo
mode
is
purely
all
on
the
front.
End
ui.
It
actually
all
translates
down
to
yaml
and
gets
stored
as
yaml
in
this
linked
security
policy
project.
So,
no
matter
what
you
do,
it
ends
up
being
yamal.
The
rule
mode
is
just
a
convenience
for
users
who
don't
want
to
learn
our
yaml
syntax,
just
to
create
a
policy
yep
so
they're,
exactly
it's
just
purely
a
front
end
construct
there.
A
In
fact,
it
might
be
worth
just
showing
real,
quick,
the
mock
that
we're
working
towards
for
this.
A
The
way
this
works
is
you'll
actually
get
this
well.
That's
really
zoomed
in
you'll
get
this
yaml
preview
on
the
side
and
then,
as
you
fill
out,
the
rule
in
the
rule
mode
it'll
live
update
this
yaml
preview,
so
you
can
switch
between
rule
mode
and
yaml
mode.
A
It's
really
fluid
to
go
between
them
and
that
way
you
know
you
can
edit
it
in
yaml.
If
that's
your
preference
or
you
can
edit
it
here,
and
you
can
see
that
yaml
live
generate
as
you
work
on
the
right
hand,
side
when
we
actually
researched
this
feature,
we
found
that
there
were
super
strong
opinions
about
this.
It
was
really
polarizing,
it
was
like
android
and
iphone,
or
mac
and
windows.
A
Like
everybody
had
a
super
strong
opinion
about
either
I
only
work
in
yaml
and
don't
give
me
this
rule
mode
garbage
or
I
don't
want
to
touch
yaml,
that's
for
developers.
I
only
want
to
work
in
like
a
nice
ui,
so
it
was
really
polarizing.
Everybody
had
a
super
strong
opinion
and
it
was
like
one
way
or
the
other.
So
that's
why
we're
providing
both
ways
of
editing
the
policy.
A
The
other
update
I
have
is
just
around
migration.
Since
I
last
posted
this
last
week,
we've
been
able
to
work
out
our
migration
plan
a
little
bit
more.
We
are
actually
going
to
be
able
to
migrate
100
of
the
vulnerability
check
rules,
and
this
will
run
with
15-0
with
the
upgrade
to
15.0.
A
A
You
know
it
just
depends
on
when
that
gets
merged
in
and
when
it
gets
run,
but
as
part
of
that,
the
one
it
is
a
breaking
change
and
the
reason
for
that
is
just
the
permissions
on
it
are
going
to
be
different
because,
instead
of
allowing
all
maintainers
and
higher
on
the
development
project
to
edit
these
policies,
now
the
yaml
is
stored
in
a
separate
security
policies
project.
So
I
did
actually
want
to
get
some
feedback
from
the
two
of
you
here
today.
I
have
an
open
question
of
when
we
run
this
migration.
A
So
when
we
run
the
migration
we're
going
to
automatically
create
it
with
a
migration
bot,
we're
going
to
automatically
link
it
to
the
development
project,
we're
going
to
automatically
merge
in
those
new
new
policies,
but
who
should
we
put
by
default
in
that
migration
scenario
as
maintainers
on
the
security
policy
project?.
A
Would
be
the
question,
should
we
put
just
the
development
group
owner?
Should
we
put
maintainer
in
higher
we're
trying
to
figure
that
piece
out.
C
My
recommendation
would
be
to
put
maintainer
and
higher
just
the
same
as
what
is
today
and
notify
the
people
that
that
has
happened,
because
that's
that's
probably
going
to
cause
a
riot.
B
Yeah,
I
think
that
if,
if
they
have
the
access
to
create
a
policy
in
the
first
place,
then
they
should
have
access
to
the
policy
projects,
that's
created,
but
some
sort
of
notification.
So
when
I've
been
like
messing
around
with
it
and
I've
created
policies
and
projects
that
don't
have
policies
yet
and
it
creates
the
new
security
policy
project,
I
didn't
realize
that
was
happening
in
the
workflow.
It
like
took
me
a
minute
to
read
and
see
that
the
project
had
changed.
A
A
That's
good
to
know.
Eventually,
we
would
like
to
actually
hide
away
that
linked
security
policy
project
entirely,
so
that
customers
don't
have
to
worry
about
where
those
things
are
being
stored,
but
that's
pretty
far
out
on
our
roadmap,
so
yeah
that's
good
feedback,
but
we
might
need
more
notification.
B
Yeah,
I
kind
of
expected
at
least
like
a
badge
or
something
to
be
applied
to
my
project
when
I
implemented
that
but
yeah,
it
was
just
not
as
clear.
C
A
So
you
can
actually
go
through
and
create
your
own
project
somewhere
else,
and
it
does
not
have
to
be
in
the
same
group.
So
you
can
actually
link
a
development
project
to
any
other
project
that
you
have
access
to
anywhere
in
gitlab.
A
A
All
right,
well,
that's
great
feedback,
any
other
thoughts
or
comments
on
that
change
or
on
security
policies
in
general,.
C
I'm
I'm
curious
if
a
new
project
like
that
is
created
automatically
by
us,
is
it
gonna
impact
people's
or
or
the
customers
size,
the
the
size
limit,
question
that
comes
up
and
I'm
curious
if
that's
gonna
affect
them
or
if
they,
you
know
what
I'm
talking
about.
Like
you
know,
when
I
have
a
repository
in
in
sas,
I
have
a
certain
amount
of
size
limit
to
it
and
I
think
we're
putting
some
new
restrictions
around
it
recently
going
to
happen
soon.
So
will
this
affect
that
or
not
that's
just
a
question.
A
A
All
right
any
other
topics
to
discuss
today,
any
other
hot
issues,
focus
areas;
feedback
that
you've
gotten
from
customers
related
to
protect
that
I
can
help
you
with.
B
I
think,
at
least
for
the
recording,
since
we
mentioned
it
in
slack
it's
worth
noting.
That
was
it
that
additional
analyzers
aren't
being
added
into
the
action
types
until
group
level
policies
are
implemented.
A
Yep,
we
are
it's
a
trade-off.
We
do
have
to
add
support
for
each
of
those
individually
and
so
we've
gotten
a
lot
of
feedback
and
requests
for
having
it
at
the
group
level.
A
So
we
kind
of
did
sas
and
secret
detection
and
dash
and
container
scanning
and
now
shifting
focus
to
the
group
level,
but
we
will
come
back
and
add
in
the
other
analyzers
we
do
plan
to
support
all
of
them
and
actually
eventually,
we
plan
to
merge
all
of
this
together
with
compliance
pipelines
so
that
you've
got
one
solution
for
enforcing
things
that
run
instead
of
two,
so
lots
on
our
roadmap.
But
we
can
only
do
one
thing
at
a
time.
A
We
are
planning
to
move
container
scanning
down
to
the
free
tier
similar
to
what
would
with
similar
to
what
was
done
with
sas.
So
you
know
users
can
run
it.
They
can
get
the
json
artifact
that
they
can
manually
download
and
view,
but
that's
pretty
much
more
or
less
it.
They
won't
be
able
to
view.
You
know
really
anything
else
in
the
ui
right:
we're
not
giving
them
access
to
the
security,
dashboard
or
vulnerability
list
or
merge
requests.
You
know
security,
approval
policies
or
anything
like
that.
A
Are
there
any
concerns
from
either
of
you
with
that
happening?
It's
actually
on
my
to-do
list,
probably
soon,
sometime
this
month
to
message
it
out
more
broadly
to
sales.
B
A
No,
no
simply
because
what
is
out
there
already
in
the
open
source
community
is
really
good,
but
we
are
planning
to
augment
our
so
container
scanning
is
really
a
basic
thing.
It's
not
like
some
of
the
other
analyzers
that
do
more
complex
stuff.
It's
a
very
basic
string
comparison,
so
it
pulls
a
list
of
all
of
the
operating
system
packages
that
are
installed
on
the
container
and
then
it
has
a
vulnerability
database
and
it
does
a
comparison
between
the
two
so
the
logic
to
grab
that
list
of
packages.
A
On
the
container
I
mean
it's
really
pretty
straightforward,
you're,
basically
running
like
if
it's
debbie
and
you're
running,
like
an
app
list
installed
command
you're
just
looking
technically,
I
think
they
actually
open
up
the
folder
for
the
package
manager
and
grab
a
list
of
all
of
the
packages.
But
it
really
is,
you
know,
there's
nothing
special
there,
there's
no
secret
sauce,
nothing
special
in
any
of
that.
A
Really
what
the
value-add
comes
down
to
is
how
good
is
your
vulnerability
database
and
so
we're
planning
to
continue
to
take
everything
that
is
in
the
trivia,
vulnerability
database
and
the
derived
vulnerability
database,
but
also
to
merge
in
our
gymnasium
database
content.
So
that's
on
our
backlog
and
we
actually
have
two
versions.
If
you've
been
following
that
project,
the
naming
is
a
little
bit
weird,
but
we
have
gymnasium
db,
which
is
proprietary,
and
then
we
have
a
new
advisories
community
database
which
is
available
for
anyone
to
use.
A
But
it's
a
one
month
time
delay
from
gymnasium
db,
so
we're
planning
to
incorporate
both
of
those
but
the
advisories
community
one
will
be
in
free
and
the
gymnasium
db
updates
will
be
in
the
paid
version.
So
that
way,
you
know
the
underlying
scanner
will
be
the
same.
We're
not
going
to
go
build
our
own
proprietary
scanner
because
again,
like
it's
really
basic
technology,
there's
no
secret
sauce
there,
but
we
will
be
able
to
differentiate
those
between
free
and
ultimate
based
off
of
the
quality
of
the
vulnerabilities
and
the
timeliness
of
detecting
them.
A
All
right,
I
think,
that's
everything
I
have
for
today
and
let's
either
of
you,
two
have
more
thanks
for
joining
today
and
feel
free
to
reach
out
and
sync
up
in
the
slack
channel
as
needed.
C
A
Yep
great
question,
so
we
still
have
two
other
categories
we
have
container
scanning
and
we
have
security.
Orchestration
security
orchestration
includes
all
the
security
policy
stuff
that
we've
been
doing
the
security
approvals,
the
we're
actually
temporarily
removing
the
alert
dashboard,
but
we
plan
to
bring
that
back
in
the
near
future.
So
all
of
that
security,
orchestration
stuff,
we're
in
the
process
of
figuring
out
like
exactly
how
we
think
about
protect
from,
like
a
charter
perspective.
A
What's
our
goal
for
charter,
we
do
still
want
to
participate
in
production
security
to
the
extent
that
there's
overlap
with
the
apsec
team
and
that's
really
what
this
deprecation
is
about.
We're
going
after
the
infrasec
team-
and
we
just
you
know
now-
is
not
the
time
for
us
to
go
after
the
infrasec
user
they're,
not
already.
A
It's
a
pretty
tough
sell
to
bring
them
into
gitlab
with
our
current
feature
set,
and
we
really
would
need
not
only
a
big
investment
there,
but
probably
also
some
pricing
and
packaging
changes
to
accommodate
the
way
that
that
market
works.
So
that's
why
we're
moving
away
from
container
network
and
host
security?
What
we're
not
moving
away
from
is
like
running
container
scans
in
production,
and
that
piece
you
know
that's
an
area
of
overlap.
A
Infrasec
cares
about
that,
but
so
does
the
appsec
team,
because
ultimately
it's
the
developers
that
have
to
go
fix
those
problems,
whereas
if
you're
just
dealing
with
network
firewall
rules,
that's
not
necessarily
on
the
developers
to
fix
so
we're
just
trying
to
recenter
ourselves
on
problems
that
ultimately
have
to
make
their
way
back
to
developers
to
fix
and
address
so
they're
again
we're
still
figuring
out
the
details
of
that
charter,
but
part
of
that
is
still
a
delineation
between
you
know:
production
security
concerns
versus
non-production
and
security.
A
Orchestration
is
a
shared
category
it's
in
protect
at
the
moment,
but
it
could
just
as
easily
be
insecure
or
perhaps
even
manage
for
that
matter,
because
it's
not
really
a
you
know,
there's
nothing
unique
about
that.
That
puts
it
necessarily
in
protect
so
again
we're
still
trying
to
figure
that
out.
That's
a
question.
We
don't
have
fully
answered
ourselves
yet.
C
Okay,
no
problem:
I
was
just
just
curious
because
it
looked
like
you,
you,
you
had
quite
a
bit
that
you're
giving
up
there,
and
so
I
wasn't
sure
what
what
what
protect
is
going
to
mean
in
the
future.
But
but
thank
you
for
clarifying.
I
think
that
that
makes
a
lot
of
sense.
The
direction
the
new
direction
science
seems
pretty
good.
A
Yeah
and
part
of
that
deprecation
is
just
freeing
up
resources
to
double
down
and
focus
even
more
on
container
scanning
and
security
orchestration.
So
every
time
you
know,
if
we're
doing
one
thing,
then
we're
not
doing
something
else.
Because
of
that-
and
you
know
no
matter
how
you
you
carve
it
up
like
you,
you're,
never
going
to
get
more
done
by
doing
more
things
and
so
you've
got
to
you
know
this
really
is
just
a
matter
of
refocusing
our
efforts
and
allowing
us
to
move
a
little
bit
faster
on
those
two
remaining
two
categories.