►
From YouTube: Govern:Security Policies group discussion 2022-10-11
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
Welcome
to
our
group
meeting
for
the
security
policies
group,
it's
been
a
while
since
we've
had
this,
but
Alexander
you've
got
a
few
things
to
demo
for
us.
B
Yeah
I,
it's
it's
things,
everybody
knew
was
coming,
but
I
just
wanted
to
reiterate
the
feature.
Flags
for
the
scam
execution,
rule
mode
on
both
project
level
and
group
level
has
been
defaulted
on,
as
well
as
the
operational
vulnerability
cluster
and
agent
filters
on
the
project
level.
Have
that
feature
like
has
also
been
defaulted
on,
so
I'm,
not
gonna,
not
gonna
demo.
It
because
I've
demoed
it
before,
but
those
are
definitely
making
it
into
15.5
so
that
very
exciting.
A
Awesome
yeah:
that's
great
news:
that's
really
going
to
make
it
a
lot
more
usable
for
everybody
for
that
feature,
so
great
work
on
that
and
then
the
only
other
thing
I
think
that
we've
got
in
our
agenda
today
is
talking
about
role-based
approval
actions
for
scan
result
policies.
A
So
we've
put
this
through
design.
I
think
we're
ready
to
do
planning
breakdown.
I
can
just
change
my
screen
real
quick!
This
is
actually
priority
four
here,
but,
as
you
mentioned
Alexander,
where
we
just
finished
this
one
out,
so
this
will
be
rolling
off
the
list.
Priority
three
will
be
coming
off
priority.
One
we'll
likely
be
wrapped
up
here
soon.
The
mirror
is
finishing
that
one
up,
so
that
would
quickly
be
making
this
priority
too,
and
we've
got
a
few
different
phases.
A
But
the
net
result
of
this
would
be
impacting
the
action
section
for
scan
result
policies
where
right
now
you
can
just
add
individuals
and
groups.
We'd
be
splitting
it
up
so
that
you
can
add
either
users
groups
or
by
role,
and
so,
if
you
pick
roll
you'd
be
able
to
pick
owner
maintainer
developer
reporter
guest
I
assume.
Ideally
this
would
be
multi-select
so
that
you
could
pick
more
than
one
I.
Guess:
that's
not
really
here
in
the
designs,
but
that
would
be
the
ideal
state.
A
And
then
you
could,
you
know,
join
additional
things
together.
If
you
wanted
to
also
add
in
some
other
users
or
groups
or
or
other
things
into
this
list,.
A
Even
if
we
don't
do
actually
looking
at
these
designs
again
now,
it
looks
like
the
design
wasn't
for
this
to
be
multi-select.
We
just
pick
one
and
then
you
add
another
condition.
We
could
do
that
as
well
as
long
as
the
end
state
is
that
the
user
is
able
to
pick,
you
know
different
roles
as
eligible
approvers.
That
would
be
accomplishing
the
purpose
of
the
Epic
from
a
product
standpoint.
C
Yeah
I
can
add
explanation
because
we
are
updating
the
drop
down.
They
are
removing
the
check
mark
of
the
multi-selection,
which
I
feel
like
it's
a
confusing
that
if
user
open
the
drop
down
there
is
a
lot
no
check
box
in
between
for
multi
or
single
selection,
it's
confused
user
and
it's
more
clear.
We
just
do
it
this
way
and
user
know,
for
example,
is
or
permission
and
also
like
they
know
it.
C
Yeah,
because
it's
well,
we
have
a
design
to
update
it
with
the
checkbox
in
between
so
when
user
open
it,
they
will
directly
know
it's
multi-selection,
because
the
little
square
in
front
of
it,
but
that
design
has
been
reverted,
go
back
to
this
one
which
is
before
updating,
so
I
was
really
hoping
the
little
box
was
could
be
there.
The
plan
was
really
like
this
quarter,
the
update
to
the
square,
but
somehow
it
yeah
the
design
changes
again,
and
there
are
more
research
coming
up.
C
So
in
some
designs
that
I
feel
like
if
we
can
make
them
more
clear.
The
single
selection
is
like
a
single
selection
and
then
let
user
like
use
the
add
button
to
add
more
single
selection.
If
they
want
it
and
with
the
rows,
I
don't
expect
in
the
normal
cases
they
will
select
all
of
them
so
like
adding
the
average
shouldn't,
be
a
big
problem,
but
in
the
research
you
will
see
that
in
normally
like,
if
people
want
to
select
other
rows,
they
can
like
to
the
multi-selection
right.
C
A
And
then
yeah,
so
are
there
any
other
questions
on
this?
Are
we
ready
to
move
this
into
refinement?
I,
don't
have
the
notes
document
up
at
the
same
time,
but.
B
What
Sam
or
Satya
you
mentioned
that
from
the
back
end
perspective,
starting
with
phase
three
directly
would
be
easier.
Can
you
elaborate
on
that.
D
Yeah,
so
what
I
initially
said
or
thought
was
to
have
a
new
type
called,
maybe
role
approvers
instead
of
having
the
IDS
of
the
users
belonging
to
a
role.
So
that
way
we
introduce
a
new
type.
D
So
from
the
backend
policy,
ammo
would
have
a
new
type.
It
could
be
no
something
like
role
approvers
to
the
required
approval
action
type
and
that
contains
the
roles
list
of
roles
specific
to
that
particular
action.
B
Got
it
that
makes
me
think
of
another
another
question:
what
in
the
designs
there
were
roles
like
owner
or
maintainer
and
stuff
like
that,
what
Sam
will
you
want
this
designed
to
be
implemented
both
at
the
project
level
and
group
level?
Is
that
correct,
yep.
B
Got
it
so
at
the
group
level
are
there
there
are
owners
right
and
maintainers
at
the
group
level
are
the
main:
can
you
be
a
maintainer
of
a
project
but
not
a
maintainer
of
a
group
so
so,
which
one
would
we
show
no.
A
So
these
these
policies
don't
actually
apply
to
the
group.
You
create
them
at
the
group
level,
but
then
they
flow
down
to
the
projects
in
the
group.
So
they
you
know
all
of
the
policies
both
scan
execution
and
scan
results.
They
actually
get
applied
and
implemented
down
at
the
project
level.
So
when
you're
creating
a
group
level
policy,
it's
not
a
policy
for
that
group.
A
B
Got
it
so
then,
the
in
the
design
there
were
numbers
like
next
to
the
groups
like
maintainers
six
people.
Those
numbers
wouldn't
show
up
for
the
group
level,
then
or
correct.
A
B
Got
it
cool?
Thank
you.
Another
question,
I
thought
of
I'm.
Sorry
I
was
looking
at
this
right
before
the
meeting,
so
I
have
time
to
write
it
all
down,
which
is
bad
practice.
I'm.
Sorry
that
wasn't
more
async
but
Sashi.
Do
you
see
any
performance
implications
in
collecting
all
the
members
from
every
project
or
collecting
all
the
members
from
every
group?
If
we
were
to
implement
this
at
the
group
level,.
D
Not
sure
from
the
top
of
my
mind
but
I
think
getting
the
count
would
be,
could
be
a
good
first
step
rather
than
getting
all
the
users,
but
there
might
be
some
performance
overheads
on
top
of
it.
Getting
on
a
project
level
would
be
straightforward,
but
for
a
group
it
might
be
different.
Yeah
we'll
have
to
maybe
factor
in
as
well.
B
B
Thank
you,
yeah.
Those
are
all
the
questions
I
had
about
the
project
right
now,
but
I'm
I'll
be
looking
at
more.
A
Sounds
good
I
think
the
consensus
is
to
leave
it
as
one
Epic
for
now,
so,
at
least
on
the
back
end,
it
sounds
like
they'll
be
going
straight
to
phase
three
I
think
if
you
wanted
to
split
it
out
into
smaller
phases,
you
could
do
that.
Alexander
would
be
up
to
you,
but
you
know
if
you
want
to
create
sub
epics
or
multiple
issues
or
just
go
to
phase
three.