►
From YouTube: UX Group Feedback: Security Gates
Description
Kyle Mann shares designs for Security Gates. Issue: https://gitlab.com/gitlab-org/gitlab-ee/issues/10391
A
A
Currently,
we
do
have
a
feature
which
is
the
merge
request
approvals
seen
in
the
merge
request,
widget,
but
the
is
to
not
give
the
level
of
specificity.
These
security,
analyst
or
security
team
would
want
unblocked
in
a
merge
request
with
with
selected
severity
in
and
selected
in
severity
level
of
vulnerabilities.
That
cannot
be
allowed
to
proceed
for
a
merge
request
and
then
also
selecting
a
specific
security
approver.
A
So
it's
a
little
bit
different
than
the
approvers
that
we
see
now
in
the
approvals
feature,
the
screen
we're
looking
at
now,
just
for
context
is
in
our
settings.
I
would
show
you
settings,
but
my
GDK.
Unfortunately,
it's
not
working,
but
this
is
where
DD
settings
are
set
for
merge
requests
and
you
can
add
members
to
approve,
merge,
requests
and
in
a
project
level,
and
then
these
are
sort
of
different
options
and
conditional
rules
that
you
can
apply
thereafter.
A
Just
open
up
so
one
workflow
that
we
have
for
this
as
an
NBC
or
actually.
Let
me
just
point
out
some
of
the
key
considerations,
so
you
can
kind
of
help
analyze
this
little
through
the
same
eyes
that
we
were
is.
This
has
been
a
deal-breaker
for
clients
upgrading
to
ultimate
and
using
our
secure
features,
because
they
want
that
control
over
a
merge
request
with
certain
vulnerabilities
that
have
not
been
fixed
by
the
developers.
A
So
so
that's
the
hot
button
on
the
business
side.
This
would
be
an
ultimate
tear
feature.
So
that's
that's
kind
of
the
block
for
it
to
be
upgrading
where's.
The
approval
settings
right
now
starts
at
premium
as
security
is
our
secure
features
and
defend
features,
of
course,
are
very
green.
Our
settings
there's
not
an
exclusive
place
for
settings,
so
we
would
have
to
reevaluate
the
information
architecture
of
where
we
want
to
put
these
settings.
A
So
this
project
definitely
surfaced
that
in
terms
of
the
the
feature
and
design
and
the
user
experience,
we
don't
want
to
create
noise
for
the
security
team
and
the
security
analyst
user.
While
they
do
want
the
control
of
being
able
to
block
merge
requests
with
certain
designated
vulnerabilities,
we
don't
want
to
create
unnecessary
noise
for
them,
because
there
could
be
a
lot
of
false
positives
with
vulnerabilities
in
our
scanning
that
we
don't
want
them
to
be.
A
You
know
getting
paying
on
on
all
of
those
rather-
and
this
is
kind
of
an
important
consideration-
is
we
want
to
make
sure
that
the
developers
have
the
responsibility
to
deal
with
the
vulnerabilities,
but
this
adds
a
layer
of
accountability
to
the
security
team,
so
it's
kind
of
a
key
distinction
to
consider.
As
we
look
through
the
designs,
the
other
thing
is
is
given
DevOps
and
CI.
Cd
security
features
should
not
slow
down
the
pipeline
or
the
merge
request
process
the
CI
CD
process.
So
you
know
we
definitely
want
to
consider
that.
A
The
consideration
of.
Should
this
be
a
separate
feature,
or
should
this
be
something
that
we
put
into
approvals
and
kind
of
fine-tune
it
that
way
in
the
case
of
this
float,
we
separated
it
right
here
and
we
put
it
in
its
own
section,
so
the
user
would
expand
this
and
they
could
toggle
on
security
gates,
and
this
drop
down
is
where
they
would
set
a
severity
level.
A
This
isn't
a
side.
I'll
actually
come
back
to
this
at
the
end.
I
want
to
just
get
your
feedback
about
that
with
settings,
but
the
next
thing
is
is
go
down
to
these
designs,
actually,
so
once
they
toggle
it
on
and
they
select
the
severity
level
that
they
like
it
defaults
at
critical,
only
they
then
hit
add
approvers.
So
that's
mirroring
the
and
leveraging
the
approvals
feature
that
we
have
now.
A
They
add
one
or
more
approvers,
which
would
be
required
for
again
for
a
critical
level
vulnerability
to
pass
through,
merge
requests.
It
would
require
this
person's
approval
and
once
they've
added
one
or
more
people,
it
would
be
safe
changes.
So
that's
following
the
design
pattern
in
our
settings
area.
A
So
how
would
this
then
appear?
It
would
appear
in
the
merge
request.
Widget,
like
the
approval
set
settings,
because
we're
leveraging
that
are
that
feature.
That's
already
there
with
the
added
text
of
security,
gate
approval
needed
from
X
Y
&
Z
person,
X
Y,
&
Z
person,
whoever
the
designated
people
are
no
other
approvals,
need
it
required
that
has
to
do
with
the
merge
request
approvals
feature
so
from
here.
One
of
these
to
either
one
of
the
users
from
the
security
team
group
or
ada
lovelace,
the
user
in
this
case
would
approve
this.
A
A
So
kind
of
going
back
to
one
side
consideration
just
to
kind
of
help.
The
user
understand
the
settings
right
now.
We
have
this
learn
more.
That
goes
to
documentation,
but
one
thing
we
kind
of
explored
in
this
case
is,
since
these
two
are
pretty
closely
related,
but
fundamentally
different.
There
could
be
some
confusion,
so
we
kind
of
explored
this
idea
to
have
this
little
question
here.
A
That's
clickable
that
says
how
does
security
gates
work
could
just
give
them
a
little
bit
more
information
about
what
this
feature
is
without
having
to
jump
to
another
tab
with
documentation.
This
drop
down
gives
them
the
kind
of
three
steps
involved
designate
an
eligible
security.
Approver
approval
is
required
for
merge
requests
with
unresolved
selectable.
A
If
vulnerabilities
are
resolved,
security
gate
is
lifted
and
security
approval
is
not
needed,
so
hopefully
it.
The
idea
here
is
that
it
can
be
a
little
bit
more
of
a
straightforward
way
to
kind
of
tell
them
what
the
distinction
is
and
how
this
feature
works
as
well
as
again
going
back
to.
Why
is
it
separate
from
merge
request
approvals?
It's
because
just
one
in
our
current
one,
there
are
these
optional
conditional
rules.
Once
you
set
approvers
that
would
conflict
with
the
requirements
for
a
security
gate,
approval.
A
So
anyway,
that
is
the
flow
where
we
are
at
in
terms
of
the
product
discovery.
Is
it
really
led
to
this
key
question,
which
is
the
proposed
that
we
just
went
through
this
direction
was
aiming
for
a
lighter,
lift
optimizing
for
delivery,
hey,
let's,
let's
get
this
out
the
door
and
let's
have
people
start
using
it.
However,
a
more
long-term
solution
may
be
figuring
out.
A
How
approvals,
how
the
approvals
feature
and
security
gates
feature
can
work
together,
and
a
user
then
would
create
approvers
and
then
designate
rules
around
those
approvals,
so
that's
kind
of
where
we're
at
now.
Some
of
the
considerations
again
is
like
that.
The
to
sort
of
conditional
rules
of
the
two
features
compete
with
each
other.
Another
consideration
is,
is
as
security
grows,
so
will
settings
and
right
now
there
actually
isn't
a
designated
area
for
security
settings.
It's
just
in
general,
so
just
kind
of
designing
for
the
future
and
kind
of
having
a
clean
information
architecture.
A
It
seems
like
it
may
be
a
good
start
to
start
splitting
it
because,
while
it's
a
security
gate
split
now,
it
may
evolve
into
security
settings
and
that
may
have
kind
of
a
subset
of
security
settings
below
it,
and-
and
this
is
kind
of
an
interesting
consideration-
that
I'd
love
your
feedback
and
experience
on
that.
You've
maybe
had
to
deal
with
this,
but
the
approval
feature
starts
at
a
premium
level,
whereas
what
we
just
reviewed
would
start
at
a
Altima
trouble.
A
B
Yeah
I
had
a
question
that
I
wrote
in
the
doc.
Maybe
you
already
went
through
that
or
it's
in
the
issue
and
I
didn't
find
it.
Why
not
reuse
the
existing
approvals
feature
allowing
users
to
specify
approvers
so
individuals
or
groups
that
are
tied
to
security?
So,
basically
saying
like
these
existing
approvers,
like
this
person
or
that
group
is
a
security
gate
and
these
are
not
security
gate
for
ISM
yeah.
A
The
the
challenges
there
that
we
experience
like
so
so
just
so
for
reference,
it's
it's
a
great
question.
This
was
literally
why
we
ended
up
separating
it
out.
This
is
the
current
merge,
request,
approvals
feature
and,
basically,
how
that
would
work.
Is
there
or
one
ways
that
we
explored,
that
it
could
work
is
that
you
could
have
the
toggle
here
to
add
security
gates,
but
that
conflicts
then
with
these.
So
then
the
next
step
that
you'd
have
to
do
is,
maybe
you
add,
an
approver
and
then
designate
that
approver
to
be
security
gates.
A
However,
so,
if
you
took
that
approach,
then
these
options
right
here
would
conflict,
then,
with
the
designated
security
gate
approvers,
because
it's
a
hard
stop
for.
If
you're
designating
someone
as
a
as
a
security
gate
approver
for
critical
vulnerabilities,
the
requirement
is,
is
that's
a
hard
stop
until
that's
taken
care
of,
or
it
receives
approval
from
that
person.
But
these
conditional
rules
right
here
like,
for
example,
this
can
override
approvers
and
approvals
required
for
merge
requests.
That
would
then
conflict
that
would
override
that
person
so
kind
of
going
back.
A
Then
considering
that
you
know
it
would
be
more
of
a
lift
here
to
kind
of
do
a
bit
of
a
redesign
with
approvals
in
general.
It
would
be
reevaluated
these
options
here,
since
so
that
they
don't
conflict
and-
and
that's
kind
of
like
what
I
closed
on
is.
We
could
go
in
that
direction.
It
just
seemed
like
a
heavier
lift
and
then
the
other
consideration
is
that
so
caridy
gates
is
for
the
next
tier
up.
So
maybe
it
was
easier
to
separate
it
for
those
reasons,
but
so
so.
C
I
just
wanted
to
ask
her
just
sort
of
ask
one
thing.
So
is
the
assumption
that
code,
owners
and
security
gate
approvers
would
be
different
stakeholders
in
this,
so
you
could
have
because
I
notice
in
some
of
our
own
repositories-
there's
you
know
a
list
of
approvers
for
merger
quests.
But
the
assumption
here
is
that
security
gate
approvers
could
be
different
from
those
approvers.
A
C
A
A
So
and
I'm
glad
that
you
and
Pedro
joined,
because
you
know
Lucas
brought
it
to
our
attention
to
and
the
issue
that
you
know.
Since
this
is
settings
we
should
really
connect,
and-
and
this
is
an
area
that
that
you
all
have
been
involved
in
so
in
those
two
different
paths
of
separating
it
out
or
kind
of
taking
this
area
and
doing
a
redesign
with
all
approvals
I
mean.
Do
you
have
any
other
thoughts
to
weigh
in
on
on
that
direction?
A
You
know,
maybe
it's
not
as
heavy
at
the
list.
As
you
know,
Andy
and
I
were
imagining,
but
also
keeping
in
line
with
with
the
tears
and
and
also
your
thoughts
on
as
security
grows.
It's
inevitable
that
it's
gonna
need
its
own
space
in
settings,
so
this
seems
like
a
sustainable
direction
to
start
evolving,
that
setting
space
so
I
guess
with
your
experience
in
settings,
what
are
kind
of
initial
thoughts
with
all
that.
B
A
C
A
And
we
don't
want
to
create
that
noise
for
the
security
analyst
like
that,
that
message
at
the
bottom
right
here
that
would
disappear
if
the
developer
removed
the
vulnerability.
So
again,
it's
it's
it's
just
when,
when
we're
thinking
about
dev
SEC
ops
with
with
developers
it,
they
have
the
responsibility
for
applying
the
security
and
taking
care
of
vulnerabilities,
but
the
security
team
has
the
accountability.
So
this
is
giving
them
the
accountability.
B
B
But
even
as
you
were
saying,
maybe
in
the
future,
you
would
eventually
even
move
the
security
gates
settings
into
another
area,
so
that
might
be
even
more
confusing
because
I
don't
know,
I
think
there
are
a
lot
of
good
things
about
one
approach
and,
and
the
other
I
would
love
to
see
more
than
assumptions
that
this
could
or
could
not
work
that
that's
what
I
would
say,
because
it's
it's
a
it's
a
big
for
for
for
all
that.
That
is
that
is
here,
I!
Think
it's
a
big
change.
B
Nonetheless,
adding
this
new
settings
area,
it's
not
something
that
it's
easy,
I
think
it's
easy
to
change
in
the
future,
but
it's
still
something
big.
So
I
don't
know.
If
this
is
the
MVC
I
would
say
the
MVC
is
piggybacking
on
the
existing
merge
request
approvals.
That
would
be
from
my
understanding
the
minimum
viable
change,
but
yeah.
E
Maybe
we
have
an
issue
open
to
explore
security
navigation
at
the
group
project,
an
instance
level,
but
in
terms
of
features
that
would
also
require
settings.
It's
unknown.
We
have
this
bill
of
materials
which
could
have
settings
in
it
and
honor
mediate,
which
could
have
more
settings
in
it,
as
well
as
license
management
which
is
tucked
into
CI
CDs.
So
there's
more
settings
so
in
terms
of
creating
an
information
architecture
that
has
more
than
one
setting
involved.
We
do
have
that
in
the
if
we
nested
security
features
together.
D
Yeah
I
was
just
curious
because
it's
a
little
risky
if
we
put
something
somewhere
and
then
let's
say
three
milestones
later
it
moves.
So
if
we
can
think
a
little
bit
more
long-term
and
if
we
are
fully
aware
that
we
are
going
to
have
additional
secure
settings
and
we
have
a
level
of
confidence
that
they
need
to
be
separated.
Or
there
needs
to
be
this
security
settings
area,
then
that
should
influence
the
decision
here.
E
A
You
know,
and
and
that's
kind
of
the
direction
that
had
us
fooled.
This
security
gates
feature
out
of
this
to
merge,
request
approval
section
just
so
that
you
know
it
starts
its
own
section
and
you
start
building
the
security
features
on
here
and
and
I.
Think
last
week,
Christy
and
Shane
pointed
out
that,
well,
you
know,
eventually
it
seems
like
security
would
even
you
you
should
consider
it
meriting
its
own
section
over
here,
like
general,
doesn't
seem
like
an
appropriate
appropriate
place,
so
I
agree
yeah,
so
it
kind
of
goes
back
to
those
two
questions.
A
Is
it
Pedro's
point?
It's
like
the
MBC.
What
is
the
NBC?
Is
it
making
it
easier
in
leveraging
the
merge
request
approvals
that
we
have
today
and
just
putting
it
in
there,
but
then
that
discounts
kind
of
the
long-term
strategic
information
architecture
initiative
that
that
you're
kind
of
alluding
to
Valerie
and
and
that's
kind
of
where
we're
at
is
like
well,
which
direction
do
we
want
to
take
on
that
and
which
one
makes
more
sense?
A
E
Maybe
we
we
can
explore
the
two
pages
point
about
like
an
MVC.
We
explore
integrating
it
into
merge,
request
approvals
and
then
once
the
feature
kind
of
makes
its
gains
and
maturity.
We
kind
of
then
are
able
to
have
more
flexibility
being
pulled
out
and
then
put
it
into
its
own
settings
area,
and
then
that
can
be
like
a
big
like
hey
now
like
now.
B
Yeah,
it's
exactly
that
and
I
think
and
that's
the
point
of
the
the
product
discovery
issue.
Is
it's
not
just
to
find
out
what
the
MVC
is,
but
it's
to
kind
of
paints
the
picture
of
what
is
ahead
like
what?
What
are
we
looking
for
in
terms
of
second
or
third
iterations?
On
top
of
this,
and
as
as
you
progress
along
that
iteration
timespan
like
the
first
second
third,
things
start
getting
more
blurry
right.
B
We
start,
we
start
having
less
and
less
confidence,
but
at
least
we
can
see
more
or
less
where
we
can
go
and
that
can
help
us
along
the
way
and
yeah
I.
Think
that
that's
the
way
it
lab
has
worked
so
far
is
is
like
doing
the
MVC
seeing
how
that
acts
out
in
the
world
for
some
things
it
works
for
others.
There
are
so
many
questions
that
we
need
to
do.
Research
I'll,
leave
it
up
to
you.
How
confident
you
feel
about
certain
things
and
if
you
need
research
for
them.
F
A
F
So
if,
if
we
had
visibility,
if
we
already
knew
what
kind
of
settings
we
might
put
in
security
settings
area,
this
could
have
been
a
good
candidate,
maybe
for
tree
testing,
because
to
petros
point
it
seems
like
if
I
understand
correctly,
the
question
is:
where
would
a
user
expect
to
find
the
security
gate,
approval,
widget?
Or,
if
that's
the
word
so,
but
but
if
we
don't
really
know
or
have
a
suggestion
for
what
that
settings,
he
was
going
to
look
like
down
the
road.
F
Maybe
I
can
actually
it's
worth
the
Chad
with
Sara
and
Catherine
they've
done
a
lot
of
work.
Around
navigation
I'm
still
not
cut
off
on
that.
Maybe
there's
something
there
that
we
can
do
in
terms
of
research.
That's
more
exploratory
as
opposed
to
testing
a
given
option.
Don't
know
I
have
to
think
about
that.
B
Yeah
well
one
thing:
I
just
wanted
to
point
out
and
we're
already
over
time
in
Marcel
I
before
this
call
I
suggested
to
Marcel.
Oh
wow,
you
should
add
that
issue
that
you're
working
on,
so
you
can
discuss
it
yeah,
but
I
just
wanted
to
finish
and
I
will
stop
talking
just
to
say
that,
of
course,
research
needs
to
be
done
to
figure
out
that
navigation
and
that
settings
for
security,
but
I
just
again
not
having
a
lot
of
information.
I'm,
not
working
with
the
security
folks.
B
I
just
want
us
to
be
aware
that
sometimes
we
we
want
to
make
things
our
own
and
have
our
own
space
when
sometimes
it's
it's
not
necessary.
It's
like
that
that
big
problem
that
web
designers
have
that
each
department
of
the
company
wants
to
have
a
slice
of
the
home
page.
You
know
it's
a
bit
like
that,
I'm,
not
saying
that
that's
what
you're
doing
and
all
we
should
have
our
own
space
and
we
need
our
own
seat
settings
area.
B
D
I
think
that's
a
great
point.
We
don't
want
to
ship.
The
org
I
think
that's
kind
of
the
phrase
that
people
tend
to
use,
but
at
the
same
time
we
should
look
at
how
others
are
doing
this,
and
it's
very
like
having
a
security
area
is
not
abnormal
it's
pretty
common.
So
we
need
to
take
that
into
consideration.
So
not
I.
Don't
have
the
answer
I'm,
not
saying
that
we
should
go
one
way
or
the
other,
but
we
definitely
need
to
look
into
it
and
I.