►
From YouTube: Protect/Compliance PM and UX Sync June 16 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
Great
well,
I
figured
I'd
just
put
something
on
our
calendar,
so
we
had
a
regular
touch
point
since
there's
a
lot
of
overlap
between
our
two
groups-
and
you
know
I
know
we
met
a
couple
months
ago,
but
I
think
it'll
be
good
for
us
to
just
stay
in
sync,
so
that
was
really
the
purpose
of
this
meeting.
If
you
know
we
don't
need
to
have
it
one
month
we
can
always
just
cancel,
but
I
figured
it
would
be
good,
a
good
thing
just
to
keep
on
our
calendars
austin.
B
Okay,
cool.
I
was
just
trying
to
think
back
to
our
last
conversation
and
some
things
related
to
security,
compliance
that
have
come
up
since
then,
so
I
was
trying
to
throw
some
content
into
an
empty
agenda
doc.
So
none
of
these
are
in
a
specific
order,
but
since
one
of
them
stuck
out
to
you,
why
don't
we
start
with
that?
One.
A
A
But
I
know
last
time
we
talked
you
probably
remember
this
this
prototype,
and
this
is
what
will
show
up
under
security
and
compliance
policies
and
what
you're
seeing
right
now
is
actually
at
the
group
level.
So
all
of
our
work
so
far
has
been
at
the
project
level,
but
when
we
do
start
to
implement
group
level
policies
which
is
coming
up
on
our
roadmap,
we're
going
to
want
to
allow
users
to
only
apply
these
policies
based
off
of
their
compliance
framework
labels.
A
So
we're
actually
planning
to
use
that
compliance
feature
here
to
let
users
limit
you
know
which
of
these,
which
of
the
projects
in
the
group
get
the
policy
applied
to
them
so
for
the
first
iteration
we're
only
supporting
gast
and
we're
adding
in
secret
detection,
as
part
of
that
so
for
the
first
iteration
they'll
write
policies
that
look
like
this.
You
know
if
a
pipeline
is
run
for
the
main
branch,
then
you
won't
have
all
of
these
options.
A
But
you
know
das
you'll
be
able
to
require
a
dash
scan
to
run
with
these.
You
know,
site
and
scan
profiles,
and
so
again,
instead
of
having
this
applied
to
all
of
the
projects
you
know
in
the
entire
group,
they
might
want
to
say.
Well,
I
only
care
about
having
this
policy
for
projects
in
the
group
that
have
the
production
label
or
you
know
whatever
other
label
this.
This
would
all
map
back
to
the
compliance
framework
labels
they
had
configured
for
the
group.
A
C
A
C
So
this
one
just
doesn't
have
a
compliance
framework
set
up,
but
so
this
one
I
just
tried
to
model
a
hypothetical
organization
that
has
a
root
group,
several
subgroups,
with
various
projects
with
different
compliance
frameworks.
One
of
the
use
cases
we
talked
through
is
a
compliance
team.
Member
wants
to
make
one
change
to
make
a
single
source
of
truth.
They
need
to
be
able
to
have
a
preview
of
if
I
select
this
policy
or
this
framework,
what
happens?
C
What
gets
applied
across
my
organization
so
like
what
sam
white
was
showing
there
with
certain
scam
policies,
only
apply
to
certain
labels?
What
happens
if
I
select
this
label?
What
policies
am
I
opted
into
because
one
of
the
things
we've
learned
since
we
released
compliance
frameworks
is
that
they
are
generated
at
the
root
group
and
applied
selectively
throughout
the
organization
rather
than
justified
in
one
group,
and
only
used
in
one
group,
this
kind
of
a
visualization
of
that
to
keep
in
mind.
C
A
B
B
B
So
I
think
one
of
our
short-term
visions
for
helping
clarify
what
compliance
frameworks
are
doing
is
even
showing
at
your
project
view
when
you're
going
to
apply.
This
thing
be
aware:
it's
going
to
come
with
this
this
this
and
this
and
this
so
that
you
have
a
little
bit
of
awareness
right
now.
I
think,
because
the
people
that
create
the
frameworks
are
really
the
ones
that
can
apply
them,
there's
going
to
be
some
overlap
of
knowing
that
functionality
inherently,
but
with
that
said,
introducing
it
as
like.
A
A
So,
if
you're,
if
you,
when
you
go
to
apply
this
to
the
project,
you're
able
to
see
which
policies
will
then
take
effect,
I
guess
the
other
area
that
I
wanted
to
sync
up
on
was
you
know
after
we
move
that
to
the
group
level
and
start
using
those
compliance
framework
labels
based
off
of
our
previous
discussion.
I
was
understanding
that,
like
same
for
a
second,
if
you
go
back
to
that
edit
screen
for
the
compliance
framework
yeah,
so
here
where
it
says
compliance
pipeline
configuration
location.
A
As
I
see
it,
our
vision
would
be
to
actually
remove
that
from
here
entirely.
So
you
wouldn't
you,
you
could
still
connect
a
compliance
framework
label
to
a
compliance
pipeline,
but
you
would
no
longer
do
that
on
this
screen.
Instead,
you
would
create
a
security
policy
that
requires
that
pipeline
to
run
when
the
pipeline
is
run.
B
Yeah
I
mean
they're
they're
different.
I
guess
you
could
call
them
personas,
but
they're
different
tasks
to
be
upheld
here
like
one
is
creating
this
unique
framework
attribute
and
then
creating
settings
off
of
it.
I
think
the
initial
vision
for
compliance
frameworks
was
they
would
become
like
this
single
source
of
truth,
that
you
could
create
these
sensible
defaults
enforcements
for
projects.
B
Inevitably,
you're
not
going
to
be
able
to
do
everything
in
this
form,
but
we
can
use
these
frameworks
to
drive
the
power
of
it.
So
yeah
today,
there's
an
input
field
to
specify
where
that
file
lives,
but
perhaps
we
can
create
other
call
to
actions
to
encourage
users
that
if
they
want
to
set
up
these
things
in
other
places,
they
can.
B
A
So
we
talked
about
this
like
two
or
three
months
ago
when
we
met
last,
but
I
don't
expect
you
to
remember
it
so
I'll
show
it
to
you
again
that
would
show
up
here
when
you're
creating
the
policy.
So
you
go
in.
You
create
a
new
security
policy
and
instead
of
requiring
a
scan,
you
would
require
a
ci
script
to
be
run
as
part
of
that
pipeline.
A
So
you
can
either
put
a
linked
file
or
actually
to
make
it
even
easier
on
the
users.
They
could
just
type
in
a
block
of
cie
ammo
to
run
either
way,
but
that
would
accomplish
the
same
net
result,
but
in
this
ui
so
that
way,
there's
you
know
only
one
place
that
they
go
to
set
up.
What
that
compliance
framework
label
does
would
be
in
the
policy
ui,
and
maybe
we
reference
them
over
here.
You
know
from
the
label
creation,
but
that
would
be.
A
B
I
I
the
one
thing
that
would
kind
of
scare
me
about:
it
is
because
of
how
impactful
the
compliance
pipeline
can
be
if
they
don't
pick
a
specific
framework
for
it
to
go
to.
It
could
wreak
havoc
on
that
group.
So
that
would
be
the
the
biggest
thing
that
would
be.
My
concern
is
like,
if
you
weren't,
selecting
which
one
you
need
to
go
to.
Oh.
C
Well,
so
there
is
a
slight
difference
as
my
understanding
on
how
the
policy
pipelines
work
versus
compliance
pipelines.
Today,
the
and
sam
white
correct
me
on
this,
but
what
sam's
showing
right
now
this
will
be
appended
to
an
existing
pipeline
configuration
as
opposed
to
our
current
compliance
pipelines.
Are
you
run
the
compliance
pipeline
full
stop.
A
I
think
we
would
want
it
sam.
I
think
we'd
want
to
keep
yours
running
the
way
it
runs
today,
and
we
probably
would
just
need
to
make
that
more
clear
here
in
the
ui
which
things
are
running
as
separate
processes
and
which
things
are
being
merged
in
because
right
now
we
don't
provide
any
language
to
make
that
clear,
but
I
don't
think
we
would
want
to
change
the
behavior
of
what
you're
doing.
C
A
A
B
It's
going
to
merge
in
the
project's
unique
yaml
file
if
it's
included
into
the
compliance
pipeline.
So
it's
almost
like
it
doesn't
matter
what
is
written
at
the
project
level.
The
compliance
pipeline
is
what's
run.
If
the
compliance
team
chooses
to
allow
you
to
run
your
own
pipeline,
they
can
include
it,
but
it's
almost
as
though
it's
not
it's
not
running
merge
with
it's
going
to
run
only
that
file
unless
it
includes
the
projects
and
sam.
You
could
show
that
example
in
your
compliance
project.
A
C
Yeah
that
makes
sense.
If,
if
that's
the
case,
we
would
need
to
dig
in
a
little
bit
on
how
we
would
want
to
allow
people
to
apply
compliance
framework
labels
in
that
case,
because
you
would
not
be
able
to
apply
multiple,
because
if
a
sox
framework
applied
one
compliance
pipeline
and
a
sams
framework
applied
a
different
one,
we
would
have
no
way
to
merge
those
two
together.
So
that
would
just
be
in
detail.
We
would
need
to
hash
out
for
using
the
existing
compliance
pipeline
functionality.
C
C
A
Yeah,
so
I've
been
sort
of
keeping
an
eye
on
it.
I
mean
my
engineering
team
is
still
doing
everything
at
the
project
level
because
we're
just
trying
to
get
a
lot
of
the
underlying
scaffolding
in
place
to
even
support
security
policies.
So
we
haven't
like
really
dug
into
that
deep.
Yet
from
the
limited
bit
that
we
have
looked
into
it,
it
seems
like
the
the
cascading
settings
framework
that
that's
there
is
not
going
to
work
for
security
policies,
but
if
we
can
leverage
it,
we
will.
C
A
We
do
still
want
to
have
that
same
cascading
effect,
where
you
know
you
should
be
able
to
go
into
the
project
and
see
a
list
of
all
of
the
policies
that
are
applied
to
that
project,
whether
they're
created
at
the
group
level
or
workspace
level
or
at
the
project
level,
and
probably
that's
just
a
column
in
your
list
of
policies
that
says
you
know
this
is
a
group
level
policy
go
edit
it
at
the
group
level
when
it
comes
to
time
to
enforce
the
policies.
The
policies
generally
tend
to
be
additive.
B
A
A
Yeah,
so
all
of
these
policies
boil
down
to
yaml
that
gets
stored
very
much
like
your
compliance
project.
It
gets
stored
in
a
separate
repository,
so
the
customer
can
set
up
their
own
permissions
on
that
to
govern.
Who
can
you
know
who
can
edit
these
and
put
it
all
through
a
two-step
approval
process
if
they
want
to
so
saving?
One
of
these
policies
actually
auto
generates
an
mr
back
into
that
security
policy
project.
A
C
A
A
C
Probably
good
for
this
month
from
the
compliance
group
side
of
the
house,
we're
working
through
some
bugs
and
some
small
refinements
on
compliance
frameworks,
but
nothing
that's
going
to
make
a
major
change
to
how
users
interact
with
them
just
more
refinements
about
what
we
intended
than
release.
Initially,.
A
Sounds
good
and,
on
my
end,
I'll
drop
this
link
in
the
next
document
too,
but
it's
probably
worth
just
sharing.
We
keep
our
priorities
like
a
prioritized
list
of
our
roadmap,
it
as
an
issue-
that's
always
open
in
gitlab,
and
so
just
glancing
through
here
we're
working
right
now
on
allowing
users
to
edit
the
policies
in
the
policy
ui
so
like
right
now,
the
ui
experience
is
pretty
poor,
it's
practically
non-existent,
which
is
why
it's
behind
a
feature
flag.
A
A
Those
should
be
fairly
small
level
of
effort
type
things
and
then,
after
that,
we're
planning
to
move
it
up
to
the
group
level
where
it's
at
the
project
level.
Only
right
now
and
then
down
here,
we
plan
to
add
support
for
compliance
pipeline.
So
I
don't
have
an
epic
created
for
that
yet,
but
just
to
give
you
a
rough
notional
idea
of
like
our
priorities
and
where
some
of
these
things
fall.