►
From YouTube: Secure UX: security approval rules recommendations
Description
Reviewing epics with ux/usability improvement recommendations at the project and group level
0:00 - 2:57 context and current ux demo
2:57 - 20:18 epic issues overview (project level)
20:18 - 22:08 epic issues overview (group level)
epics:
https://gitlab.com/groups/gitlab-org/-/epics/2319
https://gitlab.com/groups/gitlab-org/-/epics/3202
A
A
It's
separated
in
two
different
areas
and
what
so
accountability
is
for
the
user
that
is
responsible
for
setting
up
the
security
gate
or
a
license
check
and
then
responsible
is
for
the
developer,
who
has
to
comply
with
it
or
maybe
an
ax
murderer
quest
and
has
to
in
a
merge
request
where
the
vulnerability
check
is
as
it
is
being
applied
because
certain
criteria
has
been
been
found
and
just
a
quick
background
is
vulnerability.
Check
will
disallow
a
merge
request
when
critical,
high
or
unknown
vulnerabilities
have
been
detected
even
if
they've
been
dismissed
and
license.
A
B
So
now,
I
added
and
it
looks
like
a
normal
rules,
but
its
approval
rules
there
currently
no
indication
to
tell
you
that
this
is
special
and
I
can
edit
it.
But
you
can
see
that
I
cannot
like
I
didn't
name
anymore,
and
you
can
only
like
at
approvers
and
change
its
enable/disable
if
I
change
it
to
0,
that
is
disabled
and
just
button
become
a
little
bit
gray,
but
you
can
still
click
on
it
and
change
it
back
to
1.
So
there
are
a
lot
of
like
issues
around
this
set
up
processes.
B
A
Now
the
good
thing
is
is
once
this
issue
is
taken.
Care
of
this
will
help
us
out
with
the
next
following
recommend,
recommend
at
issues
form
five
and
four,
for
this
is
showing
the
approval
groups
here
in
the
configuration
page-
and
this
is
important,
because
a
prerequisite
for
vulnerability
check,
for
example,
to
to
be
on
or
to
be
able
to
be
turned
on
is.
A
Some
of
the
scanners
need
to
be
turned
on
at
least
one
of
them,
for
example,
assassins
to
be
turned
on
for
the
vulnerability
check
two
to
really
matter
because
so
having
it
all
on
the
same
page
helps
with
that
prerequisite,
and
even
not
for
the
person
accountable
for
the
settings.
It's
helpful
for
developers
just
to
see
how
projects
are
set
up
in
terms
of
security
and
again
just
bring
in
visibility
that
the
feature
exists
and
it's
available
to
users
is
another
important
aspect
that
it
it
is
on
this
page
with
some
of
our
other
features.
A
Is
it
not
active,
but
this
one
was
scheduled
for
thirteen
one,
but
actually
the
recommendation
is
that
we,
we
do
there's
a
UX
debt
issue
to
do
to
take
care
of
vulnerability,
check
and
license
check,
plus
it
makes
it
easier
for
development.
For
these
other
two
follow-up
issues
is
it's
just
dropping
it
into
these
other
pages?
A
So
in
in
this
design,
we
actually
see
like
we're,
given
them
some
status
on
the
configuration
page
that
these
scans
aren't
updated
and
then
here
the
status
here
is
a
scanner
is
not
enabled,
and
we
have
this
banner
hair.
That's
clarifying
a
vulnerability
check
requires
one
or
more
scanners
to
be
enabled,
so
we're
helping
guide
the
user
to
actually
know
what
the
prerequisite
and
what's
required
for
this
check
to
be
turned
on.
A
B
And
before
I
go
to
next,
one
I
just
want
to
one
thing:
that
the
reason
that
why
we
want
to
do
the
general
settings
first
and
then
move
it
to
a
configuration
and
the
license
check.
Is
we
don't
want
to
create
this
inconsistency
that
if
you
make
it
better,
the
lesson
check
our
own
security
session
and
then
is
not
reflect
the
same
thing
either
go
to
the
general
setting
and
change
it.
B
So
we
need
to
make
them
work
the
same,
so
user
recognize
they're
the
same
thing
and
there
are
not
different
experiences
and
for
the
one
number
six
is
too
light
user
notice.
This
after
we
get
like
is
in
the
base
that,
in
the
configuration
is
ready
in
the
general
session,
is
already
in
the
lessons
is
ready.
We
can
tell
you
there
that
hey,
there
is
a
cool
feature.
Do
you
want
to
go,
enable
it
so
there's
just
like
pouring
the
visibility's
and
next
one?
B
So
the
number
seven
is
really
like
to
separate
from
general
rules,
so
for
those
user
like
bomb
to
always
go
to
the
settings,
to
change
thing
to
have
an
overview
to
give
them
a
better
sense.
That's
the
security,
our
difference
like
we
want
to
separate
them
from
this
general
rules.
Now
they're
like
in
one
lease
the
UX
check
like
if
you
have
a
developer
check
or
something
like
that,
they
are
together
with
this
lessons.
B
Check
and
vulnerability
check
is
not
very
easy,
so
we
want
to
separate
them
into
two
small
sessions
and
there
are
the
approval
rules.
So
it's
more
visible
for
you,
they're,
not
hey.
Those
two
are
different
things,
and
this
is
all
the
preparation
for
the
next
one,
because
they're
over
writing
rules.
That's
over
right.
This
general
thing-
and
this
is
the
make
it
easier
to
enable
and
disable-
and
this
can
be
done
at
all
the
places
where
the
habits
the
base
ready.
So
it's
just
a
taco
pattern
to
tend
to
turn
it
on
and
off.
B
Now
you
need
go
to
edit
and
change
the
approval
required
number
to
zero
in
this
disabled.
It's
not
very
easy
to
you
for
user
to
understand
the
thing
and
when
they
have
the
toggle
button,
we
can
also
do
it
in
our
security
configuration
page
to
the
lessons
check
page.
So
this
is
also
like
one
feature
to
make
it
easier
for
user.
Everyone.
B
So
the
next
one
is
the
like
to
make
it
user
understand
like
how
much
is
required
and
then
like
how
much
is
like
zeros.
So
when
we
have
a
toggle
button,
we
should
also
like
here.
When
you
know
change
to
zero
is
immediately
disable.
Let
are
like
we
can
have
a
rule.
That's
like
you
can
have
not
have
zero
like
what
do
you
mean
by
their
own
that
if
I
have
two
people
required
and
then
like
they're,
a
pro
I
only
have
one
people
and
then
like
this
master,
doesn't
work.
B
It's
need
to
be.
The
approval
number
need
to
be
bigger
than
the
number
of
required
approvals,
and
this
need
to
work
with
the
privacy
issue
with
the
toggle
button.
So
there
are
two
things
we
need
to
fix.
It
I
think
this
isn't
not
really
like
you.
Axing
is
more
like
a
back,
because
current
is
leave.
You
work
edge
is
working
a
buggy
way.
That's
either,
don't
understand
it.
B
The
impression
that's
each
time
you
check
on
something
for
all
the
rules
above,
as
has
been
done
so
the
another
thing
we
need
to
do
is
like
move
security
session
below
this
approval
rules
and
do
a
technical
check
like
all
those
overriding
rules
won't
apply
to
our
security
lose.
So
it
will
act
exactly
the
same
as
like
our
own
configuration
session
and
the
license
check
session
to
make
the
separation
easier,
and
this
is
another
small
improvement.
That's
another
like
the
placeholder
one
cow
was
mentioning.
A
B
So
if
we
click
on
the
problem
first,
they
can
see
that's
like
their
the
session
like
a
required
approval
from
vulnerability
check.
It
says
it's
already
approved,
but
you
can
still
not
murder
it
and
then
user
don't
understand
hey.
Why
can
still
not
murder
it
says
is
approved,
but
actually
there
are
like
two
security
checked
into
a
provisions
like
other
things,
so
the
solution
is
that
we
really
just
separated
like
in
two
different,
approves
and
like
expanded,
to
also
make
the
message
more
clear.
A
B
So
if
I
click
bigger
on
the
problem
photo,
so
this
is
like
a
little
bit
more
complex
situation
like
the
private
situation
is
when
there
is
MRIs
only
blocked
by
security
check,
and
now
the
MRI
is
blocked
by
two
things:
I
won
at
the
security
check.
Another
one
is
this:
merge
request
conflicts,
so
user
need
to
solve
two
things
and
we're
not
item
like
merge
button
disabled
button
next
to
it,
but
only
tell
them
one
thing:
so
there
might
be
like
two
personas
of
the
user.
B
One
is
sewing
conflicts,
another
one
is
sewing
security
and
for
the
security
guy
that
come
years
at
everything's,
good
I
don't
need
to
do
anything,
but
actually
they
need.
But
then
we
don't
tell
them
so.
The
solution,
if
we
go
back
to
the
solution
screen,
is
to
clearly
tell
people
are
two
things
you
need
to
do
so
you
need
to
solve
the
merge,
merge,
request,
conflict
and
another
thing
you
need
to
like
check
the
security
approvals
and
different
people
are
different.
Responsibility
can
come
there
and
do
their
own
thing
and
the
next
one
well.
B
So
this
one
is
really
a
bag
is
like
on
my
settings.
I
have
three
approvals
and
when
I
created
I'm
are
only
where
show
up
and
there's
just
why
it
doesn't
make
sense,
and
you
user
cannot
edit
it
changes
or
anything
we
just
need
to
move
this
session,
like
the
solution
is
very
simple,
like
user
need
to
see
all
the
security
check
when
the
kratom
are,
if
they
are
credit.
A
A
I'll
come
back
to
it
this.
This
is
just
really
quick.
This
one
is
just
as
changes
are
made
when
there's
a
security
when
you're
in
a
merge
request,
for
example,
vulnerability
check
it
just
shows
in
the
approval
area
like
chameleon,
was
pointing
out,
there's
no
other
indications
that
a
problem
has
been
made
or
anything
we've
seen
in
user
tests.
It's
easy
to
overlook
that
approval
section,
so,
hence
the
earlier
recommendations.
A
This
is
an
issue
Lucas
made
a
while
ago,
after
the
implementation
of
just
bringing
the
system
notes
here
to
the
merge
request,
similar
how
we
have
in
the
issue
of
when
these,
when
these
things
happen
and
because
there
are
some
changes.
For
example,
you
know
the
critical
vulnerability
that
was
there
could
be
removed
and
then
the
approval
required
could
also
be
removed.
B
Yeah,
the
three
here
was
talking
about
the
problem.
That's
there
is
only
one
approve
button
that
approve
everything
so
like
I
need
to
approve
them
differently
because,
like
UX
might
be
good,
but
Security's,
no
good,
not
because
I'm
eligible
for
all
of
them,
if
I
prove
them
approve
all
of
them
together.
So
this
is
also
kind
of
back
like
why
they
need
to
be
approved.
B
B
Me,
if
not
I
can
leave
a
message
to
let
the
people
who
who
response
for
it
to
check
it,
and
this
is
also
improvement
for
the
private
solution.
Private
solutions
still
have
all
the
approvals
together
with
different
buttons,
but
this
one
has
really
moved
them
into
different
sections.
For
example,
like
the
vulnerability
check
is
based
on
ability.
Lessons
check
is
miss
lessons,
and
so
we
may
get
some
really
just
likes
to
the
session,
where
user
need
to
check
the
results.
B
A
Something
to
consider
here
is
for
larger
customers
adopting
this
surfacing
it
and
at
a
higher
level.
Maybe
the
group
or
instance
it's
that
the
first
step
here
is
allowing
users
to
see
what
projects
are
configured
with
vulnerability
check.
Otherwise,
they'd
have
to
go
project
to
project
to
know
where
they
even
put
the
vulnerability
check.
So
again
in
the
similar
vein
is
showing
in
the
user
interface.
It
could
be
a
good
'we
also
to
promote
it,
and
so
you
consider
a
group
dashboard.
A
It's
just
understanding
how
our
my
projects
set
up
for
security
across
multiple
projects,
then
maybe
a
second
step
could
be
applying
the
rule
to
multiple
projects
from
the
group
level
or
instant
and
then
customizing
the
rule.
This
is
also
something
that
could
be
done
at
the
project
level
and
customizing
means
like
a
sort
of
conditional
rule.
So
the
vulnerability
check
is
a
hard
fast
rule
for
high
critical
and
unknown.
But
what
if
I
only
want
to
disallow
merge
request
if
critical.
A
Vulnerabilities
were
found,
and
that
would
be
the
only
rule
or
different
variations
of
that,
and
so
that's
what
this
is
looking
at
so
given
where
we're
at
now,
it
would
probably
be
really
helpful
to
have
feedback
on
you
know.
What's
the
general
approach
that
we
want
to
do,
do
we
want
to
invest
in
the
project
we
want
to
invest
in
the
group.