►
From YouTube: Monthly Protect/Compliance PM/UX Sync - October 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).
B
Yeah
sure
do-
and
I
was
working
on
pulling
out
my
figma
page
as
well
as
I
don't
have
gdk
running
right
now.
So
the
first
question
I
had
was
around
the
configuration
page
that
is
under
security
and
compliance,
so
I
saw
that
that
had
kind
of
released
earlier
this
summer.
B
A
That's
a
good
question.
I
think
it's
becca
that's
been
driving
that
most
out
of
everyone.
I
have
not
heard
any
feedback
on
that
page
at
all
myself,
not
that
I've
been,
I
haven't,
been
asking
for
it
either.
So
maybe
that's
part
of
why,
but
it
also
hasn't
come
up
on
any
customer
calls
or
anything.
A
B
That's
okay.
I
mean,
as
what
kind
of
happens
with
the
fact
that
we
have
the
name
compliance
in
our
groups.
Title
I
mean
it
can
sometimes
be
confusing.
What
is
a
group
compliance
feature
and
what
is
maybe
more
of
a
compliance
feature
to
users
more
broadly
so
licensed
compliance
is
a
great
example
where
you
don't
own
that
feature,
but
it
has
the
word
compliance
in
it.
So
inherently
it
feels
like
it
should
be
tied
to
compliance.
B
I
can
do
a
quick,
just
walk
through
what
I
initially
was
thinking
as
like
an
iteration
from
where
we're
at
today.
B
So
the
first
half
focuses
on
security
and
testing,
and
perhaps
this
compliance
tab
could
focus
on
the
compliant
management
aspect
aspect
for
these
given
projects,
so
you
can
understand
if
your
license
compliance
is
enabled,
but
are
you
also
taking
advantage
of
the
other
compliance
features
that
we
outline
in
our
docs?
Like?
Are
you
using
compliance
frameworks?
Do
you
have
pipeline
compliance
configured?
B
Are
you
running
any
external
status
checks,
ssh
key
restrictions
like
I
mean
this
list
could
be
quite
long,
but
maybe
we
could
start
with
some
of
our
most
valuable
compliance
features
as
a
way
to
encourage
users
to
use
them
if
they
aren't
already
using
them
by
creating
a
single
space
where
they
can
kind
of
see
that
in
aggregate,
but
I'm
still
not
entirely
clear
on
what
the
intent
was
for
the
security
testing
aspect
of
it.
So
maybe
that's
where
I
can
tag
up
with
and
becca
better
understand
how
that's
going.
A
Yeah,
that
sounds
good.
I
know
what
they've
got
in
there
kind
of
varies
I've
personally,
I've
always
been.
That
is
really
the
place
to
store
any
settings
like
as
opposed
to
a
policy,
but
if
you
had
a
project
bubble
setting
for
something
you
know,
that's
where
I
would
be
inclined
to
put
it,
but
yeah
becca's
becca's.
Definitely
the
best
one
to
talk
to
you
for
this
page.
B
Yeah,
that
makes
sense-
and
I
think,
right
now,
a
lot
of
compliances
features
are
kind
of
just
interspersed
throughout
settings,
so
there
are
some.
I
think
we
could
definitely
pull
in.
If
we
wanted
to
like
a
compliance
framework
is
something
that
we
could
definitely
lift
and
shift
out
of
settings
and
put
into
configuration.
B
B
That's
good
yeah.
Thanks
for
your
thoughts
on
that
sam
courage,
you
want
to
add
any
other
questions
or
thoughts
around
that.
C
Yeah,
I
I
think
my
main
feedback
and
what
I
liked
in
your
mock-ups
they're
austin,
was.
It
really
would
help
us
tell
a
better
story
about
what
is
complying
to
gitlab
by
putting
all
of
those
things
together
whenever
we
have
to
walk
users
or
customers
through
well,
you
go
to
this
settings
tab
to
change
this,
then
you
go
to
that
one.
The
story
really
gets
mingled
and
it
almost
makes
it
feel
like
it's
a
it's
an
afterthought
when
it's
definitely
not
an
afterthought.
C
So
I
think
if
there
is
an
opportunity
for
us
to
bring
a
lot
of
our
compliance
pieces
together,
it
would
really
help
us
talk
to
that
compliance
persona.
This
is
the
screen
you
live
in
primarily,
and
that
makes
it
very
easy
for
them
to
understand.
Oh,
I
need
to
buy
a
premium
or
ultimate
to
get
this
experience.
C
What
do
you
mean
like
configuration
page
from
showing
or
in
the
settings
page.
B
C
Oh,
I
see,
I
guess
my
point
was
more
of
like
when
imagine
you're
a
person
evaluating
purchasing,
git
lab
and
the
person
runs
through
the
demo
and
they
have
to
click
through
six
screens.
You're
gonna
get
cognitive
overload,
you're
gonna
get
distracted
by
oh
well.
What's
that
other
thing
you
don't
mean
to
talk
to
me
about
and
you
might
miss
the
central
value
point
we
try
and
make
with
the
compliance
story.
B
Yeah,
that
makes
sense.
I
also
think,
even
for
people
that
are
using
ultimate
or
premium,
it
would
help
them
understand
if
they're
actually
utilizing
the
features
at
their
disposal,
because
some
of
it
is.
It
is
like
an
extension
of
a
feature
that
you
have
to
know
about
to
know
that
you're
using
it
so
exactly.
C
Cool,
actually,
that
would
help
us
increase
adoption
and
other
features
and
other
stages,
because
well
I'm
not
using
compliance
controls
on
this
other
part
of
git
lab,
but
I
am
using
this
one.
Let
me
go
explore
the
one
I'm
not!
That
might
help
with
some
discoverability
an
interesting
thought.
B
The
next
thing
I
wanted
to
highlight
this
came
up
in
a
recent
merge
request
where
we
were
finally
appending
something
to
the
word:
compliance
in
the
navigation
because
for
a
while,
it
just
said
the
word
compliance,
but
once
you
open
it
up,
it
said
compliance
dashboard
to
be
a
better
representation
of
what
it
is,
we're
going
to
call
it
the
compliance
report,
but
tech
writing,
guided
us
and
saying
it
should
be
just
a
uncapitalized
report.
B
B
B
Yeah
and
all
of
that
I
can
go
sleep
and
find
the
comment
too.
If
you
want
me
to
type
writing
it.
B
B
So
an
example
like
where
it
should
not
be
capitalized
like
kubernetes
clusters
is
not
supposed
to
be
capitalized,
whereas,
like
I
think,
security
dashboard
is
supposed
to
be
capitalized,
I
think
it
all
has
to
do
just
like
grammatically
what's
correct,
but
I
do
agree.
It
just
kind
of
feels
a
little
odd
to
see
a
mixture
of
both
well
grammar.
C
A
C
A
Okay,
yeah,
I
mean
I
can
share
that
back
with
the
team,
but
it
seems
like
this
is
a
broader
navigation
problem
that
we
need
to
rely
on.
I
agree
with
sam
curry,
though
we
should
not
just
change
one.
Like
one
item:
that's
gonna
make
it
stand
out
like
a
sore
thumb.
There
we've
gotta
at
least
stay
consistent
within
the
same
menu.
B
Yeah,
I
will
most
definitely
find
the
thread
that
we
had
around
it.
It
was
between
ian
and
evan
reed,
and
then
I
can
link
that
for
you
once
I
find
it
because
I
haven't
found
it
just
yet.
A
Yeah,
thanks
for
sharing
that
out
I'll
pass
that
on
to
everyone
too
yeah.
So
my
agenda
item
here
was
mostly
just
an
fyi.
I
know
we've
been
talking
about
this
for
a
long
time,
but
we're
actually
getting
close
to
starting
work
on
it.
We
haven't
started
work
yet,
but
we
did
put
this
epic
through
planning
breakdown,
which
means
it's
in
refinement
and
the
next
step
after
that
will
be
that
it's
we
start
working
actually
implementing
it.
So
right
now,
all
of
our
security
policies
are
at
the
group
level.
A
We
did
default
that
feature
flag
to
on
in
14-3,
so
you
probably
saw
that
show
up
here.
This
new
policies,
tab
or
policies.
Page
looks
like
this.
One
has
mostly
network
policies,
but
you
can
also
create
scan
execution.
Policies
in
here
looks
something
like
this
right
now.
It's
all
yaml,
we
don't
have
the
rule
mode
yet
so
it
still
is
a
little
bit.
A
You
know
the
user.
Experience
is
still
under
development,
but
it's
there
and
it
works.
So
the
next
step
is
going
to
be
to
move
all
of
this
up
to
the
group
level
as
well
and
have
those
flow
down
to
the
project
level.
So
yeah
take
a
look
at
that
epic.
Let
me
know
if
you
have
any
thoughts
or
feedback
once
we
finish
that
body
of
work,
the
next
step
for
us
is
going
to
be
to
filter
which
projects
in
the
group
are
affected
by
a
project
compliance
label.
A
So
I
know
I've
kind
of
shared
this
rough
idea
out
with
you
before,
but
at
a
super
high
level,
and
this
isn't
like
ux
designs,
but
when
you
go
to
create
a
policy,
this
is
the
rules
mode
that
we
don't
have
yet
you'll
be
able
to
say.
I
wanted
this
to
apply
to
all
projects
where
I
only
want
to
apply
it
to
projects
that
have
specific
compliance
framework
labels.
So
this
would
be
a
point
of
integration
between
our
two
groups
and
we
haven't
we're
not
starting
work
on
that
design
issue.
A
I
don't
know
what
your
bandwidth
is
in
the
upcoming
milestones,
but
if
you
have
some
bandwidth
to
co-collaborate
on
that,
I'm
assuming
you
might
want
to
show
some
of
this
information
back
on
the
group
settings
page
where
you
set
up
the
compliance
framework
label
or
maybe
somewhere
else
to
show
which
policies
are
tied
to
which
labels
in
some
way.
A
A
A
That
does
we
are
trying
to
help
with
potential
confusion
in
the
way
we're
going
about
our
mocks
for
the
group
level
policy
management.
So
we
are
planning
on
creating
this
new
source
column.
On
that
policy
page
and
saying
you
know,
the
policy
applies.
A
So
hopefully
that'll
help
at
least
a
little
bit
with
the
confusion,
but
I
can
see
where
yeah
that
definitely
could
get
a
little
bit
confusing
here
again
as
well
like
when
you
create
a
new
policy.
We're
gonna
provide
this
information
icon
up
top
and
once
we
have
that
filter
for
the
compliance
framework.
Labels
down
here
I'll
have
to
play
with
this
a
little
bit.
But
we
could
probably
just
do
some
smart
inline
messaging
to
make
it
really
clear
exactly
which
projects
are
going
to
be
affected
by
the
policy.
C
A
I
want
you
know
to
apply
this
policy
if
it
has
this
label,
so
that
would
be
solved
at
least
eventually
for
the
short
term.
You
would
probably
do
it
at
the
root.
Well,
we
don't
really
expose
the
group
very
well
either,
but
you
could
do
it
in
any
of
your
top
level
groups
and
it
would
flow
down
right.
C
Yeah,
I
think,
that's
probably
going
to
be
one
of
the
bigger
like
ux
designs,
have
questions
on
how
we
want
to
approach.
This
might
be
a
follow-on
couple
of
iterations,
but
I
think
that's
the
feedback
we'll
get
from
a
lot
of
the
customers,
because
what
a
lot
of
them
are
doing
with
the
compliance
frameworks
today
is
using
it
to
govern
multiple
different
groups
potentially
and
the
framework
is
defined
at
the
root
group.
But
each
of
those
individual
subgroups
would
inherit
that
from
there.
A
Yeah
that
makes
sense
just
to
show
one
more
mock.
This
would
be
like
on
a
project
level,
so
you
would
be
able
to
see
if
you
go
into
any
given
project,
you're
going
to
be
able
to
see
those
all
those
policies
that
flow
down.
So
if
this
was
in
you
know
your
project
or
I
guess
sorry,
this
is
a
group
anyway,
you
can
see
which
ones
flow
down.
So
this
one
is
inherited
from
a
parent
group.
A
These
ones
are
inherited
from
the
workspace
and
they
would
actually
be
read
only
in
this
location
because
to
edit
them
you
would
need
to
go
to
the
respective
object
to
edit
it
so
that
you're
editing
it
in
the
correct
place,
but
yeah,
I
can
definitely
see
just
some
very
mindful.
Ux
is
going
to
be
needed
there
to
make
sure
that
it's
really
clear
what
you're
doing
right
and
where
those
policies
are
being
applied.
C
A
So
so
far,
we
have
don't
have
a
need
for
policy
reduction.
All
of
the
policies
that
we
have
today
are
purely
additive.
So
if
one
policy
requires
a
scan
to
run
and
another
policy
requires
a
scan
to
run,
you
can
just
run
both
scans
there's.
No,
it's
not
really
a
strong
need
to
try
to
deconflict
things
like
if
you're,
both
requiring
a
fast
scan
to
run
with
slightly
different
parameters.
A
You
can
just
run
it
twice
once
with
parameter
set
a
once
with
parameter,
set
b,
all
right
eventually,
you
know
if
we
do
run
into
that,
which
we
probably
will
at
some
point
the
policy
that
we're
planning
on
pursuing.
There
is
one
where
the
first
of
all
the
most
restrictive
action
will
always
take
precedence.
A
So
a
policy
with
a
block
action
or
a
deny
action
will
take
precedence
over
anything
with
an
allow
action
and
the
secondary
rule
to
that.
If
there's
a
conflict,
that's
not
resolved
with
the
level
of
restrictiveness,
then
the
more
specific
policy
will
take
precedence.
So
a
group
level
policy
would
take
precedence
over
a
workspace
level
policy
and
a
project
level
policy
would
take
precedence
over
a
group
one
and
that
allows
users
to
define
like
a
broad
organization
policy
set
and
then
create
project
level
exceptions
as
needed.
B
Do
you
anticipate
the
inverse
happening
like
organizations
saying
we
want
to
set
the
broad
level
policy
and
not
let
these
projects
define
their
own
set.
A
So
the
way
we're
structuring
this,
it
would
be
the
same
individuals
responsible
for
all
of
that.
So
it's
you
know
we're
following
a
principle
of
separation
of
duties
here,
so
that
it's
not
like
there's
another
group
that
can
go
and
set
a
project
bubble
override.
It
would
be
that
same
group
of
individuals
that
would
be
responsible
for
the
project
policies,
as
is
responsible
for
the
workspace
policies.
So
if
they
don't
want
to
override
it,
they
just
don't
override
it.
It's
not
like
they
need
to
prevent
someone
else
from
doing
that.
A
A
Anyway,
you
know
so
whether
it's
the
security
team
or
the
compliance
team,
that's
managing
policy.
A
That's
managed,
often
it's
similar
to
the
way
you're
doing
compliance
pipelines
and
that
it's
managed
in
a
separate
project.
So
those
individuals
can
set
their
own
access
controls,
their
own
merge,
request,
approval
workflows,
and
so
it's
not
like
there's,
like
I
said,
there's
not
another
team
managing
project
bubble
policy
that
they
need
to
keep
from
overwriting
the
workspace
policy.
It's
the
same
group
doing
both
got
it.
B
C
That'll
help
reduce
a
lot
of
the
complexity.
That
was
one
of
the
things
we
ran
into
with
compliance
pipelines
is
how
do
we,
let
customers
define
multiple
definitions
and
then
disambiguate,
and
we
ultimately
just
said
you
can't
you
get
one
and
you
have
to
disambiguate
yourself.
C
A
So
in
that
way,
we're
able
to
just
run
multiple
jobs
for
everything
that
we
need
and
we
take
precedence
over
anything
in
the
gitlab
ci.yaml
file,
but
other
than
that
there
aren't
really
conflicts.
We
don't
conflict
with
our
own
other
policies.
We
just
use.
You
know
another
big,
long,
random
string
of
numbers
essentially
to
create
a
separate
job
for
each
thing
that
has
to
run.
A
Cool
all
right.
C
A
We
are
going
to
be
adding
support
for
sas
next
that
we're
gonna
start
working
on
it.
This
milestone
it
will
we're
not
committed
to
delivering
it
in
14.5,
so
it'll
probably
be
delivered
in
14
6,
and
we're
actually
doing
that
before
we
move
things
to
the
group
level,
so
that'll
happen
first
and
then
we're
going
to
take
a
pause
on
adding
new
scanner
types
and
instead
move
it
to
the
group
level.
C
A
Yeah,
absolutely
it
doesn't
have
full
like
customization
by
default,
we're
just
going
to
run
sas
with
the
same
settings
that
are
used
for
the
default,
auto
devops
template,
so
they
won't
have
the
ability
to
customize
any
of
their
sas
variables
other
than
maybe
one.
I
can't
remember
which
one
I
think
we're
letting
them
customize
one.
A
So
it
does
have
some
limitations
to
it
like
if
you're,
using
a
language
that
we
require
the
compiled
binary
to
scan,
which
isn't
a
lot
of
languages.
But
there
are
some
that
we
require
that.
Then
you
can't
really
use
this.
You
know
there
are
some
like
caveats
like
that.
That
will
have
to
add
configuration
settings
more
in
the
future,
but
we
should
be
able
to
cover
at
least
the
majority
of
sas
use
cases
with
that
iteration.
A
C
I
think
we're
at
time,
so
it
was
great
great
job
with
y'all
yeah.
I.
B
Did
I
did
find
a
tech
writing
comment
as
well,
which
I
highlighted
in
docs
awesome
in
case
you're
curious?
It's
because
it's
not
a
proper
noun.
Okay.