►
From YouTube: Protect PM/CS Sync - July 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
All
right
so
welcome
to
our
monthly
sync
for
protect.
I
just
have
a
few
items
to
cover
here
at
the
beginning
around
our
upcoming
roadmap
plans,
just
as
an
fyi,
so
in
protect
we've
been
working
on
security
policies
and
by
the
way,
taylor
since
you're.
The
only
one
here
in
this
meeting.
If
you
have
questions,
feel
free
to
just
dive
in
and
ask
me,
you
know
along
the
way,
so
security
policies
we've
been
working
on,
allowing
users
to
require
certain
scans
to
run
as
part
of
the
pipeline
job.
A
A
But
it'll
be
a
new
tab
in
the
security
compliance
menu
called
policies
and
the
way
it
actually
works
is
there's
a
separate
security
policy
project
that
gets
linked
to
your
what
we
call
the
development
project
and
that's
where
those
security
policies
are
stored.
So
that
way
you
can
have
full
separation
of
duties
for
the
people
who
can
manage
these
security
policies
totally
separate
from
the
users
who
manage
the
actual
project
itself?
C
We're
learning
about
security
policies
and
they're
no
longer
going
to
be
behind
a
feature
flag.
Yes,
that's
great!
I
I'm
I
was
joining
this
too,
as
I'm.
I
think
I've
told
sam
this,
I'm
you
know
going
to
be
doing
this
assessment
with
usaa
and
part
of
that
I'm
going
to
be
going
to
be
showing
this
stuff.
So
this
is
good.
This
is
a
good
timing.
A
C
A
C
It
doesn't
need
to,
I
don't
need
to
be
showing
it
per
se,
this
part
of
it.
I
need
to
be
talking
about
our
roadmap
for
this
part
of
it
got
it,
I'm
going
to
show
the
other
parts
that
are
in
it
so
far
and
say:
here's
where
we're
headed-
and
you
know
I've
already
done
that
with
them
and
they
like
the
direction.
So
this
is
just
more
concrete
for
that.
A
Nice
yeah,
so
I
don't
think
we
quite
have
it
in
there
yet
still
working
on
it
so
yeah
the
road
map
here
is.
We
actually
already
have
a
concept
of
policies
in
the
product.
Today,
it's
under
threat,
monitoring
and
in
the
policies
tab.
Here
you
can
create
psyllium
policies,
selenium
network,
hey.
C
A
Yep,
so
this
is
this
is
where
the
policies
exist
as
of
right
now
in
14
1
we're
going
to
be
moving
it
getting
rid
of
this
tab
and
consolidating
everything
under
a
tab
or
a
page
over
here.
That's
just
policies,
but
we
actually
have
some
semblance
of
policies
today,
where
you
can
manage
network
policies,
so
I'm
going
to
switch
over
to
mocks
so
we'll
have
this
policies.
Tab
will
still
let
you
create
network
policies,
but
will
also
start
letting
you
create
scan,
create
scan
execution
policies.
A
If
I
can
talk
here
and
again,
all
of
those
policies
are
stored
in
a
linked
security
policy
project.
So
if
you
click
edit
security
or
edit
policy
project
here,
you
can
pick
any
other
project
in
the
whole
instance
that
you
have
permission
to
access
and
then
that's
where
the
yaml
for
these
policies
gets
stored.
So
you
can
have
full
separation
of
duties
between
your
security
team
and
the
developers
that
manage
the
project,
so
you
can
actually
separate
out
who's
able
to
edit
and
manage
these
policies
entirely
for
the
first
release.
A
The
only
thing
we're
supporting
is
the
ability
to
require
that
a
das
scan
gets
run
as
part
of
the
pipeline,
but
we're
expanding
that
rather
quickly
afterwards
and
14.
2
we'll
be
adding
support
for
secret
detection
and
then
sas
afterwards
and
we'll
just
keep
adding
things
from
there.
A
So
what
it
looks
like
is,
basically
you
just
get
this
yaml
editor.
If
you
go
to
create
the
policy
where
you
can
go
in
and
edit,
you
know,
create
a
policy
that
says,
there's
a
rule
that
if,
if
a
pipeline
runs
for
the
master
branch,
then
as
an
action,
I
want
to
require
das
to
run
with
this
site
profile
and
the
scan
profile.
A
When
you
create
this
policy,
it
actually
makes
the
site
and
scan
profiles
uneditable.
So
they're
read
only
as
long
as
these
profiles
are
in
use
by
the
policy.
So
that
way,
the
developers
can't
change
this
configuration
and
it's
guaranteed
to
run
that
way,
all
the
time,
every
time
we're
actually
injecting
this
job
into
the
pipeline
with
a
separate
process.
A
So
all
of
this
happens
totally
independently
of
everything
else
in
the
gitlab
ci.yaml
file.
So
it
doesn't
matter
what
variables
they've
put
in
there:
what
pre-processing
processing
jobs
or
post-processing
jobs.
Basically,
this
injects
a
job
into
the
pipeline,
100
guaranteed
every
single
time
that
it
requires
stats
to
run.
C
Yeah,
so
in
the
real
scenario,
the
policy
should
be
the
same,
but
certain
things
like
what
branches
it
runs
on
certain
projects
are
are
going
to
be
different
for
different
teams.
Right
and
so
is
there
a
notion
of
being
able
to
say
you
know
I
need
to.
I
need
to
have
this
happen
at
a
different
stage,
or
I
need
to
happen
a
different
branch
or
like
some
of
the
things
that
are
not
related
to
the
scan
happening,
but
when
it
happens
and
where
it
happens,
maybe
on
an
individual
project
basis
right.
C
A
C
C
That's
good
yeah.
I
definitely
know
that
they're
gonna
want
organization-wide
or
group-wide
policies
you
know
is,
is
gonna,
be
the
first
task
there,
but
you
know,
I
think
this
this
solves
the
the
general.
Is
there
a
way
to
reference
a
like?
I
can,
I
can
say
I
have.
I
have
a
policy
set
up
here,
but
instead
of
in
this
policy,
having
all
the
details
be
part
of
this,
can
I
can
I
reference
a
upstream
project
that
you
know
similar
to
how
we
would
do
for
like
the
the
new
kubernetes
cluster.
C
You
know
main
project
that
does
the
infrastructure,
spinning
that
up
like
referencing
now,
and
you
showed
it
if
you
go
back
to
two
tabs.
I
think
this
part
here
uh-huh.
So
this
is
where
I'm
a
little
confused.
So
this
this
is
referencing
a
project
that
the
policies
are
coming
from,
though,
so
that's
not
part
of
the
project
itself.
A
Yeah,
so
you've
got
your
what
I'll
call
your
development
project
and
then
you've
got
a
security
policy
project,
and
so
this
yaml
that
you're
looking
at
here,
gets
stored
in
the
security
policy
project
that
way:
okay,
okay,
okay,
yeah!
I
get
it
now
we're
good,
so
your
security
team
can
be
maintainers
on
the
security
policy
project
and
your
development
team
has
no
way
to
edit
those
policies.
A
Yep,
so
just
a
note
as
well
overall
on
our
direction
here
we
have
kind
of
this
big
matrix
of
things
that
we
want
to
do
so.
We've
got
all
of
the
different
scanners:
we've
got
different
types
of
scans,
we've
got
project
group
and
workspace
level,
there's
a
lot
of
stuff
in
here,
so
you
know
we're
just
hitting
the
tip
of
the
iceberg
with
this
initial
mvc,
but
eventually
we
want
to
expand
this
out.
To
be
inclusive
of
you
know,
all
types
of
policies
that
you
might
want
to
have.
A
A
That
one
also
is
we're
tackling
in
a
very
iterative
way,
our
very
first
iteration
of
that
is
going
to
turn
on
in
14
1
we're
releasing
it
in
what
we're
calling
an
alpha
state,
it'll,
probably
be
14
2
or
14
3,
before
it's
a
little
bit
more
polished,
but
with
that
you'll
actually
be
able
to
use
those
same
scan
policies
to
schedule
a
scan
against
a
running
kubernetes
cluster,
and
it
will
go
out.
It'll.
Look
at
all
of
the
containers
that
are
running
in
that
cluster.
C
A
Yeah
great
question:
let
me
wrap
up
just
showing
you
some
running
container
stuff
and
then
I'll
come
back
to
that,
if
that's
okay,
yeah,
so
to
be
able
to
scan
containers
running
in
production
again,
what
that's
going
to
look
like
at
the
end
of
the
day
is
basically
just
another
tab
on
that
vulnerability
report.
A
A
It's
running
a
bit
slow
today,
so
we're
still
working
out
the
terminology
for
this.
I
think
we've
actually
decided
on
development,
vulnerabilities
and
operational
vulnerabilities,
but
the
development
vulnerabilities
will
be
things
that
exist
in
gitlab,
they're,
typically
scanned
as
part
of
your
pipeline.
The
operational
vulnerabilities
will
be
things
essentially
in
production.
A
C
A
So
no,
they
may
not
be
the
same
for
a
customer.
That's
using
ci,
cd
and
deploying
into
production
all
the
time
then
yeah
they
will
pretty
much
be
the
same.
A
Some
customers
have
images
out
there,
containers
that
are
running
and
have
been
running
for
months
or
even
an
embarrassing
number
of
years,
and
they
haven't
been
updated,
and
so
eventually
there
starts
to
be
a
difference
between.
What's
you
know
in
get
lab
and
what's
actually
running
in
production,
another
reason
for
having
them
separated
is
just
difference
in
persona.
A
C
A
So
it
actually
gets
executed
in
the
cluster
itself.
Prerequisite
is
installing
starboard
into
the
cluster
once
it's
installed
there
and
running
though
we
I
think
we
are
using
a
pipeline
is
where
we
landed,
but
we're
just
fetching
the
results
so
we're
not
executing
the
scan
in
the
pipeline.
We're
just
fetching
the
results
from
from
kubernetes,
so
it's
actually
running
in
kubernetes
itself.
A
A
So
it
would
allow
you
to
select
a
kubernetes
cluster
that
you've
connected
to
gitlab
to
do
the
scanning.
So
if
you
go
to
infrastructure
and
kubernetes
clusters,
you've
connected
it
via
the
certificate
method
or
with
the
kubernetes
agent,
those
would
be
the
options
of
clusters
that
you
can
go
out
and
scan.
C
And
so
this
is,
this
is
going
to
be
scoped
to
people
using
kubernetes
versus
using
containers
in,
however
else
they
want
to
be
using
containers
at
runtime
docker,
whatever
else
right
like
if
you're
asking
for
just
generic
like
open
shift,
support
or
something
yeah.
A
A
Correct
this
is
scoped
to
just
kubernetes,
doesn't
mean
it'll,
always
stay
that
way,
we
might
add
support
for
more
orchestrators
in
the
future,
but
at
least
for
now
kubernetes
only
since
it's
in.
B
C,
will
it
use
the
same
architecture
to
load
up
the
vulnerability,
json
file,
meaning
kind
of
going
back
to
brian's
question?
If,
if
a
customer
has
an
open
shift
thing
that's
scanning,
if
they
can
emit
a
json
that
we
can
pull
in,
then
would
that
also
work?
Is
that
part
of
this
architecture
or
not?
I
think.
A
That
would
work.
You
would
have
to
kind
of
rewrite
a
large
chunk
of
our
code
to
support
something
like
that.
B
A
Yeah
yeah.
Okay,
sorry,
I
misunderstood
yes,
that
that
should
work
equally
well.
In
fact,
our
first
iteration
of
this
you're
actually
fetching
the
vulnerabilities
just
by
including
a
job
in
your
pipeline,
and
it
does.
It
just
creates
a
json
file,
just
like
all
of
the
other
scanners.
So
the
answer
would
be
yes
for
that.
One.
C
A
You
would
at
least
again
for
the
first
iteration
we're.
Actually
it
makes
less
sense
to
do
these
scans
as
part
of
a
pipeline
and
more
sense
to
do
it
on
a
scheduled
basis.
Yeah,
so
we'll
eventually
just
be
handling
these
as
a
scheduled
scan
or
a
scheduled
pipeline
job.
Essentially,
but
yes,
exactly
put
it
in
your
cicd
file,
then
it
would
show
up
as
a
job
there.
A
Right
this
is
the
long-term
prototype
that
we've
got
for
this
whole
policy
editor
thing,
and
this
will
tie
back
into
your
question
in
a
minute
about
the
compliance
frameworks,
but
just
to
show
where
we're
headed.
You
know
our
mvc
is
the
yaml
mode.
Only
so
you
know
you
can
come
in
here
and
say
if
a
pipeline
is
run
for
the
main
branch
I
want
to
require
das
to
run.
A
So
you
could
scan
the
production
cluster
and
you
pick
your
namespaces
in
that
cluster,
and
you
know
the
frequency
that
you
want
to
fetch
the
vulnerabilities
from
that
cluster.
So
you'd
actually
have
a
container
scanning
scan
in
this
scenario,
so
you
would
have
set
it
up
with
yaml.
Something
like
this
is
the
way
that
we're
headed.
A
B
Yeah
one
quick
question
in
the
other
discussion
that
we
just
had
with
regards
to
the
real
time
scanning
or
runtime
scanning.
B
A
So
that's
outside
of
the
scope
of
protect
it's
actually
the
vulnerability.
It's
the
threat,
insights
group,
insecure
that
owns
that
so
matt
wilson.
I
don't
know
of
any
immediate
plans
to
change
that
doesn't
mean
he
doesn't,
but
I'm
not
aware
of
any
right
now.
Okay,
no
problem!
Thank
you!
A
A
What
we're
doing
here
has
in
a
sense,
some
overlap
with
what
that
group
is
doing
in
another
sense,
it's
very
different
and
complementary,
and
it
comes
down
to
the
way
that
we're
actually
enforcing
these
things
to
be
run
so
with
the
compliance
framework
pipeline.
What
they're
doing
is
they're
merging
any
of
that
all
of
that
yaml
into
the
gitlab
ci.yaml
file
and
then
running
that
and
executing
that,
so
there
are
pros
and
cons
to
doing
that.
A
One
of
the
upsides
is
that
you
know
there's
a
huge
amount
of
flexibility.
Almost
anything
you
want
to
enforce
out
of
the
gate
you
can
enforce,
whereas
with
the
approach
we're
going,
we
have
to
kind
of
add
support
for
one
thing
at
a
time.
You
know
one
scanner
at
a
time
one.
You
know
it's
it's
much
slower
of
a
process.
A
Another
upside
of
their
approach
is
that
you
actually
would
have
access
to
environmental
variables
that
are
set
in
the
original
gitlab
ci.yaml
file.
So
there's
some
ability
to
like
read
things
and
respond
and
react
and
change
your
logic,
depending
on
the
scenario
that
you're
in,
whereas
the
approach
we're
going
with
is
very
independent
of
the
gitlab
ci.yaml
file
and
that
we
are
forcefully
injecting
a
job
to
be
run
and
we're
ignoring
everything
else
in
the
gitlab
ci.ml
file.
A
So
if
you
know,
customers
did
some
fancy
scripting
with
the
pre,
pre
or
post
jobs,
or
you
know,
set
things
like
dashed
innate
or
disabled
to
true
or
you
know,
if
they
try
to
just
it's
really
easy
to
start
impacting
other
jobs
when
you
have
kind
of
full
access
to
the
gitlab
ci.yaml
file,
and
so
having
that
sense
of
isolation,
just
provides
a
little
bit
of
a
stronger
guarantee
that
it's
actually
required
to
run.
A
Also
with
this
approach,
where
we're
headed
is
a
very
easy
to
use
ui,
I
know
the
the
compliance
framework
pipelines
require
quite
a
lot
of
different
steps
to
set
up
and
link
everything
together.
A
A
If
you
want
to
send
an
alert,
a
slack
notification,
an
email
call
out
to
an
external
web
hook,
there's
a
plethora
of
other
actions
that
we
can
take
here
and
so
in
the
future.
We
want
to
actually
bring
what
they
have
into
this
workflow,
where
you'll
create
a
scan
policy
or
a
security
policy
to
require
a
ci
file
to
be
merged
in
to
the
rest
of
the
pipeline
and
run
so
again
we're
planning
to
take
what
they've
built
and
just
bring
the
user
experience
together.
A
That
help
at
least
a
little
bit
to
clarify
the
those
two
guys
thanks
so
yeah
at
least
short
term.
You
know
we're
kind
of
going
off
a
little
bit
separately,
but
we'll
bring
those
together
again
right
now
we
only
have
this
at
the
project
level.
They
only
have
a
group
level,
but
at
some
point
we're
going
to
move
this
to
the
group
level
and
those
will
start
to
converge
at
that
point
as
well,
then
we're
almost
out
of
time.
We've
spent
the
whole
time
talking
about
roadmap.
A
I
guess
the
last
thing
I
just
wanted
to
highlight
here
is
that
we
got
a
dedicated
headcount
from
the
board
a
while
ago
that
we
just
barely
filled
the
position
for
to
focus
exclusively
on
security
approvals
and
improving
that
experience
so
long
term.
The
plan
is
actually
to
bring
vulnerability
check
out.
I
guess
I've
closed
that
tab
prematurely
out
from
where
it
exists
today
and
instead
allow
users
to
create
scan
results
policies.