►
From YouTube: UX Showcase Vulnerability Check Approval Rules
Description
Annabel Dunstone Gray walks through policy creation for more robust approval rules
A
The
specific
rule
that
I'm
going
to
be
talking
about
and
we're
proposing
replacing,
is
this
one
right
here:
the
vulnerability
check
if
you're
a
project
maintainer
you
have
access
to
these
rules,
so
any
project,
maintainer
or
above
can
create
or
edit
these
approval
rules.
If
you
hover
over
the
vulnerability
check,
you'll
see
this
little
pop
over
that
says,
emerge
request.
A
Approval
is
required
when
a
security
report
contains
a
new
vulnerability
of
high
critical
or
unknown
severity,
and
then,
if
you
click
edit
or
enable
you
can
see
all
of
the
role
options,
so
you
can
choose
the
target
branch.
In
this
case,
it's
master.
The
approval
is
required,
and
then
you
can
select
from
this
drop
down
any
user
or
group
that
you
want
to
be
eligible
to
approve.
A
The
limitations
of
this
existing
flow-
there
are
a
few,
so
the
first
one
is
that
there's
no
separation
of
duties
like
I
mentioned
all
project
maintainers,
have
access
to
these
approval
rules,
so
they
could
theoretically
go
in
and
disable
or
edit
them
at
will,
whereas
the
vulnerability
check,
in
particular
that's
kind
of
more
of
a
security
related
check.
The
security
team
wants
to
know
if
a
critical
vulnerability
is
going
to
be
merged
into
the
project.
A
A
And
third,
it's
not
quite
flexible
enough
and,
as
I
mentioned
in
the
pop
over,
the
approval
will
be
launched.
It
will
be
triggered
every
time
any
of
these
vulnerabilities
are
found,
there's
no
option
to
fine
tune
which
vulnerability,
severity
or
type
that
you
want
to
alert
the
security
team.
For
so
here,
I'm
going
to
jump
into
a
demo
that
we've
built
out
for
sort
of
ux
research
purposes
and
to
test
concepts
quickly.
A
This
will
give
you
an
idea
of
how
our
policies
currently
work.
This
is
the
policy
editor
and
something
like
this
already
exists
on
production,
for
network
policies
and
on
staging
for
network
and
scan
execution
policies.
But
in
this
example
we're
going
to
be
adding
a
new
one
called
scan
result
policy.
A
To
give
you
an
idea
of
how
this
works.
We
could
name
it
no
limit
approval
policy,
and
then
you
would
write
your
description,
enable
or
disable
it,
and
then
you've
got
this
pretty
basic.
If
this,
then
that
syntax,
where
you
can
get
super
granular,
if
you
want
to
to
create
your
approval
roles
in
this
case,
you
can
choose
your
scanner,
but
I'm
going
to
select
any
if
any
scan
finds
two
or
more.
A
This
should
be
a
multi-select
to
any
more
critical
vulnerabilities
in
the
main
branch
that
are
let's
say
newly
detected
or
reintroduced
then
ignore
this.
But
then
you
can
require
an
approval
from
two
or
more
individuals
in
this
approval
group
and
to
give
you
a
slightly
better
idea
of
how
this
could
potentially
look.
A
There
are
other
options,
actually
no
forget
that
I'm
going
to
switch
back
to
here,
you'll
notice
that
that
yaml
was
generated
instead
of
creating
a
policy
right
in
the
database.
We're
going
to
be
adding
it
into
a
separate
approval
policy
project
which
naming
could
be
changed.
Let's
call
it
a
policy
project
for
now.
A
To
help
illustrate
that
I
have
this
really
probably
overly
weird
mural,
but
this
is
how
it
could
go
if
you
wanted
to
create
policies
in
this
way.
So
you
could
create
your
security
policy
project
and
then
you'd
add
your
security
team
as
owners
of
that
project,
and
then,
when
you
create
your
policies,
those
are
going
to
get
added
as
merge
requests
into
that
into
this
security
project.
A
And
every
time
that
merge
request
is
created,
it
has
to
be
approved
and
merged
only
by
the
members
of
that
project.
Who
is
the
security
team
and
then
those
policies
will
show
up
in
the
projects
that
you've
linked
to
it.
So
you
get
the
separation
of
duties,
but
then,
since
you're,
using
git,
you
also
get
the
benefits
that
git
provides,
which
includes
a
history.
A
A
So
going
back
to
that
policy
demo,
I
showed
the
specifics
that
you
can
create
for
your
roles,
but
if
you
wanted
to
not
only
require
approval,
one
of
the
great
things
about
this
policy
builder
is
that
you
can
add
additional
actions.
So
maybe
if
a
critical
vulnerability
is
found
in
a
merge
request,
you
also
want
to
send
an
alert
to
gitlab
or
possibly
send
a
slack
notification
to
a
user
or
channel,
and
all
of
these
rules
and
actions
are
additive,
so
they
should
not
conflict
with
each
other.
A
And
then
what
about
the
existing
vulnerability
check
rule
that
I
mentioned
in
the
project
settings?
This
is
still
kind
of.
I
mean
I
only
created
this
a
few
days
ago,
so
it's
still
in
review
and
I'll
probably
change
it,
but
I'm
proposing
a
read-only
view
if
there
are
no
policies
created,
but
otherwise
there
would
be
sorry.
I
forget
that
we
are
going
to
create
a
read-only
view
here
in
the
merge
request
settings
so
that
users
know
what's
going
to
happen.
A
A
You
can
also
click
on
the
scan
result.
Policy
from
here,
I
think
everyone
should
be
able.
Well
all
members
of
this
project
should
be
able
to
look
at
that
policy.
But
if
you
wanted
to
edit
it,
you
would
end
up
creating
a
merge
request
and
then
again
that
would
get
routed
to
the
security
team.
On
that
approval
policy
project,
so
there
would
still
be
plenty
of
checks
to
make
sure
that
the
security
is
always
is
always
the
most
important
piece
of
this.
A
So
what's
next
solution
validation,
we
have
already
conducted
solution.
Validation
for
the
container
network
policies
that
I
mentioned
is
already
live
on
production,
some
of
the
quotes,
while
they're
not
quotes
some
of
the
takeaways
were
that
users
did
find
the
if
this
and
that
mode
really
intuitive.
A
And
if
you
don't
like,
if
this,
then
that
which
some
users
might
prefer
the
yaml
itself,
you
can
go
into
the
yaml
and
update
it.
If
you
already
know,
if
you
already
know
the
format-
and
it
would
still
generate
that
snippet
over
here,
so
we
will
be
needing
to
create
a
similar
study,
asking
participants
to
create
edit
and
find
security,
approval
policies,
and
then
the
policy
builder
is
pretty
flexible
and
it
can
be
used
not
only
for
all
of
these
security
cases,
but
possibly
within
other
groups.
B
A
B
A
It
doesn't
in
this
policy
builder,
I'm
not
sure
about
that
one
yet
because
it
should
technically
the
thing
is
yaml
can
we
can
actually
add
more
things
here
that
exist
in
the
role
mode?
So
maybe
not.
I
think
the
policy
preview
doesn't
work
all
the
time
because
you
can
get
really
specific
with
with
these
ammo
options.
So
that's
a
good
question
and
I
need
to
find
out
my
it'd
be
close.
It
did
I.
I
don't
know
that
we
can
do
that.
A
Yeah
from
what
I
saw
in
the
research
users,
don't
tend
to
flip
between
the
two
they'll:
either
just
go
straight
yaml.
If
they
already
know
what
they're
doing
or
they'll
you
know
fill
it
out
here
and
then
they'll
notice,
the
preview
updating
here
and
if
you
do
fill
it
out
here,
I'm
pretty
sure
it.
I
don't
know
why
there's
a
zero
on
the
end.
C
Yeah
I
was
wondering
if,
if
users
would
be
able
to
see
at
the
project
level
like
if
the
policy
was
set
at
the
group
level
and
a
project
inherited
the
policies,
is
there
any
way
that
they
could
see?
That,
like
that's
where
that's
coming
from?
I
don't
even
know
if
that's
important,
but
have
you
thought
about
that.
A
Yeah,
so
that
separate
project
that
policy
project
right
now,
it's
at
the
project
level,
because
that's
again
the
first
or
the
easiest
way
to
get
this
done
so
stick
to
the
project
level.
We
don't
we're
not
going
to
have
these
policies
at
the
group
level
for
quite
a
while,
but
I
imagine
in
the
future
if
we
do
have
policies
at
the
group
level,
all
of
the
projects
would
inherit
those,
and
you
would
see
the
hopefully
you'd
see
those
approval
policies
right
here
for
other
policies,
I'm
not
sure
we'll
have
to
we
should.
A
C
If,
if
someone's
going
to
want
to
configure
sas
to
run
in
a
particular
way,
chances
are
they're,
gonna
want
to
copy
and
paste
or
you
know,
apply
those
policies
or
not
policies,
those
that
configuration
to
other
projects
which
will
be
easier
when
we
have
it
at
the
group
level.
But
I'm
wondering
if
there's
like
an
mvc
that
both
of
us
could
do
where
you
kind
of
like
copy
and
paste
into
other
groups,
I'm
not
sure
how
like
complex
the
policy
configuration
would
be.
I
know
with
sas.
C
C
A
Yeah-
and
you
mentioned
going
into
each
project
and
manually
doing
these
things,
and
you
still
do
kind
of
have
some
manual
project
by
project
work,
to
link
all
the
projects
that
you
want
to
be
associated
with
that
approval
policy
project.
You
have
to
go
and
link
it
yourself
and
that's
something
that
you
know.
If
we
end
up
doing
this
at
the
group,
or
instance
level,
we
won't
have
to
do
that.
We
can.
Potentially
you
know
if
it's
at
the
group
just
add
all
the
projects
that
you
want
right
then,
and
there
yep.
C
D
Hey
annabelle
a
bit
related
to
becca's
question.
I
know
that
configure
also
uses
this
configuration
project
pattern
for
cluster
management,
so
you
create
a
cluster
management
project
and
you
link
it
to
your
own.
I
wonder
if
we
should
have
some
sort
of
guideline
for
how
to
deal
with
this
because,
as
we
add
more
and
more
features
like
this,
I
wonder
if
our
users
can
get
confused
of
having
multiple
projects
that
are
only
meant
for
configuring
things
in
other
projects.
A
A
That
does
mean
that
we'll
lose
a
lot
of
the
benefits
that
we're
getting
from
this
project.
So
I'm
not
sure
if
it's
it's
a
for
sure
plan,
I
do
think
it
is.
It
is
nice
to
be
discoverable
because
the
flow
is
it
makes
sense,
but
it
is
a
little
weird.
I
mean
you
have
to
manually,
select
that
security
project
and
if
you
don't
have
one,
then
we're
going
to
auto,
create
it
for
you
and
then
you
have
to
go
and
manually
add
that
security
team
to
make
sure
they're
all
the
members.
A
You
know
well
to
make
sure
that
they're
all
added
properly.
That's
that's
another
step
that
you
need
to
take,
so
I
haven't
given
thought
to
how
we
can
improve
that,
but
I'm
hoping
that
we
should
definitely
add
that
actually,
as
part
of
our
solution,
validation
to
make
sure
that
people
can
not
only
create
these
policies
but
that
they
know
where
they're
going
and
how
to
sort
of
separate
the
security
team
with
their
project
and
link
those
properly
to
the
development
team.
D
So
I'm
not
from
configure,
actually
maybe
maybe
justin
can
can
speak
to
that.
I
do
think
using
using
a
repository,
is
has
a
lot
of
benefits
because
you
have
the
git
history
attached.
But
at
the
same
time,
if
this
configuration
was
on
the
group
level,
we
would
feel
a
bit
more
official
and
and
more
centralized
for
our
users.
I
think.
E
Yeah,
we
haven't
had
enough
validation
to
find
out
if
people
how
people
are
accepting
the
project
stuff.
Yet
when
it
comes
to
the
kubernetes
agents
and
whatnot,
unfortunately,
but
I
think
we
we
have
recognized
the
failings
of
sort
of
having
to
force
the
way
our
current
tools.
Architecture
is
set
up,
and
you
know
fitting
into
projects,
as
opposed
to
figuring
out
this
global
groups
concept.
E
D
B
C
E
E
A
A
The
downsides
seem
pretty
extreme,
losing
all
they
get
history
and
then
the
built-in
permission
levels
that
you
can
get
with
the
project.
As
far
as
I
know,
our
main
reason
for
moving
to
the
database
is:
is
it
auditing?
No,
if
you
wanted
to
find,
let's
say
all
the
projects
that
you
have
an
approval
rule
looking
for
a
specific
sas,
critical
vulnerability,
there's
not
really
any
way
to
search
for
those
in
the
projects.
You
would
need
it
to
be
in
the
database.